Международный СММ

Nostr

Платформа · разбор собран по официальным страницам самой площадки и сервисов-помощников.

Обзор

Nostr — не площадка, а протокол. Название расшифровывается как Notes and Other Stuff Transmitted by Relays — «заметки и прочее, передаваемое через релеи». Сайт nostr.com описывает его так: «свободная и открытая сеть, которой никто не владеет и которую никто не контролирует».

Устройство простое и на нём держится всё остальное. Есть релеи — серверы, которые хранят и раздают сообщения. Есть клиенты — приложения, через которые люди читают и пишут. И есть ключи: открытый ключ работает как имя пользователя, закрытый — как пароль; именно ключи, а не компания, дают вам право на вашу личность. Поскольку личность принадлежит ключу, а не приложению, вы можете переходить между клиентами, сохраняя профиль, подписчиков и записи.

Технически всё сводится к одному типу объекта. Базовый документ протокола гласит: единственный существующий тип объекта — «событие» (event), подписи и ключи используют схему Шнорра на кривой secp256k1, а релей выставляет наружу websocket-точку, куда клиент шлёт три вида сообщений: EVENT для публикации, REQ для подписки на выборку и CLOSE для её закрытия.

Для справочника это значит вот что: у Nostr нет владельца, единой аудитории, рекламного кабинета, правил модерации и программы выплат. Дальше разбирается, что есть вместо них.

Кто здесь есть

Числа аудитории Nostr не существует — и не может существовать в привычном виде. Нет центрального сервера, который считал бы пользователей: есть множество независимых релеев, каждый из которых видит только своих.

Косвенно судить можно только по конкретным релеям. Клиент на nostr.com по умолчанию подключается к шести релеям и показывает их список прямо в интерфейсе: relay.nostr.com, relay.damus.io, nos.lol, nostr.bitcoiner.social, nostr.mom и relay.snort.social. Каталог релеев проект рекомендует смотреть на стороннем сервисе Nostr.watch, каталог клиентов — на nostrapps.com (страница о релеях, страница о клиентах).

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

Как начать

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

Отсюда следует главный риск, о котором предупреждает сам проект: закрытый ключ даёт полный доступ к аккаунту — с ним можно писать от вашего имени, менять профиль и отправлять сообщения; если ключ потерян и копии нет, кнопки «забыли пароль» не существует. Практический совет проекта: не вставляйте закрытый ключ в каждое приложение подряд — безопаснее подписывающее расширение браузера или удалённый подписыватель.

Проверяемого имени, похожего на «галочку», добиться можно: отдельный документ протокола описывает привязку ключа к домену. Клиент берёт из профиля адрес вида имя@домен, запрашивает https://домен/.well-known/nostr.json?name=имя и сверяет полученный открытый ключ с ключом автора записи. Для компании это и есть способ подтвердить, что аккаунт действительно её: подтверждение даёт контроль над доменом, а не решение модератора.

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

Что можно публиковать

Форматы задаются «видами» событий, а виды описаны в отдельных документах — NIP (Nostr Implementation Possibilities). Их перечень ведётся в открытом репозитории и включает, среди прочего: короткие заметки и ветки обсуждений, длинные материалы, изображения и видео, прямые эфиры и «спейсы», опросы, календарные события, вики, торренты, списки, закладки и цитаты (перечень NIP).

Ограничений длины и размера у протокола нет — они есть у релея, и релей обязан их объявлять. Документ о сведениях о релее описывает поля: max_message_length — предельный размер входящего JSON в байтах (он же фактически ограничивает размер события), max_content_length — предельное число символов в поле содержания, max_event_tags — предельное число меток, max_subscriptions — число одновременных подписок на одном соединении, max_limit — потолок числа событий в ответе на один запрос.

Так это выглядит на практике. Релей relay.damus.io на дату проверки объявляет предел сообщения 1 000 000 байт, 200 подписок и потолок выборки 500 событий; релей nos.lol — 131 072 байта, 20 подписок, те же 500 событий; релей relay.nostr.com — 131 072 байта, 200 подписок, 500 событий. Числа принадлежат каждому релею в отдельности, и на другом релее они будут другими.

