- Nostr é um protocolo de comunicação aberto que exclui o controle centralizado, com uma arquitetura projetada para permitir a livre circulação de informações por meio de diversas combinações de clientes e relays
- Os usuários garantem identidade e autenticidade das mensagens com base em chaves privadas e assinaturas, e os clientes se conectam simultaneamente a vários relays para realizar propagação e consulta distribuídas
- O protocolo não tem dono, mas cada operador de relay define critérios próprios de censura e bloqueio conforme suas políticas, e os usuários escolhem de quais relays querem ler
- Indo além do microblog no estilo Twitter, o ecossistema está se expandindo com subprotocolos como grupos fechados (NIP-29), marketplaces, wiki distribuída e colaboração em código/torrent/live streaming
- Ainda está mais para uma etapa que exige participação de desenvolvedores e early adopters do que para um produto finalizado, e desafios como spam, escalabilidade e descobribilidade vêm sendo enfrentados com estratégias de combinação entre clientes e relays
An open protocol with a chance of working
- O Nostr busca ser um espaço público de comunicação sem vínculo com orientação política, definindo uma arquitetura cliente/servidor escalável como um padrão simples que qualquer pessoa pode implementar e usar
- Não é controlado por uma empresa ou governo específico, e abraça a sensibilidade aberta e caótica da internet em seus primórdios, na qual diversos clientes mostram a mesma camada de informação sob perspectivas diferentes
- O site apresenta capturas de tela de clientes reais, destacando a diversidade do ecossistema e sua orientação para uso prático
Many clients, many servers
- Diferentemente de serviços centralizados, os clientes do Nostr se conectam a múltiplos relays ao mesmo tempo
- Cada relay é um servidor baseado em WebSocket que atua como um repositório distribuído de publicações, consultando e assinando eventos de interesse
- Como nenhum relay específico é tratado como fonte única de confiança, há um efeito de distribuição do risco de censura e shadowban
- Por meio de links de referência, o material orienta o aprendizado sobre as diferenças em relação aos modelos existentes
A new paradigm for communication
- A identidade do usuário é representada por uma chave privada secreta, e todas as mensagens incluem assinatura digital, permitindo verificar a autenticidade do autor sem uma autoridade central
- Essa base de confiança criptográfica viabiliza um broadcasting resistente à censura
- Também há link para um vídeo com explicação mais acessível, reduzindo a barreira de entrada
The protocol is ownerless, relays are not
- O protocolo é sem proprietário, mas os relays são de propriedade privada, e cada operador pode definir livremente seus próprios critérios de aceitação e recusa
- Como os usuários podem escolher livremente quais relays ler, coexistem diversidade de expressão e liberdade de escolha de acesso
- Em vez de uma dicotomia “a favor ou contra a censura”, o foco está na pluralidade de regras por servidor e na escolha do usuário
Freedom of association
- Como o efeito de rede não fica preso a uma única organização, a estrutura dificulta que um grupo específico de usuários prejudique estruturalmente os demais
- Vídeos relacionados destacam a liberdade de associação e separação
Your own piece of Nostr
- Programadores podem facilmente operar seu próprio relay e aplicar suas próprias regras
- O texto aponta para repositórios de implementação de relay, incentivando contribuição e experimentação
New Ideas — Exploring the commons
- Indo além do microblogging no estilo Twitter, o protocolo aceita vários tipos de dados, como vídeo/textos longos/imagens/notas de voz
- Há intensa experimentação com subprotocolos como grupos fechados, Wikipedia distribuída, Couchsurfing, marketplaces e anotações na web
- Também estão em andamento tentativas de usar o Nostr como camada de descoberta e coordenação em colaboração distribuída de código baseada em git, hospedagem de arquivos, compartilhamento via torrent e vídeo ao vivo
- A coleção de propostas de padrão NIP busca ampliar funcionalidades e promover interoperabilidade
Ecosystem — Still under construction
- Embora exista um grande volume de software open source e uma base ampla de usuários, o ecossistema ainda não está no estágio de produto refinado e acabado
- A participação de usuários iniciais e desenvolvedores é importante para melhorar o fluxo do protocolo e a UX
Microblogging — The outbox model
- O modelo de outbox é apresentado como abordagem padrão para implementar clientes resistentes à censura, mas seus parâmetros ainda são flexíveis
- O guia de implementação explica como tratar os relays como armazenamento e define estratégias de assinatura e publicação
Relay-based groups — NIP-29
- O NIP-29 apresenta uma forma eficiente de implementar grupos fechados no estilo fórum/chat com base em relays
- O modelo orienta uma estrutura que reduz a dependência de um único relay, mantendo a resistência à censura
How Nostr works
- O objetivo é oferecer liberdade real, mantendo a conexão entre usuário e público mesmo em ambientes hostis
- Com múltiplos relays, indexação local e leitura seletiva, busca garantir acessibilidade contínua
FAQ — perguntas e respostas principais
-
O que é um “protocolo”?
- É uma linguagem comum usada por vários softwares para se comunicarem, e significa interoperabilidade não vinculada a um app específico, como e-mail/HTML/HTTP
- Vários apps que compartilham a mesma linguagem podem se substituir entre si, cada um com sua própria expressão e UI
-
Como lidar com spam e conteúdo indesejado?
- O feed padrão traz apenas informações de pessoas que eu sigo, então spam por push é difícil
- Consultas abertas, como ver comentários, podem ficar expostas a spam, então usam-se estratégias de redução da superfície de contato como limite a contatos de segundo grau, whitelist de relays confiáveis e relays pagos ou verificados
- Não existe solução perfeita, mas o Nostr foi projetado com resiliência como premissa
-
Escala em caso de adoção em massa é viável?
- A base é uma arquitetura cliente-servidor, e como os usuários naturalmente se distribuem por centenas de relays, o balanceamento de carga já está embutido
- Conectar-se a muitos relays pode parecer problemático, mas as pessoas tendem a seguir grupos de contas com interesses parecidos, fazendo com que os relays acabem formando denominadores comuns naturais
- Apps nativos conseguem lidar com centenas de conexões WebSocket e garantem desempenho com banco de dados local e requisições em lote
-
Como responder ao assédio online?
- Assim como no spam, publicações indesejadas podem ocorrer, então a minimização de exposição é feita com bloqueio, listas de bloqueio compartilhadas e relays de leitura restrita
- Recursos de proteção como ver apenas amigos também podem ser emulados por meio de políticas de relay
-
Por que não Mastodon/Fediverso?
- A ausência de criptografia impede um modelo multi-master, gerando problemas de identidade vinculada ao servidor e de transferência de confiança entre servidores
- Exige confiança excessiva nos operadores dos servidores, além de haver críticas à dependência de domínio e DNS
- O Nostr permite formar comunidades reais no nível do relay com identidade não vinculada ao servidor e escolha de relay
-
Por que não Bluesky/ATProto?
- A centralização de identidade baseada em PLC e o fluxo de fonte única Relay-AppView-Client ampliam o risco de censura, reordenação e shadowban
- Isso pode ser melhorado com múltiplas fontes, mas nesse caso a estrutura acabaria convergindo para algo muito parecido com o Nostr
-
Os incentivos para operar relays estão alinhados?
- O custo de operação do servidor é baixo, e diferentes atores, como comunidades/pessoas/organizações/provedores de hospedagem, podem oferecer relays a baixo custo
- Como os usuários podem ir para qualquer lugar, diversos agentes econômicos acabam alinhados
-
É possível ver todo o conteúdo espalhado por vários relays?
- Assim como ninguém consegue ver tudo no mundo, só é possível observar dentro dos limites de foco e de acesso permitido
- Essa é uma restrição natural decorrente da atenção e da escolha de relays
-
Como a busca funciona?
- Em essência, só é possível buscar aquilo que já foi visto, então, para busca pública, crawlers/indexadores precisam coletar seletivamente a rede
- Com armazenamento local, os clientes podem encontrar rapidamente em busca local o conteúdo que foi visto ou com o qual houve interação
- Relays temáticos podem oferecer busca útil dentro de um escopo com sua própria indexação
-
Sem algoritmo, como descobrir conteúdo novo?
- A base está na exploração do grafo de interações da rede de seguidos, e o Nostr também pode ter algoritmos locais, de relay ou baseados em IA
- É possível aplicar vários mecanismos de descoberta, como destaques e resurfacing de retorno no cliente local e curadoria do lado do relay
-
Qual é a relação com o Bitcoin?
- Compartilha princípios criptográficos e surgiu da comunidade Bitcoin, mas não há dependência
- Zaps são um padrão de gorjeta em Bitcoin implementado por alguns clientes e são totalmente opcionais
1 comentários
Comentários no Hacker News
É importante saber que a criptografia do Nostr é seriamente falha
As principais vulnerabilidades apresentadas neste artigo são as seguintes
O protocolo de eventos não autentica a chave pública, então a assinatura com chave simétrica é meramente formal
Dois clientes importantes, como Damus e Iris, nem sequer verificam a assinatura em si
As DMs no sistema usam criptografia CBC não autenticada, então um atacante pode alterar o conteúdo com bitflips na mensagem
Como os apps fazem prévia automática de links, o antigo ataque EFAIL pode ser reproduzido
Não há separação de chaves no sistema, então é possível enganar o usuário para usar a chave de sessão incorretamente
No geral, são erros básicos de iniciante no nível de meados dos anos 2000
O Nostr pode ter outras vantagens, mas não é uma plataforma adequada se você quer segurança de ponta a ponta
Atuei por muito tempo na comunidade Nostr e até criei uma extensão para Safari
Não li esse artigo, mas acho que os pontos levantados incluem mal-entendidos ou equívocos sobre o próprio protocolo Nostr
No Nostr, a chave pública funciona como identidade
Criptograficamente, uma identidade baseada em chave pública não pode ser falsificada (desconsiderando bugs de implementação)
Em termos de UX, pode ser difícil verificar a identidade real do dono da chave pública, mas isso é um problema separado da segurança criptográfica
Dizer que "o protocolo de eventos não autentica a chave pública" não faz o menor sentido
A maioria dos clientes e relays de fato verifica as assinaturas
Como autor do Damus, esclareço que isso se refere a uma versão antiga — esse problema foi corrigido
No início, ele se conectava apenas a relays confiáveis, e esses relays verificavam as assinaturas
Cheguei até a criar um banco de dados embarcado chamado nostrdb para verificação otimizada de assinaturas
Também está errado dizer que as DMs são vulneráveis por usarem CBC não autenticado
A nota inteira é coberta por assinatura secp256k1
Prévia automática de links, imagens etc. pode ser ativada ou desativada, e se isso preocupar, recomenda-se usar VPN
Tentei descobrir qual algoritmo de chave é usado no Nostr, mas isso não está explicitamente indicado em nenhum ponto da documentação
Ao pesquisar, tudo acaba levando a conteúdos sobre Blech32 (codificação de chaves do Bitcoin)
Pela documentação introdutória do hellonostr.dev, dá para ver que a própria codificação já embute informação de versão
No formato
npub1abcxyz...,npubé o cabeçalho,1é a versão, e o restante é a chaveConsulte a documentação relacionada
Os problemas apontados na prática dependem da implementação (apps que não verificam assinatura, o que destrói a essência do protocolo),
ou vêm de um esquema provisório de criptografia do começo do projeto (já substituído por NIP44 etc. e auditado de forma independente)
No momento, não há nenhum problema fatal nem que exija resposta prática urgente
Não sei por que estou ouvindo falar desses problemas pela primeira vez só agora
Isso deveria ser discutido rapidamente
Do ponto de vista de protocolo, fico curioso se uma plataforma federada mais segura seria o Bluesky (AT Protocol) ou o fediverse
Muita gente entende errado e acha que os relays do Nostr se federam e compartilham mensagens
Na prática, não é assim
Se você fizer um clone do Twitter, o app cliente precisa pesquisar e publicar diretamente em vários relays
e, se não usarem relays em comum, vocês não conseguem ver as mensagens uns dos outros
Se usar apenas um relay, vira algo totalmente centralizado,
e, se usar vários, fica lento e trabalhoso, então o usuário precisa saber manualmente a quais relays se conectar
A documentação dos NIPs também era bagunçada, o que dificultava a manutenção
Os relays também podem se federar
O protocolo Nostr não especifica nada sobre haver ou não federação
Eu opero um indexador (relay), e ele se integra com outros relays
Como um relay de ActivityPub, qualquer cliente pode se conectar ao indexador para bootstrap e buscar metadados de eventos
Mesmo sem se conectar ao mesmo relay, há várias formas de os clientes trocarem informações
Acho que é um desafio muito interessante
Se você indicar, nos metadados do perfil, relays de leitura e escrita como no NIP65,
o cliente pode encontrar facilmente todo o conteúdo adequado
Além disso, várias outras ideias estão sendo testadas
Acho que é um problema solucionável
Os relays não são donos do conteúdo gerado pelo usuário, então não há necessidade de federação
Os clientes normalmente dependem de um conjunto de relays escolhido pelo próprio usuário
Ainda assim, vários relays importantes operam armazenando também eventos de outros relays, uma espécie de federação
Ex.: Primal, TheForrest, nostr.land
O nostr.land é um relay pago, focado principalmente em filtragem de spam e agregação de notas de vários relays públicos
Se não quiser, você pode escolher outros relays
A maioria dos usuários provavelmente consegue ver mais de 99% das notas com a federação atual de relays, embora esse número não possa ser verificado
Alguns clientes e signers armazenam notas em privado,
e, se um relay censurar uma nota, é possível reagir republicando em outro relay a qualquer momento
Na prática, se você usa relays pagos populares, rapidamente encontra avisos em 3/4 dos eventos de escrita dizendo “já registrado em outro relay”
Por fim, relays também podem atuar como clientes, e isso é conveniente como cache em mobile ou em redes lentas
O modelo outbox tem problemas, mas como os desenvolvedores de clientes podem oferecer opções,
ele pode se expandir com flexibilidade da federação até P2P
A maioria dos clientes suporta outbox, então não é necessário usar o mesmo relay
Cada usuário pode ter relays separados de inbox e outbox
Havia partes estranhas na documentação dos NIPs,
mas a maioria dos NIPs está melhorando bastante,
e isso seria algo trivial de resolver com releases regulares oficiais
Muitos desenvolvedores estão reagindo rapidamente
Seria bom se esses projetos explicassem com clareza seus casos de uso, filosofia e implementação, distinguindo bem cada um
Quando você vê pela primeira vez, nem dá para saber se isso é uma rede social ou um protocolo
“É voltado a censura? Preciso ler um artigo de blog?”
Scuttlebutt, Mastodon, ActivityPub, Diaspora etc. são iguais nisso
Afinal, “qual a diferença para email?”, “o que isso tem de melhor que o Twitter?”
Antes de entender, a pessoa já fica confusa se isso é implementação técnica, produto, site ou app
Provavelmente pouca gente consegue explicar com precisão o Urbit também
Ainda assim, acho melhor do que “Web3”
Bluesky e Gemini são relativamente claros nessa parte
O Nostr é uma solução de compromisso entre a estrutura P2P e a arquitetura da web
Ele usa servidores web para acompanhar o fluxo natural da internet,
enquanto reduz a dependência do usuário em relação aos servidores e reforça identidade e autenticação de dados com chaves públicas/assinaturas
Como resultado, ele transfere poder ao usuário com algo como um “credible exit”
Por isso, em vez de um novo caso de uso, eu o chamaria de uma “nova internet”
Há trade-offs centrados no usuário, e não na plataforma (incluindo diferenças nos padrões de UX)
Como oferece valores parecidos com a resistência à censura das redes sociais existentes,
ele parece ter muitos casos de uso sociais
Seria bom alguém criar um site assim
Achei muito estranho usar a palavra “apolitical” na primeira linha da descrição do produto
Ao mesmo tempo também aparece a palavra “open”, que aqui tem um sentido intrinsecamente político
Não lembro se o Nostr tinha ligação com criptomoeda, mas acho que isso também me confundiu
O Nostr não tem “nostr coin” nem ações on-chain
Gosto muito disso
Especialmente porque a interseção entre Nostr e a comunidade cripto parecia quase total
Há muitos usuários que usam principalmente Bitcoin
A direita tem uma longa história de se descrever como “apolitical”
Serviços federados/distribuídos como Nostr, Mastodon e Discord
só conseguiriam realizar de verdade uma rede social descentralizada se o próprio app cliente embutisse seu relay e todo usuário também atuasse como servidor
Softwares P2P clássicos já faziam isso, e na prática funcionava bem
Só que, se o usuário hospedar arbitrariamente dados que ele mesmo não obteve diretamente,
surge o problema de ser punido por conteúdo ilegal, semelhante a casos em que alguém é pego com drogas ilícitas no aeroporto
Por causa desse risco, a próxima geração de estruturas P2P precisaria de “filtragem de conteúdo ilegal” baseada em IA (ex.: CP, filmes)
Ou então teria de ser uma comunidade totalmente fechada
para que, se surgir algum problema, a responsabilidade fique apenas dentro da comunidade
No fim, o modelo em que todo cliente também é servidor é o melhor modelo de rede social distribuída
O projeto iroh funciona assim
O “relay” serve apenas para intermediar a conexão entre dois clientes
Veja a explicação de conceitos do iroh
É legal, mas estruturas realmente P2P não costumam funcionar tão bem
Até o iroh depende internamente de relays
O Nostr concede diretamente aos relays o poder de aplicar políticas (e já tem isso implementado sem hacks adicionais)
Fico feliz em ver o Nostr no topo do HN
Ainda está em estágio inicial, mas o Nostr também permite “zapps” (micropagamentos instantâneos baseados em Bitcoin-Lightning)
É um modelo de rede social descentralizada e sem anúncios,
que permite recompensar criadores diretamente com pequenos valores, sem problemas de anúncios nem algoritmos
Também dá para pagar por trabalho em PRs de clientes Nostr com zaps
Veja este exemplo de bounty
O Bitcoin já é bastante regulado
Ao ler comentários assim, dá até vontade de se cadastrar, mas ao explorar a página de descoberta
fiquei impressionado ao ver pessoas realmente negociando produtos de verdade (máquinas, Kakao, educação alternativa etc.)
Não é simplesmente “publique seu diário e peça dinheiro”
É diferente nesse sentido
Parece uma plataforma para produtos, serviços e criadores reais
O Nostr existe há pelo menos 5 anos
Mesmo durante a pandemia, muita gente saiu do Twitter para o Nostr
Então é difícil concordar com a ideia de que ele está só começando agora
Apresentação de vários apps de Nostr
openux.app - alternativa ao Mobbin
kinostr.com - chat de filmes em tempo real
zap.stream - streaming ao vivo no estilo Twitch
dtan.xyz - torrent
zapstore.dev - loja de apps sem necessidade de permissão
nostrnests.com - chat em salas de áudio
zapmeacoffee.com - semelhante ao Buy Me A Coffee
asknostr.site
É assim que um protocolo social distribuído permite diversos casos de uso,
e, do ponto de vista do usuário, as vantagens são
O Nostr não precisa ser usado só como serviço de microblogging, ele também tem vários usos como camada subjacente
Ex.: Trystero
usa Nostr para estabelecer conexões P2P WebRTC sem servidor central
(licença MIT)
Eu também já pensei em fazer broadcast multicanal resistente à censura com Nostr, Bittorrent DHT, Mastodon etc.
A ideia é que a rede só se rompa se todos os métodos falharem
De forma parecida, eu me perguntava se Nostr ou ATProto
também poderiam servir como “armazenamento de mensagens offline” para mensageiros instantâneos P2P
Usá-los para estabelecer a conexão também é uma abordagem criativa
É uma ideia realmente muito boa
Eu queria fazer algo parecido, mas ainda bem que alguém já fez e me poupou tempo
Não entendo por que essas redes sociais técnicas acabam indo, como a web atual,
para plataformas separadas baseadas em conta, em vez de cada pessoa conectar sua própria homepage pessoal como na web original
Tirando RSS, fico curioso se nunca houve tentativas de criar uma rede que incentivasse sites pessoais
enquanto acrescentasse uma camada de mídia social centralizada (chat, feed etc.)
Aqui, “conta” é basicamente um par de chaves pública/privada
Você também pode operar seu próprio relay
e usar qualquer relay com a mesma chave pública
Também pode transmitir posts para todos os relays que quiser
Se quiser, pode até gerar uma nova chave a cada post
Em Mastodon e similares, a conta fica vinculada ao servidor, então há menos mobilidade e liberdade
Mas, por outro lado, não existe nenhum método de recuperação de conta, o que pode ser um problema
Talvez valha a pena ver RSDS(Really Simple Decentralized Syndication)
Em grande parte, o nostr já é assim
Só que, em vez de websites, usa o tipo de dado “nota”, e em vez de servidores, usa apenas “relays”
Pergunta-se por que você considera isso “claramente um serviço voltado para técnicos”
e se não estaria presumindo demais sobre o que os fundadores têm em mente
Em essência, já é possível combinar várias tecnologias
para construir por conta própria um sistema de homepage pessoal/chat/feed
Mas os problemas práticos desse modelo híbrido são
Tentar resolver tudo isso ao mesmo tempo inevitavelmente leva a concessões
Descentralização total vem em troca de problemas de descobribilidade e acessibilidade
A afirmação de que “não precisamos mais de contas” também se entrelaça com a questão de múltiplas identidades online e offline
No fim, isso é uma questão de escolha de valores, e os vários serviços distribuídos experimentais populares entre técnicos (ex.: Mastodon, Nostr, Smolweb)
carregam a influência da mentalidade da internet inicial (contracultura, abertura, padronização, composabilidade)
Não existe uma solução que satisfaça todo mundo,
então acho que o valor essencial da internet está na diversidade, padronização e abertura
“apolitical communication commons”
Algumas pessoas apontam que o rótulo ‘apolítico’ em si
já é uma declaração política e uma posição de poder
Fico em dúvida por que existe tanto medo da “política”
Cita-se como exemplo o princípio básico da Grécia Antiga de que participar da política é um dever natural do cidadão
A própria palavra ‘idiot’ teria origem em alguém apolítico
O conceito de “apolitical”, na prática,
costuma ser visto sob regimes autoritários como a postura de quem se cala e apoia implicitamente a ordem vigente
Em regimes ditatoriais como o da Rússia, isso vira um atalho para a repressão da liberdade e perseguição
Serviços como o Nostr vêm sendo bloqueados quando governos declaram a operação de relays ilegal ou criminosa
“Se tudo é política, então política não é nada”
Parece que o autor só quer evitar discussões não técnicas
“apolitical” também pode ser interpretado como significando que todos são bem-vindos
A única barreira de entrada é ter conexão com a internet
Isso provavelmente foi escrito como reação à tendência de censura nas redes sociais nos últimos 10 anos
Algumas pessoas também defendem que “devemos usar os privilégios de certa posição para ajudar os outros”
Isso também pode se aplicar aqui