LINUX.ORG.RU
ФорумTalks

Распределённая блогоплатформа?


0

1

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

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

Итак, предположим, существуют два блогосервиса: SuperBlogs.xxx и AnotherBlogs.xyz. Их идентификаторами являются их доменные имена — не самый надёжный в мире, но довольно оптимальный способ понять, когда сервер «ещё тот», а когда «уже не тот», то есть начал закрываться, переезжать, становится недоступным и так далее. В общем, будем считать, что эти два сервиса за всё время существования так и останутся доступны именно по этим доменам.

Пользователь с внезапным именем Алиса публикует свой пост про котяток и цветочки на SuperBlogs.xxx. Технически это означает, что на сервере SuperBlogs.xxx теперь хранится новый объект «пост Алисы», родителем которого является объект «блог Алисы», родителем которого является объект «весь SuperBlogs.xxx». В свою очередь, комментарии к посту становятся детьми объекта «пост Алисы». Тут важно, что у объекта может быть и несколько родителей одновременно — это позволит пользователям гибко выносить комментарии в другие места. «Пользователь поделился ссылкой в своём дневнике», вот это всё.

SuperBlogs.xxx через стандартизированное API даёт доступ к лентам: «все новые дети объекта «блог Алисы»», «все новые дети объекта «пост Алисы #5»», «все новые дети объекта «комментарий у Алисы #1488»». Опционально ещё всякие фильтры и поиски, но это пока опционально.

В свою очередь, друг Алисы с ещё более внезапным именем Боб пользуется сервисом AnotherBlogs.xyz и читает ленту своих друзей там. Замечу, что он мог бы с тем же успехом пользоваться и десктопным приложением, похожим на RSS-клиент, но вот наш конкретный Боб пользуется онлайн-сервисом, который в данном сценарии является, по сути, клиентом (на самом деле он и клиент, и сервер, и на дуде игрец, ибо все равны в нашей децентрализованной сети). Так вот, действуя как клиент, AnotherBlogs.xyz обращается к SuperBlogs.xxx, запрашивая последние обновления по подписке «все новые дети объекта «блог Алисы»». В запросе он отправляет идентификаторы всех постов Алисы, о которых он уже знает. (Тут есть обширное поле для оптимизаций и упрощений запроса, типа «не буду перечислять подробно, но я уже получил либо меня не интересуют посты ранее этого года».) В ответ сервер присылает свежачок, и клиент сохраняет его у себя.

Пока всё понятно, да? Теперь усложняем. Вводим самый главный нюанс: Алиса не привязана к серверу SuperBlogs.xxx. Её новые посты не обязаны появляться именно там, они могут появляться где угодно. Разумеется, на практике люди не меняют блогохостинги как перчатки, поэтому у клиента, скорее всего, будет выставлена по умолчанию настройка «Искать посты Алисы только на SuperBlogs.xxx». (Другие опции — «Искать там, где нашёл в прошлый раз», «Искать на всех известных мне узлах», «Искать на 10 самых популярных плюс на каком-то специальном веб-архиве для подстраховки» и т.п.) Как вы понимаете, я клоню к тому, что если суровый Роскомнадзор пришёл и удалил запись про котяток и цветочки с SuperBlogs.xxx, но она успела скачаться на другие сервера, то наш Боб сможет увидеть котяток и цветочки, загрузив копию оттуда.

Идём дальше. Что если Алиса действительно захочет удалить свою запись? Или изменить её, оставив только цветочки, но убрав котяток под давлением Роскомнадзора, который борется с зоофилией? Или если администрация SuperBlogs.xxx сочтёт эту запись спамом и бояном и удалит её? В нашей сети против этих трёх бед действует один ответ: никаких изменений и удалений нет. То, что выгружено в сеть, не может быть отгружено обратно. Но погодите разбегаться, есть выход: специальные посты типа «апдейт». Это такие специальные диффы, которые применяются к предыдущей версии поста и изменяют либо полностью удаляют его.