Запретов по содержанию у протокола нет. Есть техническая разметка: отдельный документ описывает пометку чувствительного содержания, другой — жалобы на события, третий — запрос на удаление. Обратите внимание на слово «запрос»: удаление в Nostr — это просьба к релеям, а не гарантия. Что именно принимать и хранить, решает владелец релея.

Как расти

Алгоритмической ленты в протоколе нет. Что показать пользователю, решает клиент, а какие события отдать — релей. Клиент на nostr.com показывает это прямо: в его интерфейсе есть варианты ленты «подписки», «глобальная» и «своя», а ниже — список подключённых релеев.

Отсюда практическое следствие, которое проект объясняет сам: если Nostr кажется медленным или пустым, дело может быть в релеях; часть релеев быстрые и надёжные, часть отключается и не отвечает, и добавление нескольких хороших релеев многое меняет. Рост в Nostr — это в первую очередь публикация в те релеи, где действительно есть читатели.

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

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

Путь к монетизации

Площадки нет — значит, нет и выплат от площадки. Зато есть прямые платежи между людьми, и они описаны в самом протоколе.

Механизм называется «зап» (zap) — платёж через сеть Lightning. Документ протокола вводит два вида событий: 9734 — запрос на зап, то есть обращение плательщика к кошельку получателя за счётом, и 9735 — квитанция, подтверждение кошелька получателя, что счёт оплачен. Ход такой: клиент берёт из профиля получателя адрес его платёжной точки, проверяет, что она поддерживает Nostr, отправляет туда подписанный запрос и получает счёт; после оплаты кошелёк публикует квитанцию. Смысл квитанции объяснён там же: она позволяет клиентам показывать платежи прямо в ленте — ради удовольствия или как средство борьбы со спамом.

Комиссии площадки в этой схеме нет — деньги идут от кошелька к кошельку. Но и гарантий площадки нет тоже: за доставку платежа отвечают сеть Lightning и выбранный вами провайдер кошелька.

Кроме запов перечень протокола содержит и другие денежные механизмы: цели сбора (zap goals), значки, кошельки Cashu и «натзапы», удалённое подключение кошелька и события заказов между людьми. Каждый из них реализуется клиентом по желанию.

Инструменты и автоматизация

«Официального API» у Nostr нет по той же причине, по которой нет владельца: сам протокол и есть интерфейс. Любая программа может открыть websocket к релею и работать с ним напрямую (базовый документ). Ключей разработчика, заявок на доступ и модерации приложений не существует.

Перед тем как строить сервис, стоит прочесть предупреждение из самого перечня: «NIP здесь — не контрольный список протокола. Ничто не заставляет никакую программу реализовывать какой-либо NIP. Каждое приложение выбирает подмножество, нужное для его задачи». Это значит, что нельзя рассчитывать на функцию только потому, что она описана: нужно проверять, поддерживает ли её конкретный релей. Способ проверки предусмотрен: релей отдаёт по HTTP документ со списком поддерживаемых NIP, названием программы, версией, контактами и ссылкой на свои условия обслуживания. Три названных выше релея объявляют одинаковый набор: все три работают на программе strfry и поддерживают NIP 1, 2, 4, 9, 11, 28, 40, 45, 70 и 77.

Из готовых средств проект называет расширения браузера для подписи и удалённые подписыватели, а также собственный подписыватель Pomegranate. Каталоги клиентов и релеев ведутся вне протокола — на nostrapps.com и Nostr.watch (страница о клиентах, страница о релеях).

Ограничения и правила

Кому подходит

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

Подходит проектам, связанным с биткойном и Lightning: платежи встроены в протокол в виде запов, и это самая развитая часть его денежной механики.

Не подходит, если вам нужны предсказуемый охват и отчётность: измерять здесь нечего — ни площадки, ни статистики, ни рекламного кабинета. Не подходит для массовой рассылки и «продвижения»: релей вправе потребовать плату, вход или доказательство работы и отключить вас без объяснений. И не подходит, если в организации требуется договор с поставщиком услуг: такой стороны у протокола нет.

