Мысли вслух по поводу распределённой социальной системы

Balancer> 2. Ведение распределённой базы пользователей

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

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

Проблема...

3. Завести центральную базу специально для OpenID, с которой будут знакомы все сервера системы. Вроде бы удар по распределённости, но это всё же не священная корова.
4. Использовать p2p для передачи и хранения расширенной информации... Но тогда идентификаторы пользователей должны быть уникальными.

Balancer>> 2. Ведение распределённой базы пользователей
Balancer> Однако, такой вариант может обеспечить неплохую защищённость системы от падения отдельных узлов. Блоги соответствующего сервера станут недоступны, а вот пользователь сможет работать (читая доступные блоги) с другого, работающего сервера.

читал?


===
Современный интернет похож на пруд. То, что легко увидеть, заглянув в эти камыши, — это гуси (сайты). Они плавают на поверхности, они всем видны. Но есть еще караси (посетители), их несравненно больше, чем гусей, но их не видно — караси под водой. Мы лишь иногда видим круги на воде, и по ним можем догадываться, что караси здесь невидимо ходят.
Ситуация эта не менялась много лет, но браузеры развивались, и теперь браузер пользователя — это некий агрегат, который управляется скриптами, способен сам бегать по разным сайтам, собирая информацию для страницы, и — что особо интересно! — эту информацию хранить. Потому что есть html5, браузерные хранилища, есть кое-где SQLite, есть флэш-хранилища наконец. И все это может хранить информацию чуть ли не до 5 мегабайт и больше. Есть отдельный вопрос, доступна ли эта информация только сайту, который ее туда положил на хранение или можно ее сделать общедоступной. Этим вопросом я пока не интересовался, но и не суть важно. Кроме того, компьютер посетителя — это не терминал, а самостоятельная штука большой вычислительной мощности (иногда — больше, чем сервер).
Теперь смотрим сюда:
.....
Что это было?! Этого всего на моем сайте нет и никогда не было. Я тут ни при чем вообще. Эти блоки сам собрал на вашем экране ваш браузер, пока собирал эту страницу. Он побегал по разным сайтам и собрал. А сайты, между прочим, его отметили как посетителя, записали в статистику, провернули счтчик посещаемости и т.п. Но я и мой сайт тут ни при чем — я только дал вашему браузеру, грубо говоря, что-то вроде такого (владельцы движка поймут):
{_IMBLOAD: Error _}
{_IMBLOAD: Леонид Каганов: 2010/11/13 Биноник: сделали сервер публичного проекта _}
{_IMBLOAD: http://vasya_pupkin.dyndns.org/blog/2010/11/12.html _}
{_IMBLOAD: Ошибка 404: файл не существует _}
Это работает, причем уже полгода как (только обновиться бы, я там подправил чуть . Работает это, правда, только с сайтами на движке, которые поддерживают мой протокол IMBLOAD. Я пока не интересовался вопросом, может можно какой-то JSON употребить, не изобретая велосипедов. Для чего это нужно? Во-первых, таким способом можно читать, например, френд-ленту. Не на одном сайте, и не специальными клиентами, а вот так вот — браузер сам пробежался, куда надо было, и собрал. Кроме того, необязательно копировать себе понравившийся пост Васи Пупкина — пусть он грузится с родного сайта, вдруг Вася написал дополнение или исправил опечатки?
Следите за мыслью дальше. Обратим внимание, блок номер три от Васи Пупкина — «не загрузился». На самом деле, такого сайта и нет, это я для примера. Почему сайт не отвечает? Да не важно. Быть может, блог Васи Пупкина находится на его домашнем компьютере, и он сейчас выключен, а Вася на неделю уехал в деревню.
И вот дальше начинается самое интересное. Предположим, браузер видит, что сайт недоступен. Нет гуся на пруду, в нашей терминологии. Но есть караси. Которые, быть может, хорошо знают этого гуся, быть может, были у него на сайте совсем недавно и у них в кэше (который, как мы помним, много мегабайт) могла сохраниться его страница. Дело за малым: найти карася, у которого остался кэш. Конечно, браузеры между собой общаться не могут. Но они могут послать сигнал на ближайший сайт системы о том, что такой-то узел не отвечает, нет ли кэша? Кэша, понятное дело, у сайта нет. Но зато он теперь будет спрашивать всех проходящих мимо браузеров, не сохранилось ли у них этого материала. И если сохранилось — то пришлите на сайт, чтобы его снова раздавать.
Мораль: нет ничего невозможного в том, чтобы создать технологию и сеть движков, которая бы стирала разницу между гусями и карасями. В результате мы получаем надежную отказоустойчивую самовосстанавливающуюся систему. И как только я закончу строить на binoniq.net традиционную «гусиную» составляющую (блогохостинг с классическими пользовтаелями), я наверно начну эксперименты по работе с «карасями», потому что я думаю, что за этим будущее. По крайней мере — одна из важных составляющих информационного будущего.
===

Tico> 3. Завести центральную базу специально для OpenID, с которой будут знакомы все сервера системы.

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

Tico> 4. Использовать p2p для передачи и хранения расширенной информации...

Не катит. Это же потребует особых клиентов. У нас же у пользователей простые браузеры. Или XMPP-клиент.

Чтобы стереть разницу окончательно, нужно ввести распределённое хранение данных уже в больших обьёмах на компьютерах у юзеров. Мегабайтами тут не обойдёшься. А секьюрный распределённый storage уже есть - это Freenet.

Kuznets> читал?

Нет. Идея интересная и очевидная, но сегодня мало актуальная. Очень уж много ограничений на браузеры накладывает.

Если так важна доступность серверных данных, то проще на серверах дублирование организовать

Хотя - да. Мысль о дублировании информации весьма интересна и полезна.

Balancer> Так что нужно иметь базу привязок OpenID и серверов пользователей (централизованную или унифицированную - уже другой вопрос).

Ну да. Собственно примерно как ed2k.

Balancer> Не катит. Это же потребует особых клиентов. У нас же у пользователей простые браузеры. Или XMPP-клиент.

Сегодня нет простых браузеров Плагин?

Tico> Сегодня нет простых браузеров Плагин?

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

...

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

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

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

Ага. Кстати, p2p для обмена данными пользователя можно использовать только между серверами. Клиент передаёт ID на ближайший сервер, тот уже дальше тягает остальную с пиров. Но явный минус такой системы в её тормознутости. Тут идея центральной базы заруливает идею чистого p2p.

Tico> Кстати у того же Freenet есть и болталка и типа форумы и борды.

Уже года полтора они перманентно мертвы Старые варианты оказались сильно уязвимы к спаму и DDoS, новые так и не сделали. В общем, мне так и не удалось в них ни разу пообщаться

Tico> А собственно чем так хороша идея распределённости социальной сети?

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

Вот понравился мне чей-то блог на Фейсбуке. Но я не читаю Фейсбук, я хочу читать этот блог в своей ленте на Авиабазе. С имеющимися системами такого не реализовать.

Tico> Т.е. чего ты пытаешься добиться, малоуязвимости, привата, или перформанса?

Удобства и унификации

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

Так почему бы не сделать ещё один шаг и, раз уж мы уже работает с внешними ресурсами (те же трансляции и кросспостинги) не сделать такую же распределённую систему? А уж если она ещё и сможет обеспечить резервирование при падении одного из серверов - это вообще будет прекрасно

Tico> Ага. Кстати, p2p для обмена данными пользователя можно использовать только между серверами.

Это уже s2s называется и используется во многих протоколах, в том же XMPP

Balancer> Вот понравился мне чей-то блог на Фейсбуке. Но я не читаю Фейсбук, я хочу читать этот блог в своей ленте на Авиабазе. С имеющимися системами такого не реализовать.

А разве RSS не призван заниматься как раз этим?

Balancer> Так почему бы не сделать ещё один шаг

Т.е. это в общем навороченный кросспостинг на едином протоколе?

Balancer> Это уже s2s называется и используется во многих протоколах, в том же XMPP

Ну и чудненько - осталось посадить обмен персональными данными на неё. Но всё равно тормозить будет, это неизбежно, увы

Tico> А разве RSS не призван заниматься как раз этим?

RSS тебе не позволит комментировать сообщения в ленте

Tico> Т.е. это в общем навороченный кросспостинг на едином протоколе?

По сути, где-то так

Tico> Ну и чудненько - осталось посадить обмен персональными данными на неё. Но всё равно тормозить будет, это неизбежно, увы

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

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

Balancer> RSS тебе не позволит комментировать сообщения в ленте

А и не надо. Его можно использовать только для переотражения ленты на твоём сайте. А отправку сделать как ты уже сказал, отдельным потоком.

Balancer> Тут подразумевается, что вся реальная нагрузка будет идти на сервер пользователя от его пользователей.

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

Tico> Я имел ввиду другой юз кейз - при авторизации пользователя пройдёт время, пока вся персональная информация становится доступной на том сервере через который пользователь зашел.

В современном Интернете - это ничтожно Всё за миллисекунды решится.

Tico> Если авторизация может проходить быстро, то подгрузка инфы через p2p может занять время

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

Balancer> Тем более, что сегодня такая система итак массово иже используется, когда ты на стороннем сайте авторизуешься через facebook или gmail

Убедил

PS: Увы, работать надо