Распределёные форумы/блоги. Продолжаем разговор. Нужен совет.

Есть такая штуковина - RetroShare. Там уже рспределённость, форумы и блоги реализованы. Аутентификация по GPG-ключам.

Вы предлагаете коммитить форумы в гитхаб? Это не нарушает terms of usage?

Нарезать на месяцы, а старые не хранить совсем. Решение далеко не лучшее, но и мусорку разводить не надо. Или можно задействовать сжатие.

Оно еще живо? Я тыкал палочкой это с месяц назад, но что то там было грустно.

Вы предлагаете коммитить форумы в гитхаб? Это не нарушает terms of usage?

1. Система может работать на любых репозиториях. Просто github по понятным причинам интересен.

2. Какие конкретно пункты ToU это может нарушать?

а старые не хранить совсем

Нет. Архивы обязательны. Иначе смысла никакого нет.

Или можно задействовать сжатие.

Git этим и будет заниматься :)

Есть такая штуковина - RetroShare

Это совсем другая идея. Идея того, что делаю я в том что:

— Для простого пользователя вообще ничего не изменится, как были web-форумы (блоги, сайты), так и остались.

— База данных становится распределённой и распределённой на привычной всем DVCS, что позволяет максимально обеспечить сохранность данных.

— Появляется возможность работы с одними проектами с разных хостов (участвующих в система) в произвольных сочетаниях.

Нет. Архивы обязательны. Иначе смысла никакого нет.

Складывать в облака?

Я не знаю, просто советую еще раз проверить на всякий случай. Руководствоваться логикой не проверяя контракт или соглашение пользователя - ошибочная практика

Хотя даже согласно логике - это abuse на шару выделяемого пространства для кода. Они то дают 1 ГБ с учётом что большинство не использует целый ГБ. Нужно не забывать, что если вы на шару получили гигабайт, то это одолжение, а не ваше право

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

Складывать в облака?

Да. На сервера, поддерживающие git :)

Просто проблема именно в максимальных объёмах. В первую очередь на том же github'е.

Я не знаю, просто советую еще раз проверить на всякий случай.

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

Ваше решение с Git интересно, но не навредите, захламляя Github

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

Тут такой момент. Если сам подход к вопросу станет популярным (о, я бы этого хотел :D), то вопросы размещения репозиториев с «форумами школоты» будет решать эта самая школота. А за свои проекты (и выбор серверов, с которыми им работать) я отвечаю сам :) Более того, основная нагрузка, вообще, будет на своём же сервере. Просто нужно иметь резерв — на то система и распределённая.

За месяц публикуется 35..40 тыс. сообщений
DVCS и гейт-сайт для отображения, кеширования с целью поиска и т.п.)

elasticsearch для доков и поиска + hbase/voldemort для свалки аттачей. Оба имеют асинхронные клиенты, шардинг, репликацию, дружественны к hadoop и горизонтально масштабируются by-design. Если полнотекстовый поиск не нужен, то можно хорошо сэкономить на оперативке.

Сейчас совокупный объём всех аттачей растёт на 5..7Гб в месяц.

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

Может лучше лить куда нибудь где нет лимитов на объем?

elasticsearch для доков и поиска + hbase/voldemort для свалки аттачей

Это вопрос гейта/сайта. Он может иметь множество решений, вплоть до загрузки базы в любой обычный форумный движок (только вопросы с ID надо решить). Фактически, традиционные web-форумы становятся кешем для распределённых данных (которые использовать в лоб будет почти невозможно).

Интересует же именно межгейтовая синхронизация, распределённое хранилище данных. А проблема аттачей — в том, что с одной стороны, хочется всё держать в одном месте, с другой — не хочется «захламлять github» — забивать репозиторий большими объёмами бинарных данных.

Вот нащупать тут удовлетворяющее решение пока не могу.

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

Задача стоит в построении распределённой устойчивой к запретам и блокировкам системы. Соответственно, подобный сервер становится только нодой системы, но справляться с хранением надо иначе. Тем интересен BTSync — там можно хранить большие объёмы прямо у пользователей. Но это лишняя сущность как в плане софта (одним браузером уже не обойтись), так и в плане расслоения данных — топик форума перестаёт быть чем-то атомарным.

Может лучше лить куда нибудь где нет лимитов на объем?

Лучше. Но ещё лучше пробовать решить проблему так, чтобы лимиты сильно не влияли. Это повысит выживаемость системы.

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

Тем интересен BTSync — там можно хранить большие объёмы прямо у пользователей. Но это лишняя сущность как в плане софта (одним браузером уже не обойтись)

Сразу вспоминается peerCDN, вроде его yahoo скупила сейчас.

Задача стоит в построении распределённой устойчивой к запретам и блокировкам системы.

Это непросто, учитывая что взбесившийся принтер никак не хочет останавливаться.

Это непросто, учитывая что взбесившийся принтер никак не хочет останавливаться.

В данном случае запретить систему можно только полностью перекрыв доступ ко всем не лицензированным ресурсам :) Тут даже блокировка шифрования и нестандартных протоколов не спасёт. Данные распределённые, гейт за рубежом. Заблокировали — спокойно заходим через другой гейт.

Впрочем, даже заблокировав Интернет целиком можно систему не убить — коммиты можно будет носить на флешконете :) Тут только жёстче встанет вопрос спама/вандализма/школоты — разрешить каждому коммитить, значит снять вопрос контроля качества с гейта.

(да, всё сказанное именно к базе сообщений на git, так как BTSync, конечно, блокируется легко).

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

Возможные решения, что я вижу:

— Инкрементные автоматические ID со смещением. В случае закрытой системы между участниками можно договориться, что в N последних цифр ID прописан номер участника системы. Минусы — жёсткая, тяжело расширяемая структура, сужение диапазона рабочих ID, на большинстве форумов в базах в качестве ID используются 32 бит целые.

— Использовать в качестве ID дату + несколько цифр UUID. Подобная же фигня, ещё большее сужение диапазона ID.

— Назначение при импорте сообщений своих уникальных ID в каждом проекте. Проблема в обмене ссылками. Одно сообщение на разных гейтах получается под разным номером... С другой стороны, по хорошему, парсер форумов не должен сохранять в БД полные URL'ы тем, форумов и сообщений — система распределённая, завтра домен поменяется, ссылки все накроются? А если написано на другом гейте но на форум, копия которого есть в текущем гейте читателя — зачем ему уходить на первый гейт? Так что напрашивается трансляция URL сообщений/тем/форумов во внутренний формат и обратное преобразование при показе. В этом случае несовпадающе ID на гейтах проблемой быть перестают. Достаточно рядом с сообщением хранить реальный UUID и сохранять при размещении ссылки в базу именно его. В этом варианте тоже есть подводные камни, но мне он кажется более реальным.

Ещё как вариант — использовать унифицированный формат ссылок, хранящий и UUID, и локальный ID.

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

А если хранить информацию об аттачах в git-annex?

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

Еще интересно выглядят планы по добавлению telehash.

А если хранить информацию об аттачах в git-annex?

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

Сами файлы можно хранить где угодно, куча бэкендов есть

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

Еще интересно выглядят планы по добавлению telehash.

А в чём суть?

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

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

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

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

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

А в чём суть?

P2P протокол, предполагается использовать для (автоматической) синхронизации изменений между репозиториями, которая в настоящий момент работает через xmpp/ssh. Упомянул как возможную альтернативу проприетарному BTSync.