Заповедник

На сайте http://bechtold.biz была 21 февраля 2012 г. опубликована статья:



Я написал
Получил по e-mail


По существу ответа могу пояснить следующее:

1. О синхронизации времени - подразумевается, что клиент синхронизируется с сервером точного времени автоматически (вне зависимости от показаний системных часов и действий пользователя). Небольшая разница в секунду-две некритична для форума. А для того, чтобы не возникало коллизий по "одновременной" отправке, можно добавлять к "штампу даты" ГОД-МЕСЯЦ-ДЕНЬ-ЧЧ-ММ-СС ещё несколько случайных цифр в качестве стотысячных долей секунды, например: 2012-10-12-12-05-35-12345. Эта же строка, кстати, может быть и уникальным идентификатором сообщения. Мало стотысячных, давайте добавим стомиллионную долю. Пусть будет 2012-10-12-12-05-35-123456789.

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

3. Относительно "дырок, мест с пустыми сообщениями" - не надо. Достаточно уведомлять пользователя "В тему поступили новые сообщения" и предоставлять ему выбор - "Показать только новые посты" и "Показать (перерисовать, перезагрузить) тему с выделением новых постов".

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

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

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

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

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

Пока всё.



P.S. Внутри "Заповедника" есть еще одна тема по обсуждению проблематики распределенного форума: topic120.html

Форумы Xpoint на ту же тему: http://xpoint.ru/forums/thread/45272.xhtml#395704

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

1. О синхронизации времени - еще раз повторюсь. Если все участники "честные", то такой проблемы нет. Действительно достаточно примерного времени.
Синхронизироваться даже не обязательно с каким-то специальным сервером. Это может быть один из клиентов. Например первый из темы, или просто вычислать соотвествие id клиента и текущей даты (грубо говоря найти ближайший хеш id к хешу даты) и использовать каждый день нового клиента как ведущего.
Но проблема остается, если один из участников захочет отправлять свои сообщения "раньше" других. То есть будет выставлять произвольное время для сообщений. Тут никакой сервер синхронизации по времени не поможет. Нужна нумерация, либо "ответ" на сообщение, то есть делать внутреннюю структуру в виде дерева, чтобы всегда был указатель на сообщение, которое было раньше.

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

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

4. о "вообще должно быть по кругу" ... Во-первых, здесь не нужно "обходить всех" нужно только тех, кто участвует (в т.ч. читает) в конкретной теме
В данном случае речь идет о теме. Все сообщения во всей системе у всех пользователей - будет слишком затратно как только количество участников превысит 50-100 человек.

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

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

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

У меня та же беда
Но написать хорошее ТЗ - считай, полдела.

Еще я смотрю внимательно на смежные, похожие вещи - I2P, TOR, Freenet...

И еще, есть подозрение: нельзя ли уже существующие технологии просто пересобрать по другому, прикрутить, например, phpBB к какому-нибудь облачному хранилищу?

И нужно искать единомышленников.

Про облачное хранилище вот здесь еще вопрос закинул:



P.S. Ваш пост от 21-10-2012, 10:11:22 чуть позже почитаю.

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

Это я не понял.

Конкретизирую: Вы видите проблему в том, что участник (злонамеренно или по недосмотру) некорректно выставил системное время на своем компе?
Или Вы имеете в виду такого злоумышленника, который вмешивается в сам код программы-клиента, и генерит вчерашние "штампы времени" во все свои сообщения?

Да? Я мыслил программу именно как клиента, как некий отдельный браузер по типу "всё в одном".
А Вы считаете, что должна быть некая программная реализация только самого протокола обмена, которым, скажем хоть Opera, хоть Chrome могут пользоваться?

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

Skype, например, весьма строго следжит за своей целостностью. И отрубается, если что не так. Вот кое-что об этом.

С этим согласен.

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

Значит, интерфейс важен не менее программной реализации. Выглядеть (по крайней мере, с первого взгляда) он должен как "обычный" форум. Или как можно ближе к тому.

Да, конечно.

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

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

Не обязательно. Пусть даже участников "много", но они разделены во времени. Рассмотрим такую ситуацию: допустим, во вторник у нас была целостная тема с 100 участников и все успели обменяться всеми постами со всеми участниками. Тогда здесь всё ОК. Однако в среду общение продолжили 70 "вторничных" и пришло еще 40 "средничков". Всё снова обменялись всем со всеми, и, как будто бы, тоже всё ОК. Но в четверг! В тему пришли только 30 тех вторничных, которых не было в среду, и продолжили постить как ни в чем не бывало, ничего не зная о постах в среду ни 70 "вторничных", ни 40 "средничков". В пятницу никого из 30 снова нет - и так две версии одной темы никогда не совместятся.

