LINUX.ORG.RU
ФорумTalks

Распределённая социальная система. Продолжение изысканий. Мысли вслух.

 , , ,


4

4

В продолжение тем, типа Распределёные форумы/блоги. Продолжаем разговор. Нужен совет. и подобных :)

Понимание того, как должна выглядеть и работать наша социальная система всё чётче кристаллизуется. Чую, скоро приступлю к практическим экспериментам :) Хотя в отсутствии коммьюнити, при наличии только собственных нод и одного источника данных, работать будет не так интересно.

...

Ознакомился я тут с относительно популярными в наше время готовыми решениями. Diaspora, Identica, GNU Social.

Основная проблема, не дающая им (ИМХО) нормально стартовать — отсутствие гейтов к имеющимся данным классических систем что сразу снижает интерес и малая польза от распределённости. Пользователь всё равно остаётся привязан к собственной ноде. Пусть даже в некоторых реализациях и возможен ручной перенос данных на другие ноды. Нет прямого обмена контентом между нодами. Только по подписке пользователей.

Думаю, более востребованная система, в отличие нынешних, должна предоставлять:

— Гейт-доступ к имеющимся материалам классических форумов и блогов. Тут понятно и без комментариев. Есть информация — есть пользователи.

— Автоматический обмен контентом не по подписке пользователя, а в рамках категории. Сейчас пользователь, ищущий что-то интересное, должен предварительно обыскивать остальные ноды сам. И только найдя нужное, может подписаться на потоки. Нужно, чтобы всё актуальное можно было найти на одной текущей ноде.

— Обмен пользовательскими данными. Пользователь должен уметь размножать свой идентификатор на более чем одну ноду. Чтобы при потере одной из нод из сети, он мог продолжить работу через другие ноды не перерегистрируясь и не перенося данные.

...

— Кстати, замечание — основной контент обязан быть публичным. Чтобы гости имели возможность читать статьи и обсуждения без предварительной регистрации.

Ну и проблема подобных систем — очень узкая трактовка материалов. Нужны не только блоги/микроблоги, но и публикация статей (в т.ч. Wiki), форумы/обсуждения, фотогалереи и т.п. Писал на этот счёт мысли в http://www.balancer.ru/g/p3864467

...

Вот по архитектуре системы пользователей пока чёткого понимания вопроса нет. Думаю, вначале можно будет стартовать и с нынешним вариантом, прибитых к ноде гвоздями юзеров.

Зато довольно чёткие начальные представления по обмену данными.

Для хранения больших объёмов данных, картинок и аттачей, пока наиболее интересным вариантом выглядит IPFS. Основные плюсы:

— Файлы идентифицируются по хешу содержимого. Можно залить на разных нодах одни и те же файлы, у них останутся одни и те же идентификаторы.
— Система работает достаточно быстро. Я бы сказал, вполне на уровне нынешнего Web'а. Речь, конечно, о первой межнодовой передаче файла, потом он кешируется и отдаётся шустро.
— Система легко расширяется, софт на Golang прост в установке.
— Готовая прозрачная система гейтования. Можно использовать выдачу данных с гейтов сразу, не имея привязки к ним.

Минусы:

— Нет(?) вменяемого контроля наличия файлов в сети. Если все ноды-хранилища с файлом исчезнут, то никто не гарантирует доступность файла со временем
— Похоже, система разрабатывается одним человеком, что не очень хорошо гарантирует её будущее.

Для хранения, собственно, архива сообщений думаю попробовать Gittorrent. Не выгорит с ним (хотя почему нет?) можно будет прозрачно использовать обычный Git, хотя это снизит гибкость привязкой к серверам репозиториев.

Перемещено JB из general

★★★★★

по «утягиваемым картинкам» могу предположить хранение со счётчиком ссылок. как только ссылки равны нулю - можно удалять.
а так, это смахивает на базы данных с шардингом. разбить юзеров на группы и хранить на разных серверах. для надёжности можно сделать кластер. заюзать что-нибудь типа cassandra на P2P: https://www.facebook.com/notes/facebook-engineering/cassandra-a-structured-st...

