Продолжение мыслей и экспериментов по распределённым форумам

Чтобы не повторяться, поток мыслей по теме: http://www.wrk.ru/support/2014/04/t89569--aviabaza-raspredelyonnaya.7177.html

никто не мешает в такой открытой системе размещать материалы от чужого имени.

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

самое главное - насколько оно законно в России?

и чтобы прочитать пару веток форума надо напрячь всю доступную числодробильню до воя кулеров?

Это не важно. Сегодня одни законы, завтра другие, а технологии постоянны.

Увы. Есть лучше идеи?

нету. просто не вижу большого смысла в сабже.

Вопрос авторства материалов. Подписываться одним ником, понятно, вообще не катит. Использовать e-mail в качестве идентификатора решение напрашивающееся, но увы — все данные форума будут общедоступны.

Напрашивается подпись gpg. Заодно решится и

никто не мешает в такой открытой системе размещать материалы от чужого имени.

у гита есть субмодули. git submodule add/del/pull

Вместо почтового адреса можно взять его хеш. С однократным подтверждением по почте.

скоро (мобильные) устройства будут как хосты :) o_O

Здравствуй p2p интернет.

Но в общем здравая мысль - смысл понятен. База тоже д.б. распределенная - ее не надо синхронизировать - только то что нужно.

Надо писать RFC или уже есть такое?

p/s Подумалось - нужен интернет наоборот: не c2s а s2c или с2с или s2s

В общем решаемо всё.

Второй вопрос ещё сложнее. Вопрос авторства материалов.

ЭЦП.

самое главное - насколько оно законно в России?

А пофиг. На то оно и распределённое.

у гита есть субмодули. git submodule add/del/pull

Они помогут перенести часть файлов из одного репозитория в другой со всей историей?

Напрашивается подпись gpg
ЭЦП

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

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

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

В правильном направлении мыслю? :)

Сюда явно напрашивается асимметричное шифрование.

Вместо почтового адреса можно взять его хеш

Кстати, да. Ещё остаётся вопрос обратной связи с автором. Видимо, можно указывать с привязкой к серверу-гейту, с которого писал автор (типа <md5>@server), на котором уже и хранить хеш для e-mail каждого автора. Ну а кто будет писать минуя гейты, тот или пусть указывает e-mail прямо, или сознательно теряет обратную связь.

База тоже д.б. распределенная - ее не надо синхронизировать - только то что нужно.

Суть в том, чтобы распределённый бэкенд был в DVCS, в человекочитаемом формате. Я сейчас использую JSON для исходных данных и сформированный markdown/html (r/o) для удобного просмотра прямо в репозитории, минуя web-гейт.

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

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

Тут, кстати, ещё одна проблема средней тяжести — ID сообщений/тем. Понятно, что можно тупо использовать многобайтовые UUID, но хочется простоты целочисленных автоинкрементных ID (для удобства работы). Надо подбирать истину где-то посередине :) То ли составлять ID сообщений из даты + ID проекта + ID пользователя, то ли ещё как-то... В принципе, если я разбиваю репозитории по датам, вплоть до одного репозитория на месяц, то даже год/месяц в ID можно не включать, хватит DDHHMMSS+UserID...

посмотри как сделан twister, авось натолкнет на мысли.

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

посмотри как сделан twister, авось натолкнет на мысли

Там идеология совсем другая.

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

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

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

Догадался глянуть нагрузку по аттачам. У меня сейчас это 3-5Гб в месяц. Так что однозначно придётся резать репозитории по месяцам :) И то уже не каждый сервис такое переварит.

Интересно, как GitHub, например (если разберусь, как в Git переносить файл со всей историей между репозиториями), относятся к таким объёмам? :D

Да, вот ещё момент. Есть идеи, как бороться в такой системе со спамом?

Ага. В git, кажется, перенести файл со всей историей тоже не вопрос:
http://gbayer.com/development/moving-files-from-one-git-repository-to-another...

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

Тут, кстати, ещё одна проблема средней тяжести — ID сообщений/тем.

системные номера - конечно зло в общем. (см.ниже альтернативный подход)

Суть в том, чтобы распределённый бэкенд был в DVCS, в человекочитаемом формате.

По сути если форум разбить на много маленьких файлов - [host/domain/|remote]forum/section/topic/thread/message.any-ml|json[+xslt] (кстати это можно преобразовать в читаемый ID - типа path), то будет очень удобно по гиту забирать особенно развлечения для гиков. Такая репа будет выполнять роль и своеобразной БД. А в качестве клиента какой-угодно просмотрщик, хоть org-mode или движок по усмотрению (конвейер не сложно прикрутить)

Одно но: версионность нужна очень мало где в задачах форумов. Хотя нет нужна везде - это-ж синхронизация только надо пулиться и пушиться без конфликтов как-то. Да - subtree в помощь.

Аттачи, картинки туда не тащить - т.к. DCVS не очень эффективно работает с бинарщиной (если только в какой-нибудь baseNN переводить мелкие объекты)

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

Тут, кстати, ещё одна проблема средней тяжести — ID сообщений/тем.

Каждая тема - ветка. Сообщение - коммит.

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

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

Идентификаторы, всё же, видимо, придётся использовать UUID. Для удобства работы с SQL-кешем хотелось бы вложить их в 64 бита. Стандартные UUID куда длиннее. Будет ли корректным тупо обрезать их?

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

Изначально планировал использовать формат «один постинг = один файл JSON».

Сейчас думаю, не надо ли переходить на формат «один топик = один файл JSON». Иначе больно много мелких файлов выходит. Для FS лишняя нагрузка.

С другой стороны, парсинг мелочёвки проще с точки зрения блокировок при модификации.

Интересно, а в природе нет чего-нибудь embedded, типа sqlite, но на plain-text? :)

Поиграл с git и mercurial на месячном срезе форумов. В принципе, почти идентично. Так что, хоть мне нравится mercurial, буду делать ставку на git — он более распространён, проще будет и с хостингами, и с поддержкой.

Ещё интересный момент — если припрёт, в рамках этой системы можно будет обмениваться обновлениями при отсутствии онлайна, на «флешконете», например :)

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

Минимальная длина ключа для sha256 — 384 бита. Получается минимальная строка в 64 символа. Достаточно ли этого для поверхностной защиты?

Минимальная длина ключа для sha256 — 384 бита. Получается минимальная строка в 64 символа. Достаточно ли этого для поверхностной защиты?

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

Есть мысли?

/cast summon Витус Вагнер.
То есть он всё равно сюда не придёт, он сюда заходит раз в два года в лучшем случае... Но он что-то такое пилит.

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

В правильном направлении мыслю? :)

ИМХО, ключи должны лежать только у пользователя, а генерацией подписанного сообщения должен заниматься клиент (возможно, веб клиент, если есть возможность задействовать для этого javascript)