Итак, что же будет происходить, если запись удалена? Это значит, что помимо сообщения «пост #5: котятки и цветочки» SuperBlogs.xxx будет распространять ещё и «пост #6: удалить прошлый пост». В зависимости от настроек как клиента, так и сервера эти две записи либо будут схлопнуты в одну (т.е. дифф будет применяться ещё на сервере), либо не будут. Если SuperBlogs.xxx абьюзоустойчивый и не боится Роскомнадзора, то он будет предоставлять обе опции. Заметьте, что это, как ни странно, наиболее выгодная политика. Ведь если запись просинкалась хоть на один посторонний сервер, то в дальнейшем её смогут найти все прежние читатели Алисы (и они даже убедятся, что это не фейк, ведь в нашем светлом мире все сообщения по умолчанию подписываются ключами, а вы как думали?). Есть только три способа, чтобы Боб не увидел поста Алисы. Первый: Алиса сама, добровольно, в трезвом уме и со своим ключом, публикует дифф-удаление, и тогда Боб со стандартными настройками клиента, скорее всего, уважительно относится к её воле и не читает удалённый пост. Второй: один из цензуроподвластных серверов, через которое прошло сообщение, добавляет дифф-удаление от своего имени (подобно добавлению заголовка X-Spam-Status в почте), в этом случае клиент, которым пользуется Боб, имеет повод ругнуться и предложить Бобу игнорировать такой чужеродный дифф. Наконец, третий способ: SuperBlogs.xxx прикидывается дурачком и просто перестаёт упоминать «пост #5» в своих ответах на запросы. Что ж, ему же хуже. Сообщение продолжает существовать неудалённым в виде копий на других площадках, и даже те пользователи, которые безоговорочно доверяли сообщениям от SuperBlogs.xxx, вполне могут прочитать «пост #5»: ведь диффа с безоговорочно доверенным «опровержением» они попросту не получили, а вот «пост #5» из других источников получили! Наиболее продвинутые могут в таких ситуациях даже автоматически занижать SuperBlogs.xxx в локальном списке предпочтительных, потому что зачем же доверять сервису, который то ли удаляет, то ли теряет и не доставляет сообщения, тогда как весь интернет вокруг уже в курсе, что «пост #5» был и написала его Алиса? Таким образом, с большой долей вероятности удалить опубликованное сообщение у кровавого режима не получится.

Специально подчёркиваю, что дифф может происходить как на клиенте, так и на сервере. Предположим, Алиса —— злостный спамер или просто назойливый чайник, и она наплодила 100500 одинаковых сообщений. Задача SuperBlogs.xxx как цивилизованного сервиса — удалить дубли, чтобы не засорять ленты подписанных пользователей. Выгодно ли SuperBlogs.xxx тупо замалчивать их существование и вещать про 1 запись вместо 100500 начиная с того момента, как администрация их обнаружила? Нет, не выгодно. Так как остальные 100499 сообщений могли уже разойтись по другим клиентам и серверам. Правильная стратегия — выпустить 100499 диффов-удалений, подписанных ключом пользователя Antispam@SuperBlogs.xxx или типа того. Клиенты, которые доверяют администрации (а таких будет подавляющее большинство), не будут требовать от сервера всей истории изменений, а просто получат одну неудалённую запись. Остальные же пользователи, которые собирают у себя дома веб-архив либо просто чересчур параноидальны, получат все 200999 записей (100500 постов плюс 100499 удалений) и получат возможность локально копаться во всей истории. И снова все счастливы! Да что ж это такое, никому не получается насолить!

Остаётся один, возможно, не совсем очевидный вопрос: а как мы вообще собираемся идентифицировать сообщения, как их нумеровать? Как понять, что вон та запись, прилетевшая в клиент из стороннего веб-архива — это именно «пост Алисы #5»? А никак. Мы оставляем нумерацию на совести SuperBlogs.xxx, так как, повторяю, пользователи не меняют блогохостинги как перчатки. Поэтому нумерацию обеспечивает тот сервер, на котором размещено сообщение, а остальные используют её, т.е. идентификатор у всех выглядит примерно так: «SuperBlogs.xxx/Алиса/5». Мы не ставим перед собой цель дать возможность постить котяток сразу «в никуда», «в облако». Мы лишь ставим цель не потерять уже запощенных котяток, если пост будет забанен, сервис — закрыт, сервер — недоступен, и так далее. Если Алиса захочет свалить на другой блогохостинг, она сама напишет об этом (более или менее стандартизированное) сообщение, с которого и начнёт новый блог на AnotherBlogs.xyz. А так как у неё есть публичный ключ, Боб сможет легко убедиться, что перед ним та же Алиса, что и прежде. Продвинутые клиенты нашей замечательной сети будут сами периодически опрашивать известные публичные сервера-«адресные книги» с целью проверить, не появилось ли новых блогов с теми же ключами у людей, на которых подписан Боб. При определённом желании можно реализовать это так, что Боб даже не заметит, что посты Алисы теперь качаются с нового, менее зацензуренного или просто более удобного Алисе сервиса. Умный клиент сети сам красивенько склеит историю сообщений Алисы с разных сервисов воедино.

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

Я не верю, что вы это всё дочитали, но всё равно принято говорить спасибо, что вы это всё дочитали. Спасибо.

