Nostr — открытый протокол подписанных событий, которыми клиенты обмениваются через независимые ретрансляторы. Социальные сети — одно из применений; у протокола нет собственного блокчейна или общего консенсуса всех ретрансляторов.
Событие содержит pubkey, created_at, kind, tags, content, id и sig. NIP-01 получает id через SHA-256 из строго заданной сериализации и использует BIP340 на secp256k1. Клиент проверяет целостность и авторизацию ключом. created_at указывает автор; это не независимая отметка времени и не доказательство достоверности. [Nostr — NIP-01: Basic protocol] [fiatjaf — Original Nostr description]
Клиент публикует EVENT и подписывается через REQ по WebSocket. OK сообщает о приёме или отказе именно этого ретранслятора. EOSE завершает список сохранённых событий, но не обязательно подписку на новые. Ни одно сообщение не подтверждает получение адресатом, репликацию всей сети или постоянное хранение. [Nostr — NIP-01: Basic protocol]
Внутри фильтра событие должно выполнить все условия: автор и тип означают AND. Несколько фильтров в REQ объединяются через OR; достаточно одного. limit ограничивает начальный список, не количество будущих событий. Отсутствие результата может означать ограниченную историю ретранслятора, а не отсутствие события. [Nostr — NIP-01: Basic protocol]
Заменяемые события сравниваются по pubkey и kind, адресуемые — ещё и по тегу d. Новая версия может заменить старую; при равном времени выбирается лексикографически меньший id. Эфемерные события не предполагают хранения. Это правила ретрансляторов, а не неизменный глобальный архив; реализации могут различаться. [Nostr — NIP-01: Basic protocol]
NIP-19 использует Bech32 для отображения пользователю: npub обозначает открытый ключ, nsec — закрытый. Кодирование не является шифрованием. Передача nsec раскрывает секретный ключ, а не просто ссылку на профиль. События и фильтры NIP-01 используют шестнадцатеричные открытые ключи, не форму npub. [Nostr — NIP-19: Encoded entities]
NIP-05 связывает имя, похожее на адрес почты, с открытым ключом по ответу домена. Это подтверждает связь, а не реальную личность или честность. Клиент должен следить за исходным ключом: если домен назначит имени другой ключ, нельзя автоматически подменять им ранее выбранный профиль. [Nostr — NIP-05: Internet identifiers]
NIP-09 определяет просьбу автора удалить его события. Перед скрытием клиент должен проверить одинаковый открытый ключ оригинала и запроса. Ретрансляторы и клиенты могут обработать запрос, но протокол не удалит каждую загруженную или сохранённую копию. Удаление в одном интерфейсе не доказывает глобального стирания. [Nostr — NIP-09: Deletion requests]
NIP-44 определяет зашифрованный payload, а не полную систему личных сообщений; NIP-17 добавляет оболочки и правила доставки. Само NIP-44 не обеспечивает forward secrecy при последующей утечке ключа. Сетевые адреса, время и поведение клиента остаются важны даже при шифровании. Поддержку конкретных NIP нужно различать по приложениям. [Nostr — NIP-44: Encrypted payloads] [Nostr — NIP-17: Private messages]
Для полной картины прочитайте эту статью вместе с Nostr Wallet Connect, Schnorr signature, Приватный ключ, Приватность в Bitcoin, Псевдонимность. На эту статью также ссылаются Nostr Wallet Connect, Network Effect.