Iron_Bug ★★★★ ()
Ответ на: комментарий от Iron_Bug

по «утягиваемым картинкам» могу предположить хранение со счётчиком ссылок. как только ссылки равны нулю - можно удалять

Доля утерянных файлов всегда составляет очень небольшую величину, считанные доли процентов, так что на эту проблему можно забить.

Я тут сообразил более серьёзную проблему IPFS. Она не позволяет _расшаривать_ каталоги архивов файлов. Т.е. составить некий индекс и отдавать прямо с живой копии. Она позволяет только _зааплоадить_ файлы (в т.ч., да, целыми каталогами) в сеть. Фактически на нодах получится двойное хранение. Исходные файлы и локальное IPFS-хранилище. Убивать оригиналы же стрёмно, ибо тогда они оказываются в замкнутой на себя системе, где их сложно контролировать.

Тут надо подумать ещё будет.

а так, это смахивает на базы данных с шардингом

Да. Шардинг с репликацией :) Ноды выбирают, что конкретно им у себя хранить (что-то в духе старого FIDO с подписками на эхи). Количество нод с идентичным контентом определяет избыточность и отказоустойчивоcть.

заюзать что-нибудь типа cassandra на P2P

Я хочу реализовать систему, не привязанную к какой-то платформе на уровне обмена данных. Как хранить данные внутри ноды — это её личное дело. Где-то будет PHP+MySQL, где-то — NodeJS и MongoDB, где-то — flatfile и ручная работа с JSON-файлами.

Собственно, я не переоцениваю силы и не хочу велосипедить с уймой фронтендов и бэкендов. Буду пытаться реализовать протокол для синхронизации разных систем. Написал, например, один юзер с мобильного клиента в Wordpress в свой блог. А блог Wordpress-плагином соединён в сеть. И его запись уже читает другой пользователь на другом сервере в форуме MyBB. Или под тем же Android в Tapatalk.

Хотя это предельный случай, начну я, конечно, с задач попроще. В первую очередь — обмен данными в своих проектах. Может быть, кросспостинг в распределённые p2p-сети с целью привлечения внимания. Контента там сейчас мало :)

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

с репликацией всегда была одна проблема: консистентность и залочивание для записи. когда копий много - встаёт вопрос, как лочить их, если юзер собрался редактировать данные. чтобы два юзера одновременно не отредактировали один файл. и чтобы последующее редактирование было возможно только после полной репликации, когда точно известно, что файл одинаков на всех нодах. в общем, из-за этого система тормозит (на работе люди делают нечто подобное и уже наступили на кучу граблей).

Iron_Bug ★★★★ ()
Ответ на: комментарий от Iron_Bug

когда копий много - встаёт вопрос, как лочить их, если юзер собрался редактировать данные

У нас это в общем случае не проблема, т.к. у одного документа один юзер. Ну, или согласованная группа юзеров :) В случае редких конфликтов при работе в группе, просто пишем обе версии в репозиторий, а активной делаем последнюю. Или иначе согласовать — это далеко не первостепенная проблема :)

в общем, из-за этого система тормозит

В рассматриваемой системе не требуется транзакционная целостность. Там, вообще, возможна асинхронная репликация с произвольными задержками. Кто-то может вообще, например, на форуме отвечать офлайн. И только при следующей синхронизации данные расползутся о другим нодам.

KRoN73 ★★★★★ ()

Ты хочешь интернет без серверов, причём

  • если пользователь ставит флажок «хочу хранить», то данные копируются к нему;
  • если пользователь ставит флажок «хочу читать», то данные распределяются между всеми нодами пропорционально количеству таких «лайков» (больше лайков — больше вероятность сохранности файла);
  • если процент лайков падает ниже порогового значения, файл удаляется у всех нод, кроме поставивших «хочу хранить».

