Децентрализация: часть первая, теоретическая

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

=> 🖼️ Децентрализация: часть первая, теоретическая

Картинку сделал Midjourney, и в этот раз даже превзошёл мои ожидания.

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

Первую вы сейчас читаете — она про теорию.

Вторая рассказывает о федиверсе. [1]

А третья про совсем децентрализованные сервисы [2] (почти) без серверов.

Чтобы описать суть децентрализации, надо сперва описать явление и проблематику централизации. В широком смысле слова, как подсказывает Капитан Очевидность, централизованный сервис — это такой сервис, у которого есть некий центр. Суть этого центра может быть не всегда очевидной — некоторые крупные сервисы распределены по множеству дата-центров по всему миру, и тем не менее, они остаются централизованными в главном аспекте: контроль над сервисом остаётся у одной организации, а иногда даже у одного человека.

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

[🖼️ image] [3] Не думаю, что тут нужна иллюстрация, на самом деле. И так всё понятно: один сервис — одна компания.

=> [1] Вторая рассказывает о федиверсе. | [2] А третья про совсем децентрализованные сервисы | [3] [🖼️ image]

Право выбора

А как было бы удобно, если бы соцсети и мессенджеры были подобны мобильным телефонам? Люди регистрируются у разных операторов, но могут друг с другом общаться почти на таких же условиях, как и внутри сети. Звучит немного фантастически: сложно представить, чтобы пользователи ватсаппа могли писать пользователям телеграма, не покидая своего привычного мессенджера. Приходится держать целую папку с мессенджерами. У меня, например, их всего восемь.

Хотя вообще-то идея о том, что пользователи разных серверов могут писать друг другу, реализована уже много лет назад в виде электронной почты. Каждый волен выбрать себе какой-нибудь почтовый сервис, который откроет ему возможность писать практически кому угодно. Одни пользователи выбирают условно бесплатные сервисы с рекламой на основе анализа писем. Другие предпочитают заплатить деньгами и пользоваться чем-то более приватным. Третьи вообще поднимают свой собственный сервер <зачёркнуто>и страдают, пытаясь сделать так, чтобы их письма не падали в спам. И вся эта сложная структура вполне нормально работает: пользователь пишет письмо, отправляет его своему почтовому серверу, а тот, в свою очередь, пересылает его дальше почтовому серверу собеседника.

[🖼️ image 1] [4] Центрального сервера нет, но пользователи могут общаться друг с другом, потому что отдельные серверы связаны между собой.

Тот же принцип задействован и при разработке концепции соцсетей без единого центрального сервера: вместо него множество серверов с независимым управлением, каждый из которых может взаимодействовать с другим серверами. Таким образом, не слишком усложняя жизнь пользователям, решаются проблемы модерации и хранения данных. Взаимодействие серверов друг с другом создаёт федеративность. А совокупность всех взаимосвязанных серверов называют федиверсом [5].

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

А вот что не очень классно — это целый зоопарк протоколов, с которыми придётся столкнуться, погружаясь в администрирование. Проект The Federation, например, насчитывает девять разных протоколов [6], которые используют федеративные соцсети для общения между серверами! (На самом деле, восемь, ибо Matrix, не считается, но об этом в следующем посте) При этом, готовых решений, реализующих хотя бы один протокол, ещё больше: какие-то ориентированы на текстовые посты, какие-то на фотки, какие-то на музыку и подкасты и т.п. И ни одно решение не поддерживает сразу все существующие протоколы. Зато некоторым этого количества протоколов мало, и они продолжают придумывать свои. Но среди них хотя бы есть лидер.

[🖼️ image] [7] XKCD [8] отлично описывает ситуацию.

=> [4] [🖼️ image 1] | [5] | [6] девять разных протоколов | [7] [🖼️ image] | [8]

Тотальная децентрализация без серверов

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

