LINUX.ORG.RU
ФорумTalks

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

 , , ,


0

3

Поскольку идея с распределёнными сайтами более-менее работает (Zim Wiki в DVCS и гейт-сайт для отображения, кеширования с целью поиска и т.п.), перешёл ко второй стадии, распределённым форумам. Задача намного сложнее, но и востребованнее.

Если тупо бухнуть всю БД моих форумов в один репозиторий, то любая DVCS тихо умрёт. Попробовал нарезать по датам сообщений. Экспорт в формате один репозиторий-один год, порождает несколько 2-3 Гб текста + с десяток гигабайт аттачей, всё вместе — до миллиона файлов. DVCS такое пережёвывают, но очень медленно. git add выполняется на голом тексте, без аттачей (1.3Гб данных) около часа.

Видимо, надо резать ещё и по месяцам, тогда время работы станет приемлемым.

Теперь проблемы.

Напрашивается разделение по раздельным проектам/ресурсам. Т.е., типа, нефиг всё валить в один репозиторий, можно порезать политика — в одном, авиация — в другом, компьютеры — в третьем. Проблема в том, что идеология системы должна обеспечивать свободный перенос материалов между проектами. Типа, сносить танцпол их чисто технических форумов в политические. В случае монолитного репозитория — никаких проблем, hg move/git vm — и готово. Но напрашивается идея разделения по репозиториям. Тогда в системе могут появится вообще независимые участники. Да и тем, кто будет выкачивать репозитории для офлайновой работы не придётся тянуть ненужное.

Значит встаёт вопрос переноса материалов (со всей историей) из одного репозитория в другой. Для mercurial это, хоть несколько геморройно, но выполнимо (экспорт файлов в новый временный репозиторий со всей историей, присоединение этого репозитория в целевой, удаление материалов и старого репозитория).

Как с этим в git? Ибо вопрос выбора движка DVCS тут становится принципиальным, перенести из git в mercurial файлов со всей историей уже точно не получится :) Надо всё делать на одной системе.

Второй вопрос ещё сложнее. Вопрос авторства материалов. Подписываться одним ником, понятно, вообще не катит. Использовать e-mail в качестве идентификатора решение напрашивающееся, но увы — все данные форума будут общедоступны. И очень немногие захотят светить свои e-mail'ы. Ещё хуже ситуация с архивами. Там 90% пользователей зачастую вообще уже не участвуют в работе и обратная связь с ними затруднена.

Лобовое решение — централизованный сервер авторизации, который назначает ID юзеров. Фактически, то, что и сейчас есть в пределах обычных форумов. Проблема в централизованности.

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

Есть мысли? :)

★★★★★

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

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

Stahl ★★☆ ()
Ответ на: комментарий от dib2

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

Stahl ★★☆ ()
Ответ на: комментарий от Stahl

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

dib2 ★★★★★ ()

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

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

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

feofan ★★★★★ ()

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

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

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

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

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

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

swwwfactory ★★ ()

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

ЭЦП.

Deleted ()
Ответ на: комментарий от dib2

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от bvn13

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

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

KRoN73 ★★★★★ ()

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

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

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

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

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

KRoN73 ★★★★★ ()

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

kernelpanic ★★★★★ ()
Ответ на: комментарий от question4

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от swwwfactory

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

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

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

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

kernelpanic ★★★★★ ()
Ответ на: комментарий от tazhate

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от kernelpanic

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

KRoN73 ★★★★★ ()

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

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

KRoN73 ★★★★★ ()

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

KRoN73 ★★★★★ ()

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

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

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

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

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

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

swwwfactory ★★ ()
Ответ на: комментарий от KRoN73

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

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

kernelpanic ★★★★★ ()

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

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

KRoN73 ★★★★★ ()

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

KRoN73 ★★★★★ ()

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

KRoN73 ★★★★★ ()

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

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

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

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

KRoN73 ★★★★★ ()

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

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

KRoN73 ★★★★★ ()

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

swwwfactory ★★ ()

Есть мысли?

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

Xellos ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

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

feofan ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.