Да. Как в торрентах. У пира X есть торрент-ссылка, у сида Y есть файл, но они ничего не знают друг о друге, пока к X не подключится Z, у которого недавно был обмен с Y. Для торрентов это работает и без трекер-сервера, через DHT. Просто дольше сидишь и ждешь, пока наберется достаточное количество сидов.

Но будет ли подобная схема работать для форума?

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

вычислать соотвествие id клиента и текущей даты (грубо говоря найти ближайший хеш id к хешу даты)

Это я не понял.

Чтобы определить кого из участников считать сервером точного времени. Если это нужно будет.
Чтобы не вешать всегда на одного, надо выбирать каждый раз разного. Выбирать можно разными способами. Быстро приходит в голову идея похожая на DHT. Там идет поиск по "ближайшим" участникам. Ближайший определяется через хэш его id и хэш файла или слова (при поиске в слов в Kademlia). А тут клиент знает сегодняшнюю дату, и выбирает источник времени чтобы хэш текущей даты (число, месяц, год) был максимально близок хэшу одного из участников. Каждый день это будут разные участники, то есть от кого-то одного зависеть не будет.
Однако тут есть проблема разных часовых поясов (для разных людей будет "главным" свой сервер времени). Но и тут можно исходить из времени GMT. Считая мировое время имея значение часового пояса.
Хотя, я все-таки думаю, что метка времени не должна быть определяющей в сортировке сообщений. Она только как факт отправки должна использоваться.

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


Да? Я мыслил программу именно как клиента, как некий отдельный браузер по типу "всё в одном".
А Вы считаете, что должна быть некая программная реализация только самого протокола обмена, которым, скажем хоть Opera, хоть Chrome могут пользоваться?
В идеале, каждый заинтересованный человек должен иметь возможность сделать своего клиента, который будет ему удобен. То есть должен быть известный протокол, который надо использовать. Есть даже возможность использовать два протокола. Что-то простое http/json-образное для использования в браузерах (на javascript, скоро будут websocket и браузеры смогут связываться друг с другом), и чуть более компактное для всех остальных, bencode+gzip например (оно будет удобнее при считывании пачками сообщений, когда сразу пара тысяч сообщений упакуется в пару килобайт).

сама идея распределенного форума, "торрент-форума" сильно интересует.
Такие штуки есть уже. Но они слишком тяжелые. Нужно долго разбираться, работает все не очень быстро. А вообще, касаемо слова "торрент". Есть идея делать так же как с торрентами. Но нужен "растущий" торрент. То есть взять блок какого-то размер (16КБ кажется минимальный у торрента), и просто делать запросы как в торрентах, указывая другим участникам битовую строку с имеющимися кусками. Можно договорится о количестве сообщений с блоке. Например 0x10000 сообщений и блоков максимум 0x10000, в результате тема закроется на ~4 млрд. сообщений. Но тут уже блоки будут разного размера в байтах, хотя сообщения будет 65536 (или меньше, как удобней). Но я не придумал внятной идеи, как увеличивать "размер" торрента, то есть когда увеличить количество блоков и как оповещать об этом всех участников (хотя это не сложно, просто отдавать всегда вместе с запрошенным куском, какую-то служебную информацию). Но эта реализация будет иметь проблему "опрос всех подряд", будет постоянный поиск новых сообщений. А я думаю, что новые сообщения должны приходить без запроса. Должна быть какая-то волна, которая разносится от клиента создавшего сообщение. Причем можно практически любое число изначальных получателей сделать. И плясать от хэша: отдавать сообщения "ближайшим" по хэшу клиентам. Те отдадут своим ближайшим, и так далее. Но отдача должна быть в обе стороны (больше своего хэша и меньше своего хэша), хотя можно контролировать от кого пришло и ему не отправлять, но это как бы дополнительный контроль, отправитель может узнать, что его сообщение не было получено, если не увидит этого же сообщения. Но тут уже надо моделировать, как это вообще работать будет.

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

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

