162 / 736NOSTR

Nostr

Публикации и идентичность без привязки к одному приложению

В обычной социальной сети учётной записью управляет её оператор. Nostr разделяет идентичность, приложение и серверы, передающие публикации. Поэтому можно сменить приложение и продолжить пользоваться прежним ключом. Но это не гарантирует доставку каждой публикации или конфиденциальность любого сообщения.

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

Анна находит в Nostr авторов, за которыми хочет следить. Со временем приложение перестаёт её устраивать. Если безопасно использовать тот же приватный ключ или подключённое устройство подписи в другом приложении, идентичность можно сохранить. Публичный ключ позволяет другим узнавать Анну и проверять подписи; приватный — подписывать от её имени. Поэтому npub и nsec принципиально различаются. Согласно NIP-19, это представления публичного и приватного ключей в кодировке Bech32. NIP — пронумерованные документы, описывающие правила и расширения Nostr. Кодирование не является шифрованием: nsec — не безобидная ссылка на профиль, которой можно делиться с кем угодно. Сохранение идентичности также не гарантирует, что новое приложение найдёт все старые публикации или перенесёт каждую настройку. [2] [7]

Приложение, называемое клиентом, подписывает публикацию и отправляет её выбранным relay. Relay — сервер, который принимает сообщения, а затем хранит или пересылает их по собственным правилам. Приложение Петра подключается к таким серверам и запрашивает интересующие его публикации. Единого центрального сервера нет, как нет и обязанности копировать всё на каждый сервер. Технически обмен идёт через WebSocket, постоянно открытое соединение: EVENT передаёт сообщение, REQ создаёт подписку, а OK сообщает о принятии или отклонении. Даже положительный OK не подтверждает доставку Петру или вечное хранение. EOSE обозначает конец сохранённых результатов запроса; после этого подписка может продолжать получать новые сообщения. [1] [7]

Получив сообщение, приложение Петра проверяет, соответствует ли подпись указанному публичному ключу и остались ли подписанные данные неизменными. Это не доказывает правдивость текста или личность автора вне сети. Время создания тоже указывает автор, поэтому независимой временной меткой оно не является. Для интересующихся технической стороной: запись event содержит pubkey, created_at, kind, tags и content — ключ, время, тип, метки и содержание. SHA-256 вычисляет из строго определённого представления этих данных короткое контрольное значение id. Оно позволяет обнаружить изменение подписанных данных. Поле sig содержит Schnorr Signature по BIP340 на кривой secp256k1. Подпись говорит: «Эти данные подписал владелец соответствующего ключа», а не «Этому утверждению следует доверять». [1]

Длинный публичный ключ трудно запомнить. NIP-05 позволяет связать его с идентификатором, напоминающим адрес электронной почты. Приложение спрашивает соответствующий домен, какой ключ закреплён за именем, и сравнивает ответ с ключом профиля. Тем самым проверяется конкретная связь с доменом, но не автоматически настоящее имя, репутация или надёжность человека. Оператор домена может изменить привязку. Если Анна уже следит за человеком, определяющим должен оставаться исходный публичный ключ: передача того же имени другому ключу не должна незаметно менять того, за кем она следит. Псевдонимность означает использование постоянного обозначения вместо настоящего имени, а не гарантию анонимности. [3]

Петру необязательно скачивать все сообщения. Он отправляет фильтр, например для определённых авторов и типа публикаций. Разные условия одного фильтра соединяются правилом AND: должны выполняться все. Несколько допустимых значений одного условия — альтернативы OR; так же объединяются несколько фильтров в одном REQ. Достаточно соответствовать любому из этих фильтров. limit ограничивает начальную порцию сохранённых результатов, но не автоматически будущие сообщения подписки. NIP-01 использует в событиях и фильтрах шестнадцатеричный вид ключей, а не пользовательский формат npub. Пустая выдача может объясняться фильтром, выбранным сервером или его архивом. Она не доказывает, что публикации нет нигде. [1]

Анна меняет описание профиля и хочет показать новое. Поэтому Nostr различает правила хранения событий. Для заменяемых событий relay выбирает самую новую запись с той же парой pubkey и kind. У адресуемых событий добавляется значение метки d, позволяющее различать, например, документы одного автора. Если заменяемые записи имеют одинаковое время, рекомендуется оставить лексикографически меньший id — первый в порядке сортировки его записи. Временные события, называемые ephemeral, вообще не предполагают обязательного хранения. Это соглашения, и поведение серверов может различаться. Nostr поэтому не является реестром, в котором вся сеть согласует единственную неизменную историю. [1]

Анна замечает, что опубликовала то, что хотела оставить личным. NIP-09 позволяет отправить подписанный запрос на удаление. Перед его выполнением клиент должен проверить, что запрос и исходная публикация относятся к одному публичному ключу: посторонний не может удалить публикацию Анны, просто сославшись на неё. Сотрудничающие серверы и приложения могут убрать материал или перестать его показывать. Но запрос не удалит все копии, скриншоты и независимые архивы. Скрытие публикации в одном приложении также не означает, что другой сервер больше её не выдаёт. Поэтому важнее то, что вы публикуете, чем само наличие кнопки «Удалить». [4]

Публичную публикацию может прочитать любой, кто её получил: подпись сама по себе не скрывает содержание. Личные сообщения используют дополнительные правила. NIP-44 описывает шифрование содержимого, а NIP-17 — упаковку и доставку сообщений с дополнительными слоями защиты. Это не автоматическая анонимность: сетевые адреса, время обмена и поведение приложения по-прежнему могут раскрывать сведения. Такое шифрование также не обеспечивает forward secrecy — защиту старых разговоров при последующей утечке долговременного ключа. Получив нужный приватный ключ и ранее записанные зашифрованные сообщения, можно прочитать и прошлую переписку. Проверяйте, какие расширения действительно поддерживает приложение: слово «Nostr» само по себе не описывает его конфиденциальность. [5] [6]

Для полной картины прочитайте эту статью вместе с Nostr Wallet Connect, Schnorr Signature, Private Key, Приватность в Bitcoin, Псевдонимность, SHA-256. На эту статью также ссылаются Nostr Wallet Connect, Network Effect.

DOC · 001Nostr — NIP-01: Basic protocolСпецификация DOC · 002Nostr — NIP-19: Encoded entitiesСпецификация DOC · 003Nostr — NIP-05: Internet identifiersСпецификация DOC · 004Nostr — NIP-09: Deletion requestsСпецификация DOC · 005Nostr — NIP-44: Encrypted payloadsСпецификация DOC · 006Nostr — NIP-17: Private messagesСпецификация DOC · 007fiatjaf — Original Nostr descriptionПервичный источник
Обновлено: Сначала источники · Не является инвестиционной рекомендацией