Как раз то, что искал!

15286: By Компьютерщик REMOTE_HOST [125.rnt-63.wwwcom.ru] on Saturday, April 11, 2009 - 05:50:

Спасибо за статейку. Удачи Вам!

14861: By undertaker REMOTE_ADDR [89.218.69.170] on Friday, December 05, 2008 - 15:05:

Думаю, будет интересно узнать мнение Виктора Вагнера по поводу распределенного блоггинга:

http://www.wagner.pp.ru/~vitus/articles/dblog.html

14822: By REMOTE_ADDR [94.102.60.151] on Sunday, November 23, 2008 - 00:32:

Authentication Error

14812: By REMOTE_ADDR [94.102.60.152] on Saturday, November 22, 2008 - 18:23:

Authentication Error

14782: By REMOTE_ADDR [94.102.60.153] on Friday, November 21, 2008 - 13:14:

Authentication Error

14766: By REMOTE_ADDR [94.102.60.152] on Friday, November 21, 2008 - 00:17:

Authentication Error

14753: By REMOTE_ADDR [94.102.60.152] on Thursday, November 20, 2008 - 09:09:

Authentication Error

14719: By REMOTE_ADDR [94.102.60.152] on Monday, November 17, 2008 - 15:21:

Authentication Error

14698: By REMOTE_ADDR [94.102.60.152] on Sunday, November 16, 2008 - 15:33:

Authentication Error

14673: By REMOTE_ADDR [94.102.60.151] on Saturday, November 15, 2008 - 14:51:

Authentication Error

14616: By REMOTE_ADDR [200.63.42.136] on Sunday, October 26, 2008 - 18:06:

Authentication Error

14571: By REMOTE_ADDR [200.63.42.136] on Friday, October 24, 2008 - 09:48:

Authentication Error

14526: By REMOTE_ADDR [200.63.42.136] on Tuesday, October 21, 2008 - 10:12:

Authentication Error

14478: By REMOTE_ADDR [200.63.42.136] on Friday, October 17, 2008 - 10:29:

Authentication Error

14423: By REMOTE_ADDR [200.63.42.136] on Tuesday, October 14, 2008 - 03:02:

Authentication Error

14305: By REMOTE_ADDR [200.63.42.136] on Thursday, August 21, 2008 - 14:15:

Authentication Error

14170: By HTTP_X_FORWARDED_FOR [38.13.190.195.unknown.Steephost.net] on Thursday, June 19, 2008 - 02:11:

Authentication Error

14087: By REMOTE_HOST [78-1-155-99.adsl.net.t-com.hr] on Wednesday, May 21, 2008 - 02:32:

Authentication Error

13932: By korent,korent HTTP_X_FORWARDED_FOR [206.51.232.109] on Sunday, December 30, 2007 - 20:08:

Authentication Error

13882: By korent,korent HTTP_X_FORWARDED_FOR [206.51.232.109] on Saturday, December 29, 2007 - 16:40:

Authentication Error

13866: By korent,korent HTTP_X_FORWARDED_FOR [206.51.232.109] on Saturday, December 29, 2007 - 09:16:

Authentication Error

13851: By korent,korent HTTP_X_FORWARDED_FOR [206.51.232.109] on Saturday, December 29, 2007 - 02:27:

Authentication Error

13819: By goblin,goblin HTTP_X_FORWARDED_FOR [mail214.galacell.com] on Wednesday, November 21, 2007 - 17:02:

Authentication Error

13801: By goblin,goblin HTTP_X_FORWARDED_FOR [mail214.galacell.com] on Tuesday, November 20, 2007 - 12:05:

Authentication Error

12303: By Gjlden [82-137-4-208.rdsnet.ro] on Sunday, August 05, 2007 - 09:45:

Не совсем по теме, но я видел ссылку у Vladimir Vysotsky-ого просто добавлю, что открылся форум на русском языке на сайте, которую он напомнил

http://ru.goldengate.gg/

12084: By KellyAgesslausaZem [c-67-176-50-62.hsd1.co.comcast.net] on Wednesday, May 23, 2007 - 15:47:

Authentication Error

7303: By Utochka_lj [ce.wayxcable.com] on Tuesday, August 01, 2006 - 09:55:

Ничего не поняла, но жутко интересно. Кря! :-)

6987: By letmein [async35.dialup.etr.ru] on Tuesday, August 30, 2005 - 03:03:

