Наброски архитектуры децентрализованной нецензурируемой соцсети на базе блокчейна Emer, построенной по роевому принципу.
О документе
Это не статья для масс. Это не описание готового продукта или сервиса. Это весьма специфический документ о моих мыслях и возможно - будущей разработке. Но документ не секретный. И призван он начать обсуждение, чтобы получить обратную связь - насколько предложенная система востребована, а также получить указания на ошибки, ежели таковые будут обнаружены. Возможно - читатели смогут предложить некие полезные изменения и дополнения к рассматриваемой архитектуре. Также документ фиксирует моё авторство данной архитектуры. Статья является публичным достоянием, и никакая её часть, а также предложенная архитектура не может быть запатентована или копирайчена. Хотя конечно же копирайт может быть применён к какой-то конкретной имплементации предложенной архитектуры.
Я рад буду, если какая-либо компания или группа энтузиастов решит разрабатывать продукт на базе этой архитектуры. Я открыт к взаимодействию. Если Вы заинтересованы в участии - пишите предложения в комментариях, или на e-mail: support[X]emercoin.com (замените [X] на известный символ).
Текущее положение дел
Соцсети в XXI веке стали значительным фактором общественной жизни, капитализация соответствующих компаний составляет сотни миллиардов долларов. Естественно, такой важный фактор всякие недобросовестные люди превращают в инструмент политической борьбы, пример тому - блокировка учётной записи президента США. По моему мнению - позор и дискредитация плюрализма мнений. Про менее известных людей, попадающих под раздачу, можно и не упоминать, им несть числа.
Мне лично известен один пользователь Фейсбука, у которого есть несколько учётных записей, и по мере блокировки одних - он продолжает писательство с других, и так по кругу.
Последней каплей, переполнившей лично моё терпение, стал факт блокировки очередного канала в Телеграм - системе, которая себя позиционирует как неблокируемая, с end-to-end шифрованием и тп.
Да, мне могут возразить, что мол и поделом, и канал есть за что блокировать. Но факт налицо - блокировки там не только возможны, но и применяются, и существование Вашего канала - просто добрая воля соответствующей корпорации.
Да и end-to-end шифрование там.. Вам конечно заявляют, что оно - есть. А есть ли на самом деле? Вы имеете возможность анализировать исходные коды Телеграм-клиента? И собрать клиента из исходников, дабы убедиться, что пользуетесь программой без закладок? Используете такой? Нет? Скачиваете готовую аппликацию? Ну значит, просто верите корпорации. Она не обманет! И если говорит, что end-to-end шифрование есть, и его обойти нельзя - то по другому ж быть не может, не так ли? И это можно сказать не только о Telegram, а вообще практически обо всех мессенжерах и соцсетях!
UPD: Мне указали, что клиента Телеграм собрать можно, так что вычеркнут неверный параграф выше. Тем не менее, проблема блокировки канала (что толкнуло меня на эту идею) остаётся.
Предпосылки
Глядя на окружающую действительность я вижу, что хорошей неблокируемой соцсети или системы передачи сообщений и нет. Есть анонимные мессенжеры, например тот же Tox или Jabber. Но это мессенжеры, а не соцсети, то бишь не системы публикации. Есть федеративная соцсеть Mastadon, где можно публиковать посты и отправлять приватные сообщения. Но там, насколько я понимаю, нет доказуемого end-to-end шифрования, и доказательства аутентичности сообщений. И по любому, здесь пользователь регистрируется на некоем сервере и тот является хранителем его учётной записи и тп. И миграция на другой требует изменения учётной записи и тп. Есть ещё близкий по духу проект nostr, но там нет нормального PKI и механизма поиска серверов (там они называются relay), что усложняет систему, и делает её уязвимой против атак "человек посередине".
Хотелось бы иметь некую систему, которая обеспечивает:
- Принципиальное отсутствие глобальной цензуры. Некто имеет возможность цензурировать, но только у себя локально. И другие сами решают, принимать ли результаты цензуры этого деятеля, или нет.
- Работу системы как в режиме мессенжера, так и в режиме публикации.
- Сокрытие от читателей IP-адреса отправителя.
- Криптографическое доказательство авторства сообщений.
- В режиме мессенжера - доказуемое e2e (end-to-end) шифрование, без возможности внедрения "человека посередине", который перешифровывает сообщения и вторгается в переписку.
- Высокую надёжность - то есть защиту от технических сбоев, блокировок, или волюнтаристских решений, воздействующих сразу на всю сеть.
- Открытость архитектуры. Возможность пользователям разработать своё ПО для участия в системе, а также возможность аудита чужого ПО.
- Независимость от серверов, то есть возможность по ходу дела менять сервера, вышедшие из доверия, а то и из бизнеса на другие, без изменения истории постов, пользовательсокого ID, и подобной учётной информации.
Архитектура
Для достижения вышеуказанных целей, предполагается:
Сделать компоненты взаимно независимыми, с высокой избыточностью, то бишь дублированием функционала несколькими участниками.
Использовать блокчейн для организации взаимодействия между компонентами, и инфраструктуры публичных ключей (PKI). Блокчейн здесь хранит учётную информацию о пользователе, то бишь является средой хранения и достоверной доставки сервер-независимой учётной записи.
Предлагаемая архитектура состоит из трёх подсистем:
1. Клиентское ПО (далее - клиент). Это может быть бинарная программа-аппликация, или WEB-страница, содержащая JavaScript, исполняющий функции клиентского ПО. С помощью этого ПО пользователи обмениваются сообщениями, публикуют свои статьи, и читают чужие. Клиент коммуницирует с одним или несколькими серверами (из имеющегося множества), которые он выбрал для взаимодействия. Прямой коммуникации между клиентами не предусматривается. Повторю: клиент взаимодействует не со всеми серверами, а только с некоторыми, куда он отправляет свои публикации и откуда получает приватные сообщения.
2. Серверное ПО. Эти системы - хранилища сообщений. Они принимают сообщения на хранение, и выдают соответствующему клиенту. Сервера не взаимодействуют друг с другом, и не знают ничего друг о друге. Каждый - независим, как пчела в рое. Предполагается, что в системе существует много серверов. Их количество неограничено.
3. Записи в блокчейне Emer. В подсистеме emerDNS хранится запись пользователя, которая содержит:
Имя пользователя в качестве доменного имени системы emerDNS, например dns:alice.emc. Также возможно создание отдельной TLD-зоны для этой системы, если в том возникнет резон.
В ресурсной записи TLSA - хранится публичный ключ пользователя. В поле "Selector" можно хранить версию алгоритм и крипто-протокола для подсистемы открытых ключей, которым будем подписывать и шифровать сообщения, а в поле "Matching type" - алгоритм и крипто-протокола симметричного шифрования. Например, связка ED25519+AES может иметь версию (1,1).
В ресурсной записи SRV - хранится список серверов (доменные имена и порты), с которыми данный пользователь взаимодействует. Пример доменной записи в emerDNS, иллюстрирующий сказанное выше:
SRV=10:10:sites.emc:8001,50:50:example.com:8080|TLSA=0:1:1:b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9
В данном примере наш гипотетический пользователь alice заявляет на весь мир, что он взаимодействует с серверами sites.emc:8001, example.com:8080, а его публичный ключ ED25519 - это b063..07b9.
Использование блокчейна Emer позволяет решить проблему надёжной и достоверной доставки информации о пользователе всем заинтересованным. А использование подсистемы emerDNS позволяет изолировать запросы от клиента данной сети от запросов к кошельку через JSON API. И даже клиент с уязвимостью не сможет получить доступ к балансу кошелька, вывести монеты или сделать другие неприятные дейстия. Кроме того, при использовании emerDNS клиент может сам решать (на основе конфигурации) - использовать ли ему локальную Эмер-ноду для доступа к информации об участниках сети, или же он верит внешнему серверу - находящемуся в своей доверенной сети, или публичному серверу, поддерживаемому сообществом Emercoin или OpenNIC.
Алгоритмы взаимодействия
Регистрация пользователя
Для создания учётной записи, пользователь должен создать в системе emerDNS запись, содержащую:
- Свой username в качестве доменного имени emerDNS
- Список серверов, с которыми он будет взаимодействовать в ресурсной записи SRV
- Свой публичный ключ в реурсной записи TLSA.
Пример такой записи рассмотрен выше.
После отправки сообщения в блокчейн-сеть Emer, и первого подтверждения сети (примерно 10 мин), пользователь может работать с соцсетью Swarm.
Публикация поста в соцсеть
Пусть пользователь alice решил создать публичный пост. Для этого он пишет пост, подписывает его приватным ключом, связанным с публичным из записи TLSA, и отправляет своим серверам, в нашем примере - sites.emc:8001, example.com:8080.
Каждый сервер, получив сообщение, делает следующее:
- Из сообщения извлекает имя отправителя, в нашем случае - alice.
- Из emerDNS посредством DNS-запроса извлекает значение TLSA для alice, где получает публичный ключ (b063..07b9) и ID алгоритма подписи (1) в поле "Selector".
- В соответствии с алгоритмом - валидирует подпись. Если инвалидна - игнорирует сообщение.
- Далее, сервер извлекает из emerDNS значение записи SRV, и убеждается, что он сам есть в списках серверов для данного пользователя. Если нет - снова игнорирует запись.
- Если проверки прошли - то добавляет сообщение в хранилище сообщений для этого пользователя.
Если сервер недоступен - он не получает соответствующего сообщения. Возможно - в будущем отправитель сможет дослать соответствующее сообщение, когда сервер снова станет доступен. Или удалить ненадёжный сервер из своего списка в emerDNS.
Чтение чужого поста
Пусть пользователь bob решил прочесть публичные сообщения от пользователя alice. Для этого он:
- Делает запрос в emerDNS (в свою локальную копию блокчейна) на ресурсную запись SRV для alice, и извлекает оттуда список серверов, хранящих сообщения от alice.
- У этих серверов - запрашивает новые сообщения (скажем, сообщает серверу, что сообщения до даты такой-то пересылать не надо).
- При получении новых сообщений - для каждого из них проверяет аутентичность, для чего - валидирует цифровую подпись сообщения на публичном ключе alice, который он получает в emerDNS в ресурсной записи TLSA от alice.
Таким образом, если какой-то из серверов был недоступен либо при отправке, либо при получении сообщения, если оставался хотя бы один работоспособный - сообщение будет опубликовано и доставлено всем заинтересованным читателям. А потом, когда вышедший из строя сервер снова будет онлайн, отправитель (в нашем случае alice) сможет загрузить туда своё сообщение, и целостность постов будет восстановлена.
Владелец некоего сервера может удалять сообщения отправителя на своём сервере, или даже отказать этому отправителю в обслуживании. Но тогда другие копии сообщений будут храниться в других серверах, и читатели их всё равно получат. А отправитель далее сможет удалить тот сервер из списка своих серверов в emerDNS, и тем самым прекратить взаимодействие с серверм, который вышел из доверия.
Отправка комментария
Пользователь bob может отправить специальное сообщение - комментарий к посту от alice. Для этого он:
Создаёт сообщение от своего имени (bob), и подписывает своим приватным ключом, связанным с публичным в его записи TLSA.
Из emerDNS извлекает список серверов (ресурсная запись SRV) для alice, и отправляет им свой комментарий. Комментарий имеет ссылку на оригинальный пост от alice.
Каждый сервер, получивший комментарий, делает проверки:
- Из комментария Боба извлекает ссылку на статью Алисы и убеждается, что статья имеется в его хранилище. Если нет - комментарий игнорируется.
- Из комментария Боба извлекает имя пользователя bob, и для него делает запрос в emerDNS на получение ресурсной записи TLSA Боба.
- Извлекает из ресурсной записи TLSA публичный ключ Боба, и им валидирует сообщение. Чем удостоверяется, что комментарий действительно отправил Боб, и тот для валидной статьи от Алисы.
- Если все проверки прошли - добавляет комментарий.
Отправка приватного сообщения
Пользователь bob может отправить приватное сообщение alice. Для этого он:
- Создаёт сообщение для alice.
- Делает запрос в emerDNS, получает публичный ключ alice из её TLSA-записи.
- Шифрует сообщение для alice на её публичном ключе.
- Подписывает это сообщение своим приватным ключом.
- Делает запрос в emerDNS, получает список серверов alice из её SRV-записи.
- Отправляет сообщение для alice на сервера, с которыми она взаимодействует.
Каждый сервер, получив приватное сообщение:
- Делает запрос в emerDNS для публичного ключа Боба (запись TLSA).
- Проверяет подпись сообщения, чем убеждается, что оно - от Боба.
- Извлекает имя получателя (alice) из сообщения, и делает запрос для ресурсной записи SRV, откуда извлекает список серверов.
- Проверяет, входит ли он сам в этот список. Если да - то оставляет сообщение для alice у себя.
Примечательно то, что вполне нормальна ситуация, когда alice до получения данного сообщения вообще никогда не посещала этот сервер. Но раз она его включила сервер в свой список - то когда-нибудь планирует посетить, и забрать сообщения.
Далее, alice присоединяется к серверу и забирает накопившиеся сообщения. Напомним, что они - зашифрованы!
Для каждого сообщения, Алиса:
- Делает запрос в emerDNS для публичного ключа Боба (запись TLSA).
- Проверяет подпись сообщения, чем убеждается, что оно - от Боба.
- Если проверка прошла - то Алиса расшифровывает сообщение своим приватным ключом, и читает его.
Таким образом возникает доказуемое end-to-end шифрование, и внедрение "человека посередине" невозможно. За счёт неизменности блокчейна, Алиса всегда получает корректный публичный ключ Боба, и Мэллори (человек посередине) не может подменить сообщение, и отправить его от имени Боба. Также Мэллори не может преподнести Бобу свой публичный ключ, выдав его за публичный ключ Алисы. Ибо Боб извлекает ключи из локальной копии блокчейна, и что туда Алиса когда-то внесла - то там и будет.
Резюме
Предложенная роевая архитектура решает все задачи, заявленные в разделе "Предпосылки". Она имеет высокую масштабируемость, и надёжность, так как не имеет единой точки отказа (SPOF). Выход из строя нескольких серверов в худшем случае создаст временные проблемы пользователям, которые используют только это подмножество серверов. И даже в этом случае, пользователь легко меняет список серверов в своей SRV-записи в блокчейне, и после подтверждения блока - отправляет свои посты на новые сервера. И все читатели тут же получают доступ к постам.
Соответственно, появление или выход из бизнесов каких-либо серверов не влияет на пользовательскую запись, и для абонентов данного пользователя не ощущается никак.
Система swarm напоминает топор, которы служит семье 100 лет, и в котором пять раз меняли обух, и десять раз - топорище.
Монетизация
Возможно, владельцы серверов захотят получать какие-то деньги от пользователей - почему б и нет? Пчелу тоже надо кормить, в конце концов!
Вполне разумным представляется вариант, когда сервер получает плату за хранимые данные, скажем $1/GB/год. Платёж также может быть отправлен с помощью платежа той же системы Emer, в Emercoin. Но платность или бесплатность того или иного сервера - это его выбор, никак не влияющий на другие сервера.
Мысли об имплементации
Представляется разумным время сообщения определять временем отправителя. У всех часы могут идти по разному. Тогда получатель Боб, запрашивая у сервера свежие сообщения от Алисы, должен запрашивать "после такой-то даты по времени Алисы".
Для больших файлов (картинки и тп) - имеет смысл хранить файл в некой общей директории с именем, которое есть крипто-хеш от файла. А реальные файлы - делать hard-линками на данный файл. Это обеспечит дедуплицирование картинок и тп. Время от времени можно удалять файлы, у которых счётчик hard-линков стал равен единице.
Структура сообщений. Так как сообщения выглядят простыми, то не вижу смысла для них применять JSON, XML и прочие структурные штуки. Достаточно формата e-mail сообщений rfc-822, c полями типа
ключ: значение
то есть имеем заголовок типа e-mail, где каждая строка описывает нужную сущность (from, to, signature, msg-type), потом пустая строка, и далее - бинарное сообщение.
ID сообщений. Наверное разумно в качестве ID сообщения использовать хеш sha256 от всего сообщения, включая заголовок.