Sistemas Descentralizados/03 - Nostr4 min
Limites do Nostr
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Todos os limites abaixo têm a mesma raiz: não há consenso e não há operador. Nenhum é bug pendente de correção — são o preço do que o Nostr ganhou. Estudá-los é mais útil que estudar as features.
1. Deleção não existe
O kind: 5 (NIP-09) é um pedido. Relays honestos apagam; qualquer relay que já copiou o evento pode ignorar, e clientes podem ter cache. O NIP-62 (Request to Vanish) é mais amplo — "apague tudo meu daqui" — e continua sendo pedido.
Publicou, publicou. Trate todo evento como permanente.
2. Não existe ordem global
created_at é declarado pelo autor. Ele pode datar no futuro para fixar o post no topo dos feeds — e isso acontece. Some-se a isso que cada relay entrega na ordem que quiser, e o resultado é: a ordem da sua timeline é uma opinião do seu cliente, não um fato do sistema.
Sem consenso, tempo objetivo não existe. Ver 2. Consenso e Finalidade para o contraste.
3. Não existe contagem confiável
Seguidores, curtidas, respostas: tudo é estimativa por amostragem dos relays consultados. Dois clientes mostram números diferentes e ambos estão certos. Ver o exemplo em 3. Relays e Fan-out.
4. Disponibilidade do dado é responsabilidade sua
Seus posts existem só nos relays que resolveram guardá-los. Relay caiu, mudou de política, expirou dado antigo, ou o dono cansou de pagar o servidor: sumiu. Não há replicação automática entre relays, não há garantia de durabilidade, não há SLA.
A mitigação é operacional, não protocolar: publicar em vários relays, rodar o seu próprio, fazer backup local. O usuário virou o administrador da própria durabilidade — e a maioria não sabe disso.
5. Spam
Sem porteiro, qualquer chave publica qualquer coisa, e chaves são gratuitas e infinitas. É o mesmo ataque Sybil que a blockchain resolve com PoW/PoS — só que aqui não há recurso escasso nenhum.
As defesas são econômicas ou sociais, nunca criptográficas:
| Defesa | NIP | Como funciona |
|---|---|---|
| Relay pago | — | custo por conta |
| Proof of Work | 13 | custo computacional por evento |
| Web of trust | 85 | só quem é seguido por quem você segue |
| Autenticação | 42 | relay exige identificação para escrever |
| Denúncia e rótulo | 56, 32 | moderação publicada como dado, não imposta |
Repare que nenhuma resolve — todas aumentam o custo ou transferem a decisão para o cliente.
6. A chave é o calcanhar de Aquiles
Este é o limite mais grave, e o mais honesto de encarar:
- Vazou a
nsec→ acabou. Não há revogação, não há rotação, não há trocar a senha - Perdeu a
nsec→ acabou. Não há recuperação, não há suporte, não há "esqueci minha senha" - Sua identidade inteira, histórico e seguidores estão amarrados a 32 bytes que você precisa guardar para sempre
As mitigações existem e todas seguem a mesma estratégia — manter a chave longe do aplicativo:
| NIP | Abordagem |
|---|---|
| 07 | extensão de navegador assina; o site nunca vê a chave |
| 46 | bunker: signer remoto, o app pede assinatura por RPC |
| 55 | app assinante no Android |
| 49 | ncryptsec: chave cifrada com senha, portável |
Nenhuma resolve rotação. Trocar de chave significa começar do zero — e convencer seus seguidores, um a um, de que a chave nova é você. O NIP-26 (assinatura delegada) tentou atacar isso e foi desaconselhado por "peso demais para pouco ganho".
É o mesmo problema estrutural de 3. Limites do Web3: quando identidade é uma chave em vez de uma linha em banco de dados, recuperação de conta deixa de existir — e toda mitigação funciona reintroduzindo alguma confiança em terceiros.
7. Fragmentação entre clientes
"Suporta Nostr" não diz nada. Um cliente implementa 18 dos 95 NIPs, outro implementa 30 diferentes. Você publica um artigo (kind: 30023) e o amigo, noutro app, vê um perfil vazio. Ver 6. Catálogo de NIPs.
8. Privacidade é opt-in e parcial
Por padrão tudo é público e permanente. DMs decentes exigem NIP-17 + 44 + 59 juntos, e mesmo assim o relay que recebe sabe seu IP e horários. O grafo social — quem você segue, o kind: 3 — é público por design.
Trade-offs
Vale colocar lado a lado o que cada limite comprou:
| Limite | O que comprou |
|---|---|
| Sem deleção | ninguém pode apagar você |
| Sem ordem global | sem consenso → barato e rápido |
| Sem contagem | sem estado global → relay trivial |
| Sem durabilidade garantida | relay descartável → censura precisa de coordenação global |
| Spam livre | sem porteiro → sem quem te barre |
| Sem recuperação de conta | sem operador → identidade que ninguém tira |
Nenhuma linha é acidente. Toda garantia que um sistema oferece precisa de alguém que a garanta — e ao remover esse alguém, você remove a garantia junto. Essa é a lição que atravessa toda a trilha.
Exemplo prático
Onde o Nostr é a escolha certa:
- Publicação resistente à censura (jornalismo, protesto, país hostil)
- Identidade portátil entre aplicativos
- Rede social que não pode te desligar
- Feed público que outros apps possam ler sem API nem chave
Onde é a escolha errada:
- Qualquer coisa que precise apagar dado (LGPD, direito ao esquecimento)
- Qualquer coisa que precise de contagem exata (votação, saldo, estoque)
- Qualquer coisa que precise de ordem (leilão, fila, transação)
- Público que não consegue guardar uma chave privada — que é quase todo mundo
O teste rápido, e é o mesmo de 3. Limites do Web3 invertido:
Existe alguém que precisa poder desfazer, contar ou ordenar?
Se sim, o Nostr não é a ferramenta — e insistir significa reimplementar, mal, o consenso que ele escolheu não ter.
Relacionado
Parte de MOC Nostr · nostr-protocol/nips