Как будет реализовываться система модерирования? Как пользователи будут получать доступ в тот или иной раздел? "Все имеют доступ везде"
Самый просто вариант, который решает почти все-все проблемы - создание темы(топика) без привязки к каким-либо разделам. У темы есть ID. Пока человека не позвали в обсуждение, он, вроде как, и не знает, что такая тема есть. Однако, клиент будет получать запросы на поиск темы по неизвестным ему ID, и можно так изменить клиента (сделать своего), чтобы эти неизвестные ID отображались в отдельном списке. Получается, что против недобросовестного человека должна быть защита. Тут множество идей с паролями и цифровыми подписями.
Пока у вас нет специального пароля ваши сообщения, например, не будут передаваться другими участниками, то есть не будут встраиваться в обсуждение. Модерация может "отменять" выдачу подписей. Но я против модерации силами одного человека. Хотя, в данной системе, удалять сообщения не получается, придется делать команды "отмены" сообщений, то есть для всех желающих можно будет видеть как работает модератор, что он исправляет и удаляет. Однако, как мне кажется, каждый должен сам модерировать все что он читает. Если вам не нравится как кто-то пишет ставите ему "не показывать сообщения этого участника", и они у вас просто пропадут с экрана. Можно даже посылать служебное сообщения "участник123 отметил не показывать сообщения участника555". И любой желающий сразу может видеть у кого есть много отрицательных значений, и даже настроить клиента, чтобы автоматически отключать таких участников после какого-то количества минусов.
Я думаю, что надо делать разные типы топиков: закрытые - только по приглашению, открытые для чтения - запись по приглашению, полностью открытые, зашифрованные, и т.п. Можно делать приглашения только от автора или от любого участника. Там нафантазировать можно очень много. Это не самая сложная часть.

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

Но будет ли подобная схема работать для форума?
Нужно замоделировать такие условия. И посмотреть, что получится. Я думаю, что чем дальше, тем больше времени копьютер/телефон подключены к интернету все больше.

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

Кстати, рекомендую попробовать Cscape, конечно, если он еще жив. Не знаю как оно работает, но это мессенджер без сервера. ID там выдаются автоматически, по самому большому текущему номеру. Работает тоже не очень быстро (на фоне icq и т.п.), но и не смертельно медленно. Однако там совершенно точно нет форумов, только два человека.

Да, но методы противодействия могут быть разными.

В случае простой ошибки мы можем опираться на некое "Время Распределенного Форума". Клиент в принципе не должен подключаться к сети, пока время на его компе не будет (с точностью порядка 30 секунд, например) совпадать с "ВРФ". Если пользователь ошибся, ВРФ его просто поправит.

Как организовать ВРФ? Ну, первое что приходит в голову, принцип: кто уже в сети, у того время и правильное. Вновь подключившийся получает информацию о разнице его текущего времени и времени форума. Этот разница автоматически вносится в "штамп времени" во все его сообщения (или программа-клиент автоматом правит системное время). Еще можно периодически "усреднять" время всех подключенных к сети. Поясное время, думаю, не проблема, оно же отображается где-то в реестре ОС, его надо просто учесть, привести к GMT.

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

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


Именно!


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


Вот именно! Принцип распределенности должен быть абсолютным!


Что конкретно Вы имеете в виду?
Tor? Freenet? I2P? Tahoe-LAFS?
Кстати, о Tahoe-LAFS. Полностью распределенная файловая система. Пробовали? У меня почему-то не устанавливается.


Ну, да, я отсюда же танцевал. Чистый P2P.


И не надо.
Имхо, возможность удалять – лишняя для любого форума. Ну и с правкой ранее отправленных сообшений я бы тем более не заморачивался. Сначала думайте, потом пишите – вот и всё. Еще возможность произвольно закрывать для обсуждения тему кажется мне совершенно лишней. Если только она специально не создана как "объявление".


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


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


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


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


Я тоже только к этому пришел.

И еще тогда нужно закладывать какой-то механизм "восстановления последовательностей" на случай "разрыва непрерывности". Форум должен прекратить работу на отправку новых сообщений до того момента пока 90% (условно) пользователей не синхронизируются полностью. Остальных придется встречать сообщением "У-упс! Мы Вас немножко потеряли " Остается надеяться, что эти непрятности будут происходить только на первом этапе, пока подключенных пользователей "мало".


Первый раз слышу. Где взять?

=============================
P.S. Надо остальным буду думать.

Не понял, почему не пройдет. Как выглядит "Клиент в принципе не должен подключаться к сети, пока время на его компе не будет (с точностью порядка 30 секунд, например) совпадать с "ВРФ" ?
Чтобы узнать, что время не совпадает, сначала нужно подключится.
Вы, наверное, говорите о том, что если время слишком отличается, то никто из участников не должен принимать такие сообщения и передавать дальше.
Но есть сложность в том, что человек мог написать сообщение вчера, но как раз связь прервалась, и сообщение не успело уйти. Или может быть еще хуже. Он получил большой кусок данных от другого участника (от "вторничного") и должен передать сегодня (уже "четверг") всем остальным.
По предложенной схеме такие сообщения не будут приниматься остальными.


