Как устроен Nostr и почему соцсеть без единого сервера вообще работает

Почти каждый децентрализованный протокол для соцсетей со временем превращается в монстра. ActivityPub тащит за собой тяжелые сервера Mastodon, где бан на одном узле отрезает тебя от половины аудитории. P2P-сети вроде Scuttlebutt упираются в проблемы синхронизации на мобилках и жрут батарею за полдня.

Создатель протокола Nostr (расшифровывается как Notes and Other Stuff Transmitted by Relays) пошел от обратного: выкинул блокчейны, выкинул сложные P2P-протоколы и оставил только криптографию и простые вебсокет-релеи.

В чем суть задумки

Nostr — это не готовая соцсеть или отдельное приложение. Это спецификация сетевого взаимодействия, которая умещается в пару десятков коротких документов (NIPs, Nostr Implementation Possibilities).

У вас нет логина, пароля или привязки к номеру телефона. Аккаунт — это пара криптографических ключей: приватный (secp256k1) и публичный. Публичный ключ служит вашим идентификатором, а приватным вы подписываете каждое действие.

Любое сообщение, статья, реакция или смена аватарки в терминологии протокола называется событием (event). По сути, это обычный JSON-объект:

{
  "id": "4376c65d2f23493d6050d0c393d01f50252a607d58eab305699c6811ea70017d",
  "pubkey": "9fe415e4177d13521649f80e4293097b540e555d34a14f4e2454b62412f93008",
  "created_at": 1672531199,
  "kind": 1,
  "tags": [],
  "content": "Привет, это тестовый пост в Nostr!",
  "sig": "250e938424f...подпись...4e8f9b"
}

Клиент формирует такой JSON, подписывает его вашим приватным ключом и отправляет по WebSocket на один или несколько серверов-ретрансляторов (relays).

Как работают релеи

Релей — это глупый сервер. Он не знает, кто вы, и ему все равно на логику вашего приложения. Его задача:

Принять JSON по вебсокету.
Проверить подпись автора.
Сохранить событие в базу (обычно SQLite или PostgreSQL).
Разослать событие подписчикам, которые запросили фильтр по вашему pubkey.

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

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

Главная инженерная проблема

В теории всё красиво: релеев много, цензуры нет. На практике возникает вопрос: как клиент читателя узнает, на какие именно релеи автор отправляет свои посты?

Если подписаться на 500 человек, опрашивать тысячи существующих релеев накладно. В сообществе прижилась модель Outbox (NIP-65). Автор публикует список релеев, в которые он пишет (write relays). Подписчик запрашивает этот список и подключается только к ним. Для оптимизации клиенты собирают пересечения и держат открытыми соединения всего с 10-15 серверами.

Что пишут на Nostr разработчики

Из-за простоты спецификации на Nostr начали строить вещи, далекие от обычного микроблогинга:

Клиенты вроде Damus (iOS), Amethyst (Android) или Coracle (Web) для общения в стиле Twitter.
Платформы для длинных статей (NIP-23), где посты хранятся в Markdown.
P2P-мессенджеры с шифрованием сообщений открытым ключом собеседника.
Системы авторизации на сайтах (NIP-07), когда браузерное расширение подписывает запрос вместо ввода логина и пароля.

Библиотеки для работы с протоколом есть практически под любой стек: Go, Rust, TypeScript, Python, Dart. Написать минимальный клиент, который подключается к релею и слушает поток постов, можно буквально за 30-40 строк кода.

Стоит ли копать глубже

Nostr не идеален. Здесь сложно организовать поиск без сторонних индексаторов, нет встроенного удаления данных (удаленный пост может навсегда остаться на упрямом релее), а синхронизация между несколькими клиентами иногда сбоит.

Но если вам интересен чистый, минималистичный сетевой дизайн без оверинжиниринга, репозиторий определенно стоит изучить. Начните со спецификации базовых событий в NIP-01, а готовые клиенты можно пощупать через каталог nostrapps.com.