?

d ★★★ ()
Ответ на: комментарий от d

Ты хочешь интернет без серверов, причём

С серверами. Но с заменяемыми.

если пользователь ставит флажок «хочу хранить», то данные копируются к нему

Нет. Если нода (сервер) отмечает «хочу хранить данные таких-то других нод и/или участников».

если процент лайков падает ниже порогового значения, файл удаляется у всех нод

Такие механизмы можно как обсуждать уже позже, так и оставлять целиком на желание конкретных нод.

KRoN73 ★★★★★ ()
Ответ на: комментарий от d

Или ты хочешь отвязать контент от формы и хранить его в файлах внутри всеобщей 9pfs, чтобы можно было делать rsync на директории интересующих людей, когда выходишь онлайн?

d ★★★ ()
Ответ на: комментарий от d

Или ты хочешь отвязать контент от формы

Это одна из задач. Но не как самоцель, а как средство обмена между нодами. Внутри себя нода может хранить данные в любом удобном для неё виде.

внутри всеобщей 9pfs, чтобы можно было делать rsync на директории интересующих людей, когда выходишь онлайн?

Я пока полагаю (пока без экспериментов, может по ним обламаюсь), что удобнее файлы между нодами синхронизировать через ipfs, а тексты — через git и/или gittorrent.

чтобы можно было делать rsync на директории интересующих людей, когда выходишь онлайн?

Не буквально rsync, но обмен актуальными данными. И «когда выходишь онлайн» — это крайний случай, как правило обмен данными между нодами должен идти онлайн. Пусть и не с такой синхронностью, как принято в кластерах. Не страшно, если данные при обмене будут запаздывать на минуты. Это не IM.

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

ну, согласованных юзеров в природе не бывает. если их не ограничивать только одним логином на всех.
а репликация с произвольными задержками может приводить к сюрпризам типа: юзер ответил, а топика или поста, на который он отвечал, уже нет (удалили). и тут непонятно, как разруливать подобные ситуации. в итоге получатся объекты, которые и удалены, и не удалены одновременно. и то же самое с редактированием.

Iron_Bug ★★★★ ()
Ответ на: комментарий от Iron_Bug

а репликация с произвольными задержками может приводить к сюрпризам типа: юзер ответил, а топика или поста, на который он отвечал, уже нет (удалили)

В сети нельзя удалить материал. Это частное дело конкретных нод. Соответственно, ответ останется на тех нодах, где топик остался неудалённым.

Это же одна из задач системы, обеспечить сохранность материалов от всякого государственного влияния и т.п. :)

и то же самое с редактированием

Это будет актуально только для коллективных статей/wiki. Достаточно редкий случай. И конфликты в таком случае можно разруливать вручную.

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

если в сети нельзя удалить материал - она через неделю будет засрана ботами, в том числе государственными :)
тогда нужна возможность защиты сети от злонамеренных нодов.

Iron_Bug ★★★★ ()
Ответ на: комментарий от Iron_Bug

если в сети нельзя удалить материал - она через неделю будет засрана ботами

Ноды, которые будут пускать таких ботов, будут просто исключены из сети :)

тогда нужна возможность защиты сети от злонамеренных нодов

Естественно, что получать данные нода сможет только с нод, которым она доверяет, а не с любых.

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

Наверное, потому, что я читаю сейчас Computer Networks, мне пришла в голову следующая мысль: ты хочешь продумать и реализовать стек протоколов не столько для обмена данными, сколько для их представления.

Вот тебе ночная аналогия. Ты пишешь в текстовом редакторе текст. Хочешь кому-то показать, или кто-то хочет прочитать. Чтобы это сделать, тебе приходится подниматься на самый верхний уровень сайтов-бложиков, и то же приходится делать твоему читателю. Этот файл лежит в твоей ФС, и было бы разумно решить вопрос на этом уровне. Но стек протоколов представления информации так сросся, что нельзя получить текст сам по себе, его приходится оборачивать в «пост в жж», «коммент на лоре», «объявление на авито». И ты говоришь: так, у меня есть заметка, а какой протокол высокого уровня использовать для её просмотра (жж, лор, авито) — это дело читающего. Может, он вообще поставит локальное приложение просмотрщик постов. С треем и пиктограммами.

