Nostr Está Se Centralizando. Por Design

01. listas de relay padrão são um ponto único de falha

todo cliente importante vem com uma lista de relay padrão hardcoded. Damus, Primal, Amethyst — todos fazem isso. quando lançaram, descoberta de relay não existia, então os desenvolvedores hardcodearam o que estava funcionando e era confiável. racional. temporário.

exceto que temporário virou permanente. a rede prática agora é de 10–15 servidores bem conhecidos. operadores sabem disso. governos sabem disso. três relays cumprem uma ordem judicial e eu perco o acesso de escrita ao grafo social que achei que era meu.

um sistema descentralizado com padrões centralizados é um sistema centralizado — só com latência extra.

02. NIP-65 está correto. também é amplamente ignorado.

NIP-65 define duas listas no meu perfil: relays para os quais escrevo (outbox) e relays dos quais leio (inbox). se todo mundo publica nos seus próprios relays declarados, os dados se distribuem naturalmente — minhas notas ficam onde escolhi colocá-las. meu cliente busca suas notas nos seus relays declarados, não em um índice central. a topologia da rede espelha o grafo social.

na prática o lado outbox funciona parcialmente. a falha silenciosa é o fallback: se meu relay está lento, o cliente escreve em um relay padrão sem nenhuma indicação de que isso aconteceu. o lado inbox é pior — a maioria dos clientes consulta os mesmos 10–15 relays grandes e assume que minhas notas chegaram lá por replicação. às vezes chegaram. frequentemente só parcialmente.

NIP-65 depende de relays conversando entre si. essa camada de gossip nunca foi construída adequadamente. então clientes não podem confiar que buscar nos relays declarados retorna uma imagem completa — e caem de volta para os grandes.

o que é autorrealizável. relays grandes acumulam tudo porque clientes continuam escrevendo lá como backup, tornando-os mais completos, fazendo clientes depender mais deles. clientes tentaram enforçar o modelo outbox estritamente — notas sumiram, pessoas reclamaram, o enforcement foi revertido. então NIP-65 ganha menção honrosa nos readmes e override silencioso em produção.

03. feeds algorítmicos precisam de alguém para rodar o algoritmo

no momento em que um cliente oferece feeds inteligentes ou descoberta, ele precisa indexar a rede inteira — ou terceirizar isso. Primal faz sua própria indexação. yakihonne também. clientes estão se tornando frontends para esses serviços, e meu par de chaves não me protege de um feed curado por um provedor de infraestrutura com seu próprio modelo de negócios e exposição jurisdicional.

sem distribuição adequada de relays, não consigo fazer descoberta pelas bordas — preciso de alguém no meio com um índice completo. o agregador preenche a lacuna, vira load-bearing. o algoritmo voltou. só fala WebSocket.

04. relays pagos recriam a economia de plataforma

relays pagos fazem sentido como defesa contra spam. mas também são pontos naturais de agregação. conteúdo de qualidade gravita para relays com uptime e filtragem. leitores seguem conteúdo. efeitos de rede entram em ação. o mercado de relays pagos vai se consolidar em um punhado de provedores dominantes — exatamente como aconteceu com hospedagem de email e todo outro protocolo federado que tocou incentivos comerciais.

o operador de relay vira a nova plataforma. ele tem meu IP, meu pagamento, meu grafo social. reconstruí o Substack em um formato de wire diferente.

05. spam foi resolvido na camada errada

filtragem de spam no nível do relay — prova de trabalho, pagamento, convite — fazia sentido em 2022. ferramental de WoT não existia, dados do grafo social eram muito esparsos, e operadores precisavam proteger seus recursos agora. então construíram portões. funcionou.

esse é precisamente o problema. uma solução funcionando remove a pressão para construir a correta — filtragem Web of Trust em nível de protocolo, criptográfica, portátil entre relays. nunca foi construída porque portões no nível do relay já "resolveram" spam. WoT continua subespecificado, a maioria dos clientes o trata como opcional, e todo novo relay padroniza para o mesmo padrão de controle de acesso.

