Криптоблоги
Dec. 4th, 2007 11:33 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vitus_wagnerТут в связи с приобретением ЖЖ СУПом пошла новая волна обсуждений того, как бы заменить ЖЖ на что-нибудь неподконтольное ни одной коммерческой структуре. Волна эта далеко не первая (см мой журнал по тэгу distributed-blog). Предыдущие как-то к созданию чего-либо реального не привели. Ну кроме lj.rossia.org, который представляет себе всего лишь площадку, подконтрольную ДРУГОЙ структуре.
Тут я еще немножко подумал и предлагаю структуру сети, которая обеспечивает примерно функциональность ЖЖ в смысле френдования, прав доступа подзамочных постов, скрытия комментариев etc, но при этом является распределенной. Причем, чем более популярен журнал, тем больше его копий существует в сети.
Сеть взаимосвязанных блогов состоит из узлов двух типов - узлов публикации и узлов чтения. Узел публикации - это обычный web-сервер, более-менее постоянно доступный в сети. который раздает блог и френдленту некоторого пользователя (пользователей). При этом копирует к себе все посты и комментарии к постам друзей этого пользователя. Соответственно, читать некоторый журнал можно через сервер любого из его френдов. Там же можно комментировать, и можно даже постить. Посты и комментарии будут реплицироваться по всем серверам, несущим данный блог. Поскольку копия foaf-файла у данного сервера есть, он всех их знает.
Узел чтения - это программа, работающая на локальном компьютере пользователя. Она либо встроена в браузер, либо работает прокси между браузером и интернетом. Выкачивая странцу блога, поста или френдленты она выполняет необходимые криптографические операции - проверяет подписи под постами и комментами, расшифровывает подзамочные посты и скрытые комментарии (если у данного пользователя есть на них право).
При постинге она подписывает текст поста или комментария, или, если необходимо, его шифрует.
На узлах публикации все открытые посты и комментарии хранится в виде xhtml-файлов, отдельные фрагменты которых подписаны в соответствии со спецификацией xml-dsig. То есть для того чтобы прочитать их, ничего кроме браузера не надо. Если совсем не предпринимать никаких усилий, то каждый пост/комментарий будет сопровождаться строчкой base64-символов, представляющих электронную подпись. Если чуточку не полениться, её можно скрыть средствами CSS.
Посты, предназначенные для узкого круга ограниченных людей хранятся в виде PGP ASCII-armored данных, т.е. тоже base64, зашифрованных для всех получателей (ведь у каждого участника системы, имеющего узел чтения, есть ключевая пара, открытую часть которой могут получить остальные участники). Когда это читается через узел чтения, оно автоматически (Прозрачно для пользователя, за исключением запроса passphrase один раз за сеанс) расшифровывается и показывается как было.
Пользователи системы делятся на три категории - свои, чужие и анонимы. Свои - это те, у кого есть узел чтения и ключевая пара.
Чужие - это те, кто постит комментарии, авторизуясь по OpenID с OpenID-провайдеров, не входящих в систему.
Их пост отправляется браузером на узел публикации (ведь узла чтения у них нет) и подписывается ключом этого узла. Эта подпись удостоверяет, что такой-то узел такого-то числа во столько-то аутентифицировал автора данного комментария по OpenID как такого-то. Ну, и также то, что никто другой с тех пор текста этого комментария не менял.
Аналогичным образом подписываются анонимные комментарии.
Если согласно настройкам блога или конкретной записи чужой или анонимный комментарий должен быть скрыт, он шифруется узлом публикации только для хозяина блога. То же самое делается если узел чтения, который так же, как и узел публикации видел эти настройки, не зашифровал комментарий сам.
С точки зрения узла публикации, все пользователи системы (т.е. свои) равны, но некоторые равнее других. Равнее других, естественно, те, которые платят за хостинг данного узла публикации. Они имеют единственное преимущество перед всеми остальными - если они кого-то добавляют себе во френды, узел публикации, узнав об этом (получив то-ли с узла чтения то-ли с другого узла публикации обновления foaf-файла этого пользователя, естественно, им подписанное) тут же начинает кэшировать блог нового френда.
В норме, конечно, каждый юзер читает свою френдленту через свой узел публикации. Но если вдруг что случилось (злые электрики вырубили свет в серверной, бульдозерист переехал кабель или кровавая гэбня конфисковала сервер) юзер может попытаться прочитать свою френдленту через любой другой узел публикации. Благо локальная копия foaf-файла у него в узле чтения есть, и тот может автоматически попытаться выяснить, какой из имеющихся в онлайне узлов публикации содержит копии наибольшего количества блогов его френдов. Узел чтения может даже попытаться автоматически собрать полную френдленту из данных с нескольких узлов публикации.
Узлы публикации синхронизируются между собой по протоколу, представляющему собой нечто среднее между RSS и NNTP - публикуется feed новых поступлений (как постов, так и комментариев, в том числе отредактированных постов, раскрытых владельцем блога комментариев etc). Увидев в feed-е идентификатор объекта, который у него отсутствует или устарел, другой узел публикации идет и забирает этот объект. По обычному HTTP.
Идентификаторы постов должны включать в себя
1. Идентификатор блога (url или e-mail-образныай адрес владельца)
2. Идентификатор (hostname) узла, где пост впервые попал в систему (узел чтения может ставить свой собственный идентификатор)
3. Некий уникальный номер внутри данного узла для данного автора.
Идентификтаор комментария должен включать в себя
1. Идентификатор поста.
2. Идентификатор узла,
3. Уникальный номер
Кроме того, в комментарии должен так или иначе присутствовтаь идентификатор комментария, ответом на который он является.
В фиде указываются идентификаторы объектов и даты выработки подписи под ними. Что автоматически позволяет определить устаревания объектов.
В качестве PKI используется pgp-шная PKI, так как она
1. Распределенная, не требует выделенных удостоверяющих центров
2. Работает давно и хорошо
3. Документирована на понятном для простых пользователю языке. Точно помню, что в комплекте pgp 2.6.3 была дока для чайников. На сайте gnupg я её сейчас не нашел, ну в крайнем случае из старых архивов выкопаем.
P.S. Следует помнить, что электронные подписи обладают свойством non-repudiation. Поэтому храните свой секретный ключ от узла чтения так, чтобы он не попал в руки кровавой гэбне. А то он послужит доказательством что именно вы написали то, что им подписано. От всего остального можно отрекаться. Даже наличие некоторого блога на вашем сервере не означает что автор его вы - мало ли, вы просто его почитать решили, а сервер взял и выкачал весь.
Тут я еще немножко подумал и предлагаю структуру сети, которая обеспечивает примерно функциональность ЖЖ в смысле френдования, прав доступа подзамочных постов, скрытия комментариев etc, но при этом является распределенной. Причем, чем более популярен журнал, тем больше его копий существует в сети.
Сеть взаимосвязанных блогов состоит из узлов двух типов - узлов публикации и узлов чтения. Узел публикации - это обычный web-сервер, более-менее постоянно доступный в сети. который раздает блог и френдленту некоторого пользователя (пользователей). При этом копирует к себе все посты и комментарии к постам друзей этого пользователя. Соответственно, читать некоторый журнал можно через сервер любого из его френдов. Там же можно комментировать, и можно даже постить. Посты и комментарии будут реплицироваться по всем серверам, несущим данный блог. Поскольку копия foaf-файла у данного сервера есть, он всех их знает.
Узел чтения - это программа, работающая на локальном компьютере пользователя. Она либо встроена в браузер, либо работает прокси между браузером и интернетом. Выкачивая странцу блога, поста или френдленты она выполняет необходимые криптографические операции - проверяет подписи под постами и комментами, расшифровывает подзамочные посты и скрытые комментарии (если у данного пользователя есть на них право).
При постинге она подписывает текст поста или комментария, или, если необходимо, его шифрует.
На узлах публикации все открытые посты и комментарии хранится в виде xhtml-файлов, отдельные фрагменты которых подписаны в соответствии со спецификацией xml-dsig. То есть для того чтобы прочитать их, ничего кроме браузера не надо. Если совсем не предпринимать никаких усилий, то каждый пост/комментарий будет сопровождаться строчкой base64-символов, представляющих электронную подпись. Если чуточку не полениться, её можно скрыть средствами CSS.
Посты, предназначенные для узкого круга ограниченных людей хранятся в виде PGP ASCII-armored данных, т.е. тоже base64, зашифрованных для всех получателей (ведь у каждого участника системы, имеющего узел чтения, есть ключевая пара, открытую часть которой могут получить остальные участники). Когда это читается через узел чтения, оно автоматически (Прозрачно для пользователя, за исключением запроса passphrase один раз за сеанс) расшифровывается и показывается как было.
Пользователи системы делятся на три категории - свои, чужие и анонимы. Свои - это те, у кого есть узел чтения и ключевая пара.
Чужие - это те, кто постит комментарии, авторизуясь по OpenID с OpenID-провайдеров, не входящих в систему.
Их пост отправляется браузером на узел публикации (ведь узла чтения у них нет) и подписывается ключом этого узла. Эта подпись удостоверяет, что такой-то узел такого-то числа во столько-то аутентифицировал автора данного комментария по OpenID как такого-то. Ну, и также то, что никто другой с тех пор текста этого комментария не менял.
Аналогичным образом подписываются анонимные комментарии.
Если согласно настройкам блога или конкретной записи чужой или анонимный комментарий должен быть скрыт, он шифруется узлом публикации только для хозяина блога. То же самое делается если узел чтения, который так же, как и узел публикации видел эти настройки, не зашифровал комментарий сам.
С точки зрения узла публикации, все пользователи системы (т.е. свои) равны, но некоторые равнее других. Равнее других, естественно, те, которые платят за хостинг данного узла публикации. Они имеют единственное преимущество перед всеми остальными - если они кого-то добавляют себе во френды, узел публикации, узнав об этом (получив то-ли с узла чтения то-ли с другого узла публикации обновления foaf-файла этого пользователя, естественно, им подписанное) тут же начинает кэшировать блог нового френда.
В норме, конечно, каждый юзер читает свою френдленту через свой узел публикации. Но если вдруг что случилось (злые электрики вырубили свет в серверной, бульдозерист переехал кабель или кровавая гэбня конфисковала сервер) юзер может попытаться прочитать свою френдленту через любой другой узел публикации. Благо локальная копия foaf-файла у него в узле чтения есть, и тот может автоматически попытаться выяснить, какой из имеющихся в онлайне узлов публикации содержит копии наибольшего количества блогов его френдов. Узел чтения может даже попытаться автоматически собрать полную френдленту из данных с нескольких узлов публикации.
Узлы публикации синхронизируются между собой по протоколу, представляющему собой нечто среднее между RSS и NNTP - публикуется feed новых поступлений (как постов, так и комментариев, в том числе отредактированных постов, раскрытых владельцем блога комментариев etc). Увидев в feed-е идентификатор объекта, который у него отсутствует или устарел, другой узел публикации идет и забирает этот объект. По обычному HTTP.
Идентификаторы постов должны включать в себя
1. Идентификатор блога (url или e-mail-образныай адрес владельца)
2. Идентификатор (hostname) узла, где пост впервые попал в систему (узел чтения может ставить свой собственный идентификатор)
3. Некий уникальный номер внутри данного узла для данного автора.
Идентификтаор комментария должен включать в себя
1. Идентификатор поста.
2. Идентификатор узла,
3. Уникальный номер
Кроме того, в комментарии должен так или иначе присутствовтаь идентификатор комментария, ответом на который он является.
В фиде указываются идентификаторы объектов и даты выработки подписи под ними. Что автоматически позволяет определить устаревания объектов.
В качестве PKI используется pgp-шная PKI, так как она
1. Распределенная, не требует выделенных удостоверяющих центров
2. Работает давно и хорошо
3. Документирована на понятном для простых пользователю языке. Точно помню, что в комплекте pgp 2.6.3 была дока для чайников. На сайте gnupg я её сейчас не нашел, ну в крайнем случае из старых архивов выкопаем.
P.S. Следует помнить, что электронные подписи обладают свойством non-repudiation. Поэтому храните свой секретный ключ от узла чтения так, чтобы он не попал в руки кровавой гэбне. А то он послужит доказательством что именно вы написали то, что им подписано. От всего остального можно отрекаться. Даже наличие некоторого блога на вашем сервере не означает что автор его вы - мало ли, вы просто его почитать решили, а сервер взял и выкачал весь.
no subject
Date: 2007-12-14 08:38 am (UTC)Кроме того, с очевидностью, никакое техническое решение не обеспечивает 100% гарантии сохранности архивов.
На мой взгляд, вероятность сохранения хотя бы одной копии архива в сети из 10 миллионов участников с "естественной" репликацией, окажется выше, чем в сети из 10000 участников с более жесткими требованиями к архивации. Просто за счет "закона больших чисел".
Решение, которое подходит для слишком большого спектра применений мне a priori кажется подозрительным - каждую конкретную задачу оно будет решать хуже, чем более специализированное решение. Поэтому не надо пытаться объять необъятное.
Тут мне уже в одном из предыдущих постов кто-то предлагал решать задачу создания простенького Web-форума путем написания веб интерфейса к NNTP-серверу. Я тогда сравнил это с ситуацией, когда для задачи "Доставить сейф весом 200кг на второй этаж" вместо того чтобы взяться вчетвером и поднять по лестнице предлагается "а давайте изобретем и построим антигравитатор, и тогда мы им легко этот сейф поднимем".
no subject
Date: 2007-12-14 09:18 am (UTC)Кстати, у участия в жесткой системе есть не только минусы (в смысле высоты барьера), но и плюсы. Участник расплачивается необходимостью резервировать место на диске и гонять лишний трафик - зато раздает его ограниченному количеству соседей, поэтому не только застрахован от атаки, но и может раздавать популярный контент без особых проблем с нагрузкой.
2) С очевидностью, любое техническое решение скорее всего более-менее обеспечит те цели, для которых его ввели. Ваше решение проблему архивов просто не рассматривает - и "за счет закона больших чисел" ничего не обеспечит. Соотношение стоимости дискового пространства и каналов сейчас не таково, чтобы естественным было "вечное" кэширование - следовательно, подавляющее большинство участников информацию, которую мало запрашивают, будет стирать. В некоторых случаях это даже и хорошо, а в некоторых - не очень.
3) А я что-то сложное предлагаю для обеспечения разнообразия применений? По-моему, элементарную вещь, с точки зрения архитектуры естественную - развести по разным уровням протоколы доставки контента и его интерпретации.
no subject
Date: 2007-12-14 09:25 am (UTC)Рассматривать надо не соотношение дискового пространства и каналов, а соотношение дискового пространства и возможностей участников сети по генерации и восприятию контента.
Даже если мы рассматриваем в качестве контента (статичные) фотографии, возможности пользователя по их генерации достаточно ограничены.
Задуматься о нехватке пространства могут заставить только видеоролики. Соответственно, их лучше в ближайшее время - до следующей революции в области систем хранения - не кэшировать.
Впрочем, я уверен, что в ближайшее время емкость систем хранения достигнет такого уровня, что хранение видеоряда с продолжительностью, сравнимой с продолжительностью человеческой жизни перестанет быть проблемой. А больше хранить всё равно не нужно - пользователь просмотреть не успеет.
no subject
Date: 2007-12-14 09:35 am (UTC)допустим, у меня несколько сот френдов - и виртуальный хостинг... Я очень задумаюсь над сплошным хранением их лент... Думаю, что в ближайшие два-три года в этом смысле ничего не изменится.
no subject
Date: 2007-12-14 09:41 am (UTC)Ну допустим, 30Мб на журнал на 300 френдов. Каких-то вшивых 10 гигабайт. На типичном в наше время терабайтном винте 100 таких архивов уместится. Эквивалентно 10 полнометражным фильмам по максимуму пожатым в MPEG4. Это если контент хранится несжатым. А если сжатым то вообще на 1 DVD влезет.
Виртуальные хостинги сейчас не дают столько дискового пространства, потому что спроса нет. С финансовой точки зрения им столько давно не жалко.
no subject
Date: 2007-12-14 10:43 am (UTC)Впрочем, мы ж ориентируемся не на свой стереотип поведения - а на удовлетворение достаточно типичных потребностей, нес па? ИМХО, для человека с десятком френдов все наши изыски вообще вряд ли понадобятся... его скорее всего устроит ЖЖ в нынешней инкарнации.
Вшивых 10 Гб - это выделенный сервер и почти никаких других вариантов. Не высоковат барьер?
Виртуальные хостинги не дают столько дискового пространства не потому, что спросу нет - а потому, что нет спроса на хостинг с оплатой по трафику.
Впрочем, эти рассуждения просто мало относятся к делу - если мы мыслим нашу систему как ориентированную на широкое использование в ближайшие пару лет, то мы должны принимать в расчет возможности и установки типичного интернетчика - а они таковы: арендовать виртуальный хостинг за два-пять баксов в месяц, потому что - а зачем больше? ради победы демократии в мировом масштабе? Т.е. для большинства участников вопрос о кэшировании без стирания будет решаться однозначно.
А если мы презюмируем требование иметь выделенный сервер - то ни о каких миллионах участников говорить не придется; это будут в лучшем случае тысячи - десятки тысяч.
no subject
Date: 2007-12-14 11:48 am (UTC)Я не собираюсь решать задачу MPAA-устойчивого распространения голливудских блокбастеров. Ибо чем дальше, тем больше прихожу к выводу, что контент, который настойчиво пытаются защитить копирайтом, не заслуживает распространения вообще.
Вообще, я считаю что основной хостинговой площадкой для распределенного блога должны являться домашние машины на broadband-соединениях. Уж на домашней машине 10Gb найти не проблема. Пару уже отсмотренных фильмнов на DVD скинуть и готово.
no subject
Date: 2007-12-14 05:52 pm (UTC)Ну, это довольно спорный вывод. Скажем, я храню на диске несколько гигабайт архивов электронных библиотек, при том что очевидно не успею прочитать за свою жизнь и десятой части.
no subject
Date: 2007-12-14 10:49 am (UTC)no subject
Date: 2007-12-14 11:51 am (UTC)Еще раз повторяю - лично я P2p файлообменник писать не буду. Ибо считаю что в том море контента, которое там сейчас есть, почти ничего хорошего нет. А что есть - все доступно на arjlover.net по обычному http.
Написать специализированную систему для обмена между fb2-библиотеками - это я ещё подумаю. Опять же в предположении что библиотека у юзера на домашней машине. Там траффик будет в разы меньше, чем в блогах (основной траффик - исправление опечаток), и в качестве транспорта можно существующие XMPP-сети использовать.
no subject
Date: 2007-12-14 12:27 pm (UTC)