Т.е. ты создаёшь на своей ноде директорию, и интересующиеся люди её синхронизируют. Или ты запрашиваешь у лора новую директорию, тебе её создают в /general, а я лазил по лору, увидел твою директорию и стал создавать поддиректории.

Вот нету подфайлов, беда. Директории отражают древовидную структуру, но формально не могут содержать контента вне файлов.

d ★★★ ()
Ответ на: комментарий от KRoN73

Ноды, которые будут пускать таких ботов, будут просто исключены из сети :)

Как бишь там, «снести с бона»? :)

al_exquemelin ★★★ ()
Ответ на: комментарий от KRoN73

тут всё равно не получится удачного для всех решения. потому что даже нормальные юзеры раздувают флуд и могут устраивать холовары. допустим, Вася терпеть не может Петю и хочет удалить петины комментарии у себя на ноде. но у их общего друга Вани есть все комментарии и после рептикации - увы! всё возвращается к тому, как было. по принципу «четырёх рукопожатий» получится, что все будут читать всех. и будет сложно сделать так, чтобы все юзеры были довольны и чтобы в контенте не было шлака. тогда уж лучше сделать мэйл-листы - это то же самое, по идее. отложенные комментарии, все пишут, что хотят, а каждый юзер на входе фильтрует рассылку и оставляет то, что считает нужным. если прикрутить к агенту мыла обработчик «обновлений», то получится как раз примерно то, что требуется.

Iron_Bug ★★★★ ()
Ответ на: комментарий от d

Наверное, наоборот: лор и жж — это протоколы низкого уровня. Текст over лор, фото over вк. А ты хочешь единый протокол, чтобы всё over него. И пока мысли приходят к ФС в роли протокола и файлу в роли его пакета. Всё over ФС.

d ★★★ ()
Ответ на: комментарий от Iron_Bug

тут всё равно не получится удачного для всех решения. потому что даже нормальные юзеры раздувают флуд и могут устраивать холовары.

Правила нод индивидуальны. Т.е. модераторы ноды могут банить каких-то юзеров по своим правилам и их контент на выбранной ноде показываться не будет. Я в порядке эксперимента такое хочу на своих форумах попробовать даже без вопросов репликации. Реализовать несколько сервисов с общей синхронизируемой базой, но разными наборами правил. От полного отсутствия всяких ограничений (не левом домене, типа, забанит Роскомнадзор — фиг с ним, можно на другом поднять) на одном сервере до жёстких клубных правил на другом или хитром наборе экспериментальных ограничений на третьем.

но у их общего друга Вани есть все комментарии и после рептикации - увы! всё возвращается к тому, как было

Так UUID пользователя общий на всю систему. Забанили юзера на ноде, его сообщения не показываются, откуда бы они не пришли (хранить ли их транзитом или вообще не принимать — тоже дело ноды).

тогда уж лучше сделать мэйл-листы

Если довести мейл-листы до ума, то получатся те же самые форумы с нодами :)

KRoN73 ★★★★★ ()
Ответ на: комментарий от dk-

Информация должна быть доступной независимо от произвола отдельных личностей.

KRoN73 ★★★★★ ()

Гейт-доступ к имеющимся материалам классических форумов и блогов

Практически не реально, разве что экспорт. Все сообщения надо подписывать как минимум дважды - пользователем и нодой. На каком из форумов сообщения идентифицируют по подписи?

Для хранения, собственно, архива сообщений думаю попробовать Gittorrent.

Зачем? Текст все равно ничего не весит и отлично жмется. При редактировании будет еще одно сообщение с тем же ид но более новым таймштампом.

KillTheCat ★★★★★ ()

