O protocolo Nostr, explicado em linguagem simples

Um protocolo é um conjunto de regras para como programas se comunicam entre si. Uma plataforma é uma empresa que executa esses programas em seu nome. Twitter é uma plataforma. Email é um protocolo. Nostr é um protocolo.

A distinção importa porque protocolos e plataformas têm diferentes modos de falha, diferentes estruturas de custo e futuros diferentes. Este guia explica o que torna Nostr um protocolo especificamente, o que isso significa na prática, e por que o design permanece pequeno propositalmente.

TL;DR. Nostr é um protocolo de mensagens pub/sub com assinaturas criptográficas. Define um formato de evento pequeno e uma forma simples para clientes enviar e receber esses eventos via relays. Nenhuma empresa é dona dele. Qualquer um pode escrever um cliente, executar um relay ou propor extensões. A especificação principal cabe em algumas páginas.

Quando estiver pronto, pegue seu endereço @nostr.blog →

O que um protocolo realmente é

Email é uma boa comparação. Quando você envia um email do Gmail para o Outlook, o Gmail não precisa da permissão do Outlook. Ambos os serviços falam SMTP (o protocolo de email), e SMTP define tudo o que é necessário para um servidor de mail passar uma mensagem para outro. Os servidores são de empresas diferentes. O protocolo é um acordo neutro.

Nostr funciona da mesma forma. Um evento Nostr (um post, um like, um follow) é um objeto JSON com uma forma específica definida no protocolo. Um relay é qualquer servidor que concorda em aceitar, armazenar e reencaminhar eventos conformes com essa forma. Quaisquer dois clientes que falem Nostr podem interagir através de qualquer relay que fale Nostr, independentemente de quem fez qualquer um dos três.

O protocolo é um acordo neutro. As implementações são livres para ser qualquer coisa.

A especificação Nostr, nas frases mais poucas

Três regras cobrem quase tudo.

1. Um event é um objeto JSON com id, pubkey, created_at, kind, tags, content, sig. O id é um hash dos outros campos; o sig é uma assinatura Schnorr sobre o id usando a contrapartida privada do pubkey.
2. Um relay aceita events válidos sobre WebSocket e serve subscriptions que filtram events por autor, kind, tag ou tempo.
3. Um cliente assina events e os publica para relays; lê events ao se inscrever em relays com filters.

Esse é o protocolo principal. Toda funcionalidade avançada (artigos longos, zaps, DMs, comunidades, listas) é uma extensão que se encaixa nesse frame sem mudá-lo.

Por que o protocolo permanece pequeno

A maioria dos protocolos cresce por acumulação. Cada caso de uso adiciona à especificação; cada década a especificação é maior que a década anterior. HTTP agora tem centenas de páginas. Email cresceu de um punhado de RFCs para uma floresta. Nostr evitou isso por design.

O mecanismo é NIPs (Nostr Implementation Possibilities). Novas funcionalidades não são adicionadas à especificação principal; elas são propostas como NIPs opcionais. Clientes implementam os NIPs que se importam. Outros clientes os ignoram. Um NIP popular se torna parte do protocolo prático porque implementações suficientes o falam; um NIP impopular desaparece sem cerimônia.

Isso significa que o núcleo é para sempre pequeno (os invariantes importantes: events assinados, relays abertos, identidade portável) e as bordas são para sempre flexíveis (novas funcionalidades evoluem sem quebrar clientes existentes). Um cliente Nostr de 2022 ainda funciona em 2026 porque o núcleo não mudou; ele apenas faz menos coisas que clientes mais novos.

Protocolo vs plataforma, concretamente

Cinco diferenças práticas que você pode sentir como um usuário.

Identidade. Em uma plataforma, sua conta é de propriedade da empresa. Em um protocolo, sua conta é uma identidade criptográfica que você possui. Ninguém pode tirá-la de você.

Dados. Em uma plataforma, seus posts vivem no banco de dados deles. Em um protocolo, seus posts vivem em múltiplos relays independentes. Se um desaparecer, os outros ainda têm.

Velocidade de funcionalidades. Em uma plataforma, funcionalidades são lançadas quando a empresa decide. Em um protocolo, funcionalidades são lançadas quando qualquer implementador as escreve. Isso é mais lento em alguns aspectos (sem roadmap central) e mais rápido em outros (muitos experimentos em paralelo).