А где гарантия, что второй участник не пособник? А может сам злоумышленник. Или вообще первый во всем прав, а второй дает ему другое время? Почему у второго время будет правильным, как это доказать первому?


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



Freenet я устанавливал, но не пошло. Что-то с ним не то.
Есть интересный чат в streamerp2p. Я не знаю по какому принципу он работает, но вроде бы не через сервер. Правда там очень просто, никаких хранений сообщений и шифрования, то есть задача намного более простая. Но если там действительно распределенная система, значит придумали как пересылать сообщения между участниками.
Еще чаты есть в emule. Там обычный IRC плюс какой-то свой вариант, не знаю как он работает, но визуально вроде бы как медленнее, чем в streamerp2p. Хотя проверять скорость я не мог, визуально приглядывался.

Tahoe-LAFS - не знаю, что такое. Надо посмотреть.



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


Я вижу две крайние ситуации:
1. банит-разбанивает всех подряд без разбору, и противодействовать никак нельзя (уйти всем одноврменно из старой интересной темы не хочется
2. спамеры одолевают, что-то надо делать - каждый сам отключает спамера, но постоянно появляется новый, это решается с помощью приглашений. Но тогда надо делать отзыв приглашений, чтобы один притащивший спамера (случайно или специально) больше бы не мог этого сделать. Отбирать приглашения может только давших его. Но тут проблема, что кто-то не захочет этого делать, тогда мы даем полномочия автору темы (а больше пока некому) и он снова начинает банить всех без разбору. Опять получается, автор всеми руководит.
Есть еще вариант "выборов" - участники не только отключают кого-то, но ставят плюсы. По достижению какого-либо количества плюсов (51% от количества участников, например), он может начать раздавать баны. При нужде, плюсы отзываются (когде человек стал неадекватен). Но тут снова риск, кто-то может подключить по цепочке множество участников, и проголосовать за себя. Либо наоборот, при большом количестве "спамеров" и постоянном появлении новых, потенциальный модератор не наберет нужного количества голосов (если они будут считаться как проценты от количества участников).



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


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



1. как такое реализовать?
2. все разошлись и мы вдвоем больше не можем писать в этой теме?
3. а зачем это нужно?


Опечатка. Cspace. Много где есть. http://code.google.com/p/cspace/

Предлагаю часть вопросов вынести в отдельные ветки:

Распределенный форум: модерация и самоуправление

Распределенный форум: структура тем и сообщений

Стало вдвое неудобнее.

Хех. Кому "стало неудобнее"?

Однако, налицо конфликт.
Что делать?

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

Имелось в виду поэтапное соединение.
1. Первый запрос типа: "Меня слышат на сокете ".... : ...."?
2. Если ОК, то второй запрос – запрос на синхронизацию времени.
3. Повторяем пункт 2 случайным образом несколько раз (скажем, 10) с разными клиентами.
4. Если время - ОК, работаем дальше на прием-отправку сообщений, если нет – нет.
5. Дополнительно проверяем совпадение времени в заголовке каждого "нового" сообщения.
Ну, извини, человек! Не повезло тебе, значит Дождись подтверждения о принятии твоего сообщения сетью.
Нет-нет! Здесь я не имел виду, что проверяется время каждого сообщения. Синхронизируется именно "ВРФ" – свои собственные часы каждой программы-клиента. Если у тебя правильное "ВРФ", то от тебя принимаются все куски данных. Предполагается, что и во вторник ты получил их "правильно", поскольку и во вторник ты их бы не получил, если у тебя не совпадало "ВРФ".

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

Допустим, изначально к сети подключены 150 добросовестных клиентов с синхронизированным временем "14.00". Каким образом к ним подключится шестой хакер со своим временем "13.00"?
Ему нужно будет:

а) запустить, как, минимум, еще 10 клонов на разных IP со "своим" временем "13.00".
б) запретить в протоколе запросы к "неклонам".

Но в этом случае он сможет отправлять свои сообщения только своим клонам! 150 добросовестных клиентов не будут принимать его сообщения. Фактически он создаст несвязанный с остальными сектор распределенного форума.

Значит, далее ему нужно будет

в) после обмена сообщениями между клонами поменять свое время на "правильное".

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

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

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

Тогда, идеальная схема (в общих чертах) должна быть такая, что только ДРУГИЕ пользователи знают пароль на расшифровку храняшейся у тебя базы.
Причем каждый ДРУГОЙ знает пароль только того куска, который им же и зашифрован.
А сам ты можешь видеть свои собственные посты только через подключение к ДРУГИМ.