А чем не годится Frost@Freenet? Но это не совсем социальная сеть, это аналог Фидо, только на Р2Р. А социальные сети нафиг...

Flame4all ()
Ответ на: комментарий от KillTheCat

Все сообщения надо подписывать как минимум дважды - пользователем и нодой. На каком из форумов сообщения идентифицируют по подписи?

Что мешает заводить табличку соответствия local_user_id и node_id+user_id?

Зачем?

Для удобства контроля изменений. Для удобства клонирования. Один фиг, нужен p2p обмен данными, в т.ч. для забора архивов простыми юзерами. Какую альтернативу можно предложить? rsync не децентрализован :)

KRoN73 ★★★★★ ()
Ответ на: комментарий от Flame4all

А чем не годится Frost@Freenet?

— Это чистый p2p, поэтому страшно тормозной
— Нет никаких гарантий сохранения нужных данных
— Собственная структура данных, не ориентированная на удобный обмен между нодами
— Отсутствует гейтовая система, интеграция с обычными инструментами
— Отсутствует система категорий данных
— Отсутствуют раздельные рейтинговые системы с настройкой индивидуальной репликации по нодам
— ...

Короче, это совершенно другая система :) Но, в принципе, можно подумать и о двустороннем гейтовании в неё из моей :D Я не разбирался, там API есть нормальный?

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

Это чистый p2p, поэтому страшно тормозной

Так хорошо же, неполноценный (не децентрализованный) р2р нафиг. Лучше тормоза потерпеть. Подумаешь сообщения не моментально приходят...

Нужность других пунктов не понял.

не разбирался, там API есть нормальный?

Собственно, Freenet предоставляет распределенное р2р хранилище (данные хранятся у пользователей в зашифрованном виде), на основе него ты можешь пилить любой сервис. Недостаток один: демон на Java.

Flame4all ()
Ответ на: комментарий от Flame4all

неполноценный (не децентрализованный) р2р нафиг

Тебе не нужен. Ну так я не о твоих запросах речь веду :)

Нужность других пунктов не понял.

Потому что тебе не нужно :)

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

Ну может быть ты меня можешь переубедить аргументами и я тоже захочу.

Flame4all ()
Ответ на: комментарий от Flame4all

Ну может быть ты меня можешь переубедить аргументами и я тоже захочу.

Зачем тебя переубеждать? :) Ты ж не целевая аудитория.

А я хочу просто дать удобный и мало зависящий от судьбы конкретных серверов инструмент для обмена информацией обычных пользователей. Которым пофиг на анонимность, но которым важна скорость и удобство работы.

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

мало зависящий от судьбы конкретных серверов инструмент для обмена информацией

Ну и как этого можно добиться без полноценного р2р, без полной децентрализации по принципу dht?

Flame4all ()
Ответ на: комментарий от Flame4all

Ну и как этого можно добиться без полноценного р2р

Достаточно федеративной системы. Ушёл один сервер — продолжаем работать с другого.

...

Массовые отказоустойчивые кластерные решения работают не на p2p и dht :)

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

А причём тут отказоустойчивость? Если это единственное что тебя волнует, то больших технических сложностей тут нет, 99,9% аптаймом никого не удивишь. Сейчас всяких роскомнадзоров и JB следует бояться больше всего.

Flame4all ()
Ответ на: комментарий от Flame4all

А причём тут отказоустойчивость?

При том, что сабжевая идея (в плане надёжности, хотя это не единственный аспект, который меня интересует) требует отказоустойчивости :)

99,9% аптаймом никого не удивишь

Аптайм тут вообще не при чём. Я же даже про офлайн писал :) Главная задача — сохранение информации при уходе из сети нод. Насовсем. Надоело владельцу, разорился он или помер — с нынешними реализациями всё, капец информации. Я хочу, чтобы она продолжала оставаться доступной.

Сейчас всяких роскомнадзоров и JB следует бояться больше всего.