Блджад, как это все читать?

ЛОР - не блогоплатформа.

dvrts ★★★ ()

SuperBlogs.xxx

Порноблоги?

Остаётся один, возможно, не совсем очевидный вопрос: а как мы вообще собираемся идентифицировать сообщения, как их нумеровать? Как понять, что вон та запись, прилетевшая в клиент из стороннего веб-архива — это именно «пост Алисы #5»? А никак.

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

Sadler ★★★ ()
Последнее исправление: Sadler (всего исправлений: 1)

Чувак, достаточно стандартного api и серверов с pgp подписями. Только это нах никому не уперлось.

zloelamo ★★★★ ()
Последнее исправление: zloelamo (всего исправлений: 1)

Пост не читал, но догадываюсь, что автор хочет:
1) API для выгрузки блога.
2) API для загрузки блога целиком из дампа вместе с комментариями.
3) Комментарии подписываются ключами, чтобы владелец блога не мог добавить комментов от чужого имени.
4) ...
5) Profit!

Biga ()
Последнее исправление: Biga (всего исправлений: 1)

Хрен с ними с распределённостями, дайте мне один API, который подойдёт ко всем блогоплатформам, а остальные закопайте. Сколько ж можно велосипедить.

Deleted ()

не читал, но осуждаю.

не нужно.

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

Это я целиком и полностью поддерживаю!

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

Поддержке или неподдержке всяких других API (RSS/Atom для чтения + что-то ещё для записи) это никак не противоречит, и пускай эти вещи существуют параллельно.

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

Было б это, можно было бы руками бэкапиться. Лучше, чем ничего. А так, конечно, я не против.

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

Я тоже Ъ, поэтому не знаю, как у них там организовано, но подозреваю, что просто сайт периодически скачивает записи из чужих RSSов. То есть просто такой гугл-ридер. Если автор записи удалит её у себя из блога, а потом скрипт на Planet Qt осуществит синхронизацию и тоже удалит эту запись из своей подборки, то всё, приплыли: новый читатель уже не увидит запись в ленте. Хотя 100 предыдущих читателей, которые её там видели, могли бы запросто восполнить пробел.

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

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

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

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

Кэш в RSS читалке не пойдёт, потому что потом его экспортировать куда-то очень непростое занятие.

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

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

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

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

frozenix ★★★ ()

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

UPD: Google Wave, по моему, примерно в эту сторону двигался, не?

Zubok ★★★★★ ()
Последнее исправление: Zubok (всего исправлений: 1)

Иди к Каганову, он что-то в этом направлении пилил.

om-nom-nimouse ★★ ()
Ответ на: комментарий от greatperson

Назвать какнить «Cloud-Sync» и пеарить за внедрение на различные платформы. Для начала реализовать на пыхе, т.к. сайтов больше всего именно на пыхе.

Ну и соответственно этот Cloud-Sync должен иметь какие-то стандартные инструменты - Cloud-Sync-сервер должен отдавать контент бложека по запросу Cloud-Sync-клиента.

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

И еще не понятно какое именно техническое решение подойдет - пилить в виде «плагина» или ставить как независимое приложение.

Потому как если приложение:

1) можно кроссплатформенно и решит часть проблем интеграции с существующими CMS/FW. 2) в виде демона или сервиса. 3) тупо натравливаем его на свой сайт а-ля: $ cloud-syncd --attach http://mysite.ru/ (оно там само будет проходить раз в час например wget'ом рекурсивно). 4) можно хранить свой индекс как угодно, хоть толстого клиента к БД прикручивай, хоть в файл дампуй бинарно и «сикай» по нему потом. 5) на своем бложике просто добавь специальные теги-метки (ну например <div class=«cloud-sync-datetime»>2014-06-26 13:44:08</div>) по которым твой проходчик будет синхрить дыффы постов по времени, содержимому и т.д. 6) такое же ПО установленное на другом сайте обращаясь напрямую к твоему демону/сервису получит только нужную задифленную инфу, а твой стандартный сервер не будет напрягаться от лишних запросов сотни проходчиков с других сайтов.

Что-то все это на хуки в гите смахивает )))

deep-purple ★★★★★ ()

не читал, но по названию - есть пачка распределенных блогоплатформ для сетей вроде freenet и i2p

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

Уход в альтернативные сети — несколько другого уровня затея. Я предлагаю решение внутри существующего веба.

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

я к тому - ты проверь, можт эти утилиты вполне работают и в обычном вебе

upcFrost ★★★★★ ()

Почти все это можно сделать в виде веб-гуя для git.

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