Вообще-то, можно. Пользователи могут связываться друг с другом напрямую. Подобная архитектура именуется peer-to-peer, сокращённо p2p. У подобных по-настоящему децентрализованных сервисов нет единого сервера, который бы хранил сведения о пользователях в принципе. Процесс регистрации в таком случае практически отсутствует и больше напоминает процесс создания ключей для криптокошелька.

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

[🖼️ image 2] [9] На самом деле, конечно, не совсем так, но принцип примерно похож. Серверов в идеале не должно быть совсем. Однако, есть проблемы и посерьёзнее. Такой подход позволяет без особых затрат доставлять информацию, но не хранить её в течение долгого срока. Когда мы пользуемся какой-либо соцсетью, мы просматриваем материалы, написанные разными людьми в разное время — иногда больше десяти лет назад. В децентрализованной сети же по определению не должно быть сервера, который мог бы хранить у себя такие данные. Да, можно хранить их у пользователей. Очевидно, что нет смысла хранить все архивы всех постов у всех пользователей вообще — логичнее дробить данные и сохранять их фрагментами, причём, разумеется, дублируя одни и те же данные у разных пользователей: пока один пользователь не в сети, данные можно получить и у другого. Решение, конечно, есть, но оно не идеальное, поскольку рано или поздно часть пользователей может отключиться насовсем, и если степень избыточности при дублировании данных оказалась низкой, то часть данных станет недоступной вместе с пользователями, хранившими их. А если же степень избыточности была высокой, то активные члены соцсети вынуждены хранить у себя гигабайты данных — тоже как-то нехорошо.

🧮

А можно и посчитать!

Мой архив активности инсты за скромные три года составил порядка 100 мегабайт, и это всего 40 постов и 85 сторис — у среднестатистического пользователя архив будет в два-три раза больше. Если хранить локально 30 таких архивов — свой и копии данных своих друзей — это до девяти лишних гигабайт. Не фатально, конечно, но всё же весьма накладно. И даже с таким подходом в почти любой момент времени порядка половины постов будут недоступны, потому что все, кто их хранит, закрыли приложения и выключили компьютеры.

💸

Занимательный факт: весь архив транзакций биткоина, т.е. весь его блокчейн, весит на текущий момент (декабрь 2024) более 630 гигабайт [10]. А это, фактически, только записи о переводах: в них очень мало инфы, что-то около 250 байт на одну транзакцию.

Хранение данных пользователей в тру-децентрализованных сервисах устроено плюс-минус одинаково: в основном, это распределённые хранилища данных на основе DHT [11], IPFS [12], BitTorrent [13] и Gossip [14], иногда с применением блокчейнов [15] и аналогичных технологий. Поскольку, так или иначе, какие-то данные приходится хранить на чужих устройствах, и при этом их надо защищать от подделок и несанкционированного доступа, всё доверие к данным упирается в шифрование. Поэтому в большинстве случаев регистрация в сервисе — это лишь генерация пары ключей и последующее анонсирование открытого ключа для других участников сети. А ещё некоторые из таких сервисов довольно неплохо ориентированы на анонимность участников.

Но обо всём этом продолжу, пожалуй, в следующих частях. Вторая, про федиверс, уже вышла и доступна здесь [16]. Третья, про peer-to-peer, тоже готова [17].

=> [9] [🖼️ image 2] | [10] более 630 гигабайт | [11] DHT | [12] IPFS | [13] BitTorrent | [14] Gossip | [15] блокчейнов | [16] доступна здесь | [17] тоже готова

А пока можно обсудить пост в комментариях в телеге [18] (централизованной) или в чятике в матриксе [19] (федеративном).

=> [18] в комментариях в телеге | [19] чятике в матриксе

Proxy Information
Original URL
gemini://gemini.danis.one/decentralized_pt_1_theory
Status Code
Success (20)
Meta
text/gemini
Capsule Response Time
488.055418 milliseconds
Gemini-to-HTML Time
13.394521 milliseconds

This content has been proxied by September (3851b).