Nostr
Plataforma · a análise detalhada foi elaborada a partir das páginas oficiais páginas da própria plataforma e das ferramentas auxiliares.
Veja também: como ler as fichas и sobre as fontes e sobre o método.
Visão geral
Nostr não é uma plataforma, e sim um protocolo. O nome significa Notes and Other Stuff Transmitted by Relays — «notas e outras coisas transmitidas por relays». O site nostr.com o descreve assim: «uma rede livre e aberta que ninguém possui e que ninguém controla».
A estrutura é simples e é sobre ela que se apoia todo o resto. Há relays: servidores que armazenam e distribuem as mensagens. Há clientes: aplicativos pelos quais as pessoas leem e escrevem. E há chaves: a chave pública funciona como nome de usuário e a privada como senha; são as chaves, e não uma empresa, que dão a você o direito à sua identidade. Como a identidade pertence à chave e não ao aplicativo, você pode passar de um cliente para outro mantendo o perfil, os seguidores e as publicações.
Tecnicamente tudo se reduz a um único tipo de objeto. O documento base do protocolo diz: o único tipo de objeto existente é o «evento» (event), as assinaturas e as chaves usam o esquema de Schnorr sobre a curva secp256k1, e o relay expõe para fora um ponto websocket ao qual o cliente envia três tipos de mensagem: EVENT para publicar, REQ para assinar uma seleção e CLOSE para fechá-la.
Para este diretório isso significa o seguinte: o Nostr não tem dono, nem um público único, nem painel de anúncios, nem regras de moderação, nem programa de pagamentos. A seguir se analisa o que existe no lugar disso.
Quem está aqui
O número de público do Nostr não existe — e não pode existir no sentido habitual. Não há um servidor central que conte os usuários: há uma multidão de relays independentes, e cada um enxerga apenas os seus.
Indiretamente, só cabe julgar por relays concretos. O cliente de nostr.com conecta-se por padrão a seis relays e mostra a lista deles diretamente na interface: relay.nostr.com, relay.damus.io, nos.lol, nostr.bitcoiner.social, nostr.mom e relay.snort.social. O projeto recomenda consultar o catálogo de relays na ferramenta externa Nostr.watch, e o catálogo de clientes em nostrapps.com (página sobre os relays, página sobre os clientes).
Não há recorte por idioma nem por país, e não pode haver: o protocolo não guarda essa informação sobre o usuário. Por padrão, o perfil contém apenas nome, descrição e imagem.
Como começar
Não há cadastro no sentido habitual: a conta é um par de chaves gerado pelo aplicativo. Nem confirmação de e-mail, nem número de telefone, nem moderação do pedido.
Daí decorre o principal risco, sobre o qual o próprio projeto adverte: a chave privada dá acesso completo à conta — com ela é possível publicar em seu nome, alterar o perfil e enviar mensagens; se a chave for perdida e não houver cópia, não existe o botão «esqueceu a senha». Conselho prático do projeto: não coloque a chave privada em qualquer aplicativo — é mais seguro usar uma extensão de navegador para assinar ou um assinador remoto.
Um nome verificável, parecido com um «selo de verificação», é possível de conseguir: um documento à parte do protocolo descreve a vinculação da chave a um domínio. O cliente pega do perfil um endereço do tipo nome@domínio, solicita https://domínio/.well-known/nostr.json?name=nome e compara a chave pública obtida com a chave do autor da publicação. Para uma empresa esse é justamente o modo de confirmar que a conta é realmente dela: a confirmação vem do controle sobre o domínio, e não da decisão de um moderador.
Não há uma conta comercial à parte — assim como não há uma conta comum. A presença de uma empresa no Nostr é uma chave vinculada ao seu domínio e, se ela quiser, um relay próprio.
O que se pode publicar
Os formatos são definidos pelos «tipos» de eventos, e os tipos são descritos em documentos à parte: os NIP (Nostr Implementation Possibilities). A lista deles é mantida em um repositório aberto e inclui, entre outras coisas: notas curtas e tópicos de discussão, materiais longos, imagens e vídeos, transmissões ao vivo e «spaces», enquetes, eventos de calendário, wikis, torrents, listas, favoritos e citações (lista de NIP).
O protocolo não impõe limites de comprimento nem de tamanho: quem os impõe é o relay, e o relay é obrigado a declará-los. O documento sobre as informações do relay descreve os campos: max_message_length — tamanho máximo do JSON recebido em bytes (que, de fato, limita também o tamanho do evento), max_content_length — número máximo de caracteres no campo de conteúdo, max_event_tags — número máximo de marcadores, max_subscriptions — número de assinaturas simultâneas em uma mesma conexão, max_limit — teto do número de eventos na resposta a uma única consulta.
É assim que isso aparece na prática. O relay relay.damus.io declara, na data da verificação, um limite de mensagem de 1 000 000 de bytes, 200 assinaturas e um teto de seleção de 500 eventos; o relay nos.lol — 131 072 bytes, 20 assinaturas, os mesmos 500 eventos; o relay relay.nostr.com — 131 072 bytes, 200 assinaturas, 500 eventos. Os números pertencem a cada relay separadamente, e em outro relay serão diferentes.
O protocolo não tem proibições de conteúdo. Há marcação técnica: um documento à parte descreve a marcação de conteúdo sensível, outro as denúncias sobre eventos, e um terceiro o pedido de exclusão. Repare na palavra «pedido»: a exclusão no Nostr é uma solicitação aos relays, e não uma garantia. O que aceitar e o que guardar quem decide é o dono do relay.
Como crescer
No protocolo não há feed algorítmico. O que mostrar ao usuário quem decide é o cliente, e quais eventos entregar, o relay. O cliente de nostr.com mostra isso de forma explícita: na interface dele há opções de feed «assinaturas», «global» e «próprio», e mais abaixo uma lista dos relays conectados.
Daí decorre uma consequência prática que o próprio projeto explica: se o Nostr parece lento ou vazio, a causa podem ser os relays; parte dos relays é rápida e confiável, outra se desconecta e não responde, e acrescentar alguns relays bons muda muita coisa. Crescer no Nostr consiste, antes de tudo, em publicar naqueles relays onde realmente há leitores.
Painel de anúncios não existe: o protocolo não tem nem uma plataforma que venda exibições nem um mecanismo para contabilizá-las. Tampouco há estatísticas integradas; o mais próximo disso é a consulta COUNT, que o relay executa na medida do possível e de forma aproximada.
Contra o spam o protocolo propõe um recurso pouco comum: o documento sobre a prova de trabalho permite ao relay exigir dos eventos novos uma complexidade de cálculo determinada. O segundo recurso é o dinheiro: parte dos relays é paga, e isso reduz o spam, porque manter um relay custa dinheiro e os usuários passam a ter um motivo para se comportar direito.
Caminho para a monetização
Não há plataforma — logo, também não há pagamentos da plataforma. Em compensação, há pagamentos diretos entre pessoas, e eles estão descritos no próprio protocolo.
O mecanismo se chama «zap»: um pagamento pela rede Lightning. O documento do protocolo introduz dois tipos de eventos: 9734 — o pedido de zap, isto é, a solicitação do pagador à carteira do destinatário para que emita uma fatura, e 9735 — o recibo, a confirmação da carteira do destinatário de que a fatura está paga. O percurso é este: o cliente pega do perfil do destinatário o endereço do seu ponto de pagamento, verifica se ele oferece suporte ao Nostr, envia para lá uma solicitação assinada e recebe uma fatura; depois do pagamento, a carteira publica o recibo. O sentido do recibo é explicado no mesmo lugar: ele permite aos clientes mostrar os pagamentos diretamente no feed — por prazer ou como recurso de combate ao spam.
Nesse esquema não há comissão da plataforma: o dinheiro vai de carteira a carteira. Mas também não há garantias da plataforma: pela entrega do pagamento respondem a rede Lightning e o provedor de carteira que você escolher.
Além dos zaps, a lista do protocolo contém outros mecanismos monetários: metas de arrecadação (zap goals), distintivos, carteiras Cashu e «nutzaps», conexão remota de carteira e eventos de pedidos entre pessoas. Cada um deles é implementado pelo cliente se ele assim quiser.
Ferramentas e automação
O Nostr não tem «API oficial» pela mesma razão pela qual não tem dono: o próprio protocolo é a interface. Qualquer programa pode abrir um websocket para um relay e trabalhar com ele diretamente (documento base). Não existem chaves de desenvolvedor, nem pedidos de acesso, nem moderação de aplicativos.
Antes de construir uma ferramenta, vale ler a advertência da própria lista: «Os NIP aqui não são uma lista de verificação do protocolo. Nada obriga programa nenhum a implementar qualquer NIP. Cada aplicativo escolhe o subconjunto necessário para a sua tarefa». Isso significa que não se pode contar com um recurso apenas porque ele está descrito: é preciso verificar se um relay concreto o suporta. O modo de verificar está previsto: o relay entrega por HTTP um documento com a lista dos NIP suportados, o nome do programa, a versão, os contatos e um link para as suas condições de serviço. Os três relays citados acima declaram o mesmo conjunto: todos os três funcionam com o programa strfry e suportam os NIP 1, 2, 4, 9, 11, 28, 40, 45, 70 e 77.
Entre os recursos prontos, o projeto cita as extensões de navegador para assinar e os assinadores remotos, assim como o seu próprio assinador, o Pomegranate. Os catálogos de clientes e de relays são mantidos fora do protocolo: em nostrapps.com e Nostr.watch (página sobre os clientes, página sobre os relays).
Limitações e regras
- Não há regras comuns. Não existe um único documento que proíba algo a todos os participantes da rede. As regras são fixadas pelo dono do relay; o protocolo apenas prevê um link para as condições de serviço nas informações do relay.
- Os limites são fixados pelo relay e ele mesmo os declara: tamanho da mensagem, comprimento do conteúdo, número de marcadores, número de assinaturas, teto da seleção.
- O relay pode exigir entrada pelo protocolo de autenticação ou prova de trabalho para os eventos novos.
- A exclusão não é garantida: o documento descreve justamente um «pedido de exclusão», e cada relay decide se o executa ou não.
- A perda da chave é irreversível. Não há recuperação de acesso.
- A rede não tem moldura jurídica. A responsabilidade recai sobre o dono do relay e sobre o autor; o protocolo não tem uma pessoa jurídica com a qual firmar um contrato. A própria lista de NIP é publicada em um repositório sem licença indicada.
Para quem serve
Serve para projetos aos quais importa a independência em relação ao dono da plataforma: a identidade pertence à chave, e não a uma empresa, a conta não pode ser bloqueada de forma centralizada, e se um relay não agradar basta trocar de relay. Serve para desenvolvedores: conectar-se à rede não exige nem chave de aplicativo nem aprovação.
Serve para projetos ligados ao bitcoin e ao Lightning: os pagamentos estão integrados ao protocolo na forma de zaps, e essa é a parte mais desenvolvida da sua mecânica monetária.
Não serve se você precisa de alcance previsível e de relatórios: aqui não há nada para medir — nem plataforma, nem estatísticas, nem painel de anúncios. Não serve para envio em massa nem para «promoção»: o relay tem o direito de exigir um pagamento, uma autenticação ou uma prova de trabalho e de desconectar você sem explicações. E não serve se na organização se exige um contrato com um fornecedor de serviços: essa parte o protocolo não tem.
Dados verificados da base
Dados verificados resumidos em que se apoia a análise detalhada.
Sobre a plataforma
a plataforma se descreve assim: «Nostr is a free and open-source protocol for social media and other things - controlled by users, not platforms.»
autodescrição: é uma declaração da própria plataforma sobre si mesma, não uma avaliação independente
fonte, verificado 2026-07-28
o Nostr (Notes and Other Stuff Transmitted by Relays) é descrito como uma rede livre e aberta que ninguém possui e ninguém controla; os relays armazenam e distribuem as mensagens, e os clientes permitem lê-las e escrevê-las
É um protocolo, e não uma plataforma: não tem dono, gerenciador de anúncios nem programa de pagamentos
fonte, verificado 2026-07-28
o único tipo de objeto é o evento (event); as assinaturas e chaves usam o esquema de Schnorr na curva secp256k1; o relay expõe um ponto websocket, e o cliente envia EVENT para publicar, REQ para criar uma inscrição e CLOSE para encerrá-la
Documento básico do protocolo, o NIP-01
fonte, verificado 2026-07-28
Por onde começar
a barreira de entrada no nostr não tem um dono único de regras: «Nostr (Notes and Other Stuff Transmitted by Relays) is a free and open network that nobody owns or controls»; o conjunto de propostas para o protocolo diz o mesmo a respeito de si próprio: «NIPs listed here are not a protocol checklist. Nothing forces any software to implement any NIP»
citações literais, idioma da fonte: inglês. A segunda vem do README do conjunto de NIPs: https://raw.githubusercontent.com/nostr-protocol/nips/master/README.md. Conclusão prática para o leitor: não existem condições de entrada únicas e obrigatórias para toda a rede; as condições são definidas por cada relay e por cada aplicativo, e são diferentes entre si
fonte, verificado 2026-08-07
o relay tem o direito de fechar a escrita, exigir entrada por assinatura ou prova de trabalho: na lista de limitações da NIP-11 constam «auth_required», «restricted_writes», «min_pow_difficulty», «payment_required»; «Your client should expect that requests exceed these practical limitations are rejected or fail immediately»
citações literais, idioma da fonte: inglês, ortografia da fonte preservada. Não há inscrição, convite nem moderação no nível do protocolo; tudo o que foi listado são propriedades de cada relay, e dá para conhecê-las solicitando ao relay o seu documento de informações
fonte, verificado 2026-08-07
Conta e acesso
a conta é um par de chaves, e não um registro guardado pelo dono da plataforma: «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»
citação literal, idioma da fonte: inglês. Não se exige cadastro, verificação de identidade nem aprovação para obter as chaves: o par de chaves é gerado no dispositivo. O nome verificável opcional no formato nome@domínio é descrito no NIP-05, à parte
fonte, verificado 2026-08-07
a conta tem um par de chaves: a pública funciona como nome de usuário, e a privada como senha; a identidade pertence à chave, e não ao aplicativo, por isso é possível trocar de cliente mantendo o perfil e os seguidores
Não há cadastro, confirmação de e-mail nem moderação de pedido
fonte, verificado 2026-07-28
em caso de perda da chave privada sem cópia de segurança, não há como recuperar o acesso: não existe botão «esqueci a senha»
O projeto aconselha não inserir a chave privada em cada aplicativo, e sim usar uma extensão assinadora ou um assinador remoto
fonte, verificado 2026-07-28
nome verificável no formato nome@dominio: o cliente consulta https://dominio/.well-known/nostr.json?name=nome e compara a chave pública recebida com a chave do autor do registro
Para uma empresa é uma forma de confirmar a conta pelo controle do domínio, e não por decisão de um moderador
fonte, verificado 2026-07-28
O que se pode publicar
a lista de NIPs descreve, entre outras coisas: notas curtas e tópicos, materiais longos, imagens e vídeos, transmissões ao vivo e spaces, enquetes, eventos de calendário, wikis, torrents, listas, favoritos e citações
A lista de NIPs não é um compromisso: nada obriga um programa a implementar qualquer NIP
fonte, verificado 2026-07-28
Como se paga aqui
Quem é aceito. não há limite mínimo de seguidores, de visualizações ou de número de publicações para os pagamentos: os zaps vão diretamente de pessoa a pessoa pela rede Lightning, e a única condição é o destinatário ter uma carteira com endereço 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»
citação literal, idioma da fonte: inglês. Limite zero: a NIP-57 não exige número de seguidores, nem horas de exibição, nem tempo de existência da conta. Os valores-limite são definidos pela carteira do destinatário nos campos «minSendable» e «maxSendable», e não pela rede
fonte, verificado 2026-08-07
não há comissão da rede nem quem pudesse cobrá-la: o dinheiro passa ao largo do protocolo, pela carteira do destinatário, e o nostr não participa do acerto — a NIP-57 descreve apenas dois tipos de eventos, o registro do pedido e o registro do recibo: «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»
citação literal, idioma da fonte: inglês. A carteira ou um nó da rede Lightning podem cobrar sua própria comissão — isso já não é o nostr, e o tamanho dela não é fixado na NIP-57. A rede não tem comissão, participação nem valor mínimo de saque, porque não há intermediário que segure o dinheiro
fonte, verificado 2026-08-07
os pagamentos entre pessoas estão descritos no protocolo como «zaps» pela rede Lightning: o evento 9734 é o pedido de zap, e o evento 9735 é o recibo da carteira do destinatário confirmando o pagamento da fatura
Não há comissão da plataforma no esquema: o dinheiro vai de carteira a carteira; a responsabilidade pela entrega é da rede Lightning e do provedor da carteira
fonte, verificado 2026-07-28
a lista de NIPs contém também metas de arrecadação (zap goals), insígnias, carteiras Cashu e nutzaps, conexão remota de carteira e eventos de pedidos entre pessoas
Cada mecanismo é implementado pelo cliente conforme sua vontade
fonte, verificado 2026-07-28
Quanto custa
o protocolo não cobra nada, mas um relay em particular pode: a NIP-11 prevê campos para cobrança — «Relays that require payments may want to expose their fee schedules»: «fees»: «admission» (taxa de admissão), «subscription» (assinatura, com o campo «period»), «publication» (taxa de publicação, com indicação dos tipos de eventos); na lista de limitações do relay há o indicador «payment_required»
citações literais, idioma da fonte: inglês. Os números são definidos por cada relay, por isso não existe um preço de entrada único na rede. Exemplo apresentado na própria NIP-11 como modelo de resposta do relay nostr.wine: «fees»: «admission»: ({«amount»: 18888000, «unit»: «msats»}) — é uma declaração do relay no exemplo do documento, não um cálculo nosso nem uma promessa de preço atual
fonte, verificado 2026-08-07
Limites e restrições
o relay declara seus limites no documento de informações: max_message_length (tamanho do JSON recebido), max_content_length (caracteres no campo de conteúdo), max_event_tags, max_subscriptions, max_limit; são possíveis exigências de autenticação e de prova de trabalho
Documento NIP-11; o protocolo não tem limites próprios de comprimento e de tamanho
fonte, verificado 2026-07-28
o relay relay.damus.io, na data da verificação, declara limite de mensagem de 1 000 000 bytes, 200 inscrições simultâneas e teto de 500 eventos por consulta; software strfry
O número pertence a este relay; em outro ele é diferente
fonte, verificado 2026-07-28
o relay nos.lol declara limite de mensagem de 131 072 bytes, 20 inscrições e teto de 500 eventos por consulta
Medido por consulta ao documento de informações do relay
fonte, verificado 2026-07-28
o relay relay.nostr.com declara limite de mensagem de 131 072 bytes, 200 inscrições e teto de 500 eventos por consulta; os NIPs declarados são 1, 2, 4, 9, 11, 28, 40, 45, 70, 77
O mesmo conjunto de NIPs é declarado por damus.io e nos.lol
fonte, verificado 2026-07-28
Restrições
não há regras únicas: o que aceitar e armazenar é decidido pelo dono do relay; o protocolo apenas prevê um link para os termos de serviço nas informações do relay
A exclusão é descrita como «pedido de exclusão», e sua execução não é garantida
fonte, verificado 2026-07-28
recursos contra spam: o relay pode exigir prova de trabalho de determinada dificuldade ou autenticação; parte dos relays é paga, o que, pela explicação do projeto, reduz o spam
O Nostr.watch é recomendado pelo projeto como catálogo de relays, e o nostrapps.com como catálogo de clientes
fonte, verificado 2026-07-28
o arquivo para robôs de nostr.com permite o rastreamento do site a todos os agentes
Verificado separadamente
fonte, verificado 2026-07-28
Aspectos jurídicos
o repositório com a lista de NIPs está publicado sem licença indicada
O protocolo não tem pessoa jurídica com quem seja possível firmar contrato
fonte, verificado 2026-07-28
Acesso via API
o cliente em nostr.com conecta-se por padrão a seis relays: relay.nostr.com, relay.damus.io, nos.lol, nostr.bitcoiner.social, nostr.mom, relay.snort.social
A lista é visível diretamente na interface
fonte, verificado 2026-07-28
não existe uma «API oficial» separada: a interface é o próprio protocolo, e qualquer programa pode abrir um websocket para um relay; não existem chaves de desenvolvedor nem moderação de aplicativos
O suporte a recursos específicos precisa ser verificado no documento de informações do relay
fonte, verificado 2026-07-28
Idiomas
idioma da interface da página inicial: en
O idioma foi obtido do atributo da marcação; as versões, do hreflang
fonte, verificado 2026-07-28
Seção do catálogo: todos os semelhantes Veja também: índice do catálogo · comparação de agendadores · seleção por situação · restrições das plataformas