Хм... Надо прорисовать это дело, что ли...



Вот как-то что-то подобное делают в Tor ("луковое" шифрование) и в I2P ("чесночное" шифрование). Там промежуточный узел может расшифровать только адрес, куда перенаправить полученный пакет данных, но не содержание пакета данных. I2P вообще исходит из того, что скомпрометированы ВСЕ промежуточные узлы.

и сразу напоминаю

Если никого не осталось, то это 100%. Тогда очевидно, что передача сообщений просто будет невозможно и никаких дополнительных мер принимать не нужно (и не получится).



Допустим придет десять разных вариантов времени, какой правильный?


Как узнать, что "время - ОК"? И что делать, если у клиента "время - не ОК", он вообще не сможет отправлять сообщения?


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


К1
К2
К3
К4 ----- инициатор сообщения. отправитель. отправляет К3 и К5.
К5
К6

шаги
1) К4 отправляет К3 и К5.
2) К3 отправляет К2 и К4 (К4 убедился, что сообщение ушло правильно) / К5 отправляет К4 и К6 (К4 убедился, что сообщение ушло правильно)
3) К2 отправляет К3 и К1 (К3 убедился, что сообщение ушло правильно) / К6 отправляет К5 и К1 (К5 убедился, что сообщение ушло правильно, сообщение прошло по кругу и К1 уже никому не отправляет, он получил два одинаковых сообщения с "двух сторон" - от К2 и от К6)
4) К1 получил два сообщения, причем ни разу не отправлял подобное. Проблема в том, как ему дождаться второго сообщения, чтобы больше не отправлять.

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



Как они узнают, что у 10 клонов неправильное время, а у остальных правильное?



Все равно туда вписать ничего не получится. 1. Все сообщения должны иметь цифровую подпись и подделать ее будет затруднительно. 2. Все сообщения должны нумероваться. не меткой времени, а обычным счетчиком, и нельзя будет вставить сообщение 10,5 между 10 и 11.


Он тогда прочитать их не сможет.


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



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

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

Вот смотрите, допустим, первые участники РФ (далее и везде – Распределенный Форум) – Вы и я.
Наше с Вами время мы синхронизируем какой-нибудь договоренностью вне РФ. По серверам точного времени, например, не суть.
Третий подключающийся участник либо принимает наше время (время РФ - ВРФ) и подключается, или не принимает – и не подключается.
Подключившись, он становится таким же "хранителем времени" , как Вы или я. Теперь я могу отключиться, сломать часы, переехать в другой часовой пояс – не важно.
Важно, что для подключения в следующий раз, мне нужно будет либо принять ВРФ, которое храните теперь Вы и третий, либо РФ не примет меня.

Не сможет.

Они (150 участников) знают про идентичность времени у всех 150. Иначе они не соединились бы в сеть.
Сеть 10 клонов не столько "неправильная", сколько просто сеть с другим временем, отдельный сектор сети, не пересекающийся с основной сетью.


Насколько я понял, Вам не удалось решить вопросы:

а) как синхронизировать общий счетчик?
б) как разрешаются коллизии разных индивидуальных счетчиков?

Или удалось?

Мое предложение ввести ВРФ (время распределенного форума), де факто, было предложением такого "общего счетчика", который синхронизирован всегда, по умолчанию.
И одновременно общий счетчик играет роль индивидуального счетчика.

Все сообщения, которые получает клиент, он просто расставляет в теме по времени. Коллизий нет.



Пример – это очень хорошо!
Кольцо – понятно.
Однако непонятно, что заставит сообщения двигаться именно по такому кольцу?
Возможно существование двух раздельных колец:

К3
К4
К5

и

К6
К1
К2

Тогда К4 отправит по сообщению в адрес К3 и К5, получит от них подтверждения, К3 и К5 отправят сообщения друг другу и всё закончится внутри треугольника К3-К4-К5.
Треугольник К6-К2-К1 ничего не будет знать о постах в треугольнике К3-К4-К5 и наоборот.



Разумеется.
И тут мы возвращаемся к проблеме нестыковки "вторничных" и "четверговых".

В случае разрыва сети – как синхронизировать "вторничных" и "четверговых"?

Ну, да. Без подключения к сети ничего прочитать нельзя.
Это ж распределенный форум, чего Вы хотите?

Мы исходили из того, что у каждого участника темы хранится вся тема.

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

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

А если активен только один участник? Он не сможет писать? А если сейчас только двое(трое) в сети, то как быть? Ждать когда будет десять? Или какой-то процент от подключенных?


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