Проверенные факты из базы

Краткие проверенные данные, на которые опирается разбор.

Что это за площадка

площадка описывает себя так: «Nostr is a free and open-source protocol for social media and other things - controlled by users, not platforms.»

самоописание: это заявление площадки о себе, не независимая оценка

Nostr (Notes and Other Stuff Transmitted by Relays) описан как свободная и открытая сеть, которой никто не владеет и которую никто не контролирует; релеи хранят и раздают сообщения, клиенты дают их читать и писать

Это протокол, а не площадка: владельца, рекламного кабинета и программы выплат у него нет

единственный тип объекта — событие (event); подписи и ключи используют схему Шнорра на кривой secp256k1; релей выставляет websocket-точку, клиент шлёт EVENT для публикации, REQ для подписки и CLOSE для её закрытия

Базовый документ протокола NIP-01

С чего начать

у порога входа в nostr нет единого владельца правил: «Nostr (Notes and Other Stuff Transmitted by Relays) is a free and open network that nobody owns or controls»; свод предложений по протоколу оговаривает то же самое о себе: «NIPs listed here are not a protocol checklist. Nothing forces any software to implement any NIP»

цитаты дословные, язык источника английский. Вторая — из README свода NIP: https://raw.githubusercontent.com/nostr-protocol/nips/master/README.md. Практический вывод для читателя: единых условий входа, обязательных для всей сети, не существует; условия ставит каждое отдельное реле и каждое приложение, и они разные

реле вправе закрыть запись, потребовать вход по подписи или доказательство работы: в перечне ограничений NIP-11 названы «auth_required», «restricted_writes», «min_pow_difficulty», «payment_required»; «Your client should expect that requests exceed these practical limitations are rejected or fail immediately»

цитаты дословные, язык источника английский, орфография источника сохранена. Заявки, приглашения и модерации на уровне протокола нет; всё перечисленное — свойства отдельного реле, и узнать их можно, запросив у реле его документ сведений

Аккаунт и доступ

аккаунт — это пара ключей, а не запись у владельца площадки: «Every account has Nostr keys. Your public key is like your username and can be shared with anyone. Your private key is like your password and must be kept safe. These keys give you ownership of your identity, rather than a company owning it for you»

цитата дословная, язык источника английский. Ни регистрации, ни подтверждения личности, ни одобрения для получения ключей не требуется: пара ключей порождается на устройстве. Необязательное проверяемое имя вида имя@домен описано отдельным NIP-05

у аккаунта пара ключей: открытый работает как имя пользователя, закрытый — как пароль; личность принадлежит ключу, а не приложению, поэтому клиента можно менять, сохраняя профиль и подписчиков

Регистрации, подтверждения почты и модерации заявки нет

при потере закрытого ключа без резервной копии восстановления доступа нет: кнопки «забыли пароль» не существует

Проект советует не вставлять закрытый ключ в каждое приложение, а использовать расширение-подписыватель или удалённый подписыватель

проверяемое имя вида имя@домен: клиент запрашивает https://домен/.well-known/nostr.json?name=имя и сверяет полученный открытый ключ с ключом автора записи

Для компании это способ подтвердить аккаунт контролем над доменом, а не решением модератора

Что можно публиковать

перечень NIP описывает, среди прочего: короткие заметки и ветки, длинные материалы, изображения и видео, прямые эфиры и спейсы, опросы, календарные события, вики, торренты, списки, закладки и цитаты

Перечень NIP — не обязательства: ничто не заставляет программу реализовывать какой-либо NIP

Как здесь платят

Кого принимают. порога по подписчикам, просмотрам или числу публикаций у платежей нет: запы идут напрямую от человека к человеку через сеть Lightning, а условием служит только наличие у получателя кошелька с адресом lnurl — «Client calculates a recipient's lnurl pay request url from the zap tag on the event being zapped, or by decoding their lud16 field on their profile»

цитата дословная, язык источника английский. Порог нуля: ни числа подписчиков, ни часов просмотра, ни срока жизни аккаунта NIP-57 не требует. Предельные суммы задаёт кошелёк получателя полями «minSendable» и «maxSendable», а не сеть