a resposta boa o suficiente não apenas adiou a resposta certa. tornou-a estruturalmente desnecessária — até que toda a arquitetura dependesse do workaround.

06. clientes competem por retenção, não por soberania

desenvolvedores de clientes enfrentam os mesmos incentivos de qualquer app social: DAU, duração de sessão, receita. as funcionalidades que importam para descentralização — diversidade de relays, filtragem WoT, cache local de eventos — são invisíveis para mim e impossíveis de vender. as funcionalidades que impulsionam retenção — feeds algorítmicos, notificações push, onboarding polido — são fáceis de lançar e fáceis de justificar.

soberania não tem métrica. então é desprioritizada a cada sprint até virar um toggle em configurações que ninguém abre. a estrutura de incentivos faz essa escolha — não os desenvolvedores.

07. o modelo de incentivos é quebrado por design

operadores de relay e eu queremos coisas diferentes — e o protocolo não reconcilia isso.

o incentivo de um operador é uptime, controle de custo, prevenção de spam. nada disso requer servir meus dados de forma confiável. um relay que silenciosamente descarta eventos de contas de baixo tráfego ainda é comercialmente viável. para o operador, perda aceitável. para mim, meu conteúdo desaparecendo sem explicação.

eu quero meus dados nos meus termos. o operador quer um negócio sustentável. na ausência de enforcement do protocolo, os incentivos deles vencem — eles controlam a infraestrutura.

relays pagos não resolvem isso. o que estou comprando é acesso de escrita, não disponibilidade garantida. relays gratuitos têm o problema inverso — rodam na boa vontade, e quando ela acaba o relay cai e leva seu histórico junto. em ambos os casos, não há garantia criptográfica de que meus dados persistem. estou confiando em infraestrutura da mesma forma que confio em um provedor de cloud — que é exatamente o que eu deveria estar fugindo.

08. desenvolvedores perderam o ponto

existe outra camada de falha que não é discutida suficientemente — como os próprios desenvolvedores se relacionam com o protocolo.

Nostr acaba sendo um backend conveniente. nenhum banco de dados para manter. nenhuma dor de cabeça com conformidade GDPR. nenhum sistema de auth para construir. publique um evento assinado, deixe relays cuidarem do armazenamento, pronto. existem threads no Stacker News onde desenvolvedores seriamente perguntam se podem substituir seu banco de dados por um relay Nostr — usando-o como key-value store pessoal para apps de anotações, sem interesse em resistência à censura ou grafos sociais. só "é mais fácil do que rodar Postgres."

isso não está errado exatamente. o protocolo permite. mas reflete um padrão: uma parcela crescente do ecossistema está sendo construída por desenvolvedores que descobriram Nostr como conveniência de infraestrutura, não como primitivo de resistência à censura. o resultado aparece. apps que conectam a um único relay hardcoded. clientes que pulam UX de gerenciamento de chaves porque "usuários não se importam." projetos que usam Nostr para coordenação mas armazenam os dados reais no S3.

existe até um repositório no GitHub — awesome-nostr-possibilities — que existe especificamente porque pessoas perceberam que Nostr estava sendo tratado como "Mais Um Protocolo de Mídia Social" e nada mais. o título do repo é um aviso: Nostr vai falhar se ficar sendo só mais um protocolo social. esse aviso é de 2023. o ecossistema não ouviu.

a abertura do protocolo — a funcionalidade que o torna poderoso — está sendo aproveitada por conveniência enquanto as propriedades que o tornam significativo são silenciosamente descartadas.