Monetização. Em uma plataforma, a empresa captura toda a monetização. Em um protocolo, monetização é o que usuários e implementadores concordam. Nostr tem zaps (dicas peer-to-peer sobre Lightning) porque isso se encaixa na cultura; uma comunidade de protocolo diferente pode chegar a normas diferentes.

Modo de falha. Uma plataforma pode desaparecer completamente. Um protocolo não; enquanto um implementador permanecer ativo, o protocolo vive. Nostr é projetado para que até mesmo se fiatjaf (o autor original) desaparecesse amanhã, a rede continuaria funcionando sem mudanças.

O que o protocolo explicitamente não faz

Cinco coisas deixadas de fora da especificação propositalmente.

Moderação. O protocolo não decide qual conteúdo é aceitável. Cada relay tem suas próprias regras; cada cliente tem seus próprios filters; cada usuário tem sua própria lista de silenciados. Moderação acontece nas bordas, não no núcleo.

Busca. Não há busca definida pelo protocolo. Alguns relays indexam texto; outros não. Clientes que querem busca confiam em relays capazes de busca ou executam sua própria indexação. A ausência é deliberada; ela mantém o protocolo neutro sobre o que é encontrado.

Ranking. Nenhum feed "Para você". Nenhuma ponderação de engajamento. Clientes exibem events por timestamp por padrão; qualquer outro ordenamento é uma decisão de nível de cliente, não de protocolo.

Descoberta. Nenhum mecanismo de recomendação. Encontrar novas contas para seguir é uma funcionalidade de cliente, não de protocolo. Alguns clientes investem pesadamente nisso (Primal); outros deixam para os usuários (Damus).

Recuperação. Nenhuma redefinição de conta. Perca a chave privada, perca a conta. O protocolo poderia incluir rotação de chave mas não inclui, porque os tradeoffs são reais e a comunidade não concordou em um mecanismo específico ainda. Esta é uma área em andamento (rascunhos NIP-26, NIP-41).

Cada omissão é uma escolha. Protocolos permanecem pequenos ao se recusar a resolver todos os problemas ao nível do protocolo.

Quem decide o que Nostr se torna

Ninguém e todos.

Não há Fundação Nostr. Nenhum grupo de trabalho corporativo. Nenhum comitê diretor. A autoridade mais concentrada em qualquer lugar do ecossistema é o repositório GitHub do fiatjaf onde NIPs são propostos, e mesmo isso é apenas um ponto de coordenação, não um gatekeeper.

NIPs propostos são lidos por desenvolvedores de clientes. Populares são implementados. Um NIP que três clientes principais implementam é efetivamente parte do protocolo; um NIP que um desenvolvedor escreveu mas ninguém mais se importa é apenas um documento no GitHub.

Esse processo é confuso. Há problemas de coordenação, propostas duplicadas e política ocasional. É também resiliente de uma forma específica: nenhuma parte única pode arruiná-lo ao tomar uma decisão ruim, porque decisões ruins simplesmente não são adotadas. O protocolo evolui em direções ásperas pelo peso de escolhas de desenvolvedores, não por decreto.

Quando o modelo de protocolo vence

Protocolos vencem plataformas em condições específicas:

• Quando a propriedade importa mais que o polimento. Protocolos são geralmente menos polidos que plataformas. Eles vencem quando você se importa com o que o polimento não pode dar (identidade permanente, resistência à censura, interoperabilidade aberta).
• Quando o efeito de rede é o recurso. O valor de um protocolo cresce com a adoção por implementadores, não apenas usuários. Mais clientes e relays fortalecem a rede de forma que uma plataforma não pode copiar.
• Quando o horizonte de longo prazo importa. Plataformas são compradas, vendidas, encerradas ou têm seu foco alterado. Protocolos superam qualquer implementador único. Email é mais velho que a maioria das empresas; Nostr está apostando na mesma dinâmica.

Se seu caso de uso não corresponder a nenhum desses, uma plataforma é geralmente mais rápida e fácil. Isso é honesto. Nostr não é universalmente melhor que Twitter para todo uso possível. É melhor nas formas específicas que um protocolo bate uma plataforma.

Lendo a especificação atual

Se este guia o fez querer ler o protocolo diretamente, o repositório NIPs tem a lista completa. NIP-01 é o núcleo; os NIPs numerados após ele são extensões. Você não precisa entender nada disso para usar Nostr, mas ler NIP-01 leva cerca de dez minutos e clarifica muito.