комиссии сети нет и быть не у кого: деньги идут мимо протокола, через кошелёк получателя, и nostr в расчёте не участвует — NIP-57 описывает лишь два вида событий, запись запроса и запись расписки: «9734 is a zap request… 9735 is a zap receipt, representing the confirmation by the recipient's lightning wallet that the invoice issued in response to a zap request has been paid»

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

платежи между людьми описаны в протоколе как «запы» через сеть Lightning: событие 9734 — запрос на зап, событие 9735 — квитанция кошелька получателя об оплате счёта

Комиссии площадки в схеме нет: деньги идут от кошелька к кошельку; ответственность за доставку — у сети Lightning и провайдера кошелька

перечень NIP содержит также цели сбора (zap goals), значки, кошельки Cashu и натзапы, удалённое подключение кошелька и события заказов между людьми

Каждый механизм реализуется клиентом по желанию

Сколько стоит

протокол не берёт денег, но отдельное реле может: NIP-11 предусматривает поля для платы — «Relays that require payments may want to expose their fee schedules»: «fees»: «admission» (плата за допуск), «subscription» (подписка с полем «period»), «publication» (плата за публикацию, с указанием видов событий); в списке ограничений реле есть признак «payment_required»

цитаты дословные, язык источника английский. Числа задаёт каждое реле само, поэтому единой цены входа у сети нет. Пример, приведённый в самом NIP-11 как образец ответа реле nostr.wine: «fees»: «admission»: ({«amount»: 18888000, «unit»: «msats»}) — это заявление реле в примере документа, а не наш подсчёт и не обещание текущей цены

Ограничения и лимиты

релей объявляет свои ограничения в документе сведений: max_message_length (размер входящего JSON), max_content_length (символы в поле содержания), max_event_tags, max_subscriptions, max_limit; возможны требования аутентификации и доказательства работы

Документ NIP-11; у протокола собственных ограничений длины и размера нет

релей relay.damus.io на дату проверки объявляет предел сообщения 1 000 000 байт, 200 одновременных подписок и потолок выборки 500 событий; программа strfry

Число принадлежит этому релею, на другом оно другое

релей nos.lol объявляет предел сообщения 131 072 байта, 20 подписок и потолок выборки 500 событий

Измерено запросом документа сведений о релее

релей relay.nostr.com объявляет предел сообщения 131 072 байта, 200 подписок и потолок выборки 500 событий; заявленные NIP — 1, 2, 4, 9, 11, 28, 40, 45, 70, 77

Тот же набор NIP объявляют damus.io и nos.lol

Ограничения

единых правил нет: что принимать и хранить, решает владелец релея; протокол лишь предусматривает ссылку на условия обслуживания в сведениях о релее

Удаление описано как «запрос на удаление», исполнение не гарантировано

средства против спама: релей может требовать доказательство работы заданной сложности или аутентификацию; часть релеев платные, что, по объяснению проекта, снижает спам

Nostr.watch рекомендован проектом как каталог релеев, nostrapps.com — как каталог клиентов

файл для роботов nostr.com разрешает обход сайта всем агентам

Проверено отдельно

Правовое

репозиторий перечня NIP опубликован без указанной лицензии

Юридического лица, с которым можно заключить договор, у протокола нет

Программный доступ

клиент на nostr.com по умолчанию подключается к шести релеям: relay.nostr.com, relay.damus.io, nos.lol, nostr.bitcoiner.social, nostr.mom, relay.snort.social

Список виден прямо в интерфейсе

отдельного «официального API» нет: интерфейсом служит сам протокол, любая программа может открыть websocket к релею; ключей разработчика и модерации приложений не существует

Проверять поддержку конкретных возможностей нужно по документу сведений о релее

Языки

язык интерфейса главной страницы: en

Язык взят из атрибута разметки, версии — из hreflang

Раздел каталога: все похожие Смотрите также: указатель каталога · сравнение планировщиков · подбор по ситуации · ограничения площадок