a oportunidade perdida é real. Nostr não é um atalho de backend. é infraestrutura para um novo modelo de confiança — dados assinados, identidade portátil, grafos sociais controlados pelo usuário. desenvolvedores que o tratam como substituto de banco de dados estão construindo sobre a fundação sem entender para que serve a fundação. e cada app que lançam ignorando soberania torna a rede um pouco mais normal, um pouco mais parecida com o que já temos.

09. soberania real é atualmente uma funcionalidade para power users

é aqui que a falha se torna estrutural de uma forma diferente: agora mesmo, soberania de dados genuína no Nostr requer rodar seu próprio relay. isso significa um servidor, um domínio, manutenção, custo. é alcançável — mas só para pessoas com profundidade técnica e motivação para fazê-lo.

todo mundo mais confia na lista de relay padrão e chama isso de descentralizado.

o protocolo prometeu soberania para todos os usuários. o que entregou é soberania para quem está disposto a operar infraestrutura — e uma falsa sensação dela para todo o resto.

isso não é inteiramente uma falha. pode ser de fato o modelo honesto. nem todo usuário precisa do mesmo nível de soberania, e nem todo usuário deveria arcar com o mesmo ônus de infraestrutura. mas o ecossistema atual não torna esse tradeoff legível — apresenta o uso casual de relay como equivalente ao armazenamento soberano, o que não é.

a versão honesta do Nostr parece em camadas: power users rodam seus próprios relays, controlam seus dados de ponta a ponta e obtêm garantias criptográficas. todo o resto escolhe um relay em que confia, aceita o tradeoff e obtém pelo menos uma identidade portátil e resistência à censura na camada da chave — mesmo que não na camada de armazenamento. isso ainda é significativamente melhor do que Web2. mas requer ser honesto de que soberania total não é o padrão, é algo que você tem que construir para si mesmo.

o que falta é o ferramental para tornar esse caminho acessível. um relay pessoal com um clique. compromissos de armazenamento que são verificáveis sem rodar sua própria infraestrutura. reputação baseada em WoT para operadores de relay para que eu possa tomar uma decisão de confiança informada em vez de usar por padrão quem quer que o cliente hardcodeou.

o teto para power users é alto. o piso para todo o resto é mais baixo do que deveria ser. a lacuna entre eles é onde a maior parte do ecossistema vive — e onde a maior parte da centralização se esconde.

o que precisa mudar

filtragem WoT precisa ser o padrão, não uma opção. as ferramentas existem — NIP-02, NIP-51, pontuação de distância no grafo. a lacuna é priorização.

diversidade de relay precisa ser visível. me mostre em quantos relays únicos minhas notas se replicam. eu respondo a sinais que consigo ver.

fallbacks do modelo outbox precisam ser auditáveis. se um cliente escreve em um relay padrão porque o meu estava lento, isso deveria ser registrado e visível — não uma decisão silenciosa em segundo plano.

o caminho para armazenamento soberano precisa ficar mais fácil. relays pessoais com um clique, compromissos de armazenamento verificáveis, reputação de relay via WoT — esses reduzem o piso sem limitar o teto.

o veredicto

cada ponto de centralização aqui foi uma resposta racional a uma ferramenta faltante. listas de relay padrão porque descoberta de relay não estava pronta. agregadores porque indexação no lado do cliente era difícil demais. filtros de spam em nível de relay porque WoT não existia. desenvolvedores construindo por conveniência porque a proposta de valor mais profunda não era visível para eles.

cada problema resolvido removeu a pressão para construir o que teria prevenido o próximo. decisões estruturais lentas, cada uma razoável, se acumulando em algo quebrado. isso é mais difícil de consertar do que má intenção — porque não há nada para apontar.

o protocolo ainda vale a pena construir. mas não fingindo que entrega o que ainda não entrega. descentralização não é uma funcionalidade que você adiciona depois. é uma restrição sob a qual você constrói desde o dia um — ou passa anos retroencaixando em um ecossistema que já se otimizou em torno da sua ausência.

construindo infraestrutura WoT para Nostr em nostr-wot.com