А вот ещё есть такая любопытная штука -
Freenet. Как это многоуважаемый Проф. Вербитский
не слышал о ней, не понимаю !

http://freenet.sourceforge.net/index.php?page=faq

А если слышал, так надо бы упомянуть - она к делу относится, IMHO

6943: By Anton Moscal [192.168.0.225] on Wednesday, July 13, 2005 - 16:16:

Upd: Резюме - действительно принципиальных момента два:

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

2) Гаратнии того, что поиск и доступ к актуальной версии контента обеспечиваются 100% надежно при условии исправности оборудования хостинга или миррора.

Накручивать автоматическое кэширование и прочее p2p распределенность для снижения нагрузки популярных серверов можно сколько угодно, но нужно reliable ядро.

6942: By Anton Moscal [192.168.0.225] on Wednesday, July 13, 2005 - 16:11:

Misha Vebitsky:

> В суд не в суд, но возможность перехода на p2p в случае глобального облома Интернета и перехода (например) на wifi-структурированные протоколы имеет смысл предусмотреть.

Да, но у всех "классических" p2p сетей, с которыми я имел дело есть две врожденные болячки - поиск (в отсутствие центрального каталога - вроде Напстера)

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

На эти грабли наступать не хочется. То есть 100% надежный поисковик и доступность информации по ссылке.
> Важно, чтобы никому нельзя было без причины перекрыть
> кислород. Если цензуры нет, то на требования "закройте
> такого-то, он фашист/сионист/исламист/варезник/порнушник"
> ответ один - идите в суд. Если ж хостер подвергает блоги
> цензуре, судить будут его. Причем если большая часть
> хостеров прибегает к цензуре, будут судить даже
> и тех, кто не прибегает, просто не посмотрят.

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

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

А цензура на многих хостах неизбежно будет - так уж народ устроен. Даже без судов и обозной команды.

Кроме того - у большинства хостов все равно будет зависимость от провайдера.

Это, кстати, означает, что в ссылках не должен фигурировать хостинг.

А "попечительского совета" я просто боюсь - затея Крылова с Носиком - довольно типический случай. Началось "красиво", а закончилось идеей назначить Лукьяненко в главцензоры LJ. То есть - жопой. Кто
будет этим советом рулить через 5 лет - предсказать невозможно.

>Топология сети является фиксированой (точнее -
>явно прописанной в настройках).

> Это есть некий абсурд - 1000 серверов, присоединяется
> 1001, что, все остальные немедленно пойдут добавлять
> его в таблицу? Да ни в жисть. Главное - топология

Я имею в виду, что узел сам прописывает свои непосредственные связи, вместо того, чтобы "сеть сама разбиралась", как в Gnutelle.

А дальше - информация просто распространяется по тем самым связям. Собственно RIP получится, только попроще - информации меньше, опять же сами-то основные потоки информации рутить не надо - просто ссылки редиректить.

>Проблема в том, что надо не допустить одновременной
>регистрации одного nickname.

> Проблема эта отчасти дисциплинарная.
> То есть желающих зарегистрировать vasya на
> каждом сервере остановить (без централизованной
> базы данных) невозможно, а с централизованной

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

vasya/xxx.yyy.zzz

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

Проблема тут техническая - одновременная регистрация двумя узлами одного и того же ника, до того, как информация разойдется - маловероятно, но возможно.

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

Другая полумера - какое-то разрешение конфликтов - например зарегистрированный позже nick аннулируется, а пользователю предлагается его переименовать (с сохранением всего, что он успел написать) "опасный" зазор вряд ли будет превышать 2-3 часа.

Кстати - переименование пользователя - вещь полезная, так что все-таки нужен и уникальный ID. Но его-то можно формировать из ID узла (который просто "для уникальности") и номера на узле.

Можно и openID использовать или любой по выбору "коммерческий" ID - тот же mail или номер аськи. Лишь бы его как-то мог авторизовать владелец.

Надо иметь в виду, что сеть по числу узлов все-таки будет намного меньше, чем Inet. Это многие проблемы решает.

>Вероятно следует в принудительном порядке (на уровне
>софта) обязать предлагать не менее трех вариантов на выбор

> Не реалистично.
> Серьезных людей, которые это дело будут согласны
> хостить (а) надежно (б) бесплатно и (в) без цензуры
> столько не будет.

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