Мы пришли к тому, что все должны быть соединены со всеми. Сеть стремительно валится. Никто не сможет даже однократно при подключении опрашивать всех подряд участников (а если вы в десяти темах, и в каждой по сто человек, и всех надо опросить относительно времени).




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


Индивидуальные счетчики на то и индивидуальные, что они не взаимодействуют друг с другом. Они нужны, чтобы правильно выстроить сообщения от конкретного участника, чтобы знать, что у вас не все сообщения от него, и в случае чего начать опрашивать кого-либо относительно этих недостающих сообщений. Без этого счетчика, если использовать один общий, может оказаться, что сообщение выпало, если более одного участника отправили сообщения "одновременно".
Допустим у вас есть 100 сообщений. И у меня 100. Мы отправляем одновременно "ответ" на последнее сообщение, и каждый ставит номер 101 для общего счетчика. В результате часть участников будет считать, что у него есть 101 сообщение, но у кого-то будет мое сообщение, а у кого-то - вашею
Если мы добавим личный счетчик в эту систему, то при следующей отправке (допустим 201 сообщения, а личное у нас будет всего лишь второе в этой теме), другие увидят, второе сообщение от меня, и захотят узнать почему оно второе, ведь первого у них нет.
Но это так - контрольная функция. На самом деле сообщения с одинаковыми номерами должны "упаковываться в одно", но не более одного от каждого участника, то есть участник не должен посылать всегда 101 номер, будет действовать только первое сообщение 101, дальше он обязан ставить 102, 103....
И тут проблема, которую я вижу только в том, как долго "разрешать" сообщения с одинаковыми номерами общего счетчика. То есть чтобы не было, что втечение нескольких дней кто-то шлет сообщения, которые относятся ко вчерашним (сегодня последний номер уже 201, а мне все еще идут сообщения с номерами 100-199, которые вообще были вчера/час назад/минуту назад и т.п.).


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



Если k3,k4,k5 знают только друг о друге, а k6, k1, k2 знают тоже только друг о друге, то так и будет. Но если они в одной сети, то у каждого будет список участников (желательно максимальный) либо двое ближайших. Для k5 ближайшим должен быть k4 и k6, а не k3. K5 по своей логике не должен отправлять сообщения k3. Если он так делает, то он не знает про k6, k7, k8 и т.п. Если же он знает, но не получает ответа-подтверждения, то будет отправлять следующему по списку, снова следующему, снова и снова, и так пока не дойдет до конца и не оптравит k3. Но тогда все будет правильно - в сети только три участника: k3, k4, k5



Никак. Если все сговорились, от появляются исключительно в свой день, и нет никого, кто появляется между этими днями, то сообщения переданы не будут. Это очевидно.
Чтобы решать такую проблему нужно иметь кого-то в сети. Наверное вы видели на торрент-трекерных форумах комментарии "где сиды?". Пока человек не появится и не начнет раздавать, передача идти не будет.


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


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



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

Да я тоже всеми руками за доступность информации и за свободу слова!

Но вопрос в том, как и чем их обеспечить!

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

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

Единственное решение, которое я знаю – диверсификация. Пусть растут все цветы. Пусть любой и каждый может создать любую тему. Я писал об этом в соседней теме. Но отсюда неизбежно вытекает правило "каждый сам модератор своей темы". А модерировать без "банной кнопки" - невозможно.

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

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

Если 10 задано как минимально допустимое число пользователей онлайн – не сможет. Да, ждать, когда будет не менее 10.

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

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

Да нет же!
Опросить надо только 10-х на этапе подключения. На этапе организации "сеанса связи". После этого – всё – Ваше время проверено.
Если другие участники вошли в "сеанс связи" после такой же проверки – всё. Время всех, одновременно подключенных – идентично.

С часовым поясом – ну, правда, не вопрос. Синхронизируемся, да, по Гринвичу. Сдвиг часового пояса просто учитываем. Кстати, здесь могут быть интересные фичи – выбирать собеседников с близкими часовыми поясами и др...

НЕ МОЖЕТ он оказаться с неправильным временем. Он тоже получил доступ к "сеансу связи", как и Вы, ПОСЛЕ синхронизации времени.
А даже если он как-то обошел эту проверку, то все равно ему никто ничего не посылает и никто от него ничего не принимает, потому что сверка времени дополнительно происходит между отправителем и получателем при отправке каждого сообщения.

Конечно.

Во-о-от!

