Тема поднималась уже неоднократно, и сейчас я напишу просто 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 году... ой, нет, не то. Пока, конечно, всё вышесказанное живёт лишь в моей одинокой головушке, и я хотел бы узнать, есть ли реализации подобных задумок, есть ли известные недостатки у такой модели, есть ли готовые прототипы, похожие протоколы, на которые имеет смысл ориентироваться, и так далее? Есть ли просто более обоснованные, чем просто «ненужно», мнения на этот счёт?
Я не верю, что вы это всё дочитали, но всё равно принято говорить спасибо, что вы это всё дочитали. Спасибо.