Надо просто для надежности. В такой системе выпадение одного узла - просто явление штатное и нужно иметь 100% страховку на этот случай - так она есть - пока висит основной узел, работает второй, а после поднятия основной просто забирает изменения - это дешево именно потому, что он знает откуда их брать.

> А за отсутствием распределенной френд-ленты
> для насущных целей NPJ непригоден вовсе
> (то есть пригоден даже в меньшей степени,

Собираются сделать - http://www.npj.ru/npjdev/checklists/release_plan

Вообще - у NPJ есть одно большое преимущество - он живой проект, а LJ на самом деле уже законсервировался. Его можно патчить, но вряд ли он будет развиваться. Хотя - он довольно бардачный в смысле организации и сложноватый сервис.

И вынь-ориентированый - я c ним поковырялся - с koi8-локалью он просто не работает (русские буквы много где захардкожены). Если есть cp1251 (не обязательно как дефолтная), он ее подхватит и использует, но все равно криво. И править плохо. Русских текстов там слишком много и они не вынесены в базу.

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

> чем LJ, в котором можно завести фид,
> дублирующий любую френд-ленту.

Фид и в NPJ завести можно. Более того - поскольку там лучше работает eMail интеграция, можно и обмен комментами наладить. Я никак не найду время, написать почтового робота, чтобы форвадить туда и обратно копии с "зеркальных" постингов в LJ.


PS: Кстати - подумалось, что комменты можно держать у автора комментов (ну и на его
зеркалах), а в ленте ставить только ссылки (и наверное -дублировать). Тогда легко можно реализовать механизм удаления/правки. И проблема поиска всех комментов данного автора решается тривиально.

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

6939: By Vladimir Vysotsky [netblock-66-159-221-206.dslextreme.com] on Monday, July 11, 2005 - 05:56:

На всякий случай повторю здесь два аргумента, посланные лично Антону М. насчет http://oops.tepkom.ru/~msk/blogs.html:

> Соотвественно - предлагается структура с ручным конфигурированием
> связей между узлами и явным выбором авторам дневников узлов-зеркал.
> Поскольку, размер сети даже в 1000 узлов предполагает (самое меньшее)
> несколько десятков тысяч пользователей, сеть останется управляемой.

По-моему, слишком мелко, даже как замену ЛЖ. Если уж разрабатывать что-то, так способное поднять 10^9 читателей, 10^7 активных писателей,
10^5 "супер-узлов", реально хранящих большую часть информации. Ручное конфигурирование в таких масштабах, понятно, не имеет смысла.

> UserID и прочая Узлы идентифицируются уникальными nodeid,
> пользователи - уникальными userid, с которыми связаны nicknames.
> Может быть следует nickname и сделать userid.

[...]
> Сложнее с nickname. Проблема в том, что надо не допустить
> одновременной регистрации одного nickname.

Очень сложно и не нужно. Есть более простой альтернативный вариант. У пользователя есть уникальный идентификатор - например, public key - который он сам себе делает и который никто другой использовать с целью фальсификации в принципе не может. Идентификатор остается с пользователем, пока тот его использует, вне зависимости от миграции между узлами и т.п.

[[[Вербицкий написал:

> юдям придется ставить у себя софт
> для создания подписи. Этого многие не могут
> сделать

Согласен. Поэтому те, кто может, будут создавать свой ID у себя на машине, те, кто не могут - на frontend-сервере.
]]]


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

6938: By Vladimir Vysotsky [netblock-66-159-221-206.dslextreme.com] on Monday, July 11, 2005 - 05:47:

>Устраняется. Узел-бэкенд при посредстве
>API осуществляет автоматическое копирование
>(например, ежедневное) всех материалов
>на несколько других trusted-узлов, и в случае
>смерти этого узла, те вывешивают этот же контент
>в другом месте.

Во-первых, это предполагает наличие доверия между узлами, а также необходимость такое доверие настраивать. В этом слабое место подхода backend/frontend - подмножества узлов с транзитивным доверием достаточно малы, чтобы их можно было эффективно преследовать и закрывать. В моем варианте, если пользоваться такой-же терминологией, каждый узел доверяет каждому.

> А где в том, что я написал, выделенные сервера?

Backend-сервера являются выделенными с точки зрения хранения контента.

>А устраивать очередную приблуду для сальных
>и пахнущих пивом компьютерных педерастов (типа
>Фидо) не нужно, эта идея себя не оправдала.

Я думал, при обсуждении технических вопросов подобная риторика неуместна. И вообще, при чем здесь Фидо?

> Разница чрезвычайно существенная - комментарии
> никто не читает

Так и я о том же. Прагматическая разница есть, технической нет.

> Поэтому кэшировать для общего пользования
> их совершенно бессмысленно.

Кроме тех случаев, когда они представляют самостоятельный интерес.

6937: By Misha Verbitsky (Admin) [localhost] on Sunday, July 10, 2005 - 14:06:

Petya Kohts:
>Что мне непонятно из технической записки:
>как в вышеописанной ситуации будут продолжать
>вести свои блоги юзер1, ..., юзер2012 с бывшего
>сервера1.

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

Такие дела
Миша

http://www.vivatrossija.narod.ru/
ТВОРЧЕСТВО АФАНАСИЯ О РОССИИ И ИГОРЕ ТАЛЬКОВЕ

Убили Талькова, России певца
Убийцы никто не заметил лица
Жевали все импортный свой бубльгум
Отчизну продали - коммерции бум!

А он про страну со слезами кричал
Про то что Чубайс у нас свет отобрал
И что дерьмократы засели в Кремле
Их совесть купили давно в СКВ!

Вставай же россия, покайся, окстись!
Талькову-герою ты вновь поклонись
И горькой утраты стирая слезу
Ему на могилу положь ты розу...

6936: By Misha Verbitsky (Admin) [localhost] on Sunday, July 10, 2005 - 13:59:

Yuriy Shirokov:

>Если мы будем разрабатывать протокол взаимодействия узлов
>на базе, скажем, SOAP

Я почитал их описание
http://www.w3.org/TR/soap12-part1/
это ужас, летящий на крыльях ночи
(как и все, что публикуется w3.org, по-моему).
Ополоумевшие бюрократы, которым нечем другим
заняться, кроме как ебать людям мозги и втюхивать
говно. Убивать сразу. RPC это вообще большое зло.

>Это архитектурная особенность (механизм "уровней доверия"
>не позволяет полноценно заменить 50 крупных серверов на
>5000 мелких)

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

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

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

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

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

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

>Во-вторых, возможна фальсификация кэшированных на
> промежуточных узлах записей.

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

>должна строить аутентификацию на основе PGP или другого
>подобного алгоритма: каждое сообщение будет снабжено
>цифровой подписью, которую может проверить любой, имеющий
>открытый ключ автора.

Да, это обязательно надо сделать. Но фальсификации
это не помешает - например, убиранию записей.

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

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

Такие дела
Миша

http://www.zomby-x.com/chi.htm
Система Тотального Подчинения Женщины

6935: By Misha Verbitsky (Admin) [localhost] on Sunday, July 10, 2005 - 13:05:

Vladimir Vysotsky
[netblock-66-159-221-206.dslextreme.com]

>Зачем вообще делать распределенную систему, если не
>устраняется проблема потери данных или хотя бы возни по
>переходу на другой сервер, когда узел покупают, или за
>хозяином узла приходит homeland security/госбесопасность?

Устраняется. Узел-бэкенд при посредстве
API осуществляет автоматическое копирование
(например, ежедневное) всех материалов
на несколько других trusted-узлов, и в случае
смерти этого узла, те вывешивают этот же контент
в другом месте.

>Нет, базовой должна быть модель peer-to-peer сети без
>выделенных серверов.

А где в том, что я написал, выделенные сервера?

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

А устраивать очередную приблуду для сальных
и пахнущих пивом компьютерных педерастов (типа
Фидо) не нужно, эта идея себя не оправдала.

>И кстати, разница между записями и комментариями - отнюдь
>не техническая, скорее прагматическая, и то довольно
>размытая.

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

Такие дела
Миша

http://www.goldengate.hu/szex/napihard/
Szex - napi hardcore and leszbi - Osszes sorozat

6934: By Misha Verbitsky (Admin) [localhost] on Sunday, July 10, 2005 - 12:55:

Антон:
http://oops.tepkom.ru/~msk/blogs.html

> 1. Возможность распределенности в стиле нынешних
> P2P-сетей для блог-системы ни на фиг не сдалась -
> вряд ли кто-то тут будет всех в суд таскать

В суд не в суд, но возможность перехода на p2p в случае
глобального облома Интернета и перехода (например) на
wifi-структурированные протоколы имеет смысл предусмотреть.

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

Важно, чтобы никому нельзя было без причины перекрыть
кислород. Если цензуры нет, то на требования "закройте
такого-то, он фашист/сионист/исламист/варезник/порнушник"
ответ один - идите в суд. Если ж хостер подвергает блоги
цензуре, судить будут его. Причем если большая часть
хостеров прибегает к цензуре, будут судить даже
и тех, кто не прибегает, просто не посмотрят.

>Топология сети является фиксированой (точнее -
>явно прописанной в настройках).

Это есть некий абсурд - 1000 серверов, присоединяется
1001, что, все остальные немедленно пойдут добавлять
его в таблицу? Да ни в жисть. Главное - топология
самой сети (Интернета) меняется каждые 15 минут,
в этой ситуации топология сети блог-хостинга
не может оставаться постоянной. Я думаю,
использования алгоритма, подобного
RIP, не избежать по-любому.

>Проблема в том, что надо не допустить одновременной
>регистрации одного nickname.

Проблема эта отчасти дисциплинарная.
То есть желающих зарегистрировать vasya на
каждом сервере остановить (без централизованной
базы данных) невозможно, а с централизованной
базой мы лишаемся какой-либо распределенности.
И не нужно их останавливать. Надо бороться
только со злокачественными регистраторами
(identity theft). DNS создает Интернету
масу проблем (постоянные процессы о трэйдмарках,
централизованность, невозможность анонимности).

>Вероятно следует в принудительном порядке (на уровне
>софта) обязать предлагать не менее трех вариантов на выбор

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

>NPJ - интересный софт, к тому же некоторая
>распределенность заложена в нем by design,

Ему нужно, к сожалению, PHP. За счет этого машина
не очень производительна и не поддается scaling-у.
А за отсутствием распределенной френд-ленты
для насущных целей NPJ непригоден вовсе
(то есть пригоден даже в меньшей степени,
чем LJ, в котором можно завести фид,
дублирующий любую френд-ленту.

Такие дела
Миша

http://answering-christianity.com/x_rated.htm
X-Rated Pornography in the Bible

6928: By kouzdra [ts12-a12.Spb.dial.rol.ru] on Thursday, July 07, 2005 - 13:03:

Таки собрался чуть-чуть причесал свою писанину по поводу и выложил - http://oops.tepkom.ru/~msk/blogs.html

Anton Moscal

6927: By Vladimir Vysotsky [netblock-66-159-221-206.dslextreme.com] on Thursday, July 07, 2005 - 11:33:

(попал сюда с russ.ru/20050706_verbit)

Идея строить распределенный блог на базе backend узлов с приписанными пользователями порочна. Зачем вообще делать распределенную систему, если не устраняется проблема потери данных или хотя бы возни по переходу на другой сервер, когда узел покупают, или за хозяином узла приходит homeland security/госбесопасность?

Нет, базовой должна быть модель peer-to-peer сети без выделенных серверов. Существующие алгоритмы DHT уже позволяют реализовать большинство необходимых функций (хранение записей, ссылок между ними, поиск по ссылкам), сохраняя при этом полную взаимозаменяемость элементов сети.

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

И кстати, разница между записями и комментариями - отнюдь не техническая, скорее прагматическая, и то довольно размытая. И то, и то - кусочек текста с картинками, просто комментарий обязательно на что-то ссылается, а запись - не обязательно. Как следствие отсюда, кто угодно может комментировать что угодно. А предотвращение спама - личная ответственность читателя (с настройками типа "от анонимов тексты не брать"). Другими словами, pull ("что заказал, то и читаю"), в отличие от push ("читаю, что прислали").

Front-ends для поддержки веб-интерфейса, RSS и прочего - хорошая идея, там можно и пользователей регистрировать и настройки хранить, но при этом должна оставаться возможность делать все это в индивидуальном порядке.

6923: By Yuriy Shirokov [ppp83-237-16-250.pppoe.mtu-net.ru] on Monday, July 04, 2005 - 15:18:

Читал спецификации разных протоколов обмена данными и описания библиотек, их реализующих, под разные языки, "много думал"(с). Беру свои слова про Апач обратно. Если мы будем разрабатывать протокол взаимодействия узлов на базе, скажем, SOAP (что ИМХО разумно), реализовать узел как модуль к Апачу будет, кажется, логично и удобно.

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

Ещё мне не очень нравится, что система чувствительна к исчезновению из сети сразу нескольких крупных серверов. Т.е. защищена против самодурства владельцев отдельного узла, но не от масштабной акции со стороны, скажем, государства. А такие акции возможны, не по политическим причинам, так из-за "копирайта" или "child porn". Это архитектурная особенность (механизм "уровней доверия" не позволяет полноценно заменить 50 крупных серверов на 5000 мелких), и она чревата потерей контента в некоторых экстремальных ситуациях. Другое дело, что альтернатива этому --- то самое шифрование защищённых записей, имеющее свои недостатки.

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

6922: By Yuriy Shirokov [ppp83-237-16-190.pppoe.mtu-net.ru] on Monday, July 04, 2005 - 03:07:

Ещё пара замечаний.

А зачем реализовывать узел-backend в виде модуля к Апачу, когда в нём не планируется никакой функциональности, связанной с HTTP? Написать отдельный сервер будет гораздо разумнее.

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

6921: By Yuriy Shirokov [ppp83-237-16-190.pppoe.mtu-net.ru] on Monday, July 04, 2005 - 02:18:

Видимо, системы аутентификации, аналогичной фицпатриковскому OpenID (и её аналогу в НПЖ) для _действительно_ распределённой системы недостаточно. Во-первых, если сервер перестаёт существовать, перестаёт существовать и аккаунт пользователя. Во-вторых, возможна фальсификация кэшированных на промежуточных узлах записей.

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

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

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

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

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

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

6920: By Petya Kohts [ppp83-237-209-144.pppoe.mtu-net.ru] on Sunday, July 03, 2005 - 12:55:

Представим следующую ситуацию.

Некто (юзер1) пишет у себя в блоге на своем
домашнем сервере (сервер1) "Убей НАТО".
Юзера1 поддерживают юзер2@сервер1,
юзер3@сервер1, ..., юзер2012@сервер1,
которые тоже публикуют у себя запись "Убей НАТО".

Каким-то образом заинтересованные лица нейтрализуют сервер1
(заслав бойцов, нажаловавшись провайдеру и т.д.). Сервер1 недоступен.

Допустим, что нейтрализация произошла спустя
некоторое время после публикации "Убей НАТО",
достаточного для распространения записей на один
из кэширующих серверов -- сервер2.

То есть, записи пользователей с нейтрализованного
сервера1 во френдленте юзера3000@сервере2 не
пропали.

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

6914: By Misha Verbitsky (Admin) [localhost] on Thursday, June 30, 2005 - 12:17:

>najti (naprimer sgruzit') vse kommentarii dannogo
>pol'zovatelya (po vsem dnevnikam)

Да, подобный запрос (к данному узлу) можно задать в API,
конечно ("сообщить число комментов, оставленных заданным ID"
"показать i-й коммент, оставленный заданным ID"). В базе
данных LJ второй запрос не реализуется, ибо она
чересчур плоская.

>Ty khochesh' syuda pisat' konkretnye melkie zadachi

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

Такие дела
Миша

http://www.buddhistpilgrim.info/pages/about/about_07.htm
История происхождения водки и наставление, разъясняющее ее
пользу и вред, изложенные наставником Падма-Самбхавой

6912: By D. Kaledin [094.dialup.orc.ru] on Thursday, June 30, 2005 - 05:35:

Odna melkaya veshch', kotoruyu LJ ne delaet, a mozhet byt' zrya: najti (naprimer sgruzit') vse kommentarii dannogo pol'zovatelya (po vsem dnevnikam).

Ty khochesh' syuda pisat' konkretnye melkie zadachi, tipa sinkhronizacii na letu LJ/NPJ i LJ-skina dlya NPJ? ili ehto neosmyslenno?

6911: By Misha Verbitsky (Admin) [localhost] on Wednesday, June 29, 2005 - 16:54:

Об устройстве блог-сервера (техническая записка)
http://imperium.lenin.ru/LENIN/33/NPJ-LJ/RFC.html

Жду комментариев.

Такие дела
Миша

http://genitalij.there.ru/anti/
приобретай прибор АНТИАХТУНГ