А мне видится такая система, что остающиеся в ней узлы берут на себя нагрузку по хранению сообщений (и хранению времени, само собой) тех, кто временно выпал.
Допустим, я предоставил этому "облаку" 1 Гб места на своем диске с доступом к нему с 8 до 20 и в обмен получаю, скажем, 50 Мб для хранения в "облаке" своих тем круглосуточно в десяти разных местах.
Как только кто-то из этих десяти заметит, что их, хранителей, стало 9, то он тут же запихивает мои 50 Мб новому "десятому".
Это всё конечно, грубо и упрощенно изложено, но мысль, полагаю, понятна.

P.S. Я вот зарегистрировался на symform, для пробы, теперь он шлет мне на е-мэйл жалобы типа: "Где обещанные 4 гигабайта?!"

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


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



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



Для меня такой вариант не подходит.



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


Я все-таки еще раз повторюсь. Где гарантия, что это не окажется десять "хакеров" и всех будет разное время? И почему именно 10?



У меня есть серьезное подозрение, что в программе-клиенте будет больше одной темы. Скорее всего в какой-то момент их количество начнет приближаться к сотне и выше. А ведь в каждой теме свое время. Для каждой придется опрашивать по десять человек. Как-то мне это не нравится.



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


То, как я это вижу, не содержит такой проблемы. У всех есть все сообщения из темы. Ваша версия подразумевает, что либо не все сообщения, либо не все ключи от них. В результате нужно придумывать механизм "а кто-то все равно хранит все-все сообщения". И что мы имеем? Усложение для адекватных участников и упрощение для "хакера". Он становится этим специальным участником, который хранит все сообщения, и выдает/не выдает их кому хочет.


Как это сделать?

Самая главная проблема, что я не понимаю для чего это нужно. Проблем куча:
1. Скорость доступа к прочитанным сообщениям падает - каждый раз нужно грузить заново
2. Нагрузка на сеть - все заново подключающиеся, заново скачивают все сообщения (или ключи, что в данном случае почти одно и то же)
3. Нужен механизм распределения "полных" хранителей и "частичных" - это две разные системы
4. Уязвимость остается - любой желающий все равно имеет полную тему в произвольный момент времени

Теперь "плюсы":
1. Оффлайновый злоумышленник не может вырвать винчестер и утащить всю тему целиком, если человек не стал "полным" хранителем темы. (он просто подключится и скачает всю тему как и другие участники)

Больше плюсов не вижу.

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

Всё-таки, для форума тема важнее, чем личности её участников, а такая система взаимного игнора "разваливает" тему.

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

А! Действительно. Это очень правильно. Нет IP – нечего и защищать.

Да, конечно, я неудачно выразился. Я имел в виду только связь с IP.

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

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

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

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

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

Нет. Единое время – едино для всех участников сети, даже если они и не общаются друг с другом в конкретной теме.

Нет, не будут. Никакие сообщения не отправляются тем, у кого неправильное время.

Сколько бы ни было злоумышленников с одинковым, но "неправильным" временем, в моей схеме они смогут пересылать сообщения только друг другу.

10 – было взято для примера. Исходя из ситуации, когда у нас в сети, например, сто участников с нормальным временем и пусть даже злоумышленник развернул 20 неправильных клиентов (каким, кстати, образом? подключил к сети 20 машин? запустил на одной машине 20 версий клиента?). Тогда вероятность того, что при случайном переборе новым подключающимся 10 клиентов он попадет 10 раз на время хакера(ов) = (20/100)*(19/99)*(18/98)... (1/80) приблизительно равно 1/5 в 10 степени = около одной десятимиллионной. Если соотношение нормальных к ненормальным 1000 к 20, то соответствующая вероятность около 1/100 000 000 000 000 000.
И даже, если кому-то так "не повезло", то он быстро это поймет, так как сможет общаться только с этими 20 хакерами.

Разумеется.

Да почему?! Одно время для всего форума, для всех тем.

И что? Если свежеподключающийся увидел отличное время у одного из десяти опрошенных, то он этого одного вычеркнул и нашел 11-го. Итого, у свежеподключившегося – 10 нормальных с которыми работает (плюс все остальные с нормальным временем) и один ненормальный (а также все остальные ненормальные), с которыми не работает.

Здесь, имхо, разница в наших подходах.

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

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

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

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

Про сообщение нигде речь не шла. Отключается пользователь. То есть все сообщения какого-либо участника перестают отображаться.



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


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


Практика показывает, что такая причина бана - нонсенс. Банят чаще всего, потому что человек наприятен, потому что его идеи не нравятся модератору. Спамеров банат, после того, как все уже успели прочитать спам сообщения, а модератор все это время был на работе, в баре и т.п. Действия модератора _всегда_ опаздывают. Это свойство человека-модератора. Если в форуме участников нормальное количество, то спам обязательно увидят до того, как сработал модератор.