Вот, это и от них защита. При чём защита более хитрая, чем тупой уход за рубеж. Например, возможность публично показывать внутри страны только разрешённый в ней контент, давая к нему свободный доступ на нодах, не входящих в юрисдикцию страны-запретителя. Если тупо увести популярный ресурс — он теряет часть пользователей. Война блокировок — вообще оставляет только самых лояльных. А тут получится и нормальное общение на привычных ресурсах внутри страны без нарушения законов, и сохранность/доступность информации для тех, кому нужно.

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

Что мешает заводить табличку соответствия local_user_id и node_id+user_id?

Я про экспорт из обычных форумов. Конечно, можно постить подписанное сообщение как текст и автоматически парсить, но юзерам будет не удобно. Придется и постинг переделать и отображение, жирный такой плагин будет.

Да и кто станет их писать? Разрабы новой системы скорее сделают свою социалочку чем станут писать плагины к какому-то вордпрессу.

KillTheCat ★★★★★ ()
Ответ на: комментарий от KRoN73

Ну и зачем что-то выдумывать, когда принципы, лежащие в основе Freenet решают почти все эти проблемы?

Flame4all ()
Ответ на: комментарий от Flame4all

Ну и зачем что-то выдумывать, когда принципы, лежащие в основе Freenet решают почти все эти проблемы?

Если бы решал, все давно были бы во Freenet, но там даже ЛОРа нет, потому как бомбоубежища нужны для войны, а для жизни нужны клиенты, бэкапы и доступность.

ChudoYudo ()
Ответ на: комментарий от Novator

А с проектом Pandora знакомы?

Мне идея понравилась и правильно с клиента начато, но от плагинов сразу отказались, в результате обсуждение клиента идёт в ВКонтакте, а в самом клиенте такое обсуждение невозможно, с github аналогично.

Собственно это один из критериев, социальная сеть нового типа, должна уже на старте как минимум быть способна сама себя обсуждать, а желательно и поддерживать.

ChudoYudo ()
Ответ на: комментарий от Flame4all

Так война же

Так даже во время войны в бомбоубежищах проводит время лишь малая часть населения и не всё время.

Всё очень серьёзно. Lurkmore всё

Вот поэтому и нужен сабж. Чтобы мало влияла на работу сервисов как прихоть отдельных владельцев, так и злоупотребления государства.

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

Так даже во время войны в бомбоубежищах проводит время лишь малая часть населения и не всё время.

Смотря какая война. Тут аналогии из реального мира мало годятся. Матрицу смотрел? Там народ жил под землёй. Тут та же фигня, нам придётся уйти в подполье, а пролетариям придётся жить в искусственном мире, созданном роскомнадзором.

Flame4all ()
Ответ на: комментарий от Flame4all

Смотря какая война. Тут аналогии из реального мира мало годятся

А аналогии вообще развивать нельзя :) Карта никогда не равна территории.

Матрицу смотрел? Там народ жил под землёй.

А теперь попробуй эту аналогию не из бомбоубежища развить, а из современного состояния Интернета.

KRoN73 ★★★★★ ()
Ответ на: комментарий от Flame4all

Смотря какая война. Тут аналогии из реального мира мало годятся. Матрицу смотрел?

Годятся только аналогии реального мира, учиться надо у Столлмана: открытость, вирусность, массовость.

ChudoYudo ()
Ответ на: комментарий от KRoN73

А теперь попробуй эту аналогию не из бомбоубежища развить, а из современного состояния Интернета.

Современное состояние интернет таково что большинство торчит в фейсбуках, ВК и тому подобных гадюшниках и им пофиг твоя мышиная возня, им это не интересно. Лучше забить на это болт и подумать как заработать лишних денег на пролетариях.

Flame4all ()
Ответ на: комментарий от ChudoYudo

учиться надо у Столлмана

Столлман старый маразматик и не в своём уме.

открытость, вирусность, массовость.

В России это никому не интересно, кроме полутора анонимусам.

Flame4all ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.