Участник пишет "автор темы - мудак, вот новая тема http://xxx.com". Модератор удаляет сообщение и банит участника. Все остальные продолжают есть кактус.
Либо другой вариант. Модератор как всегда опоздал и половина участников куда-то ушла увидев сообщение, которое потом было удалено. Оставшиеся недоумевают что произошло.



Изначально была идея, что темы могут иметь разные правила именно в этом отношении. Причем они не описываются автором в виде текста, а задаются настройками. Один из вариантов "анонимный" представлялся так:
каждый участник, которые присоединяется обязан создать новый ID и ник (ID в любом случае автоматически генерирует клиентская программа, с ником можно обсуждать, конечно лучше вручную). То есть в пределах одной темы можно отличать участников, но в такой же соседней, даже при тех же никах, не будет совпадающих с этой темой ID, и найти человека по этому ID вне темы будет невозможно.


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



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


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


У вас получается снова получается непонятная нагрузка на сеть. 1. запрос времени. 2. ответ времени. 3 отправка сообщения. И так ведь происходит по цепочке. Три сообщения вместо одного (а вообще-то должно быть какое-то подтверждение о приеме сообщения, значит четыре).
И опять же надо думать о "правильном времени".



Любой вариант. Вы можете сделать программу , которая запретит запускать копии. Но можно сделать свою программу, которая будет подключаться сколько угодно раз. Может не двадцать, а тысячу. Не получится сделать ограничение один ip - один клиент, из-за NAT и даже из-за динамического ip (один отключился, другой тут же подключился с тем же ip)


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


Хорошо.


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


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

Я хочу, чтобы было место для общения, где люди могут не придерживаться чужих правил, а вырабатывать свои. Когда вы хотите общаться с человеком, вы придерживаетесь каких-то норм, котрые всех участников общения устраивают. Перестали устраивать - вы выходите из комнаты. В интернете мы можем себе позволить удалить кого-то из комнаты. Можем удалить для всех, а можем удалить только для конкретных людей. Я думаю нужна максимальная гибкость - каждый решает кого он хочет удалить и общаться только с теми, кто интересен и удобен в общении.
Вместе с этим, хочется получить простую в освоении и использовании программу, которая бы радовала скоростью работы.
И только потом есть желание защитить сообщения от внешнего наблюдателя. Как это решить для большого количества участников я не знаю. Поэтому я не заморачиваюсь с распределенных хранением ключей, сообщений и т.п. Хотите конфиденциальности - обмениваетесь публичными ключами и шифруете сообщения ими, только адресат сможет расшифровать. То есть придется шифровать для каждого отдельно.
Легонькая защита возможна только для конкретных сообщений. Чтобы при перехвате нельзя было быстро отфильтровать по известным словам нужно использовать симметричное шифрование (любой вариант, который нравится). Пароль хранится в первом сообщении. То есть получить пароль может фактически любой, но автоматическая дешифровка произвольного сообщения (фильтрация) у рядового провайдера работать не будет.

В таком варианте, если в теме нет одновременно хотя бы двух участников онлайн, то пересылка сообщений вообще невозможна.
То есть, мы с Вами не могли бы общаться в распределенном форуме.
Здесь сервер flybb принял Ваши посты 9 ноября и хранит их до 14 ноября, когда я, наконец, отвечаю на них. А в распределенном форуме где они будут хранится?


P.S. По остальному, извините, позже. Много возражений и предложений. Думаю.

Озирис! Озирис!

Что такое "Озирис": часть 1 и часть 2.

Там все первично необходимые ссылки и инструкции.

Кроме того, клиент Озириса для Windows (XP, Vista, Семерка) можно скачать здесь.

Но я бы посоветовал Portable версию. Работает так же, но удобно разместить где-нибудь на флэшке, или на отдельном диске. Тогда весь форум (всё написанное и всё прочитанное) можно будет легко переносить на разные компы или носители.

Все установки по умолчанию.

Cсылка (точнее, инвайт-линк) на "Заповедник для людей" в Озирисе (будет работать ПОСЛЕ установки клиента) выглядит так:

osiris://|portal|010000018382B6DCFBC9EA ... %B5%D0%B9|

(эту ссылку скопипастить в соответствующее поле в "Subscribe")

После установки и регистрации своего аккаунта переходим в "Latest discussion" тема "Проверка связи!"

Все в Озирис!

До встречи!