Boletins on Nostr Compass

Nostr Compass #26

Wed, 10 Jun 2026 00:00:00 +0000

A organização Marmot Protocol abre três novos repositórios para um rascunho de protocolo v2 e uma linhagem de clientes nativos: um workspace Rust chamado darkmatter, um app SwiftUI iOS darkmatter-ios e um app Kotlin/Compose Android darkmatter-android. O Flutter Whitenoise original é arquivado. A Chama comprime dezessete lançamentos em uma semana e cruza a linha de app independente na v3.0.0 antes de entregar uma reescrita completa da UI da sala de negociação e vitrines por vendedor na v3.1.0, em cima de compartilhamentos Shamir apenas do titular, substituição de árbitros, roteamento de comunidade mundial e notificações de negociação de ponta a ponta. A Coracle lança um serviço pago de relay hospedado apoiado pela stack open source Caravel e zooid, com integração profunda com Flotilla planejada. Angor muda para mainnet por padrão na v0.2.30 e entrega um teste de financiamento UAT de 3 usuários na v0.2.29. Amethyst entrega 41 PRs não lançados continuando o trabalho de NIP-32 / NIP-F4 / Tor da semana passada. NIP-67 (dica de completude EOSE) e autocompletar de NIP-50 são mesclados, fechando duas lacunas de correção de longa data no protocolo de relay central. NIP-GART propõe um formato de fio de preservação de privacidade para alertas de emergência, e NIP-46 ganha um método de logout.

Destaques principais

Marmot v2 (Dark Matter): redraft do protocolo, clientes nativos, app Flutter arquivado

Três novos repositórios surgiram sob a organização GitHub marmot-protocol esta semana, juntos formando a forma de progresso inicial de um rascunho do protocolo Marmot v2 e uma linhagem de clientes nativos que substitui a linha do app Flutter. darkmatter (Rust, criado em 13 de maio, trinta e quatro commits nos últimos sete dias) mantém o rascunho do protocolo v2 em spec/, um motor CGKA baseado em OpenMLS em crates/cgka-engine, um simulador de conformidade com testes de propriedade, e um modelo formal Tamarin para provas de convergência. darkmatter-ios (Swift, criado em 25 de maio) é um cliente SwiftUI apoiado por um xcframework UniFFI MarmotKit vendorizado gerado a partir do workspace Rust. darkmatter-android (Kotlin/Jetpack Compose, criado em 25 de maio) fica sobre os mesmos bindings Rust. O Flutter Whitenoise original foi marcado como whitenoise-archive (“ARQUIVADO: Este era o app Flutter original do White Noise”); um novo repositório Dart whitenoise carrega a linha Flutter ativa em paralelo.

Leia isto como progresso inicial em direção a um Marmot mais confiável, não como uma virada terminada. O README do darkmatter se rotula como “Rascunho candidato do protocolo Marmot v2, motor CGKA e workspace de conformidade” e diz diretamente: “MDK permanece a implementação Rust do protocolo implantada até que este rascunho e motor sejam adotados”. Dentro do workspace, a crate cgka-engine está marcada como 0.1.0, “único consumidor interno, não estável em semver”. Cada página de spec traz “Status: rascunho para revisão interna”. Três estrelas no repositório do workspace e zero nos apps iOS e Android confirmam que o trabalho está pré-anúncio. Direção, escopo e disciplina são o sinal aqui; a prontidão para produção não é a alegação.

O rascunho do protocolo torna concretos os deltas de v1 para v2. A extensão MLS marmot_group_data monolítica do MIP-01, que carregava nome do grupo, descrição, pubkeys de admin, id de roteamento de grupo Nostr, lista de relays, dados de imagem do grupo e configurações de mensagens que desaparecem sob um único guarda-chuva desde o início do Marmot, é dividida em componentes de app versionados: marmot.group.profile.v1 para nome e descrição, marmot.group.admin-policy.v1 para pubkeys de admin, marmot.transport.nostr.routing.v1 para o nostr_group_id aleatório e a lista canônica de relays, marmot.group.blossom.image.v1 para hash da imagem, chave de criptografia, nonce e chave de upload, e marmot.group.message-retention.v1 para segundos de mensagens que desaparecem. Cada componente é dono dos seus bytes exatos e do seu próprio caminho de versionamento, então um recurso futuro pode revisar um componente sem forçar o resto do estado do grupo a repisar o consenso da extensão MLS. As credenciais MIP-00 também ganham um novo documento fundamental account-identity-proof-v1.md, chamado como “novo em v2 e disruptivo”. A prova de identidade agora vive na sua própria superfície, separada da construção do KeyPackage.

Os deltas de biblioteca sustentam a retrabalho do spec. cgka-engine é a nova máquina de estado local do grupo: ela envolve OpenMLS, é dona dos estados de época Stable, PendingPublish, Merging e Recovering, traduz intenções em commits MLS, retorna valores tipados IngestOutcome e GroupEvent para cada envelope de transporte de entrada, e explicitamente não entrega nem transporte nem persistência. Uma trait TransportPeeler separa Nostr do motor, e uma trait StorageProvider separa SQLite (via storage-sqlite, apoiado por SQLCipher) do motor. O MDK de hoje empacota tudo isso junto; dividir as camadas permite que um motor fique sob um transporte de relay Nostr agora e sob os também entregues transportes de fluxo QUIC e broker mais tarde, sem reescrever o modelo de convergência. A convergência em si é documentada como distributed-convergence.md e provada em um modelo Tamarin que cobre seleção determinística de branch, elegibilidade fechada por política, reprodução de âncora retida, rejeição de branch obsoleto, reordenação de entrega, duplicação, invalidação de saída de app, transferência welcome/commit, consumo de proposta e limitação de saída durante sincronização. Testes de propriedade em Rust então verificam que o motor segue as mesmas regras com objetos OpenMLS reais e a estrutura do simulador. Trabalho de confiabilidade em métodos formais desta escala está ausente da stack Marmot atual.

Ambos os clientes nativos abandonam Flutter por toolkits de UI nativos da plataforma. darkmatter-ios é puro SwiftUI com uma Notification Service Extension que descriptografa despertares de push MIP-05 no dispositivo, vendoriza um pacote Swift MarmotKit gerado construído a partir do workspace Rust, e se registra sob o bundle ID dev.ipf.darkmatter e grupo de app. darkmatter-android é Kotlin e Jetpack Compose, com uma build orientada por just que produz um APK arm64-v8a assinado e lê endpoints de telemetria de local.properties. O README do Android declara o princípio arquitetural diretamente: “Dark Matter é dona dos dados do protocolo e os armazena em SQLite. O app Android deve renderizar esses dados, gerenciar o comportamento da plataforma Android e manter o estado do ciclo de vida da UI. O app Android não deve se tornar uma segunda base de dados para dados de Dark Matter”. Isso espelha a disciplina de fronteira que o README do cgka-engine impõe na camada Rust, aplicada à camada de UI.

Clientes nativos importam para Marmot porque a fraqueza mais citada do protocolo tem sido a confiabilidade móvel sob condições de entrega irregulares: despertares de notificação de prazo perdido, corridas de commit MLS durante flaps de rede, limites de busca em segundo plano que encalham avanços de época. SwiftUI e Compose dão aos clientes acesso direto a primitivos de processamento em segundo plano da plataforma que o Flutter alcança através de uma ponte de plugin, e o caminho de binding UniFFI mantém a lógica do protocolo em um único workspace Rust entregue como uma biblioteca estática em ambas as plataformas. A linha do Flutter Whitenoise continua no repositório whitenoise não arquivado, então o anúncio é aditivo: uma nova linhagem de cliente nativo roda ao lado do app Flutter enquanto o spec v2 converge. A troca de produção do MDK ou do app Whitenoise atual espera pelo rascunho, motor e clientes atingirem lançamentos prontos para produção.

Chama v2.0.0 até v3.1.0: escrow P2P independente em uma semana

O cliente de escrow P2P nativo do Nostr introduzido na Newsletter #25 na v1.3.0 entregou dezessete lançamentos taggeados nos últimos sete dias, terminando na v3.1.0 em 9 de junho com uma reescrita da UI da sala de negociação e vitrines por vendedor. A trilha de versões conta a história: v2.0.0 é a base DISRUPTIVA, então v2.0.1, v2.0.2 e v2.0.3 fecham as lacunas do trilho de financiamento Fedi WebView; v2.1.0, v2.2.0, v2.3.0 e v2.3.1 reforçam a camada de árbitros; v2.4.0, v2.5.0 e v2.6.0 adicionam superfícies de auto-custódia e roteamento de comunidade mundial; v2.7.0, v2.8.0, v2.9.0 e v2.10.0 camadam cópia de chave em inglês simples, aplicações de grupo, arbitragem de prazo de disputa e reputação. v3.0.0 amarra o pacote com notificações de negociação de ponta a ponta, e v3.1.0 em 9 de junho redesenha a tela de negociação em torno de uma espinha de progresso Reservado → Bloqueado → Liquidado, cartões de ação coloridos por papel e uma classe de listagem de vitrine por vendedor (swaps curados, livros de empréstimos e faturas).

O pivô arquitetural vive na v2.0.0. O formato LOCK de escrow mudou para que cada compartilhamento de uma divisão Shamir 2-de-3 seja criptografado apenas para seu titular (sharePolicy holder-only-v1). O ecash ao portador da federação não reconstrói mais a partir de um único participante sozinho, fechando um caminho onde uma parte maliciosa com seu próprio compartilhamento e um compartilhamento mantido pela federação poderia completar a negociação sem consentimento. Clientes pré-2.0 falham em voz alta com “não consegue encontrar seu compartilhamento”; a negociação não pode completar em um cliente obsoleto, e nenhum fundo é perdido no processo. Um bloqueio v2.0 requer que cada parte na v2.x liquide. A v2.0.0 também adicionou vitrines multi-unidade e uma visualização de Mercado apenas em sats.

A v2.1.0 introduziu a substituição de árbitros: o compartilhamento do árbitro no índice 2 de Shamir agora é criptografado para uma ordem de prioridade determinística sobre o pool de árbitros da comunidade, então um árbitro ausente pode ser substituído sem encalhar a negociação. A v2.2.0 provou que a substituição funcionou em campo em uma negociação de ₿121 e adicionou backups de substituição de cura. A v2.3.0 fechou a última lacuna de front-running de árbitros verificando a associação do árbitro à comunidade da listagem no momento do bloqueio, e a v2.3.1 fechou a corrida irmã onde um slot de árbitro auto-atribuído era uma prévia até o bloqueio os assentar.

As superfícies de auto-custódia chegaram na v2.4.0 (frase de recuperação BIP-39 para a carteira ecash Fedimint, armazenada criptografada no Nostr) e v2.5.0 (backup master nsec que é dono da identidade Nostr e da semente da carteira). A v2.6.0 retrabalhou o onboarding em torno de um seletor de comunidade global para que usuários em países sem uma Chama local sejam roteados para a federação mais próxima; builds anteriores rebatiam o usuário sem fallback. A v2.7.0 reescreveu a tela de chave de recuperação em inglês simples (“a única chave para sua conta e o dinheiro nela; Chama nunca a vê e não pode redefini-la; se você perder, ninguém pode recuperar sua conta”). A v2.8.0 adicionou aplicações de grupo, tema escuro/claro, e adicionou dois novos kinds de evento (38120 roster, 38121 aplicação). A v2.9.0 mudou a resolução de disputas no prazo: negociações contestadas que atingem o vencimento agora resolvem por decisão do árbitro; comportamento anterior fazia reembolso automático. O lançamento é marcado COORDINATED para que todas as partes em uma disputa devem atualizar. A v2.10.0 adicionou classificações de polegar para cima/polegar para baixo por negociação como um novo kind de evento 38123.

A v3.0.0 é o marco onde o app para de precisar de uma comunidade de coordenação para operar. Notificações de negociação de ponta a ponta pingam o usuário apenas em transições de estado acionáveis: contraparte bloqueou os sats, pagamento pronto para reivindicar, disputa requer a decisão do usuário como árbitro, ou negociação liquidada ou expirada. Um toggle na tela Eu liga ou desliga as notificações, e o prompt de permissão dispara apenas quando o toggle está habilitado. O dedup fire-once impede que uma recarga de estado dispare uma tempestade de alertas. Um bug de guardrail chama-errada também foi fechado no PR #103, onde versões anteriores podiam carimbar uma listagem com o rótulo de uma chama mas a federação de outra chama. Bundles desktop para Windows e Linux são entregues com o lançamento; o dmg macOS é retido até que assinatura e notarização cheguem.

Chama agora se junta a Mostro e Shopstr como um marketplace nativo do Nostr, distinguido por arquitetura sem servidor, escrow Shamir 2-de-3 apoiado por Fedimint, criptografia de compartilhamento apenas do titular, e o único dos três que entrega um cliente desktop e móvel autocontido sem uma comunidade de coordenação.

Coracle Hosting: serviço de relay pago mais stack Caravel open source

Em 3 de junho, Hodlbod anunciou o Coracle Hosting em hosting.coracle.social, um serviço de relay de comunidade hospedado que aceita pagamentos lightning recorrentes por NWC ou cartão. O serviço é alimentado por Caravel, o frontend de cobrança e provisionamento da Coracle, e zooid, um runtime de relay que hospeda muitos relays virtuais em uma única máquina. Ambos são open source no gitea auto-hospedado da Coracle. Caravel entrega com integração opcional livekit e Blossom que operadores podem alternar por relay. Um tier gratuito com limites de contagem de membros permite que operadores avaliem o serviço antes de comprometer detalhes de pagamento.

Hodlbod é sincero sobre o modelo de negócio: monetizar open source vendendo uma versão hospedada de uma stack que qualquer outra pessoa também pode rodar. O fosso competitivo é a integração Flotilla, que é o próximo passo planejado. Flotilla é dona da superfície do usuário, então a opção hospedada servida de dentro da Flotilla se torna o caminho padrão para qualquer usuário que prefira infraestrutura gerenciada. Hodlbod ofereceu adicionar outros operadores Caravel ao seletor de hospedagem alternativa da Flotilla se eles entrarem em contato, mantendo a porta aberta para um mercado de hospedagem federado.

Caravel se junta a relay.tools como uma plataforma pública de provisionamento de relay Nostr com tiers de membros pagos. relay.tools precede Caravel e entrega como o serviço criador de relay dominante hoje, com seu próprio diretório de relays de comunidade e fluxos de entrada de membro pago ou moderador. O recurso distintivo do Caravel é a stack coordenada: o runtime de relay (zooid), o frontend de cobrança e provisionamento (Caravel em si), e o seletor do lado cliente (integração Flotilla, ainda em voo) entregam como um design. O outro recurso distintivo é a densidade de muitos-relays-por-processo do zooid, onde relays de clientes compartilham um único processo host para que o operador amortize custos de hospedagem em muitas pequenas comunidades. Este é o mesmo argumento de densidade que tornou hospedagem web compartilhada viável nos anos 2000 iniciais, aplicado à camada de relay do Nostr.

Lançamentos

Angor v0.2.29 e v0.2.30: padrão mainnet e teste de financiamento UAT de 3 usuários

Angor v0.2.29 em 4 de junho e v0.2.30 em 8 de junho são os dois lançamentos desta semana para o protocolo descentralizado de financiamento Bitcoin-e-Nostr. A mudança de destaque da v0.2.30 é o PR #893, que muda a rede padrão para mainnet. Angor ainda entrega como um lançamento alpha instável, mas a mudança de padrão-mainnet sinaliza que o protocolo passou da fase apenas-testnet para os clientes desktop e móvel. A v0.2.30 também entrega um fluxo móvel de criar-projeto de único toque com upload de imagem e reset de scroll (PR #889) e resolve uma condição de corrida onde o spinner de fatura lightning podia travar (PR #890).

A v0.2.29 adicionou um teste UAT de ponta a ponta no PR #881 cobrindo envio de fundos de 3 usuários em 10 rodadas com gastos não confirmados, o primeiro teste de fluxo de financiamento multi-usuário na suíte de testes do Angor. O lançamento também adicionou um plano de implementação para um CLI Angor e servidor MCP (PR #792), com melhorias no CLI para o fluxo de teste MCP no PR #880. O PR #885 por DavidGershony corrigiu uma fatura lightning Boltz que usava a rede errada após uma troca de rede em runtime, um bug que teria aparecido em produção após o padrão mainnet da v0.2.30. Configurações agora oferecem uma purga opcional de arquivo de carteira de recuperação durante limpeza de dados (PR #883).

Sprout v0.3.15: atualização de TTL de canal efêmero e comandos slash ACP

Sprout v0.3.15, lançado em 10 de junho, é o oitavo lançamento em uma sequência que começou com a v0.3.7 em 2 de junho. Newsletter #25 cobriu a sequência v0.3.1 a v0.3.6 com o trabalho de integração mesh-llm e seções de canal; v0.3.7 até v0.3.15 são a jusante disso, focados em polimento e algumas adições voltadas ao usuário. A mudança mais visível ao usuário é uma atualização de TTL para canais efêmeros no PR #902: quando um usuário desarquiva um canal efêmero, Sprout estende o time-to-live do canal para que o desarquivamento não re-arquive imediatamente sob o timer de expiração original. Emojis customizados móveis chegam no PR #906 junto com um redesign de configurações, e contagens de reação agora animam em mudança (PR #904).

O PR #905 corrige uma lacuna de longa data onde nomes de exibição de múltiplas palavras quebravam e a extração de menção NIP-27 nostr:npub era silenciosamente dropada. Uma UI de equipe suportada por diretório para desktop entrega no PR #912 com comandos de instalar, sincronizar e revelar. Comandos slash agora passam através para conectores ACP no PR #919, permitindo que Sprout encaminhe comandos estilo /help diretamente para runtimes de agente enquanto a UI Sprout fica fora do caminho.

Wisp v1.1.1: integração com carteira Spark e guarda de colagem nsec

Wisp v1.1.1, lançado em 5 de junho, entrega uma tela de conexão de carteira de duas camadas com sub-tela Spark no PR #548 e paridade de dashboard com a UI de carteira iOS no PR #549. O lançamento inclui uma guarda de colagem nsec para todo o sistema que detecta uma colagem prefixada com nsec1 em qualquer lugar do app e bloqueia o campo de aceitá-la, fechando um dos footguns mais citados em UX Nostr. Login com scan de QR mais um modo somente visualização para npub e nprofile entrega no PR #552, permitindo que um usuário navegue em um perfil somente leitura. Mensagens de Zap agora renderizam como mini-posts na gaveta de engajamento (PR #559) para que notas de zap carreguem seu texto ao lado do valor em sats. Um filtro de rede de confiança em respostas de thread entrega no PR #583, permitindo que usuários escondam spam de resposta de contas fora do seu grafo de follow.

Nostria v3.1.46 e nospeak 1.1.3: retrabalho de notificações e reinicialização ICE

Nostria v3.1.46 em 7 de junho termina uma sequência de três lançamentos que retrabalhou o contador de notificações para contar apenas novas notificações desde a última visualização, eliminando uma inflação de longa data onde carregar notificações antigas através de scroll aumentava a contagem do badge. Nostria v3.1.45 corrigiu um bug de pagamento dividido afetando pagamentos lightning e código QR e abandonou uma UI translúcida previamente planejada como inviável no compositor do Android.

nospeak v1.1.3 em 4 de junho adiciona reinicialização ICE em estado FAILED para chamadas de voz 1 para 1. Comportamento WebRTC padrão dropa uma chamada quando candidatos ICE dão timeout sem um caminho alternativo; o caminho de reinicialização ICE renegocia candidatos para que a chamada se recupere de mudanças transitórias de NAT ou rede. Chamadas Android agora mantêm a tela ligada durante chamadas de vídeo.

Mudanças não lançadas

Amethyst: 41 PRs continuando a trilha NIP-32 / NIP-F4 / Tor

Amethyst mesclou 41 PRs esta semana sem cortar uma tag de lançamento, em cima dos 52 PRs da semana passada e do trabalho de rotulagem de hashtag NIP-32 e podcast NIP-F4 coberto na Newsletter #25. A branch ativa continua a acumular recursos para o próximo lançamento taggeado, camando polimento sobre as adições de destaque da semana passada: descoberta de rotulador de hashtag, tela de podcast, faixas e playlists de música, watchdog de auto-cura Tor, assinantes efêmeros para uploads anônimos, e zaps onchain com filtragem NIP-05. O throughput de PRs do Amethyst permanece o mais alto de qualquer cliente Nostr, e a fila não lançada é o roadmap de facto para o que outros clientes Nostr Android precisarão igualar.

Damus: rastreamento de relay a partir de mensagens OK e changelog v1.17

Damus PR #3786, mesclado em 3 de junho, adiciona mensagens OK bem-sucedidas de um relay à lista de relays pós-post. Builds anteriores do Damus populavam a lista de relays vistos apenas ao receber uma mensagem genérica do relay, o que significava que um relay que reconheceu o post mas não entregou nenhum evento de volta era invisível para o usuário. A mudança importa para usuários que querem confirmar que seu post chegou no seu relay de outbox preferido. O PR #3796 corrige um ciclo AttributeGraph na Visualização de Perfil, e o PR #3725 entrega o changelog v1.17 antes do próximo lançamento taggeado.

Shopstr: dupla publicação NIP-34

O repo shopstr da Shopstr no ngit foi anunciado no Nostr esta semana como um repo git NIP-34, juntando-se aos repos rastreados do ngit. O repo GitHub do cliente da loja permanece a superfície primária de desenvolvimento; o anúncio NIP-34 torna disponível um caminho paralelo de colaboração git-sobre-Nostr. Este é o segundo grande projeto marketplace Nostr a publicar duplamente no NIP-34 depois do Mostro, e continua a migração gradual de metadados de projeto para o transporte git do Nostr.

Hermes-Marmot: gateway de agente IA sobre MLS

hermes-marmot, um plugin para o Hermes Agent, conecta a superfície de mensagens de um agente IA a grupos Marmot (MLS-sobre-Nostr) usando mdk-python, os bindings Python para o Rust Marmot Development Kit. O plugin permite que um usuário envie DM a um agente IA de qualquer cliente Nostr que fale mensagens MLS kind 445, incluindo o Whitenoise. DMs de entrada usam desembrulho de gift wrap NIP-59 via bindings Python nostr-sdk, e welcomes de entrada fluem através de UnwrappedGift.from_gift_wrap para mdk.process_welcome e mdk.accept_welcome. Controle de acesso roda através de MARMOT_ALLOWED_USERS (uma lista de permissão npub separada por vírgulas) ou MARMOT_ALLOW_ALL_USERS=true para acesso de dev aberto.

O repo é novo (última atualização em 27 de maio) e pequeno. Sua significância é arquitetural: é a primeira ponte pública entre um runtime de agente LLM e um canal de mensagens Nostr criptografado com MLS, e o primeiro uso em produção de mdk-python além do próprio Whitenoise. O padrão aponta para comunicação agente-para-agente onde ambos os endpoints seguram chaves MLS e o relay vê apenas o texto cifrado.

Atualizações NIP e trabalho em specs de protocolo

NIP-67 dica de completude EOSE (PR #2317) mesclada

O PR #2317 por mattn foi mesclado em 6 de junho, adicionando NIP-67 ao protocolo. O NIP estende a mensagem de relay EOSE com um terceiro elemento opcional: ["EOSE", <subscription_id>, "finish"] sinaliza que todo evento armazenado correspondente ao filtro foi entregue, enquanto um ["EOSE", <subscription_id>] nu não carrega alegação de completude. Um relay que omite a dica está dizendo ao cliente que pode haver mais; um relay que omite o anúncio NIP-67 no NIP-11 mantém o comportamento de hoje sob a heurística legada existente. A mudança é retrocompatível em ambas as direções: clientes legados ignoram o elemento de array final, e relays legados o omitem.

A motivação no spec mesclado é dupla. Primeiro, perda silenciosa de dados: um cliente pede as últimas 500 notas contra um relay com um cap interno de 300 eventos, o relay retorna 300 eventos, e o cliente (usando a heurística padrão received < limit) conclui que o resultado está completo. As notas de correspondência de 201 até N mais antigas ficam no relay não lidas, com o cliente cego para esse fato. Segundo, viagens de ida e volta obrigatoriamente desperdiçadas: quando um relay limita respostas em 300 eventos, qualquer subscrição que exaure o cap requer um segundo REQ com until=<oldest_created_at> puramente para confirmar completude, mesmo quando o filtro por acaso corresponde exatamente a 300 eventos. Ambos os modos de falha são pagos por cada cliente em cada subscrição com cap exaurido. A dica "finish" é uma string opcional em uma mensagem existente e elimina ambos os custos.

Extensão de autocompletar NIP-50 (PR #2357) mesclada

O PR #2357 por Alex Gleason foi mesclado em 6 de junho, adicionando um token autocomplete:true/false à busca NIP-50. A extensão permite que um cliente marque uma consulta como uma busca typeahead para que o relay use correspondência de prefixo, com busca de texto completo como padrão para consultas sem o token. O relay Ditto o implementa para pacotes de follow, listas, e qualquer evento com uma tag title, retornando correspondências contra o prefixo do título; o caminho de busca padrão executa pontuação de texto completo. Sem este token, UIs estilo autocompletar não tinham maneira de comunicar a intenção de busca de prefixo e relays tinham que adivinhar da forma da consulta. O token é uma dica por-busca, não uma capacidade de todo o relay, então um relay pode implementá-lo para uma classe de eventos (títulos) sem alegar suporte geral de autocompletar.

NIP-GART alertas de emergência e broadcasts de localização (PR #2374)

O PR #2374 por disinqa, aberto em 9 de junho, define um formato de fio de preservação de privacidade no Nostr para alertas de emergência e broadcasts de localização endereçados a um grupo de destinatários confiáveis. O objetivo de design declarado é esconder identidade do remetente, associação ao grupo e payload dos operadores de relay enquanto mantém os eventos seguros contra replay e verificáveis por assinatura de ponta a ponta. Número NIP ainda TBD, proposta em rascunho inicial. Caso de uso é o padrão de alerta de emergência padrão: um usuário sob ameaça transmite um ping de localização que apenas um grupo pré-compartilhado de contatos confiáveis pode descriptografar, com o relay cego para remetente, conjunto de destinatários e payload. Detalhes do formato de fio vivem no PR e provavelmente evoluirão à medida que os mantenedores revisem.

Método logout NIP-46 (PR #2373)

O PR #2373 por hzrd149, aberto em 8 de junho, adiciona um método logout ao NIP-46 para que um cliente possa dizer a um bunker explicitamente que a sessão terminou. Até agora, a única forma de terminar uma sessão bunker era esperar o timeout da sessão ou parar de usar a conexão, ambos os quais deixam o bunker segurando estado de sessão para um cliente que se foi. A proposta é curta (um novo método) e é o tipo de mudança de manutenção que torna integrações bunker de longa duração mais limpas.

Proposta híbrida relay-P2P NIP-95 circulada como longform

Uma especificação NIP-95 longform circulou como um post kind:30023 do npub 91bea5cd9361504c409aaf459516988f68a2fcd482762fd969a7cdc71df4451c em 4 de junho sob o título Protocolo Híbrido Relay-P2P via WebRTC. O documento em português define um protocolo relay híbrido peer-to-peer onde clientes Nostr se conectam uns aos outros diretamente via WebRTC para mensagens ao vivo enquanto continuam a usar relays para recuperação de eventos armazenados e entrega offline. O autor explicitamente enquadrou o spec como “pronto para LLM”, provendo definições de mensagem, fluxos lógicos, esquemas de dados e regras de estado em um nível de detalhe que permite que um modelo IA gere código de cliente ou servidor funcional. A proposta ainda não chegou como um PR NIP; a circulação via kind:30023 é o precursor habitual de um pull request formal nostr-protocol/nips.

NIP-44 v3 pega um segundo assinante: Clave porta o spec

O rollout NIP-44 v3 da Amber v6.2.0 da semana passada entregou antes de qualquer PR NIPs mesclado, deixando v3 como uma extensão específica da Amber que outros clientes tinham que espelhar para interoperar. Esse enquadramento de implementação única mudou esta semana. Clave, o assinante remoto NIP-46 iOS baseado em push, entregou uma porta NIP-44 v3 independente em 3 e 4 de junho em oito commits. Primitivos criptográficos entregam em três commits: camada de chaves HKDF + ECDH, o algoritmo de padding v3, e uma API pública de nível superior mais Contexto de criptografia. Em cima desses, a superfície NIP-46 segue no cabeamento de despacho RPC dentro do LightSigner e um esquema PendingRequest que carrega o contexto v3 (kind mais scope), para que o assinante possa registrar para qual kind de evento e caso de uso o payload v3 foi aprovado.

Clave diverge da Amber na superfície voltada ao usuário. Um esquema de concessão de permissão com tiers de sensibilidade permite que usuários concedam criptografia v3 para um kind de evento e scope particulares em um nível de sensibilidade escolhido. No primeiro encontro, prompts de aprovação cientes do contexto v3 com um cartão explicativo de uma vez introduzem v3 aos usuários. O trabalho está no main e está cabeado no projeto Xcode mas não lançado; a build taggeada mais recente é a v0.2.0-build79 de 12 de maio.

Duas implementações independentes entregam NIP-44 v3 em caminhos de produção antes do PR NIPs mesclar, o que fortalece o caso para o formato de fio subjacente que o PR do protocolo formalizará. Testes de interoperabilidade cross-implementação agora se tornam o caminho para a convergência do spec, com a superfície de aprovação Android da Amber e o modelo de tier de sensibilidade iOS da Clave como os dois pontos de referência. Outros assinantes remotos cabeando v3 (o noauth do nsec.app está dormente desde maio de 2025, e outros bunkers não anunciaram trabalho v3) fortaleceriam o consenso ainda mais.

Atividade NIP-34: Iris adota a stack com um novo transporte hashtree

Iris publicou anúncios de repo NIP-34 para hashtree em 8 de junho e iris-apps, iris-drive e iris-chat-rs em 9 de junho, anunciando URLs de clone sob um novo esquema htree:// servido de wss://temp.iris.to. O transporte hashtree é uma alternativa endereçada por conteúdo aos clones roteados por GRASP, e esses quatro anúncios são seus primeiros usos públicos. Os repos carregam descrições vazias e os detalhes arquiteturais ainda estão emergindo, mas a escolha de publicar via anúncio NIP-34 (sobre um manifesto Iris-interno customizado) sinaliza que Iris está se comprometendo com a stack NIP-34 git-sobre-Nostr mais ampla.

NIP em profundidade: NIP-67 (Dica de Completude EOSE)

NIP-67 fecha uma das lacunas de correção mais antigas em NIP-01. O spec original define EOSE como o limite entre eventos armazenados e eventos de subscrição ao vivo para um REQ, mas nunca especificou se o relay tinha terminado de entregar todas as correspondências armazenadas ou tinha parado no meio do caminho por causa de um cap interno. Cada relay impõe um cap por subscrição (comumente 300 a 1000 eventos) independente do limit do cliente, e clientes não tiveram maneira de observar esse cap.

A solução alternativa padrão era comparar a contagem recebida contra o limit solicitado. Se received < limit, tratar o resultado como completo; caso contrário paginar com until=<oldest_created_at>. Ambos os ramos estão quebrados. O ramo received < limit silenciosamente trunca: um cliente pedindo 500 notas contra um relay capado em 300 vê 300 eventos, conclui que o resultado está completo porque 300 < 500, e nunca busca o resto. Eventos retidos no relay não podem sinalizar “mais disponível” através de nenhuma mensagem existente. Paginação como o segundo ramo é desperdício: um filtro que corresponde exatamente ao cap requer um segundo REQ para confirmar completude, retornando zero eventos enquanto consome uma varredura completa de filtro no relay.

A correção do NIP-67 é uma string opcional na mensagem EOSE:

["EOSE", "<sub_id>", "finish"] // explícito: todos os eventos armazenados entregues
["EOSE", "<sub_id>"] // nenhuma alegação de completude

Um relay que anuncia NIP-67 no NIP-11 supported_nips e emite um EOSE nu está dizendo ao cliente que há mais. Um relay que omite o anúncio mantém o comportamento de hoje, e o cliente recorre à heurística existente. Clientes legados ignoram o elemento de array final. Compatibilidade retroativa se mantém em ambas as direções, sem novos verbos ou kinds de evento.

O que torna NIP-67 digno de examinar é o escopo que ele deliberadamente restringe. O spec não define nenhum cursor ou token de paginação, então paginação baseada em until permanece o mecanismo. Caps de relay ficam onde estão, e o NIP não requer nenhuma exposição deles. NIP-67 preserva o significado de EOSE como o limite armazenado-para-ao-vivo e apenas adiciona um sinal sim-ou-não no limite: “eu tenho mais para você” versus “isso é tudo”. Esta superfície minimalista é por que o PR foi mesclado após um período de revisão relativamente curto para uma extensão NIP-01, e por que mattn nota explicitamente no PR que tradução IA foi usada para o texto em inglês. A mudança é pequena o suficiente para que a incerteza de tradução não importe.

Exemplo de troca ciente de NIP-67 entre um cliente e um relay que impõe cap. Anúncio NIP-11 do relay:

{
 "id": "a5f87fe2d4c8b9a0e3f1c4d5e6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1781136000,
 "kind": 11,
 "tags": [],
 "content": "{\"supported_nips\":[1,11,50,67]}",
 "sig": "f1e2d3c4b5a6978869504132c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5"
}

A troca a nível de fio que segue:

→ ["REQ", "abc", {"kinds":[1],"limit":500}]
← [...300 mensagens EVENT...]
← ["EOSE", "abc"] // sem "finish": cap atingido, mais disponível
→ ["REQ", "def", {"kinds":[1],"limit":300,"until":1780900000}]
← [...178 mensagens EVENT...]
← ["EOSE", "def", "finish"] // explicitamente completo

A resposta de 178 eventos previamente teria disparado um terceiro REQ para confirmar completude. Com NIP-67 o cliente para ali.

NIP-67 também é notável como uma emenda NIP-01 chegando com consenso raro. A maioria das mudanças NIP-01 atrai longas threads de debate porque a pequena superfície do protocolo é carga-suporte para cada implementação. NIP-67 mesclou após um período de revisão estendido (aproximadamente sete semanas do aberto ao mesclado), sugerindo que quando uma mudança NIP-01 é pequena o suficiente e o modo de falha é concreto o suficiente (perda silenciosa de dados, viagem de ida e volta desperdiçada obrigatória), os mantenedores do protocolo estão dispostos a estender o vocabulário de mensagem central.

NIP em profundidade: NIP-50 (Busca)

NIP-50 define o campo de filtro search em mensagens REQ, permitindo que clientes peçam a um relay para filtrar eventos por correspondência de texto completo contra uma string de consulta. O spec base mesclado é deliberadamente minimalista: o campo search é uma string, cada relay decide sua própria semântica de busca (quais campos são indexados, como pontuação funciona, se stemming se aplica), e relays anunciam suporte NIP-50 em seu documento NIP-11. Clientes controlam o algoritmo de busca apenas através da string de consulta em si.

Este minimalismo é tanto a força quanto a restrição do NIP-50. A força é que qualquer relay pode implementar busca em qualquer nível de qualidade: uma varredura de substring básica satisfaz o spec, e um relay rodando Elasticsearch ou Meilisearch o satisfaz igualmente. A restrição é que clientes carecem de uma maneira de expressar intenção de busca. Uma UI typeahead de menção de perfil quer correspondência de prefixo contra nomes de exibição; uma busca de conteúdo de texto completo quer pontuação de texto completo tokenizada através do corpo da nota. O mesmo campo search carrega ambos, e o relay deve adivinhar da forma da consulta.

O PR #2357 adiciona o primeiro token de extensão NIP-50: autocomplete:true ou autocomplete:false embutido na consulta de busca sinaliza qual modo o cliente quer. O relay Ditto implementa o token para pacotes de follow, listas, e qualquer evento com uma tag title, mudando para correspondência de prefixo quando autocomplete:true está presente. O token vive inline na consulta (campos de filtro separados ficam intocados), então ele viaja com a string de busca e não requer nenhum bump de protocolo de fio:

search: "fiat autocomplete:true"

Dicas em forma de token como esta são como NIP-50 sempre tratou dialetos específicos de relay. Relays já suportavam tokens como language:en e domain:example.com. Cada um permanece específico de relay, com cada relay documentando seu próprio dialeto. O PR #2357 do NIP-50 eleva autocomplete de um token privado de relay para um abençoado pelo spec, pavimentando o caminho para busca ciente de typeahead através de relays.

Exemplo de REQ NIP-50 com o token autocomplete, mirando um relay que indexa títulos de perfil kind 0:

{
 "id": "b7c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f7081a2b3c4d5e6f70819a2b3c4d5",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1781136000,
 "kind": 1,
 "tags": [
 ["client", "example-mention-picker"]
 ],
 "content": "Sent search: kinds=[0], search=\"fiat autocomplete:true\", limit=10",
 "sig": "12d3e4f5061728394a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f7081a2b3c4d5e6f70819a2b3c4d5e6f7081a2b3c4d5e6f708192"
}

O REQ real a nível de fio:

["REQ", "mention-picker", {"kinds":[0],"search":"fiat autocomplete:true","limit":10}]

Um relay que não reconhece o token trata autocomplete:true como parte da string de busca literal e recorre a correspondência de texto completo, retornando resultados corretos (se classificados diferentemente). A degradação graciosa torna o token seguro para incluir incondicionalmente para clientes que preferem correspondência de prefixo quando disponível.

A próxima extensão provável do NIP-50 é controle de classificação por-kind: uma dica que diz “classificar por created_at descendente” versus a pontuação de relevância padrão. Vários relays já aceitam sort:newest como um token privado de relay, e o mesmo caminho de elevação que trouxe autocomplete para o spec se aplica. Busca permanece um dos poucos primitivos Nostr onde relays competem em qualidade de resultado; confiabilidade de entrega é a mesma através de todos os relays conformes. Tokens incrementais permitem que clientes explorem essa competição de qualidade sem forçar relays a entregar um novo spec de peso pesado.

Nostr Compass #25

Wed, 03 Jun 2026 00:00:00 +0000

Amber 6.2.0 lança criptografia NIP-44 v3 antes da especificação. Mostro traz a fundação para escrow liquidado em Cashu em oito PRs, envolvendo o Cashu Development Kit existente como um segundo backend de liquidação junto com Lightning. NIP-F4 podcasts foi mesclado após 27 meses de debate. fiatjaf abre uma proposta contestada de desacoplamento de chave NIP-17 que reabre o argumento arquitetural bunker-versus-Marmot. Amethyst traz labeling de hashtag NIP-32, uma tela dedicada de podcast e zaps onchain em 52 PRs não lançados.

Matérias principais

Amber 6.2.0: criptografia NIP-44 v3 lançada

Amber v6.2.0, lançado em 1º de junho, adiciona suporte a criptografia NIP-44 v3 com uma tela dedicada de aprovação, preview de intent, preview de bunker, log de histórico e auto-rejeição para requisições inválidas. A release também registra autoridades ContentProvider NIP-44 v3 para que outros apps Android possam solicitar criptografia v3 junto com o caminho v2 existente. NIP-44 em si é a especificação de payload criptografado versionada usada por DMs privadas NIP-17, tráfego bunker NIP-46, e outras primitivas Nostr; v3 no Amber é opt-in junto com v2, sinalizada por um método de signer separado para que clientes do lado receptor possam negociar o algoritmo explicitamente. O PR correspondente nos NIPs ainda não chegou, então o Amber está lançando v3 antes do consenso de protocolo, com o formato de fio e autoridade ContentProvider registrados para integração de cliente downstream.

Sessões NIP-46 agora auto-aceitam requisições de ping na conexão, removendo o prompt na primeira ida-e-volta após pareamento. O método de signer sign_message foi removido inteiramente após ter sido descontinuado e não usado.

Como o Amber é o signer Android dominante, cada cliente downstream que quiser v3 tem que mirar no formato de fio do Amber até o PR dos NIPs chegar. Isso dá ao Amber influência implícita sobre a especificação final v3 até que o protocolo alcance. A troca é real: v3 em produção permite ao Amber coletar feedback de implementação para o eventual NIP, ao custo de um ponto de referência de implementação única temporário que outros clientes agora têm que igualar.

Mostro: integração de escrow Cashu via CDK

grunch trouxe oito PRs em MostroP2P esta semana integrando as primitivas P2PK multisig existentes do Cashu (NUT-10 e NUT-11) como um segundo backend de liquidação junto com Lightning no câmbio P2P Bitcoin coordenado por Nostr. As primitivas criptográficas são do Cashu; o trabalho é scaffolding de integração e uma nova trait de backend de escrow. Mostro core v0.12.0, lançado em 30 de maio, adiciona os tipos de protocolo para escrow multisig 2-de-3, assinaturas P_M por prova, e permite eventos de escrow através da validação de resposta. A arquitetura está documentada no PR #756 e usa chaves de trade por ordem esclarecidas no PR #757.

A implementação foi lançada em seis PRs subsequentes ao longo de um único dia. F2 (PR #758) adicionou a configuração, o modo de escrow e o boot condicional. A próxima fatia, F3 (PR #760), definiu uma trait EscrowBackend com uma implementação Lightning e um stub Cashu, permitindo ao Mostro trocar backends de liquidação sem mudar a máquina de estado de ordem. F4 (PR #759) envolveu o CDK (o Cashu Development Kit) para operações de mint e carteira. Trabalho de banco de dados no F5 (PR #761) adicionou locks de escrow compare-and-swap e queries active-locked. F6 (PR #762) construiu um mint containerizado em um job CI dedicado para teste de escrow ponta-a-ponta. O fluxo do Mostro já usa DMs gift-wrapped NIP-59 para coordenação de ordem sobre o relay, então o escrow Cashu se encaixa como uma segunda opção de liquidação junto com Lightning sem tocar no protocolo de fio.

Releases

ngit v2.5.0: fallback GRASP e fetches git lazy

ngit v2.5.0 muda o comportamento padrão de git push pr/<branch> e ngit send para produzir um kind PR para novas propostas quando o repositório tem pelo menos um servidor GRASP registrado. Anteriormente isso só era disparado para commits grandes acima de 60 KB ou commits contendo submódulos. Quando um PR não pode ser empurrado para os servidores GRASP do repositório, ngit agora recorre ao roteamento GRASP-06 através dos servidores declarados. A flag ngit send --git-server ou git push -o git-server=<url> permite aos contribuidores mirar em uma URL git customizada ou servidor GRASP explicitamente.

Republicações ngit init agora preservam tags desconhecidas de anúncios existentes, para que tags adicionadas por uma versão futura do ngit ou ferramenta de terceiros sobrevivam à republicação. Um aviso amarelo lista as tags carregadas, e --clean as remove sob demanda. ngit pr apply, ngit pr checkout e ngit pr list consultam servidores git de forma lazy e compartilham um único helper de fetch, para que o checkout não faça mais fetch incondicionalmente quando o commit já está local. ngit pr checkout também tenta URLs de clone fornecidas pelo submitter do evento PR como fallback quando os servidores git declarados do repo não carregam o tip do PR, correspondendo ao comportamento existente em ngit pr apply. ngit é a implementação de referência NIP-34 para colaboração git sobre Nostr, e v2.5.0 torna GRASP o caminho de primeira classe para novos contribuidores.

Jumble v26.5.7: remoção de EXIF e contagens de zap validadas

Jumble v26.5.7 adiciona duas mudanças que afetam a privacidade do usuário e a integridade de dados diretamente. Localização EXIF e identificadores de câmera agora são removidos de uploads de imagem antes que deixem o cliente, fechando uma superfície de longa data de vazamento de metadados que afetava cada imagem postada do Jumble. Contagens de zap agora são computadas apenas a partir de recibos criptograficamente validados, corrigindo contagens infladas de eventos de zap malformados que haviam permitido a atacantes exagerar totais de zap em notas. A release também adiciona verificação de identidade do remetente para DMs NIP-17, fechando uma superfície de spoofing onde um remetente podia forjar sua pubkey no seal.

nostr-calendar v1.6.0: RSVP e tratamento de participantes duplicados

nostr-calendar v1.6.0 traz o fluxo de RSVP do Formstr (PR #169) e evita participantes duplicados em convites de evento (PR #168). A opção waitForAll na função de publish agora tem padrão false para que a UI não bloqueie em relays lentos (PR #170). PR #157 lançou os dois rascunhos de proposta NIP do Formstr para agendamento de compromissos e reservas.

Sprout 0.3.6: Sprout × mesh-llm e seções de canal

Sprout v0.3.6 é o destaque de uma sequência de seis releases de v0.3.1 a v0.3.6 esta semana. Integração in-process Sprout × mesh-llm chega no PR #798, permitindo ao Sprout servir e consumir nós mesh-llm através de admissão de relay. Seções de canal definidas pelo usuário sincronizam entre dispositivos via Nostr no PR #792, e seções de canal chegam ao mobile com sync de relay no PR #800. Notificações conscientes de thread com controles mutáveis de follow e mute chegam no PR #761.

Anexos de tipo de arquivo arbitrário com cards de download chegaram no PR #810, expandindo o Sprout além de anexos apenas de imagem. Mobile ganhou uma aba de feed social Pulse (PR #772) e polimento Pulse em superfícies de feed, compose e filter (PR #796).

NostrBotKit v0.5.0: chat de grupo Marmot em um framework de bot Rust

NostrBotKit v0.5.0, lançado em 24 de maio no Codeberg, adiciona suporte a Marmot (MLS-sobre-Nostr, NIP-104) ao framework de bot Rust auto-hospedado. Quando marmot: true está definido, o bot publica seus key packages MLS (kind 443, 30443, 10051), aceita convites de grupo automaticamente e escuta mensagens em grupos aos quais aderiu. Dois novos tipos de comando, dm_marmot e dm_marmot_npub, permitem aos bots enviar mensagens para grupos Marmot nomeados ou chats Marmot 1:1 via cron jobs ou webhooks. Para evitar loops de feedback com outros bots, bots NostrBotKit só respondem a mensagens explicitamente endereçadas a eles via /command ou @botname/command. Anexos criptografados usando MIP-04 são auto-descriptografados e re-uploadados via Blossom ou NIP-96, e o banco de dados de estado MLS é criptografado com uma chave derivada da chave privada do bot. NostrBotKit é o primeiro framework Rust a lançar suporte a bot NIP-104, abrindo implantação de bot criptografado por Marmot para um perfil de operador diferente do caminho TypeScript existente.

noscrypt v0.1.14: release de biblioteca de criptografia assinada

noscrypt v0.1.14 é uma release de segurança da biblioteca de criptografia C usada por vários clientes Nostr para primitivas secp256k1, NIP-04 e NIP-44. A release vem com downloads assinados por PGP verificáveis contra a chave pública do mantenedor. Clientes downstream que empacotam noscrypt devem validar a assinatura antes de integrar.

Chama v1.3.0: novo escrow P2P Nostr-native com Fedimint

Chama v1.3.0, lançado em 1º de junho, é o destaque de uma sequência de quatro releases para um novo cliente de escrow P2P Nostr-native que usa ecash Fedimint e compartilhamento de segredo Shamir 2-de-3 para liquidação. O projeto está em getchama.app e roda sem servidor. v1.3.0 introduz “heal that sticks” (re-broadcast bem-sucedido e healing de trade que sobrevivem a reinicializações de sessão) e correspondência pay-rail, onde Chamas orientados a EUA apresentam trilhos de pagamento dos EUA primeiro. Base de storefront multi-unidade chegou em v1.2.11 (schema multi-unidade) e v1.2.12 (contador de estoque de storefront + fortalecimento de recuperação nativo de bridge Fedimint). Chama se junta a Mostro e Shopstr na categoria marketplace Nostr, distinguido por sua arquitetura sem servidor e liquidação de escrow baseada em Fedimint.

Mudanças não lançadas

Amethyst: labeling de hashtag NIP-32, tela de podcast, faixas de música

Amethyst fez merge de 52 PRs e 411 commits esta semana sem cortar uma tag de release. A maior adição funcional é PR #3111, que implementa labeling de hashtag NIP-32 e um feed de hashtag baseado em label usando eventos kind 1985 com namespace L e tags de label l. Isso substitui o mecanismo frágil de correspondência de texto #tag por um modelo de descoberta baseado em labeler onde usuários podem seguir npubs de labelers específicos da forma como seguem criadores de conteúdo. PR #3105 adiciona uma tela dedicada de podcast com lista de episódios e player inline, chegando dias após o merge da especificação de podcast NIP-F4. PR #3071 adiciona um feed de Software Apps com filtragem de lista de follow, e PR #3067 adiciona suporte a faixas de música e playlists via conjuntos NIP-51.

Signers efêmeros para uploads de post anônimos chegam no PR #3123, permitindo aos usuários postar anonimamente sem expor sua chave de identidade aos serviços de upload. Um watchdog de auto-cura Tor com testes de integração contra Arti v2.3.0 chega no PR #3053, fortalecendo o roteamento Tor do Amethyst durante interrupções transientes de rede. Zaps onchain e um filtro NIP-05 para usuários retornando do Gemini chegam no PR #3052, ampliando a superfície de zap além do Lightning para pagamentos Bitcoin onchain.

Shopstr: validação de URL de preview OpenGraph

PR #504 valida URLs de preview OpenGraph antes de renderizá-las em listagens de marketplace, fechando uma potencial superfície XSS onde vendedores maliciosos podiam embutir conteúdo com script via metadados OG forjados. Lojas hospedadas no Shopstr exibem previews OG para links externos, e URLs não validadas permitiam a um atacante injetar conteúdo arbitrário na UI da loja.

Atualizações NIP e trabalho de especificação de protocolo

NIP-F4 (Podcasts) mesclado após dois anos

PR #1093 foi mesclado em 28 de maio, dois anos e três meses após fiatjaf abrir o rascunho original. NIP-F4 define episódios de podcast como eventos kind 54 com tags imeta para metadados de arquivo de áudio (URL, mime type, código de idioma ISO, URLs de fallback, flag de serviço NIP-96, bitrate, duração), uma tag title, tags opcionais image e description, e tags t para labels de tópico. A especificação deliberadamente mantém RSS como a fonte de verdade: episódios podem carregar uma tag i referenciando o GUID de podcast RSS, permitindo aos clientes Nostr linkar para feeds de podcast existentes sem duplicar hospedagem de áudio. O longo debate na thread do PR (com o co-autor do podcast-namespace Dave Jones, Alex Gleason e Mike Terenzio) chegou a um modelo de coexistência onde Nostr fornece a camada social em cima do RSS enquanto RSS mantém a camada de distribuição. O PR #3105 do Amethyst com tela de podcast chega dias após o merge da especificação, e o trabalho de picker GIF do Jumble também inclui scaffolding inicial de anexo de podcast.

Desacoplamento de chave NIP-17 (PR #2361)

fiatjaf abriu PR #2361 em 1º de junho, propondo que NIP-17 separe a chave de identidade da chave de criptografia. Destinatários anunciam sua chave de criptografia em um novo evento kind 10044, e remetentes usam essa chave anunciada (quando presente) para o seal interno do gift-wrap, recorrendo à chave de identidade do destinatário apenas quando o anúncio está ausente. O PR também adiciona uma tag n ao seal carregando a pubkey de criptografia do remetente, para que receptores possam derivar a chave de conversa correta sem descriptografia por tentativa contra cada chave aposentada. A motivação declarada é UX de bunker: sob o design atual, um usuário bunker deve fazer round-trip de cada DM recebida através do signer para descriptografar, já que a chave de criptografia é a chave de identidade detida pelo signer. Desacoplar permite ao cliente deter a chave de criptografia localmente enquanto mantém a chave de identidade no bunker para assinaturas.

A proposta atraiu a revisão mais contestada da semana. Cody Tseng (Jumble) a apoia como o caminho mais fácil para interop de DM cross-client. Vitor Pamplona (Amethyst) objeta em dois pontos: adiciona um novo segredo de descriptografia de longa vida fora do bunker, e clientes que não a lançarem falharão silenciosamente em descriptografar mensagens de clientes que lançarem, sem caminho de degradação porque a quebra é na camada do seal. Pamplona argumenta que o problema já é resolvido corretamente pelos key packages e rotação de época do Marmot, e que retroencaixar a separação de chave na especificação base NIP-17 cria o tipo de falha de interop que o Marmot levou dois anos para engenhar em torno. A contra-argumentação do fiatjaf tem três partes: o desacoplamento é opcional por destinatário, a correção n-tag aborda a preocupação de descriptografia por tentativa, e a alternativa é manter a UX de bunker quebrada enquanto o Telegram consome o caso de uso de mensageria. A thread permanece aberta sem uma decisão de merge e é a discussão NIP mais observada do trimestre.

NIP-Silent Payments fluxo de pagamento (PR #2362)

silentius-satoshi abriu PR #2362 em 1º de junho como companheiro ao rascunho NIP mais amplo Nostr Silent Payments (PR #2355). O NIP de fluxo de pagamento define kind 8352 para notificações de recibo de silent payment (entregues via gift wrap NIP-59 para que o link de recibo não seja publicamente observável) e kind 10353 para um cache UTXO criptografado que sincroniza entre dispositivos para a mesma carteira Silent Payments. O par junto permite a um pagador sinalizar um pagamento para um endereço Silent Payments usando primitivas nativas do Nostr sem expor o link on-chain na camada aberta de relay.

NIP-PIP Perfect IP Packets (PR #2364)

RandyMcMillan abriu PR #2364 em 1º de junho como rascunho. Introduz um transporte de árvore de pacotes com três novos kinds endereçáveis: 39078 carrega o manifest, 39079 carrega fatias individuais, e 39080 carrega solicitações de reparo. A especificação define um formato de fio onde arquivos grandes são quebrados em fatias endereçáveis, com manifests descrevendo a árvore de fatias e solicitações de reparo permitindo aos receptores pedir fatias faltantes. Status de rascunho inicial se aplica, e a proposta ainda não atraiu revisão do mantenedor.

NIP-29 espaços live de áudio/vídeo (PR #2238)

PR #2238 foi mesclado em 28 de maio, estendendo grupos baseados em relay NIP-29 com suporte a espaço live de áudio e vídeo. Grupos agora podem referenciar uma sessão live-space ativa, permitindo que eventos de atividade live estilo NIP-53 se ancorem em um contexto de grupo NIP-29.

NIP-71 vídeo múltiplas faixas de áudio (PR #2255)

PR #2255 foi mesclado em 28 de maio, adicionando tags imeta de faixa de áudio a eventos de vídeo NIP-71. O novo formato carrega URL, hash, mime type, tag de idioma (com ISO-639-1 mais flag de versão original), URLs de fallback, sinal de serviço NIP-96, bitrate e duração. Isso habilita streaming apenas de áudio (video podcasts), troca de resolução com áudio estável, múltiplas faixas de idioma, e armazenamento reduzido quando servidores não embutem áudio diretamente em arquivos de vídeo. Clientes devem verificar a disponibilidade de faixa de áudio antes de assumir comportamento de faixa única.

NIP-59 gift wrap efêmero (PR #2245)

PR #2245 foi mesclado em 28 de maio, adicionando kind 21059 como contraparte efêmera ao gift wrap kind 1059 existente. A semântica corresponde ao wrap NIP-59 padrão mas segue regras de evento efêmero por NIP-01 (relays os descartam após broadcast e não os persistem). Isso permite aos apps escolher persistência baseada em requisitos: indicadores de digitação e pings de presença se beneficiam de efêmero, enquanto histórico de DM precisa de persistência.

NIP-78 kind específico de aplicação (PR #2292)

PR #2292 foi mesclado em 28 de maio, reclassificando dados específicos de aplicação NIP-78 como um kind endereçável normal, removendo a faixa separada anterior. Isso simplifica a semântica de substituibilidade e alinha NIP-78 com o modelo de evento endereçável usado por outros NIPs de estado de aplicação.

Esclarecimentos NIP-85 (PR #2304)

PR #2304 foi mesclado em 28 de maio com pequenas melhorias na linguagem em torno de múltiplas chaves e relays por provedor de serviço em Trusted Assertions NIP-85, esclarecendo o caminho de rotação de chave de operador para serviços de asserção de relay.

NIP-01 one-liner de gerenciamento de conexão de relay (PR #2307)

PR #2307 foi mesclado em 28 de maio, adicionando uma única sentença ao NIP-01 sobre como clientes devem lidar com tempos de vida de conexão de relay. A correção aborda uma lacuna de longa data onde clientes divergiam sobre manter conexões WebSocket abertas após fetching, levando a perda silenciosa de mensagem em relays que descartam conexões ociosas.

NIP-C7 restrição de chat kind 9 (PR #2310)

PR #2310 foi mesclado em 28 de maio, restringindo views de chat NIP-C7 apenas a mensagens kind 9. Isso separa chat efêmero de posts de linha do tempo kind 1 em clientes que implementam superfícies de chat estilo NIP-C7.

Simplificação NIP-55 (PR #2363)

PR #2363 por greenart7c3, aberto em 1º de junho, simplifica a especificação de aplicação signer Android. Vitor Pamplona aprovou como “Looks good” e fiatjaf perguntou se está pronto para merge. A mudança pavimenta o caminho para o registro de autoridade ContentProvider NIP-44 v3 que o Amber lançou esta semana.

NIP-44 v3 (implementação Amber antes da especificação)

Amber lançou NIP-44 v3 em v6.2.0 com oito commits implementando o upgrade de criptografia e registro de autoridade ContentProvider, mas o PR de especificação no repositório NIPs ainda não chegou. NIP-44 em si define um formato de payload criptografado versionado usado dentro de eventos assinados; o v2 existente (em produção desde 2024) usa ECDH secp256k1, HKDF, padding, ChaCha20, HMAC-SHA256 e base64. O formato de fio v3 adiciona um novo byte de versão (0x03) antes do nonce, permitindo aos clientes receptores negociar o algoritmo explicitamente. A implementação do Amber inclui auto-rejeição para requisições v3 inválidas, uma tela dedicada de aprovação distinta das aprovações v2, e log de plaintext por direção para o histórico. Até que o PR dos NIPs seja mesclado, v3 permanece como uma extensão específica do Amber. Trate-o como um sinal olhando adiante, não como sinalização estável em todo o protocolo.

Deep dive de NIP: NIP-32 (Labeling)

NIP-32 define uma forma estruturada para qualquer ator Nostr rotular eventos, pubkeys, relays, URLs ou tópicos usando eventos endereçáveis kind 1985 com um vocabulário de label com namespace. A especificação introduz duas novas tags: L denota um namespace de label, e l denota um label dentro desse namespace. Tags de alvo de label (e, p, a, r ou t) especificam o que está sendo rotulado. O requisito de namespace evita que múltiplos sistemas de label colidam: um label spam em nip28.moderation carrega semântica diferente de um label spam em relay-report.

A escolha de design que torna o NIP-32 útil além da moderação é que labels são asserções, não verdade a nível de protocolo. Um evento kind 1985 diz apenas que uma pubkey específica rotulou um alvo específico em um namespace específico. O modelo de confiança é delegado ao cliente: cada cliente escolhe quais labelers honrar, quais namespaces ler, e que affordance de UI dar a cada label. A mesma primitiva carrega avisos de conteúdo, atribuição de licença, tags de idioma ISO-639-1 em notas kind 1, tags geográficas ISO-3166-2, classificação de conteúdo, sugestões de moderação distribuída e pontuações de reputação.

O PR #3111 do Amethyst esta semana é a maior implantação até agora. Adiciona labeling de hashtag através de NIP-32 e um feed de hashtag baseado em label, permitindo aos usuários navegar por labels atribuídos por labelers confiáveis. O mecanismo anterior de correspondência de texto #tag que originalmente dirigia a descoberta de hashtag no Nostr permanece como fallback para notas não rotuladas. O modelo hashtag-como-label significa que a mesma nota pode ser descobrível sob múltiplos labels atribuídos por labelers diferentes, e usuários podem silenciar ou impulsionar labelers específicos sem afetar as notas subjacentes.

Auto-labeling também é suportado. Um autor pode anexar tags L e l diretamente às suas próprias notas kind 1 para declarar idioma, localização e tópico. Uma nota taggeada ["L", "ISO-639-1"], ["l", "en", "ISO-639-1"] se auto-identifica como inglês e pode ser filtrada por clientes conscientes de idioma sem infraestrutura de labeling de terceiros.

Exemplo de evento de label NIP-32 rotulando uma nota kind 1 como inglês e atribuindo a ela uma tag de moderação:

{
 "id": "a5f87fe2d4c8b9a0e3f1c4d5e6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1748908800,
 "kind": 1985,
 "tags": [
 ["L", "ISO-639-1"],
 ["l", "en", "ISO-639-1"],
 ["L", "nip28.moderation"],
 ["l", "approve", "nip28.moderation"],
 ["e", "8b39f4e5d6c7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3", "wss://relay.example.com"]
 ],
 "content": "Labeled as English-language content approved for NIP-28 chat moderation",
 "sig": "f1e2d3c4b5a6978869504132c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5"
}

O rollout do Amethyst combinado com o recente trabalho de Trusted Relay Assertions sugere que NIP-32 está se tornando o substrato padrão para qualquer padrão “asserção dirigida pelo usuário sobre um alvo” no Nostr. O próximo teste é se labelers em si desenvolvem hierarquias de confiança: se usuários seguirão npubs de labelers específicos da forma como seguem criadores de conteúdo.

Deep dive de NIP: NIP-F4 (Podcasts)

NIP-F4 foi mesclado esta semana, dois anos e três meses após fiatjaf abrir o rascunho original (PR #1093). O prefixo F é numeração hex simples: NIP-F0 até NIP-FF usam o mesmo espaço hex de 1 byte que NIP-0A até NIP-0D, com a faixa hex superior servindo como overflow agora que a faixa decimal 01–99 está enchendo. NIP-F4 define como podcasts publicam episódios e metadados como eventos Nostr enquanto mantêm RSS como uma camada complementar para o próprio arquivo de áudio.

A escolha arquitetural central é que cada podcast é seu próprio par de chaves Nostr. A especificação abre com isso diretamente: “cada podcast é seu próprio par de chaves Nostr”. Isso permite aos podcasts combinar sua presença de podcasting com uma presença normal kind 0 / kind 1 de microblogging, e permite a um podcast mudar de propriedade ao longo do tempo através de handover de chave ou assinatura compartilhada estilo MuSig2. Quatro kinds de evento carregam a camada de publicação:

kind:10154: metadados de podcast substituíveis. Carrega tags title, image, description, website opcionais, e tags p opcionais marcando autores com um role de host, cohost ou editor.
kind:10164: contra-reivindicação de autor. O exemplo na especificação usa kind 10064 (um typo aberto para correção), mas o cabeçalho e o texto ao redor o identificam como kind:10164. Usuários listam as pubkeys de podcast que autoriam, para que clientes possam verificar as tags p em kind:10154 contra uma reivindicação equivalente do suposto autor. Sem isso, um podcast poderia falsamente marcar qualquer um como host.
kind:54: eventos de episódio autorados pela pubkey do podcast diretamente. Tags incluem title, image opcional, description, e uma ou mais tags audio. Cada tag audio é ["audio", "<audio-url>", "<optional_media_type>"]. A especificação nota “outros campos importantes a serem especificados aqui depois de mais descoberta”, e a forma mesclada é deliberadamente mínima.
kind:10054: uma lista favoritos-de-podcasts estilo NIP-51, permitindo aos usuários marcar quais podcasts seguem.

O debate da thread em torno do merge envolveu o co-autor do Podcasting 2.0 Dave Jones, Alex Gleason, Mike Terenzio, Pablo F7z e staab. Jones argumentou fortemente contra qualquer tentativa de substituir RSS: “Foi tentado muitas vezes e sempre falha”, citando JSONfeed, XMPP, AMP, API do Twitter e a migração falhada do Spotify. Terenzio reformulou a proposta como uma camada social em cima do RSS, mantendo o próprio RSS como a camada de distribuição. fiatjaf concordou em recuar e deixar a proposta amadurecer: “Concordo com tudo que você disse mas ainda acho que podemos consegui-lo, vamos parar aqui por um tempo”. Dois anos depois, a especificação mesclada chega mais perto de coexistência do que substituição.

Três questões de design permanecem explícitas na especificação mesclada:

O typo de kind:10164 (exemplo mostra 10064) precisa ser reconciliado antes que clientes possam interoperar seguramente.
Descoberta em nível de episódio sem linking RSS GUID é deixado aberto. A especificação mesclada não tem tag i, formato podcast:item:guid, e mecanismo de bridging RSS. Clientes que querem ponte um catálogo RSS existente em eventos kind 54 devem definir a convenção de ponte eles mesmos.
O stub “outros campos importantes” na definição de kind:54 deixa bitrate, duração, idioma, ponteiros de transcrição, capítulos e metadados por segmento como território aberto para propostas de acompanhamento.

O PR #3105 do Amethyst traz uma tela dedicada de podcast com lista de episódios e player inline dias após o merge, a primeira grande implementação de cliente. Jumble lançou scaffolding inicial de anexo de podcast junto com seu picker GIF. Wavlake permanece a maior plataforma de podcast Nostr-native e precisará decidir se alinha seus eventos existentes de faixa de música kind 31337 com o modelo de episódio kind 54 do NIP-F4.

Exemplo de evento de episódio NIP-F4 kind 54, correspondendo ao conjunto mínimo de tags da especificação mesclada:

{
 "id": "55807e7d5cd90d0303d7dce7397f996fdbaed8697903f326c7cf8ad999b9de3d",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1748995200,
 "kind": 54,
 "tags": [
 ["title", "Episódio 42: Por que RSS venceu"],
 ["image", "https://podcast.example.com/ep42-cover.jpg"],
 ["description", "Dave Jones e fiatjaf sobre coexistência de protocolo e a camada social."],
 ["audio", "https://podcast.example.com/audio/ep42.mp3", "audio/mpeg"]
 ],
 "content": "Neste episódio discutimos a jornada de dois anos do NIP-F4 do rascunho ao merge, e por que a coexistência com RSS acabou sendo a escolha arquitetural correta.",
 "sig": "abc123def456789012345678901234567890abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef01234567"
}

O PR #1093 esteve aberto por 27 meses, bem acima da duração mediana aberta para PRs de NIP mesclados. O próximo teste para NIP-F4 é se o typo de kind 10164 é reconciliado, se convenções de descoberta de episódio e ponte RSS emergem dos implementadores, e se os principais hosts de podcast publicam sob pares de chaves por-podcast como a especificação recomenda.

Nostr Compass #24

Thu, 28 May 2026 00:00:00 +0000

Amethyst v1.11.0 traz uma implementação completa de calendário NIP-52 com lembretes, splits de zap Bitcoin on-chain e suporte a respostas em grupos Marmot. White Noise v2026.5.22 lança notificações push no iOS através de uma Notification Service Extension, junto com UX de bloqueio e um botão para adicionar membros. Vector v0.4.0 traz uma reescrita completa do vector-core, Tor com um clique e bridges, signers remotos NIP-46, sincronização de grupos MLS com negentropy completo, e um servidor MCP de 21 ferramentas para agentes de IA. Applesauce v6.1.0 introduz listas de relay de lookup NIP-51 (kind 10086) e um conjunto completo de factories git-cast NIP-34. MDK adiciona mensagens efêmeras NIP-40 entre iOS e Android através de uma superfície UniFFI unificada, e Mostro v0.17.4 fecha o loop de bond anti-abuso com payouts Fase 3 de bonds slashed para o vencedor. Notedeck faz merge de reconciliação negentropy NIP-77 completa para giftwraps e backfill de threads, Cordn surge como um messenger MLS mediado por coordenador que troca uma dependência de disponibilidade de ponto único por ordenação de época mais rígida e um modelo operacional mais simples, uma implementação de referência NIP-B0 chamada deepmarks lança um cliente de bookmarks monetizado por curador, e a equipe do Formstr abre quatro propostas coordenadas de NIP de calendário cobrindo auto-remoção de participantes, eventos privados, recorrência e agendamento descentralizado de compromissos.

Matérias principais

Amethyst v1.11.0: calendários, splits de zap on-chain e respostas no Marmot

Amethyst, o cliente Nostr para Android mantido por Vitor Pamplona, lançou v1.11.0. PR #2994 adiciona uma implementação de evento de calendário NIP-52 com uma UI dedicada e um sistema de lembretes, para que eventos de calendário agora sejam renderizados em sua própria categoria de linha do tempo, separada da visualização long-form genérica de kind-30023. PR #3018 estende zaps Bitcoin on-chain com suporte a splits, distribuindo uma única transação Bitcoin entre múltiplos destinatários conforme a tag zap-split existente, para que um pagamento on-chain se comporte da mesma forma que um split Lightning. PR #2974 adiciona uma tela paginada de histórico de transações on-chain que apresenta cada zap liquidado com status de confirmação de bloco.

Mensageria de grupo ganha paridade com chat um-para-um: PR #2995 adiciona suporte a respostas para mensagens de grupo Marmot/MLS, para que threads dentro de grupos criptografados agora sejam renderizados com a mesma UI de referência de pai que notas públicas. PR #2984 fortalece a validação de recibo de zap NIP-57 verificando se o provedor LNURL corresponde ao lud16 declarado do destinatário, fechando uma classe de falsificação onde um LNURL de terceiros poderia forjar um recibo para um pagamento que nunca chegou. PR #2968 aceita dimensões de ponto flutuante em tags imeta NIP-92, alinhando o Amethyst com clientes que publicam valores de densidade de pixel fracionários de dispositivos como o display Retina do iPhone. A release também conecta Payment Targets, uma nova pote de gorjetas multi-trilho de evento substituível coberto na seção de protocolo abaixo.

White Noise v2026.5.22: push no iOS, UX de bloqueio e adicionar membros

White Noise, o messenger de grupo do protocolo Marmot, lançou v2026.5.22 com notificações push no iOS como recurso em destaque. PR #673 implementa uma iOS Notification Service Extension (NSE) que descriptografa mensagens MLS dentro do processo de extensão e as apresenta como notificações do sistema, para que usuários de iPhone não precisem mais ter o app em primeiro plano para receber mensagens. A infraestrutura de push-token do Android é roteada através do mesmo pipeline de backend, com a NSE por plataforma mantendo ciphertext fora do broker.

PR #676 adiciona uma UX completa de bloqueio e desbloqueio com fluxos de confirmação e filtragem de lista de contatos. PR #679 adiciona o botão há muito solicitado “Add members” à tela de info do grupo, fechando uma lacuna de UX onde admins de grupo tinham que recorrer a links de compartilhamento. PR #688 introduz uma tela dedicada de configurações de notificação para iOS, e PR #687 conecta compartilhamento via toque longo para mídia e mensagens.

MDK adiciona mensagens efêmeras NIP-40 entre plataformas

O Marmot Development Kit, o core Rust compartilhado usado por White Noise iOS, White Noise Android, e qualquer cliente Marmot futuro, mesclou PR #306 para expor validação de mensagens efêmeras e tratamento de expiração NIP-40 através da ponte UniFFI. O PR é o segundo de uma série de três partes. iOS e Android agora compartilham uma implementação Rust da lógica de expiração; as regras de temporização vivem em um único caminho de código auditado consumido por ambas as plataformas via UniFFI. PR #307 limita o comprimento armazenado dos motivos de falha de welcome e os sanitiza antes da persistência, uma passagem de fortalecimento separada que complementa o tratamento de eventos de welcome lançado na semana passada.

Mensagens efêmeras em MLS não são apenas uma comodidade de UI. A tag de expiração é publicada com o envelope de mensagem criptografada, então um destinatário que nunca abre a mensagem ainda tem o ciphertext subjacente expirando na camada de relay junto com qualquer cópia em cache no cliente receptor. Com o MDK detendo o caminho de validação, o comportamento permanece consistente entre clientes: qualquer implementação Marmot conforme impõe a mesma semântica de expiração, então um cliente honrando a expiração enquanto outro faz cache para sempre deixa de ser um risco de portabilidade.

Mostro v0.17.4: Fase 3 fecha o loop de bond slashed

Mostro, o protocolo de câmbio Bitcoin peer-to-peer construído no Nostr, lançou a Fase 3 de seu rollout de bond anti-abuso em v0.17.4. PR #738 traz o fluxo de payout para bonds slashed, pegando o colateral perdido do perdedor e distribuindo-o para o vencedor da disputa. PR #743 adiciona a Fase 3.5, uma mensagem explícita de confirmação de payout para o vencedor para que ele saiba que os sats slashed foram liquidados, com o evento de confirmação chegando na mesma sessão Nostr da resolução de disputa. A Fase 2, coberta na semana passada, introduziu slashing como uma ação de admin; a Fase 3 é a diferença entre ameaçar uma penalidade e aplicá-la.

PR #746 permite ao daemon finalizar disputas que não têm uma linha de solver, um caso de borda que anteriormente travava a resolução em disputas legadas. PR #748 tolera taxas nulas na resposta /exrates/BTC do Yadio para que uma breve interrupção no Yadio não quebre mais o caminho de conversão fiat do Mostro. PR #745 documenta a especificação para provedores de preço multi-fonte, a base para remover o Yadio como um ponto único de falha. O cliente mobile do Mostro conectou o caminho de claim correspondente da Fase 3 no PR #596.

Applesauce v6.1.0: relays de lookup e git casts NIP-34

Applesauce, o toolkit Nostr modular que alimenta a stack de Coracle, noStrudel e Pablo F7z, lançou v6.1.0 em seus pacotes. A release adiciona suporte de primeira classe a listas de relay de lookup NIP-51: eventos kind 10086 permitem que um usuário sinalize “pergunte a esses relays se quiser me encontrar”, ficando ao lado de listas de outbox NIP-65 como uma primitiva de descoberta. Aplicações construídas em applesauce-core obtêm um observável reativo User.lookupRelays$ e um loader correspondente em applesauce-relay.

Factories git-cast NIP-34 chegam em applesauce-factory, dando a cada cliente construído em Applesauce um caminho de uma linha para publicar anúncios de repositório (kind 30617), patches (kind 1617) e issues (kind 1621). Propriedades reativas User.favoriteGitRepos$, User.gitAuthors$ e User.graspServers$ permitem que aplicações listem repos seguidos por um usuário, mantenedores de repo e servidores GRASP configurados diretamente do mesmo objeto User. A release também corrige métodos manuais de pool que silenciosamente descartavam relays offline no PR #73.

Notedeck faz merge de negentropy NIP-77 para giftwraps e backfill de threads

Notedeck, o cliente desktop nativo multi-coluna do Damus, mesclou PR #1459 em 25 de maio para conectar reconciliação negentropy NIP-77 completa ao caminho de outbox compartilhado. O PR adiciona frames de cliente e relay NIP-77, sessões negentropy relay-local, e um rastreador de histórico completo de outbox que dirige reconciliação de conjunto local e buscas de eventos faltantes. Giftwraps de mensagens obtêm reconciliação negentropy para que envelopes de mensagem privada possam ser recuperados dos relays de leitura da conta selecionada. Visualizações de thread não são mais limitadas pelo limite de resposta de assinatura ao vivo. Dave PNS substitui sua implementação negentropy local do Dave pelo caminho de outbox compartilhado enquanto preserva seu comportamento existente de histórico limitado.

Assinaturas ao vivo e negentropy agora usam filtros separados. Um fluxo pode manter uma pequena solicitação ao vivo enquanto emite um filtro negentropy mais amplo para reconciliar o que o relay já tem. O PR intencionalmente não habilita sync negentropy amplo para linhas do tempo home ou perfil, o que mudaria características de custo de cold-start. Cobertura de teste foi adicionada para reconciliação, entrega de giftwrap, backfill de thread, restauração Dave PNS, troca de conta, redirecionamento de relay, retries de fetch e comportamento de relay NIP-77.

Vector v0.4.0: reescrita do vector-core, Tor, NIP-46, MLS com negentropy completo, e uma superfície de agente MCP

Vector, o messenger cross-platform focado em privacidade construído em DMs NIP-17 e grupos Marmot, lançou v0.4.0 como sua maior release até hoje. O destaque é uma reescrita completa do motor: toda a lógica do Vector agora vive em uma única crate desacoplada, vector-core, compartilhada entre desktop, Android e qualquer cliente futuro, com mais de 440 testes no próprio core e a shell da aplicação com milhares de linhas removidas. A reescrita é a base para um CLI do Vector, bots e SDKs que dirigem o mesmo código de protocolo que a GUI.

Integração com Tor vem com roteamento de tráfego com um clique e suporte a bridge para contornar censura. Suporte multi-conta chega com um switcher in-app. Login com signer remoto chega via NIP-46 com pareamento bunker por QR ou URI colada, para que usuários possam fazer login sem nunca expor sua nsec. Delete-for-everyone funciona tanto em DMs NIP-17 quanto em chats de grupo Marmot, com o Vector mantendo a chave efêmera de assinatura como uma divergência deliberada da especificação que as notas de release destacam explicitamente: “um desvio das especificações tradicionais NIP-17/Marmot para controles aprimorados de privacidade do usuário.” A chave efêmera retida dá aos clientes Vector prova local de que uma exclusão foi sancionada pelo remetente original, mas também significa que qualquer outro cliente que toque no Vector vê uma superfície de verificabilidade de exclusão diferente dos clientes NIP-17/Marmot de referência.

Sync de grupo MLS agora é totalmente reconciliado sobre negentropy NIP-77, a mesma direção que o Notedeck tomou para giftwraps e threads esta semana. O uploader Blossom faz failover entre múltiplos servidores, aprende as capacidades de cada servidor e sincroniza a lista de servidores entre dispositivos. Pacotes de emoji customizados são criáveis pelo usuário, compartilháveis e cross-compatíveis com outros clientes Nostr. A memória SQLite caiu de aproximadamente 308MB para 5MB. O painel de emoji abre a partir de cache em disco e shortcodes estilo Discord (:smile:) mais ranking de frequência Unicode apresentam o glifo certo primeiro.

A adição mais nova é vector-agent, um servidor MCP (Model Context Protocol) que expõe 21 ferramentas para que agentes de IA possam dirigir o Vector: enviando DMs, gerenciando grupos, fazendo upload de arquivos, editando perfis. Este é o segundo projeto Nostr esta semana (junto com o Shopstr) a lançar uma superfície MCP, e a primeira aplicação de classe messenger a fazê-lo. Combinado com o AgentNoise (coberto na semana passada), o padrão de clientes Nostr controlados por agente está passando de experimentos pontuais para uma direção deliberada de plataforma.

Cordn aparece como um messenger MLS mediado por coordenador

Cordn (cliente web em cordn.net, repos em Cordn-msg/cordn e Cordn-msg/cordn-web) é um novo messenger MLS que adota uma abordagem arquitetural diferente do Marmot. Onde o Marmot é totalmente baseado em relay sem coordenador privilegiado (cada membro do grupo escreve diretamente para relays e qualquer relay conforme pode carregar o tráfego), o Cordn introduz um papel de coordenador por grupo implementado como um serviço ContextVM. O coordenador ordena commits MLS e lida com distribuição de welcome.

O argumento do Cordn, declarado em sua página /why, é que MLS como implantado em messengers de produção “não é livre de coordenação” e que “disseminação pública fracamente ordenada” torna a convergência de estado de grupo “muito mais difícil” sem um ponto forte de coordenação. Um design mediado por coordenador fornece avanço de época previsível e resolução mais simples de commits concorrentes. Participantes se conectam ao coordenador usando chaves efêmeras, então o coordenador aprende o ID do grupo e o timing do tráfego de commit mas não quais pubkeys de longo prazo são membros. Qualquer parte consultando relays para um grupo Marmot já pode ver a mesma superfície: atividade de grupo por ID de grupo, com timing inferível pela chegada de eventos. Cordn também reconhece que “confiança de disponibilidade permanece” com auto-hospedagem: um coordenador auto-hospedado evita a preocupação de centralização na camada do operador mas introduz um ponto único de falha para a liveness do grupo. Marmot evita esse ponto único deixando a ordenação para o próprio MLS (épocas e mensagens Commit lidam com ordenação dentro do protocolo) e distribuindo eventos Welcome via gift wrap NIP-59, ao custo de disciplina do lado do admin: admins devem esperar pelo reconhecimento do relay de um Commit antes de enviar o Welcome correspondente, e clientes devem reconciliar commits concorrentes quando a entrega do relay compete com uma transição de estado.

O contraste vale a pena examinar para qualquer equipe escolhendo uma stack de mensageria privada. Marmot troca alguma complexidade de implementação por uma implantação agnóstica a relay sem ator privilegiado no caminho. Cordn troca uma dependência de disponibilidade de ponto único por ordenação mais apertada e um modelo operacional mais simples. Ambos os projetos são construídos em MLS e usam Nostr como camada de identidade e transporte. A discordância é sobre onde vive o custo de coordenação. Os repos cordn-msg mostram cadência estável de commits com o serviço coordenador implementado sobre ContextVM e a camada MLS construída em ts-mls.

deepmarks: bookmarks NIP-B0 com publicação monetizada por curador

deepmarks-public é um cliente de referência para a especificação de bookmark proposta NIP-B0 (kind 39701), com uma arquitetura de três caixas (curador, indexador, visualizador) e um sistema de níveis financiado por zaps NIP-57 diretos ao curador. O cliente implementa NIP-B0, NIP-07, NIP-46, NIP-57, NIP-44, NIP-98, NIP-65 e Blossom BUD-01 e BUD-04 para armazenamento de arquivo. Um nível vitalício de 21.000 sats converte leitores pagantes em destinatários recorrentes de zap para o curador. O curador publica eventos de bookmark, o indexador os enriquece com metadados legíveis por máquina e o visualizador renderiza o feed; cada papel é um serviço implantável separado.

Releases

Amber v6.1.0 GA: backup criptografado por conta

Amber passou de v6.1.0-pre3 para GA v6.1.0 esta semana. PR #444 lança backup e restore criptografados para o banco de dados de permissões de aplicação, e PR #446 divide o backup por conta, para que usuários com múltiplas identidades Nostr possam fazer backup e restaurar cada conjunto de grants de app independentemente. O trabalho de assinatura PSBT coberto na semana passada está no corte GA.

Citrine: assinaturas por relay e prevenção de vazamento de URL onion

Citrine, o relay pessoal no dispositivo que vem com o Amethyst, lançou duas correções neste ciclo. PR #157 alterna de uma única assinatura global para assinaturas taggeadas por relay, para que dois relays de origem compartilhando um filtro kinds: [1] não colidam mais no lado do agregador. PR #162 filtra URLs de relay onion quando o proxy Tor de saída está desabilitado, evitando que endereços onion vazem para o caminho de roteamento clearnet.

Angor v0.2.27 e v0.2.28: confiabilidade de relay e reconexão Boltz

Angor lançou v0.2.27 e v0.2.28. PR #874 corrige um bug de dedup de relay onde apenas um relay estava conectado por vez, uma regressão que silenciosamente degradava a confiabilidade para projetos com múltiplos endpoints de relay. PR #876 adiciona lógica de reconexão WebSocket para monitoramento de submarine-swap Boltz, para que uma breve desconexão não deixe mais um swap em estado desconhecido.

Nostrord v1.1.0: zaps NIP-57 e distinção de papéis NIP-29

Nostrord lançou v1.1.0 com suporte a zaps Lightning NIP-57 para mensagens e perfis (PR #98) e uma distinção adequada no feed de atividade entre mudanças de papel NIP-29 e adições de membro (PR #92), que costumavam renderizar identicamente e obscureciam quem havia sido promovido versus quem havia sido convidado.

ぬるぬる v1.5.x: keystore MLS SQLCipher e catch-up de época

ぬるぬる (nurunuru, por tami1A84), um cliente Nostr em japonês que implementa mensageria de grupo MLS (kind 443) junto com NIP-44, busca avançada NIP-50, NIP-55 e NIP-70, lançou cinco releases esta semana. PR #184 introduz criptografia SQLCipher para o keystore MLS na camada rust-engine. PR #187 e PR #188 estendem SQLCipher para Android e iOS respectivamente, com uma etapa de purga de plaintext legacy e guards de CI. PR #189 e PR #191 adicionam catch-up de época de par MLS com um cache de replay e um banner de recuperação em ambas as plataformas, para que um cliente que fica para trás em commits de grupo possa se recuperar sem perder a conversa. ぬるぬる é um cliente Marmot construído em mdk-core, mdk-sqlite-storage e mdk-storage-traits de marmot-protocol/mdk, então o trabalho SQLCipher e catch-up de época chega dentro do mesmo runtime MDK que o White Noise usa.

Bitcredit Core v0.5.10: correção de propagação de bloco com raiz Nostr

Bitcredit Core lançou v0.5.10 com uma correção para um campo Nostr-node-id ausente durante propagação de bloco, que estava quebrando fluxos de criação de empresa que incluíam upload de identidade. Bitcredit é um protocolo de e-bill que usa identidades Nostr como raiz de confiança para eventos de propagação de empresa e bill.

Mudanças não lançadas

Jumble abriu PR #797 para login Google via o signer de threshold Pomegranate, permitindo a um usuário dividir sua chave Nostr entre múltiplas partes para que nenhum signer único detenha o segredo completo. Este é um passo significativo além dos fluxos bunker ou nsec-import: um usuário pode recuperar sua conta mesmo se uma parte signer for comprometida, sem que essa parte jamais detenha a chave privada completa.

Shopstr abriu PR #492 inicializando um servidor MCP (Model Context Protocol), com PR #494 construindo a infraestrutura de suporte (fetch de relay, parsers, validação, erros, dedup, log de auditoria) e PR #472 adicionando uma allowlist de relay para o gerenciador de relay MCP. Isso torna o Shopstr o primeiro marketplace Nostr a se expor como um servidor MCP, para que agentes de IA possam navegar e agir em listagens NIP-99 como uma ferramenta estruturada.

Keydex, o vault de compartilhamento de segredo Shamir, abriu uma migração substancial no PR #226 movendo kinds customizados 1337-1345 para a faixa 713-721, junto com PR #239 adicionando AEAD sobre shares Shamir e PR #234 migrando para aritmética GF256. A migração de faixa de kind alinha o Keydex com a forma como o repositório NIPs aloca kinds customizados, saindo de uma faixa auto-declarada.

Mill (nostr-mill) é uma nova UI de signer Nostr drop-in do OceanSlim (mantenedor do relay Go grain), lançado como um Web Component de tag de script único no npm e jsDelivr. Uma tag <script> dá a um app web todos os seis pontos de entrada de signer comuns por trás de uma UI unificada: extensão de navegador NIP-07, bunker NIP-46 (colar URL ou pareamento QR com relays especificáveis pelo usuário, incomum entre integrações bunker in-page), Amber NIP-55 via intents Android, nsec criptografada armazenada em sessionStorage via AES-256-GCM com PBKDF2, npub somente leitura, e geração de par de chaves no navegador. O componente é tematizável através de 29 propriedades customizadas CSS escopadas no Shadow DOM e expõe uma pequena API rastreada por SemVer (MILL.open, eventos mill:connected / mill:disconnected, exports de tema nomeados). A motivação do mantenedor é que fluxos de login bunker foram reimplementados um app web por vez em todo o Nostr. Consolidar em um componente compartilhado permite que clientes convirjam em como o UX do signer deve se comportar, e transforma fluxos opcionais (como login com chave delegada através de signers de threshold, espelhando o login Google baseado em Pomegranate do Wisp coberto acima) em uma superfície reutilizável que qualquer app pode adicionar. Mill está em npm v1.5.0, mantenedor único, estágio alpha, com grain como o primeiro integrador planejado.

moStard, um fork Monero-first do noStrudel por roguehashrate, chegou à v1.0.1 esta semana com um conjunto de recursos reduzido e uma identidade temática Monero em camadas na mesma stack Applesauce + worker-relay. O trabalho desta semana trouxe renderização para eventos de software-application kind 32267 do Zapstore (cards embutidos na linha do tempo mostrando nome do app, ícone, screenshots, plataforma, licença e um link de launch para zapstore.dev/apps/<d-tag>), enquetes via kind 20 e kind 21, gorjetas baseadas em Payment Targets NIP-A3 com QR codes por método, renderização de markdown em notas, suporte a picker GIF para teclados GIF externos, e correções de pareamento de signer Amber. O enquadramento Monero se estende ao fluxo de gorjeta: entradas payto NIP-A3 para endereços monero obtêm botões de primeira classe na mesma UI junto com lightning e bitcoin. O cliente é de mantenedor único e estágio alpha, mas o trabalho de 27 de maio mostra um construtor puxando NIP-A3 dos anúncios de especificação de protocolo desta semana direto para um fork em produção em dias.

Atualizações NIP e trabalho de especificação de protocolo

Stack NIP de calendário: quatro propostas da equipe Formstr

Ix2 (@geralt-debugs) abriu quatro PRs de NIP coordenados em 17 de maio, todos referenciando a implementação calendar.formstr.app já lançada sob o mesmo autor. PR #2350 propõe kind 84 como um evento generalizado de “auto-remoção de participante”: um participante taggeado em qualquer evento pode publicar um kind 84 referenciando o original via tags e, a e k para sinalizar opt-out. Relays devem validar que o signer do kind 84 aparece em uma tag p do evento referenciado antes de honrar a remoção, e uma exclusão kind 5 sempre tem precedência. O PR generaliza um padrão que anteriormente era descrito apenas dentro do contexto de calendário NIP-52, tornando o kind 84 a maneira padrão para não-autores se retirarem de qualquer evento de participante.

PR #2351 é a fundação da stack de calendário: NIP-52E para eventos de calendário privados (kinds 32678 time-based, 32681 day-event, 32123 lista de calendário privado, 31926 lista de ocupado, 1052 gift wrap, 52 rumor) e NIP-52R para eventos recorrentes. No centro arquitetural está o padrão view-key: um par de chaves gerado aleatoriamente criptografa o conteúdo do evento com NIP-44, e a metade secreta (codificada em bech32 como nsec) é gift-wrapped para cada participante. O signer detém apenas a tag d pública; todo o resto vive em content criptografado. Desacoplar a criptografia de conteúdo da identidade dessa forma significa que editar um evento não requer re-envio de chaves para destinatários. NIP-52R define duas tags opcionais nos kinds existentes 31923 e 31922 para declarar recorrência usando valores RRULE RFC 5545 brutos, com o índice de dia D tornando-se opcional quando RRULE está presente. Forward secrecy está explicitamente ausente: uma view key vazada revela todas as versões passadas e futuras do evento sob a mesma tag d.

PR #2352 constrói sobre NIP-52E com uma especificação descentralizada de agendamento de compromissos que a descrição do PR chama de “uma alternativa drop-in para Calendly/Cal.com sem intermediário central.” Kind 31927 anuncia uma página de agendamento com janelas de disponibilidade criptografadas; kind 32680 é um registro de recuperação auto-criptografado do lado do host para a view key; kinds 1057 e 1058 são a solicitação e resposta de reserva gift-wrapped. O mecanismo inteligente: o reservante gera tanto a tag d quanto a view key para o futuro evento privado antes de enviar a solicitação, para que o reservante possa adicionar o compromisso ao seu próprio calendário imediatamente com a chave correta, e o host nunca precise fazer round-trip de chave de volta. Respostas de reserva carregam uma tag status não criptografada no wrap externo para que relays possam filtrar sem descriptografar.

Uma implementação de referência já está no ar em calendar.formstr.app e como o app Calendar Android no Zapstore. PR #2351 fecha o PR #2027 em seu favor, consolidando uma proposta anterior de calendário privado que estava aberta desde o início do ano.

Payment Targets e Silent Payments

Mais duas propostas de NIP circularam esta semana em documentos long-form kind:30023.

Uma proposta de Payment Targets (NIP-A3 / payto) define um evento substituível kind 10133 carregando uma ou mais tags ["payto", "<type>", "<authority>"] que mapeiam para URIs payto: RFC 8905. Tipos suportados incluem bitcoin, lightning, ethereum, monero, nano, cashme, revolut e venmo. A intenção é padronizar um pote de gorjetas multi-trilho que complementa (não substitui) zaps NIP-57 baseados em lud16. Amethyst v1.11.0 é o primeiro implementador; PRs mesclados #2953 e #3009 trazem a superfície de assinatura e observação, e PR #3011 conecta a UI para PaymentTargetsEvent.

Duas propostas concorrentes de Silent Payments vieram de autores diferentes. A primeira variante deriva chaves de scan e spend de silent-payment BIP-352 de nsec via tweaks aditivos públicos, para que qualquer remetente possa construir um endereço sp1q... de uma npub sem configuração. O aviso do autor é explícito na especificação: “bscan e bspend DEVEM ser tratados com exatamente o mesmo cuidado que nsec”, porque a chave de scan revela a nsec. Uma segunda variante toma a abordagem inversa, adicionando um campo sp_address aos metadados de perfil kind 0 contendo um endereço padrão de silent-payment BIP-352 cujas chaves são mantidas independentes da identidade Nostr. A variante dois é estruturalmente mais segura. Ambas as propostas atraíram uma thread de revisão ponderada; erskingardner (líder do Marmot) postou um comentário detalhado no gist trbouma rastreando a proposta. Sua preocupação central é que a variante 1 deriva a chave privada de scan de nsec mais um tweak publicamente computável, o que significa que qualquer um segurando a chave de scan (incluindo um serviço de scan de terceiros ao qual o usuário tem que delegar na prática) pode recuperar a nsec completa subtraindo esse tweak. A mesma chave que permite a um serviço remoto escanear pagamentos recebidos para você também permite a esse serviço roubar sua identidade e quaisquer fundos derivados dela.

No lado git-over-Nostr NIP-34, hzrd149 publicou 2 patches para schemata. O próprio gitworkshop.dev atraiu dois relatos de issues: um sinalizando que sessões de login são perdidas no refresh da página ao usar um signer remoto NIP-46, o outro pedindo por estilo distinto de link em previews de README.

Seis anos de maios do Nostr

A última newsletter de maio de 2026 recua das releases da semana para percorrer o mês de maio ao longo da história do Nostr. Cada ano teve um centro de gravidade diferente: 2021 foi um único commit, 2022 foi a formação do próprio repositório NIPs, 2023 foi a explosão de especificações de protocolo, 2024 foi o ciclo de consolidação, 2025 foi quando negentropy foi mesclado e o Notedeck do Damus se graduou para Beta, e 2026 é o mês coberto neste e nos três issues anteriores.

Maio de 2021

O Nostr tinha seis meses. O único código Nostr vivia em fiatjaf/nostr e o mês inteiro produziu exatamente um commit, mas esse commit se tornou uma das partes mais usadas do protocolo. Em 22 de maio, fiatjaf redirecionou o NIP-02 como o NIP de lista de contatos. A mensagem do commit diz: “repurpose NIP-02 and add NIP authorship”, e o crédito explícito é para PR #16 por arcbtc (Ben Arc do LNbits), aberto em 9 de fevereiro e fechado no dia anterior ao fiatjaf incorporar a ideia no NIP-02. A proposta do arcbtc era pequena: um kind para “enviar lista de seguidores para relays” que seria “útil para restaurar contas e recomendar chaves públicas para seguir.” fiatjaf generalizou isso em um único evento kind:3 cujas tags servem três propósitos ao mesmo tempo. Elas são uma lista de follows (o grafo social), um store de petname (apelidos locais para amigos) e uma fonte de recomendação de relay (quais relays um follow usa). O mesmo evento, substituível por autor, tornou-se a resposta canônica para “quem essa pessoa segue”, “como ela os chama” e “onde ela lê.” Cada cliente construído nos próximos cinco anos lê kind:3. A convenção adicionada no mesmo commit, de que cada NIP nomeia seu autor, é a razão pela qual cada especificação agora tem assinatura.

Maio de 2022

O mês em que o repositório NIPs se tornou um projeto comunitário. Em 1º de maio, fiatjaf migrou as especificações de fiatjaf/nostr para um repositório dedicado nostr-protocol/nips e em 2 de maio adicionou critérios formais de aceitação. Dois dias depois, Robert C. Martin (Uncle Bob) abriu PR #1, o primeiro pull request externo, propondo convenções de threading para tags e e p. O PR foi originalmente numerado NIP-13, então renumerado para NIP-10 para abrir espaço para proof-of-work. Três dos primeiros seis NIPs são do Uncle Bob: NIP-10 (marcadores de threading), NIP-14 (a tag Subject), e o commit de 21 de maio que fixou kind:1 como o kind canônico de nota de texto curta. Em 5 de maio, William Casarin fez seus primeiros commits de NIP: NIP-13 Proof of Work e o evento kind:2 recommend-relay. No dia seguinte, fiatjaf publicou NIP-07 window.nostr, vinte linhas de markdown que definiram a interface de signer de extensão de navegador ainda usada hoje. O aviso CORS do NIP-05 por David A. Harding e o filter.limit do NIP-01 chegaram na mesma semana. nostr-tools lançou sua primeira build ESM importável no navegador em 8 de maio. Semisol rascunhou NIP-15 (End Of Stored Events) e NIP-16 (faixas de kind de evento) no final do mês, os documentos que ainda governam a semântica de sync de relay e a classificação regular-vs-substituível-vs-efêmero.

Maio de 2023

A explosão de especificação de protocolo. Sessenta e quatro PRs de NIP foram abertos naquele mês, com várias das propostas que definiram a superfície do Nostr para os próximos dois anos todas chegando em 31 dias, e o maior anúncio de financiamento que o Nostr já havia recebido chegou em 4 de maio com o grant OpenSats de $10 milhões do #startsmall de Jack Dorsey, o dinheiro que sustentou cada onda de grants Nostr desde então. NIP-47 (Nostr Wallet Connect) foi mesclado em 2 de maio, trazendo a especificação wallet-connect do Alby para o protocolo principal. Dois dias depois, Vitor Pamplona propôs NIP-53 Live Activities com salas kind:30311 e mensagens de chat kind:1311, a fundação para cada superfície de livestreaming Nostr que seguiu. Pablo Fernandez abriu NIP-84 Highlights em 5 de maio e NIP-89 Recommended Application Handlers em 14 de maio. v0l (Kieran Babich, autor do Snort) propôs NIP-98 HTTP Auth em 8 de maio, a primitiva de autenticação da qual NIP-96 e Blossom ambos depois dependeram. Jonathan Staab propôs NIP-32 Labels em 15 de maio, e NIP-30 Custom Emoji foi mesclado no mesmo dia. Arthur Franca propôs NIP-96 HTTP File Storage Integration em 21 de maio. Dois dias depois, Vitor adicionou zap splits ao NIP-57 e verbiricha adicionou rascunhos long-form kind:30024 ao NIP-23, a especificação que se tornou a fundação para fluxos de trabalho modernos de autoria long-form Nostr em Habla, YakiHonne e Highlighter. fiatjaf propôs NIP-29 Simple Groups no final do mês, o mesmo NIP-29 que Wisp, Flotilla, Chachi e 0xChat implementam em produção hoje.

Maio de 2024

O ciclo de consolidação. Menos propostas chamativas, mais entregas. NIP-54 Decentralized Wikis foi mesclado em 2 de maio com artigos kind:30818 e tags d normalizadas por caso. Três dias depois, NIP-56 foi estendido para que relatos de abuso pudessem sinalizar ameaças digitais (malware, phishing) junto com categorias apenas de conteúdo. Em 6 de maio, reações NIP-25 foram simplificadas para parar de incluir a thread de resposta inteira como tags e. Arthur Franca propôs NIP-22 Comment em 12 de maio, introduzindo kind:1111 para que respostas a eventos não-kind:1 (artigos, arquivos, produtos) obtenham uma forma estruturada de threading. Em 19 de maio, fiatjaf reformulou o NIP-46 para abandonar o NIP-04 inteiramente e mudar todo o tráfego bunker para criptografia NIP-44, o movimento de descontinuação que moldou cada implementação bunker desde. Em 20 de maio, NIP-71 Video Events foi mesclado com kind:21 e kind:22, e NIP-10 adicionou o argumento opcional de pubkey em tags e para que clientes possam resolver autores de thread sem primeiro buscar o evento referenciado. NIP-35 Torrents de Kieran Walsh foi mesclado em 22 de maio, e em 24 de maio o README dos NIPs referenciou pela primeira vez CIP-01 como uma proposta off-repo, sinalizando o início do padrão “NIPs como um de vários locais de proposta”. Em 25 de maio, um PR de limpeza removeu a tag aes-256-gcm do NIP-71 antes que implementações downstream a congelassem. NIP-96 adicionou list files e removeu o requisito de transformação em 27 de maio. Em 28 de maio, Jonathan Staab propôs elevar a barra de aceitação de NIP para exigir pelo menos duas implementações interoperáveis antes que um rascunho possa se graduar. Lado do cliente: Damus taggeou v1.7.2 e v1.8 mais uma v1.9 com tratamento completo de marcador NIP-10 em 9-10 de maio, trouxe autenticação NIP-98 em notificações push, e lançou suporte completo a marcador NIP-10. Amethyst tornou NIP-17 o modo padrão de DM em 14 de maio, construiu gerenciamento de relay outbox-model NIP-65, adicionou seleção de servidor NIP-96, e lançou derivação de chave NIP-06 BIP-32/BIP-39. Primal Android 0.99.2 em 10 de maio adicionou tagging de usuário e NWC de carteira externa, seguido por 0.99.4. Pablo Fernandez trouxe um cluster de optimistic-update NDK entre 24-31 de maio. Snort adicionou seleção de servidor NIP-96, e cashu-ts separou suas primitivas de criptografia em @cashu/crypto.

Maio de 2025

O mês em que NIP-77 (Negentropy Syncing) foi mesclado em 27 de maio, a especificação do fiatjaf e Doug Hoyte para o protocolo de fio que substitui filtros REQ de força bruta por computação de diferença de custo logarítmico. Este era o mesmo negentropy que strfry havia lançado dois anos antes como recurso do lado do relay, agora formalizado como um protocolo cliente-relay, e a entrada no README chegou no mesmo dia. Na semana anterior, NIP-23 long-form definiu como documentos HTML se associam a entidades Nostr através de uma tag <link> em 24 de maio, a primitiva de cópia web canônica. NIP-25 adicionou dicas de relay de alvo de reação em 22 de maio e removeu a recomendação emoji-para-like/dislike, tratando emojis como unidades semânticas distintas. NIP-52 foi simplificado em 14 de maio para focar nos kinds que os clientes estavam lançando em produção, o corte que tornou as extensões de calendário Formstr de um ano depois mais limpas de enxertar. Em 9 de maio, Follow Packs (kind 39089 listas de follow curadas) e Favorite Relays (uma nova lista substituível sob o NIP-51) entraram no README no mesmo dia. O arco do Protocolo Marmot ainda não havia começado: apenas o repositório whitenoise-rs existia (primeiro commit 9 de setembro de 2024), e maio de 2025 era sua fase de protótipo Svelte+Tauri, com o commit de 14 de maio removendo código específico do Tauri conforme o projeto pivotava para sua arquitetura atual. O core Rust dedicado MDK (12 de setembro de 2025), o repositório de especificação Marmot (19 de setembro de 2025), e a UI Flutter (2 de dezembro de 2025) todos vieram depois.

Maio de 2026

O mês coberto na Newsletter #21, #22, #23 e neste issue. A linha definidora é MLS-no-Nostr chegando a produção multi-cliente: MDK 0.8.0 lançou primitivas de leaf-index MIP-05 e key packages endereçáveis, seguido por PR #306 adicionando validação de mensagem efêmera NIP-40 entre iOS e Android através de uma superfície UniFFI compartilhada. White Noise v2026.5.22+25 lançou push no iOS através de uma Notification Service Extension que descriptografa ciphertext MLS dentro do processo de extensão para que o broker nunca veja plaintext, e dois novos clientes Marmot apareceram: Scramble (um cliente .NET/Avalonia para desktop e Android com slots KeyPackage multi-dispositivo) e Cordn (uma arquitetura MLS alternativa usando um coordenador por grupo sobre ContextVM). Angor migrou sua mensageria criptografada de NIP-04 para NIP-44 no PR #860, fechando o arco de descontinuação que abriu com a proposta NIP-44 de Paul Miller em maio de 2023. A equipe Formstr abriu a maior submissão coordenada de NIP na memória recente em 17 de maio, com PR #2350 para auto-remoção de participante, PR #2351 para eventos de calendário privados e recorrência (NIP-52E e NIP-52R), e PR #2352 para agendamento descentralizado de compromissos, todos com calendar.formstr.app já lançando a implementação de referência. Amethyst v1.11.0 renderizou eventos de calendário NIP-52 em sua própria categoria de linha do tempo, e o padrão de clientes controlados por agente que começou com AgentNoise na semana passada continuou com Vector v0.4.0 lançando um servidor MCP de 21 ferramentas e Shopstr abrindo sua superfície MCP como o primeiro marketplace-como-ferramenta-de-agente do Nostr.

Se você quiser discutir, mande uma DM para nós no Nostr.

Nostr Compass #23

Thu, 21 May 2026 00:00:00 +0000

Primal 3.5 lança uma shell Android reconstruída, Amethyst adiciona zaps Bitcoin onchain, White Noise ganha renderização de markdown e deep links, Keycast passa por uma auditoria de segurança, e AgentNoise permite controlar agentes de código IA locais através de chat criptografado pelo Marmot. Hostr lança uma plataforma de acomodações para aluguel P2P no Nostr com quatro NIPs em rascunho cobrindo listagens, reservas e escrow baseado em EVM. Angor migra mensageria criptografada de NIP-04 para NIP-44, Dart NDK adiciona NIP-77 e um signer web, Alby js-sdk v8 lança reconexão multi-relay NWC nativa, e KeyChat corrige uma lacuna de forward secrecy na exclusão de prekey único do Signal. No lado do protocolo, o bond anti-abuso do Mostro chega à Fase 2, Wisp lança respostas privadas e reações gift-wrapped, e uma onda de implementação NIP-05 do Namecoin toca meia dúzia de clientes em uma única semana.

Matérias principais

Primal 3.5 para Android

Primal, o cliente social apoiado por sua própria infraestrutura de relay de cache, lançou 3.5.9 esta semana com uma shell de aplicação reconstruída. O redesign substitui a estrutura de navegação anterior por um layout atualizado e uma nova tela Explore, dando à principal superfície de descoberta seu próprio home dedicado. A release adiciona reprodução de áudio para link previews, para que arquivos de áudio embutidos em notas sejam reproduzidos inline sem sair do feed. Badges de verificação NIP-05 agora aparecem inline nos perfis, apresentando confirmação de identidade em um relance. A filtragem de notificações recebeu uma reformulação, permitindo aos usuários restringir quais tipos de eventos chegam à sua lista de notificações. O editor ganhou melhor tratamento de event-links, e a camada de banco de dados subjacente recebeu correções de estabilidade.

White Noise: markdown, deep links e metadados de áudio

White Noise, o app de mensageria de grupo criptografado pelo Marmot construído sobre Nostr e MLS (RFC 9420), teve uma de suas semanas mais movimentadas nos repositórios de frontend e backend.

No frontend, PR #665 adiciona renderização completa de markdown para mensagens de chat, para que negrito, itálico, blocos de código e links agora sejam renderizados nativamente na visão de mensagem. PR #675 ativa o fluxo de sair de grupo que anteriormente era bloqueado para admins não-últimos, e PR #661 adiciona suporte nativo a deep link para URIs whitenoise:// e whitenoise-staging:// cobrindo usuários, chats e configurações, sem exigir nenhuma infraestrutura de redirecionamento HTTP.

No backend em whitenoise-rs, PR #835 faz a rotação de key package funcionar corretamente reutilizando o slot d_tag para publicações kind:30443, ativando a semântica de eventos substituíveis NIP-33 para que rotações sucessivas de key package substituam o evento anterior nos relays, mantendo apenas o key package atual. PR #833 estende FileMetadata com campos opcionais duration_ms e waveform para anexos de áudio, coordenado com o PR #300 do MDK que adiciona os mesmos campos às tags de mídia MIP-04. Uma nova crate whitenoise-markdown (PR #836) substitui o parser de tokens nostr-sdk anterior por uma biblioteca dedicada de renderização de markdown.

A própria especificação do protocolo Marmot recebeu uma correção de segurança no PR #68, que fecha um problema de segurança especificando explicitamente HKDF-SHA256 para derivações de chave de imagem no MIP-01, removendo ambiguidade que poderia levar à divergência de implementação. No MDK, PR #307 sanitiza motivos de falha em welcome e limita o comprimento armazenado, fechando uma constatação de segurança separada.

Amethyst v1.10.0: Zaps Bitcoin Onchain

Amethyst lançou quatro releases esta semana, com v1.10.0 como o destaque. A release adiciona suporte para zaps Bitcoin onchain NIP-BC, permitindo aos usuários enviar, receber e exibir zaps liquidados diretamente onchain via transações Bitcoin. Releases anteriores na sequência corrigiram a detecção de blob Blossom para rejeitar nomes de arquivo não conformes (v1.09.2), aplicaram patches nas regras do ProGuard para builds desktop, e mesclaram o pull request #2977 para mostrar zappers de Bitcoin onchain como uma linha ₿ dedicada na galeria expandida de reações. Uma tela de histórico de transações on-chain em progresso com paginação chegou no PR #2974.

AgentNoise: controle agentes de código sobre White Noise

AgentNoise por nvk é um helper de desktop nativo em Rust que permite usar um telefone rodando White Noise como superfície de controle para sessões locais de agentes de código Codex e Claude. A ferramenta escuta um ou mais chats White Noise, autentica remetentes através de um fluxo de PIN de primeiro pareamento, e lança agentes de código locais através do launcher configurado. Enviar /claude <prompt> do seu telefone abre uma nova sessão de trabalho White Noise nomeada segundo o hostname da máquina e um curto resumo do prompt, então transmite atualizações de progresso e saída final de volta para esse chat. É intencionalmente Rust-first e mantém Node fora do caminho da ponte confiável. O projeto chegou à v0.1.24 esta semana, adicionando respostas mais curtas legíveis para o telefone, referências de job por prefixo curto único, e um watcher de sessão local opcional. AgentNoise dirige os CLIs wn e wnd de marmot-protocol/whitenoise-rs como subprocessos, então compartilha seu transporte Nostr com o próprio cliente White Noise.

Auditoria de segurança do Keycast concluída

Keycast, o servidor de assinatura remota NIP-46 orientado a equipes que armazena chaves privadas Nostr criptografadas em repouso no SQLite, completou uma auditoria de segurança em maio de 2026. A passagem de hardening abordou questões de autenticação, permissão, integridade de dados e dependências, e os resultados estão documentados em AUDIT.md. As mudanças incluem: HTTP auth NIP-98 agora requer exatamente uma tag u e uma tag method, rejeita timestamps obsoletos e valida hashes payload; a allowlist ALLOWED_PUBKEYS é parseada exatamente e aplicada no servidor; políticas vazias agora fazem default-deny em requisições de sign/encrypt/decrypt; a aplicação de foreign-key é ativada em conexões SQLite; e rotas de app aninhadas como /teams/:id são protegidas no servidor. Uma migração SQL normaliza o JSON antigo de permissão allowed-kinds no startup. O projeto ainda está em estágio inicial e a auditoria observa itens residuais antes de confiá-lo com chaves reais de equipe.

Scramble: cliente Marmot para desktop e Android

Scramble (anteriormente OpenChat) é um cliente .NET/Avalonia para desktop e Android para o Protocolo Marmot, implementando MIPs 00-04: publicação de KeyPackage (kind:30443), metadados de grupo com a extensão MLS NostrGroupData, eventos welcome gift-wrapped NIP-59 (kind:444), mensagens criptografadas ChaCha20-Poly1305 (kind:445) e anexos de mídia criptografados Blossom. É totalmente interoperável com White Noise e qualquer outro cliente compatível com Marmot.

O projeto lançou 13 releases esta semana, com suporte multi-dispositivo como recurso principal. Cada dispositivo gera um slot único de KeyPackage (uma tag d no kind:30443). No startup, Scramble busca os próprios KeyPackages do usuário nos relays, detecta IDs de slot de dispositivos pares, e os adiciona automaticamente a grupos MLS existentes usando o fluxo de commit em stage. O auto-add é restrito a grupos onde o usuário atual é admin; grupos não-admin são pulados com orientação para pedir ao admin do grupo. Um banner de divulgação de forward-secrecy informa a dispositivos recém-vinculados que mensagens antigas não estão disponíveis. Uma passagem de reconciliação de ID de slot (TryReconcileSlotId) lida com dispositivos migrados de versões pré-multi-dispositivo comparando bytes de KeyPackage do relay com material de chave local para adotar a tag d correta. A reconexão de signer externo para usuários Amber e NIP-46 também foi corrigida: o guard IsConnected que bloqueava a auto-reconexão embutida do ExternalSignerService foi removido em todos os nove pontos de chamada em NostrService.

Hostr: acomodação para aluguel P2P no Nostr

Hostr (fonte) é uma plataforma peer-to-peer de acomodações para aluguel construída inteiramente no Nostr. Cobre todo o fluxo estilo Airbnb (buscar e listar propriedades, negociar reservas e liquidar pagamentos) usando quatro NIPs em rascunho que o projeto está desenvolvendo em paralelo com a aplicação.

O NIP de acomodação estende classificados NIP-99 (kind:30402 ativo, kind:30403 rascunho) com tags específicas de acomodação para tipo (room, house, apartment, villa, hotel, hostel, resort), horários de check-in/check-out, estadia mínima, e índices de células geoespaciais H3 para busca baseada em localização em precisão configurável. O NIP de reserva define um protocolo completo de negociação e ciclo de vida: eventos de reserva substituíveis kind:32122 carregam um trade ID d, uma tag âncora a de listagem, e tags p de participantes com papéis (buyer, seller, escrow); rumors de mensagem estruturada kind:1327 entregam contraofertas privadas de estágio de negociação via gift wraps NIP-59 para que a negociação fique fora de relays públicos; eventos de transição append-only kind:1326 criam uma trilha de auditoria pública uma vez que uma reserva é confirmada. A privacidade do comprador é preservada através de chaves Nostr temporárias por trade vinculadas à identidade real do comprador via tags participant_proof criptografadas. O NIP de escrow define anúncios de serviço de escrow kind:30303 e declarações de confiança de usuário kind:17388; a implementação de referência usa contratos inteligentes EVM em Rootstock, com contractBytecodeHash permitindo aos clientes verificar se o contrato implantado corresponde a uma implementação auditada conhecida. O NIP de listagem de marketplace define tags genéricas compartilhadas entre todos os perfis de marketplace NIP-99, incluindo instantBook, negotiable, quantity, securityDeposit, cancellationPolicy e maxDisputePeriod. Esta semana o projeto preparou sua submissão à app store e mesclou suporte a identidade de cliente MCP para automação voltada a agentes.

Duas novas entradas apareceram na plataforma Shakespeare MiniApps esta semana: InkPress, um gerador de revista por IA que publica conteúdo estruturado no estilo revista como eventos Nostr, e PressStr, uma plataforma de escrita e publicação para a stack Soapbox.

Lançando esta semana

ngit v2.4.4

ngit lançou v2.4.4, adicionando ngit sync --trust-server (-t) para casos em que um servidor git está fast-forward à frente do estado Nostr. Quando essa situação é detectada, o sync reporta as refs afetadas e requer a flag para assinar e publicar um evento de estado atualizado; uma configuração git nostr.trust-server-domains fornece uma allowlist separada por ponto e vírgula para servidores que devem ser confiados automaticamente sem a flag.

Amber v6.1.0-pre3 adiciona assinatura PSBT

Amber lançou v6.1.0-pre3 com layout melhorado para novas conexões de app, correções de crash, e uma opção select/deselect all na tela de permissões. PR #438 adiciona suporte a assinatura PSBT através dos caminhos baseados em Intent e em relay NIP-46, permitindo ao Amber assinar Partially Signed Bitcoin Transactions sem expor a nsec ao app requisitante.

Wisp v1.1.0 lança respostas privadas e remove suporte a Amber

Wisp lançou v1.1.0 com respostas privadas via gift wrap NIP-17 (PR #540), reações gift-wrapped e zaps DIP-03 em respostas privadas (PR #543), auto-tradução para notas (PR #523), e uma entrada em fiat estilo register no diálogo de zap. PR #541 migra zaps privados de um esquema plaintext de DM-relay caseiro para DIP-03 com roteamento adequado de DM-relay. O mesmo ciclo de release removeu o suporte a signer remoto NIP-55 (PR #531), abandonando Amber e outras integrações de signer externo, e removeu o relay local empacotado (PR #533). Wisp é um cliente social Nostr para Android.

Calendar by Formstr v1.5.4 corrige gift wrap para novos participantes

Calendar by Formstr lançou v1.5.4 (a mais recente em uma sequência v1.5.2 → v1.5.4). PR #160 corrige um bug onde editar um evento de calendário privado com novos participantes publicava o evento atualizado com as novas pubkeys em tags p mas nunca criava ou entregava convites gift wrap a esses participantes, quebrando o fluxo de convite para adições de última hora. PR #156 adiciona tratamento de erro em torno da descriptografia de eventos privados para que clientes não lancem mais em eventos indecodificáveis, e PR #138 corrige horários de eventos recorrentes que estavam desviando através de fusos horários.

Applesauce v6.1.0 adiciona git casts NIP-34 e relays de lookup NIP-51

Applesauce lançou v6.1.0 em seus pacotes com suporte significativo a NIP-34 (git-over-Nostr): applesauce-common adiciona novos casts GitRepository, GitGraspList e FavoriteGitRepos além de factories correspondentes, e expõe propriedades reativas User.favoriteGitRepos$, User.gitAuthors$ e User.graspServers$ para que aplicações possam listar repos git seguidos por um usuário, mantenedores de repo, e servidores GRASP configurados diretamente do mesmo objeto User. A mesma release adiciona suporte a listas de relay de lookup NIP-51 kind 10086, uma adição recente à família relay-list usada para descobrir onde encontrar dados específicos. applesauce-core ganha replaceableAddress em EventCast para lookup de endereço substituível NIP-01, além de pointer, kind e um helper getReplaceableAddressForEvent, e adiciona um método timeline$() no cast base User. PR #73 corrige métodos manuais de pool que descartavam silenciosamente relays offline.

Sprout v0.0.16 lança binário Sprig e protocolo huddle v2

Sprout pelo Block, um workspace de equipe auto-hospedado baseado em relay Nostr onde humanos e agentes IA compartilham as mesmas salas e log de eventos, lançou v0.0.16 do app desktop junto com builds contínuos do novo binário all-in-one Sprig (PR #605), que empacota o harness ACP, agente e MCP de desenvolvedor em um único binário estilo busybox para implantação fácil. A flag --no-memory adicionada no PR #611 permite a operadores desativar a injeção de memória central NIP-AE para o harness ACP. No lado de tempo real, PR #609 estende o protocolo de voz huddle a um header de frame v2 suportando até 10 pares simultâneos.

Nostrord v1.0.3 adiciona keychain do OS e multi-conta

Nostrord lançou v1.0.3 com armazenamento local de chave fortalecido usando keychain do OS e fallback de passphrase, suporte multi-conta, e um QR code de bunker tocável que abre o app signer no Android.

Angor migra para NIP-44 e lança fortalecimento de segurança

Angor, o app de crowdfunding Bitcoin construído em Nostr e Taproot, lançou três releases instáveis esta semana (v0.2.24, v0.2.25 e v0.2.26) com um conjunto de mudanças de fortalecimento de segurança e integração Nostr. PR #860 migra a mensageria criptografada Nostr de NIP-04 para NIP-44, substituindo o esquema baseado em XOR descontinuado por criptografia ChaCha20-Poly1305. PR #861 permite uploads de mídia Blossom sem uma carteira selecionada usando uma chave de auth Nostr efêmera, desbloqueando uploads para usuários que ainda não conectaram uma carteira. A série de segurança abordou várias categorias fortalecidas: PR #854 adiciona segurança de tipo para AngorKey e proteção de memória de mnemonic, PR #856 impõe validação em nível de protocolo para timelocks, taxas de fee, limites de dust e regras de penalidade, e PR #851 aplica fortalecimento não-disruptivo em oito categorias de severidade média e baixa. PR #859 corrige compatibilidade com GrapheneOS habilitando compilação AOT e removendo geração de código em runtime, e PR #855 evita perda de carteira em swipe-kill Android persistindo o estado da carteira antes do OS terminar o processo.

Alby js-sdk v8.0 lança reconexão multi-relay NWC

Alby js-sdk lançou a linha v8.0 (v8.0.1 até v8.0.3) com suporte a subscription NWC multi-relay. PR #516 atualiza a dependência nostr-tools e habilita auto-reconexão nativa através de múltiplos relays, substituindo a abordagem anterior de polling por lógica de reconexão nativa de relay. PR #542 substitui todas as chamadas console.debug por uma interface de logger injetável para que desenvolvedores de aplicações possam rotear diagnósticos SDK através de sua própria infraestrutura de logging. A release remove o polyfill WebSocket, exigindo Node.js 22 ou superior para consumidores do lado do servidor. v8.0.2 adicionou uma correção para um bug de import crypto de utils que quebrava certos bundlers.

KeyChat v1.41.1 corrige forward secrecy

KeyChat, um app de mensageria que combina o protocolo Signal com transporte de relay Nostr, lançou v1.41.1+6513. A correção em destaque impõe forward secrecy excluindo prekeys únicos Signal imediatamente após uma descriptografia bem-sucedida, fechando uma lacuna onde um prekey retido poderia ser usado para descriptografar mensagens passadas se o dispositivo fosse comprometido posteriormente. A release também adiciona preview de URL para mensagens consistindo de um único link, centraliza auto-download de mídia sob um novo FileDownloadManager com um limite automático de 20 MB, e refatora a busca de info de relay NIP-11 para forçar refresh em cold start para que configurações de fee de relay pago sempre carreguem corretamente.

Em desenvolvimento

Citrine mesclou PR #151 implementando aplicação de NIP-70: o relay Android agora bloqueia reposts que embutem conteúdo de eventos protegidos, como a especificação requer. PR #149 adiciona ações de exibição e cópia para múltiplos endereços de conexão, localhost, Wi-Fi local e Tor, a partir da tela de configurações do relay. PR #141 adiciona tratamento de challenge AUTH NIP-42 através de integração com signer externo Amber.

Mostro chegou à Fase 2 de seu rollout de bond anti-abuso. PR #737 aterrissa a lógica de slash de disputa dirigida pelo solver: handlers de admin agora consomem o payload BondResolution do mostro-core, permitindo que um admin dê slash no bond de qualquer parte ao resolver uma disputa. A Fase 1.5, mesclada no PR #736, introduziu uma ação dedicada PayBondInvoice e status WaitingTakerBond, separando o pagamento do bond anti-abuso do taker do payout de trade do buyer. O cliente mobile adicionou o UX completo da Fase 1.5 no PR #592. Mostro é um protocolo de câmbio Bitcoin peer-to-peer construído no Nostr.

Damus mesclou PR #3773 restaurando o indicador de sinal de relay, e PR #3775 corrige relays que se recusavam a reconectar após uma falha inicial de conexão.

rust-nostr mesclou PR #1358 adicionando traits de finalização de eventos e builders de evento específicos de NIP, tornando mais fácil construir eventos corretamente tipados para funções específicas de protocolo. PR #1363 faz backport de uma correção garantindo que o signer NIP-46 se inscreva em notificações antes de enviar a resposta de connect, fechando uma condição de corrida onde mensagens de cliente chegando imediatamente após connect poderiam ser perdidas.

dart-nostr mesclou PR #44 adicionando um resolver de relay Namecoin .bit e registros TLSA pin, permitindo que aplicações Flutter resolvam URLs de relay wss://example.bit/ através de DNS Namecoin para seus endereços WebSocket reais.

Dart NDK (o kit de desenvolvimento Nostr Dart/Flutter, agora em relaystr/ndk) mesclou PR #464 implementando NIP-77, o protocolo de assinatura offline de eventos. No lado do signer, PR #602 e PR #601 adicionam um signer de evento específico da web e uma abstração PlatformEventVerifier, permitindo que apps Flutter web usem o signer da plataforma sem um caminho de código separado; PR #604 introduz uma factory de signer de evento para seleção de signer em runtime. PR #608 adiciona getDmRelays() para buscar a lista de relays de DM NIP-17 de um usuário (kind:10050), e PR #600 corrige a preservação de campos assinados NIP-46 para que signers remotos não percam campos no round-trip.

Pages by Form* (repo), o app colaborativo de documentos Nostr-native do Formstr hospedado em pages.formstr.app, mesclou quatro PRs esta semana apertando os fluxos de anexo criptografado e gerenciamento de documentos. PR #37 corrige imagens faltando em exportações DOCX, HTML e PDF fazendo inline de anexos criptografados: busca blobs <encrypted-file> de servidores Blossom, descriptografa-os com AES-GCM 256-bit usando a chave e nonce armazenados, valida o tipo MIME da imagem e os converte em URLs data base64 para que exportações preservem imagens que só existem no Blossom em forma criptografada. PR #39 adiciona um mecanismo de busca local de documentos, PR #38 limpa o fluxo de renomear, e PR #40 corrige o tratamento de backup compartilhado.

Zap Cooking mesclou PR #396, a primeira fase de uma reformulação de feed que assenta primitivas de renderização de feed sem nenhuma mudança visível ao usuário ainda. O PR introduz um parser de tag imeta NIP-92 que lê os slots url, m (MIME), dim (dimensões), blurhash, alt, x (hash de arquivo) e fallback, mais um decodificador blurhash canônico portado à mão (~200 LOC) que produz URLs data PNG via canvas com um fallback null seguro para SSR. Quando tags imeta estão ausentes, o parser recorre a extrair URLs brutos de imagem e vídeo do conteúdo do evento usando as mesmas heurísticas que o feed atual já usa.

Nurunuru (ぬるぬる, tami1A84/null--nostr), um cliente Nostr com variantes nativas Android, iOS e Web compartilhando um motor FFI Rust, mesclou seu sync Native → Web v1.5.0 no PR #176. O sync traz várias adições de recursos ao build Web que já foram lançadas no Android v1.4.9 e iOS 1.0.4: o NotificationModal agora apresenta notificações de aniversário, detecção de zap de follow mútuo e notificações de reação com emoji customizado; o picker de reação abandona a linha rápida de reações padrão Unicode e centra o UX em emoji customizado; o motor de recomendação em lib/recommendation.js filtra usuários sem ícones ou display names e prioriza entradas Following com Recomendado carregando em background. Entrada de voz é o único recurso indo na outra direção: o build Web já usa streaming ElevenLabs Scribe, e v1.5.0 sincroniza parcialmente o lado Nativo para o SpeechRecognizer padrão do OS (Android) e SFSpeechRecognizer + AVAudioEngine (iOS) enquanto a integração completa do Native Scribe é adiada para v1.6.

Trabalho de protocolo e especificação

PR #2251 aperta a especificação de eventos protegidos NIP-70: agora afirma explicitamente que reposts embutindo o conteúdo completo de um evento protegido devem ser rejeitados pelos relays. NIP-70 define a tag - que sinaliza que um autor de nota não consente com ter sua nota republicada. A especificação original cobria o comportamento de filtragem do relay, mas deixava o caso de repost ambíguo. Este PR fecha essa lacuna. O PR #151 do Citrine implementa a aplicação no lado do relay nesta mesma semana.

PR #1653 propõe um NIP de Drafts para salvar e sincronizar eventos de rascunho privados. A proposta usa eventos substituíveis com um status draft e criptografia NIP-44 para a própria chave do autor, permitindo aos clientes salvar trabalhos em progresso em relays sem que esses eventos sejam visíveis a mais ninguém. O evento draft carrega o evento de publicação pretendida completo como conteúdo criptografado, incluindo seu eventual kind e tags.

Snapshots (PR #2279) é uma proposta aberta para definir um evento de snapshot imutável para preservar uma versão exata de um evento Nostr substituível. O evento snapshot carrega o conteúdo completo do evento substituível em um ponto dado no tempo, com uma tag a ligando-o de volta ao endereço do evento substituível para que todas as versões históricas sejam consultáveis juntas. Isso torna possível para observadores inspecionar estado histórico mesmo após relays pararem de reter versões antigas.

Onda de NIP-05 Namecoin: Esta semana viu um esforço coordenado para adicionar resolução NIP-05 .bit a clientes Nostr. O feed de discussão de NIP capturou PRs open-source contra Aegis (#14, que adiciona verificação no momento da assinatura no signer), nostter (#2128) e dart-nostr (#44), junto com um rascunho de NIP upstream (PR #2349). O PR do Aegis é notável por colocar a verificação no lado produtor: o signer verifica a chain Namecoin antes de assinar qualquer evento kind:0 que reivindique uma identidade .bit e avisa o usuário em caso de mismatch, capturando o problema antes que o evento chegue a qualquer relay.

Deep Dive de NIP: NIP-07 (window.nostr para Navegadores Web)

NIP-07 define a interface window.nostr que extensões de navegador expõem a aplicações web. É a interface de signer mais amplamente implantada na web, implementada por extensões incluindo Alby, nos2x, Flamingo e horse.

A interface tem dois métodos obrigatórios e vários opcionais. window.nostr.getPublicKey() retorna a chave pública do usuário como uma string hex sem nunca expor a chave privada à página chamadora. window.nostr.signEvent(event) recebe um evento parcial com created_at, kind, tags e content, e retorna o evento assinado completo com id, pubkey e sig adicionados. O ponto chave é que a chave privada nunca deixa o contexto isolado da extensão; a aplicação web submete um evento não assinado e recebe de volta um assinado.

Os métodos opcionais cobrem criptografia: window.nostr.nip04.encrypt e window.nostr.nip04.decrypt para o esquema mais antigo NIP-04 (agora descontinuado), e window.nostr.nip44.encrypt e window.nostr.nip44.decrypt para o esquema atual NIP-44. Extensões que suportam NIP-44 podem portanto lidar tanto com criptografia de mensagens diretas quanto com qualquer outra aplicação que precise de criptografia com chave por pubkey sem a página chamadora ver a nsec.

A especificação também inclui uma recomendação aos autores de extensões: carregue scripts com "run_at": "document_end" no manifest da extensão para que window.nostr esteja disponível sincronamente quando a página carrega, evitando condições de corrida onde um cliente verifica window.nostr antes de a extensão tê-lo injetado.

Um exemplo chave de NIP-07 em ação é o projeto Keycast coberto acima. O frontend web do Keycast usa NIP-07 para assinar eventos HTTP auth NIP-98: o app SvelteKit nunca manuseia a nsec do usuário diretamente. Ele chama window.nostr.signEvent para produzir o header de auth, então envia esse header à API do Keycast. Essa arquitetura significa que o material da chave fica na extensão do navegador durante todo o fluxo de gerenciamento de chaves de equipe.

{
 "id": "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2",
 "pubkey": "7f8e9d0c1b2a3e4f5d6c7b8a9f0e1d2c3b4a5f6e7d8c9b0a1f2e3d4c5b6a7f8a",
 "created_at": 1747785600,
 "kind": 1,
 "tags": [],
 "content": "Hello from a NIP-07 signed event",
 "sig": "0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2cdd"
}

Deep Dive de NIP: NIP-39 (identidades externas em perfis)

NIP-39 define como um usuário Nostr pode declarar controle sobre identidades de plataformas externas em seu perfil. Cada declaração usa uma tag i dentro de um evento kind:10011, afirmando propriedade de uma conta específica em outra plataforma junto com uma prova que pode ser verificada independentemente.

Cada tag segue o formato ["i", "platform:identity", "proof"], onde platform:identity combina o nome da plataforma e o nome de usuário com um separador de dois-pontos (github:semisol, twitter:semisol_public). proof aponta para um artefato verificável na própria plataforma.

Para GitHub, a prova é um Gist ID. O usuário cria um Gist público de sua conta GitHub contendo o texto Verifying that I control the following Nostr public key: npub1.... Um cliente verificando a reivindicação busca https://gist.github.com/<identity>/<proof> e verifica que o Gist foi criado pelo nome de usuário GitHub reivindicado e contém a pubkey esperada. Para Twitter a prova é um tweet ID, para Mastodon um post ID, e para Telegram uma referência de mensagem em um grupo público.

O nome do provedor de identidade deve conter apenas a-z, 0-9 e os caracteres ._-/, e não deve conter :. Nomes de identidade devem ser normalizados para minúsculas, com o alias primário usado quando múltiplos existem.

A discussão NIP-05 .bit do Namecoin acontecendo esta semana mostra o papel do NIP-39 na stack de identidade mais ampla: fornece uma forma padronizada e agnóstica a relay de cross-referenciar uma chave Nostr com uma identidade estabelecida em outro lugar, sem exigir nenhuma autoridade de verificação central. Um cliente pode verificar independentemente a prova buscando um artefato público na plataforma nomeada, e a prova está vinculada à pubkey Nostr específica no texto do Gist ou tweet, não a uma credencial genérica da plataforma.

{
 "id": "b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3",
 "pubkey": "7f8e9d0c1b2a3e4f5d6c7b8a9f0e1d2c3b4a5f6e7d8c9b0a1f2e3d4c5b6a7f8a",
 "created_at": 1747785600,
 "kind": 10011,
 "tags": [
 ["i", "github:semisol", "9721ce4ee4fceb91c9711ca2a6c9a5ab"],
 ["i", "twitter:semisol_public", "1619358434134196225"],
 ["i", "mastodon:bitcoinhackers.org/@semisol", "109775066355589974"]
 ],
 "content": "",
 "sig": "1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3eff"
}

É isso por esta semana. Se você está construindo algo ou tem novidades para compartilhar, mande uma DM para nós no Nostr ou nos encontre em nostrcompass.org.

Nostr Compass #22

Wed, 13 May 2026 00:00:00 +0000

Bem-vindo ao Nostr Compass, o seu guia semanal sobre o desenvolvimento do protocolo Nostr.

Esta semana: O Nostr VPN lança oito versões em sete dias desde um fluxo de emparelhamento de dispositivos redesenhado até uma troca de AEAD que duplica aproximadamente o débito TCP. O Marmot Protocol (a fundação do White Noise) lança uma versão frontend que completa a funcionalidade de bloqueio de utilizadores e 31 PRs em MDK e backend. O Grain lança v0.6.0 com quatro novas implementações de NIP num único marco. O Citrine lança v3.0.0-pre1 com Tor integrado e agregação de relay. O Amber lança v6.1.0-pre2 com melhorias no fluxo de conexão e assinatura. O Alby Hub lança v1.22.2 com uma página de IA e Agentes e integração com Core Lightning. O Mostro lança bonds de taker concorrentes e o mostro-core v0.11.0. O Jumble lança cinco versões com histórico de pesquisa recente e correções de persistência de dados de conta. O Nostrord lança três versões com modais de partilha de grupo e pacotes Arch Linux. O Flotilla lança 1.8.0 com videochamadas, renderização de email e menções de sala. O Calendar by Formstr lança v1.5.1 com agendamento de consultas e sincronização com o calendário Android. O Tamagostrich lança um Tamagotchi NIP-78 descentralizado com recompensas em sats. As discussões de NIP apresentam Reservas, Serviços de Custódia, Listagens de Alojamento, Zaps Onchain e regras de comunidade verificáveis. Dois mergulhos profundos em NIP cobrem o NIP-78 (dados específicos de app) e o NIP-98 (HTTP Auth).

Principais histórias

Nostr VPN lança oito versões culminando em v4.0.10

O Nostr VPN, a VPN mesh descentralizada baseada em Rust que usa Nostr para descoberta de pares e um protocolo noise apoiado em FIPS para o plano de dados, lançou oito versões de v4.0.1 a v4.0.10 em macOS, Linux, Windows e Android esta semana.

A mudança principal está no v4.0.8: o AEAD foi trocado do backend soft chacha20poly1305 do RustCrypto para o ChaCha20-Poly1305 do BoringSSL no ring 0.17, que usa NEON otimizado manualmente em aarch64 e AVX2/AVX-512 em x86_64. Os benchmarks Docker em hardware idêntico mostraram o débito TCP direto de 2 nós a saltar de 437 para 1097 Mbps. O formato wire não foi alterado.

No início da semana, o v4.0.1 reconstruiu o fluxo de emparelhamento de dispositivos com proteção contra fuga de nó de saída, um bloco de configuração WireGuard unificado em Nós de Saída e artefactos macOS assinados e notarizados. O v4.0.2 melhorou a descoberta LAN com sockets multicast reutilizáveis para que pares na mesma LAN prefiram caminhos de underlay diretos. O v4.0.9 adicionou batching sendmmsg(2) no caminho de envio UDP, empurrando o stream único TCP de 1066 para 1548 Mbps (1,45×). O v4.0.10 lançou uma revisão completa de UX para emparelhamento de dispositivos: Convidar Dispositivos e Aderir à Rede são agora cartões separados, a importação automática dispara ao colar uma string nvpn://invite/, e o emparelhamento próximo dividiu-se em dois toggles independentes de 15 minutos.

Marmot/White Noise lança frontend com bloqueio completo e 31 PRs em MDK e backend

O White Noise, a app de mensagens de grupo privadas construída sobre o protocolo Marmot baseado em MLS, lançou v2026.5.7+24 a 7 de maio como a versão frontend que completa o conjunto de funcionalidades de bloqueio. A versão anterior lançou silêncio, pesquisa e arquivo; esta conclui o bloqueio. Um utilizador bloqueado fica agora oculto de convites, pré-visualizações de chat, linhas de tempo de mensagens, resultados de pesquisa e notificações, e as suas mensagens deixam de contar para os contadores de não lidos. Os anexos de vídeo funcionam de ponta a ponta em todos os dispositivos. O aviso de offline cobre agora todos os ecrãs.

O trabalho de suporte abrange 31 PRs em MDK e backend. O MDK recebeu a PR #258 com o formato wire da extensão v3 e o esquema disappearing_message_secs, preparando o terreno para mensagens temporárias.

O trabalho de frontend inclui a PR #653 que corrige resumos de chats arquivados usando uma consulta pontual para que os chats arquivados sejam renderizados corretamente, a PR #644 que expõe um stream subscribe_to_group_state ao Dart para atualizações reativas de UI, e a PR #635 que corrige a recuperação de notificações de signatário externo Android quando a app de assinatura é iniciada a frio.

Grain v0.6.0 adiciona NIP-40, NIP-50, NIP-70 e NIP-45

O Grain, o relay Nostr e biblioteca de cliente baseados em Go, lançou v0.6.0 a 6 de maio com quatro novas implementações de NIP e uma passagem de reforço de produção. O marco v0.6 adiciona expiração de eventos NIP-40, pesquisa de texto completo NIP-50, eventos protegidos NIP-70 e contagem de eventos NIP-45.

A expiração de eventos via NIP-40 permite aos publicadores definir um timestamp de expiração para que o relay descarte eventos após expiração. A pesquisa de texto completo NIP-50 permite que clientes emitam filtros search em mensagens REQ. Os eventos protegidos via NIP-70 impedem relays de partilhar eventos sem permissão explícita do autor. As consultas de contagem NIP-45 permitem que clientes peçam a um relay para devolver uma contagem de eventos correspondentes, reduzindo a largura de banda para consultas do tipo “quantas notas tem este utilizador”.

A versão também inclui reforço de produção: configurações padrão mais seguras, respostas de rejeição NIP-01 corrigidas e melhor contrapressão para consumidores lentos.

Lançamentos desta semana

Citrine v3.0.0-pre1 traz Tor integrado e agregação de relay

O Citrine, a app Android que transforma um telemóvel num nó relay Nostr, lançou v3.0.0-pre1 como pré-lançamento esta semana. As principais adições são suporte Tor integrado para acesso a relay que preserva a privacidade e agregação de relay, onde o Citrine pode recolher eventos de múltiplos relays upstream e servi-los a clientes locais. A PR #139 adiciona suporte a NIP-77 (Reconciliação Negentropy) para sincronização de eventos eficiente baseada em reconciliação de conjuntos. A PR #137 encaminha todos os URLs através do proxy Tor, a PR #133 alivia a pressão na thread de UI no caminho de receção de eventos, e a PR #132 reduz o consumo de bateria do agregador de relay. A versão também adiciona uma vista de análise de eventos com um gráfico circular que divide os eventos armazenados por tipo.

Amber v6.1.0-pre2 melhora o fluxo de conexão de nova app

O Amber, a app Android de assinatura para NIP-55 (Aplicação de Assinatura Android) e NIP-46, lançou v6.1.0-pre2. As principais correções: o diálogo de assinatura fecha agora corretamente após aceitar um pedido bunker, pedidos bunker malformados mostram um ecrã de pedido inválido, e é adicionada limitação de taxa para pedidos de assinatura baseados em intent. A PR #430 corrige fugas de memória e ineficiências no caminho de assinatura.

Alby Hub v1.22.2 adiciona página de IA e Agentes e suporte ao Core Lightning

O Alby Hub, o nó Lightning auto-custodial e servidor Nostr Wallet Connect, lançou v1.22.2 com várias adições importantes. A nova página de IA e Agentes expõe as capacidades Lightning e NWC do Alby Hub a agentes de IA e ferramentas compatíveis com MCP. Um modo de carteira onchain integrado permite aos utilizadores receber e enviar Bitcoin onchain diretamente do Alby Hub. Rótulos personalizados para transações melhoram a contabilidade. As páginas de definições foram redesenhadas para maior clareza. A funcionalidade mais solicitada desde o lançamento chegou: Core Lightning (CLN) é agora um backend suportado a par do LND e LDK.

Mostro lança bonds de taker concorrentes e mostro-core v0.11.0

O Mostro, o protocolo de negociação Bitcoin peer-to-peer no Nostr, fundiu 11 PRs esta semana avançando a funcionalidade de bond de taker que previne griefing ao exigir que ambas as partes bloqueiem fundos antes de uma negociação prosseguir. A PR #733 implementa bonds de taker concorrentes onde múltiplos takers podem submeter faturas de bond simultaneamente e o primeiro a bloquear ganha, descartando os outros. A PR #735 alinha o memo da fatura de bond com a secção 6.1 da especificação.

O mostro-core lançou v0.11.0 com as adições correspondentes à biblioteca: a PR #144 adiciona Action::PayBondInvoice e Status::WaitingTakerBond, e a PR #143 adiciona o payload BondResolution para ações de liquidação e cancelamento de administrador. O mostro-cli lançou v0.15.0 atualizando para mostro-core 0.11.0.

Jumble lança cinco versões com pesquisa recente e persistência de conta

O Jumble, o cliente Nostr centrado em relay disponível como app web e app desktop Electron, lançou cinco versões esta semana: v26.5.2 a v26.5.6. O v26.5.2 agrupa notificações por Hoje / Esta semana / Este mês / Anteriores com cabeçalhos de data fixos. O v26.5.3 lança um .zip macOS a par do .dmg para que a versão desktop Electron possa aplicar atualizações automáticas no local. O v26.5.4 adiciona um seletor de emoji implementado internamente com abas de pacotes de emoji. O v26.5.5 adiciona histórico de pesquisa recente. Um bug crítico de persistência é corrigido no v26.5.6: as contas e dados em cache sobrevivem agora a um reinício completo da app.

Nostrord lança modais de partilha de grupo, upload de media e pacotes Arch Linux

O Nostrord, um cliente Nostr direcionado a grupos baseados em relay NIP-29, lançou v1.0.0, v1.0.1 e v1.0.2 esta semana. O v1.0.1 lança pacotes Arch Linux via AUR como nostrord-bin com artefactos .pkg.tar.zst assinados com PGP (PR #44), um botão para saltar para o mais recente quando se está a rolar para cima num canal ativo (PR #45), e colagem de imagem e media diretamente no input de chat (PR #46). O v1.0.2 adiciona partilha de grupo via PR #49 com um modal de partilha que gera tanto um URI nostr:naddr (kind 39000, NIP-19 + NIP-21) como um link nostrord.com/open/ compatível com web.

FIPS v0.3.0 lança alcance multiplataforma, descoberta de pares Nostr e gateway para LANs não modificadas

O FIPS (Free Internetworking Peering System), o projeto de rede mesh nativo de Nostr coberto no #20, lançou v0.3.0 esta semana, um marco importante que alarga o projeto de Linux-only para Linux, macOS, Windows e OpenWrt.

A principal adição é a descoberta de pares mediada por Nostr com travessia NAT UDP assistida por STUN. Os nós publicam agora anúncios de overlay assinados como eventos substituíveis parametrizados kind:37195 em relays Nostr públicos. Quando ambos os pares estão atrás de NAT, o daemon coordena um hole punch usando sinalização NIP-59 (Gift Wrap) para a troca offer/answer.

Um novo binário fips-gateway permite que hosts LAN não modificados alcancem destinos mesh sem executar o daemon FIPS. A mesma troca ring 0.17 ChaCha20-Poly1305 que impulsionou o salto de débito do Nostr VPN esta semana também chega ao FIPS v0.3.0. Os benchmarks em aarch64 mostram o stream único TCP de dois nós a passar de 437 para 1097 Mbps e a latência de ping do caminho de relay de três nós a cair de uma média de 7,68 ms para 0,72 ms.

Camelus v1.10.1 lança versões desktop

O Camelus, o cliente Nostr para Android e desktop, lançou v1.10.1 com versões desktop para Windows e Linux, expandindo de uma distribuição apenas para dispositivos móveis.

Flotilla 1.8.0 lança videochamadas, renderização de email e menções de sala

O Flotilla, a app de chat de grupo baseada em relay NIP-29 do hodlbod, lançou 1.8.0 esta semana com várias adições notáveis. As salas de voz suportam agora vídeo: os participantes podem ligar câmaras ou partilhar o ecrã durante uma chamada. A renderização de email chega através de uma atualização à biblioteca welshman: o Flotilla pode agora receber mensagens que incorporam conteúdo de email HTML, renderizando o HTML inline com formatação, imagens e links intactos. As menções de sala permitem que os utilizadores referenciem outras salas e relays com links inline clicáveis. A pesquisa de espaço inclui agora conteúdo de mensagens e correspondências locais para além dos nomes de canais.

Calendar by Formstr lança v1.5.1 com agendamento de consultas e sincronização com calendário Android

O Calendar by Formstr (github.com/formstr-hq/nostr-calendar), uma app de calendário nativa Nostr para eventos públicos e privados, lançou v1.5.0 a 10 de maio e v1.5.1 a 11 de maio. O agendamento de consultas chega na PR #89, permitindo que os utilizadores criem slots de tempo reserváveis no seu calendário. A integração de calendário Android somente leitura na PR #123 sincroniza eventos Nostr com o calendário do dispositivo. As notificações de eventos chegam na PR #130. O v1.5.1 segue com uma correção de bug de URL e atualização de metadados ZSP.

Em desenvolvimento

Amethyst adiciona posts agendados, regras de comunidade NIP-9A e relay local desktop

O Amethyst, o cliente Android rico em funcionalidades, fundiu 78 PRs esta semana em várias áreas de funcionalidades importantes.

Os posts agendados chegam ao Android na PR #2765: os utilizadores podem compor uma nota e definir um tempo de publicação futuro, com a fila gerida localmente no dispositivo. Uma versão desktop ganha um relay local embutido com persistência de eventos SQLite na PR #2841.

Três PRs implementam regras de comunidade NIP-9A diretamente no cliente: a PR #2798 valida posts contra regras de comunidade no compositor antes de enviar, a PR #2799 adiciona um editor de regras NIP-9A estruturado ao fluxo de nova comunidade, e a PR #2800 adiciona um filtro de feed NIP-9A opcional. A PR #2812 redige segredos e payloads sensíveis dos logs de debug. A PR #2821 adiciona tags ricas NIP-92 (imeta) a cada evento HLS publicado e autopublica uma nota kind:1 auxiliar para que as transmissões ao vivo apareçam em feeds padrão.

Shopstr adiciona registo de auditoria MCP e segurança de sessão

O Shopstr, o mercado descentralizado no Nostr, fundiu cinco PRs esta semana. O registo de auditoria para a camada de ferramentas MCP chega na PR #456. A segurança de sessão reforça-se na PR #477, que fixa sessões MCP à sua chave API de origem e adiciona desalocação por TTL para evitar sequestro de sessão.

Dart NDK adiciona suporte web e verificação de assinatura de seal

O Dart NDK, a biblioteca Dart para desenvolvimento de protocolo Nostr usada em apps Flutter, fundiu seis PRs esta semana. O suporte web chega no SembastCacheManager via PR #571. A verificação de assinatura de seal chega na PR #595 para o fluxo NIP-59 (Gift Wrap).

rust-nostr refatora tags e conexão proxy

O rust-nostr, o SDK Rust com bindings para Python, Kotlin, Swift e JavaScript, fundiu três PRs esta semana. A PR #1347 é uma grande reformulação de tags que normaliza o acesso a tags em todo o SDK. A PR #1351 substitui o tipo Connection por Proxy na camada SDK.

Sprout lança v0.0.10 e v0.0.11

O Sprout, o cliente Nostr e relay da Block coberto no #21, lançou v0.0.10 e v0.0.11 com melhorias no autocompletar de menções, suporte para download de imagens e correções de tratamento de erros de agentes.

Clave continua o rollout de NostrConnect multi-conta

O Clave, o signatário remoto iOS NIP-46 coberto no #21, lançou versões adicionais esta semana avançando o trabalho de NostrConnect multi-conta. A PR #52 promove o Connect de uma folha apresentada a partir da vista principal para um tab de nível superior entre contas. Uma correção de segurança no build 71 fecha um bypass do limite de 5 ligações por conta.

Novos projetos

Tamagostrich lança um Tamagotchi NIP-78 descentralizado com recompensas em sats

O Tamagostrich é um jogo de animal de estimação virtual baseado em browser lançado no IDENTITY Hackathon 2026 onde um avestruz bebé, Nori, evolui através da atividade social Nostr do utilizador. O estado do animal vive num evento NIP-78 kind:30078 para que sincronize em todos os dispositivos que partilham o mesmo par de chaves. Zaps, reações, reposts e novos seguidores concedem XP; sem atividade, a felicidade e energia decaem 100 pontos por 24 horas. As recompensas de marco pagam em sats automaticamente via NIP-47 (Nostr Wallet Connect): 50 sats no nível 5, 210 sats no nível 10 e 420 sats no nível máximo 21.

Trabalho de protocolo e especificação

O repositório de NIPs fundiu a PR #2338 corrigindo links de referência README para tipos de eventos Marmot e o kind geocaching 37516. Cinco novas propostas abriram esta semana:

A PR #2331 propõe o NIP-9A: Regras de Comunidade Verificáveis, introduzindo kind:34551, um evento substituível parametrizado que permite ao proprietário de uma comunidade publicar um documento de regras legível por máquina e assinado criptograficamente. Os clientes obtêm as regras antes de o utilizador submeter um post e rejeitam o rascunho localmente se violar alguma regra.

A PR #2335 propõe Eventos de Reserva para Mercados Nostr, definindo kind:32122 (eventos de reserva substituíveis parametrizados), kind:1326 (registos de auditoria de transição apenas de adição) e kind:32124 (avaliações pós-negociação). A negociação é privada: os rascunhos de propostas são enviados como eventos filho de mensagem estruturada embrulhados em gift wrap NIP-59 entre comprador e vendedor.

A PR #2334 propõe Serviços de Custódia para Mercados Nostr, usando kind:30303 para operadores de custódia declararem o seu endereço de contrato EVM, hash de bytecode, cadeia suportada, tabela de taxas e tokens aceites.

A PR #2333 propõe Perfis de Listagem de Alojamento para Listagens de Mercado NIP-99, estendendo as listagens classificadas NIP-99 com tags de índice geoespacial H3 e campos promovidos específicos de alojamento para listagens de arrendamento de curta duração.

A PR #2332 propõe NIP-BC: Zaps Onchain (kind 8333), explorando uma identidade direta entre chaves Nostr e endereços Bitcoin Taproot: uma pubkey Nostr é uma chave secp256k1 x-only de 32 bytes, tal como uma chave interna BIP-341 P2TR, o que significa que qualquer utilizador Nostr já tem um endereço Bitcoin mainnet determinístico derivável da sua pubkey, sem necessidade de LNURL, custodiante ou endereço Lightning.

Mergulho profundo em NIP: NIP-78 (Dados específicos de app)

O NIP-78 define uma forma padrão para as aplicações armazenarem dados arbitrários privados ou públicos em nome de um utilizador usando eventos Nostr. O tipo de evento principal é 30078, um evento substituível parametrizado onde a tag d é uma string de identificador definida pela aplicação. Uma aplicação dá ao seu slot de armazenamento uma tag d única (por exemplo tamagostrich-pet-state ou amethyst-settings) e publica um evento 30078 com o conteúdo JSON ou texto que precisa de persistir. Como 30078 é substituível e com âmbito por tag d, a aplicação pode atualizar o estado armazenado publicando um novo evento com a mesma tag d, e o relay retém apenas a versão mais recente.

{
 "id": "<hex de 64 caracteres>",
 "pubkey": "<hex de 64 caracteres>",
 "created_at": 1747180800,
 "kind": 30078,
 "tags": [
 ["d", "tamagostrich-pet-state"]
 ],
 "content": "{\"level\":7,\"xp\":1420,\"happiness\":82,\"energy\":61}",
 "sig": "<hex de 128 caracteres>"
}

A motivação principal é a sincronização entre dispositivos sem um servidor centralizado. Qualquer cliente que conheça a chave pública de um utilizador e a tag d da aplicação pode obter o estado atual do conjunto de relays do utilizador e reconstruir o estado da aplicação em qualquer dispositivo. O utilizador é dono dos dados porque vivem em eventos assinados pelo seu par de chaves.

Para dados de aplicação privados, os eventos NIP-78 podem encriptar o campo de conteúdo usando NIP-44 (Encriptação Versionada) ou o mais antigo NIP-04 antes de publicar. Para dados de aplicação públicos, como os distintivos de conquista do Tamagostrich exibidos no perfil do utilizador, podem ser armazenados sem encriptação.

A especificação deixa deliberadamente o formato do conteúdo em aberto. As aplicações escolhem o seu próprio esquema; o NIP-78 apenas padroniza o tipo de evento e o mecanismo de âmbito por tag d.

Os utilizadores atuais do NIP-78 incluem o Tamagostrich (sincronização de estado do animal), o Wisp (backup de carteira kind:30078 e sincronização de definições de segurança entre dispositivos), o NosPress (estado de orquestração CMS) e várias implementações de sincronização de definições de cliente Nostr.

Fontes primárias:

Especificação NIP-78
Tamagostrich: implementação em produção esta semana

Ver também:

Mergulho profundo em NIP: NIP-98 (HTTP Auth)

O NIP-98 define um esquema de autenticação HTTP que permite que pares de chaves Nostr autorizem pedidos a servidores HTTP, eliminando a necessidade de nomes de utilizador, palavras-passe ou tokens OAuth para acesso a API do lado do servidor. Um cliente constrói um evento Nostr de curta duração do kind 27235, assina-o com a sua chave privada, codifica o JSON em base64 e envia-o num cabeçalho HTTP Authorization: Nostr <base64>.

{
 "id": "<hex de 64 caracteres>",
 "pubkey": "<hex de 64 caracteres>",
 "created_at": 1747180800,
 "kind": 27235,
 "tags": [
 ["u", "https://files.example.com/upload"],
 ["method", "POST"],
 ["payload", "<hash-sha256-do-corpo-do-pedido>"]
 ],
 "content": "",
 "sig": "<hex de 128 caracteres>"
}

O evento kind 27235 inclui o método HTTP numa tag method, o URL completo do pedido numa tag u e um timestamp created_at. O servidor valida a assinatura, verifica que o método e URL correspondem ao pedido real, e confirma que o timestamp é recente (dentro de alguns minutos) para evitar ataques de replay.

O design significa que qualquer servidor que implemente NIP-98 pode autenticar utilizadores Nostr sem qualquer registo prévio, criação de conta ou segredo partilhado. Da perspetiva do utilizador, a autenticação é transparente: a sua chave de assinatura Nostr é também a sua credencial de API.

O NIP-98 é usado no Blossom (BUD-01) para autenticar uploads e downloads de blobs. O Routstr usa-o para controlo de acesso à API HTTP por pedido com RBAC a nível de npub. O Sprout usa-o para autenticação de transporte git e acesso REST ao relay. O Clave usa-o para chamadas de emparelhamento proxy. O Alby Hub usa autenticação derivada de NIP-98 para a sua API de administração, e o Nostr.build usa-o para autorização de upload.

A especificação define uma extensão opcional: uma tag payload contendo o hash SHA-256 do corpo do pedido, que permite ao servidor verificar que o evento assinado e o corpo do pedido foram criados juntos, impedindo um MITM de substituir um corpo diferente após o cliente ter assinado o evento de autenticação.

Fontes primárias:

Ver também:

NIP-96: Integração de Armazenamento de Ficheiros HTTP

Nostr Compass #21

Wed, 06 May 2026 00:00:00 +0000

Bem-vindo ao Nostr Compass, o seu guia semanal sobre Nostr.

Esta semana: O Marmot Protocol lança o MDK 0.8.0 com os primeiros primitivos de notificação MIP-05, pacotes de chaves NIP-51 endereçáveis e uma revisão de segurança reforçada. O LaWallet NWC lança v0.10.0, o maior lançamento desde o financiamento OpenSats, trazendo um painel de administração completo, carteira para o utilizador, registo de atividade de ponta a ponta e o novo esquema LightningAddress 1→N e NWCConnection. O Amethyst realiza um sprint de estabilização do Nests com eliminação de falhas de áudio durante a renovação JWT, subscrições de dados de chave com consciência do ciclo de vida, reconexão keep-alive de relay e um indicador animado do participante que está a falar. O ngit lança v2.4.2 e v2.4.3 corrigindo a deteção de servidores GRASP para submissões de PR e a filtragem de eventos de estado multi-remote. O GRAIN lança v0.5.4 com reforço de produção e uma correção silenciosa de perda de dados. O Mostro Core lança v0.10.1 com artefactos de lançamento assinados com PGP. O Clave lança v0.2.0 com suporte a múltiplas contas no iOS.

Principais histórias

MDK 0.8.0 adiciona primitivos de notificação MIP-05 e pacotes de chaves endereçáveis

O MDK, a biblioteca central em Rust do protocolo Marmot, lançou v0.8.0 a 4 de maio. Este lançamento inclui os primeiros blocos de construção de notificação MIP-05, move os pacotes de chaves MIP-00 para eventos endereçáveis para que o pacote de chaves de um utilizador possa ser substituído no lugar, melhora a compatibilidade de grupos com versões mistas, expande a cobertura UniFFI para bindings móveis e reforça os caminhos de validação em torno de ações administrativas, commits, armazenamento, limites de encriptação e tratamento de replays. Os primitivos MIP-05 incluem helpers de índice de folha adicionados na PR #235, que fornecem aos clientes downstream informação suficiente para entregar notificações push por destinatário sem revelar a estrutura do grupo. A PR #273 restaura a publicação de mdk-core no crates.io, e a PR #269 expõe o módulo test_util por trás de uma funcionalidade Cargo test-utils para que suites de testes de clientes externos possam partilhar o harness de testes do Marmot.

LaWallet NWC v0.10.0 lança o monorepo completo e a carteira para utilizador

O LaWallet NWC, a implementação NIP-47 Nostr Wallet Connect da equipa LaWallet, lançou v0.10.0 a 30 de abril. Este é o maior lançamento desde que o projeto recebeu financiamento OpenSats. Inclui o monorepo completo, o painel de administração completo, uma carteira para utilizador, um registo de atividade de ponta a ponta, branding dinâmico e o novo esquema LightningAddress 1→N e NWCConnection. A carteira voltada para o utilizador lançada na PR #191 cobre integração, início, envio/receção, digitalização, moedas, um feed de atividade e uma cache offline.

Amethyst estabiliza o Nests com keep-alive, resiliência JWT e subscrições de ciclo de vida

O Amethyst, o cliente Android rico em funcionalidades, continuou o trabalho nas salas de áudio NIP-53 Nests com um sprint de estabilização focado nos modos de falha que quebravam chamadas em produção. A correção de falhas de áudio na PR #2733 sobrepõe a nova aquisição de credenciais com o stream ativo durante a renovação JWT. Um novo mecanismo keep-alive na PR #2730 reconecta relays desligados sem necessitar de ação manual do utilizador, e a PR #2728 substitui o KeyDataSourceSubscription legado pelo LifecycleAwareKeyDataSourceSubscription. A PR #2724 adiciona um indicador de anel exterior animado que destaca o participante que está a falar em sessões com múltiplos oradores.

ngit v2.4.2 e v2.4.3 corrigem deteção de servidores GRASP e eventos de estado multi-remote

O ngit, a ferramenta de linha de comando e plugin git para colaboração NIP-34, lançou v2.4.2 a 28 de abril e v2.4.3 a 1 de maio. O v2.4.2 corrige uma discrepância de normalização de URL onde repo_grasps continha nomes de host normalizados mas a comparação era feita com URLs de clone completos. O v2.4.3 corrige uma ambiguidade de evento de estado que surgiu quando um repositório tem múltiplos remotes nostr:// com o mesmo identificador.

GRAIN v0.5.4 traz reforço de produção e uma correção silenciosa de perda de dados

O GRAIN, o relay Nostr e biblioteca de cliente baseados em Go, lançou v0.5.4 a 30 de abril. O lançamento consolida seis correções acumuladas desde v0.5.3, incluindo um bug silencioso de perda de dados no arranque rápido Docker que anteriormente descartava eventos quando o contentor reiniciava, e um bug de correção da camada de armazenamento nas leituras de eventos endereçáveis.

Mostro Core v0.10.1 adiciona artefactos de lançamento assinados com PGP

O Mostro Core, a biblioteca Rust que fornece funcionalidade peer-to-peer para o daemon Mostro, lançou v0.10.1 a 28 de abril. O novo lançamento adiciona artefactos de lançamento assinados com PGP e um fluxo de verificação de lançamento para que os empacotadores downstream possam confirmar a proveniência dos artefactos.

Lançamentos

Clave v0.2.0 lança multi-conta no iOS com assinatura NIP-46 (Nostr Connect)

O Clave, a app iOS de assinatura remota NIP-46, lançou v0.2.0 a 5 de maio. A maior atualização introduz suporte a múltiplas contas: o Clave pode agora ter até quatro contas num único dispositivo, com um seletor de um toque e isolamento por conta. A PR #23 adiciona a canalização iOS para multi-conta, e a PR #22 adiciona um campo signer_pubkey à carga APNs para que o dispositivo saiba a que conta pertence um pedido de assinatura remota.

Wisp lança trabalho de estabilidade v1.0.3 → v1.0.5

O Wisp, o cliente Android, lançou v1.0.3, v1.0.4 e v1.0.5 a 4 de maio com trabalho de estabilidade. A PR #506 adiciona Thumbhash para pré-visualizações de imagens desfocadas enquanto o media completo carrega, e a PR #514 reduz o engasgamento ao mudar de separadores inferiores.

Amber 6.1.0-pre1 lança correções de layout e estabilidade

O Amber, a app Android de assinatura para NIP-55 e NIP-46, lançou v6.1.0-pre1 com uma passagem de layout no fluxo de conexão de nova app e várias correções de falhas. A PR #416 corrige o layout do ActivityStatsBar e problemas de overflow de texto.

Routstr Core v0.4.3 melhora pagamento, reembolso e relatórios de utilização

O Routstr Core lançou v0.4.3 como pré-lançamento a 1 de maio com melhorias no tratamento de pagamentos e reembolsos, rastreamento de custos e relatórios de utilização.

Nostria v3.1.37 a v3.1.41 adiciona marcadores Web e um tema automático

O Nostria, o cliente Nostr multiplataforma, lançou v3.1.37 a v3.1.41 adicionando suporte a marcadores Web NIP-B0, um tema automático que segue as definições do dispositivo e visualização de PDF na app.

NoorNote v0.8.9 corrige ecrã vazio no primeiro lançamento no desktop

O NoorNote lançou v0.8.9 a 28 de abril corrigindo um bug de ecrã vazio no primeiro lançamento da app desktop.

Kubo v0.3.4 a v0.4.1 lança plataforma de vídeo Nostr segura para crianças com controlos parentais e curadoria de feed Web of Trust

O Kubo, uma plataforma de vídeo segura para crianças no Nostr, lançou v0.3.4 a v0.4.1 nos dias 4 e 5 de maio. Cada criança recebe um par de chaves Nostr separado e um feed centrado em vídeo onde os pais controlam limites de tempo (15 a 180 minutos diários), janelas de tempo permitidas e visibilidade de ações de publicação.

Mudanças não lançadas

Sprout lança Desktop v0.0.4 e v0.0.5 juntamente com autenticação de agente NIP-OA e o sidecar relay de emparelhamento

O Sprout, o cliente Nostr da Block com relay integrado, lançou Desktop v0.0.4 a 5 de maio e v0.0.5 a 6 de maio. A PR #471 conecta a autenticação de agente NIP-OA ao fluxo de adesão NIP-43 do relay para que um agente autónomo possa provar que uma chave pública humana específica autorizou as suas ações. Um novo relay sidecar efémero para emparelhamento de dispositivos NIP-AB chega na PR #467 como sprout-pair-relay.

nostream adiciona suporte a relay Marmot e reações NIP-25

O nostream, a implementação de relay Node.js, fundiu suporte a relay do Marmot Protocol cobrindo MIPs 00 a 03 na PR #602, suporte a reações NIP-25 na PR #589 e correspondência de prefixo geohash para filtros #g na PR #586.

strfry adiciona observabilidade por conexão e reduz o teto nofiles

O strfry, o relay Nostr em C++, fundiu 14 PRs direcionados à observabilidade. A PR #218 adiciona observabilidade de saída pendente por conexão e um limite de contrapressão configurável. A PR #224 remove alocações de heap std::function do fanout do monitor por evento.

Damus substitui GIFs Tenor por um proxy Purple e lança UX de compactação

O Damus fundiu a PR #3737 substituindo a integração de GIF Tenor por um proxy Damus Purple.

Primal Android melhora Explorar, alertas e o emblema verificado NIP-05

O Primal Android fundiu a PR #1043 corrigindo um emblema verificado NIP-05 que piscava para utilizadores com identificadores _@domínio.

Alby Hub adiciona pagamentos NWC a partir de conexões de apps

O Alby Hub fundiu a PR #2267 permitindo pagamentos a partir de conexões de apps.

routstrd-auth: um Routstrd dockerizado para equipas com autenticação NIP-98 e RBAC npub

O routstrd-auth, criado a 27 de abril, é uma variante dockerizada do Routstrd para implementações de equipas multi-utilizador com controlo de acesso baseado em funções npub e autenticação HTTP NIP-98.

Routstrd integra Hermes para clientes daemon e modo remoto

O Routstrd fundiu a PR #22 adicionando integração com o Hermes Agent para que o ficheiro de configuração do agente seja preenchido com fornecedores de modelos e chaves API que o Routstrd descobre via Nostr.

whitenoise-rs lança isolamento de base de dados por conta e atualizações de propostas

O whitenoise-rs fundiu a PR #796 movendo tabelas de projeção de mensagens para bases de dados por conta, e a PR #791 adiciona atualizações de propostas para que grupos possam estender funcionalidades com novos tipos de propostas.

Angor 0.2.21 lança fluxos de app compactos juntamente com reforço do fornecedor de chaves e mudança de rede

O Angor lançou 0.2.21 a 6 de maio com melhorias de desempenho de design móvel, fluxos de app compactos e um fornecedor de chaves seguro.

Novos projetos rastreados e descobertos

BitMacro Signer: um bunker NIP-46 auto-hospedável com encriptação de chave do lado do cliente

O BitMacro Signer é uma ferramenta de assinatura Nostr auto-hospedável usando o modelo bunker NIP-46. As chaves são encriptadas no cliente antes do armazenamento para que o servidor nunca tenha o texto simples.

A descoberta de repositórios NIP-34 revelou 26 novos anúncios de repositórios esta semana, dos quais quatro se destacam:

gnostr: uma implementação git construída diretamente sobre Nostr

O gnostr é uma implementação git construída diretamente sobre Nostr, com os seus próprios comandos de árvore de trabalho como um cliente de controlo de versão nativo do Nostr construído de raiz.

nostr-archive: uma especificação de arquivo com endereçamento por conteúdo no Nostr e Blossom

O nostr-archive é uma especificação de rascunho e implementação de referência para arquivos com endereçamento por conteúdo no Nostr e Blossom.

flower-cache: um servidor de cache Blossom local

O flower-cache é um servidor de cache Blossom local, útil para clientes que querem um espelho local quente do conjunto de blobs de um servidor Blossom remoto.

micro-vpn-ansible: playbooks Ansible para implementação de VPN via NIP-34

O micro-vpn-ansible é uma pequena coleção de playbooks Ansible para implementar uma micro VPN, hospedada como repositório NIP-34.

Trabalho de protocolo

Atualizações NIP

Um mercado de hashrate sem intermediário no Nostr (proposta de rascunho): Rascunho anónimo de NIP argumentando que os atuais participantes do mercado de hashrate são corretores de custódia que fazem KYC aos utilizadores. Propõe um mercado de hashrate P2P em eventos Nostr.
Curated Feeds: uma alternativa mais simples aos feeds DVM (proposta de rascunho): Argumenta que os DVMs NIP-90 são demasiado pesados para curadoria simples de feeds; propõe eventos endereçáveis leves com listas ordenadas de IDs de eventos.
Profile Colors: identidade visual determinística (proposta de rascunho): Novo rascunho NIP para derivar cores legíveis determinísticas de uma chave pública Nostr para identidade visual consistente entre clientes.
NIPs Namecoin-Track: ancoragem de identidade, relays, TLS e reputação (cluster de rascunhos): Um conjunto de NIPs de rascunho movendo peças da pilha Nostr para registos ancorados no Namecoin.

NIP em profundidade: NIP-34 (git stuff)

O NIP-34 define tipos de eventos para hospedar repositórios git, patches, pull requests, issues e estado de fusão em relays Nostr. Um repositório é anunciado como um evento endereçável de tipo 30617. Os patches usam o tipo 1617 transportando a saída git format-patch. As pull requests usam o tipo 1618. As issues usam o tipo 1621 com conteúdo markdown. Os eventos de estado movem uma thread entre Open (1630), Applied/Merged ou Resolved (1631), Closed (1632) e Draft (1633). A história NIP-34 desta semana é a mesma que o lançamento GitWorkshop v2 da semana passada: o botão de fusão de PR no browser funciona porque os servidores GRASP, o ngit e o esquema de URL clone nostr:// fecham juntos o ciclo numa forge totalmente descentralizada.

NIP em profundidade: NIP-53 (Live Activities)

O NIP-53 define a superfície de eventos padrão para atividades ao vivo no Nostr: transmissões ao vivo, espaços de reunião persistentes, eventos de conferência agendados, presença de ouvintes e chat ao vivo. Uma transmissão ao vivo é anunciada como um evento endereçável de tipo 30311. O NIP-53 separa a sala persistente do evento agendado realizado dentro dela: um Meeting Space de tipo 30312 define uma sala, e um Conference Event de tipo 30313 representa uma reunião agendada ou em curso nessa sala. A superfície de atividades ao vivo do Nostr é intencionalmente leve: o NIP-53 anuncia a atividade, enquanto outros NIPs tratam de preocupações adjacentes como zaps (NIP-57), objetivos de zap (NIP-75) e gravações de vídeo (NIP-71).

Isso é tudo para esta semana. Se estiver a construir algo ou tiver notícias para partilhar, envie-nos uma DM no Nostr ou encontre-nos em nostrcompass.org.

Nostr Compass #20

Wed, 29 Apr 2026 00:00:00 +0000

Bem-vindo de volta ao Nostr Compass, seu guia semanal para o Nostr.

Esta semana: GitWorkshop transforma git-over-Nostr em uma superfície de revisão de código mais completa com um botão de merge de PR no navegador, Stars e seguimento de repositórios, um explorador de git eficiente em largura de banda, comentários de revisão inline kind 1111 e estado de notificação criptografado multi-dispositivo. Routstrd lança um daemon local que descobre provedores de modelos através de anúncios Nostr kind 38421 e os paga com Cashu. Releases com tag incluem ngit v2.4.2, Wisp v1.0.0, grain v0.5.2 e v0.5.3, Mostro Core v0.10.0 e Mostro Mobile v1.2.5, marmot-ts v0.5.0, CruxCoach v0.1.3, Meiso v1.3.0, NoorNote, Nostria, Nostr Calendar, nos2x-fox, applesauce, nostr-double-ratchet e mais. Mudanças não lançadas cobrem Amethyst Nests, nostream NIP-65 e NWC, bootstrap udp:nat baseado em Nostr no FIPS, observabilidade do strfry, atestados de proprietário do Sprout e pacotes de receitas do Zap Cooking. Projetos recém-rastreados incluem Nostrord, Clave, Treasures, smesh, Surveil, Fundstr, Nod City, deploy-nsite-to-pages e null–nostr. A retrospectiva de fim de mês cobre os Abris do Nostr de 2021 a 2026.

Matérias principais

GitWorkshop lança merge de PR no navegador, seguimento de repositórios e um explorador de git eficiente em largura de banda

GitWorkshop, a camada de colaboração baseada na web de Dan Conway para NIP-34 git-over-Nostr, lançou uma release importante esta semana que aproxima muito o fluxo de trabalho do que os desenvolvedores esperam do GitHub ou GitLab, mantendo comentários, listas de repositórios e notificações dentro de eventos Nostr assinados.

A adição em destaque é um botão de merge de PR no navegador há muito aguardado para repositórios que usam relays GRASP. A release também adiciona Stars e seguimento de repositórios construídos sobre reações e listas NIP-51, com conjuntos de repositórios fixados publicados como eventos kind 10617 que apontam para anúncios de repositório kind 30617 através de tags a ordenadas. Páginas de perfil agora podem apresentar uma lista portátil de repositórios.

Um explorador de git eficiente em largura de banda substitui o shallow clone no navegador anterior. O novo explorador se apoia no protocolo cliente/servidor git subjacente sobre o qual o GRASP é construído, para que possa lidar com repositórios grandes sem forçar o navegador a buscar um pack completo. A busca agora cobre nomes de usuário e metadados de repositório, alimentada pelo NIP-50 e uma implementação de relay ngit-indexer que descobre e sincroniza anúncios de repositório pela rede. Um fluxo de criação de repositório no navegador completa o caminho de descoberta e onboarding.

As ferramentas de revisão são reconstruídas em torno de uma aba Files Changed, um visualizador de diff por patch e um conjunto de novas primitivas experimentais. Comentários de revisão de código inline usam kind 1111, construído sobre o NIP-22: cada comentário aponta para um caminho de arquivo (tag f), um SHA de commit (tag c) e um intervalo de linhas selecionado (tag line) para que um cliente possa renderizar o comentário na posição correta em um diff. Um segundo nível de primitivas experimentais é permissionado por autor e mantenedores de repositório e usa labels NIP-32: renomear o assunto de uma Issue ou PR após a submissão, adicionar hashtags após a submissão, fixar uma CoverNote versionada no topo de um PR ou Issue para um resumo editável e marcar subthreads de discussão de código inline como resolvidos. Eventos de veredito e blocos suggestion permanecem como rascunho e ainda não foram lançados.

O estado de notificação entre dispositivos também é sincronizado através do Nostr, mas com uma reviravolta de preservação de privacidade. O GitWorkshop gera um par de chaves dedicado a notificações, criptografa esse nsec e o armazena dentro de um evento kind 30078. O nsec de notificações então assina os eventos reais de estado de notificação. A indireção evita que o signer principal do usuário seja bombardeado com requisições frequentes de criptografia e descriptografia para cada ação de leitura ou arquivamento, e impede que observadores externos vejam facilmente quando um usuário toca em seu estado de notificação. Um usuário pode sincronizar o estado de leitura e arquivamento entre dispositivos; os relays só veem blobs criptografados.

Routstrd lança um roteador local para inferência sobre Nostr

Routstrd é um novo daemon TypeScript que dá às ferramentas locais um endpoint compatível com OpenAI e roteia cada requisição para um provedor Routstr concorrente. O daemon descobre provedores através de anúncios Nostr kind 38421 definidos na especificação RIP-02 do Routstr. Ele então pontua provedores por preço, confiança e desempenho recente sob RIP-06 e envia cada requisição para a melhor opção atual.

O pagamento é feito através de uma carteira Cashu local gerenciada pelo cocod e financiada com Lightning. Isso dá ao cliente um caminho de liquidação denominado em sats, mantendo a descoberta de provedores pública e sem permissão através de relays Nostr. Se um provedor falhar durante uma sessão, o Routstrd pode recorrer ao próximo nó classificado. O caminho de instalação é bun install -g routstrd, seguido por routstrd onboard para configuração de carteira e relay.

A organização Routstr mais ampla mantém o daemon, o software de nó Python (routstr-core), uma UI de chat e especificações de protocolo. Para os usuários, a porta local se torna a interface estável: ferramentas existentes compatíveis com OpenAI apontam para o Routstrd, enquanto o daemon lida com descoberta de provedores, roteamento e pagamento.

Releases com tag

ngit v2.4.2 corrige detecção de relay GRASP para submissões de PR

ngit lançou v2.4.2 com uma correção para detecção de servidor GRASP do repositório, mantendo a submissão de PR no caminho feliz quando uma proposta usa o kind PR. Note que o ngit atualmente usa por padrão o kind Patch para a maioria das mudanças, a menos que sejam grandes; o mantenedor está trabalhando para mudar o padrão. v2.4.1, lançada mais cedo na semana, corrigiu erros fatal durante clone e fetch quando os dados git de um PR aberto não estavam disponíveis nos servidores git especificados do repositório.

Wisp v1.0.0 sai do beta

Wisp, um cliente Android em Kotlin e Jetpack Compose focado em roteamento de relay, privacidade e uma pequena UI nativa, lançou v1.0.0 e o seguiu com v1.0.2. O marco 1.0.0 reúne o toggle de denominação em fiat Normie Mode, o feed For You, configuração de grupo baseada em relay NIP-29 e transmissão de lista de relays NIP-65 cobertos no Newsletter #19. v1.0.2 adiciona suporte a tamanho de página de 16 KB do Android 15, uma aba de escaneamento de QR na drawer sheet, um botão de download para controles de vídeo inline e correções de desempenho da lista de notificações.

grain v0.5.2 corrige travamento de WebSocket, v0.5.3 continua a polir

grain, o relay Go do 0ceanSlim, lançou v0.5.2 como um hotfix crítico para um travamento de WebSocket introduzido em v0.5.0, e o seguiu com v0.5.3. O travamento fazia conexões pendurarem sob alguns caminhos de filtro e WebSocket, então operadores em v0.5.1 ou v0.5.0 devem atualizar. O grain rastreia todas as principais categorias de eventos Nostr, expõe informações de relay NIP-11, suporta controle de acesso whitelist/blacklist, limites de taxa por kind, um painel web e uma biblioteca cliente Go adicionada na linha v0.5.x.

Mostro Core v0.10.0 e Mostro Mobile v1.2.5 adotam gift wrap de chave dupla NIP-59

Mostro Core v0.10.0 adiciona o novo módulo gift-wrap NIP-59 com chaves de identidade e trade separadas. Código de transporte anterior usava uma única chave de identidade tanto para identidade de trade quanto para gift wrapping. v0.10.0 separa a identidade de trade estável da chave de wrapping efêmera, então cada trade pode usar uma nova chave de transporte enquanto preserva a identidade necessária para o protocolo de trade. A integração com o daemon chega através do Mostro PR #718, e o mostro-cli PR #165 traz a mesma migração para o cliente de linha de comando.

Mostro Mobile v1.2.5 sai junto com o trabalho de protocolo. PR #581 permite que takers filtrem ofertas pela idade da conta do maker, dando aos usuários uma maneira de evitar contas maker recém-criadas no order book. PR #580 corrige labels de papel em detalhes de ordens canceladas, e PR #576 limpa botões de cancelamento cooperativo.

marmot-ts v0.5.0 lança KeyPackages endereçáveis

marmot-ts lançou @internet-privacy/marmot-ts@0.5.0, a primeira release com quebra planejada para o cliente TypeScript do Marmot. PR #68 adiciona suporte a KeyPackage endereçáveis: KeyPackageManager agora pode lidar tanto com eventos KeyPackage legacy kind 443 quanto com os novos kind 30443. A release remove KeyPackageStore e as classes de armazenamento de estado de grupo, substituindo-as por armazenamentos genéricos de chave-valor passados para KeyPackageManager e MarmotGroup. Também move o gerenciamento de convites e grupos para MarmotClient.invites e MarmotClient.groups, então embedders diretos precisam de mudanças de construtor e armazenamento antes de atualizar.

CruxCoach v0.1.3 lança backup criptografado de dados de escalada com Nostr e Blossom

CruxCoach é um novo app Android open-source para escaladores de Kilter Board. A Kilter Board é uma parede de treinamento interativa cujos holds acendem via Bluetooth para exibir rotas. O app foi lançado em 14 de abril e chegou à v0.1.3 em 26 de abril.

v0.1.3 adiciona backup em nuvem criptografado opcional. A conta CruxCoach de um usuário é um par de chaves Nostr, e a chave privada dobra como entrada para a chave de criptografia de backup local. O app criptografa dados de escalada no dispositivo e espelha o ciphertext para servidores de armazenamento Blossom (blossom.primal.net e nostr.download). Ações de exclusão remota chamam o caminho de limpeza Blossom. Além do backup, o CruxCoach usa assinatura remota NIP-46 para suporte a Amber, DMs privadas NIP-17 para contato in-app com o desenvolvedor, listas de relays NIP-65 para descoberta de relays e a biblioteca Quartz de Vitor Pamplona para infraestrutura Nostr. Os usuários podem instalá-lo através do Zapstore ou APKs diretos do Codeberg.

Meiso v1.3.0 adiciona subtarefas, anexos Blossom e tag NIP-89

Meiso é um gerenciador de tarefas Flutter minimalista para Android que armazena tarefas como dados de aplicação kind 30078 criptografados NIP-44 em relays Nostr. v1.3.0, lançada em 6 de abril, adiciona subtarefas com relacionamentos pai/filho, links de tarefas para blocks/blocked-by/related-to/duplicate-of, anexos de imagem através do Blossom e endpoints de upload de arquivo HTTP NIP-96, uma tag client de aplicação recomendada NIP-89 em eventos publicados e uma ferramenta de sincronização de linha de comando em Go. v1.3.0 também corrige comportamento de relay em cold-start e reutilização de cliente Amber.

NoorNote, Nostria, Nostr Calendar, nos2x-fox e releases de bibliotecas

NoorNote publicou v0.8.7, v0.8.8 e v0.8.9. Essas releases corrigem o tratamento de cliques em imagens e vídeos em reposts citados, adicionam suporte a lightbox para imagens de artigos long-form e corrigem a tela de inicialização em branco no desktop. Nostria lançou v3.1.29, v3.1.30 e v3.1.31, adicionando compressão de imagens no editor de artigos, um toggle USD para carteira, controles de card promocional, suporte a PDF e polimento de layout mobile.

Nostr Calendar v1.4.1 desacopla a publicação de eventos de calendário do gerenciamento de listas de calendários e corrige o rastreamento de convites. nos2x-fox v1.19.0 adiciona prazos de autorização personalizados para grants de assinatura no navegador NIP-07 no Firefox. nostr-double-ratchet v0.0.97 lança novos binários. nostr-wot-sdk 0.9.0 monta NostrSessionProvider por padrão, e nostr-tools PR #535 adiciona suporte a parsing multi-relay para strings de wallet-connect NIP-47.

No final da semana, Amber v6.1.0-pre1 lançou um pre-release com um melhor layout de conexão a novos apps, correções no diálogo do signer, tratamento aprimorado de permissões de notificação e seleção de conta refatorada. nostr-vpn v0.3.14 lançou uma nova build com artefatos para macOS Apple Silicon, Linux e Windows. Bitcredit Core v0.5.7-hotfix-1 e v0.5.8 lançaram correções consecutivas para um problema de validação de bloco órfão. Surveil v0.1.6 trouxe polimento de UI mobile e uma página About reformulada; o projeto em si é apresentado abaixo.

applesauce 6.0.0 remove factories de eventos legacy e adiciona parsing de URI Blossom

applesauce, o toolkit Nostr TypeScript do hzrd149, lançou um trem de releases 6.0.0 em todo o monorepo. applesauce-core@6.0.0 remove a classe legacy EventFactory e os antigos helpers buildEvent, modifyEvent e createEvent, empurrando os chamadores para as novas classes factory em applesauce-core/factories e applesauce-common. Também adiciona tratamento de endereços IP e localhost ao parsing de links, expressões regulares de URI Blossom BUD-10 e novos helpers observáveis como timeoutWithIgnore, combineLatestBy, combineLatestByIndex e combineLatestByKey.

Releases em nível de pacote completam as peças específicas do Nostr. applesauce-content@6.0.0 adiciona nós de URI Blossom BUD-10 para texto e Markdown, dando aos renderizadores uma forma nativa de fazer parsing de referências Blossom em conteúdo. applesauce-actions@6.0.0 adiciona classes factory base para listas NIP-51 cobrindo relays, usuários e itens, tornando a construção de listas menos ad hoc. applesauce-wallet-connect@6.0.0 expõe WalletConnect.connectURI, para que os apps possam acessar diretamente uma URI wallet-connect NIP-47 existente.

Mudanças não lançadas

Amethyst avança com salas de áudio Nests com testes de interoperabilidade MoQ

Amethyst fez merge de vários PRs focados em Nests esta semana, construindo sobre a stack de sala de áudio Media over QUIC da semana passada. PR #2622 adiciona um harness de interoperabilidade cross-client que exercita o cliente MoQ do Amethyst contra a implementação web de referência. O objetivo é capturar divergências no nível do fio entre Android/navegador antes que os usuários as encontrem. PR #2625 melhora o foco do falante em picture-in-picture e o status da conexão, enquanto PR #2620 esclarece avatares, estado de mudo e estado de fala na grade de participantes. No final da semana, PR #2634 corrige padding de IME e window insets na visão full-screen de Nest e PR #2635 adiciona filtragem de frescor baseada em presença ao feed Nests. Separadamente, PR #2627 remove a implementação C personalizada de secp256k1 do Amethyst e migra para libschnorr256k1.

nostream adiciona suporte a lista de relays NIP-65 e pagamentos NWC

nostream fez merge de três PRs notáveis após o sprint de 53 PRs de relay da semana passada. Suporte a metadados de lista de relays NIP-65 chega no PR #585, para que o relay possa indexar e servir eventos de lista de relays kind 10002. Um processador de pagamentos Nostr Wallet Connect segue no PR #539, adicionando um caminho pay-to-relay. A limpeza de conexão melhora no PR #438, que fecha um bug de conexão morta onde sockets com subscriptions ativas não estavam sendo colhidos, causando drift nos contadores de subscription em instâncias de longa duração.

FIPS adiciona bootstrap udp:nat baseado em Nostr

FIPS, o Free Internetworking Peering System previamente coberto em Newsletter #6 e Newsletter #10, fez merge do PR #53 com bootstrap udp:nat baseado em Nostr. A mudança permite que nós publiquem anúncios Nostr, troquem sinalização criptografada de offer/answer, descubram endereços públicos através de STUN, executem UDP hole punching e passem o socket perfurado para a stack de transporte FIPS normal. A implementação vincula identidades de payload de sinal ao remetente Nostr real, consulta relays DM e advert configurados para lookup de inbox e faz rollback de handoffs de travessia adotados que falharam, para que transportes UDP órfãos não permaneçam ativos. Este é o trabalho de anúncio Nostr e travessia NAT a rastrear no repositório canônico, jmcorgan/fips.

strfry adiciona observabilidade por conexão

strfry fez merge do PR #214, adicionando observabilidade por conexão e métricas em nível de conexão exportáveis através do Prometheus. PR #204 normaliza labels do Prometheus, e PR #215 adiciona uma seção Community Integrations à documentação cobrindo projetos de identidade Namecoin construídos sobre o strfry.

Sprout adiciona Owner Attestation e suporte a múltiplos workspaces

Sprout, o cliente Nostr do Block, fez merge do PR #406 implementando NIP-OA (Owner Attestation). O recurso dá a um agente autônomo uma prova criptográfica de que uma pubkey humana específica autorizou suas ações. PR #409 adiciona suporte a múltiplos workspaces ao app desktop, PR #411 adiciona autocompletar #channel ao compose mobile, e PR #410 fecha uma janela de race que podia derrubar mensagens ativas de canal. PR #413 introduz NIP-RS para sincronização de estado de leitura entre dispositivos, e os follow-ups PR #420 e PR #422 conectam esse estado de leitura aos badges de não lidos mobile.

Zap Cooking fez merge de uma semana produtiva de trabalho de publicação de receitas. Solicitações de exclusão NIP-09 para os Pacotes de Receitas do próprio usuário chegam no PR #367. A confiabilidade de publicação melhora através do PR #366, que força cada nova receita para o relay garden e adiciona uma fila de retry para o conjunto compartilhado de receitas. Publicação de pacote autoral com um clique chega no PR #365, e PR #331 adiciona suporte a login bunker NIP-46.

Whitenoise-rs criptografa seu banco de dados local

whitenoise-rs fez merge do PR #758, adicionando criptografia SQLCipher para o banco de dados Whitenoise em disco. Isso fecha uma lacuna de segurança em repouso de longa data para a stack daemon do Marmot. PR #775 expõe capacidades requeridas de grupo, PR #772 migra operações de mídia de grupo para MediaOps de propriedade da sessão, e PR #773 extrai um holder SharedServices como parte do refactor de session-ops. No lado mobile, whitenoise PR #577 ativa o auto-restart de boot para o serviço em primeiro plano do Android, corrigindo o caso onde o daemon não voltava após uma reinicialização do dispositivo.

Recém-rastreado e descoberto

Nostrord: um cliente NIP-29 construído com Kotlin Multiplatform e WASM

Nostrord é um novo cliente de chat em grupo NIP-29 que visa o caso de uso de substituição do Discord. Grupos vivem em relays Nostr com membership, papéis, moderação e controle de acesso aplicados pelo relay, então o estado do grupo é hospedado pelo relay NIP-29 selecionado. O desenvolvedor do cliente não controla um banco de dados de aplicação separado para esses grupos. O app web roda em web.nostrord.com e é construído com Kotlin Multiplatform compilando para WebAssembly, com builds nativos para Android, iOS e desktop em desenvolvimento. Nostrord é um recipiente de grant OpenSats e interopera com os mesmos relays NIP-29 usados por Flotilla, Chachi e 0xChat.

Clave traz assinatura remota NIP-46 para iOS via APNs

Clave é um signer remoto iOS em beta que assina eventos Nostr quando o app não está aberto. A chave privada permanece no Keychain do iPhone. Quando um cliente envia uma requisição de assinatura remota NIP-46, um proxy do lado do servidor entrega uma Apple Push Notification, acordando uma Notification Service Extension por até 30 segundos. Essa extensão descriptografa a requisição com criptografia NIP-44, assina com a chave do Keychain e publica a resposta. O registro de token de dispositivo usa HTTP Auth NIP-98 para evitar sequestro de token. Clave suporta pareamento bunker:// e nostrconnect://, níveis de confiança por cliente, overrides por kind, e foi testado com Nostur e noStrudel.

Treasures: geocaching descentralizado no Nostr

Treasures é uma plataforma de geocaching onde caches e achados são eventos Nostr assinados. Criadores de cache publicam eventos endereçáveis kind 37516 com coordenadas GPS. Descobridores registram a descoberta escaneando um QR code anexado ao cache físico; o código codifica a pubkey do criador, a tag d do cache e uma chave privada de verificação usada como prova da visita física. Zaps NIP-57 podem fluir de descobridores para criadores de cache, e o app ao vivo está em treasures.to.

smesh v0.5.1: relay, cliente e signer Nostr auto-hospedados em uma stack

smesh é uma stack Nostr auto-hospedada escrita em Moxie, uma linguagem personalizada derivada de Go e TinyGo pelo mleku. A stack entrega um binário nativo de relay com suporte a HTTP, WebSocket, AUTH, busca e Blossom; sm3sh, um cliente web compilado para módulos ES; e uma extensão de signer no navegador com assinatura NIP-07 no navegador mais suporte a criptografia NIP-04 e NIP-44. Trabalho recente inclui mensageria de grupo MLS (RFC 9420) em v0.5.0, reconciliação de conjunto negentropy para sincronização de relay e um motor de grafo Web of Trust. O código vive na forge auto-hospedada do mleku em git.smesh.lol, construída com sua própria ferramenta git-web. O repositório relacionado gitea-nostr-auth é uma ponte OAuth2/OIDC para o Gitea: usuários autenticam com um signer NIP-07 no navegador, a ponte descobre relays através de NIP-65, e o Gitea recebe claims de identidade OIDC padrão.

Surveil: um construtor de decks de Magic: The Gathering no Nostr

Surveil é um cliente Nostr para jogadores de Magic: The Gathering que permite aos usuários buscar cartas, construir decks, escanear cartas físicas no Android com OCR ML Kit no dispositivo e compartilhar decks pela rede. Decks são publicados como eventos endereçáveis kind 37381, e a especificação de evento de deck está documentada no NIP.md do projeto. A camada social é construída a partir de primitivas Nostr padrão: comentários em thread NIP-22 (kind 1111) escopados a cada deck, reações NIP-25 (kind 7), dados de perfil NIP-78 (kind 30078) para lares de jogadores, feeds de follows kind 3 e forks que carregam uma tag a de volta para o deck original. v0.1.6 foi lançada esta semana com polimento de UI mobile, melhorias no contador de vida, uma página About reformulada e uma pill de relay no banner hero do deck. O app web roda em qualquer lugar onde HTML estático seja servido, o build Android é entregue através do Zapstore, e eventos kind 37381 também são indexados nativamente pelo Ditto como decks de Magic. O repositório está no GitLab em chad.curtis/surveil.

Adições menores: Fundstr, Nod City, deploy-nsite-to-pages e null–nostr

Fundstr é uma plataforma de financiamento de criadores no Nostr usando ecash Cashu para promessas únicas e recorrentes, com definições de nível de criador e DMs Nostr. Nod City é um site de avaliações de serviços Bitcoin onde as avaliações são eventos Nostr assinados e os revisores podem receber zaps; nenhum repositório de código público foi encontrado. deploy-nsite-to-pages é uma GitHub Action que espelha um nsite para o GitHub Pages usando nsyte download, suportando nsites kind 15128 raiz e kind 35128 nomeado. null–nostr, também descoberto nos dados NIP-34 desta semana, é o cliente coberto na recente onda OpenSats como Nurunuru; suporta mensageria de grupo MLS, Amber, busca NIP-50, posts protegidos NIP-70, badges ProofMode e distribuição via Zapstore.

FIPS não é um projeto novo para o Compass. Foi coberto em Newsletter #6 e Newsletter #10. O banco de dados agora aponta para o repositório canônico correto, jmcorgan/fips, e a descoberta NIP-34 desta semana também trouxe à tona mirrors git-over-Nostr relacionados como fips e awesome-fips.

Trabalho de protocolo

Atualizações de NIP

Propostas recentes e discussões no repositório NIPs:

Merged esta semana:

NIP-34 repositórios git: remover extensão de tag refs não usada (PR #2325): Remove uma extensão de tag refs do NIP-34 que foi definida mas não utilizada. A limpeza reduz a ambiguidade de implementação para ferramentas git-over-Nostr.
NIP-34 repositórios git: remover afirmação incorreta sobre NIP-09 (PR #2326): Remove uma afirmação incorreta de que eventos de exclusão NIP-09 podem resetar o estado do repositório. A exclusão NIP-09 é uma solicitação de exclusão de evento do lado do cliente, não uma máquina de estado de repositório. A correção evita que implementadores de NIP-34 tratem dicas de exclusão como resets autoritativos de repositório.

Trabalho aberto e conduzido por implementação:

Comentários de revisão de código inline kind 1111 do GitWorkshop: O kind de comentário de revisão de código inline está documentado no NIP.md do GitWorkshop e está agora em uso ativo, mas ainda não foi proposto como um NIP formal. Eventos de veredito (kind 7321) e blocos suggestion permanecem como rascunho e ainda não foram lançados. Feedback de implementação do GitWorkshop e ngit determinará se as formas se tornam um NIP independente de git-review ou permanecem como uma convenção de aplicação em camadas sobre NIP-34.
Nostr mail core e Nostrmon: Dois novos rascunhos de NIP personalizados circularam esta semana. Nostr mail core propõe kind 1301 para conteúdo de email RFC 2822, embrulhado com NIP-59 para entrega privada e conectado a email legacy através de pubkeys de ponte resolvidas por NIP-05. Nostrmon esboça kinds de eventos endereçáveis para regiões, mapas, criaturas, NPCs, saves de jogadores e itens. Ambos permanecem como rascunhos personalizados, não NIPs merged.
NIP-67: EOSE Completeness Hint (PR #2317): A proposta continua a iterar sobre a adição de um marcador positivo de completude ao EOSE, permitindo que relays distingam “eventos armazenados totalmente entregues” de casos EOSE legacy onde o relay não faz nenhuma afirmação de completude.

Seis abris do Nostr

Abril dá uma seção transversal limpa do caminho de desenvolvimento do Nostr: o documento de protocolo em 2021, trabalho inicial de clientes em 2022, a onda de aplicações pós-Damus em 2023, mensageria privada e trabalho git-over-Nostr em 2024, Blossom e limpeza de lista de relays em 2025, e grants de cliente focados em adoção em 2026.

Abril de 2021: o documento do protocolo antes do repositório NIPs

Fiatjaf publicou o artigo original do Nostr, “Notes and Other Stuff Transmitted by Relays”, em 20 de novembro de 2020. Esse primeiro texto já continha a forma central que ainda define o protocolo: usuários assinam eventos com chaves, publicam-nos para relays e leem dos relays que escolhem. O log de commits nostr-protocol/nostr não mostra commits entre 1º e 30 de abril. A atividade fica de ambos os lados: commits de março de 2021 adicionaram links iniciais “nostwitter” e um filtro kind, enquanto maio de 2021 redirecionou o NIP-02 e adicionou autoria de NIP.

Em abril de 2021, não havia mercado público de clientes, nenhuma rede de relays visível e nenhum repositório NIPs. O protocolo ainda vivia como um pequeno documento e alguns experimentos. Nostr ainda não havia se tornado uma rede social ou uma plataforma de desenvolvimento. Era ainda um modelo relay/chave/evento aguardando sua primeira onda sustentada de contribuidores.

Abril de 2022: NIPs ainda viviam no repositório principal

Abril de 2022 foi o último mês antes dos NIPs saírem do repositório principal nostr-protocol/nostr. Como a divisão ainda não havia acontecido, o repositório dedicado nostr-protocol/nips não tinha histórico de pull requests de abril. No repositório principal, três commits de abril foram feitos: “Update readme to add nip12” em 8 de abril por goswami1999, “add kinds list” em 25 de abril por jb55, e “add js formatting to sample code” em 28 de abril por steliosrammos.

O trabalho de clientes também começava a tomar forma. Commits do Damus de abril de 2022 adicionaram comportamento inicial de chatroom, manipulação de perfil e ícones do app, enquanto nostr-tools se tornava o caminho da biblioteca JavaScript para clientes iniciais e experimentos. No lado do protocolo, queries genéricas de tag NIP-12 deram à busca de tags um lugar documentado, a lista de kinds moveu o Nostr em direção a um modelo de registro, e melhores exemplos em JavaScript tornaram a especificação mais fácil de implementar para autores de clientes e bibliotecas. Em 1º de maio, fiatjaf moveu os NIPs para o repositório dedicado. Abril de 2022 foi o último mês da era original de repositório único.

Abril de 2023: expansão de aplicações pós-Damus

Abril de 2023 chegou três meses após o Damus ser lançado na iOS App Store em 31 de janeiro de 2023, e após Jack Dorsey ter postado sua chave pública Nostr. A rede acabara de absorver sua primeira grande onda de crescimento público. Clientes como Damus, Snort, Iris, Coracle e Amethyst estavam ativos, enquanto operadores de relay estavam aprendendo o que um grafo social maior fazia com as suposições de largura de banda, spam, busca e moderação.

Abril de 2023 teve um PR merged nos NIPs: PR #456, merged em 17 de abril, adicionando links de entidade bech32 NIP-19 ao tratamento de URI NIP-21. Os commits ao redor mostram a pressão de aplicação por trás do trabalho de protocolo. Abril de 2023 viu trabalho em NIP-45 COUNT, marcadores de zap específicos de evento, NIP-15 marketplace, semântica de delegação de exclusão NIP-26, metadados de arquivo NIP-94, tratamento de erros wallet-connect NIP-47 e emoji personalizado NIP-30. A lista de contribuidores havia se ampliado para incluir fiatjaf, staab, pablof7z, Semisol, CodyTseng, sethforprivacy, mikedilger, AsaiToshiya, alexgleason, martindsq, frbittencourt e arkin0x.

Damus, Snort, Iris, Coracle e Amethyst não eram mais demos em torno de uma especificação; eram clientes de produção lidando com onboarding, feeds, spam, zaps, mídia e seleção de relay. O trabalho de protocolo de abril de 2023 se lê como o backlog que esses clientes criaram: zaps, marketplaces, metadados de arquivo, contagem, emoji e links de identidade todos empurraram a especificação além de notas e follows simples.

Abril de 2024: mensageria privada, git-over-Nostr e suporte a mantenedores

Abril de 2024 teve dois PRs de NIP merged. PR #1167, merged em 10 de abril, corrigiu terminologia confusa em assinatura remota NIP-46, onde clientes e signers precisam de linguagem exata para ações solicitadas e autorizadas. PR #1108, merged em 17 de abril, expandiu repositórios git NIP-34 com eventos de status, esclarecimentos, mantenedores opcionais, identificadores de repositório e tags de descobribilidade. Esse passo tornou git-over-Nostr mais prático para ngit e depois GitWorkshop.

NIP-17, anteriormente NIP-24, chegou em 24 de abril como mensagens seladas gift-wrapped para DMs privadas e pequenos chats em grupo. Trabalho de cliente e biblioteca ocorreu em paralelo: Amethyst, Primal, Gossip, nostr-tools, NDK e rust-nostr estavam todos ativos no mesmo período.

OpenSats também anunciou suporte de longo prazo para desenvolvedores Nostr em abril de 2024: PabloF7z em 9 de abril, Stuart Bowman em 12 de abril, e hzrd149 em 15 de abril. Esses grants moveram o financiamento de grants de projetos isolados em direção à manutenção sustentada de relays, bibliotecas e infraestrutura de clientes.

Abril de 2025: limpeza densa de NIP e formalização do Blossom

Abril de 2025 foi o mês de protocolo mais denso nesta retrospectiva, com dezesseis PRs de NIP merged. O mês começou com PR #1846, adicionando transações e endereços blockchain ao NIP-73, e PR #1865, adicionando tags NIP-C0 à tabela de tags padronizada. Continuou com PR #1801 e PR #1889, ambos melhorando a orientação de republicação de lista de relays kind 10002, e PR #1879, que encolheu e esclareceu o NIP-65.

PR #1822 adicionou NIP-B7 para interação com Blossom, dando aos clientes Nostr e servidores Blossom uma camada de coordenação canônica após mais de um ano de prática informal. PR #1051 descontinuou o NIP-26, a especificação de assinatura de evento delegada. O NIP-26 havia sido difícil de implementar com segurança e havia se tornado menos atraente à medida que o NIP-46 e outros padrões de signer amadureceram.

O resto do mês combinou limpeza com expansão de aplicações: PR #1882 adicionou campos de política de privacidade e termos de serviço ao NIP-11, PR #1849 expandiu bookmarks web kind 39701 sob o NIP-B0, PR #1891 adicionou esse kind de bookmark ao README, e PR #1895 adicionou tags padronizadas NIP-B0. OpenSats anunciou sua Décima Primeira Onda de Grants Nostr em 16 de abril, financiando Swae, HAMSTR, Vertex, Nostr Double Ratchet e Nostr Game Engine. Primal, Coracle, noStrudel, nostr-tools, NDK e rust-nostr também estavam entregando através deste período, então a limpeza de protocolo ficava próxima do trabalho ativo de cliente e biblioteca.

Abril de 2026: fortalecimento do NIP-34, badges e grants focados em adoção

Abril de 2026, o mês que este issue encerra, teve quatro PRs de NIP merged. O primeiro foi o PR #2276, merged em 1º de abril, que mudou os badges de perfil NIP-58 para kind 10008 e adicionou conjuntos de badges kind 30008, tornando a atribuição de badges e coleções de badges mais componíveis. Uma segunda mudança de usabilidade git-over-Nostr chegou no PR #2312, merged em 10 de abril, adicionando semântica de URL de clone nostr:// ao NIP-34. As limpezas de 25 de abril, PR #2325 e PR #2326, removeram linguagem não usada e incorreta do NIP-34.

Commits relacionados afiam as mesmas superfícies. Em 22 de abril, fiatjaf adicionou uma lista de servidores Blossom ao NIP-51 e ajustou a edição de metadados NIP-29 para corresponder ao comportamento estilo PUT do Flotilla. Em 26 de abril, ele renomeou o NIP-5A para clareza. Abril de 2026 focou em tornar superfícies de protocolo já usadas mais fáceis de implementar e mais difíceis de interpretar mal.

OpenSats anunciou sua Décima Sexta Onda de Grants Nostr em 8 de abril, apoiando Amethyst Desktop, Nostr Mail, Nostrord, Nurunuru (null–nostr) e uma renovação do HAMSTR: clientes desktop, mensageria estilo email, UX de grupo, onboarding em japonês e conectividade off-grid.

Obrigado por ler o Nostr Compass #20. Mande uma DM para nós no Nostr com dicas, correções ou novos projetos para cobrir.

Nostr Compass #19

Wed, 22 Apr 2026 00:00:00 +0000

Bem-vindo de volta ao Nostr Compass, seu guia semanal sobre o Nostr.

Esta semana: Amethyst faz uma grande rodada de trabalho em Marmot, comunidades e salas de áudio com MoQ; TollGate estabiliza acesso à internet pay-per-use sobre Nostr e Cashu na v0.1.0; e nostream fecha uma semana intensa de trabalho em relay em torno de NIP-45, NIP-62, compressão, hardening de consultas e paridade completa com NIP-11. Forgesworn publica uma stack completa de assinatura, identidade e APIs pagas para Nostr. ShockWallet continua avançando em fluxos de carteira Lightning nativos de Nostr. A suíte Formstr, Pollerama, Forms e Calendar, mergeia 26 PRs em hardening de segurança, i18n e suporte a RRULE. StableKraft, Keep, topaz, WoT Relay, Flotilla e NipLock completam a lista de lançamentos. Os deep dives cobrem NIP-72 e NIP-57.

Shipping This Week

Primal Android lança aba Explore, verificação NIP-05 e player de áudio

Primal Android empurrou 11 PRs mergeadas em cima do redesenho de feed da semana passada. O PR #1021 introduz uma nova aba Explore construída em torno de usuários populares, follow packs e feeds curados, e o PR #1015 adiciona um editor de feed que pré-preenche a partir da DSL de Advanced Search do Primal. O PR #994 entrega UI de verificação NIP-05 para perfis, e o PR #997 embute um player de áudio no feed para anexos de arquivos de áudio. O PR #1018 adiciona pareamento nostr-connect NIP-46 a partir do scanner de QR da carteira, reutilizando o mesmo caminho de câmera para signer pairing e wallet linking.

strfry adiciona métricas Prometheus do caminho de escrita e corrige envelope AUTH da NIP-42

strfry lançou um lote de melhorias voltadas a operadores. O PR #194 adiciona um exporter Prometheus dedicado para métricas do caminho de escrita e um novo gauge de conexões, e o PR #197 registra bytes enviados e recebidos por conexão, além de índices de compressão para operadores acompanhando largura de banda. O PR #192 promove o limite hardcoded de tags em filtros a uma opção configurável em runtime. Em corretude de protocolo, o PR #201 altera respostas de falha AUTH da NIP-42 de uma mensagem NOTICE para o envelope OK que a NIP realmente especifica, resolvendo uma incompatibilidade antiga para relays com autenticação obrigatória.

Shopstr reforça segurança de storefront em 13 PRs

Shopstr, o cliente marketplace Nostr, mergeou 13 PRs nesta semana dominadas por correções de segurança. O PR #434 fecha uma falha de JavaScript armazenado em links de storefront que permitia execução de scripts do vendedor no navegador do visitante, o PR #417 escapa a renderização HTML da policy do storefront para bloquear XSS refletido, e o PR #418 fecha uma API de deleção de eventos em cache sem autenticação que permitia remoção de dados entre usuários. O PR #433 exige autenticação para leitura de mensagens em cache, o PR #419 protege endpoints de mutação da storefront e do event cache atrás de auth adequada, e os PR #435 e PR #414 corrigem dois achados de SSRF de code scanning. No lado funcional, o PR #421 torna segura contra replay a fila de publicações em relays que falharam, o PR #425 repara uma busca quebrada de wallet events, e o PR #392 revalida descontos salvos no carrinho antes do checkout.

Nostria v3.1.26 até v3.1.28 adiciona reprodução de música em background no Android

Nostria cortou seis releases nesta semana, da v3.1.22 à v3.1.28. A principal mudança da v3.1.26 é reprodução de música em background no Android: o app se mantém ativo enquanto o áudio toca, com controles de mídia na barra de notificações e na lock screen. As releases seguintes, v3.1.27 e v3.1.28, fazem hardening dessa nova superfície de serviço de mídia. A Newsletter #18 cobriu o ciclo anterior, com geração local de imagens.

Wisp v0.18.0-beta adiciona Normie Mode, feed For You e configuração de grupos NIP-29

Wisp, o cliente Android em Kotlin e Jetpack Compose de barrydeen, lançou a v0.18.0-beta em 16 de abril. O release mira usuários vindos de contextos menos Bitcoin-native: o PR #462 adiciona um Normie Mode que mostra valores denominados em fiat em todo o app, e o PR #464 reformula o onboarding com seletor de tópicos e um coach para o primeiro post. O PR #469 adiciona um feed For You que mistura follows estendidos, eventos em alta e hashtags seguidas.

No trabalho de protocolo, o PR #471 adiciona configuração de grupos NIP-29 para flags, invites, papéis e prompts AUTH, e o PR #478 corrige uma falha de ordenação para que o Wisp espere AUTH NIP-42 antes de emitir eventos de grupo 9021, 9007 e 9009, além de mostrar falhas do lado do admin. O PR #481 faz broadcast de notas aos inbox relays NIP-65 das pubkeys mencionadas para que replies alcancem seus alvos mesmo quando conjuntos de relays de remetente e destinatário não se sobrepõem.

NoorNote v0.8.4 adiciona posts agendados e zaps em live stream

NoorNote lançou a v0.8.4 e a v0.8.5. A principal adição da v0.8.4 é um add-on de Scheduled Posts: o app entrega um evento totalmente assinado a um relay operado pela NoorNote, que o publica no momento agendado, então as chaves privadas nunca saem do dispositivo. O mesmo release adiciona zaps com um toque em cards de live stream, em que os sats aparecem na sobreposição de chat da stream via NIP-53, e mantém o saldo da carteira visível quando a API de cotação fiat fica temporariamente indisponível. A v0.8.5 corrige um bug de deduplicação de timeline que causava posts duplicados em longos scrolls no Android.

topaz v0.0.2 lança um relay Nostr para Android

topaz, um novo relay Nostr que roda em telefones Android, de fiatjaf, publicou a v0.0.2 em 2026-04-17. O projeto é Kotlin-first e posiciona o telefone como um relay pessoal sempre disponível. Nesta fase o escopo é estreito: um relay funcional dentro de um pacote Android instalável.

StableKraft v1.0.0 lança o primeiro release estável da PWA de música e podcasts

StableKraft é uma PWA em Next.js para descobrir, organizar e transmitir música puxada de feeds de podcast, usando Nostr para auth e recursos sociais e Lightning para pagamentos V4V. Ela chegou à v1.0.0 em 2026-04-18. Na mesma semana, o projeto endureceu ingestão de feeds com um cache OPML de 15 minutos e stripping de XML inválido e reduziu a janela de nightly reparse de 720 horas para 24 horas em um ajuste posterior, acelerando a autocorreção de feeds recém-adicionados.

NipLock lança um gerenciador de senhas baseado em NIP-17

NipLock é um gerenciador de senhas que armazena e sincroniza credenciais entre dispositivos usando mensagens diretas gift-wrapped da NIP-17. Cada entrada de senha é uma DM NIP-17 da chave do próprio usuário para ela mesma, então os mesmos eventos se replicam para qualquer dispositivo autenticado com essa chave. A assinatura funciona com nsec bruto, extensões de navegador como nos2x ou Amber via NIP-46, o que mantém a chave mestra fora do dispositivo cliente.

flotilla-budabit refina sua superfície de repositórios NIP-34

O fork da comunidade Budabit do Flotilla, chamado flotilla-budabit, lançou um conjunto de correções em seu fluxo de git-over-nostr da NIP-34. As atualizações desta semana restauram controles de discussão de repositório, mantêm abas fixas visíveis em páginas de detalhe, carregam anúncios de repositório a partir de relays GRASP salvos e sincronizam o estado de patch aplicado pelo mantenedor. Mantendo-se próximo ao upstream do Flotilla, o fork prioriza a view de repositórios para contribuidores da comunidade Budabit.

rx-nostr 3.7.2 até 3.7.4 adicionam verificador padrão e argumentos opcionais no construtor

rx-nostr, a biblioteca Nostr baseada em RxJS, lançou 3.7.2, 3.7.3 e 3.7.4. O PR #192 adiciona um verificador padrão de assinaturas Schnorr, eliminando a necessidade de quem chama ligar um verificador manualmente, e uma release emparelhada crypto@3.1.6 corrige um bug de uso em @noble/curves que estava produzindo falhas espúrias de verificação. O PR #195, na 3.7.4, torna opcionais os argumentos de createRxNostr(), permitindo integrações rápidas com zero configuração.

Keep Android v1.0.0 lança builds reproduzíveis e zero trackers

Keep, um gerenciador de senhas e segredos nativo de Nostr, lançou a v1.0.0 em 21 de abril após uma série de PRs de hardening. O PR #241 adiciona uma receita de build reproduzível com toolchain fixada e verificada, o PR #248 troca Google ML Kit por ZXing para remover dependência de Google Play Services, e o PR #252 publica um scan do Exodus Privacy mostrando zero trackers na build v1.0.0. O PR #256 adiciona um manifesto zapstore.yaml para que o APK possa ser distribuído via zapstore sem publisher intermediário.

Flotilla 1.7.3 e 1.7.4 adicionam encapsulamento kind 9 para salas NIP-29 mais ricas

Flotilla, o cliente de grupos NIP-29 do hodlbod, lançou 1.7.3 e 1.7.4. A principal mudança de protocolo é o encapsulamento em kind 9 de tipos de conteúdo que não são chat, anunciado na nota de release do hodlbod e rastreada contra o NIP PR #2310. Encapsular eventos de calendário, enquetes e outros payloads em kind 9 preserva o contexto da sala quando esses objetos são enviados a um grupo, permitindo que clientes renderizem o objeto embutido sem perder de qual sala ele veio.

Essa mesma linha de release adiciona enquetes, suporte ao esquema de URL Aegis para login NIP-46, compartilhamento nativo de invites para spaces, room mentions, colagem de imagem da área de transferência no mobile, drafts, vídeo em chamadas e melhorias de paginação do feed. É o primeiro release do Flotilla desde 1.7.0 e 1.7.1, cobertos na Newsletter #16 por salas de voz e login por email.

WoT Relay v0.2.1 migra eventstore para LMDB

WoT Relay, o relay filtrado por web of trust da bitvora, lançou a v0.2.1 em 2026-04-22. O PR #97 migra o eventstore para LMDB e recalibra os fetches iniciais do grafo WoT para que o relay construa seu trust graph sem esgotar orçamentos de leitura upstream, e o PR #99 faz upgrade de golang.org/x/crypto para v0.45.0 com as correções de segurança correspondentes. O PR #100 atualiza a URL de software e a string de versão anunciadas via NIP-11 para o release.

Suíte Formstr: hardening do Pollerama, i18n no Forms, suporte a RRULE no Calendar

A suíte Formstr mergeou 26 PRs nesta semana, espalhadas por Pollerama, Formstr Forms e Nostr Calendar, com um tema claro de segurança no app de enquetes e trabalho de feature no restante.

Pollerama, o app nostr-polls para criação e voto em enquetes Nostr, endureceu seu tratamento de chaves. O PR #182 expira DMs em cache no logout para que um dispositivo compartilhado não vaze estado do usuário anterior, o PR #175 move a chave local para armazenamento seguro do navegador, e o PR #171 protege JSON.parse do conteúdo de perfil kind 0 em todo caminho de login, para que um perfil malformado não derrube a sessão. No lado de produto, o PR #186 conecta deep linking HTTPS de pollerama.fun, e o PR #169 torna clicáveis os nomes de autores nos resultados.

Formstr, a suíte nostr-forms para forms nativos de Nostr, ampliou sua superfície de input e onboarding. O PR #475 adiciona suporte a URLs de áudio e vídeo para embeds de mídia dentro dos forms, o PR #439 introduz i18n no app web, e o PR #466 entrega um importador de onboarding para Google Forms, permitindo que criadores migrem sem reconstruir pesquisas do zero. O PR #463 fecha um vazamento de privacidade removendo logs sensíveis de chaves do console do navegador.

Nostr Calendar by Formstr lançou v1.3.0 e v1.4.0 no mesmo dia, com destaque para uma superfície adequada de regras de recorrência. O PR #107 adiciona suporte a RRULE múltiplo e customizado, e o PR #101 corrige um bug antigo ao interpretar datas RRULE flutuantes como UTC segundo a RFC 5545, eliminando deriva de horário entre timezones. O PR #97 permite adicionar eventos compartilhados ao calendário pessoal, o PR #86 introduz preferências de notificação por lista, e o PR #112 entrega o caminho retrabalhado de login e loading presente na v1.4.0. Os três projetos se apoiam em eventos de calendário da NIP-52 e compartilham a mesma stack de login.

Também lançaram: notedeck, nostr.blue, cliprelay, Captain’s Log

Um punhado de clientes lançou releases iterativas sem um recurso dominante. O cliente em Rust da equipe Damus, notedeck, publicou a v0.10.0-beta.4 com correções em rendering de colunas e relay pool. O cliente em Rust baseado em Dioxus nostr.blue v0.8.6 puxou o Dioxus 0.7.5 e destravou a build Android ao converter a bridge de áudio nativa em um plugin manganis::ffi. cliprelay, uma ferramenta de sincronização de clipboard entre dispositivos que retransmite entradas por Nostr, lançou Desktop v0.0.3 e Android v0.0.4, ajustando o loop de sync e removendo variantes Android de 32 bits. Captain’s Log publicou três builds alpha cujo recurso mais útil é detecção de liveness no sync relay, substituindo sockets caídos sem ação do usuário.

In Development

whitenoise-rs refatora para views de conta com escopo de sessão

whitenoise-rs, o daemon em Rust por baixo do cliente Marmot, mergeou 15 PRs avançando uma refatoração em múltiplas fases, saindo de singletons globais para views AccountSession por conta. O objetivo é quebrar um monólito compartilhado em superfícies menores por conta, mais fáceis de entender, testar e evoluir sem vazamento de efeitos colaterais pelo daemon inteiro.

A fundação veio com o PR #743, que introduz AccountSession e AccountManager, seguida por relay handles com escopo por conta no PR #753. Fases posteriores moveram drafts e settings, operações de mensagem, leitura e escrita de grupo, membership, push notifications, leituras de key packages e criação de grupo para superfícies pertencentes à sessão ao longo dos PRs #760 até #769. A fase 15 fecha o ciclo no PR #770, que transfere o dispatch de eventos para a sessão, fazendo com que cada conta consuma seu próprio tráfego de relay sem contenção em um dispatcher compartilhado.

White Noise adiciona UI de block/unblock, leave-group e avisos offline

White Noise, o cliente Marmot, adicionou os controles que faltavam no ciclo de vida dos grupos. O PR #578 lança a UI de block e unblock em cima de um block hook introduzido no PR #573, e o PR #571, junto do PR #572, conecta clear_chat, delete_chat e leave_and_delete_group do lado Rust ao app. Os PR #569 e PR #576 adicionam avisos offline nas telas de chat e settings para que usuários saibam quando o daemon não consegue alcançar seus relays. O PR #585 estreita o caminho amplo de delete all key packages para uma operação de delete legacy key packages, evitando que um cliente em migração entre formatos de KeyPackage apague chaves atuais junto das legadas.

MDK adiciona suporte a invites entre versões mistas e convergência de SelfUpdate

MDK, o Marmot Development Kit, mergeou sete PRs. O fio condutor do trabalho é compatibilidade, mantendo clientes em versões ligeiramente diferentes do Marmot capazes de convidar uns aos outros, rotacionar o próprio estado e recuperar-se limpos de entradas malformadas.

A correção principal é o PR #261, que computa RequiredCapabilities de um grupo como o LCD das capabilities dos convidados e desbloqueia invites entre versões mistas de Amethyst e White Noise. O PR #264 converge o formato wire de SelfUpdate entre implementações; SelfUpdate é a mensagem de controle que um membro de grupo envia quando rotaciona seu próprio KeyPackage ou estado de capabilities, então drift ali quebra silenciosamente a auto-rotação entre clientes mesmo quando invites e welcomes ainda fazem parse. Em robustez, o PR #262 faz parse dos key packages dos convidados antes de persistir o signer do criador para que um convidado malformado não deixe estado residual, o PR #256 corrige a validação de depletion de admin no lado do receiver, e o PR #259 impede que o backend de armazenamento in-memory evite estado crítico de segurança sob pressão. O PR #265 expõe um accessor group_required_proposals para que clientes possam inspecionar as proposals que DEVEM entrar antes de o próximo commit ser válido sem precisar mergulhar em internals do MDK.

nostter adiciona criptografia NIP-44 a people lists, bookmarks e mutes

nostter mergeou 10 PRs. O PR #2088 adiciona criptografia NIP-44 a mute lists, o PR #2089 faz o mesmo para bookmarks e o PR #2090 para people lists, migrando para longe da NIP-04 onde aplicável. O PR #2087 remove um caminho legado de migração de mutes kind-30000 agora que o fluxo criptografado kind-10000 se estabilizou.

zap.cooking lança pontuação Nourish e thread de comentários reutilizável

zap.cooking, o cliente Nostr de receitas, mergeou 20 PRs nesta semana. O principal recurso é um novo módulo de pontuação de receitas chamado Nourish, nos PR #317 e PR #319, que avalia receitas em eixos nutricionais. Ao lado disso, uma refatoração em quatro estágios, do PR #299 ao PR #302, extrai o módulo Comments para um CommentThread reutilizável que pode ser inserido em qualquer view. O polimento do lado de receitas inclui scaling no PR #309, um botão unificado de upload de mídia no PR #307 e uma aba Replies no perfil no PR #310.

ridestr extrai coordenador compartilhado de passageiros

ridestr, o app descentralizado de ride-sharing, mergeou 10 PRs refatorando suas telas em Compose em componentes mais focados e extraindo a lógica de protocolo de passageiro e motorista para um módulo coordenador compartilhado :common, no PR #70. O PR #60 adiciona um receiver kind 3189 para driver-ping no lado Roadflare do app.

Blossom rascunha cabeçalho BUD-01 Sunset para expiração de blobs

Blossom, o protocolo do hzrd149 para armazenar blobs em servidores HTTP indexados por hash SHA-256, abriu o PR #99 para adicionar um cabeçalho Sunset ao BUD-01. Um servidor pode usar o cabeçalho para anunciar um timestamp futuro em que deixará de servir um blob, permitindo que clientes planejem em torno de retenção limitada antes de bater em um 404. Como a proposta usa semântica padrão da RFC 8594 e é apenas consultiva, o servidor continua livre para manter o blob por mais tempo ou honrar a expiração declarada em base best effort.

New Projects

Forgesworn publica um kit criptográfico de 29 repositórios para Nostr

Forgesworn lançou 29 repositórios open source em cinco dias cobrindo assinatura, identidade, atestações, web of trust e descoberta de APIs pagas sobre Nostr.

A stack de assinatura se ancora em nsec-tree, um esquema determinístico de derivação de subidentidades que transforma um único segredo mestre em identidades Nostr ilimitadas e não correlacionáveis, e em Heartwood, um signer remoto NIP-46 que roda em Raspberry Pi com Tor habilitado por padrão. Sapwood adiciona uma UI web de gerenciamento para modelar um signer Heartwood, e heartwood-esp32 publica um experimento com a mesma lógica de token de assinatura em uma placa Heltec WiFi LoRa 32. nsec-tree-cli expõe os fluxos de derivação, prova e recuperação por Shamir para operação offline-first.

Em identidade e confiança, Signet chegou à v1.6.0 como um protocolo descentralizado de verificação de identidade para Nostr, com pareamento por QR em que a pubkey de sessão é validada e pinada ao relay. nostr-attestations define um evento kind 31000, NIP-VA, para credenciais, endorsements, vouches, provenance, licensing e trust, consolidando o que hoje está espalhado por formatos ad hoc. nostr-veil constrói uma web of trust que preserva privacidade por cima disso, com asserções NIP-85 apoiadas por LSAG ring signatures em secp256k1, de forma que um vouch possa provar membership em um grupo sem revelar qual membro o emitiu.

O lado de monetização cobre APIs pagas via Lightning e Nostr. toll-booth é um middleware L402 para Express, Hono, Deno, Bun e Cloudflare Workers que transforma qualquer API em um toll booth Lightning em uma linha, com toll-booth-dvm expondo a API protegida como um DVM da NIP-90 e toll-booth-announce fazendo bridge para 402-announce, que publica eventos parameterized replaceable kind 31402 para descoberta de serviços HTTP 402 no Nostr. 402-indexer é o crawler que recolhe esses anúncios. A organização também publicou uma coleção de 29 rascunhos de NIP cobrindo coordenação de serviços, confiança, pagamentos, disputas, hierarquia de chaves, curadoria de recursos e descoberta de API paga.

Tudo é escrito em TypeScript, sem dependências quando possível, e lançado por uma nova ferramenta bash-only chamada anvil, reforçada para supply chain, com attestation de builds reproduzíveis em múltiplos runners e trusted publishing por OIDC. Várias primitivas do conjunto, incluindo ring signatures, range proofs e shares de palavras por Shamir, preenchem lacunas antigas da camada de bibliotecas Nostr.

ShockWallet lança sincronização nativa de carteira Lightning via Nostr e conexões com múltiplos nós

ShockWallet é uma carteira Lightning que usa Nostr como transporte para conexão com nós Lightning self-custodial. O app faz pareamento com um ou mais nós Lightning.Pub sobre Nostr via um nprofile, e depois assina autorizações de pagamento end-to-end entre a carteira e o nó. A equipe lançou o PR #608 em 2026-04-18 com um passe de UI no dashboard de canais, acompanhado de um fluxo QR de admin invite link para novos usuários do PUB, PR #606, e de uma correção de legibilidade no dashboard de métricas, PR #607.

O ShockWallet usa eventos de dados específicos de aplicação NIP-78 para sincronização do estado da carteira entre dispositivos, de forma que a visão da carteira do usuário permaneça consistente entre navegador desktop e telefone sem um servidor centralizado de sync. Isso o coloca uma camada abaixo da NIP-47: NIP-47 é a interface que um app usa para pedir a uma carteira existente que pague, enquanto o ShockWallet usa Nostr como transporte de conta e sessão da própria carteira até o nó Lightning subjacente. Ao lado da carteira, a equipe segue empurrando o CLINK, um protocolo de pareamento de sessão baseado em Nostr para conexões carteira-app, mantendo uma única codebase TypeScript que gera builds para web, Android e iOS.

Issues do Nostrability migram para git over Nostr após censura do GitHub

Nostrability, o rastreador de interoperabilidade de elsat para clientes e relays Nostr, está movendo seu fluxo de issues para git over Nostr depois que a organização Nostrability foi derrubada do GitHub e o suporte do GitHub não respondeu por duas semanas. O issue tracker migrado agora vive em GitWorkshop/ngit, onde as issues existentes foram carregadas e relatórios futuros de interoperabilidade podem permanecer em infraestrutura nativa de Nostr.

nowhere codifica sites inteiros em fragments de URL e roteia pedidos por Nostr

nowhere é um novo projeto AGPL-3.0 de 5t34k que serializa um site inteiro no fragmento da URL depois de #, comprime esse conteúdo com substituição por dicionário e DEFLATE cru e então o codifica em base64url. Como o HTTP proíbe navegadores de enviar fragments ao servidor, o host que entrega a página nunca vê o conteúdo e o próprio site nunca fica armazenado em um servidor. O projeto lança oito tipos de site, incluindo event, fundraiser, store, petition, message, drop, art e forum, e cada um pode ser assinado criptograficamente pelo criador e criptografado com senha na própria URL.

Cinco dos oito tipos são puramente estáticos, mas store, forum e petition exigem comunicação ao vivo para pedidos, posts e assinaturas, e esse tráfego roda por relays Nostr usando chaves efêmeras com criptografia NIP-44, então o relay armazena eventos que não consegue ler de chaves descartáveis que não consegue rastrear. Uma loja com item único cabe em cerca de 120 caracteres, o que faz de um link nowhere um QR code imprimível para uso offline via o leitor nowhr.xyz. O repositório é um workspace pnpm dividido em um pacote codec, uma biblioteca de componentes Svelte 5 web com integração Nostr e pagamento e o app shell nowhr em nowhr.xyz.

Pequenas novas superfícies: relayk.it e Brainstorm Search

Dois projetos pequenos merecem menção sem um changelog pesado. relayk.it, construído por sam da equipe Soapbox, é um cliente de descoberta de relays construído com Shakespeare que roda inteiramente no navegador e aponta usuários para relays Nostr ativos. Brainstorm Search surge como uma UI de busca Nostr em página única focada em expor conteúdo pela rede.

Protocol and Spec Work

NIP Updates

Propostas e discussões recentes no repositório de NIPs:

Open PRs and Discussions:

NIP-67: EOSE Completeness Hint (PR #2317): propõe adicionar um terceiro elemento opcional à mensagem EOSE da NIP-01 para que um relay sinalize se entregou todos os eventos armazenados que correspondem ao filtro. Hoje, EOSE marca a fronteira entre histórico e tempo real, mas não diz nada sobre completude. Um cliente que pede 500 eventos a um relay limitado a 300 recebe 300 eventos e um EOSE, sem saber se aquilo é tudo ou se o relay parou no meio. A proposta adiciona o formato ['EOSE', '<sub_id>', 'finish'] quando o relay entregou tudo e mantém o formato legado de dois elementos como caso sem alegação de completude. O desenho é backward compatible, já que relays que não anunciam suporte caem na heurística atual, e clientes que conhecem o suporte podem parar de paginar assim que veem o sinal positivo.
NIP-5D: Nostr Applets (PR #2303): propõe um novo kind para distribuir applets interativos em Nostr. Onde a NIP-5A cobre sites estáticos e a NIP-5C cobre scrolls executáveis em WASM, a NIP-5D mira o meio-termo de applets front-end autocontidos que rodam no iframe sandboxed ou WebView de um cliente, endereçáveis por evento Nostr e atualizáveis por uma tag replaceable. Clientes passam a ter uma maneira de distribuir experiências de terceiros, como enquetes, calculadoras e mini-games, sem precisar criar um sistema completo de plugins. O PR aberto continua iterando sobre o modelo de segurança de passagem de mensagens entre applet e host.
NIP-29: spec de subgrupos (PR #2319): estende grupos baseados em relay da NIP-29 com uma hierarquia de subgrupos para que um grupo único hospede vários canais paralelos sem precisar criar grupos independentes no mesmo relay. O PR define um identificador de subgrupo que se apoia na tag h, especifica como eventos de moderação da faixa kind 9000 passam a valer para um subgrupo e esclarece como clientes devem renderizar a hierarquia. A mudança preserva o formato de uma única tag h em mensagens simples, mantendo clientes antigos funcionais em salas com subgrupos.
NIP-29: permissões explícitas de papel em kind 39003 (PR #2316): define um schema explícito de permissões no evento de papéis kind 39003 da NIP-29. Cada papel passa a ser um conjunto nomeado de operações concedidas, como invite, add-user, remove-user, edit-metadata, delete-event e add-permission, com expiração opcional. Hoje, dois relays NIP-29 rodando o mesmo grupo podem discordar sobre o que um moderator pode fazer, e clientes não têm como refletir essa diferença ao usuário; o schema corrige isso.
NIP-11: campo access_control para descoberta de relays restritos (PR #2318): adiciona um objeto opcional access_control ao Relay Information Document da NIP-11, listando o modo de restrição do relay, como open, invite, payment ou allowlist, e qualquer endpoint que um cliente possa usar para pedir acesso. O campo é apenas consultivo e permite que clientes e diretórios filtrem relays restritos para fora de listas públicas e mostrem aos usuários, de antemão, por que um relay se recusa a aceitar escritas.
NIP-63a: Minimal Payment Gateway Descriptor (PR #2315): coberto na Newsletter #18. O PR continua iterando no formato do descritor de gateway de pagamentos kind 10164 e no layout dos campos para regras de assinatura por faixa.
NIP-XX: Agent Reputation Attestations, kind 30085 (PR #2320): propõe um evento endereçável kind 30085 para atestações assinadas sobre agentes autônomos e serviços no Nostr, cobrindo confiabilidade, honest advertising e claims de resolução de disputas. Cada atestação aponta para uma pubkey alvo, carrega uma pontuação em faixa delimitada e referencia o evento de evidência que justifica a nota. A motivação é que DVMs da NIP-90 e outros mercados de serviço ainda não têm uma forma padrão para clientes publicarem feedback verificável que outros clientes possam filtrar.
NIP-TPLD: Transient Private Location Data (PR #2309): continua a partir da Newsletter #18 com mais iterações em torno do kind 20411, do formato de criptografia por destinatário com NIP-44 e da semântica da tag ttl para retenção em relays.
marmot-ts 0.5.0 release PR (PR #70): o PR pendente de release para @internet-privacy/marmot-ts@0.5.0 empacota as primeiras breaking changes planejadas no cliente Marmot em TypeScript. O release faz KeyPackageManager suportar tanto eventos legados kind 443 quanto os novos kind 30443, remove KeyPackageStore e as classes de armazenamento de estado de grupo em favor da passagem de um key-value store genérico diretamente para KeyPackageManager e MarmotGroup e move invites e gerenciamento de grupo para MarmotClient.invites e MarmotClient.groups. Projetos que embutem marmot-ts diretamente terão mudanças de construtor e camada de storage para absorver o release.

NIP Deep Dive: NIP-72 (Moderated Communities)

NIP-72 define um modelo de comunidades baseadas em tópico no Nostr em que moderadores curam uma view de leitura sobre escritas que, em si, continuam irrestritas. Diferente de grupos baseados em relay da NIP-29, em que o relay é a autoridade tanto de membership quanto de moderação, uma comunidade NIP-72 vive em eventos Nostr comuns e qualquer relay que carregue os kinds relevantes pode servi-la. Qualquer pessoa pode publicar em uma comunidade, e apenas posts aprovados por um moderador reconhecido aparecem no feed da comunidade.

Uma comunidade é definida por um evento endereçável kind 34550 publicado por seu criador. O evento é replaceable com tag d, então o criador pode editar os metadados ao longo do tempo sem perder a identidade da comunidade. A tag d é o slug estável, tags name, description, image e rules carregam metadados de exibição, e uma série de tags p com marcador moderator lista as pubkeys cujas aprovações contam. Tags relay opcionais com marcadores author, requests ou approvals sugerem onde cada tipo de evento deve ser publicado e buscado.

{
 "id": "f1e2d3c4b5a69788f1e2d3c4b5a69788f1e2d3c4b5a69788f1e2d3c4b5a69788",
 "pubkey": "c3d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8a7b6c5d4e3f2a1b0c9d8e7f6a5b4c3d2",
 "created_at": 1745280000,
 "kind": 34550,
 "tags": [
 ["d", "bitcoin-devs"],
 ["name", "Bitcoin Devs"],
 ["description", "A moderated community for Bitcoin protocol discussion."],
 ["image", "https://example.com/bitcoin-devs.png"],
 ["rules", "Stay on topic; cite sources."],
 ["p", "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876", "", "moderator"],
 ["p", "a1b2c3d4e5f6a7b8c9d0a1b2c3d4e5f6a7b8c9d0a1b2c3d4e5f6a7b8c9d0a1b2", "", "moderator"],
 ["relay", "wss://relay.example.com", "author"],
 ["relay", "wss://relay.moderator.com", "approvals"]
 ],
 "content": "",
 "sig": "aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899"
}

Um usuário envia um post publicando qualquer evento comum, uma nota kind 1, um artigo long-form kind 30023, um evento de calendário kind 31922 e assim por diante, e adicionando uma tag a cujo valor é a coordenada da comunidade 34550:<creator_pubkey>:<slug>. O post é um evento Nostr totalmente válido por si só, e clientes sem suporte a NIP-72 simplesmente o veem como uma nota endereçada a uma coordenada com formato de comunidade. Clientes com conhecimento da comunidade filtram sua view para posts aprovados por um moderador reconhecido.

A aprovação é um evento separado kind 4549, publicado por um moderador. A aprovação referencia a submissão por tag e, o autor por tag p e a comunidade por tag a, além de embutir o evento de submissão stringificado no campo content como cópia em cache. Essa cópia embutida mantém o post aprovado renderizável mesmo que o autor original apague depois o evento-fonte.

{
 "id": "a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3",
 "pubkey": "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876",
 "created_at": 1745283600,
 "kind": 4549,
 "tags": [
 ["a", "34550:c3d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8a7b6c5d4e3f2a1b0c9d8e7f6a5b4c3d2:bitcoin-devs"],
 ["e", "b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4"],
 ["p", "e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5"],
 ["k", "1"]
 ],
 "content": "{\"id\":\"b3c4d5e6...\",\"pubkey\":\"e4f5a6b7...\",\"kind\":1,\"content\":\"Question about sighash flags\",\"tags\":[[\"a\",\"34550:c3d2e1f0...:bitcoin-devs\"]],\"created_at\":1745283500,\"sig\":\"...\"}",
 "sig": "bbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aa"
}

O modelo de aprovação tem três propriedades úteis. Decisões de moderação são transparentes: toda aprovação é um evento Nostr assinado que qualquer um pode buscar, então um usuário cético pode auditar qual moderador aprovou qual post e em que momento. A moderação não é exclusiva: a mesma submissão pode ser aprovada por múltiplas comunidades, e um post rejeitado por uma pode ser aprovado por outra, porque a tag a é apenas um endereço para uma view curada. A moderação é reversível na camada de leitura: se uma comunidade remove um moderador de seu evento kind 34550, aprovações anteriores desse moderador deixam de contar em clientes que respeitam a lista atual de moderadores.

É no lado da leitura que clientes diferem. A maior parte dos clientes com suporte a comunidades renderiza o feed filtrando eventos kind 4549 tagueados com a coordenada da comunidade, deduplicando pelo ID do evento subjacente e então renderizando o post embutido. Alguns clientes também buscam diretamente as submissões e usam aprovações apenas como whitelist, o que faz sentido quando aprovações estão incompletas ou stale. Alguns poucos clientes, incluindo noStrudel e, desde o PR #2468 desta semana, Amethyst, expõem a fila de submissões pendentes aos moderadores como uma view separada.

Comparadas aos grupos baseados em relay da NIP-29, as trocas ficam claras. Comunidades NIP-72 funcionam sobre qualquer rede de relays sem suporte especial, então o caminho de escrita é portátil e a moderação é visível e passível de fork. Uma submissão é pública no momento em que é publicada, e posts não aprovados ficam ocultos na camada de renderização do cliente. Para espaços em que spam precisa ficar totalmente fora do wire, NIP-29 se encaixa melhor. Para comunidades públicas temáticas em que aprovação funciona mais como uma front page curada do que como um portão, NIP-72 se encaixa melhor.

NIP Deep Dive: NIP-57 (Zaps)

NIP-57 define zaps, uma forma de anexar pagamentos Lightning a identidades e eventos Nostr e de publicar um recibo verificável desse pagamento de volta aos relays. Um zap prova que um remetente específico pagou um valor específico a um destinatário específico por um alvo específico, e a prova pode ser lida por qualquer cliente Nostr sem confiar apenas na palavra do remetente. A spec atravessa três sistemas, LNURL, Lightning e Nostr, e fixa como eles precisam cooperar.

O fluxo tem quatro atores. O cliente do remetente descobre o endpoint LNURL do destinatário a partir do perfil kind 0, campos lud06 ou lud16, ou de uma tag zap no evento que receberá o zap. Esse cliente então assina um evento de request de zap kind 9734 descrevendo o pagamento pretendido e o envia ao callback LNURL do destinatário, não aos relays. Do outro lado, o servidor LNURL do destinatário valida o request, devolve uma invoice Lightning cujo description hash compromete a string do request e, depois que o remetente paga, publica um recibo de zap kind 9735 no conjunto de relays pedido pelo remetente.

Um request de zap, kind 9734, é um evento assinado que declara a intenção do pagamento. Os campos críticos são uma tag p com a pubkey do destinatário, uma tag e ou a opcional identificando o evento ou conteúdo endereçável que está sendo zapeado, uma tag amount em millisats e uma tag relays listando onde o recibo deve ser publicado. O content carrega uma mensagem opcional do remetente acompanhando o zap. Uma tag k registra o kind alvo para que consumidores filtrem zaps pelo tipo de conteúdo financiado.

{
 "id": "c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2",
 "pubkey": "a5b4c3d2e1f09876a5b4c3d2e1f09876a5b4c3d2e1f09876a5b4c3d2e1f09876",
 "created_at": 1745280000,
 "kind": 9734,
 "tags": [
 ["p", "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876"],
 ["e", "b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4"],
 ["amount", "21000"],
 ["relays", "wss://relay.damus.io", "wss://nos.lol", "wss://relay.nostr.band"],
 ["k", "1"]
 ],
 "content": "great post",
 "sig": "ccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbcc"
}

O recibo de zap, kind 9735, é publicado pelo servidor de carteira do destinatário depois da confirmação do pagamento. Ele não é assinado pelo remetente; é assinado pelo servidor de carteira usando a nostrPubkey anunciada pelo destinatário na response LNURL. Um recibo válido carrega o request de zap stringificado na tag description, a invoice paga na tag bolt11 e uma tag preimage provando que a invoice foi liquidada.

{
 "id": "d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3",
 "pubkey": "e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0",
 "created_at": 1745280060,
 "kind": 9735,
 "tags": [
 ["p", "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876"],
 ["P", "a5b4c3d2e1f09876a5b4c3d2e1f09876a5b4c3d2e1f09876a5b4c3d2e1f09876"],
 ["e", "b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4"],
 ["bolt11", "lnbc210n1pj...bolt11invoicestring"],
 ["description", "{\"id\":\"c1d2e3f4...\",\"pubkey\":\"a5b4c3d2...\",\"kind\":9734,\"content\":\"great post\",\"tags\":[...]}"],
 ["preimage", "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef"]
 ],
 "content": "",
 "sig": "ddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccdd"
}

A regra de validação é onde a NIP-57 ganha suas garantias de confiança. Um cliente que exibe um recibo kind 9735 como zap deve verificar quatro coisas: a assinatura do recibo corresponde à nostrPubkey anunciada na response LNURL do destinatário, o valor da invoice bolt11 corresponde à tag amount no request embutido, o description hash da invoice compromete a string do request de zap e a preimage gera o payment_hash da invoice. Um recibo que falha em qualquer uma dessas checagens é apenas uma alegação de pagamento, não uma prova. Clientes que renderizam contagens agregadas de zap sem fazer essas checagens são trivialmente falsificáveis por um atacante que publique eventos kind 9735 forjados.

Zaps privados adicionam uma camada de confidencialidade por cima. Um remetente pode criptografar o content do request de zap para o destinatário e incluir uma tag anon no request externo, de modo que a rede de relays veja o alvo do pagamento mas não consiga ler a nota anexada. Alguns clientes dão um passo adicional e geram um keypair efêmero novo para o próprio request, então o recibo ainda prova que um pagamento aconteceu, mas o destinatário não consegue ligá-lo à pubkey de longa duração do remetente. Esse padrão de anonymous zap é mais forte que um private zap simples, em que a mensagem fica escondida, mas a chave do remetente ainda pode ser visível ao longo do caminho do request.

A NIP-57 também sustenta o sistema de metas de zap especificado na NIP-75. Uma meta é um evento kind 9041 que declara um valor alvo e um conjunto de relays onde recibos contam, e qualquer recibo de zap vinculado ao ID do evento da meta contribui para seu progresso. Clientes contabilizam o progresso somando os valores bolt11 validados de eventos kind 9735 correspondentes. O PR #2469 do Amethyst nesta semana conecta metas à tela Live Activities da NIP-53 e renderiza um ranking de top zappers a partir desses mesmos recibos.

Zap splits são definidos em um apêndice do NIP. Um destinatário pode publicar um perfil kind 0 com múltiplas tags zap, cada uma com um peso, para que um único pagamento de zap seja dividido entre várias pubkeys de acordo com os pesos publicados. Criadores de conteúdo, colaboradores e destinatários de taxas de plataforma podem todos ser pagos atomicamente a partir de um único request de zap assinado pelo remetente. Diversos clientes, incluindo Amethyst, Damus e noStrudel, implementam split-paying end-to-end.

É isso por esta semana. Se você está construindo algo ou tem notícias para compartilhar, mande DM no Nostr ou nos encontre em nostrcompass.org.

Nostr Compass #18

Wed, 15 Apr 2026 00:00:00 +0000

Bem-vindo de volta ao Nostr Compass, seu guia semanal sobre o Nostr.

Esta semana: Amethyst mergeia 29 PRs, incluindo suporte a Tor no desktop, uma implementação customizada em C de secp256k1 com bindings JNI, um sistema completo de chamadas WebRTC para NIP-AC, conformidade MLS com RFC 9420 para Marmot e suporte a múltiplas carteiras NWC. nstrfy estreia como app Android de push notifications nativo de Nostr usando eventos kind 7741. HAMSTR adiciona rede mesh Reticulum, levando eventos Nostr a LoRa sem conexão de internet. Bloom lança a v0.1.0 como app desktop que empacota um servidor de mídia Blossom e um relay Nostr. WaveFunc estreia com a v0.1.0 como diretório e player de rádio na internet construído sobre Nostr. Botburrow inicia desenvolvimento como plataforma self-hosted de bots para chats em grupo criptografados com Marmot. Snort lança v0.5.0 até v0.5.3 com auditoria de segurança, verificação WASM em lote e um sistema de mensagens reescrito. Primal Android redesenha seu layout de feed.

Shipping This Week

Bloom v0.1.0 lança servidor Blossom self-hosted e relay

Bloom lançou seu primeiro release, a v0.1.0, em 9 de abril. Construído com Tauri v2 e React 19, o Bloom empacota um servidor completo do protocolo Blossom, de BUD-00 até BUD-10, e um relay Nostr em uma única aplicação desktop que roda em macOS, Windows e Linux, com builds Android e iOS planejadas. Usuários ganham armazenamento soberano de arquivos com endereçamento por conteúdo via SHA-256, suporte a metadados de arquivo NIP-94 e resolução do esquema URI blossom:// sem precisar administrar infraestrutura de servidor. Dezesseis assets binários específicos de plataforma acompanham o release.

WaveFunc v0.1.0 e v0.1.1 lançam rádio na internet sobre Nostr

WaveFunc lançou a v0.1.0 e a v0.1.1 em 13 de abril, estreando como diretório e player de rádio na internet baseado em Nostr. Kinds de evento customizados definem o modelo de dados: kind 31237 para listagens de estações, kind 30078 para listas de favoritos, kind 1311 para chat ao vivo e kind 1111 para comentários em estações. Um backend de relay Khatru fornece armazenamento em SQLite e full-text search com Bluge, suportando NIP-50.

O WaveFunc vem com uma carteira NIP-60 Cashu e suporte a nutzaps, tendo migrado de NDK para applesauce-core. A v0.1.1 adiciona carrosséis de gênero, popover para doações via Lightning, gerenciamento de estações para usuários autenticados e listagem no Zapstore. A build desktop em Tauri v2 ganhou integração com system tray, suporte a media keys, autostart e deep linking. Há builds para macOS, Windows, Linux e Android em wavefunc.live.

Snort lança v0.5.0 até v0.5.3 com hardening de segurança e overhaul de performance

Snort, o cliente web Nostr em React, lançou três releases da v0.5.0 à v0.5.3. A v0.5.0 é a maior, trazendo uma auditoria de segurança abrangente com verificação real de assinaturas Schnorr, proteção reforçada em NIP-46 contra mensagens forjadas de relay, melhorias na criptografia de PIN e remoção da confiança em delegação NIP-26 não verificada. As melhorias de desempenho incluem verificação de assinaturas em lote com WASM, rotas lazy-loaded, um carregador de perfis prioritários reescrito com batch loading e chunking e otimizações no worker relay. O release também adiciona exibição de invoice kind 7000 exigindo pagamento para DVMs da NIP-90. O PR #620 reformulou o sistema de mensagens para performance, persistindo gift wraps no worker relay e substituindo o cálculo O(n²) da lista de chats por uma abordagem de passagem única baseada em Map.

Primal Android lança 3.0.21 e redesenha o layout do feed

Primal Android lançou a v3.0.21 com correções para votos de zap em enquetes, compartilhamento multi-conta de carteira e auto-reconnect do remote signer e do serviço de carteira. Sete PRs mergeadas vieram em seguida: o PR #1008 unifica o layout da tela principal, o PR #1010 implementa um novo design de card de feed com avatares maiores e indentação do conteúdo, o PR #1009 adiciona suporte a vídeo e layout retrato em cards de mídia, o PR #1012 introduz um campo de texto compacto para quick replies e o PR #1013 redesenha as app bars.

Nostria v3.1.19 até v3.1.21 adiciona geração local de imagens com AI

Nostria lançou três releases da v3.1.19 à v3.1.21 com mais de 80 commits. A principal adição é geração local de imagens com Janus Pro usando aceleração WebGPU, permitindo que usuários gerem imagens no dispositivo sem API externa. Os releases também adicionam geração de imagens em nuvem, chat multimodal, suporte a ONNX runtime, uma biblioteca de prompts e gerenciamento de cache de AI. No lado do cliente, a atualização traz um novo sistema de diálogos, overhaul do editor de notas, melhorias em embeds de música e mudanças no fluxo de login com signer. A Newsletter #17 cobriu o release mobile nativo v3.1.18 com suporte a signer local.

TubeStr v1.0.3 lança atualizações no feed e no studio

TubeStr, um app privado de compartilhamento de vídeos familiares construído sobre Nostr, lançou a v1.0.3 em 13 de abril. O release adiciona melhorias ao feed e ao studio. O PR #3 reformula as telas de onboarding e o PR #2 corrige um erro de exportação de vídeo. O app usa NDK e MDK, o Marmot Development Kit, para compartilhamento criptografado de mídia entre familiares, com integração Blossom planejada para armazenamento de mídia. O TubeStr está disponível no Zapstore.

In Development

Botburrow começa o desenvolvimento como plataforma de bots para Marmot

Botburrow é um novo projeto da equipe Marmot, iniciado em 3 de abril. É uma plataforma self-hosted de gerenciamento de bots em que cada bot recebe sua própria identidade Nostr, entra em chats de grupo criptografados com MLS do Marmot por meio de mensagens Welcome e envia e recebe mensagens end-to-end encrypted. O dashboard, construído com Rails 8.1, se comunica com um único daemon whitenoise-rs, wnd, por um socket Unix.

O Botburrow expõe uma camada substancial de scripts e operações: comandos, triggers e ações agendadas executam código Ruby customizado, scripts podem inspecionar perfis, membership de grupos e invites pendentes por meio do wnd, o dashboard inclui uma live chat view para trocar mensagens com bots em grupos reais, e cada bot tem seu próprio armazenamento de arquivos para configs, dados em cache e saída gerada. Uma imagem Docker com builds multi-arch mira self-hosting sem configuração em Umbrel e Start9. Uma seção sobre trust model no README documenta as fronteiras de segurança.

Nostr Archives adiciona relay de feeds em alta e resolução de entidades

Nostr Archives, a plataforma de arquivamento e analytics em nostrarchives.com, seguiu em desenvolvimento constante em sua API, em Rust, e no frontend, em Next.js 16. Na API, o PR #118 adiciona filtragem por intervalo de tempo ao leaderboard de clientes, e o PR #117 adiciona contadores de engajamento a eventos de reply. No frontend, o PR #85 resolve entidades Nostr diretamente a partir do path da URL, para que colar um npub ou note ID na URL faça o site renderizar o conteúdo, e o PR #86 adiciona uma página de documentação da API. A plataforma roda quatro serviços de relay: um relay de busca NIP-50, um relay de feeds em alta, visível em wss://feeds.nostrarchives.com, um scheduler relay para eventos futuros e um indexer relay para kinds 0, 3 e 10002.

Damus corrige a timeline de favoritos

Damus, o cliente iOS, mergeou o PR #3708, reescrevendo a função subscribe_to_favorites() com filtragem in-place, reconstrução de deduplicação e seleção persistida de abas.

Nostur adiciona private zaps e visualização de emoji customizado

Nostur, o cliente iOS, publicou 10 commits nesta semana adicionando suporte a private zaps, visualização de emoji customizado, correção de renderização animada .webp e detecção de formato de áudio em mensagens de voz.

Amber lança v6.0.1 até v6.0.3 com backup WebDAV e correções de reconexão a relays

Amber, o app signer Android da NIP-55, lançou três releases nesta semana. A v6.0.1 adiciona duas novas opções de backup, WebDAV e compartilhamento para Google Drive, implementa exponential backoff para reconexões com relays, atualiza a biblioteca Quartz para 1.08.0 e corrige validação de eventos de atualização do app e de perfil. A v6.0.2 adiciona uma opção de índice de conta ao usar seed words e corrige a reconexão a relay quando o relay está offline no startup. A v6.0.3 adiciona uma correção extra para request IDs vazios ao receber intents.

Plektos v0.6.0 redesenha com temas Ditto

Plektos, a plataforma descentralizada de meetups e eventos construída sobre NIP-52 com mapas interativos, lançou a v0.6.0 e a v0.6.1 em 14 de abril. A atualização adiciona temas de comunidade ao estilo Ditto com upload de imagem de fundo, configuração do formato do avatar e overhaul de UI. O PR #6 responde a uma revisão completa de código cobrindo achados de segurança, arquitetura e UX. O Plektos usa Nostrify para integração de protocolo, NIP-46 para login remoto e zaps para pagamento de ingressos. A build Android está no Zapstore.

Shadow adiciona Nostr OS API e app de carteira Cashu

Shadow, a plataforma de runtime de apps do Justin Moon, publicou mais de 30 commits em dois dias. O commit 88cbda5 adiciona um app de carteira Cashu rodando dentro do runtime Shadow. O commit 865c415 adiciona um demo de podcast player. O runtime expõe Shadow.os.nostr e Shadow.os.audio como APIs de nível de sistema, e a faixa Pixel do runtime roda um compositor Wayland em dispositivos Android com root e composição por GPU. Os PR #1 e PR #2, do colaborador k0sti, corrigem carregamento de fontes no desktop Linux e tratamento do diretório de estado XDG. Ainda não há release formal.

Lief, um app Nostr para compor e enviar cartas long-form a outros usuários Nostr, lançou a build v2026.04.12 em 12 de abril. A atualização corrige um problema de login com signer Amber no Android, simplifica o fluxo de lembrete de signer, atualiza a dependência nostrify e adiciona integração com Zapstore.

Espy, um app social Nostr em que usuários compartilham color moments, capturando paletas de 3 a 6 cores de cenas reais como forma de comunicação visual pré-verbal, lançou a build v2026.04.12 em 12 de abril. A atualização reformula o color picker com um arco curvo de saturação no lugar do toggle em escala de cinza, corrige bugs de flicker no anel de matiz e adiciona personagens Easter egg, Alchemist e Astrologer. A compressão reduziu assets PNG em 703 KB. O release também corrige um problema de login com signer Amber, simplifica o fluxo de signer nudge, atualiza a dependência nostrify e adiciona integração com Zapstore.

Jumble adiciona filtros de kind por feed e aba de artigos

Jumble, o cliente Nostr, publicou 13 commits nesta semana adicionando filtragem de kind por feed, uma aba Articles, sincronização de status de leitura de notificações com uma opção que preserva privacidade, um modo de ocultar avatar e correção de uma race condition na troca de conta.

Primal Web lança 8 version bumps

Primal Web lançou versões 3.0.93 até 3.0.101 em uma semana com 21 commits. O trabalho se concentrou em melhorias no chat de live stream, correções de limites de mentions, paginação de bookmarks, prevenção de likes duplicados e correções no relay proxy.

Protocol and Spec Work

NIP Updates

Mudanças recentes no repositório de NIPs:

Merged:

NIP-34 (Git Stuff): adiciona URLs de clone nostr:// (PR #2312): NIP-34 define como hospedar repositórios git no Nostr usando anúncios de repositório kind 30617 que listam branches, tags, localizações de relay e pubkeys de mantenedores. Até agora, a spec não tinha um esquema formal de URL para referenciar esses repositórios. Este PR adiciona um formato de clone URL nostr:// que funciona com helpers git-remote-nostr, então git clone nostr://npub1.../relay.ngit.dev/ngit resolve o npub, ou endereço NIP-05, descobre as localizações de relay do repositório e busca os dados do repositório. Três padrões de URL são definidos: nostr://<naddr> para referências diretas a eventos endereçáveis, nostr://<npub|nip05>/<identifier> para referências legíveis por humanos e nostr://<npub|nip05>/<relay-hint>/<identifier> quando o cliente precisa de um relay hint. Tanto o relay hint quanto o identifier são percent-encoded conforme a RFC 3986. O formato já é implementado por Shakespeare e pelo helper git-remote-nostr do ngit, e exibido por GitWorkshop.dev e NostrHub.io. O PR também endurece o formato da tag d para identificadores de repositório, para que URLs nostr:// produzam URIs válidas.

Open PRs and Discussions:

NIP-63a: Minimal Payment Gateway Descriptor (PR #2315): propõe um novo evento replaceable kind 10164 que permite a criadores de conteúdo declarar payment gateways, modelos de preço e regras de assinatura para acesso a conteúdo pago. Hoje, conteúdo pago no Nostr exige que cada cliente implemente seu próprio fluxo de pagamento, sem forma padrão de um criador dizer que o conteúdo custa X sats via gateway Y. O evento proposto embutiria descritores de gateway diretamente em eventos Nostr, permitindo que clientes descubram métodos de pagamento aceitos, faixas de preço e opções de assinatura a partir de um único evento replaceable. Isso desacopla a apresentação de pagamento de provedores específicos, de forma que um criador poderia aceitar Lightning, Cashu ou gateways fiat sem exigir integração customizada em cada cliente.
NIP-XX: Relay Self-Declaration Manifest and Retention Horizon (PR #2314): propõe dois primitivos de wire protocol para transparência de relays. O primeiro é o kind 10100, um evento replaceable gossipable em que operadores de relay declaram seus endpoints, em clearnet, Tor e I2P, janela de retenção, política de escrita e NIPs suportados. Diferente dos Relay Information Documents da NIP-11, que são entregues por HTTP e não podem ser descobertos pelo próprio Nostr, manifests kind 10100 se propagam pela rede de eventos Nostr como qualquer outro evento, com binding TOFU por meio do campo pubkey da NIP-11 para evitar spoofing. O segundo primitivo é HORIZON, uma nova mensagem relay-to-client ['HORIZON', <sub_id>, <earliest_timestamp>] enviada antes de EOSE. Quando o intervalo temporal pedido por um cliente ultrapassa a janela de retenção do relay, o relay responde com o timestamp mais antigo que possui, trocando dead ends silenciosos por fronteiras temporais explícitas. A motivação é que o campo retention da NIP-11 foi removido em fevereiro de 2026 por falta de uso, porque a entrega apenas por HTTP falhou em distribuição. Uma implementação de referência roda no nostr-rs-relay 0.9.0 com pruning de 90 dias.
NIP-TPLD: Transient Private Location Data (PR #2309): propõe o kind 20411, na faixa efêmera, para compartilhar geolocalização criptografada com destinatários específicos. Serviços centralizados de compartilhamento de localização como Google Maps e Apple Find My exigem confiar em uma autoridade central com movimentos em tempo real. Este NIP define uma alternativa privacy-first em que o conteúdo do evento contém um mapa JSON de pubkeys destinatárias para payloads criptografados com NIP-44, cada um contendo um geohash em nível de precisão configurável. Múltiplos destinatários são tratados em um único evento com criptografia por destinatário, então cada pessoa só pode descriptografar seu próprio payload. Uma tag ttl define o time-to-live sugerido em segundos, e a faixa efêmera de kinds sinaliza a relays que esses eventos não devem ser armazenados indefinidamente. As tags p permitem que clientes filtrem eventos relevantes sem descriptografar o conteúdo.
NIP-5C (Scrolls): atualização de programas WASM (PR #2281): continua o desenvolvimento da spec de publicação e execução de programas WebAssembly, que define convenções para publicar e descobrir binários WASM como eventos Nostr. Scrolls são programas autocontidos que clientes podem baixar de relays e executar em um runtime sandboxed, transformando o Nostr em uma rede de distribuição de código executável. O PR refina o formato do evento e a interface de runtime. Um demo app mostra scrolls rodando no navegador, com programas de exemplo publicados como eventos Nostr que qualquer cliente pode buscar e executar. O conceito estende a NIP-5A, sites estáticos, da entrega de páginas HTML para a execução de programas interativos, tudo distribuído pela mesma infraestrutura de relays.
Suporte a payloads grandes na NIP-44 (PR #1907): propõe estender a criptografia versionada da NIP-44 para lidar com payloads maiores que o limite atual de 65.535 bytes. A mudança é backward compatible, então implementações que não precisam de mensagens grandes podem ignorá-la. A motivação prática é assinatura remota NIP-46 de listas grandes de contatos kind 3, em que a lista de follows de um usuário pode ultrapassar o limite de tamanho quando serializada em JSON. Sem essa mudança, signers remotos não conseguem criptografar responses contendo grandes listas de contatos, forçando workarounds ou truncamento.
NIP-C7: restringe kind 9 a views de chat (PR #2310): NIP-C7 define o kind 9 como uma mensagem leve de chat, uma nota curta de texto destinada a conversa em tempo real em contextos de chat como grupos da NIP-29 e streams de live activities da NIP-53. Este PR adiciona o requisito de que clientes que renderizam uma chat view como stream de eventos ordenados DEVEM buscar apenas eventos kind 9, evitando perda de contexto quando outros tipos de conteúdo, como notas kind 1 e artigos kind 30023, se misturam à timeline do chat. Outros tipos de conteúdo ainda podem ser citados dentro de uma mensagem kind 9 seguindo reposts da NIP-18. A motivação vem de uma discussão comunitária sobre mensagens kind 9 aparecendo em feeds gerais sem contexto, já que mensagens de chat costumam ser respostas curtas que só fazem sentido dentro de um thread de conversa.

NIP Deep Dive: NIP-29 (Relay-based Groups)

NIP-29 define um modelo de mensagens em grupo em que o próprio relay gerencia membership e moderação. Grupos vivem em um relay específico, identificados por uma string aleatória de ID, e o relay impõe quem pode escrever no grupo. Essa é uma arquitetura diferente de Marmot, com criptografia MLS do lado do cliente, ou de chats em grupo da NIP-17, com gift-wrapped DMs: na NIP-29, o relay é a autoridade, as mensagens podem ser lidas pelo operador do relay e a moderação acontece no nível do relay.

Um grupo é identificado pelo formato <host>'<group-id>, por exemplo groups.nostr.com'abcdef. O ID especial _ é reservado como grupo de topo para discussão em nível de relay. Todos os eventos de usuário enviados ao grupo carregam uma tag h com o ID do grupo:

{
 "id": "a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890",
 "pubkey": "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876",
 "created_at": 1744675200,
 "kind": 9,
 "tags": [
 ["h", "abcdef"],
 ["previous", "a1b2c3d4", "e5f67890", "12345678"]
 ],
 "content": "Has anyone tested the new relay config?",
 "sig": "e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4"
}

A tag previous funciona como mecanismo de detecção de adulteração. Clientes incluem os primeiros 8 caracteres hex dos eventos recentes vistos no mesmo relay dentro das últimas 50 mensagens. Relays rejeitam eventos com referências previous a eventos fora do banco, o que impede replay de mensagens para uma cópia bifurcada do grupo em outro relay. Não é uma cadeia completa de custódia, mas torna rebroadcasts fora de contexto detectáveis.

A membership é gerenciada por um conjunto de kinds de moderação na faixa 9000-9020. Um usuário entra publicando um request de entrada kind 9021, que o relay aceita ou rejeita com base em sua política:

{
 "id": "b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1",
 "pubkey": "f1a2b3c4d5e6f7890123456789abcdef0123456789abcdef1234567890abcdef",
 "created_at": 1744675200,
 "kind": 9021,
 "tags": [
 ["h", "abcdef"],
 ["code", "invite-xyz-123"]
 ],
 "content": "I'd like to join the dev discussion group.",
 "sig": "11223344556677889900aabbccddeeff11223344556677889900aabbccddeeff11223344556677889900aabbccddeeff11223344556677889900aabbccddeeff"
}

A tag code opcional se vincula a invite codes criados por admins via eventos kind 9009. Um usuário sai publicando kind 9022, e o relay emite automaticamente uma remoção kind 9001 em resposta. Admins podem adicionar usuários com papéis, kind 9000, remover usuários, kind 9001, editar metadados do grupo, kind 9002, e apagar eventos, kind 9005. O sistema de papéis é flexível: papéis são rótulos arbitrários, e o que cada papel pode fazer é política do relay, não algo definido pelo protocolo. O relay publica a configuração do grupo como eventos endereçáveis: kind 39000 para metadados, kind 39001 para lista de admins, kind 39002 para lista de membros e kind 39003 para papéis e capacidades.

Grupos podem ser públicos, qualquer um lê, só membros escrevem, fechados, só membros leem e escrevem, ou totalmente abertos. As settings de visibilidade e acesso de escrita são ortogonais e controladas pelas flags public, open, visible e unrestricted no evento de edição de metadados kind 9002. Um relay pode hospedar muitos grupos simultaneamente, cada um com membership e moderação independentes.

A spec aceita qualquer kind de evento dentro de um grupo, não apenas mensagens de chat. Artigos de formato longo da NIP-23, eventos de calendário da NIP-52, lives da NIP-53 e listagens de mercado podem carregar uma tag h e participar do contexto do grupo. Isso faz grupos NIP-29 funcionarem mais como servidores do Discord ou workspaces do Slack, onde diferentes tipos de conteúdo coexistem no mesmo namespace.

Flotilla é o cliente NIP-29 em desenvolvimento mais ativo, com salas de voz, login por email e DMs com proof-of-work adicionadas na v1.7.0. Coracle também suporta grupos NIP-29. No lado de relay, groups.fiatjaf.com é uma implementação de referência de fiatjaf. Nostrord, um cliente NIP-29 em Kotlin Multiplatform financiado pela OpenSats, está em desenvolvimento inicial com moderação estilo Discord e threading.

O tradeoff contra alternativas criptografadas como Marmot é explícito. Grupos NIP-29 podem ser lidos pelo operador do relay. Não há end-to-end encryption, nem forward secrecy, nem segurança pós-comprometimento. O relay é uma parte confiável para integridade de conteúdo e enforcement de membership. Em troca, o modelo oferece simplicidade: não há material de chave para gerenciar, nem sincronização de estado entre dispositivos, nem negociação MLS handshake. Um operador sobe um grupo, usuários entram e as mensagens fluem. Para comunidades públicas, canais de dev e espaços de discussão aberta, o modelo de confiança no relay combina com o caso de uso. Para mensagens privadas em que o relay não deve ler o conteúdo, NIP-17 ou Marmot são escolhas mais apropriadas.

NIP Deep Dive: NIP-90 (Data Vending Machines)

NIP-90 define um protocolo para computação on-demand sobre Nostr. Um cliente publica um request de job, provedores de serviço competem para cumpri-lo e os resultados são entregues como eventos Nostr. A spec descreve isso como money in, data out, tratando o Nostr como um mercado para processamento de dados, em que clientes se importam com o resultado, não com quem o produziu.

O protocolo reserva os kinds 5000-5999 para requests de jobs, 6000-6999 para resultados e o kind 7000 para feedback. O kind do resultado é sempre 1000 acima do kind do request: um request kind 5001 produz um resultado kind 6001. Abaixo está um request de job pedindo sumarização de texto:

{
 "id": "c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2",
 "pubkey": "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876",
 "created_at": 1744675200,
 "kind": 5001,
 "tags": [
 ["i", "https://example.com/article.txt", "url"],
 ["output", "text/plain"],
 ["relays", "wss://relay.damus.io", "wss://nos.lol"],
 ["bid", "5000"],
 ["param", "lang", "en"],
 ["param", "max_tokens", "280"]
 ],
 "content": "",
 "sig": "aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899"
}

A tag i especifica os dados de entrada com um marcador de tipo. Quatro tipos de entrada são definidos: url, buscar e processar dados na URL; event, usar um evento Nostr como entrada; job, encadear a partir da saída de um job anterior; e text, texto inline. A tag bid define um pagamento máximo em millisats. A tag param carrega parâmetros específicos do tipo de job, e a tag output especifica o formato de resposta esperado.

Um provedor de serviço pega o request e publica um resultado:

{
 "id": "d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3",
 "pubkey": "9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba",
 "created_at": 1744675260,
 "kind": 6001,
 "tags": [
 ["request", "{\"id\":\"c3d4e5...\",\"kind\":5001,...}"],
 ["e", "c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2", "wss://relay.damus.io"],
 ["i", "https://example.com/article.txt", "url"],
 ["p", "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876"],
 ["amount", "5000", "lnbc50n1pj..."]
 ],
 "content": "The article discusses three protocol changes proposed for the next quarter...",
 "sig": "fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210"
}

O resultado marca o evento request original, inclui a entrada para referência, endereça a pubkey do cliente e opcionalmente inclui uma invoice Lightning na tag amount. O cliente pode verificar que o resultado veio de um provedor específico conferindo a pubkey.

Feedback de job, kind 7000, fornece atualizações de status enquanto um job está em andamento. Provedores podem emitir eventos de feedback com valores de status como payment-required, processing, error ou success. Isso dá visibilidade em tempo real a jobs longos:

{
 "id": "e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4",
 "pubkey": "9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba",
 "created_at": 1744675230,
 "kind": 7000,
 "tags": [
 ["status", "payment-required"],
 ["e", "c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2", "wss://relay.damus.io"],
 ["p", "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876"],
 ["amount", "5000", "lnbc50n1pj..."]
 ],
 "content": "",
 "sig": "11223344556677889900aabbccddeeff11223344556677889900aabbccddeeff11223344556677889900aabbccddeeff11223344556677889900aabbccddeeff"
}

O encadeamento de jobs permite que saídas alimentem jobs posteriores. Um cliente pode definir o tipo de entrada como job e referenciar o ID de evento de um job anterior. O provedor do job downstream espera o resultado upstream e então o processa. Isso cria pipelines componíveis: transcrever áudio, kind 5002, depois resumir a transcrição, kind 5001, e depois traduzir o resumo, kind 5003. Cada passo pode ser cumprido por um provedor diferente.

Por privacidade, clientes podem criptografar as tags i e param usando a criptografia da NIP-04 com a pubkey do provedor, colocando o payload criptografado no campo content e adicionando uma tag encrypted. Isso esconde dados de entrada e parâmetros de relays e outros provedores, embora exija que o cliente selecione um provedor específico desde o início.

Tipos específicos de request de job são definidos em um repositório separado. Os tipos atuais incluem geração de texto, kind 5050, sumarização, kind 5001, tradução, kind 5002, speech-to-text, kind 5003, geração de imagens, kind 5100, e recomendação de conteúdo, kind 5300.

Snort adicionou exibição de invoice de pagamento obrigatório kind 7000 na Newsletter #17, renderizando invoices Lightning diretamente no feed quando um DVM responde com exigência de pagamento. noStrudel tem um explorador de DVM para navegar por provedores disponíveis. Do lado dos provedores, projetos como DVMDash acompanham atividade de DVM pela rede, e vários serviços focados em AI oferecem geração de texto, criação de imagens e moderação de conteúdo por meio do protocolo NIP-90. A NIP-89, Recommended Application Handlers, complementa a NIP-90 ao permitir que provedores publiquem suas capabilities como eventos Nostr descobríveis.

É isso por esta semana. Está construindo algo ou tem notícias para compartilhar? Mande DM no Nostr ou nos encontre em nostrcompass.org.

Nostr Compass #17

Wed, 08 Apr 2026 00:00:00 +0000

Bem-vindo de volta ao Nostr Compass, seu guia semanal sobre o Nostr.

Esta semana: Amethyst lança a v1.08.0 com integração Arti Tor e uma UI de Shorts redesenhada, enquanto incorpora implementações em Kotlin puro de MLS e Marmot à sua biblioteca Quartz. Nostur lança a v1.27.0 com gravação de vídeo, perfis com GIF animado e respostas privadas. Shosho lança a v0.15.0 com Shows (informações personalizadas de live conectadas ao OBS) e um carrossel vertical de vídeos no estilo TikTok. Nymchat reverte Marmot e lança chats de grupo NIP-17 aprimorados com chaves efêmeras rotativas. Nostr VPN lança suporte a exit nodes e empacotamento para Umbrel ao longo de seis releases. Amber salta para a v6.0.0-pre1 com chaves de assinatura NIP-46 por conexão e atualizações in-app via Zapstore. Notedeck chega à v0.10.0-beta com self-update de APK via Zapstore, e NIP-58 (Badges) recebe uma migração de kind. Dois deep dives de NIP cobrem NIP-17 (Private Direct Messages) e NIP-46 (Nostr Remote Signing).

Notícias

Amethyst lança Arti Tor e incorpora MLS e Marmot em Kotlin puro

Amethyst, o cliente Android mantido por vitorpamplona, lançou quatro releases da v1.07.3 até a v1.08.0 e incorporou um grande lote de trabalho ainda não lançado à sua biblioteca Quartz (o módulo Nostr compartilhado em Kotlin Multiplatform). O release principal é a v1.08.0 “Arti Tor”, que migra a conectividade Tor do app da biblioteca Tor baseada em C para Arti, a implementação em Rust do Tor Project. A migração resolve crashes aleatórios que aconteciam com os bindings anteriores de Tor em C. Arti é o substituto de longo prazo do Tor Project para a codebase em C, escrito do zero em Rust para memory safety e async I/O.

O release v1.07.3 redesenhou a UI de Shorts, substituindo o design paginado por feeds edge-to-edge para fotos, shorts e vídeos longos. O mesmo release migrou badges para kind 10008 e bookmarks para kind 10003, alinhando-se à migração de kind de NIP-58 mergeada nesta semana. A v1.07.4 corrigiu um problema no tratamento de secret do Nostr Wallet Connect, e a v1.07.5 corrigiu um crash no upload de imagens.

Na branch main, mas ainda sem release com tag, a equipe escreveu uma implementação completa em Kotlin tanto de MLS quanto do protocolo Marmot, eliminando a necessidade de bindings nativos de bibliotecas C/Rust. O PR #2147 adiciona a camada central de mensagens de grupo Marmot MLS, o PR #2149 adiciona a UI de chat em grupo, o PR #2146 adiciona processadores de mensagens de entrada e saída com um subscription manager, o PR #2141 adiciona persistência do estado de grupo MLS e gerenciamento de rotação de KeyPackage, o PR #2150 adiciona uma suíte completa de testes de MLS com assinatura de GroupInfo aprimorada, e o PR #2158 adiciona rastreamento do status de publicação de KeyPackage. O PR #2166 adiciona uma implementação secp256k1 em Kotlin puro para operações criptográficas de Nostr, substituindo a dependência da biblioteca nativa em C. Combinado com a implementação de MLS em Kotlin, Quartz pode executar assinatura Nostr e mensagens de grupo Marmot sem nenhum binding nativo, o que abre caminho para targets Kotlin Multiplatform incluindo iOS.

A equipe também está construindo suporte a NIP-AC (P2P Voice and Video Calls): o PR #2143 adiciona uma suíte completa de testes para a máquina de estados de chamadas do NIP-AC, e o PR #2164 impede que ofertas de chamada antigas sejam disparadas novamente após reiniciar o app.

Nostur v1.27.0 adiciona gravação de vídeo e respostas privadas

Nostur, o cliente Nostr para iOS, lançou a v1.27.0 em 2 de abril. O release adiciona gravação de vídeo dentro do app com corte antes do upload, para que usuários possam capturar clipes curtos, ajustá-los ao tamanho desejado e publicar sem sair do cliente. O suporte a GIF animado se estende a fotos de perfil e de banner, com renderização de WebP animado adicionada também. Uma nova integração com Shortcuts permite que usuários enviem posts Nostr a partir de automações do Apple Shortcuts. O release também adiciona respostas privadas e corrige problemas de compatibilidade de DM que afetavam a entrega de mensagens entre Nostur e outros clientes.

Shosho v0.15.0 lança Shows e carrossel vertical de vídeo

Shosho, o app de live streaming Nostr, lançou a v0.15.0 e a v0.15.1 em 7 de abril. O recurso principal é Shows: streamers podem configurar informações personalizadas do show antes de entrar ao vivo e conectar seu show ao OBS ou a qualquer encoder externo. Isso separa os metadados de “o que estou transmitindo” do ato de entrar ao vivo, de modo que streamers possam preparar títulos, descrições e produtos antes de começar a transmitir. O mesmo release adiciona um carrossel vertical de vídeo no estilo TikTok para navegar por lives, clipes e replays em um feed de tela cheia, além de Quick Add para publicar clipes de vídeo e adicionar produtos diretamente de uma página de perfil. A v0.15.1 corrige um bug em que o teclado escondia o campo de entrada do chat da live.

Lançamentos

Notedeck v0.10.0-beta lança self-update via Zapstore

Notedeck, o cliente desktop e mobile da equipe Damus, lançou a v0.10.0-beta.1 e a v0.10.0-beta.2 como prereleases de teste para self-update de APK. O PR #1417 adiciona self-update de APK via o atualizador Nostr/Zapstore no Android, expandindo o trabalho de descoberta de atualizações nativa do Nostr da Newsletter #14. O fluxo de atualização descobre novos releases por meio de eventos Nostr publicados em relays, depois baixa o APK de onde quer que o desenvolvedor o hospede (GitHub releases, Blossom CDN ou outras fontes), verifica o hash SHA-256 contra o evento Nostr assinado e faz a instalação. O PR #1438 corrige um bug na tela de boas-vindas em que os botões Login e CreateAccount navegavam imediatamente de volta, e o PR #1424 corrige overflow de texto na visualização de sessão do Agentium AI.

Amber v6.0.0-pre1 adiciona chaves de assinatura NIP-46 por conexão

Amber, o app assinador NIP-55 (Android Signer Application), lançou a v6.0.0-pre1 em 4 de abril. A mudança mais importante é o uso de chaves de assinatura por conexão para o protocolo bunker NIP-46 (Nostr Remote Signing). Em vez de usar um único par de chaves para todas as conexões bunker, o Amber agora gera uma chave distinta para cada cliente conectado. Se a conexão de um cliente for comprometida, o invasor não pode se passar pelo signer para outros clientes.

O PR #377 adiciona verificação e instalação de atualizações in-app via Zapstore, juntando-se ao Notedeck na adoção de distribuição de apps nativa do Nostr. O PR #375 trata falhas de AndroidKeyStore de forma segura ao exibir um aviso aos usuários em vez de causar crash, e o PR #371 adiciona limpeza de banco de dados com limites de tamanho e truncamento de conteúdo para impedir crescimento ilimitado de armazenamento. O pre-release também carrega a whitelist de relay auth NIP-42 e o login por frase de recuperação mnemônica do ciclo v5.0.x coberto na semana passada.

Nostria lança app mobile nativo

Nostria, o cliente Nostr multiplataforma mantido por SondreB, lançou um app mobile nativo para Android com oito releases da v3.1.11 até a v3.1.18. A nova capacidade mais importante é o suporte nativo a signer local para signers como Amber e Aegis. Também estão disponíveis instaladores desktop para Linux, macOS e Windows. O PR #610 reduz a pressão de memória do feed com limites adaptativos em runtime e limpeza de preview URLs. A v3.1.14 corrige a integração com Brainstorm, um provedor de Web of Trust. A v3.1.15 se concentra em melhorias de música. O novo app Android está disponível no Zapstore.

diVine 1.0.8 lança uploads retomáveis e DMs

diVine, o cliente de vídeo short-form, lançou a 1.0.8 com 87 PRs mergeados. Uploads retomáveis permitem que criadores continuem uploads interrompidos chunk por chunk em vez de reiniciar do zero em uma conexão instável. O release adiciona configurações de qualidade de vídeo e bitrate, double-tap para curtir e melhorias em DMs. O PR #2722 adiciona um plugin de câmera para macOS para captura de vídeo no desktop, e o PR #2820 migra o sistema de notificações para uma arquitetura BLoC com enriquecimento e agrupamento. A equipe também substituiu stickers e artes de categoria gerados por AI por SVGs do OpenMoji (PR #2844, PR #2842).

Manent v1.3.0 adiciona desfoque de notas sensíveis e auth NIP-42

Manent, o app privado de notas criptografadas e armazenamento de arquivos, lançou a v1.3.0 em 2 de abril. Usuários agora podem marcar notas como sensíveis para desfocá-las na visualização em lista, mantendo conteúdo privado oculto durante rolagens casuais. O release também adiciona suporte a NIP-42 (Authentication of Clients to Relays), permitindo que o Manent se autentique em relays que exigem isso antes de aceitar eventos. O Manent armazena todos os dados criptografados em relays Nostr usando o par de chaves do usuário, então o suporte a NIP-42 amplia o conjunto de relays que ele pode usar para armazenamento.

Wisp v0.17.0 até v0.17.3 adicionam zaps em live stream e backup de carteira

Wisp, o cliente Nostr para Android, lançou seis releases da v0.16.2-beta até a v0.17.3-beta com 44 PRs mergeados. O release v0.17.0 adiciona prompts de segurança para backup de carteira e melhorias na UX de zap. A v0.17.1 adiciona visibilidade de chat de live stream entre plataformas e funcionalidade de zap em live stream. O PR #423 adiciona auto-search de perfis, uma animação de sucesso de zap e melhorias de status do usuário. O PR #426 corrige um crash por falta de memória em computeId para eventos com listas grandes de tags. Os releases v0.16.x adicionaram autocomplete de shortcode de emoji, melhorias na UI de chat em grupo e filtragem de usuários bloqueados em todos os caminhos de notificação.

Mostro lança deep links, taxas de câmbio do Nostr e uma correção para pagamento duplicado

Mostro, a exchange peer-to-peer de Bitcoin construída sobre Nostr, teve atualizações tanto em seu daemon de servidor quanto em seu cliente mobile nesta semana. No lado do servidor, o PR #692 impede que escritas antigas de ordens causem pagamentos duplicados, um bug que poderia fazer com que um vendedor recebesse duas vezes pela mesma negociação. O PR #693 usa atualizações direcionadas para escritas de dev_fee em vez de sobrescrever a ordem inteira.

Mostro Mobile, o cliente Flutter, lançou a v1.2.3 em 3 de abril. O release trata deep links de diferentes instâncias do Mostro, para que usuários possam tocar em links que os encaminham ao servidor de exchange correto. O PR #498 detecta DMs de admin e de disputa no pipeline de notificações em background, e o app agora busca taxas de câmbio via Nostr com fallback HTTP/cache. O PR #560 corrige um bug de bloqueio de conexão com relay que impedia o app de alcançar relays em certas condições de rede.

Unfiltered v1.0.12 adiciona hashtags e comentários

Unfiltered, um cliente Nostr focado em conteúdo orientado por imagem, lançou a v1.0.12. O PR #69 adiciona suporte a hashtag e o PR #72 adiciona a capacidade de escrever e exibir comentários em posts. O PR #71 corrige problemas de navegação com múltiplas imagens por post.

Primal Android lança compartilhamento multi-conta de carteira e auto-reconnect do remote signer

Primal, o cliente Nostr para Android, lançou um release em 7 de abril. A atualização adiciona compartilhamento multi-conta de carteira e menu overflow com deleção de carteira em Dev Tools. O remote signer agora faz auto-reconnect quando a conexão cai, e o serviço de carteira ganhou sua própria lógica de auto-reconnect. As correções incluem votos de zap em enquetes que não aparecem mais como Top Zaps, prevenção de crash com opção de enquete vazia, ocultação do saldo da carteira quando não existe carteira, e mapeamento do tipo WalletException para códigos de erro em respostas NWC.

Titan v0.1.0 lança navegador nativo nsite:// com registro de nomes no Bitcoin

Titan, um navegador desktop nativo para a web do Nostr, lançou a v0.1.0 em 7 de abril. O Titan resolve URLs nsite:// consultando nomes legíveis por humanos registrados no Bitcoin, consultando relays Nostr pelos eventos de conteúdo do site e renderizando páginas buscadas em servidores Blossom. O resultado é uma experiência de navegação web sem DNS, sem certificados TLS e sem provedores de hospedagem. Os nomes são registrados por meio de uma interface web vinculada a transações de Bitcoin. O release inicial sai como um .dmg para macOS (ARM, com suporte a Rosetta 2 para Intel) e inclui suporte a ambiente de desenvolvimento Nix.

Bikel v1.5.0 lança serviço foreground nativo para telefones sem Google

Bikel, um rastreador de ciclismo descentralizado que transforma trajetos em dados de infraestrutura pública usando Nostr, lançou a v1.5.0 em 4 de abril. O release migra do Expo TaskManager dependente de GMS para um serviço foreground nativo customizado, garantindo rastreamento confiável de percursos em background em LineageOS, GrapheneOS e outras variantes Android sem Google. O Bikel Bot ganhou uma arquitetura dual-pocket com coleta autônoma de eCash via Cashu nutzaps. As v1.4.3 e v1.4.2 corrigem sincronização do rastreamento em background para ambientes Android não padrão, e o app adiciona toggles para pontos de mapa de bicicletários no OSM.

Sprout adiciona suporte a NIP-01, NIP-23 e NIP-33

Sprout, uma plataforma de comunicação da Block com um relay Nostr embutido, lançou a desktop/v0.1.0-rc7 em 6 de abril. Nesta semana a equipe adicionou suporte a artigos kind 30023 de NIP-23 (Long-form Content), eventos parameterized replaceable NIP-33 com substituição identificada por tag d, e notas de texto kind 1 e listas de follows kind 3 de NIP-01/NIP-02. O release também adiciona um sistema adaptativo de tema de IDE com 54 temas, polimento na UX do histórico de workflows e execuções de agentes, e uma limpeza da barra lateral de membros.

mesh-llm v0.56.0 lança protocolo distribuído de configuração

mesh-llm, um sistema distribuído de inferência de LLM que usa pares de chaves Nostr para identidade de nó, lançou a v0.56.0 em 7 de abril. O release adiciona um protocolo distribuído de configuração com semântica de ownership, quantização assimétrica de cache KV (chaves Q8_0 com valores Q4) para reduzir uso de memória, armazenamento em keychain do SO para keystores de identidade, streaming suave de chat com fila de mensagens, e correções para layout em tela cheia e divisão de cache KV com flash attention.

Nostr VPN lança suporte a exit nodes e empacotamento para Umbrel

Nostr VPN, uma VPN peer-to-peer que usa relays Nostr para sinalização e WireGuard para túneis criptografados, lançou seis releases da v0.3.0 até a v0.3.6 nesta semana. O ciclo v0.3.x adiciona suporte a exit node no Windows e macOS, permitindo que peers roteiem tráfego de internet por outros nós da rede. A propagação de invites e aliases agora sincroniza sobre Nostr, para que usuários possam compartilhar acesso à rede sem coordenação fora de banda. Os releases adicionam empacotamento para Umbrel para deployment self-hosted, NAT punch-through usando endpoints públicos memorizados, limpeza automática de exit nodes obsoletos e uma especificação de protocolo publicada. O projeto também estabilizou o tratamento de rotas no macOS com rotas padrão auto-recuperáveis e reparo de underlay, e adicionou uma build Android via Tauri. Há builds disponíveis para macOS (Apple Silicon e Intel), Linux (AppImage e .deb), Windows e Android.

Nymchat reverte Marmot e lança chats de grupo NIP-17 aprimorados

Nymchat, o cliente de chat com suporte a MLS, lançou 14 releases da v3.56.261 até a v3.58.274. A mudança mais significativa é uma guinada de protocolo: a v3.57.261 adicionou chats de grupo Marmot MLS, mas a v3.58.268 reverteu de volta para NIP-17 porque o suporte multi-device do Marmot ainda não está concluído, o que causava problemas na sincronização do estado do chat de grupo entre dispositivos. A v3.58.271 introduz chats de grupo NIP-17 aprimorados com chaves efêmeras rotativas para todas as mensagens, projetadas para impedir ataques de timing e correlação. A semana também trouxe um sistema de friends com controle granular de settings (v3.58.262), sincronização de mensagens de chat em grupo MLS em settings criptografadas do app, e múltiplas correções de conectividade com relay.

nak v0.19.5 adiciona multi-server Blossom e publicação por outbox

nak, o toolkit de linha de comando Nostr do fiatjaf, lançou a v0.19.5. O comando blossom agora aceita múltiplas flags --server para fazer upload para vários servidores Blossom em uma só chamada. Um novo comando key expande chaves parciais preenchendo com zeroes à esquerda. O comando event ganha uma flag --outbox para publicar eventos pelo modelo outbox, e fetch agora sai com código de erro quando nenhum event é retornado.

Em desenvolvimento

White Noise adiciona previews com thumbhash e bridge de registro de push

White Noise, o mensageiro privado construído sobre o protocolo Marmot, mergeou cinco PRs. O PR #549 substitui previews de imagem com blurhash por thumbhash, um algoritmo mais novo que produz imagens placeholder mais nítidas com payload menor (normalmente abaixo de 30 bytes contra cerca de 50-100 bytes do blurhash), preservando a proporção e a distribuição de cores da imagem original. Blurhash permanece como fallback para conteúdo mais antigo. O PR #548 atualiza whitenoise-rs e adiciona a bridge de registro de push MIP-05, conectando ao cliente o trabalho de spec de push notifications da semana passada. O PR #493 adiciona paginação baseada em cursor para mensagens de chat, substituindo a estratégia anterior de carregamento por uma abordagem guiada por scroll.

Route96 adiciona configuração dinâmica de labels e limpeza zero-egress

Route96, o servidor de mídia Blossom do v0l, mergeou três PRs. O PR #80 adiciona configuração dinâmica de modelo de labels via a admin API, permitindo que operadores troquem modelos de classificação de conteúdo sem reiniciar o servidor. O PR #82 adiciona campos de configuração de labels à admin UI. O PR #79 adiciona uma política de limpeza de arquivos zero-egress que remove automaticamente arquivos que nunca foram baixados, reduzindo custos de armazenamento para operadores.

Snort lança endurecimento de segurança e invoices de pagamento para DVM

Snort, o cliente web, lançou dois releases nesta semana junto com uma auditoria de segurança abrangente. As correções incluem verificação de assinatura Schnorr, proteção contra falsificação de mensagens de relay em NIP-46 (impedindo que atacantes injetem requests de assinatura por relays comprometidos), melhorias na criptografia de PIN e remoção da confiança em delegação NIP-26. Os ganhos de desempenho vêm de verificação Schnorr em lote em WASM, rotas lazy-loaded, traduções pré-compiladas e eliminação da verificação dupla por event. O PR #618 adiciona exibição de invoice exigindo pagamento para kind 7000 de NIP-90 (Data Vending Machine), de modo que quando um DVM responde com uma exigência de pagamento, o Snort renderiza a invoice Lightning diretamente no feed.

Damus melhora compactação do LMDB

Damus, o cliente iOS, mergeou o PR #3719 adicionando compactação automática do LMDB em um cronograma, evitando que o banco de dados local cresça sem limites ao longo do tempo. O PR #3663 melhora o BlurOverlayView para que pareça protetor em vez de quebrado.

Captain’s Log adiciona indexação de tags e sincronização de notas

Captain’s Log (Comet), a ferramenta Nostr-native de escrita long-form da Nodetec, mergeou quatro PRs nesta semana. O PR #156 adiciona indexação de tags e suporte a sync entre notas, o PR #157 refatora a sincronização de notas e o tratamento de tags, e o PR #159 corrige a sync de notas enviadas para a lixeira para que notas deletadas permaneçam deletadas entre dispositivos.

Relatr v0.2.x redesenha sistema de plugins com marketplace de validadores nativo do Nostr

Relatr, um motor de pontuação de Web of Trust que calcula rankings de confiança com base na distância do grafo social e em validadores configuráveis, lançou a família v0.2.x com um redesenho completo do sistema de plugins. Validadores agora são escritos em Elo, uma linguagem funcional portátil de expressões bifurcada para suportar capacidades em múltiplas etapas orquestradas pelo host (consultas Nostr, buscas no grafo social, resolução NIP-05). Plugins são publicados como eventos Nostr kind 765, tornando a distribuição nativa da rede de relays. Um novo plugin marketplace permite que operadores descubram, instalem e ponderem validadores a partir do navegador, com um CLI (relo) para autoria e publicação local. A arquitetura é sandboxed: plugins só podem invocar capacidades que o host fornece explicitamente, então um validador malicioso não pode escapar de seu escopo definido. Instâncias do Relatr agora podem ser gerenciadas a partir do site, com visibilidade total sobre quais plugins compõem o algoritmo de pontuação e seus pesos individuais.

Shopstr melhora navegação mobile e controle de acesso

Shopstr, o marketplace Nostr-native para compra e venda com Bitcoin, publicou 158 commits nesta semana entre seu app principal e o projeto complementar Milk Market. As correções incluem melhorias no layout mobile de comunidades, comportamento de fechar menus ao navegar e auto-close de dropdowns. Rotas protegidas não podem mais ser acessadas por URL direta sem login, e a lógica de correspondência de slug agora lida corretamente com múltiplas correspondências exatas.

Pollerama adiciona notificações, busca de filmes e UI de avaliação

Pollerama, um app de enquetes, surveys e rating social construído sobre Nostr, adicionou notificações de threads, um recurso de busca de filmes e uma reformulação da UI de avaliação. O release também corrige problemas de carregamento do feed e atualiza versões de dependências.

Purser constrói daemon de pagamentos Nostr-native com criptografia Marmot

Purser, um daemon de pagamentos Nostr-native projetado como substituto do Zaprite, mergeou nove PRs nesta semana enquanto desenvolvia sua arquitetura central. O projeto usa MLS do Marmot via MDK para mensagens criptografadas entre merchant e customer, com Strike e Square como provedores de pagamento. Nesta semana entraram carregamento de config e catálogo, validação de schema de mensagens, a camada de comunicação MDK, implementações dos provedores Strike e Square, um polling engine, limitação anti-spam de taxa, persistência de pagamentos pendentes e o pipeline de processamento de pedidos. Todos os 99 testes agora exercitam operações reais de MLS do mdk-core depois que a equipe removeu MLS mockado em favor de criptografia real em modo local.

Vector refatora anexos de DM e adiciona edição de perfil

Vector, o mensageiro Nostr focado em privacidade construído com Tauri, mergeou o PR #55 refatorando o frontend. A decriptação e o salvamento de anexos de DM foram movidos para a biblioteca vector-core, e o app agora suporta edição de perfil. A flag de cancelamento de upload foi corretamente conectada via TauriSendCallback, e callbacks não usados de preview de anexos foram removidos.

Trabalho de Protocolo e Spec

Atualizações de NIPs

Mudanças recentes no repositório de NIPs:

Mergeado:

NIP-58 (Badges): Profile Badges passam para kind 10008, Badge Sets para kind 30008 (PR #2276): Migra Profile Badges de kind 30008 para kind 10008 (um event replaceable, um por pubkey) e introduz kind 30008 para Badge Sets. Antes, Profile Badges usavam o mesmo kind (30008) que as definições de Badge, tornando-os eventos parameterized replaceable identificados por uma tag d. O novo kind 10008 é um event replaceable simples: um por pubkey, sem necessidade de tag d. Clientes consultam um único event replaceable por usuário em vez de varrer eventos parameterized replaceable. O Amethyst v1.07.3 já sai com essa migração.
NIP-34 (Git Stuff): adicionar follow lists relacionadas a git (PR #2130): Adiciona convenções de follow lists para tracking de repositórios e issues do NIP-34. Usuários publicam conjuntos de follows kind 30000 com tags d como git-repos ou git-issues contendo referências de tag a a repositórios (kind 30617) que querem acompanhar. Clientes podem se inscrever nesses conjuntos de follows para mostrar atividade de repositório no feed de um usuário, de forma semelhante a como listas de contatos kind 3 funcionam para pubkeys.

PRs abertos e discussões:

NIP-AC: P2P Voice and Video Calls over WebRTC (PR #2301): Expande o NIP-100 original (implementado pelo 0xChat) com três mudanças: migração para criptografia NIP-44 encapsulada em gift wraps NIP-59 para eliminar vazamentos de metadados, um workflow WebRTC especificado para configuração de chamadas de voz e vídeo (offer, answer, ICE candidates), e um modelo mesh de chamadas em grupo em que cada peer estabelece uma conexão WebRTC direta com todos os demais peers. A spec não é backwards-compatible com o NIP-100. O Amethyst já está desenvolvendo contra ela, com uma suíte de testes para a máquina de estados de chamadas (PR #2143) e tratamento de ofertas de chamada antigas (PR #2164) entrando nesta semana.
NIP-340 (FROST Quorum) (PR #2299): Propõe convenções para assinatura threshold FROST (Flexible Round-Optimized Schnorr Threshold) no Nostr. FROST permite que um grupo de signers controle coletivamente uma identidade Nostr em que qualquer conjunto t-of-n de membros pode assinar events sem reconstruir a chave privada completa. O NIP define como coordenar rodadas de assinatura, distribuir key shares e publicar events assinados por threshold, apoiando-se no trabalho do signer Igloo do projeto FROSTR.
NIP-5D (Nostr Web Applets) (PR #2303): Define um protocolo postMessage para aplicações web sandboxed (“napplets”) executadas em iframes se comunicarem com uma aplicação hospedeira (“shell”). O shell fornece ao napplet assinatura Nostr, acesso a relay e contexto do usuário por meio de uma API estruturada de mensagens, enquanto o sandbox do iframe impede acesso direto a chaves. Isso estende o modelo de hospedagem de sites estáticos de NIP-5A em direção a aplicações interativas que podem ler e escrever events Nostr. O NIP está em desenvolvimento ativo com uma implementação runtime funcional.
NIP-5C (Scrolls) (PR #2281): Renomeado da proposta anterior NIP-A5. Define convenções para publicar e descobrir programas WebAssembly no Nostr. Binários WASM são armazenados como events Nostr, e clientes podem baixá-los e executá-los em um runtime sandboxed. Um demo app mostra scrolls executando no browser, com programas de exemplo publicados como events Nostr que qualquer cliente pode buscar e executar.
NIP-85 (Trusted Assertions): esclarecimentos (PR #2304): Torna mais precisa a linguagem da spec sobre múltiplas chaves e relays por provedor de serviço, esclarecendo como clientes devem lidar com assertions de provedores que operam em várias pubkeys ou endpoints de relay.
NIP-24 (Extra Metadata Fields): published_at para events replaceable (PR #2300): Generaliza a tag published_at de NIP-23 (Long-form Content) para todos os events replaceable e addressable. A tag é apenas de exibição: se published_at for igual a created_at, clientes mostram o event como “created” naquele momento; se forem diferentes (porque o event foi atualizado), clientes podem mostrar “updated” no lugar. Isso permite que perfis kind 0 exibam datas de “joined at” e que outros events replaceable preservem seu timestamp original de publicação ao longo de atualizações. Uma proposta complementar de NIP-51 (PR #2302) adiciona a mesma tag a list events.
NIP-59 (Gift Wrap): kind efêmero de gift wrap (PR #2245): Adiciona kind 21059 como contraparte efêmera do gift wrap kind 1059 existente. Events efêmeros (kinds 20000-29999) seguem a semântica de NIP-01: relays não são obrigados a armazená-los e podem descartá-los após a entrega. Isso permite que aplicações enviem mensagens em gift wrap que desaparecem dos relays depois de entregues, reduzindo exigências de armazenamento para mensagens de alto volume e mantendo o mesmo modelo de criptografia em três camadas das DMs regulares NIP-17.

OpenSats anuncia a décima sexta rodada de grants para Nostr

OpenSats anunciou sua décima sexta rodada de grants para Nostr em 8 de abril, financiando quatro grants inéditos e uma renovação. Amethyst Desktop recebe financiamento para que o contribuidor Robert Nagy construa um app desktop standalone sobre os módulos Quartz e Commons, levando o conjunto de recursos do cliente Android para interfaces orientadas a mouse com conexões persistentes a relay. Nostr Mail recebe financiamento para construir um sistema completo de email sobre Nostr usando events kind 1301 encapsulados em gift wraps NIP-59, com um cliente Flutter e servidores bridge SMTP para compatibilidade com Gmail/Outlook. Nostrord recebe financiamento para um cliente de grupos baseado em relay NIP-29 em Kotlin Multiplatform com mensagens em grupo ao estilo Discord, moderação e threads. Nurunuru recebe financiamento para construir uma versão nativa iOS do cliente Nostr japonês, modelado sobre a interface familiar do LINE, com login biométrico baseado em passkey para onboarding. HAMSTR recebeu renovação de grant (financiado pela primeira vez na décima primeira rodada).

NIP Deep Dive: NIP-17 (Private Direct Messages)

NIP-17 define o padrão atual para mensagens diretas privadas no Nostr. Ele substitui o esquema mais antigo NIP-04 (Encrypted Direct Messages), que vazava metadados (remetente, destinatário e timestamps ficavam todos visíveis nos relays) e usava uma construção de criptografia mais fraca. O NIP-17 combina NIP-44 (Encrypted Payloads) para criptografia com NIP-59 (Gift Wrap) para proteção de metadados, criando um sistema em três camadas em que relays não conseguem ver quem está falando com quem.

O protocolo usa três kinds de event empilhados um dentro do outro. A camada mais interna é a mensagem em si, um event kind 14 sem assinatura:

{
 "id": "a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890",
 "pubkey": "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876",
 "created_at": 1744108800,
 "kind": 14,
 "tags": [
 ["p", "f1a2b3c4d5e6f7890123456789abcdef01234567890abcdef1234567890abcdef", "wss://inbox.example.com"],
 ["subject", "Project update"]
 ],
 "content": "The new relay config is deployed. Let me know if you see any issues.",
 "sig": ""
}

O event kind 14 é deliberadamente sem assinatura (sig vazio). A spec descreve isso como fornecendo negabilidade, mas na prática a proteção é limitada. O selo kind 13 que encapsula o rumor é assinado pela chave real do remetente. Um destinatário pode mostrar o selo assinado a um terceiro, provando que o remetente se comunicou com ele, mesmo sem revelar o conteúdo da mensagem. Com provas de conhecimento zero, um destinatário pode provar o conteúdo exato da mensagem sem revelar sua própria chave privada. O rumor sem assinatura é como uma carta não assinada dentro de um envelope assinado: a assinatura do envelope liga o remetente ao conteúdo. Negabilidade real exigiria autenticação simétrica (como os HMACs do Signal), o que é incompatível com o modelo descentralizado de relay do Nostr, no qual mensagens precisam ser autoautenticáveis. Os pontos fortes reais do NIP-17 são privacidade de metadados e sigilo de conteúdo, não negabilidade.

Essa mensagem sem assinatura é então encapsulada em um selo kind 13, que é assinado pelo remetente real e criptografado com NIP-44 para o destinatário:

{
 "id": "b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1",
 "pubkey": "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876",
 "created_at": 1744022400,
 "kind": 13,
 "tags": [],
 "content": "<nip44-encrypted kind 14 payload>",
 "sig": "e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4"
}

O selo não tem tags, então mesmo que seja decriptado ele não revelaria o destinatário. O selo é assinado pela chave real do remetente, o que permite ao destinatário autenticar a mensagem verificando que a pubkey do selo corresponde à pubkey do kind 14 interno.

O selo então é encapsulado em um gift wrap kind 1059, assinado por uma chave aleatória descartável e endereçado ao destinatário:

{
 "id": "c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2",
 "pubkey": "9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba",
 "created_at": 1744065600,
 "kind": 1059,
 "tags": [
 ["p", "f1a2b3c4d5e6f7890123456789abcdef01234567890abcdef1234567890abcdef"]
 ],
 "content": "<nip44-encrypted kind 13 payload>",
 "sig": "fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210"
}

A pubkey do gift wrap é uma chave aleatória gerada apenas para esta mensagem, e o created_at é randomizado em até dois dias no passado. Essa é a camada mais externa que os relays realmente veem: uma mensagem de uma pubkey desconhecida endereçada ao destinatário, com um timestamp que não reflete quando a mensagem foi de fato enviada. O timestamp randomizado protege contra análise posterior de events armazenados, mas um adversário conectado ativamente aos relays ainda pode observar quando o gift wrap apareceu pela primeira vez, então essa defesa é limitada a observadores passivos que consultam dados de relay mais tarde. Como a pubkey é aleatória e o timestamp é falso, os relays não conseguem determinar o remetente real. Para ler a mensagem, o destinatário decripta o gift wrap usando sua própria chave e a pubkey aleatória, encontra o selo dentro dele, decripta o selo usando sua própria chave e a pubkey do remetente obtida do selo, e encontra a mensagem kind 14 dentro.

O NIP-17 não fornece forward secrecy. Todas as mensagens são criptografadas usando o par de chaves estático do Nostr (via derivação de chave do NIP-44 a partir das chaves do remetente e do destinatário). Se uma chave privada for comprometida, toda mensagem passada e futura criptografada para essa chave poderá ser decriptada. Esse é um tradeoff deliberado: como a criptografia depende apenas do nsec, um usuário que faz backup do seu nsec pode recuperar todo o histórico de mensagens a partir de qualquer relay que ainda armazene os gift wraps. Protocolos como MLS (usado por Marmot) fornecem forward secrecy por meio de material de chave rotativo, mas ao custo de exigir sincronização de estado e tornar impossível a recuperação histórica de mensagens após a rotação de chave.

O NIP-17 também define kind 15 para mensagens com arquivos criptografados, adicionando tags file-type, encryption-algorithm, decryption-key e decryption-nonce para que o destinatário possa decriptar um arquivo anexado que foi criptografado com AES-GCM antes do upload para um servidor Blossom. O kind 10050 é usado para publicar a lista preferida de relays de DM do usuário, para que remetentes saibam onde entregar gift wraps. O conjunto de tags pubkey + p em uma mensagem define uma sala de chat; adicionar ou remover um participante cria uma nova sala com histórico limpo.

As implementações cobrem a maior parte dos clientes principais. nospeak usa NIP-17 para todas as mensagens um a um. Flotilla usa NIP-17 para suas DMs com proof-of-work. Amethyst, Primal, Nostur, Damus, noStrudel e Coracle implementam NIP-17 como seu protocolo principal de DM. A spec também suporta mensagens que desaparecem ao definir uma tag expiration no gift wrap.

NIP Deep Dive: NIP-46 (Nostr Remote Signing)

NIP-46 define um protocolo para separar a chave privada do usuário da aplicação cliente. Em vez de colar um nsec em um app web, o usuário roda um signer remoto (também chamado de “bunker”) que mantém a chave privada e responde a requests de assinatura por relays Nostr. O cliente nunca vê a chave privada. Isso reduz a superfície de ataque: um cliente comprometido pode solicitar assinaturas, mas não consegue extrair a chave em si.

O protocolo usa kind 24133 tanto para requests quanto para responses, criptografados com NIP-44 (Encrypted Payloads). Um cliente gera um client-keypair descartável para a sessão e se comunica com o signer remoto por mensagens criptografadas em NIP-44 marcadas com as pubkeys um do outro. Aqui está um request de assinatura de um cliente para um signer remoto:

{
 "id": "aa11bb22cc33dd44ee55ff6677889900aabbccdd11223344556677889900aabb",
 "pubkey": "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86",
 "created_at": 1744108800,
 "kind": 24133,
 "tags": [
 ["p", "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52"]
 ],
 "content": "<nip44-encrypted JSON-RPC request>",
 "sig": "1122334455667788990011223344556677889900aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff0011223344556677"
}

O content criptografado contém uma estrutura semelhante a JSON-RPC:

{
 "id": "random-request-id-1",
 "method": "sign_event",
 "params": ["{\"kind\":1,\"content\":\"Hello from remote signing\",\"tags\":[],\"created_at\":1744108800}"]
}

O signer remoto decripta o request, o apresenta ao usuário para aprovação (ou aprova automaticamente com base nas permissões configuradas), assina o event com a chave privada do usuário e devolve o event assinado em uma response:

{
 "id": "bb22cc33dd44ee55ff6677889900aabb11223344556677889900aabbccddeeff",
 "pubkey": "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52",
 "created_at": 1744108801,
 "kind": 24133,
 "tags": [
 ["p", "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86"]
 ],
 "content": "<nip44-encrypted JSON-RPC response>",
 "sig": "aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899"
}

Conexões podem ser iniciadas de qualquer lado. Um signer remoto fornece uma URL bunker:// contendo sua pubkey e informações de relay. Um cliente fornece uma URL nostrconnect:// com sua pubkey de cliente, relays e um secret para verificação da conexão. O parâmetro secret impede connection spoofing: apenas a parte que recebeu a URL fora de banda pode completar o handshake.

Oito métodos são definidos: connect para estabelecer a sessão, sign_event para assinar events, get_public_key para obter a pubkey do usuário, ping para keepalive, nip04_encrypt/nip04_decrypt para criptografia legada, nip44_encrypt/nip44_decrypt para criptografia atual, e switch_relays para gerenciamento de relay. A migração de relay é tratada pelo signer remoto, que pode mover a conexão para novos relays ao longo do tempo sem quebrar a sessão.

Clientes solicitam capacidades específicas no momento da conexão por meio de um sistema de permissões. Uma string de permissão como nip44_encrypt,sign_event:1,sign_event:14 solicita acesso à criptografia NIP-44 e acesso de assinatura apenas para events kind 1 e kind 14. O signer remoto pode aceitar, rejeitar ou modificar essas permissões. Isso significa que um cliente web para ler e publicar notas talvez receba apenas permissão sign_event:1, enquanto um cliente de DM pode também receber permissões sign_event:14 e nip44_encrypt.

Amber implementa NIP-46 no Android, e sua v6.0.0-pre1 nesta semana adiciona chaves de assinatura por conexão para isolamento entre clientes. nsec.app (antigo Nostr Connect) fornece um bunker baseado na web. nostr-tools inclui BunkerSigner para clientes JavaScript, e o PR #530 da semana passada adicionou skipSwitchRelays para gerenciamento manual de relay. O protocolo também suporta auth challenges: quando um signer remoto precisa de autenticação adicional (senha, biometria ou token de hardware), ele responde com uma auth_url que o cliente abre no browser para que o usuário conclua o processo.

Isso é tudo por esta semana. Está construindo algo ou tem novidades para compartilhar? Envie uma DM para nós no Nostr ou nos encontre em nostrcompass.org.

Nostr Compass #16

Wed, 01 Apr 2026 00:00:00 +0000

Bem-vindo de volta ao Nostr Compass, seu guia semanal sobre o Nostr.

Esta semana: Amethyst lança v1.07.0 com notas fixadas, gerenciamento de relay via NIP-86 e suporte a NIP-62 Request to Vanish. NIP-5A (Static Websites) é mergeado no repositório de NIPs, definindo como hospedar sites sob pares de chaves Nostr usando armazenamento Blossom. Flotilla lança v1.7.0 com salas de voz, login com email e senha e DMs com proof-of-work. White Noise corrige churn de relays na v2026.3.23, nospeak lança sua 1.0.0 como mensageiro criptografado sem cadastro. Nymchat adota Marmot para chats de grupo criptografados com MLS com fallback para NIP-17. Calendar by Form* chega à v1.0.0 com listas privadas de calendário e importação ICS, Amber adiciona recuperação por mnemônica e whitelist de relay auth NIP-42, e a spec Marmot move KeyPackages para eventos endereçáveis enquanto reforça o formato de push notifications MIP-05.

Notícias

Amethyst lança notas fixadas, gerenciamento de relay e Request to Vanish

Amethyst, o cliente Android mantido por vitorpamplona, lançou seis releases em três dias, da v1.07.0 até a v1.07.5. O conjunto principal de recursos cobre seis superfícies de protocolo: notas fixadas, uma tela dedicada de feed de enquetes, suporte a NIP-62 (Request to Vanish) para solicitar exclusão completa de eventos dos relays, NIP-86 (Relay Management API) de dentro do cliente, avaliações NIP-66 (Relay Discovery and Liveness Monitoring) na tela de informações de relay, e exibição de informações de membros NIP-43 (Relay Access Metadata and Requests).

NIP-86 define uma interface JSON-RPC para operadores de relay, permitindo que clientes enviem comandos administrativos como banir pubkeys, permitir pubkeys e listar usuários banidos por uma API padronizada. O Amethyst agora expõe isso diretamente em sua UI de gerenciamento de relay, para que usuários que rodam seus próprios relays possam administrá-los a partir do mesmo cliente que usam para postar. O PR #2039 substitui o antigo diálogo de entrada em hex para pubkeys de ban e allow por um diálogo interativo de busca de usuários.

A v1.07.2 adicionou uploads pelo teclado de GIF e corrigiu uma regressão de assinatura em que respostas de rejeição do Amber estavam sendo interpretadas incorretamente porque versões antigas do Amber retornavam uma string vazia para o campo rejected (PR #2042). A v1.07.5 corrige um crash ao fazer upload de imagem. As releases v1.06.2 e v1.06.3, mais cedo na mesma semana, adicionaram um seletor de tipo de enquete para escolha única versus múltipla, drag-to-seek em barras de progresso de vídeo e melhorias em postagem anônima.

NIP-5A é mergeado, trazendo sites estáticos para o Nostr

NIP-5A (Static Websites) foi mergeado via PR #1538, definindo como hospedar sites estáticos sob pares de chaves Nostr. A spec usa dois kinds de evento: kind 15128 para um site raiz, um por pubkey, e kind 35128 para sites nomeados identificados por uma tag d. Cada manifesto mapeia caminhos de URL para hashes SHA256, com tags opcionais server apontando para hosts de armazenamento Blossom onde os arquivos reais vivem.

O modelo de hospedagem funciona assim: o autor de um site constrói um site estático, faz upload dos arquivos para um ou mais servidores Blossom e então publica um evento de manifesto assinado que mapeia caminhos para hashes de conteúdo. Um servidor host recebe requisições web, resolve a pubkey do autor a partir do subdomínio, busca o manifesto na lista de relays NIP-65 do autor e serve os arquivos baixando os blobs correspondentes do Blossom. O site permanece sob controle do autor porque apenas aquela chave pode assinar um manifesto atualizado. O servidor host é substituível porque qualquer servidor que entenda NIP-5A pode servir o mesmo site a partir do mesmo manifesto.

A spec se apoia em infraestrutura que já existe. nsite, a implementação de referência do host NIP-5A construída por lez, e nsite-manager, a UI de gerenciamento do hzrd149, já estavam em funcionamento antes do merge do NIP. O merge torna oficiais os kinds de evento e as regras de resolução de URL, dando às segundas e terceiras implementações um alvo estável.

White Noise corrige churn de relays e expande controles do cliente

White Noise, o mensageiro privado construído sobre o protocolo Marmot, lançou v2026.3.23 em 25 de março. O trabalho principal é estabilidade de relay. O login não espera mais que toda publicação de lista de relays termine antes de avançar, porque a publicação agora usa lógica de quórum e tenta o restante em background. Fetches e publishes pontuais usam sessões efêmeras com escopo de relay em vez de permanecer no pool de longa duração, sessões restauradas recuperam seu caminho de refresh de grupo após o startup, e o app agora expõe diagnósticos de relay e inspeção de estado de relay via PR #495 e PR #502.

O mesmo release muda o comportamento das conversas. O PR #468 adiciona threading de respostas NIP-C7 com tags q e referências nostr:nevent, os PR #471 e PR #512 mantêm mensagens deletadas visíveis como placeholders de exclusão em vez de removê-las silenciosamente, o PR #478 adiciona um fluxo in-app de bug report usando relatórios anônimos NIP-44 (Encrypted Payloads), e o PR #486 adiciona chat de suporte diretamente no cliente. Controles de mensagens voltados ao usuário também chegaram na mesma janela: o PR #532 arquiva chats, o PR #541 adiciona mute e unmute com durações configuráveis, e o PR #535 adiciona configurações de notificação. O PR #539 é trabalho preparatório para registro de push, conectando registro APNs no iOS e detecção de Play Services no Android para que o registro seja construído sobre isso. No backend, o MDK (Marmot Development Kit) adicionou primitivas de push notification MIP-05 e um builder de notification request (PR #235, PR #238), enquanto whitenoise-rs adicionou persistência de registro de push notification (PR #688), correções de cancelamento de tarefas em background (PR #696) e recuperação de key package no startup (PR #693).

Nostr VPN chega à v0.3.0 com roster sync e invite v2

Seguindo a cobertura do lançamento da semana passada, nostr-vpn, a VPN peer-to-peer que usa relays Nostr para sinalização e WireGuard para túneis criptografados, continuou seu ritmo rápido de releases, lançando versões até a v0.3.3. O bump de versão traz duas mudanças incompatíveis: o formato de invite muda para v2 (a 0.3.0 ainda consegue importar invites v1, mas builds antigos não conseguem importar invites v2), e um roster sync assinado por admin foi adicionado ao protocolo de sinalização. Pares em versões misturadas ainda conseguem conectar-se na camada mesh, mas peers antigos não participam da sincronização de roster.

A adição de roster sync inicia o movimento em direção a uma rede gerenciada. Um nó admin agora pode enviar mudanças de associação a todos os peers, de modo que adicionar ou remover um dispositivo da mesh não exige que cada peer atualize manualmente sua configuração. As releases v0.2.x da mesma semana trataram problemas específicos de deployment: da v0.2.22 até a v0.2.28 corrigiram gerenciamento de serviço no Windows, adicionaram scripts de build para Android e refinaram o fluxo de LAN pairing.

nospeak é lançado como um mensageiro privado 1.0

nospeak, um mensageiro privado construído sobre Nostr, lançou sua 1.0.0 em 27 de março. O projeto inclui conversas um a um e em grupo, gerenciamento de contatos e uma arquitetura self-hostable. Chats um a um usam NIP-17 (Private Direct Messages), que combina NIP-59 (Gift Wrap) com NIP-44 (Encrypted Payloads) para esconder o remetente dos relays. Para mídia, arquivos são criptografados do lado do cliente com AES-256-GCM antes do upload para servidores Blossom. O release também é distribuído como imagem de container para self-hosting.

Flotilla, o cliente estilo Discord do hodlbod baseado em NIP-29 (Relay-based Groups) construído em torno do modelo “relays as groups”, lançou v1.7.0 e v1.7.1 em 30 e 31 de março. O principal recurso são salas de voz, contribuídas por mplorentz. Usuários agora podem entrar em chamadas de voz dentro de canais de grupo, com um diálogo de entrada (PR #109) que permite selecionar um dispositivo de entrada de áudio e escolher entre entrar na chamada de voz ou apenas visualizar o chat de texto. O diálogo resolve um problema de UX da iteração anterior: entrar em uma sala com voz antes forçava a ativação do microfone mesmo quando o usuário queria apenas ler mensagens ou verificar configurações da sala.

O mesmo release adiciona login com email e senha como alternativa à autenticação baseada em chave Nostr, proof-of-work em DMs, edição de DMs, onboarding e settings de relay redesenhados, detecção de suporte a Blossom via supported_nips, badges de notificação melhorados, fallback de push notification no Android e correções de upload de arquivos no Android. A v1.7.1 vem em seguida com uma correção para fallback de registro pomade ao usar um signer offline.

Hodlbod também está construindo Caravel, um gerenciador de hospedagem e dashboard para relays zooid, que registrou 40 commits nesta semana em desenvolvimento inicial.

Nymchat lança chats de grupo impulsionados por Marmot

Nymchat (também conhecido como NYM, Nostr Ynstant Messenger), o cliente de chat efêmero com bridge para Bitchat, anunciou que todos os novos chats de grupo agora usam o protocolo Marmot para mensagens criptografadas com MLS. A integração usa kinds 443, 444 e 445 para key packages, mensagens de welcome e mensagens de grupo, respectivamente, fornecendo forward secrecy, segurança pós-comprometimento e zero vazamento de metadados. Se um destinatário não puder usar MLS, o Nymchat faz fallback para seu caminho anterior de chat em grupo NIP-17 (Private Direct Messages), que ainda é end-to-end encrypted, mas não tem as propriedades de ratchet-tree do MLS.

As séries v3.55 e v3.56 desta semana se concentraram em casos de borda de chat em grupo: carregamento em novos dispositivos, comportamento de saída, roteamento de notificações e contagens de badge de não lidos. O mesmo ciclo também corrigiu uma vulnerabilidade XSS por HTML não escapado e adicionou bloqueio de palavras-chave e frases estendido a apelidos de usuários. Isso faz do Nymchat mais um cliente Marmot a se juntar a White Noise e OpenChat, ampliando o conjunto de apps que podem trocar mensagens de grupo criptografadas com MLS sobre o mesmo protocolo.

Lançamentos

Calendar by Form* v1.0.0

Calendar by Form*, o app de calendário descentralizado construído sobre NIP-52 (Calendar Events), chegou à v1.0.0 em 29 de março. O release adiciona listas privadas de calendário usando eventos Nostr criptografados (kind 32123) com self-encryption NIP-44 (Encrypted Payloads), para que usuários possam organizar eventos em coleções privadas sem expor o agrupamento aos relays. O mesmo release adiciona tratamento de intent ICS para importar dados de calendário de outras aplicações e solicitações de convite para compartilhar eventos entre usuários.

Amber v5.0.2 até v5.0.4

Amber, o app assinador NIP-55 (Android Signer Application), lançou três point releases: v5.0.2, v5.0.3 e v5.0.4. A adição mais visível é login por frase de recuperação mnemônica (PR #358), que permite que usuários restaurem seu signer a partir de uma seed phrase BIP39 em vez de exigir a string bruta nsec ou ncryptsec. O PR #357 adiciona uma whitelist de relay auth NIP-42, para que usuários possam restringir quais relays estão autorizados a solicitar autenticação do cliente. O PR #353 adiciona seleção de escopo de criptografia para permissões de decrypt, permitindo conceder acesso apenas a NIP-04 ou apenas a NIP-44 em vez de uma permissão ampla. A v5.0.4 corrige um bug em que a rejeição não respeitava permissões com escopo de encrypt e decrypt e melhora o desempenho ao receber múltiplas requisições de bunker.

Aegis v0.4.0

Aegis, o signer multiplataforma, lançou v0.4.0 em 26 de março. O release adiciona modos de autorização Full e Selective nas Settings e corrige múltiplos problemas de leitura de QR code. Commits posteriores d4f799f, 3313af9, 3b214e4 e e4f40b6 continuam o mesmo trabalho com controles de seleção em lote, estatísticas reutilizáveis de seleção em lote, APIs set-all-groups selection e estatísticas de uso por permissão na página de permissões do app.

Schemata v0.2.7 até v0.3.0

Schemata, as definições JSON Schema para validar kinds de evento Nostr, lançou quatro releases da v0.2.7 até a v0.3.0 com 21 PRs mergeados. A v0.3.0 traz correções de consistência de padrões em URLs de relay, IDs hex, tipos MIME e strings BOLT-11 (PR #126), centralização de padrões de URL de relay (PR #117), schemas de tipo base bech32 NIP-19 (PR #118), e validação para eventos spell kind 777 (PR #125). O pipeline de release agora publica uma nota kind 1 no Nostr a cada release (PR #120), então o projeto se anuncia pelo próprio protocolo que valida. O Schemata agora suporta uma dúzia de linguagens além do pacote canônico JS/TS: Rust, Go, Python, Kotlin, Java, Swift, Dart, PHP, C#/.NET, C++, Ruby e C.

Junto com o Schemata, a equipe publicou schemata-codegen, um gerador experimental de código que toma uma abordagem diferente para o mesmo problema de validação. Onde os pacotes validadores do Schemata exigem uma dependência runtime de JSON Schema, o schemata-codegen transpõe schemas diretamente para construções tipadas de linguagem nativa (typed tag tuples, kind interfaces e runtime validators), removendo a necessidade de uma biblioteca validadora em runtime. O comparativo codegen-vs-validators documenta quando cada abordagem faz sentido.

BigBrotr v6.5.0 até v6.5.4

BigBrotr, a plataforma de analytics de relay, lançou cinco releases da v6.5.0 até a v6.5.4. A v6.5.0 centraliza a validação de URL de relay com uma factory function parse_relay_url() e adiciona verificação de comprimento de URL e sanitização de path. A infraestrutura de monitoramento também recebeu correções: eventos de anúncio agora incluem tags de localização geohash (seguindo NIP-52), e proteção por timeout foi adicionada aos testes de metadados Geo/Net NIP-66 que não tinham deadline e podiam travar indefinidamente. O PR #410 faz upgrade do PostgreSQL de 16 para 18, trazendo o subsistema de async I/O e melhor throughput de WAL para o pipeline de analytics de relay.

Relay da Vertex Lab adiciona busca de perfil NIP-50

Vertex Lab, a equipe por trás do npub.world e do motor de Web of Trust Vertex, anunciou que wss://relay.vertexlab.io agora suporta NIP-50 (Search) para consultas de perfil. O NIP-50 estende o filtro padrão REQ do Nostr com um campo search, permitindo que clientes enviem consultas de full-text search a relays com suporte a indexação. Adicionar busca de perfil a um relay que já serve dados de Web of Trust significa que clientes conectados ao relay.vertexlab.io podem descobrir usuários por nome ou descrição sem um serviço de busca separado.

Hashtree v0.2.17 e v0.2.18 lançam mesh WebRTC e Iris Desktop

Hashtree, o sistema de armazenamento de blobs content-addressed do mmalmi que publica raízes de Merkle no Nostr, lançou v0.2.17 e v0.2.18 em 31 de março. Os dois releases encerram um sprint de 30 commits que adiciona três capacidades distintas. Primeiro, o crate hashtree-webrtc (renomeado para hashtree-network na v0.2.18) adiciona distribuição peer-to-peer de blobs via WebRTC com sinalização mesh unificada entre o CLI Rust, o simulation harness e o cliente TypeScript. Segundo, o pipeline de release agora constrói artefatos Windows (zip do CLI e instalador do Iris), levando a cobertura multiplataforma a macOS, Linux e Windows. Terceiro, ambos os releases empacotam o Iris Desktop 0.1.0, o cliente social Nostr do mmalmi, como assets AppImage, .deb e instalador Windows ao lado do CLI do Hashtree. O Hashtree foi coberto pela primeira vez na Newsletter #10 quando foi lançado como um armazenamento compatível com Blossom baseado em filesystem. A camada WebRTC é o primeiro passo em direção à distribuição peer-to-peer de conteúdo sem depender de servidores Blossom centralizados.

Nostr Mail Client v0.7.0 até v0.7.2

Nostr Mail Client, o cliente Flutter em estilo email construído sobre identidades Nostr, lançou v0.7.0, v0.7.1 e v0.7.2 em três dias. O trabalho de produto mais visível se concentrou em onboarding (PR #9) e edição de perfil (PR #10), peças básicas para qualquer cliente que tente apresentar o Nostr como uma mailbox. Os point releases posteriores empacotaram esse trabalho em novos builds Android e Linux.

Wisp v0.14.0 até v0.16.3

Wisp, o cliente Nostr para Android, lançou mais 13 releases da v0.14.0-beta até a v0.16.3-beta. O trabalho desta semana inclui correções de rumor JSON NIP-17 (PR #385), badges de repost em cards de galeria (PR #383), detalhes expansíveis de reações (PR #382), conjuntos persistentes de emoji (PR #381) e controles de autoplay de vídeo (PR #380). A mais recente v0.16.3-beta também corrige shortcodes de emoji customizado com hífens e tags de emoji ausentes.

Primal Android 3.0.17

Primal Android lançou 3.0.17 em 24 de março. O PR #1000 mapeia tipos de WalletException para códigos de erro em respostas NWC, dando a clientes NIP-47 informação estruturada de falha em vez de erros genéricos. O PR #995 corrige votos por zap em enquetes aparecendo como Top Zaps, e o PR #998 oculta o saldo da carteira e botões de ação quando nenhuma carteira está configurada.

OpenChat v0.2.4 até v0.3.0

OpenChat, o cliente de chat baseado em Avalonia construído sobre a stack Marmot, lançou seis releases da v0.2.4 até a v0.3.0 em quatro dias. O log de commits conta a história de um cliente preenchendo o espaço entre “Marmot funciona” e “alguém consegue realmente usar isso no dia a dia”. O relay authentication NIP-42 chegou, seguido por uma UI de seleção de relay com filtragem de eventos duplicados. Mensagens de voz ganharam pause, resume, seek e exibição de tempo. O caminho do signer foi reforçado: conexões com Amber foram corrigidas com um formato atualizado de URI NIP-46, o WebSocket faz auto-reconnect antes de enviar requests, e requisições duplicadas ao Amber agora são detectadas verificando respostas replayadas. No lado de armazenamento, Linux e macOS ganharam secure storage AES-256-GCM com chaves baseadas em arquivo, e o fetch de metadados de usuário agora usa descoberta de relay NIP-65 e faz cache dos resultados em um banco local.

Igloo Signer 1.1

Igloo, o signer threshold FROST para iOS do projeto FROSTR, lançou v1.1 em 28 de março. Assinaturas FROST (Flexible Round-Optimized Schnorr Threshold) permitem que um grupo de signers controle coletivamente um par de chaves Nostr, em que qualquer conjunto t-of-n de participantes pode assinar um evento sem que nenhuma parte individual detenha a chave privada completa. O Igloo é uma das primeiras implementações mobile dessa abordagem para Nostr.

nak v0.19.3 e v0.19.4

nak, o toolkit de linha de comando Nostr do fiatjaf, lançou v0.19.3 e v0.19.4 em 26 e 30 de março. Ambos os releases corrigem condições de panic: o PR #118 substitui strings.Split por strings.Cut para impedir um potencial acesso out-of-bounds, e o PR #119 previne a mesma classe de panic no parsing de flags do curl.

Flora v0.3.0

Flora, uma extensão Chrome para gravação e compartilhamento descentralizado de tela no Nostr, lançou v0.3.0. O release adiciona compartilhamento privado de vídeo criptografado com modos público, não listado e privado. Gravações privadas são criptografadas com AES-256-GCM e entregues aos destinatários via NIP-17 (Private Direct Messages), então a gravação nunca toca um servidor em cleartext.

YakiHonne Mobile 2.0.3

YakiHonne, o cliente Nostr mobile, lançou 2.0.3 com avaliações de relay e pedidos de entrada, respostas aninhadas expandidas, auto-tradução de notas e suporte a múltiplos relays em NWC.

Atualizações de Projetos

Zap Cooking adiciona zap polls e verificação de pagamento Branta

Zap Cooking, a plataforma de receitas e conteúdo, mergeou 11 PRs nesta semana focados em conteúdo interativo e fluxos de pagamento. O PR #277 adiciona zap polls (kind 6969), em que usuários votam enviando sats e podem ver listas de votantes com fotos de perfil. O PR #274 redesenha a UX das enquetes para que a interface de votação se encaixe mais naturalmente no feed.

O PR #276 adiciona leitura de QR code pela câmera ao fluxo Send Payment e integra Branta, um serviço de verificação que checa se um destino de pagamento é legítimo antes do envio. A Branta verifica destinos de pagamento contra phishing, troca de endereço e interceptação man-in-the-middle antes do envio. Na implementação do Zap Cooking, um nome de plataforma e logo verificados pela Branta aparecem diretamente no fluxo de pagamento, e QR codes habilitados para Branta podem carregar parâmetros branta_id e branta_secret para que a carteira possa verificar o destino a partir do próprio código escaneado.

diVine prepara o terreno para busca unificada e reforça entrega de vídeo

diVine, o cliente de vídeo short-form, passou a semana reforçando busca, navegação de feed, recuperação de playback e comportamento de upload. O PR #2540 estabelece a base para uma tela de busca unificada, com seções agrupadas para Videos, People e Tags. O PR #2623 endurece a paginação em feeds de perfil, inbox, notificações, listas discover, classic vines, busca e feeds de grid composable ao movê-los para um controlador de paginação compartilhado.

A entrega de vídeo também recebeu várias correções concretas. O PR #2643 tenta novamente fontes derivadas hospedadas pela Divine em ordem e faz fallback para o blob bruto antes de exibir um erro de playback, para que falhas transitórias em uma fonte não matem o playback imediatamente. O PR #2634 mantém uploads resumíveis no caminho controlado pela Divine quando o probing de capacidades falha de forma transitória, reduzindo uploads quebrados por pequenas falhas de rede. O PR #2637 também muda a barreira de conteúdo sensível para que vídeos só sejam efetivamente bloqueados por labels reais de warning, não apenas por labels de content warning fornecidas pelo criador.

Shopstr adiciona storefronts customizadas e Milk Market segue entregando trabalho de marketplace

Shopstr, o marketplace baseado em Nostr, mergeou o PR #245 adicionando storefronts customizadas. Isso dá aos vendedores uma superfície de home mais distinta em vez de forçar cada listagem à mesma apresentação genérica.

Milk Market, um marketplace dedicado a leite, continuou com otimizações de storefront (PR #18), recuperação de conta (PR #17), beef splits (PR #15) e correções de tipagem de ferramentas MCP (PR #16).

Notedeck adiciona efeitos sonoros e estende o caminho do atualizador rumo ao Android

Notedeck, o cliente desktop da equipe Damus, mergeou o PR #1412 adicionando um subsistema de efeitos sonoros com sons de interação de UI usando rodio, e o PR #1399 com atualizações do Agentium incluindo uma flag de título para CLI e pastas de sessão colapsáveis. Um PR #1417 aberto propõe self-update de APK via Nostr/Zapstore no Android, construindo sobre o trabalho de atualizador nativo do Nostr do Notedeck coberto na Newsletter #14.

Nostria adiciona relay hints em reposts e alinhamento com NIP-98

Nostria mergeou o PR #583 adicionando relay hints NIP-18 (Reposts) a tags e de repost para eventos kind 6 e kind 16, o PR #582 alinhando auth HTTP do Brainstorm (kind 27235) às tags obrigatórias NIP-98 (HTTP Auth), e o PR #576 adicionando testes de validação de schema do Schemata. A mudança NIP-98 significa que o Nostria pode autenticar-se em serviços externos usando o mesmo formato de auth HTTP que outros clientes usam.

Nostr-Doc adiciona empacotamento desktop e trabalho offline-first

Nostr-Doc, o editor colaborativo da Form*, teve uma semana movimentada de empacotamento e trabalho de editor. O commit fcdc00a adiciona um app desktop, o commit 3977a8e inicia trabalho de app nativo, e o commit 413a030 empurra o app em direção a comportamento offline-first. No lado do editor, o commit 1855ce8 adiciona salvar com Ctrl+S, avisos de save, correções de link preview e renderização corrigida de strikethrough.

rust-nostr otimiza parsing de NIP-21 e adiciona suporte a NIP-62 do lado do relay

rust-nostr mergeou oito PRs. O mais notável é o PR #1308, que otimiza o parsing de URI NIP-21 em PublicKey::parse alinhando-o ao desempenho padrão de parsing bech32. Antes disso, URIs NIP-21 levavam aproximadamente o dobro do tempo para serem parseados em relação a chaves bech32 brutas. O projeto também tem quatro PRs abertos adicionando suporte específico de relay a NIP-62 (Request to Vanish) nos backends memory, LMDB, SQLite e database test (PR #1315, PR #1316, PR #1317, PR #1318).

nostr-tools adiciona controle manual de relays de bunker e corrige parsing multi-relay de NIP-47

nostr-tools mergeou o PR #530 adicionando skipSwitchRelays a BunkerSignerParams para gerenciamento manual de relays, e o PR #529 corrigindo o parsing de connection string NIP-47 (Nostr Wallet Connect) para suportar múltiplos relays como a spec permite.

Nostrability integra dados de auditoria do Sherlock e publica visão geral do Schemata

Nostrability, o tracker de interoperabilidade para clientes Nostr, mergeou 14 PRs. O PR #306 integra estatísticas de scan do Sherlock ao dashboard. Sherlock é a ferramenta automatizada de auditoria da Nostrability que se conecta a clientes Nostr, captura os eventos que eles publicam e valida cada evento contra as definições JSON Schema do Schemata para detectar violações de spec. O dashboard agora mostra taxas de falha de schema por cliente (PR #315), para que desenvolvedores possam ver quais kinds de evento seu cliente implementa incorretamente. O PR #323 reformula o workflow de publicação no Nostr para que anúncios de release rodem como um job separado que não pode ser cancelado por etapas anteriores de CI.

elsat também publicou Schemata for nostr devs em 30 de março, descrevendo como schemata, schemata-codegen e Sherlock se encaixam e fornecendo números atuais de cobertura: 179 schemas de kind de evento em 65 NIPs, 154 schemas de tags, 13 mensagens de protocolo e 310 eventos de exemplo.

Nalgorithm adiciona geração de digest e cache local de score

Nalgorithm, um novo projeto de feed Nostr ranqueado por relevância, iniciou desenvolvimento público nesta semana. O commit cf6c501 estabelece o app web inicial que busca posts de follows e os pontua contra um prompt de preferência definido pelo usuário. O commit 8e931b6 adiciona uma ferramenta CLI de digest que transforma posts mais bem ranqueados em um resumo falado, enquanto o commit 4cb9c63 adiciona cache de scores em arquivo e evolução incremental do prompt aprendido a partir de likes recentes. O commit c2edfb8 também para de fazer cache de fallback scores de batches que falharam, para que uma falha transitória de scoring não achate permanentemente o ranking de um post.

TENEX adiciona vector store para RAG e startup direcionado de MCP

TENEX, o framework de agentes nativo do Nostr que conecta agentes de IA a canais Nostr via Telegram, mergeou sete PRs nesta semana. O PR #101 adiciona uma abstração plugável de vector store com backends SQLite-vec, LanceDB e Qdrant, dando aos agentes retrieval-augmented generation sem travar em um banco vetorial específico. O PR #102 torna o startup de MCP direcionado: apenas servidores MCP cujas ferramentas um agente realmente usa são iniciados, em vez de subir todos os servidores eager no primeiro uso. O PR #100 adiciona uma ferramenta send_message para que agentes com bindings de canal Telegram possam enviar mensagens proativamente em vez de apenas responder a mensagens recebidas. O PR #106 evita um spawn de subprocesso que disparava uma pré-alocação de 9 GB de memória Bun/JSC lendo .git/HEAD diretamente em vez de executar git branch.

Dart NDK move suporte a signer Amber e adiciona Alby Go 1-click

Dart NDK, o kit de desenvolvimento Nostr para Flutter, lançou 11 PRs mergeados. O PR #525 move suporte ao signer Amber para o pacote ndk_flutter, e o PR #552 adiciona conexão one-click com Alby Go na sample app. O PR #502 adiciona um script install.sh para o CLI, e o PR #523 remove a dependência do verificador Rust em favor de tratamento nativo de assets.

Trabalho de Protocolo e Spec

Marmot move KeyPackages para eventos endereçáveis e reforça push notifications

A specificação Marmot mergeou quatro PRs que mudam como o protocolo trata material de chave e associação de grupo. O PR #54 migra eventos KeyPackage de kind:443 regular para kind:30443 endereçável com uma tag d, eliminando a necessidade de deleção de eventos NIP-09 durante rotação de chave. Eventos endereçáveis sobrescrevem no lugar, tornando a rotação autocontida. O PR #57 permite que usuários não-admin façam commit de propostas SelfRemove (saída voluntária do grupo), e o PR #62 exige que admins renunciem ao status de admin antes de usar SelfRemove, prevenindo que um admin desapareça enquanto ainda detém privilégios elevados.

O PR #61 reforça o formato de push notification MIP-05, tornando explícitos a codificação base64 em blob único, versionamento, wire format de token e uso de chave x-only. O efeito é uma representação wire única e definida para blobs de token e chaves x-only em spec, bibliotecas cliente e backends de app. A implementação dessas mudanças de spec chegou à stack White Noise nesta semana e está coberta na seção White Noise v2026.3.23 acima.

Atualizações de NIPs

Mudanças recentes no repositório de NIPs:

Mergeado:

NIP-5A: Static Websites (PR #1538): Define eventos de manifesto kind 15128 (site raiz) e kind 35128 (site nomeado) para hospedar sites estáticos sob pares de chaves Nostr usando armazenamento Blossom. Veja o deep dive abaixo.
NIP-30 (Custom Emoji): Permitir hífens em shortcodes (PR #2297): Atualiza a descrição de shortcode para incluir hífens. Shortcodes com hífen já são usados na prática desde a introdução do NIP, então a spec agora documenta o uso atual.

PRs Abertos e Discussões:

NIP-C1: Agent TUI Messages (PR #2295): Propõe um formato estruturado de mensagem para agentes enviarem elementos interativos de UI por DMs criptografadas, incluindo payloads tipados text, buttons, card e table. O rascunho mantém tudo dentro do conteúdo JSON de mensagens diretas existentes NIP-17 e NIP-04. Não define um novo kind de evento e usa um formato simples de callback string para respostas de botões.
NIP-95: Hybrid Peer-to-Peer Relay Protocol (PR #2293): Propõe um modelo híbrido de relay no qual relays permanecem autoritativos, mas também podem coordenar distribuição peer-to-peer de eventos recentes via WebRTC. O rascunho introduz mensagens de relay como PEER_REGISTER, PEER_REQUEST e PEER_OFFER, com clientes estáveis atuando como Super Peers e o relay agindo como seed node e fallback.
NIP-B9: Zap Poll Events (PR #2284): Reabre a antiga ideia de zap poll do NIP-69 agora que NIP-88 (Polls) cobre enquetes gratuitas. O rascunho usa definições de enquete kind 6969 e zaps kind 9734 como votos, tornando-o um sistema de enquetes pagas com resistência econômica a Sybil. Ele complementa enquetes gratuitas one-key-one-vote.
NIP-AD: Super Zap (PR #2289): Propõe uma convenção na qual zaps enviados à pubkey de um relay ou de um cliente são exibidos como notas promocionais especializadas, transformando efetivamente recibos de zap em uma superfície de anúncio. Operadores de relay e clientes publicariam perfis com lud16, buscariam esses recibos, extrairiam o conteúdo embutido das descrições de zap e poderiam opcionalmente definir thresholds mínimos em sats para reduzir spam.
NIP-XX: Agent Reputation Attestations (PR #2285): Propõe kind 30085 como um evento parameterized replaceable para attestations estruturadas de reputação sobre agentes Nostr. O rascunho evita um score global único ao tornar a reputação dependente do observador, adiciona decaimento temporal para que attestations antigas percam peso, suporta avaliações negativas com exigência de evidência e esboça tanto weighted scoring simples quanto graph-diversity scoring para melhor resistência a Sybil.
NIP-XX: Paid API Service Announcements (PR #2291): Propõe eventos addressable kind 31402 para anunciar APIs HTTP pagas, com Nostr cuidando da descoberta e HTTP 402 do pagamento. O rascunho é tags-first para que relays possam filtrar por métodos de pagamento, preços e capacidades sem fazer parsing de conteúdo JSON, e permite schemas opcionais de request e response para que clientes ou agentes possam auto-gerar chamadas.
NIP-XX: Key Derivation from LNURL-auth via SplitSig (PR #2294): Propõe derivar um par de chaves Nostr de uma assinatura ECDSA de LNURL-auth combinada com um nonce aleatório do lado do cliente. A fórmula de derivação é nsec = SHA256(ecdsa_signature || nonce). O servidor vê a assinatura ECDSA, inerente ao handshake LNURL-auth, mas nunca vê o nonce, e o browser gera o nonce, mas não controla a assinatura. Nenhuma das partes isoladamente consegue derivar o nsec. O resultado pretendido é que a mesma carteira Lightning produza a mesma chave Nostr entre dispositivos, com a carteira como âncora de recuperação e sem que nenhum servidor consiga reconstruir a chave privada.
NIP-55: Documentar campo rejected (PR #2290): Documenta o campo rejected para respostas de signer baseadas em intent, formalizando o comportamento que a correção da série v1.07.x do Amethyst precisou contornar.

NIP Deep Dive: NIP-5A (Sites estáticos)

NIP-5A define como hospedar sites estáticos sob pares de chaves Nostr, usando dois kinds de evento e infraestrutura existente de armazenamento de blobs para transformar eventos assinados em páginas web servidas. A especificação foi mergeada em 25 de março via PR #1538.

O modelo usa kind 15128 para um site raiz, um por pubkey, e kind 35128 para sites nomeados identificados por uma tag d. Cada manifesto mapeia caminhos absolutos de URL para hashes SHA256. Aqui está um manifesto de site raiz:

{
 "id": "5324d695ed7abf7cdd2a48deb881c93b7f4e43de702989bbfb55a1b97b35a3de",
 "pubkey": "266815e0c9210dfa324c6cba3573b14bee49da4209a9456f9484e5106cd408a5",
 "created_at": 1743465600,
 "kind": 15128,
 "tags": [
 ["path", "/index.html", "186ea5fd14e88fd1ac49351759e7ab906fa94892002b60bf7f5a428f28ca1c99"],
 ["path", "/about.html", "a1b2c3d4e5f6789012345678901234567890abcdef1234567890abcdef123456"],
 ["path", "/favicon.ico", "fedcba0987654321fedcba0987654321fedcba0987654321fedcba0987654321"],
 ["server", "https://blossom.primal.net"],
 ["title", "My Nostr Site"],
 ["description", "A static website hosted on Nostr"],
 ["source", "https://github.com/lez/nsite"]
 ],
 "content": "",
 "sig": "f4e4a9e785f70e9fcaa855d769438fea10781e84cd889e3fcb823774f83d094cf2c05d5a3ac4aebc1227a4ebc3d56867286c15a6df92d55045658bb428fd5fb5"
}

O fluxo de serving funciona em três etapas. Um servidor host recebe uma requisição HTTP, extrai a pubkey do autor do subdomínio, seja um npub para sites raiz ou uma pubkey codificada em base36 para sites nomeados, busca a lista de relays do autor via NIP-65 e consulta o manifesto do site. Quando encontra o manifesto, o servidor resolve o caminho solicitado para um hash de conteúdo, baixa o blob correspondente do servidor Blossom ou dos servidores listados nas tags server e o retorna.

O formato do subdomínio DNS é rigidamente especificado. Sites raiz usam o npub padrão como subdomínio. Sites nomeados usam uma codificação base36 de 50 caracteres da pubkey bruta seguida pelo valor da tag d, tudo em um único label DNS. Como labels DNS são limitados a 63 caracteres e a codificação base36 sempre ocupa 50, a tag d é limitada a 13 caracteres. A spec também exige que tags d correspondam a ^[a-z0-9-]{1,13}$ e não terminem com hífen, prevenindo ambiguidades de resolução DNS.

Usar hashes de conteúdo significa que o mesmo site pode ser servido por diferentes servidores host, e a integridade dos arquivos é verificável sem confiar no servidor. Um servidor host não precisa armazenar arquivos por conta própria. Ele os busca sob demanda no Blossom usando os hashes do manifesto. Isso significa que o autor controla o que é servido, o servidor Blossom armazena os arquivos brutos, e o servidor host apenas conecta os dois. Qualquer um desses três componentes pode ser substituído de forma independente.

Implementações existentes incluem nsite, o servidor host que resolve manifestos e serve arquivos, e nsite-manager, uma UI para construir e publicar manifestos. A spec também adicionou uma tag source para vincular ao repositório de código-fonte do site, e a atualização de README mergeada separadamente no PR #2286 registrou os kinds 15128 e 35128 no índice de kinds do NIP.

NIP Deep Dive: NIP-62 (Request to Vanish)

NIP-62 define kind 62 como uma requisição para que relays deletem todos os eventos da pubkey solicitante. A especificação é motivada por questões legais: em jurisdições com leis de direito ao esquecimento, ter uma requisição padronizada e assinada de deleção dá a operadores de relay um sinal claro para agir.

{
 "id": "a7b8c9d0e1f23456789012345678901234567890abcdef1234567890abcdef12",
 "pubkey": "f1e2d3c4b5a697887766554433221100ffeeddccbbaa99887766554433221100",
 "created_at": 1743465600,
 "kind": 62,
 "tags": [
 ["relay", "wss://relay.example.com"]
 ],
 "content": "Requesting deletion of all events from this relay.",
 "sig": "11aa22bb33cc44dd55ee66ff77889900aabbccddeeff0011223344556677889911aa22bb33cc44dd55ee66ff77889900aabbccddeeff00112233445566778899"
}

A spec separa vanish requests direcionadas e globais. Uma requisição direcionada inclui tags relay específicas identificando quais relays devem agir. Uma requisição global usa a string literal ALL_RELAYS como valor da tag relay, pedindo que todo relay que veja o evento delete todos os eventos daquela pubkey. Relays que cumprem também devem garantir que eventos deletados não possam ser republicados de volta no relay, tornando a deleção sticky.

O NIP-62 vai além do NIP-09 (Event Deletion) em escopo e intenção. O NIP-09 permite deletar eventos individuais, e relays MAY cumprir. O NIP-62 solicita a deleção de tudo, e a spec diz que relays MUST cumprir se sua URL estiver tagueada. Ela também pede que relays deletem eventos NIP-59 (Gift Wrap) que tenham p-tag para a pubkey solicitante, o que significa que DMs recebidas são limpas junto com os próprios eventos do usuário. Publicar uma deleção NIP-09 contra uma vanish request NIP-62 não tem efeito: depois que você vanish, não pode un-vanish deletando a própria vanish request.

Nesta semana, o Amethyst v1.07.0 lançou suporte do lado do cliente ao NIP-62, permitindo que usuários iniciem vanish requests pelo app. Do lado do relay, rust-nostr tem quatro PRs abertos adicionando suporte a NIP-62 nos backends memory, LMDB, SQLite e database test (PR #1315, PR #1316, PR #1317, PR #1318). Isso coloca trabalho de suporte em cliente e relay na mesma semana.

O desenho do protocolo levanta uma tensão prática. A proposta de valor do Nostr inclui resistência à censura, significando que relays não deveriam ser capazes de impedir publicação. O NIP-62 introduz um caso em que um relay MUST impedir republicação de uma pubkey específica. As duas propriedades coexistem porque a requisição é autodirigida: você está pedindo a deleção dos seus próprios eventos, não dos eventos de outra pessoa. A propriedade de resistência à censura permanece intacta para todos, exceto para a pessoa que explicitamente optou por sair.

É isso por esta semana. Construindo algo ou tem novidades para compartilhar? Entre em contato via NIP-17 (Private Direct Messages) DM ou nos encontre no Nostr.

Nostr Compass #15

Wed, 25 Mar 2026 00:00:00 +0000

Bem-vindo de volta ao Nostr Compass, seu guia semanal sobre o Nostr.

Esta semana: Primal Android segue seu lançamento 3.0 de carteira com Follow Packs, enriquecimento de zap e deep links primalconnect://. BigBrotr publica uma análise de vazamento de nsec, escaneando 41 milhões de eventos em 1.085 relays e encontrando 16.599 chaves privadas válidas, enquanto npub.world integra alertas de vazamento às páginas de perfil na mesma semana. Martti Malmi lança nostr-vpn, uma alternativa ao Tailscale que sinaliza sobre relays Nostr e cria túneis WireGuard, com 11 releases em sete dias. A equipe do Vector abre o código do DOOM P2P sobre Nostr, FIPS lança v0.2.0, e Nostrability Schemata se expande para seis linguagens em uma semana.

Notícias

Primal adiciona Follow Packs, enriquecimento de zap e deep links

Seguindo a cobertura da versão 3.0.7 da semana passada, Primal Android passou esta semana em trabalho pós-release em torno de onboarding, UX do composer e contexto de carteira. O onboarding redesenhado introduz Follow Packs (PR #949), um botão nativo de GIF entra no composer de notas, um serviço de enriquecimento de zap (PR #979) anota transações da carteira com contexto de zap, e um protocolo de deep linking primalconnect:// (PR #969) habilita navegação entre apps.

Primal iOS está entregando o mesmo trabalho em paralelo via TestFlight, com a troca de carteira (PR #191), a implementação de enquetes e a refatoração do onboarding chegando na mesma janela.

BigBrotr mapeia chaves privadas expostas na rede de relays

BigBrotr, a plataforma de analytics de relays Nostr, publicou uma análise detalhada de chaves privadas expostas na rede de relays. O estudo escaneou 41 milhões de eventos em 1.085 relays, procurando strings nsec válidas embutidas no conteúdo dos eventos, e encontrou 16.599 chaves privadas válidas. Esse número parece alarmante até que se filtre um bot chamado “Mr.nsec”, responsável por 92% das ocorrências. Depois de remover o tráfego de bots, apenas 38 contas reais com mais de 21.000 seguidores combinados tinham chaves expostas, e nenhuma mostrava sinais de saber que suas chaves estavam públicas.

A equipe construiu um nsec-leak-checker como um serviço NIP-90 (Data Vending Machine), permitindo que usuários verifiquem se sua chave privada aparece em algum ponto do dataset escaneado sem revelar a chave ao verificador. npub.world integrou os dados de vazamento na mesma semana, exibindo banners de aviso em páginas de perfil onde chaves expostas foram detectadas. A combinação dá à rede tanto uma interface programática para DVMs e agentes quanto um aviso legível por humanos para usuários comuns. O dataset subjacente também alimenta o BigBrotr v6.4.0, que adiciona materialized views de eventos replaceable e addressable e uma correção de timeout ocioso do sincronizador.

nostr-vpn é lançado como alternativa ao Tailscale

Martti Malmi (mmalmi), criador do Iris, construiu e lançou nostr-vpn, uma VPN peer-to-peer que usa relays Nostr para sinalização e WireGuard (via boringtun) para túneis criptografados. A motivação foi direta: “Got annoyed by Tailscale requiring 3rd party accounts, so created Nostr VPN.” A ferramenta cria redes mesh entre dispositivos usando pares de chaves Nostr como identidade, sem servidor central de coordenação.

O projeto lançou 11 releases em sete dias, da v0.2.2 até a v0.2.13. Esse sprint adicionou suporte a Windows, pareamento LAN para descoberta em rede local e um sidecar Android para dispositivos móveis. A arquitetura é simples: dois dispositivos trocam metadados de conexão por relays Nostr e depois estabelecem um túnel WireGuard direto. Nostr lida com descoberta e sinalização para travessia de NAT. WireGuard cuida do tráfego real. A identidade é um par de chaves Nostr.

Malmi também continuou avançando nostr-double-ratchet, uma biblioteca de canal de mensagens seguras ao estilo Signal, com seis releases da v0.0.86 até a v0.0.93 durante a mesma semana.

DOOM open-source roda peer-to-peer sobre o Nostr

A equipe do Vector abriu o código de uma implementação multiplayer peer-to-peer de DOOM que usa Nostr para descoberta de pares, Marmot para criptografia end-to-end e Iroh, a biblioteca de rede QUIC da n0, para transporte gossip. O jogo é distribuído como um arquivo WebXDC de 4,2 MB que pode ser enviado dentro de mensagens de chat, sem exigir servidores para hospedar ou coordenar uma partida.

A abordagem técnica substitui o lockstep netcode original de 1993 por um modelo híbrido de sincronização em tempo real. Jogadores se descobrem por consultas a relays Nostr, negociam sessões por canais criptografados com Marmot e então passam o tráfego de baixa latência do jogo para a camada gossip QUIC do Iroh. A stack usa Nostr para descoberta, Marmot para criptografia e Iroh para transporte.

O Vector também entregou endurecimento de segurança nesta semana. O release adiciona um key vault endurecido em memória com proteções anti-debug e zeroize para material de chave sensível, bloqueio de usuários com filtragem completa de DMs e mensagens de grupo, e correções do canal realtime WebXDC para Mini Apps.

FIPS v0.2.0 lança transporte Tor, builds reproduzíveis e exemplos sidecar

FIPS, o projeto Free Internetworking Peering System e de redes mesh adjacente ao Nostr, lançou v0.2.0. O release adiciona suporte a transporte Tor para links mesh anonimizados, builds reproduzíveis, um exemplo sidecar que se conecta por um relay Nostr, e publicação de releases Nostr no workflow de pacotes OpenWrt. O release também corrige picos de jitter pós-rekey causados por drain-window frames. O wire format mudou em relação à v0.1.0, então nós existentes em v0.1.0 não podem interoperar com a v0.2.0 sem upgrade.

Nostrability Schemata fica multilíngue

O projeto Nostrability Schemata, que mantém definições JSON Schema para validar kinds de evento Nostr, passou de JavaScript apenas para seis linguagens em uma semana. Novos pacotes foram lançados para Rust, Go, Dart, Swift e Python, cada um fornecendo tanto um pacote de dados quanto um validador. A v0.2.6 também adicionou 17 novos schemas de kinds de evento.

O tracker de interoperabilidade da Nostrability recebeu uma reformulação em paralelo. Uma nova aba What’s New publica atualizações tanto por um feed Atom quanto por um evento Nostr, o filtro por categoria de app permite que visitantes foquem em tipos específicos de cliente, e o tracker agora detecta automaticamente linguagens de programação a partir dos metadados dos repositórios GitHub. A Nostrability também agora tem seu próprio npub, tornando o projeto descobrível pelo próprio protocolo que documenta. Para autores de bibliotecas que trabalham entre linguagens, os pacotes de schema multilíngues significam que as mesmas definições de kinds de evento ficam disponíveis como imports nativos em vez de exigir que cada projeto mantenha sua própria cópia dos schemas.

Lançamentos

Amethyst v1.06.0 e v1.06.1

Amethyst, o cliente Android mantido por vitorpamplona, lançou v1.06.0 e v1.06.1 em 23 de março. O principal recurso é suporte a enquetes usando dados NIP-85 (Trusted Assertions) para votação ponderada, com cards redesenhados de enquete e zap poll. A nova renderização dá tanto às enquetes padrão quanto às ponderadas por zap um layout visual mais limpo. A v1.06.1 vem em seguida com correções para crashes de modificação concorrente que tratam regressões de estabilidade introduzidas no caminho de renderização das enquetes.

Amber v5.0.0 e v5.0.1

Amber, o app assinador NIP-55 (Android Signer Application), promoveu seu trabalho recente de pre-release da série 4.1.x para estável com a v5.0.0 em 18 de março. Esse release estável traz o relay-auth NIP-42, Tor embutido, permissões específicas por tipo de conteúdo e armazenamento criptografado de PIN cobertos na semana passada. A v5.0.1 então remove a permissão de internet do flavor offline, de modo que esse build não pode mais fazer requisições de rede na camada de permissões do Android.

Mostro v0.17.0 e Mostro Mobile v1.2.2

Mostro, a exchange peer-to-peer de Bitcoin construída sobre Nostr, lançou v0.17.0 em 18 de março. O release do servidor continua o trabalho de disputa e reputação do ciclo v0.16.x, adicionando dados mais completos de reputação comercial para compradores e vendedores como eventos Nostr. Mostro Mobile, o cliente Flutter, acompanhou com a v1.2.2 em 23 de março, mantendo a interface mobile sincronizada com as mudanças mais recentes do protocolo.

Shosho v0.14.0

Shosho, o app de live streaming Nostr, lançou v0.14.0 em 19 de março com o lançamento do Shosho Shop. O release adiciona uma aba Shop em perfis, Shop em Browse e um botão In-Live Shop em lives e clips. As release notes dizem que produtos Nostr existentes aparecem automaticamente e que compradores clicam até a página do vendedor no Plebeian Market para compra. As release notes do Shosho não identificam o kind de evento de listagem, então ainda não é possível confirmar se o Shosho Shop lê as mesmas listagens classificadas NIP-99 que Shopstr suporta explicitamente em seu README.

Applesauce v5.2.0

Applesauce, a coleção de pacotes auxiliares do hzrd149 para construir aplicações Nostr, lançou v5.2.0 em 22 de março. O release cobre seis pacotes. O pacote SQLite corrige uma colisão de constraint UNIQUE em tags de evento que causava inserts duplicados. O pacote signers adiciona AndroidNativeSigner, que encapsula a interface nativa do assinador Android NIP-55 para que apps baseados em web-view possam usar assinatura com hardware backing sem bridge code customizado. O pacote relay adiciona um campo challenge aos objetos de status de relay e pool, rastreando estado de auth NIP-42 para que apps possam detectar quando um relay está pedindo autenticação e responder programaticamente. O pacote core ganha métodos isEventPointerSame e isAddressPointerSame para deduplicar referências de eventos, e o pacote common adiciona user.blossomServers$ para resolver os servidores Blossom de um usuário. Applesauce alimenta noStrudel, Satellite e vários outros clientes web, então essas correções se propagam pela camada de clientes web.

Wisp lança 16 releases em uma semana

Wisp, o cliente Nostr para Android, lançou 16 releases da v0.9.3-beta até a v0.13.1-beta nesta semana. As adições de recursos incluem suporte a múltiplas contas, um modo zen de notificações para reduzir interrupções, rascunhos e posts agendados, filtros de conteúdo de segurança e um novo ícone de chama.

Manent v1.2.0

Manent, o app privado de notas criptografadas e armazenamento de arquivos, lançou v1.2.0 em 20 de março. O release adiciona captura de câmera diretamente do app, redimensionamento de imagem antes do upload para reduzir custos de armazenamento, e pinch-to-zoom para revisar imagens armazenadas. O Manent armazena notas e arquivos criptografados em relays Nostr usando o par de chaves do usuário, tornando o app de telefone ou desktop um cliente fino que pode reconstruir seu estado completo a partir dos dados dos relays.

diVine 1.0.7

diVine, o cliente de vídeo short-form, lançou 1.0.7 em 21 de março com um watchdog de reprodução de vídeo que retoma automaticamente vídeos travados. Depois da infraestrutura de testes E2E e do carregamento direto de MP4 na v1.0.6, este release mira o caminho de falha remanescente de reprodução: vídeos que param no meio do stream sem lançar erro.

Alby Extension v3.14.2

Alby Extension, a extensão de navegador NIP-07 (Browser Extension Signer), lançou v3.14.2 em 18 de março com exibição de QR code de endereço Lightning e suporte a assinatura Schnorr. A adição de Schnorr alinha a extensão de navegador ao esquema de assinatura secp256k1 que o Nostr usa nativamente.

NoorNote v0.6.5 até v0.6.11

NoorNote, o app de anotações, lançou sete releases da v0.6.5 até a v0.6.11. A principal adição é Follow Packs: conjuntos curados de contas que usuários podem navegar e seguir em massa, semelhantes às Twitter Lists, mas pensados para onboarding. Usuários podem criar, editar e compartilhar Follow Packs com títulos, descrições e imagens de capa personalizados. A série também atualiza a biblioteca Nostr subjacente de NDK v2 para v3, que traz melhor tratamento de conexão de relay e gerenciamento de subscriptions. Picture notes e uma experiência redesenhada de conexão de relay completam a sequência.

nak v0.19.1 e v0.19.2

nak, o toolkit de linha de comando Nostr do fiatjaf para interagir com relays, codificar e decodificar identificadores NIP-19 (Bech32-Encoded Entities), assinar eventos e consultar dados de relay, lançou v0.19.1 e v0.19.2 em 17 e 20 de março. Os dois point releases seguem a adição de UI de fórum de grupo da v0.19.0 da semana passada.

Calendar by Form* v0.2.1

Calendar by Form*, o app de calendário descentralizado construído sobre NIP-52 (Calendar Events), lançou v0.2.1 em 20 de março. O release corrige um problema de template de notificação que afetava lembretes de eventos. O Calendar armazena eventos como eventos Nostr kind 31922 (baseados em data) e kind 31923 (baseados em hora), permitindo que qualquer cliente Nostr renderize dados de calendário se escolher suportar esses kinds. O app é construído pela equipe Formstr, que também mantém Formstr (formulários descentralizados) e Pollerama (enquetes).

NYM v3.50 até v3.53

NYM, o cliente leve de chat efêmero com bridge para Bitchat, lançou 28 releases de v3.50 até v3.53. O recurso mais notável é o Nymbot, um chat bot embutido que responde a menções @nymbot em canais e fornece funções de status e gerenciamento de relay. Um “hardcore mode” gera um novo par de chaves para cada mensagem enviada, tornando threads de conversa desvinculáveis no nível de identidade. O tradeoff é claro: perde-se identidade persistente, mas ganha-se anonimato por mensagem. A camada de relay proxy também recebeu trabalho, com workers sharded de relay proxy para melhor conectividade, suporte a canais geohash e tolerância a clock skew para nós com relógios de sistema imprecisos.

Atualizações de Projetos

Ditto adiciona ponte com Bluesky e integração com Wikipedia

Ditto, o cliente social Nostr customizável da equipe Soapbox, registrou mais de 300 commits nesta semana em três trilhas distintas de recursos. A primeira é uma ponte com Bluesky (19 commits) que renderiza posts do Bluesky inline como threads completas ao estilo feed, adiciona navegação lateral para uma página de descoberta do Bluesky baseada no feed oficial Discover (whats-hot), e conecta botões de ação para comentar, compartilhar, reagir e copiar links. Quando um usuário responde a um post do Bluesky dentro do Ditto, o modal de composição mostra um aviso destacando a natureza cross-protocol da interação. Reações kind 17 do NIP-73 (External Content IDs) impulsionam esse modelo cross-protocol: um usuário Nostr reage a um post do Bluesky, e a reação é armazenada como um evento Nostr padrão referenciando o identificador de conteúdo externo. É o mesmo padrão NIP-73 que poderia fazer ponte de reações a qualquer conteúdo externo, de posts do Bluesky a vídeos do YouTube e páginas web.

A segunda trilha é uma integração com Wikipedia (9 commits). O Ditto agora renderiza conteúdo rico de artigos da Wikipedia em páginas de detalhe em vez de previews genéricos de link, adiciona autocomplete de busca com thumbnails de artigo, e fornece uma página /wikipedia puxando conteúdo em destaque da API da Wikipedia. Resultados da Wikipedia e do Archive.org também aparecem no dropdown geral de autocomplete de busca. A terceira trilha é suporte à plataforma iOS via Capacitor, com script de build remoto e configuração de plataforma chegando junto a uma reformulação de UI (55 commits) que substitui headers com backdrop blur por um novo design de navegação em arco em todas as páginas do app. Os 314 commits movem o Ditto de um cliente apenas Nostr para um agregador multiprotocolo que trata Bluesky e Wikipedia como fontes de conteúdo de primeira classe ao lado do feed Nostr.

Pika constrói um pipeline de CI para forge NIP-34

Pika, o app de mensagens criptografadas baseado em Marmot, mergeou 33 PRs nesta semana focados em um forge NIP-34 self-hosted com CI pré-merge. O forge é uma camada de hospedagem git que recebe patches como eventos NIP-34, executa verificações de CI antes do merge e reporta status estruturado de volta por eventos Nostr. O PR #701 adiciona CI pré-merge e noturna por lanes, onde cada caminho de código (Rust, TypeScript, builds Apple) roda em sua própria lane com status pass/fail independente. O PR #715 reduz agentes de CI gerenciados para containers Incus OpenClaw para isolamento, e o PR #733 adiciona um CLI ph forge para interagir com o forge hospedado pela linha de comando. PRs de suporte tratam permissões de escrita no repositório para merges (PR #736), metadados estruturados de CI com badges de status ao vivo (PR #722), splits de nightly builds Apple (PR #738), e correções de auth do forge e branch lookup (PR #734). Este é um dos primeiros sistemas CI/CD funcionais construídos sobre eventos git NIP-34, levando a hospedagem de código-fonte baseada em Nostr além da simples troca de patches em direção ao workflow de merge e teste que desenvolvedores esperam de GitHub ou GitLab.

Nostria adiciona comunidades, snippets de código e tratamento de eventos de voz

Nostria, o cliente Nostr multiplataforma mantido por sondreb, passou esta semana expandindo a superfície do app além da filtragem Web of Trust coberta na edição #14. A principal adição é uma implementação completa do NIP-72 (Moderated Communities) com criação de comunidade, configuração de moderadores e relays, rastreamento de aprovação de posts com previews de imagem e uma página dedicada de comunidade com abas Posts e Moderators.

O mesmo trecho de trabalho também adiciona renderização e edição de snippets de código com um editor com syntax highlighting, suporte a resposta a eventos de voz para conversas em áudio, configurações de relay de chat para mensagens diretas, compartilhamento de canal pela Web Share API, um sistema de docking de toolbar para o media player, cadastro in-app no serviço mais recente do Brainstorm Web of Trust, fluxos de envio e recebimento de dinheiro em DMs usando NWC e invoices BOLT-11, tratamento de GIFs nativo do Nostr e um caminho mais forte de importação RSS para músicos que consegue capturar Lightning splits existentes de feeds de podcast.

nostr-vpn em iteração rápida

Além do lançamento inicial, o log de commits do nostr-vpn revela os problemas específicos encontrados durante deployment real. A v0.2.3 até a v0.2.5 adicionaram o script inicial de instalação e o CLI cross-platform. A v0.2.6 e a v0.2.7 trouxeram suporte a Windows, o que exigiu quoting de caminhos com UAC para escrita de configuração e atualizações de config pertencentes ao daemon. A v0.2.8 até a v0.2.10 corrigiram ações de serviço na GUI do Windows, tratamento de subprocessos do CLI e configuração de serviço no escopo da máquina. A v0.2.12 substituiu descoberta LAN por timed LAN pairing, um fluxo iniciado pelo usuário em que dois dispositivos na mesma rede local se pareiam sem sinalização via relay. O padrão é típico de testes de campo em estágio inicial: cada release mira uma falha específica de deployment, a base de usuários é pequena o suficiente para iterar diariamente, e o desenvolvedor está usando a ferramenta pessoalmente entre releases.

Comet e builds automatizados

Comet (antigo Captain’s Log), a ferramenta nativa do Nostr para escrita long-form da Nodetec, produziu mais de 40 builds alpha automatizados nesta semana. O Comet é um app desktop para escrever e publicar artigos NIP-23 (Long-form Content), com armazenamento local de rascunhos, edição Markdown e publicação com um clique para o conjunto de relays do usuário. O pipeline automatizado de builds gera um release tagueado para cada commit na branch main, o que torna a contagem bruta de releases enganosa como medida de velocidade de recursos. O que os 40 builds mostram é que o app está sob desenvolvimento ativo diário, com cada commit testado, empacotado e disponibilizado para download em minutos.

Atualizações de NIPs

Mudanças recentes no repositório de NIPs durante a janela de 17 a 24 de março:

Nenhum merge de NIP ocorreu entre 18 e 24 de março.

PRs Abertos e Discussões atualizados durante a janela:

NIP-AA: Autonomous Agents on Nostr (PR #2259): Propõe convenções para agentes autônomos operando na rede Nostr. O PR define como agentes se identificam, descobrem serviços e se coordenam com outros agentes e humanos por eventos Nostr.
NIP-50 (Search): Extensões de ordenação (PR #2283): Adiciona parâmetros de ordenação a consultas de busca NIP-50, incluindo top, hot, zaps e new. Isso permitiria que clientes solicitassem resultados ranqueados de relays com suporte a full-text search em vez de ordenar do lado do cliente.
NIP-A5: WASM Programs (PR #2281): Propõe uma convenção para publicar e descobrir programas WebAssembly no Nostr. Binários WASM poderiam ser distribuídos como eventos Nostr, com relays servindo como camada de descoberta para código executável portável.
NIP-CF: Combine Forces interoperable napps (PR #2277): Define uma convenção para aplicações Nostr interoperáveis (“napps”) que podem compor funcionalidades entre diferentes clientes e serviços.
Snapshots NIP (PR #2279): Propõe um mecanismo de snapshots de estado de relay, para sincronização e backup de relays.
Checkpoints NIP (PR #2278): Propõe eventos de checkpoint para marcar estado conhecido como bom de relay, complementando a proposta de snapshots.
NIP-58 (Badges): Refatoração de Badge Sets (PR #2276): Reestrutura como coleções de badges são organizadas e referenciadas.
NIP-11 (Relay Information Document): Extensões (PR #2280): Adiciona campos extras ao relay information document para metadados de relay legíveis por máquina mais ricos.

Cinco Anos de Marços do Nostr

A newsletter do mês passado cobriu como os fevereiros do Nostr progrediram desde a reescrita do NIP-01 (Basic Protocol Flow), passando pela onda do Damus na App Store, até redes mesh e propostas de agentes. Esta retrospectiva traça o que aconteceu em cada março de 2021 até 2026.

Março de 2021: Dois Commits

Quatro meses após sua existência, o mês de março do Nostr produziu exatamente dois commits no repositório do protocolo, ambos em 4 de março. fiatjaf adicionou links para instâncias nostwitter, apontando visitantes iniciais para deployments funcionais, e adicionou kind à definição básica de filtro. Esse segundo commit é revelador: em março de 2021, ainda não era possível filtrar eventos Nostr por kind. O protocolo era tão primitivo assim. Dois ou três relays serviam a rede. O grupo no Telegram era o único canal de coordenação. O repositório de NIPs ainda não existia; propostas de protocolo viviam como arquivos no repositório principal do nostr. fiatjaf foi o único committer naquele mês. Toda a produção de março de 2021 daquilo que se tornaria um protocolo suportando VPNs, jogos multiplayer e redes mesh cinco anos depois cabe em um único git diff.

Março de 2022: Construção pré-Damus

O repositório principal do protocolo recebeu zero commits em março de 2022. O desenvolvimento havia migrado inteiramente para repositórios de ferramentas. Branle, o cliente web em Vue.js do fiatjaf e na época a principal interface Nostr, recebeu 5 commits incluindo suporte a deployment com Docker e correções de display name NIP-05 (DNS-Based Verification) que removiam o prefixo _@ dos badges de verificação. O more-speech de Robert C. Martin, o cliente desktop em Clojure, registrou 13 ou mais commits adicionando threading, navegação por teclado e uma janela de edição. O autor de software mais famoso construindo ativamente sobre Nostr naquele mês não era um desenvolvedor cripto, mas a pessoa cujo “Clean Code” vendeu milhões de cópias, escrevendo um cliente Nostr em Clojure, uma escolha de linguagem que diz tudo sobre a comunidade inicial: eram programadores opinativos construindo para si mesmos.

A rede de relays havia se expandido para cerca de 15 relays com uma base ativa de usuários na casa das centenas. O Damus ainda não existia e só seria criado em abril de 2022. O Nostream também ainda não havia aparecido. O trabalho do mês foi infraestrutura: tornar as ferramentas existentes mais confiáveis para a pequena comunidade que já as usava diariamente.

Março de 2023: Infraestrutura pós-explosão

Um mês após a onda do Damus na App Store e o salto acima de 300.000 chaves públicas, março de 2023 foi sobre absorver o crescimento. O repositório de NIPs mergeou 28 pull requests, a segunda maior contagem mensal da história do protocolo. NIP-51 (Lists) foi mergeado, dando aos clientes coleções estruturadas de follows, mutes e bookmarks. NIP-39 (External Identities in Profiles) chegou, o NIP-78 (Application-Specific Data) forneceu um kind de armazenamento de propósito geral para apps que precisavam de estado privado, e uma reescrita do NIP-57 (Lightning Zaps) (PR #392) consolidou o fluxo de zap e clarificou a terminologia. O PR mais discutido do mês foi uma proposta alternativa de tratamento de mentions (PR #381) com mais de 50 comentários.

O novo projeto mais consequente foi o NDK (Nostr Development Kit), a biblioteca TypeScript para conexões de relay, assinatura de eventos, cache e gerenciamento de subscriptions. pablof7z fez o commit inicial em 16 de março de 2023, depois o reescreveu do zero 11 dias depois em 27 de março (“basically another initial commit”), e já tinha suporte a LNURL e zap funcionando até 31 de março. O NDK saiu do zero para suportar zaps em 15 dias. Cinco dias após a criação do NDK, em 21 de março, a equipe do Alby criou o NWC (Nostr Wallet Connect), a implementação de referência do NIP-47 que conectava carteiras Lightning a aplicações Nostr. Os dois projetos que sustentariam os três anos seguintes de desenvolvimento Nostr baseado na web nasceram na mesma janela de 30 dias. A OpenSats ainda não havia lançado seu fundo Nostr; a primeira onda só viria em julho de 2023, quatro meses após a criação do NDK.

Outras criações notáveis naquele mês incluíram NostrGit, NostrChat, um projeto nostr-signing-device da LNbits e nostrmo. Gossip, o cliente desktop em Rust focado em seleção inteligente de relay, lançou três releases. O protocolo estava em modo de construção, e as ferramentas criadas em março de 2023 ainda estão em uso três anos depois.

Março de 2024: Maturação do protocolo

Março de 2024 foi sobre endurecer o protocolo para uso de longo prazo. O repositório de NIPs mergeou 12 pull requests. A mais significativa foi NIP-34 (Git Stuff), PR #997, mergeada em 5 de março após mais de 130 comentários e 44 dias de review. A thread de discussão é uma cápsula do tempo da comunidade debatendo como construir um GitHub descentralizado. jb55 traçou paralelos com git send-email, Giszmo propôs usar hashes de root commit para descoberta entre forks (“something GitHub doesn’t do and we could”), mikedilger sugeriu autenticação assinada por evento NIP-98 (HTTP Auth) em vez de chaves SSH, e fiatjaf descartou sem rodeios a necessidade de generalidade para controle de versão: “not for each version control system, just for git. No one uses the others.” Em poucas horas após abrir o PR, fiatjaf já havia ajustado nak, go-nostr e gitstr para aceitar patches sobre Nostr. DanConwayDev, cujo ngit já era bolsista da OpenSats, esteve entre os contribuidores mais ativos da discussão. Um campo de bot para metadados de perfil também foi mergeado, dando aos clientes uma forma legível por máquina de distinguir contas automatizadas de humanas.

Amethyst lançou v0.85.0 com suporte a eventos git, artigos wiki, renderização de dados médicos e edição de conteúdo em um único release. Mostro chegou à v0.10.0. Nosflare, um relay Nostr serverless rodando em Cloudflare Workers, provou que lógica de relay pode rodar na edge. A OpenSats emitiu uma bolsa Long-Term Support para Bruno Garcia por contribuições sustentadas ao cliente Amethyst.

Março de 2025: Expansão de infraestrutura

Março de 2025 produziu 10 NIPs mergeados. O destaque foi NIP-66 (Relay Discovery and Liveness Monitoring), PR #230, mergeado em 3 de março após uma jornada de 25 meses. dskvr primeiro propôs monitoramento de relays em fevereiro de 2023, ouviu que isso poderia ser feito do lado do cliente, explicou por que conectar-se a milhares de relays ao mesmo tempo era impraticável para clientes individuais, passou por sete drafts completos, construiu nós de monitoramento em oito regiões geográficas (Nordeste dos EUA, Brasil, Oeste dos EUA, Leste dos EUA, Austrália, Índia, Coreia e África do Sul) e esperou o ferramental de relay amadurecer. Quando foi mergeado, implementações já existiam em nostr.watch, relaypag.es, monitorlizard, Snort, noStrudel e Jumble. Os dados do NIP-66 depois alimentariam os benchmarks outbox da Nostrability cobertos na Newsletter #12. O NIP-C0 (Code Snippets) também foi mergeado (PR #1852, 63 comentários), adicionando eventos kind 1337 para compartilhamento de código-fonte.

Os primeiros servidores MCP para Nostr apareceram nesse mês. nostr-mcp-server apareceu em 23 de março e nwc-mcp-server em 14 de março, apenas quatro meses após a Anthropic anunciar o Model Context Protocol em novembro de 2024. Essas pontes iniciais precederam o SDK completo ContextVM e o trabalho posterior de comércio de agentes no fim de 2025 e início de 2026.

Gossip lançou v0.14.0. Coracle, o cliente web do hodlbod com gerenciamento de feed sensível a relays, lançou três releases. A OpenSats anunciou sua décima onda de bolsas Nostr, continuando a linha de financiamento que vinha desde meados de 2023.

Março de 2026: Convergência

A atividade de março de 2026 é extraída das edições do Nostr Compass #12 até #15 (esta edição).

Março de 2026 é o mês em que linhas antes separadas convergiram em sistemas funcionais. O Marmot Development Kit lançou sua primeira versão pública com mídia criptografada, bindings multi-linguagem e uma migração para ChaCha20-Poly1305 que exigiu atualizações coordenadas entre spec, Rust e TypeScript. Shopstr e Milk Market adicionaram superfícies de comércio MCP para compras dirigidas por agentes. O relay auth NIP-42 chegou simultaneamente em Amber, strfry e OAuth Bunker, fechando o loop entre software de signer, relay e bunker. Notedeck lançou atualizações de software nativas do Nostr usando eventos de release NIP-94 (File Metadata).

Nesta semana, BigBrotr escaneou a rede completa de relays em busca de chaves privadas vazadas e publicou tanto a análise quanto um verificador DVM. Nostr VPN provou que o modelo de chaves do Nostr funciona para infraestrutura de rede, não apenas para mídia social. DOOM demonstrou que descoberta via Nostr, criptografia Marmot e transporte QUIC podem rodar um jogo multiplayer em tempo real. Amber saltou para v5.0.0. Wisp lançou 16 releases em sete dias. Vinte e cinco ou mais releases tagueados vieram de projetos importantes em uma única semana.

Sete NIPs foram mergeados nos primeiros 24 dias do mês. O protocolo adicionou marcação Djot ao NIP-54 (Wiki), limites de entrada ao NIP-19 (Bech32-Encoded Entities), lógica booleana de consulta ao NIP-91 (AND Operator for Filters), e assertions de Web of Trust ao NIP-85 (Trusted Assertions). Propostas abertas iam de agentes autônomos (NIP-AA) a programas WASM (NIP-A5) e extensões de ordenação de busca para NIP-50.

Olhando para frente

Cinco marços do Nostr traçam um arco claro. Em 2021, uma pessoa fez dois commits em um protocolo que ainda não conseguia filtrar eventos por kind. Em 2023, NDK e NWC nasceram com cinco dias de diferença para absorver a explosão pós-Damus. Em 2024, uma thread de PR com 141 comentários debateu como colaboração git deveria funcionar sobre um protocolo social. Em 2025, uma spec de monitoramento de relays que havia sido pacientemente reescrita sete vezes ao longo de 25 meses finalmente foi mergeada. Em 2026, alguém se irritou com o fato de o Tailscale exigir conta e construiu uma VPN usando pares de chaves Nostr, enquanto outra pessoa lançou DOOM multiplayer que descobre pares por relays Nostr e criptografa a jogabilidade com Marmot. O escaneamento de 41 milhões de eventos em 1.085 relays pelo BigBrotr dá uma medida concreta de quanto a rede cresceu. A área de superfície do protocolo em março de 2026 seria irreconhecível para março de 2021, mas o modelo subjacente, eventos assinados por chaves secp256k1 e distribuídos por relays, não mudou.

É isso por esta semana. Construindo algo ou tem novidades para compartilhar? Entre em contato via NIP-17 (Private Direct Messages) DM ou nos encontre no Nostr.

Nostr Compass #14

Wed, 18 Mar 2026 00:00:00 +0000

Bem-vindo de volta ao Nostr Compass, seu guia semanal sobre o Nostr.

Esta semana: Amethyst implementa suporte completo aos métodos do NIP-47 (Nostr Wallet Connect), Alby Hub adiciona suporte a múltiplos relays na v1.21.6, Amber lança v4.1.3 com Tor embutido e permissões de assinatura mais granulares, e Zeus remove um caminho arriscado de keysend NWC no PR #3835. Notedeck lança um atualizador assinado na v0.8.0-rc2 que descobre releases através de eventos NIP-94 (File Metadata), enquanto Damus corrige estado obsoleto do NIP-65 (Relay List Metadata), Nostrability Outbox revisa seus resultados de benchmark com dados corrigidos, e Primal iOS testa assinaturas diretas de relay para DMs. Primal Android lança 3.0.7, Route96 lança v0.6.0, OpenChat continua refinando a interoperabilidade Marmot na v0.1.0-alpha.11, Pika consolida seu runtime na pika/v1.1.1, e Nostria adiciona filtragem Web of Trust via NIP-85 (Trusted Assertions). O repositório de NIPs mergeia a marcação Djot do NIP-54 (Wiki) e um limite de entrada de 5000 caracteres para NIP-19 (Bech32-Encoded Entities).

Notícias

Suporte a Wallet Connect se amplia, e clientes de carteira reforçam caminhos de falha

Amethyst, o cliente Android mantido por vitorpamplona, mergeou o PR #1828, que aproxima sua implementação do NIP-47 da cobertura completa do protocolo. O patch adiciona make_invoice, lookup_invoice, list_transactions, get_balance, get_info, métodos de hold invoice, suporte a keysend com registros TLV, descoberta de capacidades via kind 13194, e eventos de notificação no kind 23197 com NIP-44 (Encrypted Payloads). Isso dá ao cliente uma superfície NWC muito mais ampla sem depender de extensões específicas de app.

A stack de carteiras ao redor se moveu na mesma direção. Alby Hub, o nó Lightning auto-custodial e serviço de carteira por trás de muitos deployments NWC, lançou v1.21.6 com suporte a múltiplos relays e fluxos de conexão e swap simplificados. Zeus, a carteira Lightning mobile, mergeou o PR #3835 removendo suporte a keysend NWC após identificar um caminho silencioso de drenagem de fundos nesse fluxo, enquanto também corrigiu tratamento de eventos pendentes e atividade Cashu. A conectividade de carteira no Nostr está ficando mais ampla, e implementadores estão removendo fluxos difíceis de proteger.

Notedeck move descoberta de releases para o Nostr

Seguindo a cobertura do Notedeck da semana passada, Notedeck, o cliente desktop nativo da equipe Damus, lançou v0.8.0-rc2 após mergear o PR #1326. O novo atualizador se inscreve em eventos de release kind 1063 assinados, identifica a plataforma local, baixa o binário referenciado e verifica o hash SHA256 antes da instalação. Metadados de release não precisam mais vir da API do GitHub ou de um site do projeto. Uma pubkey de release confiável e uma conexão de relay são suficientes.

O mesmo patch adiciona um CLI notedeck-release que publica esses eventos a partir de artefatos de release do GitHub, o que significa que o pipeline de release agora tem um caminho de publicação nativo do Nostr assim como um caminho de descoberta nativo do Nostr. Isso também aproxima o modelo de atualizador do Damus e Notedeck do fluxo de release assinado publicado via relay da Zapstore: o ferramental zsp da Zapstore já trata ativos de software como eventos kind 1063 ou 3063, então esse caminho não está limitado a um único cliente ou publicador. O restante do release candidate é trabalho prático de desktop, colunas de follows, “View As User” de perfil, suporte a NIP-59 (Gift Wrap), estatísticas de notas em tempo real e tratamento de limitações do NIP-11 (Relay Information Document), mas o atualizador é a parte que provavelmente vai durar além deste ciclo de release.

Estado de relay se aproxima do comportamento em tempo de execução

Damus mergeou o PR #3665, substituindo um ID de evento de lista de relays armazenado obsoleto por uma consulta direta ao banco de dados para o evento kind 10002 mais recente. Quando o valor antigo ficava obsoleto, operações de adicionar e remover relay podiam recorrer a listas bootstrap ou de um ano atrás, o que fazia algumas mudanças de relay parecerem bem-sucedidas enquanto deixavam o estado ativo inalterado. O PR #3690 corrige um segundo caminho de falha deletando estado lock.mdb obsoleto durante compactação LMDB para que o app não quebre com SIGBUS no próximo lançamento.

Primal iOS abriu o PR #194, que se inscreve diretamente nos relays de escrita NIP-04 (Encrypted Direct Messages) de um parceiro de chat enquanto uma conversa está aberta, mantendo o servidor de cache como fallback. Nostur abriu o PR #53, que combina pontuação randomizada de relay, filtragem de atividade NIP-66 do nostr.watch e Thompson sampling para mudar a seleção de relay de uma heurística fixa para uma política aprendida. Clientes há tempos tratam a escolha de relay como dados de configuração. Mais apps agora a tratam como estado vivo que precisa de lógica de medição e reparo.

Lançamentos

Primal Android 3.0.7

Primal Android, o cliente Android do Primal, lançou 3.0.7 com um novo ciclo de enquetes e carteira. O PR #945 adiciona votação em enquetes baseada em zap, o PR #948 pagina o carregamento de votos para que enquetes maiores continuem usáveis, e o PR #965 busca recibos de zap para todas as transações. O mesmo lançamento também marca eventos suportados com metadados de cliente NIP-89 (Recommended Application Handlers) no PR #968, o que ajuda clientes downstream a atribuir origens de eventos de forma mais limpa.

Amber v4.1.3

Seguindo a cobertura do Amber da semana passada, Amber, o app assinador Android para fluxos NIP-55 (Android Signer Application), lançou v4.1.3. O lançamento se baseia em seu recente trabalho de relay-auth NIP-42 com mais endurecimento operacional: o PR #327 adiciona Tor embutido junto com suporte Orbot, o PR #324 substitui permissões de criptografia grosseiras baseadas em NIP por regras específicas por tipo de conteúdo, e o PR #336 remove permissões de rede do flavor offline enquanto o PR #335 adiciona verificações de CI para mantê-lo assim. O PR #322 também move o armazenamento de PIN para DataStore criptografado.

Este lançamento reforça a fronteira do próprio assinador. Isso é útil para qualquer fluxo Android que entregue chaves reais ou decisões de relay-auth ao Amber, porque a parte difícil não é apenas o que o assinador pode fazer. É também quão estreitamente ele pode ser limitado.

Route96 v0.6.0

Seguindo a cobertura do Route96 da semana passada, Route96, o servidor de mídia que suporta Blossom e NIP-96 (HTTP File Storage), lançou v0.6.0. O lançamento move configuração e estado de whitelist para o banco de dados com hot reload e adiciona políticas de retenção para arquivos antigos ou frios. Também adiciona um endpoint GET /user/files mais rico além de rastreamento de file-stat para downloads e egress, o que dá aos operadores mais visibilidade sobre como seu servidor de armazenamento está sendo usado.

OpenChat v0.1.0-alpha.11

Seguindo a cobertura do OpenChat da semana passada, OpenChat, o cliente de chat baseado em Avalonia construído sobre a stack Marmot, lançou v0.1.0-alpha.11 após uma semana de trabalho rápido de protocolo. O commit c33895d encapsula eventos Welcome em gift wrap NIP-59 e remove shims antigos de normalização de tags MIP-00, o commit 2738ff4 completa a auditoria de conformidade MIP-02, e o commit 8e470cf faz o mesmo para criptografia de mensagem de grupo MIP-03. O commit 129ca37 também consolida o tratamento NIP-44 na implementação compartilhada do marmot-cs, reduzindo o risco de drift de cripto do lado do cliente.

nak v0.19.0 e v0.19.1

nak, o toolkit de linha de comando Nostr do fiatjaf, lançou v0.19.0 e v0.19.1. A série 0.19 adiciona uma interface de fórum de grupo no commit 5f4efdb, muda edições de metadados de grupo para um fluxo de substituição completa no commit da0b753, e substitui o antigo tratamento no-text por supported_kinds no commit bef67d3. Para implementadores de grupos, isso mantém o CLI alinhado com a direção que specs e clientes de grupo estão seguindo.

Atualizações de Projetos

Amethyst

Seguindo a cobertura do Amethyst da semana passada, Amethyst, o cliente Android com uma das mais amplas superfícies de protocolo no Nostr, continuou construindo sobre seu trabalho de carteira e relay após o patch NIP-47. O PR #1853 adiciona consultas COUNT do NIP-45 (Event Counting) nas telas de gerenciamento de relay, para que usuários possam ver quantos eventos cada relay realmente mantém para feed principal, notificações, DMs e dados de índice. O PR #1849 adiciona uploads de arquivos criptografados para chats NIP-17 (Private Direct Messages), com um caminho de retry para uploads não criptografados quando um host de armazenamento rejeita a versão criptografada.

O PR #1791 também traz login completo de bunker desktop NIP-46 (Nostr Connect) com um indicador de heartbeat, o que importa porque falhas de assinatura remota frequentemente parecem quebras aleatórias de UI do lado do usuário. O cliente mostra se o assinador está vivo e quão recentemente ele respondeu, enquanto também torna óbvio quando a sessão atual usa um bunker.

Nostria

Nostria, o cliente multiplataforma construído em torno de uma stack local-first, mergeou o PR #561 adicionando filtragem Web of Trust para feeds e respostas de threads. O recurso usa os dados de rank do serviço de confiança existente e os expõe como filtro de feed e filtro de respostas, ocultando autores cujo rank não alcança o limiar enquanto preserva a estrutura da thread quando descendentes confiáveis estão presentes. Isso dá aos usuários uma camada intermediária entre “mostrar todos” e curadoria baseada em listas hardcoded.

A mesma semana também trouxe o PR #563, que adiciona filtragem de conteúdo e suporte a repost na página de resumo. Fora da lista de PRs rastreados, Nostria também tem preenchido mais de sua superfície para power users. Agora suporta o mais recente serviço Brainstorm Web of Trust com cadastro in-app, junto com fluxos de enviar e receber dinheiro em DMs usando NWC e invoices BOLT-11. Também adiciona tratamento de GIFs nativos do Nostr através do NIP de emoji e um caminho mais robusto de importação RSS para músicos que pode capturar splits Lightning existentes de feeds de podcast. Nostria está tratando ranking, mídia, pagamentos e publicação como uma superfície de app conectada.

Nostur

Nostur, o cliente iOS mantido por nostur-com, abriu o PR #53 para mudar o roteamento outbox de um plano fixo para uma política pontuada. O patch adiciona pontuação randomizada de relay, filtragem de atividade de relay NIP-66 com um feed cacheado do nostr.watch, e Thompson sampling para que dados de sucesso e falha de relay mudem seleções futuras. O design mantém uma válvula de segurança quando muitos relays seriam filtrados e preserva relays .onion. Este é um dos exemplos atuais mais claros de um cliente tratando seleção de relay como um sistema adaptativo.

Nostrability Outbox

Seguindo o relatório de benchmark Outbox anterior, Nostrability Outbox, o projeto de benchmark e análise focado no roteamento de clientes NIP-65 e NIP-66, passou a semana refinando suas próprias afirmações. O PR #35 substitui resultados inflados de Thompson sampling por um re-benchmark completo em 1.511 execuções e recomenda a variante CG3 para roteamento estilo NDK. O PR #43 adiciona comparações de decay e caso de uso, corrige um bug de envenenamento de cache de 0 follows, e re-executa o dataset Telluride após fixar TTLs de cache.

Isso não é trabalho de produto no sentido usual, mas importa para autores de clientes porque os números do projeto agora são mais precisos e menos lisonjeiros nos lugares onde haviam sobreclamado anteriormente. O resultado corrigido ainda é útil. Seleção randomizada continua superando roteamento puramente determinístico nos casos que o Outbox se preocupa, aprendizado estilo Thompson pode melhorar materialmente a cobertura quando clientes persistem histórico útil de relay, e filtragem de atividade NIP-66 elimina tempo desperdiçado em relays mortos. O trabalho também está se transformando em propostas concretas de implementação, incluindo NDK #387, Nostur #53, Amethyst #1833, rust-nostr #1282, welshman #53, e applesauce #54 mais applesauce #55.

Backend do White Noise

whitenoise-rs, o backend Rust usado pelo White Noise e outros ferramentais Marmot, mergeou dois patches de endurecimento de fronteira em torno do tratamento de mídia Blossom. O PR #637 impõe HTTPS em URLs Blossom e adiciona um timeout de upload, enquanto o PR #642 limita downloads de blob a 100 MiB para bloquear pulls de mídia superdimensionados de se transformarem em um caminho de negação de serviço. Para software de mensagens privadas, URLs de mídia são uma das interfaces mais afiadas entre lógica de aplicação criptografada e infraestrutura de rede não confiável. Esta semana a equipe reforçou essa borda.

rust-nostr

rust-nostr, a biblioteca de protocolo Rust, mergeou o PR #1280 adicionando construtores de conveniência para LocalRelayBuilderNip42. Os novos helpers de leitura e escrita dão a setups de relay embutido e teste uma forma mais clara de transformar política de auth NIP-42 em código. Este é um pequeno patch de biblioteca, mas importa para equipes construindo relays locais ou empacotados em apps que precisam de auth habilitado sem repetir boilerplate toda vez.

Pika

Seguindo a cobertura anterior do Pika, Pika, o app de mensagens baseado em Marmot, lançou pika/v1.1.1 e pikachat-v1.1.1 com um ciclo de release focado em convergência de runtime. O PR #542 introduz uma fachada de runtime Marmot compartilhada para o CLI e sidecar, com o host do app migrando para a mesma superfície. O PR #556 reforça o ciclo de vida do agente OpenClaw e estado de provisionamento, enquanto o PR #600 adiciona restauração de backup e segurança de recuperação mais rígida para ambientes gerenciados.

A superfície diretamente voltada ao usuário aqui é menor que no último writeup do Pika, mas a mudança arquitetural é significativa. Puxar lógica de grupo, mídia, chamada e sessão para trás de um runtime compartilhado reduz a chance do app e daemon divergirem conforme a stack Marmot cresce.

Atualizações de NIPs

Mudanças recentes no repositório de NIPs:

Mergeado:

NIP-54 (Wiki): Troca de Asciidoc para Djot (PR #2242): Conteúdo wiki no kind 30818 agora usa Djot como formato de marcação canônico. O texto mergeado adiciona comportamento explícito de wikilink, exemplos de merge-request para kind 818, exemplos de redirecionamento para kind 30819, e exemplos de normalização não-latina para tags d. Isso dá aos implementadores um alvo de parsing mais limpo que Asciidoc e remove mais um caminho de spec que dependia de um toolchain centrado em Ruby.
NIP-19 (Bech32-Encoded Entities): Adiciona limite de entrada (PR #2264): A spec agora recomenda limitar strings de entidades codificadas em Bech32 a 5000 caracteres. Esta é uma mudança pequena com valor real para parsers, porque strings NIP-19 agora aparecem em fluxos QR, deep links, share sheets e entrada colada por usuários em muitos clientes.

PRs Abertos e Discussões:

Arquivo de Chave Nostr para NIP-49 (Private Key Encryption) (PR #2269): Propõe um formato de arquivo .nostrkey para exportação e importação de chaves criptografadas por senha. Se mergeado, daria aos clientes um caminho de backup baseado em arquivo mais normal do que copiar strings ncryptsec brutas por aí.
Consistência de estado de membros para NIP-43 (Relay Access Metadata and Requests) (PR #2267): Adiciona uma seção clarificando que relays devem manter um estado de membros autoritativo por pubkey. Isso simplificaria a lógica de clientes de grupo em torno de mudanças de membros e histórico replicado.
Orientação de exclusão para NIP-17 (Private Direct Messages) (PR #2260): Propõe um caminho concreto para edição e exclusão de mensagens privadas através de eventos de exclusão encapsulados em gift wrap. O trabalho ainda está aberto, mas autores de clientes precisam de uma resposta aqui se NIP-17 vai substituir completamente os fluxos de DM mais antigos.
URI de share-intent para NIP-222 (PR #2266): O rascunho padronizaria como apps mobile e desktop entregam conteúdo compartilhado para um cliente Nostr. Essa é uma das bordas de interoperabilidade mais ásperas nos fluxos atuais de app para app.

NIP Deep Dive: NIP-94 (File Metadata)

NIP-94 define kind 1063 como um evento de metadados de primeira classe para um arquivo. A especificação dá ao evento seu próprio content legível por humanos mais tags legíveis por máquina para URL de download, tipo MIME, hashes, dimensões, previews, fallbacks e dicas de serviço de armazenamento. Isso importa porque o arquivo se torna consultável nos relays como seu próprio objeto. Um cliente não precisa extrair metadados do conteúdo circundante para entender o que o arquivo é.

{
 "id": "6a92ef8d7c3a1b5d4e8f9a0b1c2d3e4f567890abcdef1234567890abcdef1234",
 "pubkey": "f1e2d3c4b5a697887766554433221100ffeeddccbbaa99887766554433221100",
 "created_at": 1742342400,
 "kind": 1063,
 "tags": [
 ["url", "https://downloads.example.org/notedeck/v0.8.0-rc2/notedeck-macos-universal.tar.gz"],
 ["m", "application/gzip"],
 ["x", "4a5b6c7d8e9f00112233445566778899aabbccddeeff00112233445566778899"],
 ["ox", "4a5b6c7d8e9f00112233445566778899aabbccddeeff00112233445566778899"],
 ["size", "48392011"],
 ["dim", "0x0"],
 ["magnet", "magnet:?xt=urn:btih:00112233445566778899aabbccddeeff00112233"],
 ["i", "00112233445566778899aabbccddeeff00112233"],
 ["blurhash", "LEHV6nWB2yk8pyo0adR*.7kCMdnj"],
 ["thumb", "https://downloads.example.org/notedeck/v0.8.0-rc2/thumb.png", "bbccddeeff00112233445566778899aabbccddeeff0011223344556677889900"],
 ["image", "https://downloads.example.org/notedeck/v0.8.0-rc2/screenshot.png", "ccddeeff00112233445566778899aabbccddeeff001122334455667788990011"],
 ["summary", "Signed macOS release artifact for Notedeck v0.8.0-rc2"],
 ["alt", "Notedeck desktop release archive"],
 ["fallback", "https://mirror.example.net/notedeck/v0.8.0-rc2/notedeck-macos-universal.tar.gz"],
 ["service", "nip96"]
 ],
 "content": "Notedeck macOS universal build",
 "sig": "11aa22bb33cc44dd55ee66ff77889900aabbccddeeff0011223344556677889911aa22bb33cc44dd55ee66ff77889900aabbccddeeff00112233445566778899"
}

As tags fazem mais trabalho do que aparentam à primeira vista. x identifica o arquivo servido, enquanto ox identifica o arquivo original antes de qualquer transformação do lado do servidor. As tags de preview permitem que clientes construam índices de arquivos navegáveis sem baixar o ativo completo, e summary pode carregar um excerto curto ao lado deles. fallback dá uma segunda fonte quando a URL principal falha, e service indica o protocolo de armazenamento por trás do arquivo, como NIP-96 ou outro host. NIP-94 portanto fica abaixo de postagem social e acima de armazenamento bruto. Ele descreve o arquivo, não a conversa em torno do arquivo.

É por isso que o atualizador do Notedeck desta semana é interessante. O PR #1326 usa eventos kind 1063 assinados para descoberta de releases de software, e então verifica o binário baixado contra o SHA256 publicado. O mesmo formato de evento pode descrever um artefato de software ou um upload de mídia. NIP-94 é antigo o suficiente para ser estável, mas ainda tem espaço para crescer porque mais projetos estão tratando eventos de metadados como um transporte para máquinas, não apenas como decoração para pessoas.

NIP Deep Dive: NIP-54 (Wiki)

NIP-54 define kind 30818 como um evento de artigo wiki. A especificação trata a tag d como o tópico normalizado do artigo e permite que muitos autores publiquem entradas para o mesmo assunto. O corpo do artigo vive no content, enquanto tags tratam de identidade normalizada, título de exibição, resumos e referências a versões anteriores. Isso significa que NIP-54 não é apenas um formato de conteúdo. É também um problema de recuperação e ranking, porque cada cliente ainda precisa decidir qual versão do artigo mostrar.

{
 "id": "8c94e5d1f2a300112233445566778899aabbccddeeff00112233445566778899",
 "pubkey": "00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff",
 "created_at": 1742342400,
 "kind": 30818,
 "tags": [
 ["d", "nostr-wiki"],
 ["title", "Nostr Wiki"],
 ["summary", "Djot-formatted reference article about Nostr wiki events"],
 ["a", "30818:11223344556677889900aabbccddeeff00112233445566778899aabbccddeeff:nostr-wiki", "wss://relay.example.org", "fork"],
 ["e", "11223344556677889900aabbccddeeff00112233445566778899aabbccddeeff", "wss://relay.example.org", "fork"]
 ],
 "content": "Nostr is a [protocol][] for carrying events across relays.\n\n[protocol]: nostr:nevent1example",
 "sig": "33cc44dd55ee66ff77889900aabbccddeeff0011223344556677889900112233cc44dd55ee66ff77889900aabbccddeeff00112233445566778899001122"
}

O merge desta semana muda a marcação canônica de Asciidoc para Djot no PR #2242. Isso importa para implementadores porque Djot tem uma spec standalone mais precisa e uma história de parser mais simples entre linguagens. O texto mergeado também clarifica como wikilinks por referência resolvem, como merge requests usam kind 818, como redirecionamentos usam kind 30819, e como a normalização da tag d deve se comportar para scripts não-latinos. Essas são as partes que fazem dois clientes independentes concordarem sobre para qual artigo um link aponta.

NIP-54 também ocupa um lugar incomum no protocolo. Um cliente wiki precisa de renderização de conteúdo, mas também precisa de política de ranking. Reações, listas de relay, listas de contatos e sinais explícitos de deferência todos alimentam qual artigo vence para um dado tópico. A troca para Djot não resolve esse problema de ranking, mas remove uma das ambiguidades de parser que estava por baixo dele. É por isso que o merge importa agora: a mudança é menos sobre formatação de prosa mais bonita e mais sobre tornar o comportamento wiki multi-cliente mais fácil de implementar consistentemente.

Construindo algo, ou quer que cubram? Entre em contato via NIP-17 DM no Nostr em npub1wav4fae3gyfy3xj298kxj2mj8phavz7vavps34przq02j7w902qq902923.

Nostr Compass #13

Wed, 11 Mar 2026 00:00:00 +0000

Bem-vindo de volta ao Nostr Compass, seu guia semanal sobre o Nostr.

Esta semana: Shopstr e Milk Market adicionam superfícies MCP para comércio orientado por agentes, enquanto OAuth Bunker, Amber e strfry adicionam suporte a relay auth da NIP-42 (Authentication of Clients to Relays) e eventos protegidos em software de app, signer e relay. Route96 lança duas versões focadas em rotulagem de IA, filas de moderação, perceptual hashing e documentação de servidor legível por máquina. Samizdat, já disponível na web, lançou seu primeiro alpha para Android e depois adicionou suporte de signer da NIP-55 (Android Signer Application). Formstr adiciona cadastro via NIP-49 (Private Key Encryption), Amethyst lança trabalho de resolução NIP-05 (Domain Verification) baseado em Namecoin, Mostro lança a v0.16.4, e o repositório de NIPs faz merge da NIP-91 (AND Operator for Filters) e de orientações defensivas para a NIP-66 (Relay Discovery and Liveness Monitoring).

Notícias

Shopstr e Milk Market abrem superfícies MCP para comércio

Shopstr, o marketplace peer-to-peer com pagamentos Lightning e Cashu, mergeou o PR #234 (commit 94ef7d1), adicionando um servidor MCP com autenticação por chave de API para gerenciamento de contas por agentes. A mudança adiciona .well-known/agent.json para descoberta por agentes, endpoints de onboarding e status do MCP, rotas de criação de pedidos e verificação de pagamento, ferramentas dedicadas de compra e leitura, e uma tela de configurações para chaves de API. O PR #236 estende isso com ações do lado do vendedor para mensagens, endereços, atualizações de pedido e seleção de especificação de produto. Uma correção de segurança no PR #235 substitui o hashing de chave de API com SHA-256 em uma única iteração por PBKDF2 com salt e 100.000 iterações.

Agentes podem ler anúncios da NIP-99 (Classified Listings) e seguir até o checkout usando os fluxos de pagamento já existentes da NIP-47 (Nostr Wallet Connect) e da NIP-60 (Cashu Wallet), sem fazer scraping de páginas nem reverse-engineering do comportamento do cliente.

Milk Market, um marketplace de alimentos em Nostr no milk.market, incorporou a mesma base de MCP e chaves de API no commit da6c0b4. O PR #10 adiciona pedidos por assinatura, mudanças de endereço de entrega após a compra e tratamento de checkout com múltiplos comerciantes e múltiplas moedas para Stripe e outros fluxos de pagamento em fiat. Um PR #11 posterior corrige um bug de inicialização do banco de dados no startup, em que a tabela de publicações falhadas em relays não era criada em instalações novas, causando erros 500 no primeiro carregamento. A interface voltada a agentes funciona com checkout Bitcoin-native no Shopstr ou checkout misto em fiat e Bitcoin no Milk Market.

NIP-42 relay auth chega a bunker, signer e relay

OAuth Bunker, um bunker NIP-46 (Nostr Connect) que conecta provedores OAuth à assinatura Nostr, adicionou login via NIP-07 (Browser Extension Signer), seleção automática de identidade única e limpeza de identidades deletadas (commit f0c7683). Quando existe apenas uma identidade, o bunker agora a seleciona automaticamente em vez de exibir um prompt. Deletar uma identidade também remove suas atribuições e conexões pendentes. O commit 6b8796c adiciona um caminho de configuração ALWAYS_ALLOWED_KINDS para usuários atribuídos, com kind 30078 de dados específicos de app como valor padrão, para que identidades delegadas possam gravar em armazenamento específico do app sem aprovação por evento.

Amber, o principal signer NIP-55 para Android, lançou a v4.1.3-pre4 com quatro pre-releases ao longo da semana. O PR #317 adiciona tratamento de autenticação de relay da NIP-42 para requisições kind 22242. A implementação adiciona uma nova coluna no banco de dados para rastrear permissões específicas por relay, com um índice único em (pkKey, type, kind, relay). Usuários veem uma tela dedicada de autenticação onde podem permitir ou negar por relay, ou em todos os relays com escopo curinga *, e persistir essa escolha. Permissões com curinga limpam todas as entradas específicas por relay de um kind. O PR #318 complementa isso ao refatorar as telas de requisição multi-evento para exibir detalhes inline com cartões composable, em vez de navegar para uma tela separada. A release também atualiza os relays de perfil padrão, adiciona exibição de requisições em bottom sheet e corrige um crash em dispositivos MediaTek ao desabilitar o keystore StrongBox.

No lado do relay, o strfry PR #156 implementa o tratamento da NIP-42 para eventos protegidos da NIP-70, e o PR #176 rejeita reposts que incorporam eventos protegidos.

Notedeck adiciona limites de relay da NIP-11 e recursos do Agentium

Notedeck, o cliente desktop nativo da equipe do Damus, mergeou 14 PRs nesta semana. O PR #1316 adiciona busca de limites de relay da NIP-11 (Relay Information Document), então todos os relays de outbox agora respeitam max_message_length e max_subscriptions do documento de informações do relay. A implementação inclui processamento em background, exponential backoff com jitter para retries de conexão e headers HTTP Accept customizados. O PR #1312 corrige um bug em que DMs às vezes deixavam de carregar após a troca de conta, e o PR #1333 adiciona um mecanismo de backoff à comunicação multicast com relays para evitar spam de broadcast em caso de erro.

O subsistema Agentium, a UI integrada de agente de programação do Notedeck, chamado internamente de “Dave”, recebeu colagem de imagens da área de transferência, configurações nomeadas de execução que sincronizam entre dispositivos via eventos kind 31991 da NIP-33 (Parameterized Replaceable Events), um criador de git worktree e um seletor de modelo para escolher backends por sessão (PR #1336). O PR #1338 integra egui_kittest para testes headless de UI, e o PR #1339 adiciona um cartão no dashboard para rastrear novas criações de listas de contatos por cliente. Um PR #1314 ainda aberto porta a resolução Namecoin da NIP-05 do Amethyst para o Notedeck com buscas ElectrumX, roteamento Tor via SOCKS5 e integração com a barra de busca.

diVine lança v1.0.6 com infraestrutura de testes E2E e importação NIP-49

diVine, o cliente de vídeos curtos em loop que restaura arquivos do Vine em divine.video, lançou a v1.0.6 com 127 PRs mergeados. A release adiciona importação de conta da NIP-49, suporte externo à NIP-05, tratamento de múltiplas contas, builds para macOS e Linux experimental, e uma biblioteca redesenhada de rascunhos e clips apoiada em armazenamento local.

No lado de engenharia, o PR #1928 adiciona uma infraestrutura completa de testes de integração E2E usando Patrol para automação de UI nativa contra uma stack backend em Docker, relay, API, Blossom, Postgres, Redis e ClickHouse. Cinco testes da jornada de autenticação cobrem cadastro, verificação, redefinição de senha, expiração de sessão e refresh de token. O PR #2105 muda o carregamento de vídeo de HLS-first para MP4 direto com fallback automático para HLS, reduzindo tempos de carregamento de 30 a 60 segundos para algo praticamente instantâneo. O PR #2076 coloca em cache a resposta da API do feed inicial em SharedPreferences para exibição instantânea em cold start. O PR #2104 força rótulos de conteúdo ai-generated a permanecerem ocultos nos feeds, e o PR #2100 adiciona uma configuração de segurança para mostrar apenas vídeos hospedados pelo diVine. A migração do cache de perfil de Hive para Drift continua nos PR #1881, PR #1883 e PR #1903, substituindo cerca de 1.074 linhas de código Hive por DAOs em Drift.

Vector v0.3.2 entrega sincronização negentropy da NIP-77 e melhorias de MLS

Vector, o mensageiro desktop focado em privacidade que usa criptografia de grupo MLS com a NIP-17 (Private Direct Messages) e criptografia da NIP-44 (Encrypted Payloads), lançou a v0.3.2. A principal mudança é a negentropy da NIP-77 para sincronização de grupos MLS (commit b06adf4), que recupera mensagens perdidas de forma muito mais rápida usando boot paralelo. A release também adiciona um motor de áudio reconstruído com suporte completo a Linux, spoilers de imagem com pré-visualizações borradas, hyperlinks clicáveis com rich link previews, notificações @mention com @everyone para admins de grupo, autocomplete de shortcode de emoji, silenciamento de grupos, toque para reagir em reações existentes e uploads de arquivo canceláveis. O Vector filtra explicitamente eventos de chat em grupo da NIP-17 (commit 2179a51), usando MLS exclusivamente para criptografia de grupo.

Lançamentos

Route96 v0.5.0 e v0.5.1

Route96, um servidor de mídia com suporte a Blossom e à NIP-96 (HTTP File Storage), lançou a v0.5.0 e a v0.5.1. A v0.5.0 adiciona rotulagem automatizada de IA, backfill retroativo para uploads sem rótulo, filas de moderação para arquivos sinalizados, rejeição de privacidade baseada em EXIF e tratamento de hashes banidos.

A v0.5.1 adiciona hashes perceptuais de imagem, locality-sensitive hashing para busca de imagens semelhantes, endpoints administrativos em lote e um SKILL.md publicado descrevendo a superfície de API do servidor para Blossom e NIP-96 voltada a tooling de agentes. O PR #58 move workers de background para tasks Tokio totalmente assíncronas, e o commit 97b00a3 adiciona backoff para evitar hot loops.

Samizdat v1.0.0-alpha

Samizdat, um leitor e publicador de textos longos disponível em samizdat.press, lançou seu primeiro build Android na v1.0.0-alpha. O app abre em uma página Press curada com artigos longos no Nostr e navegação em abas inferiores entre Press, Feed, Saved e Write. O build Android adiciona armazenamento nativo de chaves usando criptografia do Android Keystore com desbloqueio biométrico, lida com URIs nostr: e deep links de samizdat.press, e oferece handoff para signer via seletor de apps do Android, Amber, Primal e outros, em vez de exigir importação direta de chave. Pull-to-refresh, tratamento de safe area em diferentes tamanhos de tela e integrações nativas de compartilhamento, clipboard, haptics e splash screen agora fazem parte do shell Android, e não do wrapper web.

O commit d17308f adiciona assinatura baseada em intent da NIP-55 para os fluxos Amber e Primal, e o commit e29dab8 substitui um workaround de ponte em JavaScript por um plugin nativo Capacitor usando startActivityForResult. O app exige Android 7.0+ (API 24), é distribuído como APK de debug neste alpha e ainda não tem notificações push. Hoje a publicação depende de um app signer, enquanto o login com nsec cobre leitura local e acesso à conta.

Calendar by Form* v0.2.0

Calendar by Form*, um app de calendário descentralizado com compartilhamento privado de eventos da NIP-59 (Gift Wrap) disponível em calendar.formstr.app, lançou a v0.2.0 com o PR #38. A release estende o tratamento de eventos recorrentes da NIP-52 (Calendar Events), avançando além da base de evento único da v0.1.0. As mudanças subjacentes também tocam armazenamento local de eventos, tratamento de signer e plumbing de notificações no Android. Este é o segundo aplicativo ativo da organização Formstr após a migração de repositório no mês passado.

Mostro v0.16.4

Mostro, a exchange peer-to-peer de Bitcoin construída sobre Nostr, lançou a v0.16.4. As correções de restauração de sessão de disputa (PR #599) e de auto-close (PR #606) cobertas na semana passada estão incluídas. Novidade nesta release: o PR #625 adiciona um campo days a eventos de avaliação de usuário do kind 38384, o PR #612 adiciona expiração a esses eventos de avaliação, e o PR #614 troca a expiração hardcoded de 24 horas de eventos de pedido por configurações de expiração definidas em configuração. O PR #622 adiciona uma verificação de idempotência para evitar pagamentos duplicados de taxa de desenvolvimento.

Mostro Mobile v1.2.1

Mostro Mobile, o cliente Flutter da exchange P2P Mostro, lançou a v1.2.1 com 11 novos recursos e 11 correções de bugs. A release adiciona renderização de multimídia criptografada no chat de disputa (PR #514), auto-close da UI de disputa quando pedidos chegam a estado terminal (PR #503), leitura de QR para importação de carteira NWC (commit 12eaee4), traduções em francês e tratamento de notificações push via FCM. O PR #496 corrige um bug de padding em assinaturas Schnorr ao fixar a dependência bip340 na v0.2.0.

0xchat v1.5.4

0xchat, o cliente de mensagens ao estilo Telegram com suporte a Cashu, lançou a v1.5.4 focada em correções para desktop Linux: ícones de dock do AppImage, renderização de emoji, travamentos no menu de contexto e congelamentos na UI de resposta e cópia. A release também corrige problemas de upload de imagem e integração com npub.cash. O PR #49 elimina rebuilds desnecessários de UI ao remover um timer de polling de 3 segundos que forçava repaints glassmorphic sem fazer nada, e destrava a inicialização do login ao carregar o cache de eventos em paralelo, em vez de bloquear startup de relay, contatos e canais.

Keep v0.6.0

Keep, um signer threshold FROST para Android com suporte à NIP-55 e à NIP-46, lançou a v0.6.0 e a v0.6.1. A v0.6.0 adiciona coordenação de descritores de carteira e UI de gerenciamento, fluxo de backup/restore com autenticação biométrica (PR #184), recuperação de nsec a partir de threshold shares (PR #187), geração cross-platform de frame QR animado via Rust UniFFI (PR #188) e trilha de auditoria de assinatura com verificação de cadeia (PR #189). A v0.6.1 troca a licença de AGPL-3.0 para MIT (PR #191).

njump v0.3.0

njump, o gateway estático para visualizar conteúdo Nostr em njump.me, lançou a v0.3.0 com uma mudança incompatível no parsing de códigos note1 e uma atualização da biblioteca Nostr subjacente.

Roadstr v0.1.1

Roadstr, um app descentralizado de relato de eventos na estrada usando Nostr, lançou sua primeira demo na v0.1.1. O app exibe eventos rodoviários em um mapa usando vector tiles do openfreemap.org.

Bitcredit v0.5.3

Bitcredit, uma aplicação de e-bills com camada de transporte Nostr e relay dedicado em bit.cr, lançou a v0.5.3. O PR #846 adiciona os campos payment_actions e bill_state à API para estado de pagamento e aceitação, e o PR #849 corrige o tratamento de endereços de assinatura para signers anônimos.

OpenChat v0.1.0-alpha.3

OpenChat, uma aplicação de chat construída sobre as bibliotecas .NET MLS e C# do protocolo Marmot, lançou a v0.1.0-alpha.3. A release adiciona suporte a signer externo para Amber e fluxos da NIP-46 (commit e568d97), move a persistência do estado MLS para dentro do serviço MLS para eliminar perda de dados na janela de crash (commit 4720bc8) e publica builds para Windows, Linux e Android via um novo pipeline de CI.

OpenSignal v1.0.0

OpenSignal, um copiloto de trading em Kotlin Multiplatform para Nostr, lançou a v1.0.0. A release empacota módulos KMP compartilhados para lógica de domínio, renderização de gráficos, autenticação e publicação em Nostr, suporte a uploads Blossom via NIP-96 e hooks de inferência de IA baseados em ONNX nos shells Desktop e Android. A arquitetura publicada também inclui um serviço de IA em FastAPI para análise de screenshots de gráficos, pipelines de treinamento de modelo e um risk engine que produz planos estruturados de trade com sizing e avisos. O login aceita tanto chaves nsec brutas quanto signers externos, e o fluxo de saída termina em publicação de eventos Nostr, e não apenas em análise local.

Atualizações de Projetos

Formstr

Formstr, a alternativa ao Google Forms no Nostr, mergeou o PR #434 (commit e9c4fd5), adicionando um fluxo de cadastro que usa chaves privadas criptografadas da NIP-49 (Private Key Encryption). Antes dessa mudança, usuários precisavam de uma extensão de navegador NIP-07 ou de colar um nsec bruto para usar o Formstr. O novo fluxo gera um par de chaves no lado do cliente, criptografa a chave privada com uma senha escolhida pelo usuário pelo esquema scrypt + XChaCha20-Poly1305 da NIP-49 e armazena a string ncryptsec resultante. Depois disso, usuários podem entrar novamente só com a senha, sem instalar uma extensão signer. O gerenciamento de chaves permanece no lado do cliente durante todo o processo.

Amethyst

Amethyst, o cliente Android cheio de recursos, mergeou quatro PRs que entregam o trabalho de resolução NIP-05 apoiado em Namecoin que estava aberto na semana passada. O PR #1734 adiciona verificação NIP-05 resistente à censura via ElectrumX para identificadores .bit, d/ e id/. Quando o Amethyst detecta um desses sufixos em um campo NIP-05, ele consulta um servidor ElectrumX-NMC pelo histórico de transações do nome, analisa o script NAME_UPDATE da saída mais recente para extrair a pubkey Nostr e rejeita nomes mais antigos que 36.000 blocos, a janela de expiração do Namecoin. Conexões ElectrumX passam por SOCKS5 quando o Tor está ativado, com seleção dinâmica de servidor entre endpoints clearnet e .onion. Um cache LRU com TTL de uma hora evita consultas repetidas ao blockchain.

O PR #1771 corrige condições de corrida e problemas de corretude no resolver desse fluxo. O PR #1785 permite que novos usuários importem uma lista de follows durante o cadastro a partir de identificadores NIP-05 comuns ou dos apoiados em Namecoin. O PR #1786 adiciona configurações customizadas de servidor ElectrumX para que usuários escolham qual servidor fará suas consultas.

nostr-idb

nostr-idb, uma biblioteca que fornece métodos auxiliares para armazenar eventos Nostr em IndexedDB, mergeou o PR #6 adicionando suporte a filtros de tag AND da NIP-91. A mudança adiciona semântica de interseção ao matching de filtros no lado do cliente, para que consultas em IndexedDB possam exigir todos os valores de tag listados, em vez de qualquer um deles. O PR #8 atualiza a biblioteca para a interface mais recente do NIP-DB, e um commit b49b3d3 posterior corrige um deadlock em subscribe e remove o nostr-tools como dependência de produção.

Pensieve

Pensieve, um indexador Nostr archive-first com analytics em ClickHouse, mergeou o PR #8 adicionando enforcement de TTL de cache por entrada e coalescência de misses por chave para reduzir picos de CPU na API. Os endpoints de séries temporais mais caros, estatísticas de engajamento, atividade por hora e atividade por kind, agora usam TTLs de 10 minutos no servidor em vez de disparar tempestades sincronizadas de recomputação.

Blossom

Blossom, o protocolo e stack de servidor para hospedagem descentralizada de mídia, mergeou duas atualizações de autorização do BUD-11. O PR #91 move a autorização opcional para seu próprio BUD e esclarece o papel das tags x e server. O PR #93 limpa o comportamento de autenticação por endpoint e formaliza o header X-SHA-256 para verificação de upload. Os dois PRs consolidam a lógica de autenticação no BUD-11 e removem ambiguidades sobre hashing de requisições nos fluxos de upload, deleção e gerenciamento de mídia.

Atualizações de NIPs

Mudanças recentes no repositório de NIPs:

Mergeado:

NIP-91 (AND Operator for Filters) (PR #1365): Adiciona semântica de interseção para filtros de tags, permitindo que relays respondam a consultas que exigem todos os valores de tag listados, e não qualquer um deles. Isso reduz a pós-filtragem no lado do cliente e o consumo de banda em consultas pesadas em tags.
NIP-66 (Relay Discovery and Liveness Monitoring): Defensive Measures (PR #2240): Após o trabalho de benchmark de outbox coberto na semana passada, a spec agora adiciona avisos sobre caminhos de falha nos dados de monitoramento de relay. Clientes não devem exigir eventos de monitoramento kind 30166 para funcionar. Um monitor pode estar errado, desatualizado ou ser malicioso. Espera-se que clientes cruzem múltiplas fontes e evitem cortar grandes partes do grafo de relays de um usuário com base em um único feed.
NIP-39 (External Identities in Profiles): kind 10011 Registry Cleanup (PR #2256): Adiciona a referência ao kind 10011 diretamente na spec, alinhando-a com a implementação do Amethyst coberta na semana passada.

PRs abertos e discussões:

NIP-70 (Protected Events): Reject reposts that embed protected events (PR #2251): Se um relay aplica a NIP-70 ao evento original mas aceita reposts contendo o mesmo conteúdo, a tag - perde efeito prático. Este PR adiciona a regra de que relays também devem rejeitar reposts kind 6 e kind 16 de eventos protegidos. O strfry PR #176 já implementa isso.
NIP-71 (Video Events): Multiple Audio Tracks (PR #2255): Adiciona tags imeta de áudio para trilhas alternativas, variantes de idioma e streams apenas de áudio. Um cliente pode manter um arquivo de vídeo estável enquanto troca o idioma do áudio, ou servir o áudio como faixa separada para conteúdo em estilo podcast.
NIP-11 (Relay Information Document) and NIP-66 Relay Attributes (PR #2257): Adiciona um campo estruturado attributes aos documentos de informação de relay, dando a clientes e ferramentas de descoberta metadados legíveis por máquina além da descrição em texto livre atual.

NIP Deep Dive: NIP-49 (Private Key Encryption)

A NIP-49 define como um cliente criptografa uma chave privada com uma senha e codifica o resultado como uma string bech32 ncryptsec. O Formstr usa a NIP-49 em seu novo fluxo de cadastro.

O formato não está ligado a um kind de evento dedicado. Um cliente começa com a chave privada secp256k1 bruta de 32 bytes, deriva uma chave simétrica a partir da senha do usuário com scrypt, criptografa a chave com XChaCha20-Poly1305 e então encapsula o resultado em uma string bech32 ncryptsec. Um flag de um byte registra se a chave já foi manipulada de forma insegura antes da criptografia.

{
 "id": "4d47f4f0a6f6edbc1bbd7f4e2a45ec68f27cba91d6c6ab5cf28d8d87b0f3d57e",
 "pubkey": "1f8b4c3e7b0f9451d4f9b8a7c6e5d4c3b2a1908f7e6d5c4b3a29181716151413",
 "created_at": 1741699200,
 "kind": 30078,
 "tags": [
 ["d", "encrypted-key-backup"],
 ["format", "ncryptsec"],
 ["encryption", "nip49"]
 ],
 "content": "ncryptsec1qgg9947rlpvqu76pj5ecreduf9jxhselq2nae2kghhvd5g7dgjtcxfqtd67p9m0w57lspw8gsq6yphnm8623nsl8xn9j4jdzz84zm3frztj3z7s35vpzmqf6ksu8r89qk5z2zxfmu5gv8th8wclt0h4p",
 "sig": "6a8f6e4b2d1901735f0ad4b6e8c1f3a579d0e2b4c6f8a1d3e5f7091b2c3d4e5f11223344556677889900aabbccddeeff00112233445566778899aabbccddeeff"
}

O evento JSON acima é um exemplo em nível de aplicação, não um requisito da NIP-49. O NIP padroniza o formato da chave criptografada. Um cliente pode armazenar o ncryptsec localmente, sincronizá-lo por meio de armazenamento específico do app ou exportá-lo como string de backup. Senhas são normalizadas para Unicode NFKC antes da derivação da chave, para que a mesma senha seja descriptografada de forma consistente entre clientes e plataformas.

O flag de segurança da chave, com um byte, tem três valores definidos: 0x00 significa que o histórico de tratamento da chave é desconhecido, 0x01 significa que a chave foi comprovadamente manipulada de forma insegura, por exemplo, colada como texto plano em um formulário web antes da criptografia, e 0x02 significa que a chave foi gerada e criptografada em um contexto seguro e nunca foi exposta. Clientes podem usar isso para exibir avisos ao importar chaves com histórico inseguro conhecido.

A NIP-49 protege chaves melhor do que um export simples de nsec, mas a criptografia só é tão forte quanto a senha e o custo scrypt configurado. Valores maiores de LOG_N tornam tentativas de adivinhação offline mais caras, mas também tornam operações legítimas de descriptografia mais lentas. A spec adverte contra publicar chaves criptografadas em relays públicos, já que atacantes se beneficiam de colecionar ciphertext para cracking offline. Para comparação, a assinatura remota da NIP-46 evita expor chaves por completo, e a assinatura Android da NIP-55 mantém chaves dentro de um app signer dedicado. A NIP-49 ocupa um papel diferente: backup criptografado portátil para usuários que gerenciam suas próprias chaves.

As implementações incluem o Formstr PR #434 para cadastro, o Amber para backup e restore de ncryptsec, o diVine v1.0.6 para importação de conta, o Keep v0.6.0 para exportação de FROST shares e ferramentas de gerenciamento de chaves como nsec.app e Alby.

NIP Deep Dive: NIP-70 (Protected Events)

A NIP-70 define eventos protegidos. Quando um evento carrega a tag ["-"], um relay deve rejeitá-lo a menos que exija autenticação da NIP-42 e que a pubkey autenticada corresponda ao autor do evento.

O fluxo de autenticação da NIP-42 funciona da seguinte forma: o relay envia um desafio AUTH contendo uma string aleatória, e o cliente responde com um evento kind 22242 assinado cujas tags incluem a URL do relay e o desafio. O relay verifica a assinatura e checa se a pubkey no evento de autenticação corresponde à pubkey do evento protegido que está sendo publicado. Se as pubkeys não corresponderem, o relay rejeita o evento com o prefixo de mensagem restricted.

O conteúdo do evento ainda pode ser público. A tag - controla apenas quem pode publicar o evento em um relay que respeita a tag. Isso cobre feeds semi-fechados da NIP-29 (Simple Groups), espaços de relay apenas para membros e outros contextos em que o autor quer limitar a redistribuição pelo grafo de relays. A NIP-70 é uma convenção de tag única, não um novo kind de evento, então qualquer kind existente pode carregar a tag -.

{
 "id": "cb8feca582979d91fe90455867b34dbf4d65e4b86e86b3c68c368ca9f9eef6f2",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1707409439,
 "kind": 1,
 "tags": [
 ["-"]
 ],
 "content": "hello members of the secret group",
 "sig": "fa163f5cfb75d77d9b6269011872ee22b34fb48d23251e9879bb1e4ccbdd8aaaf4b6dc5f5084a65ef42c52fbcde8f3178bac3ba207de827ec513a6aa39fa684c"
}

Mesmo que um relay bloqueie a publicação de terceiros do evento original, alguém ainda pode republicar o conteúdo dentro de um repost. O PR #2251 trata disso ao exigir que relays também rejeitem reposts kind 6 e kind 16 de eventos protegidos. O strfry PR #156 adiciona tratamento de autenticação da NIP-42 para eventos protegidos, e o strfry PR #176 bloqueia reposts que incorporam conteúdo protegido.

A NIP-70 controla o comportamento do relay. Um destinatário ainda pode copiar o conteúdo para outro lugar, e a spec diz isso explicitamente. A tag - dá aos relays um sinal legível por máquina para recusar republicação. Para comparação, a NIP-62 (Request to Vanish) pede que relays deletem dados depois do fato, enquanto a NIP-70 impede publicação não autorizada no momento da ingestão. As duas são complementares: um autor pode marcar eventos como protegidos para limitar a disseminação e, mais tarde, pedir deleção se quiser que o conteúdo seja removido dos relays que o aceitaram.

Isso é tudo por esta semana. Está construindo algo ou tem notícias para compartilhar? Fale conosco por DM via NIP-17 ou nos encontre no Nostr.

Nostr Compass #12

Wed, 04 Mar 2026 00:00:00 +0000

Bem-vindo de volta ao Nostr Compass, seu guia semanal sobre o Nostr.

Esta semana: O Marmot Development Kit lança sua primeira versão pública com mídia criptografada e bindings multi-linguagem. Nostrability publica benchmarks do modelo outbox em 14 algoritmos de seleção de relay. Wisp vai do primeiro alpha ao beta em oito dias com Tor e assinatura NIP-55 (Android Signer Application). NIP-91 (filtros AND) é mergeado. Vector v0.3.1 entrega sincronização negentropy com ganhos de desempenho de 15x. Esta edição também inclui a retrospectiva Cinco Anos de Fevereiros do Nostr, traçando o protocolo desde uma reescrita de spec servindo três relays, passando pela explosão do Damus na App Store, até redes mesh e propostas de agentes de IA.

Notícias

Modelo Outbox Sob o Microscópio

Nostrability publicou uma série de benchmarks do modelo outbox testando quão bem diferentes algoritmos de seleção de relay recuperam eventos da rede descentralizada de relays. O projeto mergeou 16 PRs e 76 commits em dez dias, produzindo o que pode ser a análise empírica mais completa de estratégias de implementação do NIP-65 (Relay List Metadata) até hoje.

Os benchmarks testam 14 algoritmos de seleção de relay contra listas de follows reais em 15 clientes e bibliotecas em cinco linguagens. Uma abordagem de linha de base consultando apenas relays populares recupera aproximadamente 26% dos eventos. Set-cover guloso com Thompson Sampling alcança 80-90% de recall. Adicionar uma variante sensível a latência usando desconto hiperbólico e rastreamento de latência de relay EWMA elevou a completude de 62-80% para 72-96% na marca de 2 segundos em seis perfis de teste.

A filtragem de relays inativos do NIP-66 (Relay Monitoring) provou ser consequente. Pré-filtrar candidatos de relay contra dados de atividade do nostr.watch removeu 40-64% dos relays inativos e dobrou as taxas de sucesso de relay de 30% para 75-85%. Tempos de carregamento de feed caíram 39% (de 40 segundos para 24 segundos em 10 perfis). Uma simulação de corrida EOSE descobriu que esperar pelo EOSE mais um período de graça de 200ms melhorou a completude em comparação com parar no primeiro relay a terminar.

Para clientes que não conseguem reescrever completamente seu roteamento de relay, uma abordagem de “enriquecimento outbox híbrido” adiciona consultas outbox por autor sobre os relays hardcoded existentes do app. Esse híbrido alcançou 80% de recall de eventos de um ano contra os 26% da linha de base, oferecendo um caminho de migração para clientes com arquiteturas de relay legadas.

ContextVM Abre NIP de MCP e Lança Gift Wraps Efêmeros

ContextVM, o protocolo fazendo ponte entre o Nostr e o Model Context Protocol, abriu duas propostas no repositório de NIPs esta semana. O PR #2246 formaliza CVM como uma convenção para transportar mensagens MCP JSON-RPC sobre Nostr usando eventos efêmeros kind 25910. O PR #2245 estende o NIP-59 (Gift Wrap) com um kind efêmero (21059) que segue a semântica efêmera do NIP-01 (Basic Protocol Flow), permitindo que relays descartem mensagens encapsuladas após a entrega.

A convenção de gift wrap efêmero foi lançada como CEP-19 na família de lançamento ContextVM SDK v0.6.x. A implementação do SDK adiciona um enum GiftWrapMode com três configurações: OPTIONAL (aceita ambos os kinds e auto-detecta capacidade do par), EPHEMERAL (apenas kind 21059) e PERSISTENT (apenas kind 1059). Para chamadas de ferramentas de IA, o modo efêmero evita armazenar tráfego intermediário de requisição-resposta nos relays, reduzindo tanto custos de armazenamento quanto exposição de privacidade.

Novos servidores MCP públicos apareceram na rede de operadores independentes, incluindo um servidor de consulta Wolfram Alpha. A equipe ContextVM publicou CEP-15 (esquema de ferramentas comuns) e CEP-17 (publicação de lista de relays de servidor) junto com o ciclo de lançamento v0.6.x.

Marmot Development Kit Lança Primeira Versão Pública

MDK (Marmot Development Kit), a biblioteca Rust que alimenta mensagens criptografadas com Marmot em Pika e White Noise, lançou v0.6.0 como sua primeira versão pública. Mais de 200 PRs foram mergeados nesta versão, com seis novos contribuidores.

O lançamento inclui suporte a mídia criptografada (MIP-04) com derivação de seed HKDF (MIP-01 v2), resolução determinística de corrida de commits (MIP-03), armazenamento local criptografado, validação de autorização de admin para commits e propostas Marmot, e suporte GREASE para extensibilidade do protocolo. Bindings são fornecidos para Kotlin, Python, Ruby e Windows junto com compilação cruzada para Android. A biblioteca atualiza para OpenMLS 0.8.0 com correções de avisos de segurança e um tipo Secret<T> que zeroiza valores sensíveis na memória.

Uma mudança de protocolo complementar (MIP-03) substituiu a criptografia NIP-44 (Encrypted Payloads) por ChaCha20-Poly1305 para mensagens kind 445. NIP-44 exigia entrada de string UTF-8 conforme sua especificação, tornando impossível passar bytes brutos de mensagem Marmot através de bibliotecas Nostr TypeScript padrão. A substituição deriva chaves diretamente do segredo exportador do Marmot. Essa mudança que quebra compatibilidade exigiu atualizações coordenadas em toda a spec core, MDK e TypeScript SDK.

marmot-ts, a implementação TypeScript mantida por hzrd149, mergeou quatro PRs com mudanças que quebram a API. Uma atualização omnibus adicionou um gerenciador de pacote de chaves para ciclo de vida criar/publicar/rotacionar, um método conveniente sendChatMessage, pré-visualização de convite sem entrar (readInviteGroupInfo), auto-atualização para rotações de sigilo futuro e logging de debug estruturado. APIs de descriptografia de grupo foram renomeadas de readGroupMessage para decryptGroupMessage com variantes de resultado mais ricas (processed/skipped/rejected/unreadable). gzuuus contribuiu limpeza de exemplos com suporte a relay NIP-65 e tratamento de pacote de chaves de último recurso conforme MIP-00.

O White Noise CLI (wn), o backend Rust que alimenta tanto o app mobile quanto o novo TUI, mergeou 16 PRs em dez dias. O tratamento do ciclo de vida do assinador ganhou segurança contra cancelamento através de um scope guard RAII (PR #538), corrigindo uma classe de bugs onde operações abortadas podiam vazar estado do assinador. O login agora bloqueia quando listas de relay obrigatórias (kind 10002/10050/10051) estão ausentes (PR #515), e assinaturas de giftwrap recorrem a relays NIP-65 quando listas de inbox estão ausentes (PR #518). Um modo debug (PR #528) expõe consultas ao banco de dados e inspeção da árvore de ratchet MLS como saída JSON. Outras correções trataram recuperação de assinatura após re-registro do assinador, timing de catch-up de mensagens de boas-vindas, validação de filtro de relay e limites de raio de busca de usuários.

O Marmot teve expansão significativa além da stack Rust core esta semana. White Noise TUI, uma interface baseada em terminal para a stack de mensagens White Noise, foi lançado em 3 de março. Ele encapsula o CLI wn como um subprocesso e renderiza sua saída JSON através de uma arquitetura unidirecional inspirada em Elm, fornecendo navegação entre múltiplas conversas com indicadores de não lidos, criação de grupo e busca de membros, streaming de mensagens em tempo real e reações com emoji pelo terminal.

DavidGershony publicou uma stack Marmot completa em C# espelhando a arquitetura em camadas do ferramental Rust. dotnet-mls implementa primitivas criptográficas MLS RFC 9420 em C#. marmot-cs constrói sobre isso para adicionar transporte por relay Nostr, funcionando como equivalente em C# do MDK. OpenChat, um app desktop multiplataforma construído com .NET 9 e Avalonia UI, une ambos em um cliente de chat funcional com DMs NIP-44, criptografia de grupo Marmot, assinatura remota NIP-46 (Nostr Connect) e indicadores de status multi-relay.

MDK PWA Reference fornece um template Progressive Web App para construir aplicações criptografadas com Marmot, com suporte experimental para participação de agentes de IA em chats de grupo e pagamentos Bitcoin via infraestrutura de carteira Arkade.

Wisp Sai do Alpha para o Beta

Wisp é um novo cliente Nostr para Android que foi do primeiro alpha em 24 de fevereiro ao v0.3.4-beta em 3 de março, produzindo 19 lançamentos, 115 PRs mergeados e 276 commits em oito dias.

A trajetória de recursos cobre terreno que a maioria dos clientes leva meses para alcançar. A v0.1.0 foi lançada com suporte ao modelo de relay outbox/inbox e fluxos de onboarding. Na v0.1.3, o cliente tinha assinatura baseada em intent NIP-55 para Amber, um proxy SOCKS5 Tor embutido para conectividade de relay .onion, e NIP-47 (Nostr Wallet Connect). A v0.2.0 graduou para beta com filtragem de lista de mute e suporte a emoji personalizado, enquanto a v0.2.4 adicionou overlays de aviso de conteúdo. A série v0.3.x introduziu proof-of-work NIP-13 para notas, mineração PoW em background com configurações persistentes, armazenamento de relay .onion e notificações de mute de thread.

Tradução no dispositivo via Google ML Kit roda localmente sem acesso à rede após o download inicial do modelo. Uma visualização interativa de grafo social usa uma simulação de física velocity Verlet a aproximadamente 30fps com navegação pinch-to-zoom e inspeção de perfil.

Lançamentos

Vector v0.3.1

Vector, o app de mensagens criptografadas com Marmot, lançou v0.3.1 com melhorias de gerenciamento de grupo e trabalho de desempenho. Grupos multi-admin, convites em massa, convite por npub e avatares de grupo expandem os recursos de colaboração. Notificações em background no Android agora suportam ações inline de Responder e Marcar como Lido.

Sincronização determinística baseada em negentropy recupera histórico completo de conversas incluindo mensagens perdidas durante períodos offline. Voz-para-texto reconstruído com aceleração GPU no Android. O tratamento de anexos de arquivo foi reformulado com progresso de download, estados de retry, zip-e-envio de diretório e indicadores de progresso ao vivo em toda parte. O desempenho melhorou mais de 15x em tempo de inicialização, processamento de imagem, reprodução de áudio e responsividade geral da UI. O tamanho de instalação do app caiu mais de um terço, com o frontend reduzido aproximadamente pela metade. Suporte a Android ARM de 32 bits foi adicionado.

Alby Hub v1.21.5

Alby Hub, o nó Lightning auto-custodial com suporte a Nostr Wallet Connect (NIP-47), lançou v1.21.5. Um segundo relay foi adicionado à configuração NWC padrão, melhorando a confiabilidade durante reinicializações de relay. Uma correção para dados de zap inválidos na lista de transações resolve um problema de exibição com eventos NIP-57 (Lightning Zaps) malformados. Novas entradas na app store incluem Alby CLI e LNVPS.

nospeak v0.12.x

nospeak, o cliente Nostr de mensagens baseado em texto, lançou três versões durante o período. v0.12.0 adicionou bloqueio de app por PIN com teclado de 4 dígitos e mais de 15 novas traduções de idiomas incluindo bengali, tailandês, vietnamita, hindi, árabe, hebraico, urdu, turco, japonês, chinês, coreano, holandês, polonês, russo e persa com suporte RTL. v0.12.1 introduziu um tema Cypher com fundos preto puro e acentos ciano, além de geração de poster de vídeo para Android. v0.12.2 adicionou exportação de chat e Ver Perfil nos menus de contato.

Citrine v2.0.0-pre2

Citrine, o relay pessoal Android de greenart7c3, lançou v2.0.0-pre2 com melhorias de desempenho de relay através de novos índices de banco de dados e coroutines Kotlin reestruturadas. Cada app web hospedado agora inicia em sua própria porta. Busca full-text e uma tela de eventos redesenhada com expansão de eventos completam as mudanças.

NoorNote v0.5.x

NoorNote, uma aplicação de anotações baseada no Nostr, lançou 8 versões de v0.5.0 até v0.5.7. O lançamento da v0.5.0 no Android adicionou suporte ao assinador Amber NIP-55 e publicação de notas NIP-71 (Video Events). Uma página de boas-vindas redesenhada na v0.5.1 incluiu pré-visualizações de timeline pública e reduziu o APK para 15 MB. O Relay Browser na v0.5.2 permite que usuários naveguem em timelines públicas de relays via URLs compartilháveis, junto com download de mídia e reações de emoji personalizado NIP-30. Lançamentos subsequentes até a v0.5.7 trataram condições de corrida de sincronização no sistema de compartilhamento de notas colaborativas “tribes”.

NosCall v0.5.1

NosCall, o app de chamadas de voz e vídeo no Nostr, lançou v0.5.1 com suporte a mensagens de voz, uma experiência desktop otimizada com entrada de grupo, favoritos de contato no desktop, notas e filtragem de contatos, opções de exportação e limpeza de dados, e suporte a acessibilidade de tamanho de fonte do sistema.

Shosho v0.13.0

Shosho, o app de transmissão ao vivo no Nostr, lançou v0.13.0 com downloads de replay em MP4 nos menus de cartão de stream e NIP-05 (DNS-Based Verification) para perfis. O publisher RTMP migrou para a Expo Modules API. O desempenho de streaming em conexões de menor largura de banda melhorou, e crashes em dispositivos mais antigos e streaming iOS para Zap.Stream foram corrigidos.

nostr-java v2.0.0

nostr-java lançou v2.0.0 com tamanhos de buffer WebSocket configuráveis, permitindo que aplicações lidem com eventos Nostr maiores sem truncamento. O major version bump reflete mudanças que quebram compatibilidade na API de conexão.

Prism 1.1.0

Prism lançou 1.1.0 com suporte a conteúdo de formato longo (artigos kind 30023) e um editor Markdown para composição diretamente no app, seguido por um lançamento de correção 1.1.1.

Angor v0.2.6

Angor, a plataforma de crowdfunding Bitcoin, lançou v0.2.6 com integração Boltz e um fluxo de investimento em 1 clique. Tanto os tipos investir quanto financiar projeto funcionam de ponta a ponta na testnet. A equipe nota que a UI está aproximadamente 70% completa.

Atualizações de NIPs

Mudanças recentes no repositório de NIPs:

Mergeado:

NIP-91: AND Operator for Filters: Adiciona semântica de filtro AND para arrays de tags em assinaturas de relay. Atualmente, especificar múltiplos valores em um filtro de tag (por exemplo, múltiplas tags p) corresponde a eventos contendo qualquer um deles. NIP-91 permite que clientes exijam eventos correspondendo a todos os valores de tag especificados simultaneamente, reduzindo largura de banda e habilitando operações de índice mais rápidas. Múltiplas implementações de relay já existem incluindo nostr-rs-relay, satellite-node, worker-relay e applesauce. Anteriormente numerado NIP-119.
NIP-30: Emoji Set Address in Tags: Tags de emoji personalizado no NIP-30 agora podem incluir um endereço opcional de conjunto de emoji. Clicar em um emoji em um cliente pode abrir o conjunto ao qual pertence para favoritar ou navegar. Originado do cliente Chachi.
NIP-29: Add unallowpubkey and unbanpubkey: Dois novos comandos de admin para chat de grupo NIP-29. unallowpubkey remove uma pubkey da lista de permitidos sem bani-la. unbanpubkey levanta um banimento sem re-adicionar a pubkey à lista de membros. Anteriormente, a única forma de remover alguém da lista de permitidos também bania a pessoa, e desbanir exigia re-adicionar o usuário como membro.

PRs Abertos e Discussões:

NIP-A7: Spells (aberto 27 fev): Proposto por purrgrammer, spells são consultas Nostr salvas e portáteis publicadas como eventos kind 777. Um spell codifica um filtro REQ ou COUNT em tags estruturadas (k para kinds, authors para pubkeys, tag para filtros de tags arbitrários) com variáveis de runtime: $me resolve para a pubkey do usuário logado, $contacts expande para a lista de follows kind 3 do usuário. Timestamps relativos (7d, 2w, 1mo) permitem que spells definam janelas de tempo rolantes sem datas hardcoded. Já implementado em nak e Grimoire, spells permitem que usuários criem, compartilhem e se inscrevam em feeds curados que viajam entre clientes.
NIP-59: Ephemeral Gift Wrap (kind 21059) (aberto 27 fev): Adiciona uma variante efêmera dos gift wraps NIP-59. O kind 21059 segue a semântica efêmera do NIP-01, então relays descartam eventos após a entrega. Proposto por ContextVM para transporte MCP onde persistência de mensagens é desnecessária.
ContextVM: MCP JSON-RPC over Nostr (aberto 27 fev): Especifica como transportar mensagens Model Context Protocol sobre Nostr usando eventos efêmeros kind 25910 com tags p e e para endereçamento e correlação. Intencionalmente fino, delegando detalhes de protocolo à spec ContextVM.
NIP-29: Audio/Video Live Spaces (aberto 25 fev, rascunho): Rascunho de fiatjaf estendendo grupos NIP-29 com áudio e vídeo ao vivo. A proposta adiciona tags opcionais livekit e no-text a eventos de metadados de grupo. Quando um usuário quer entrar em um espaço de voz, o cliente solicita um JWT do relay em /.well-known/nip29/livekit/{groupId}. O relay verifica a associação ao grupo e emite um token com a pubkey hex do usuário como claim sub, que é passado ao LiveKit para transporte de mídia. O acesso à sala de voz herda o modelo de permissão existente do grupo, então regras de associação do lado do relay governam quem pode falar. Sendo testado no Pyramid e Chachi.
Collaborative Event Ownership (aberto 24 fev): pablof7z propõe um evento ponteiro (kind 39382) que declara um espaço colaborativo listando pubkeys de co-proprietários em tags p e um kind de evento alvo em uma tag k. Qualquer proprietário listado pode publicar eventos desse kind com a mesma tag d, e clientes resolvem o estado atual consultando todos os proprietários e pegando o evento mais recente. A atribuição de co-autoria só aparece quando uma tag a verificável referencia de volta o ponteiro e o autor aparece em suas tags p, prevenindo reivindicações falsificadas. Isso habilita páginas wiki compartilhadas e recursos co-autorados sem atribuir controle a um único par de chaves.
NIP-09: Cascading Deletion of Reposts (aberto 24 fev): Quando um autor original deleta uma nota, relays também devem deletar quaisquer reposts kind 6 ou kind 16 que a referenciam. Motivado por preocupações de privacidade: reposts podem preservar informações acidentalmente vazadas após o autor deletar a fonte. A mudança é apenas do lado do relay, não exigindo modificações nos clientes.
NIP-07: peekPublicKey (aberto 23 fev): Adiciona um método peekPublicKey() a extensões de navegador NIP-07. Diferente de getPublicKey(), retorna a pubkey atual sem solicitar confirmação do usuário, habilitando auto-login silencioso quando o usuário tem auto-login habilitado.
NIP-BB: Book (aberto 28 fev, rascunho): Define quatro kinds de evento endereçáveis (30300-30303) para publicação estruturada de livros no Nostr. Um evento Cover contém metadados raiz incluindo título, imagem de capa, licença via labels NIP-32 (Labeling) e código de idioma. Um evento Index mapeia cada capítulo à sua posição usando indexação fracionária base62, que permite aos autores inserir novos capítulos entre existentes sem renumerar. Eventos Chapter agem como cabeçalhos estruturais com imagens opcionais, enquanto eventos Episode carregam a prosa real limitada a 30.000 caracteres com tags de imagem posicionadas. Resenhas usam Zaps em eventos Cover com a descrição do Zap como texto da resenha.
NIP-54: Switch from Asciidoc to Djot (aberto 26 fev): Após a correção de internacionalização de d-tag em dezembro, este PR propõe substituir o formato de marcação Asciidoc do wiki NIP-54 por Djot, adicionando uma seção de justificativa e exemplos de wikilink para scripts não-latinos.
NIP-66: Defensive Measures (aberto 26 fev): Baseado nos aprendizados dos benchmarks nostrability/outbox, adiciona chamadas explícitas para casos limite do NIP-66. Um PR #2241 complementar define tags de saída para SSL, geolocalização, rede e verificações de conectividade.
NIP-C1: Cryptographic Identity Proofs (entrada wiki, kind 30817): Propõe eventos kind 30509 que vinculam criptograficamente certificados de assinatura APK a perfis Nostr. A prova funciona assinando uma mensagem canônica contendo a pubkey Nostr com a chave privada do certificado (suportando ECDSA, RSA PKCS1v15, Ed25519 e outros algoritmos padrão), depois publicando a assinatura em um evento kind 30509 assinado com a chave Nostr. Verificadores podem confirmar que a pessoa que controla o certificado de assinatura de um app Android também controla a pubkey Nostr que afirma publicá-lo. Provas expiram após um ano por padrão e podem ser explicitamente revogadas. Implementado no ferramental Zapstore.
NIP-31402: SARA Revenue Share Offering Registry (entrada wiki, kind 30817): Define eventos endereçáveis kind 31402 para publicar ofertas de Simple Autonomous Revenue Agreement (SARA) em relays Nostr. Emissores anunciam termos de compartilhamento de receita liquidados via Lightning incluindo percentual de pool share, gatilho de pagamento, limiar em sats, duração do termo e preço por faixas. Agentes e humanos podem descobrir ofertas em relays e se inscrever autonomamente sem uma plataforma central. O número do kind espelha o kind 30402 (L402 Service Registry, publicado pelo mesmo autor como uma entrada wiki complementar) já que SARA representa o retorno da relação de pagamento L402.

PRs Abertos e Atualizações de Projetos

Damus: NIP-89 (Recommended Application Handlers)

O PR #3337 implementa suporte a client tag NIP-89 para Damus. O app agora emite uma client tag em todos os caminhos de publicação (app principal, extensão de compartilhamento, highlighter, rascunhos) e exibe “via ClientName” ao lado de timestamps quando outros apps incluem suas tags. Um toggle de Privacidade nas configurações de Aparência permite que usuários desabilitem a emissão de tag. O PR #3652 adiciona uma seção de Armazenamento em Configurações com um gráfico de pizza interativo detalhando uso de disco do cache NostrDB e Kingfisher com suporte a exportação.

Em aberto: PR #3657 adiciona fallback de relay NIP-65 para notas citadas. Quando um nevent inline inclui uma pubkey de autor mas nenhuma dica de relay e a nota está ausente do pool do usuário, Damus busca a lista de relays kind 10002 do autor e tenta novamente a partir de seus relays de escrita.

Amethyst: NIP-39 (External Identities), NIP-C0, NIP-66

Amethyst mergeou uma onda de implementações de NIPs em 28 PRs. Reivindicações de identidade externa agora publicam como eventos dedicados kind 10011 sob NIP-39 (PR #1747), separando identidade social de metadados kind 0 com fallback retrocompatível. Suporte a trechos de código via NIP-C0 (PR #1744) adiciona eventos kind 1337 com acessores para linguagem, extensão, runtime, licença e dependências. A implementação de monitoramento de relay NIP-66 (PR #1742) cobre ambos os kinds de evento com parsing completo de tags para métricas RTT, tipo de rede, NIPs suportados e geohash.

DMs criptografadas chegaram ao Amethyst Desktop (PR #1710) com um layout de chat em painéis divididos suportando tanto NIP-04 (Encrypted Direct Messages) quanto NIP-17 (Private Direct Messages). Uma nova tela de feed de relay (PR #1733) permite que usuários naveguem posts de um relay específico com funcionalidade de follow/unfollow. Em aberto: verificação NIP-05 resistente a censura (PR #1734) adiciona um caminho de verificação paralelo para identificadores .bit que resolve contra a blockchain Namecoin em vez de HTTP DNS. Quando Amethyst detecta um sufixo .bit em um campo NIP-05, consulta um servidor ElectrumX-NMC pelo histórico de transações do nome, faz parsing do script NAME_UPDATE da saída mais recente para extrair a pubkey Nostr, e rejeita nomes mais antigos que 36.000 blocos (janela de expiração do Namecoin). Conexões ElectrumX roteiam através de SOCKS5 quando Tor está habilitado, com seleção dinâmica de servidor entre endpoints clearnet e .onion. Um cache LRU com TTL de uma hora previne consultas repetidas à blockchain.

Notedeck: Arquitetura Outbox

O PR #1303 migra o Notedeck de gerenciamento ad-hoc de pool de relays para um modelo outbox centralizado com assinaturas com escopo de conta. O módulo Messages agora publica uma lista de relay DM padrão se nenhuma existir e roteia DMs para relays preferidos dos destinatários conforme kind 10050.

Pika: Perfis por Grupo e Feed Tutorial

Pika, o app de mensagens criptografadas com Marmot disponível para iOS e Android com build desktop, ganhou perfis por grupo (PR #368). Usuários agora podem definir um nome de exibição e foto separados para cada chat de grupo, junto com uma bio personalizada. Esses perfis publicam como eventos kind 0 criptografados dentro do grupo Marmot, invisíveis para qualquer pessoa fora dele, com fallback para o perfil Nostr global do usuário quando nenhum perfil específico do grupo está definido. Quando novos membros entram, o admin retransmite todos os perfis de grupo armazenados e cada membro republica o seu próprio no commit. Fotos de perfil são criptografadas com Marmot-media antes do upload Blossom. O PR inclui 16 novos testes unitários e expõe o recurso tanto através de um comando CLI (update-group-profile) quanto da UI.

Um novo web app pika-news (PR #401) monitora os PRs do próprio GitHub do Pika e gera automaticamente tutoriais passo a passo de walkthroughs a partir de diffs de PRs, publicando-os como páginas renderizadas no servidor com autenticação NIP-07. Usuários podem discutir tutoriais específicos em tempo real através de chat autenticado por Nostr.

diVine: Widgets Embutíveis e Respostas em Vídeo

diVine, a plataforma de compartilhamento de vídeo nativa do Nostr, mergeou 132 PRs em dez dias. Widgets embutíveis via iframe (PR #1843) fornecem uma página /embed?npub=... autocontida que renderiza o perfil de um usuário e seus vídeos mais recentes. Funcionalidade de resposta em vídeo (PR #1915), protegida por feature flag, usa comentários Kind 1111 (NIP-22) com metadados imeta NIP-92 (Media Attachments). Filtros de conteúdo em três vias inspirados no Bluesky (PR #1797) oferecem controles Mostrar/Avisar/Ocultar em 17 categorias de aviso de conteúdo NIP-32.

strfry: Validação de Filtro REQ

O PR #163 adiciona validação configurável de filtro REQ ao strfry, o relay Nostr C++. Operadores podem definir máximo de filtros por REQ, presença obrigatória de autor ou tag, whitelists de kinds permitidos e limites de kinds por filtro. O recurso visa deployments de relay NWC que precisam de enforcement estrito de filtros. Em aberto: PR #173 adiciona compressão zstd opcional para payloads de evento no momento da ingestão.

rust-nostr: NIP-62 Request to Vanish

rust-nostr, a biblioteca de protocolo Nostr em Rust, adicionou suporte a NIP-62 (Request to Vanish) em todos os três backends de banco de dados: LMDB, SQLite e in-memory. A implementação LMDB inclui opções configuráveis para habilitar ou desabilitar enforcement de NIP-09 e NIP-62 por deployment.

NDK: Eventos Colaborativos e Timeout NIP-46

NDK, o Nostr Development Kit para JavaScript/TypeScript, mergeou o PR #380 introduzindo NDKCollaborativeEvent para documentos colaborativos multi-autor usando um evento ponteiro endereçável (kind 39382) que define autores autorizados. Um timeout configurável para NDKNip46Signer (PR #381) previne que operações de assinatura remota NIP-46 fiquem penduradas indefinidamente quando um bunker não responde.

TENEX: Categorização de Agentes e Gating por Pubkey

TENEX, a plataforma de orquestração de agentes de IA nativa do Nostr, mergeou dois PRs relacionados a segurança. Categorização de agentes baseada em papéis TIP-01 (PR #91) mapeia categorias de agente (principal, orchestrator, worker, advisor, auditor) para restrições automatizadas de ferramentas via um mapa de ferramentas negadas. Gating de pubkey na porta de entrada (PR #87) garante que apenas eventos de pubkeys na whitelist ou assinados pelo backend sejam roteados junto com agentes conhecidos; pubkeys desconhecidas são silenciosamente descartadas com spans OpenTelemetry para auditoria.

Zap Cooking: Painel de Membros

Zap Cooking, a plataforma de compartilhamento de receitas baseada no Nostr, mergeou 25 PRs e 85 commits em dez dias. Um painel de membros (PR #228) mostra status de assinatura com datas de expiração e opções de gerenciar/upgrade, reabilita gates de recursos para as faixas Sous Chef e Zappy com verificações tanto no lado do cliente quanto no servidor, e padroniza nomenclatura de faixas em 26 arquivos. Carregamento de mensagens de grupo em duas fases (PR #227) fornece uma busca inicial rápida de 3 dias para exibição instantânea seguida de um backfill em background de 40 dias.

O armazenamento de mnemônica de carteira foi movido de criptografia derivada de pubkey para encrypt-to-self NIP-44 (PR #224), corrigindo uma vulnerabilidade onde o esquema antigo derivava sua chave de SHA-256(pubkey), que é efetivamente não criptografado já que pubkeys são públicas. Carteiras existentes são migradas silenciosamente no primeiro carregamento. Chat de grupo NIP-29 ganhou indicadores de não lidos com badges de ponto vermelho e acesso somente por convite com códigos de convite kind 9009 (PR #213). Pré-visualizações de links e embeds de eventos Nostr agora renderizam em DMs e mensagens de grupo (PR #218). Uma seção de backup Nostr em Configurações (PR #210) armazena follows e listas de mute via armazenamento criptografado NIP-78 (Application-specific Data) com versionamento rotativo de 3 slots. O desempenho de inicialização melhorou através de serviços de notificação diferidos, renderização DOM lazy via IntersectionObserver (reduzindo nós DOM de ~15.000 para ~3.000 em um feed de 200 eventos) e TTLs estendidos de cache outbox (PR #208). Um modal de impressão de receita personalizável (PR #205) permite que usuários alternem quais seções incluir com pré-visualização ao vivo. Integração com Branta SDK (PR #222) adiciona proteções de verificação para requisições POST e GET.

Keep: Migração de Estado Orientada por Rust

Keep, o gerenciador de chaves privadas baseado no Nostr para Android, mergeou o PR #178, deletando quatro stores de configuração Kotlin em favor de estado compartilhado orientado por Rust da camada keep-mobile. Um loop de polling de 10 segundos foi substituído por KeepStateCallback push-based do Rust. O PR #179 adiciona backup e restauração criptografados com proteção por passphrase.

Mostro Mobile: Criptografia de Chat de Disputa

Mostro Mobile, o cliente mobile para a plataforma de trading P2P de Bitcoin Mostro, lançou uma migração em duas fases da criptografia de chat de disputa. O primeiro passo (PR #495) troca de encapsulamento específico do mostro para criptografia de chave compartilhada derivada da pubkey do admin. Construindo sobre isso, o PR #501 unifica o modelo de mensagem com NostrEvent e armazena eventos gift wrap criptografados em disco, consistente com o padrão de chat peer-to-peer. Uma correção de assinatura BIP-340 (PR #496) sobrescreve a dependência bip340 para 0.2.0, resolvendo um bug de padding bigToBytes() que causava 1-2% das assinaturas Schnorr serem inválidas e 100% de falha para chaves cuja chave pública começa com 0x00. Detalhes do Pedido agora mostra labels de status legíveis em vez de valores brutos do protocolo, localizados em inglês, espanhol, italiano e francês (PR #502). HalCash foi adicionado e SEPA removido como método de pagamento (PR #493), já que transferências SEPA podem exceder 24 horas (SEPA Instant permanece).

No lado do servidor, Mostro corrigiu a restauração de sessão de disputa para incluir o campo do iniciador (PR #599) e agora fecha automaticamente disputas ativas quando um vendedor libera fundos, publicando um evento Nostr de liquidação para que clientes admin vejam a resolução (PR #606).

Cinco Anos de Fevereiros do Nostr

A newsletter do mês passado traçou os marcos de janeiro do Nostr desde o desenvolvimento inicial, passando pela explosão do Damus, até a infraestrutura de segurança em 2026. Esta retrospectiva cobre o que aconteceu em cada fevereiro de 2021 a 2026.

Fevereiro de 2021: A Reescrita

Três meses após sua existência, o fevereiro do Nostr produziu a mudança inicial mais consequente do protocolo. Em 14-15 de fevereiro, fiatjaf reescreveu o NIP-01, substituindo o formato de mensagem original pelo modelo EVENT/REQ/CLOSE que o protocolo ainda usa. Antes dessa reescrita, clientes e relays se comunicavam através de uma estrutura mais simples. Separar publicação de evento (EVENT) de gerenciamento de assinatura (REQ/CLOSE) habilitou filtragem do lado do relay que se provaria essencial para escalar.

NIP-04 chegou no mesmo mês, adicionando mensagens diretas criptografadas usando segredos compartilhados derivados de troca de chaves Diffie-Hellman sobre secp256k1. Sua criptografia era básica (AES-256-CBC) e seria depois substituída pela criptografia auditada do NIP-44, mas deu aos poucos usuários iniciais seu primeiro canal de comunicação privada no protocolo.

O ferramental expandiu com noscl, um cliente de linha de comando em Go para interação com relays pelo terminal, e futurepaul iniciou nostr-rs, uma implementação inicial em Rust. A rede inteira rodava em dois ou três relays, coordenada através de um grupo no Telegram, com aproximadamente sete contribuidores ativos.

Fevereiro de 2022: Ganhando Tração

O post no Hacker News de 31 de dezembro de 2021 continuou atraindo desenvolvedores em fevereiro. O repositório nostr-protocol/nostr (o repositório formal de NIPs não existiria até maio de 2022) recebeu seis pull requests em fevereiro, incluindo NIP-13 (Proof of Work) de vinliao, NIP-14 (Reputation) de fiatjaf, NIP-15 (Resource Relations) de Cameri e NIP-17 (Git Updates Over Nostr) de melvincarvalho. O número do NIP seria depois reatribuído para Private Direct Messages; colaboração git no Nostr continuou separadamente através do que se tornou gitworkshop.dev.

O nostr-rs-relay de Greg Heartsfield foi o cavalo de batalha do mês com 34 commits e três lançamentos. A versão 0.5.0 em 12 de fevereiro adicionou limites de publicação para usuários verificados por NIP-05. As versões 0.5.1 e 0.5.2 seguiram nas duas semanas seguintes, e o relay lidou com a maior parte do tráfego da rede sozinho.

Robert C. Martin (Uncle Bob) estava construindo more-speech, um cliente desktop em Clojure, registrando 69 commits entre 18 de janeiro e o final de fevereiro. Seu envolvimento trouxe atenção da comunidade mais ampla de engenharia de software. A extensão de navegador nos2x de fiatjaf lançou suporte a descriptografia NIP-04 e políticas de preferência de relay em fevereiro, implementando a interface window.nostr (NIP-07) que clientes web ainda usam para delegação de chaves.

Branle, ainda o cliente web principal, ganhou registro de handler do protocolo web+nostr em 13 de fevereiro, uma tentativa inicial de deep linking entre aplicações Nostr. nostr-tools aprimorou a validação NIP-05. go-nostr adicionou suporte a DM criptografada NIP-04 e parsing NIP-12 (Generic Tag Queries) em 11 commits. A rede operava com aproximadamente 7-15 relays com uma base de usuários ativos provavelmente na casa das baixas centenas. Damus e Nostream ainda não existiam e não apareceriam até abril de 2022.

Fevereiro de 2023: Atenção Internacional

Fevereiro de 2023 trouxe ao Nostr sua maior onda de atenção pública. Damus, o cliente iOS de William Casarin, havia sido aprovado na App Store da Apple em 31 de janeiro após repetidas rejeições. Em 1º de fevereiro alcançou o top 10 em Redes Sociais nos EUA. Dois dias depois, em 2 de fevereiro, a Apple removeu o Damus da App Store da China supostamente a pedido da Administração do Ciberespaço da China.

Grandes veículos incluindo TechCrunch e CoinDesk cobriram a remoção, amplificando a conscientização tanto do app quanto do protocolo. Chaves públicas únicas com metadados no nostr.directory ultrapassaram 300.000 em 3 de fevereiro. Todos os relays eram operados por entusiastas pagando do próprio bolso, e a infraestrutura se esforçou para lidar com a carga. Aproximadamente 289 relays eram rastreados no início de fevereiro, número que continuou crescendo.

O repositório de NIPs registrou 29 pull requests mergeados naquele mês, a maior contagem de um único mês na história do protocolo até aquele ponto. NIP-57 (Lightning Zaps) e NIP-23 (Long-form Content) ambos foram mergeados em 13 de fevereiro, adicionando micropagamentos Bitcoin e expandindo o Nostr além de posts curtos em um único dia. NIP-65 (Relay List Metadata) havia sido mergeado uma semana antes, em 7 de fevereiro, habilitando o modelo outbox que se seguiu. NIP-46 (Nostr Connect) e NIP-58 (Badges) também foram aprovados antes do fim do mês.

A Human Rights Foundation concedeu US$50.000 a William Casarin para desenvolvimento do Nostr e Damus em 21 de fevereiro, uma das primeiras bolsas institucionais para um projeto Nostr. A OpenSats ainda não havia lançado seu fundo Nostr (isso viria em julho de 2023).

Fevereiro de 2024: Durabilidade do Protocolo

Fevereiro de 2024 mudou o foco de crescimento para durabilidade do protocolo. NIP-17 (Private Direct Messages), aberto desde julho anterior, estava trabalhando em direção a uma substituição para a envelhecida criptografia NIP-04 usando criptografia auditada do NIP-44 e gift wrapping NIP-59. NIP-04 vazava metadados para operadores de relay, que podiam ver pares remetente-destinatário. NIP-17 esconde a identidade do remetente atrás de pares de chaves descartáveis e foi mergeado na primavera seguinte após uma rodada final de revisão em março.

NIP-29 (Simple Groups) foi mergeado em 28 de fevereiro após meses de discussão, definindo como relays podem hospedar chats de grupo moderados com papéis de admin e controle de acesso. NIP-92 (tags imeta) foi mergeado em 1º de fevereiro, padronizando como clientes anexam dimensões de imagem e pré-visualizações blurhash a eventos de mídia.

Em 16 de fevereiro, o repositório de NIPs adicionou BREAKING.md, um arquivo rastreando mudanças incompatíveis com versões anteriores na especificação do protocolo. Sua criação reconheceu que o Nostr havia alcançado um nível de maturidade onde mudanças que quebram compatibilidade precisavam de documentação formal.

Vinte e dois pull requests foram mergeados naquele mês. npub.cash foi lançado como serviço de endereço Lightning permitindo que qualquer npub receba pagamentos sem rodar um servidor. Um artigo acadêmico publicado em 8 de fevereiro descobriu que 95% dos relays de uso gratuito não conseguiam cobrir custos operacionais através de doações, com 35% dos relays pagos cobrando taxas de admissão abaixo de 1.000 sats (aproximadamente US$0,45 na época).

Fevereiro de 2025: Crescimento de Infraestrutura

Fevereiro de 2025 produziu 28 pull requests mergeados no repositório de NIPs. Um NIP de Direito ao Desaparecimento foi mergeado em 19 de fevereiro, definindo como usuários podem solicitar a exclusão de seus dados dos relays em resposta a questões regulatórias sobre portabilidade de dados e controle do usuário.

NIP-60 (Cashu Wallet) e NIP-61 (Nutzaps) receberam atualizações de simplificação, otimizando o formato de armazenamento de tokens ecash. Um rollout de q-tag (quote tag) continuou em múltiplos NIPs, padronizando como eventos referenciam outros eventos para citação e threading.

Lançamentos de clientes marcaram progresso constante. Notedeck v0.3.0 alpha foi lançado no último dia de janeiro, com adoção continuando em fevereiro. Primal v2.1 seguiu em 7 de fevereiro, e GRAIN v0.3.0, uma implementação de relay em Go, foi lançado em 21 de fevereiro.

NOSTRLDN v5 reuniu a comunidade Nostr de Londres para seu quinto meetup. Uma ponte DVMCP conectou as Data Vending Machines do Nostr (NIP-90) com o Model Context Protocol, prefigurando o trabalho de integração de agentes de IA que chegaria no mês seguinte.

Fevereiro de 2026: Além das Redes Sociais

A atividade de fevereiro de 2026 é extraída das edições do Nostr Compass #8 a #11.

Fevereiro de 2026 produziu a mais ampla gama de desenvolvimento na camada de aplicação em qualquer mês do Nostr. Mostro lançou seu primeiro beta público para trading descentralizado peer-to-peer de Bitcoin, e Zapstore alcançou a versão 1.0 estável após meses em teste de release candidate. White Noise v0.3.0 entregou mensagens em tempo real criptografadas com Marmot com suporte ao assinador Amber e mais de 160 melhorias mergeadas.

Propostas concorrentes de agentes de IA de pablof7z (NIP-AE para fluxos de trabalho de agentes, NIP-AD para anúncios de servidores MCP) e joelklabo (AI Agent Messages) chegaram junto com uma proposta de Coordenação de Agentes DVM estendendo NIP-90. ContextVM lançou melhorias no SDK conectando o Model Context Protocol ao transporte Nostr. Burrow adicionou mensagens criptografadas com Marmot tanto para agentes de IA quanto humanos, estendendo a identidade e infraestrutura de relay do Nostr para comunicação máquina-a-máquina.

FIPS lançou uma implementação Rust funcional de redes mesh nativas do Nostr, usando pares de chaves secp256k1 como identidades de nó com roteamento agnóstico de transporte sobre UDP, Ethernet, Bluetooth ou rádio LoRa. Seu design mostrou que o modelo de chaves do Nostr se estende além das redes sociais para infraestrutura de rede física.

A OpenSats anunciou sua décima quinta onda de bolsas Nostr, financiando projetos incluindo ContextVM e Nostube. Mudanças de protocolo incluíram suporte a hold invoice do NIP-47 para Nostr Wallet Connect e HyperLogLog do NIP-45 (Counting Results) para estimativa de contagem do lado do relay. A descobribilidade de provedores de serviço do NIP-85 (Trusted Assertions) para pontuação de Web of Trust também foi mergeada. rust-nostr iniciou um redesign completo de API enquanto Nostria 3.0 e Frostr (iOS TestFlight) ambos foram lançados. A camada de cache local do Blossom tratou a disponibilidade de mídia entre relays.

Olhando para Frente

Cinco fevereiros de história do protocolo mostram uma progressão consistente de trabalho fundacional para diversificação na camada de aplicação, com o influxo de usuários de 2023 como ponto de virada. Em 2021, sete contribuidores trabalhavam em três relays. Em 2026, o mesmo protocolo suportava redes mesh e propostas de agentes autônomos rodando em infraestrutura de produção.

É isso por esta semana. Construindo algo ou tem novidades para compartilhar? Entre em contato via NIP-17 DM ou nos encontre no Nostr.

Nostr Compass #11

Wed, 25 Feb 2026 00:00:00 +0000

Bem-vindo de volta ao Nostr Compass, seu guia semanal sobre o Nostr.

Esta semana: White Noise v0.3.0 traz mensagens em tempo real e suporte ao assinador Amber com mais de 160 melhorias mergeadas. diVine 1.0.5 corrige problemas de reprodução de vídeo e adiciona eventos de visualização Kind 22236 para análises do criador. Pika, Ridestr e Unfiltered lançam atualizações. FIPS lança uma implementação Rust funcional de redes mesh nativas do Nostr. Notecrumbs recebe correções de estabilidade para pré-visualizações de links do damus.io. ContextVM faz ponte entre o Nostr e o Model Context Protocol. Novos projetos incluem Burrow para mensagens criptografadas com MLS entre agentes de IA e humanos, e Nostria Signer para gerenciamento de cofre e identidade baseado em navegador. Os deep dives cobrem NIP-55 para assinatura no Android e NIP-60 para sincronização de carteira Cashu.

Notícias

Melhorias de Estabilidade no Notecrumbs

Notecrumbs, a API Nostr e servidor web que alimenta as pré-visualizações de links do damus.io, recebeu uma série de correções tratando problemas de confiabilidade.

Uma correção de concorrência substituiu o mecanismo de deduplicação em voo por watch channels. Dois chamadores solicitando a mesma nota poderiam ambos se tornar buscadores, levando a um deadlock quando um completava antes que o outro se inscrevesse na notificação. Watch channels com operações atômicas garantem que apenas um buscador execute enquanto outros aguardam o resultado.

Limitação de taxa implementa uma defesa em duas camadas contra martelo de relay. Quando usuários acessam repetidamente a mesma nota, o sistema agora faz debounce de requisições ao relay com uma janela de cooldown de 5 minutos. Essa proteção se estende a todos os tipos NIP-19 e feeds de perfil, prevenindo spam proporcional aos relays durante tráfego intenso.

Melhorias de desempenho moveram buscas de dados secundários para tarefas tokio em background. As páginas agora renderizam instantaneamente com dados em cache em vez de bloquear em timeouts sequenciais de relay que poderiam somar até 7,5 segundos. Uma atualização para nostrdb 0.10.0 acompanhou essas correções.

ContextVM: MCP Sobre Nostr

ContextVM é um conjunto de ferramentas que faz ponte entre o Nostr e o Model Context Protocol (MCP). Commits recentes introduziram a nova spec CEP-8 habilitando pagamentos, e têm impulsionado melhorias no SDK ao longo de fevereiro.

O SDK fornece transportes cliente e servidor TypeScript para MCP sobre Nostr. Desenvolvedores podem expor servidores MCP através da rede Nostr e clientes podem se conectar a eles. Relays agem como um barramento de mensagens cego, apenas roteando eventos criptografados cegamente. Clientes sem suporte nativo ao Nostr se conectam através de uma camada de proxy. A biblioteca lida com gerenciamento de relay e assinatura criptográfica para autenticação de eventos. Funciona tanto em ambientes Node.js quanto de navegador.

CVMI fornece uma CLI para descoberta de servidores e invocação de métodos. Relatr calcula pontuações de confiança personalizadas a partir da distância no grafo social combinada com validação de perfil.

ContextVM se posiciona como uma camada de ponte: servidores MCP existentes ganham interoperabilidade com Nostr enquanto mantêm seus transportes convencionais.

White Noise Documenta Busca Descentralizada de Usuários

Um post de blog de jgmontoya detalha como White Noise lida com a busca de usuários através da rede de relays descentralizada.

A distribuição de perfis cria o desafio: diferente de mensageiros centralizados com bancos de dados unificados, os perfis Nostr se espalham por dezenas de relays sem índice central. White Noise resolve isso através de uma arquitetura produtor-consumidor rodando em paralelo.

Um processo produtor expande continuamente o grafo social para fora a partir dos follows do usuário, buscando listas de follows em distâncias crescentes e enfileirando pubkeys descobertos para resolução de perfil. O consumidor resolve matches através de cinco camadas crescentemente caras: tabela de usuário local (mais rápido), perfis em cache de buscas anteriores, relays conectados, listas de relay de usuários por NIP-65 e consultas diretas a relays declarados pelo usuário (mais lento).

Buscas frias levam aproximadamente 3 segundos enquanto buscas quentes do cache caem para cerca de 10 milissegundos. Para novos usuários sem grafos sociais estabelecidos, o sistema injeta nós bootstrap bem conectados para garantir funcionalidade de busca. A participação em grupos fornece um sinal social implícito ao lado de follows explícitos.

Instrumentação provou ser crítica para otimização, observa o autor. Sem métricas, melhorias eram adivinhação.

FIPS: Redes Mesh Nativas do Nostr

FIPS (Free Internetworking Peering System) é uma implementação Rust funcional de uma rede mesh auto-organizável que usa pares de chaves Nostr (secp256k1) como identidades de nó. A documentação de design acompanha o código funcional.

O protocolo trata da independência de infraestrutura: nós se descobrem automaticamente sem servidores centrais ou autoridades de certificação. Uma árvore de cobertura fornece roteamento baseado em coordenadas enquanto filtros bloom propagam informações de alcançabilidade, deixando os nós tomarem decisões de encaminhamento com apenas conhecimento local. Agnosticismo de transporte significa que o mesmo protocolo funciona sobre UDP, Ethernet ou Bluetooth. Também suporta rádio LoRa ou qualquer meio capaz de datagramas.

Duas camadas protegem o tráfego. Link-layer encryption (padrão Noise IK) protege a comunicação salto por salto entre vizinhos com autenticação mútua e sigilo futuro. Session-layer encryption (padrão Noise XK) fornece proteção ponta a ponta contra roteadores intermediários, onde apenas o destino pode descriptografar a carga útil. Isso espelha como TLS protege o tráfego HTTP mesmo ao atravessar redes não confiáveis.

A arquitetura usa uma árvore de cobertura “greedy embedding” para roteamento. Cada nó recebe coordenadas baseadas em sua posição relativa à raiz da árvore e ao pai. Pacotes roteiam gananciamente em direção a coordenadas mais próximas do destino, com filtros bloom anunciando endpoints alcançáveis. Quando o roteamento ganancioso falha (mínimos locais), nós podem recorrer a caminhos baseados em árvore.

A implementação Rust já inclui transporte UDP com descoberta por filtro bloom. Trabalho futuro visa integração com relay Nostr para bootstrapping de pares.

Lançamentos

Esta semana trouxe lançamentos através da infraestrutura de relay e aplicações cliente, com novos projetos também entrando no espaço.

HAVEN v1.2.0

HAVEN, o relay pessoal tudo-em-um reunindo quatro funções de relay com um servidor de mídia Blossom, lançou v1.2.0. Este lançamento vai além do estágio RC coberto na semana passada.

Suporte a múltiplos npubs permite que uma única instância HAVEN sirva várias identidades Nostr através de whitelisting, com nova funcionalidade de blacklist para controle de acesso. Um sistema de backup reescrito usa formato JSONL portátil, com um comando haven restore para importar notas de arquivos JSONL. Integração com armazenamento em nuvem adiciona flags --to-cloud e --from-cloud para gerenciamento de backup remoto.

Melhorias de Web of Trust incluem níveis de profundidade configuráveis para cálculos de confiança e intervalos automáticos de atualização de 24 horas com otimização sem bloqueio reduzindo overhead de memória. Configuração de user-agent para requisições de relay, configurações de timeout do Blastr e exportação de dados para JSONL compactado completam o lançamento.

White Noise v0.3.0

White Noise, o app de mensagens criptografadas baseado em MLS implementando o protocolo Marmot, lançou v0.3.0 com mais de 160 melhorias mergeadas.

Este lançamento traz mensagens em tempo real através de conexões de streaming em vez de polling, então mensagens chegam instantaneamente. Suporte ao Amber (NIP-55) significa que chaves privadas nunca precisam tocar o app. Compartilhamento de imagem agora funciona com rastreamento de progresso de upload e placeholders blurhash durante o carregamento. Visualização em tela cheia suporta pinça para zoom.

Mensagens de grupo receberam melhorias de confiabilidade com listas de chat mostrando nomes de remetentes. A criptografia MLS garante sigilo futuro. Busca de usuário se expande para fora dos follows até quatro graus de separação com resultados chegando em streaming conforme encontrados.

Uma mudança que quebra compatibilidade reseta todos os dados locais no upgrade devido a mudanças no protocolo Marmot e a mudança para armazenamento local criptografado. Usuários devem fazer backup das chaves nsec antes de atualizar.

diVine 1.0.5

diVine, o cliente de vídeo de loop curto construído sobre arquivos Vine restaurados, lançou 1.0.5 com extensas correções de reprodução de vídeo e um novo sistema de análises descentralizado.

Problemas de reprodução de vídeo dominaram as correções. Pausa fantasma está resolvida. Áudio duplo entre vídeos está corrigido. Flash preto entre miniaturas e primeiros quadros foi eliminado, e crashes de player descartado não ocorrem mais. Um player de vídeo em pool agora lida com o feed Home para reprodução consistente.

Eventos de visualização efêmeros Kind 22236 habilitam análises de criador e recomendações. O sistema rastreia fontes de tráfego (home, variantes de descoberta, perfil, compartilhamento e busca) junto com contagens de loop enquanto filtra auto-visualizações. Vazamentos de caminho de arquivo local em tags imeta de eventos Nostr são corrigidos com URLs Blossom canônicas construídas no lado do cliente por spec BUD-01.

Melhorias no assinador remoto NIP-46 incluem conexões de relay paralelizadas e suporte a URL de callback. Android reconecta conexões WebSocket ao retomar app após aprovação do assinador.

O Coracle também recebeu uma atualização esta semana.

Coracle 0.6.30

Coracle, o cliente Nostr baseado em web focado em gerenciamento de relay e moderação por Web of Trust, lançou 0.6.30 com suporte a miniaturas de vídeo, melhorando a navegação de mídia nos feeds.

Nostur trouxe novos recursos para iOS.

Nostur v1.26.0

Nostur, o cliente Nostr para iOS, lançou v1.26.0 com uma nova seção de feed de Transmissões Ao Vivo e uma tela de Configurações redesenhada. GIFs agora podem hospedar em servidores de mídia Blossom, reduzindo dependência de serviços centralizados. Integração com Klipy GIFs fornece backup quando Tenor fica indisponível. Cabeçalhos de ano em conversas de DM e exibição de contagem de menções completam as mudanças voltadas ao usuário.

Ferramental para desenvolvedores e apps CLI também receberam atualizações esta semana.

nak v0.18.5

nak, o canivete suíço de linha de comando para Nostr de fiatjaf, lançou v0.18.5 com um novo subcomando nak profile para buscar e exibir perfis de usuário. O comando git clone agora suporta nomes NIP-05 em URIs nostr://, habilitando clonagem de repositório por identificadores legíveis por humanos.

Pika trouxe melhorias para seu mensageiro multiplataforma.

Pika v0.5.3

Pika, o mensageiro criptografado com MLS para iOS, Android e desktop construído sobre o protocolo Marmot, lançou v0.5.3. Commits recentes adicionam upload de arquivo ao app desktop. Suporte a arrastar e soltar mídia também chegou. Correções de deploy no Cloudflare Workers completam a atualização.

Pika usa um núcleo Rust que possui toda a lógica de negócio enquanto iOS (SwiftUI) e Android (Kotlin) agem como camadas finas de UI renderizando snapshots de estado. MDK (Marmot Development Kit) fornece a implementação MLS. O projeto nota status alfa e alerta contra uso para cargas de trabalho sensíveis.

Ridestr melhorou sua plataforma de carona descentralizada.

Ridestr v0.2.6

Ridestr, a plataforma de carona descentralizada com pagamentos Cashu, lançou v0.2.6. Este lançamento corrige problemas de acessibilidade TalkBack. Resolve bugs onde motoristas desapareciam da lista próxima ao trocar métodos de pagamento. Também corrige falhas de atualização de contagem quando motoristas ficavam offline.

O recurso “Enviar para Todos” agora é “Broadcast RoadFlare” com correções para falhas silenciosas em instalações frescas de motorista. Ridestr implementa escrow HTLC para pagamentos de carona sem confiança e sincronização de carteira NIP-60 entre dispositivos.

Unfiltered expandiu seu app de fotos para Android.

Unfiltered v1.0.6

Unfiltered, o app de compartilhamento de fotos estilo Instagram para Android, lançou v1.0.6 com busca de usuário melhorada e reconexão automática de relay a cada 60 segundos.

Construído com Kotlin e Jetpack Compose, Unfiltered usa bindings rust-nostr e servidores compatíveis com Blossom para hospedagem de imagem. Integração com Amber (NIP-55) lida com gerenciamento seguro de chaves. O app mostra posts de contas seguidas em ordem cronológica sem algoritmos ou anúncios.

Dois novos projetos de mensagens e assinatura também foram lançados esta semana.

Burrow: Mensagens MLS para Agentes de IA

Burrow é um mensageiro implementando o protocolo Marmot para comunicação criptografada com MLS sem números de telefone ou servidores centralizados. Tanto usuários humanos quanto agentes de IA podem participar.

Um daemon CLI Rust puro com modo de saída JSONL lida com integração com sistemas automatizados. Um app Flutter multiplataforma cobre Android, iOS e Linux. Também suporta macOS e Windows. Anexos de mídia criptografam ao lado de mensagens, e WebRTC lida com chamadas de áudio e vídeo com servidores TURN configuráveis.

Burrow camada criptografia MLS sobre infraestrutura Nostr. Identidade usa pares de chaves Nostr (secp256k1) enquanto MLS KeyPackages publicam como eventos kind 443. Mensagens criptografam com NIP-44 como eventos kind 445, e convites de boas-vindas usam gift-wrapping NIP-59.

Integração com OpenClaw habilita participação de agente de IA com acesso completo a ferramentas. Listas de controle de acesso com registro de auditoria gerenciam permissões de contato e grupo. Essa combinação posiciona Burrow para cenários de mensagens agente-para-agente e agente-para-humano exigindo criptografia nível Signal sobre infraestrutura descentralizada.

Nostria Signer trouxe gerenciamento de identidade para navegadores.

Extensão Nostria Signer

Nostria Signer é uma extensão de navegador baseada em Chromium fornecendo gerenciamento de cofre e identidade para usuários Nostr.

Múltiplos cofres contendo múltiplas contas permitem usuários organizarem identidades para contextos diferentes. Internacionalização inclui suporte a idiomas RTL. Construído com Angular e TypeScript (79,2% do código), funciona tanto como extensão de navegador quanto Progressive Web App.

Nostria Signer implementa NIP-07 para assinatura de extensão de navegador, habilitando clientes Nostr baseados em web a solicitar assinaturas de eventos sem acessar chaves privadas diretamente. Migração automática de carteira lida com atualizações distribuídas através da Chrome Web Store. Usuários também podem fazer sideload da pasta dist/extension.

Desenvolvedores enfatizam o status experimental: usuários devem gerenciar suas próprias frases de recuperação secreta já que os desenvolvedores não podem restaurar acesso a chaves perdidas.

Atualizações de Projetos

Formstr Migra para Nova Organização

Formstr, a alternativa ao Google Forms no Nostr, migrou seu repositório de abh3po/nostr-forms para a organização formstr-hq. Este beneficiário de subsídio OpenSats continua desenvolvimento no novo local.

PRs Abertos Notáveis

Trabalho em progresso através de projetos Nostr:

Damus Outbox Model (PR #3602): Plano de implementação para o modelo de relay gossip/outbox no iOS. Essa mudança arquitetural melhora entrega de mensagem publicando aos relays onde destinatários realmente leem.
Notedeck Cross-Platform Notifications (PR #1296): Sistema de notificação nativo para o cliente desktop Damus cobrindo Android FCM, macOS e Linux.
NDK Cashu v3 Upgrade (PR #370): Atualiza a integração de carteira do Nostr Development Kit para cashu-ts v3.
Zeus Cashu Offline (PR #3742): Envio e recebimento de ecash offline para a carteira Lightning Zeus.
Shopstr Encrypted Digital Delivery (PR #231): Adiciona entrega criptografada para bens digitais com suporte a peso dinâmico para itens físicos.

Atualizações de NIPs

Mudanças recentes no repositório de NIPs:

Mergeado Esta Semana:

NIP-85 Service Provider Discoverability: A spec NIP-85 agora inclui orientação sobre como clientes descobrem provedores de asserção confiáveis. Quando um cliente precisa de pontuações de Web of Trust ou outras métricas computadas, pode consultar relays por anúncios kind 30085 de provedores que o usuário já segue ou confia.

NIP-29 Removes Unmanaged Groups: A spec de chat de grupo NIP-29 descartou suporte para grupos não gerenciados (onde qualquer membro poderia adicionar outros). Todos os grupos NIP-29 agora exigem gerenciamento no lado do relay com papéis de admin explícitos, simplificando implementações e reduzindo vetores de spam.

NIP-11 Removes Deprecated Fields: Documentos de informação de relay NIP-11 não incluem mais os campos depreciados software e version. Implementações devem remover esses de suas respostas.

NIP-39 Moves Identity Tags: Reivindicações de identidade externa (tags i NIP-39 para GitHub, Twitter, etc.) moveram de perfis kind 0 para eventos dedicados kind 30382. Isso separa verificação de identidade de metadados de perfil.

Progresso de NIPs de Agentes de IA:

Quatro NIPs focados em IA continuam desenvolvimento ativo. Desde a cobertura da semana passada:

NIP-AE: Agents (atualizado 19 fev): Define identidade de agente com kind 4199 para definições de agente e kind 4201 para prompting (“nudges”). Agentes podem referenciar metadados de arquivo NIP-94 para descrições estendidas.

NIP-XX: AI Agent Messages (atualizado 18 fev): Padroniza mensagens conversacionais com sete kinds de evento efêmeros (25800-25806) para status, deltas de streaming, prompts e respostas. Também cobre chamadas de ferramenta, erros e cancelamento. Eventos “AI Info” kind 31340 permitem agentes anunciarem modelos e capacidades suportados.

NIP-AC: DVM Agent Coordination (aberto 18 fev): Estende NIP-90 para fluxos de trabalho de agente autônomo. Adiciona heartbeats para descoberta de agente. Inclui revisões de trabalho para rastreamento de qualidade. Fornece escrow de dados para comprometimento de resultado, cadeias de fluxo de trabalho para pipelines de múltiplas etapas e licitação em enxame para seleção competitiva de provedor. Uma implementação de referência roda em 2020117.xyz.

NIP-AD: MCP Server Announcements (aberto 12 fev): Padroniza anúncio de servidores Model Context Protocol e habilidades no Nostr. Já em uso na plataforma TENEX.

Outros PRs Abertos:

NIP-144: Service Authorization Protocol: Define como clientes provam identidade e permissões a provedores de serviço no Nostr.

NIP-DC: Nostr Webxdc: alexgleason propõe integrar Webxdc (aplicações web descentralizadas) com eventos Nostr.

Deep Dive de NIP: NIP-55 (Android Signer Application)

NIP-55 define como clientes Nostr Android solicitam operações criptográficas de aplicações assinadoras dedicadas. Com White Noise v0.3.0 e Unfiltered v1.0.6 ambos adicionando suporte ao Amber esta semana, o protocolo de assinatura Android merece exame.

Canais de Comunicação:

NIP-55 habilita assinatura entre apps através de dois mecanismos. Intents fornecem aprovação manual do usuário com feedback visual para operações únicas. Content Resolvers habilitam assinatura automatizada quando usuários concedem permissões persistentes, deixando apps assinarem em background sem prompts repetidos.

Comunicação usa o esquema URI personalizado nostrsigner:. Um cliente inicia contato com:

nostrsigner:<base64-encoded-event>?type=sign_event&callbackUrl=myapp://callback

Operações Suportadas:

A spec define sete métodos criptográficos: assinatura de evento (sign_event) e recuperação de chave pública (get_public_key). Também oferece criptografia/descriptografia NIP-04 e criptografia/descriptografia NIP-44. Por fim, inclui descriptografia de evento zap (decrypt_zap_event).

Modelo de Permissão:

Clientes chamam get_public_key uma vez para estabelecer uma relação de confiança, recebendo o nome de pacote do assinador e pubkey do usuário. A spec determina que clientes salvem esses valores e nunca chamem get_public_key novamente, prevenindo ataques de fingerprinting.

Para requisições de assinatura, usuários podem aprovar uma vez ou conceder “lembrar minha escolha” para operações em background. Se usuários consistentemente rejeitam operações, o assinador retorna um status “rejeitado”, prevenindo prompts repetidos.

Implementações:

Amber é o assinador NIP-55 primário para Android. Clientes suportando NIP-55 incluem Amethyst, White Noise e Unfiltered, entre outros. Aplicações web não podem receber respostas do assinador diretamente e devem usar URLs de callback ou operações de clipboard.

Relação com Outros NIPs de Assinatura:

NIP-55 complementa NIP-07 (extensões de navegador) e NIP-46 (assinatura remota sobre relays). Onde NIP-07 lida com navegadores desktop e NIP-46 lida com assinatura entre dispositivos, NIP-55 fornece integração nativa Android com latência mínima.

Deep Dive de NIP: NIP-60 (Cashu Wallet)

NIP-60 define como carteiras ecash Cashu armazenam estado em relays Nostr, habilitando sincronização de carteira entre aplicações. Com Ridestr v0.2.6 usando NIP-60 para sincronização de carteira entre dispositivos, o protocolo merece exame.

Kinds de Evento:

NIP-60 usa quatro tipos de evento. O kind substituível 17375 armazena configuração de carteira incluindo URLs de mint e uma chave privada dedicada para receber pagamentos ecash P2PK. Eventos de token (kind 7375) contêm provas criptográficas não gastas, enquanto histórico de gastos (kind 7376) registra transações para transparência do usuário. Um kind opcional 7374 rastreia cotações de pagamento de mint.

Arquitetura de Carteira:

Estado de carteira vive em relays, tornando-o acessível através de aplicações. Um evento de carteira do usuário contém referências criptografadas a mints Cashu e uma chave privada específica da carteira separada da identidade Nostr do usuário. Essa separação importa: a chave da carteira lida com operações ecash enquanto a chave Nostr lida com funções sociais.

{
 "kind": 17375,
 "content": "<config-carteira-criptografado-nip44>",
 "tags": [["d", "cashu-wallet"]]
}

Gerenciamento de Prova:

Provas Cashu são instrumentos ao portador. Uma vez gasta, uma prova se torna inválida. NIP-60 gerencia isso através de um mecanismo de rollover: ao gastar, clientes criam um novo evento de token com provas não gastas restantes e deletam o original via NIP-09. IDs de token destruídos vão em um campo del para rastreamento de estado.

Clientes devem periodicamente validar provas contra mints para detectar credenciais previamente gastas. Múltiplos eventos de token por mint são permitidos, e eventos de histórico de gastos ajudam usuários a rastrear transações mesmo sendo opcionais.

Modelo de Segurança:

Todos os dados sensíveis usam criptografia NIP-44. A chave privada da carteira nunca aparece em texto claro. Como relays armazenam blobs criptografados sem entender seus conteúdos, o estado da carteira permanece privado mesmo em relays não confiáveis.

Implementações:

Carteiras suportando NIP-60 incluem Nutsack e eNuts. Clientes como Ridestr usam NIP-60 para sincronização entre dispositivos, deixando usuários recarregarem no desktop e gastarem do mobile sem transferências manuais.

É isso por esta semana. Construindo algo ou tem novidades para compartilhar? Entre em contato via NIP-17 DM ou nos encontre no Nostr.

Nostr Compass #10

Wed, 18 Feb 2026 00:00:00 +0000

Bem-vindo de volta ao Nostr Compass, seu guia semanal sobre o Nostr.

Esta semana: Uma camada de cache local do Blossom toma forma à medida que projetos independentes convergem para acesso offline a mídia no Android. Alby lança um sandbox para desenvolvedores NWC para criar e testar integrações de Nostr Wallet Connect sem arriscar fundos reais. Propostas concorrentes para comunicação de agentes de IA no Nostr chegam na mesma semana de dois autores diferentes. fiatjaf remove campos não utilizados do NIP-11, eliminando políticas de retenção, códigos de país, política de privacidade e tags de preferência de comunidade que operadores de relay nunca adotaram. O NIP-85 faz merge com orientações de descoberta de provedores de serviço para Trusted Assertions. Uma nova tag D no NIP-52 habilita indexação temporal com granularidade de dia para eventos de calendário. Novos projetos incluem Mapnolia para distribuição descentralizada de tiles de mapa, Pika para mensagens criptografadas com MLS, Keep para assinatura de limiar FROST no Android, Hashtree para armazenamento endereçado por conteúdo com integração Nostr, e Prism para compartilhar conteúdo no Nostr a partir de qualquer app Android. Primal Android faz merge de 11 PRs de NWC adicionando suporte a carteira dupla e ciclo de vida automático do serviço. Mostro Mobile lança carteira Lightning embutida via integração NWC. Notedeck se prepara para lançamento na Android App Store enquanto o HAVEN alcança v1.2.0-rc3 com suporte a múltiplos npubs e backup em nuvem. Os deep dives desta semana cobrem o sistema de Trusted Assertions do NIP-85 para delegar cálculos de Web of Trust a provedores de serviço, e o protocolo de Eventos de Calendário do NIP-52 após sua atualização de indexação com granularidade de dia.

Notícias

Camada de Cache Local do Blossom Emerge

Múltiplos projetos independentes estão convergindo para o mesmo problema: acesso offline a mídia Blossom em dispositivos móveis.

Morganite, um novo app Android de greenart7c3 (o desenvolvedor por trás do Amber e do Citrine), implementa cache no lado do cliente para mídia Blossom. Usuários podem acessar imagens e arquivos visualizados anteriormente sem conexão de rede.

Aerith lançou v0.2 com rotulagem de imagens, operações em massa de espelhamento/marcação/exclusão, filtragem por rótulo e tipo de arquivo, além de suporte inicial a cache local Blossom. Aerith é uma interface de gerenciamento para usuários que armazenam mídia em múltiplos servidores Blossom e precisam organizar e espelhar seus blobs.

Um novo guia de implementação de cache local na especificação do Blossom documenta armazenamento de blobs no lado do cliente, enquanto Prism (do mesmo desenvolvedor do Aerith) adiciona integração de upload Blossom ao seu fluxo de compartilhamento para Nostr no Android. Quatro projetos independentes convergiram para o mesmo problema esta semana: um app dedicado de cache, um gerenciador de mídia, uma especificação de referência e uma ferramenta de compartilhamento com integração Blossom, todos implementando armazenamento local persistente além do simples upload e recuperação.

Sandbox NWC para Desenvolvedores da Alby

Alby lançou um ambiente sandbox para desenvolvedores que trabalham com Nostr Wallet Connect (NIP-47). O sandbox oferece um serviço NWC hospedado onde desenvolvedores podem criar conexões de teste e enviar pagamentos simulados sem conectar a uma carteira Lightning real, enquanto observam o ciclo completo de requisição/resposta de eventos NWC em tempo real. Desenvolvedores geram uma string de conexão nostr+walletconnect:// a partir do sandbox e a passam para o cliente. O sandbox então exibe os eventos kind 23194 de requisição e kind 23195 de resposta conforme fluem entre o cliente e o serviço de carteira.

Isso reduz a barreira para novas integrações NWC. Anteriormente, os testes exigiam uma carteira Lightning pessoal ou um serviço NWC auto-hospedado. O sandbox abstrai isso, fornecendo aos desenvolvedores um ciclo de feedback imediato para implementar os métodos pay_invoice, get_balance, make_invoice, lookup_invoice e list_transactions contra um endpoint NWC ativo.

NIPs de Agentes de IA Chegam

Propostas para comunicação de agentes de IA no Nostr apareceram com poucos dias de diferença, abordando o problema sob ângulos distintos.

NIP-XX: AI Agent Messages de joelklabo define um protocolo completo para interação de agentes de IA: kinds de evento para prompts, respostas, deltas de streaming, atualizações de status, telemetria de ferramentas, erros, cancelamentos e descoberta de capacidades. Um evento de descoberta ai.info (kind 31340, substituível) permite que agentes anunciem seus modelos suportados, ferramentas com schemas, suporte a streaming e limites de taxa. A proposta de joelklabo inclui correlação de execução via ID de prompt, gerenciamento de sessão, reconciliação de stream com ordenação por sequência e orientações do NIP-59 para privacidade de metadados.

NIP-AE: Agents de pablof7z adota uma abordagem diferente, definindo kinds para instanciação de agentes: definições e lições. Esses são os tipos de evento que pablof7z usa no TENEX, o sistema de aprendizado autônomo construído sobre Nostr. Uma proposta complementar, NIP-AD: MCP Server and Skill Announcements, também de pablof7z, define eventos para anunciar servidores do Model Context Protocol e habilidades no Nostr. Comentários NIP-22 são suportados, de modo que a comunidade pode discutir e avaliar servidores MCP diretamente no Nostr.

NIP-XX cobre a comunicação completa entre agentes, enquanto NIP-AE e NIP-AD endereçam identidade e descoberta de ferramentas. Essas propostas podem convergir em um padrão unificado ou coexistir como camadas complementares.

Lançamentos

HAVEN v1.2.0-rc3

HAVEN, o relay pessoal tudo-em-um que reúne quatro funções de relay com um servidor de mídia Blossom, alcançou v1.2.0-rc3. Este release candidate adiciona suporte a múltiplos npubs, permitindo que uma única instância do HAVEN sirva várias identidades Nostr. RCs anteriores adicionaram as flags --from-cloud e --to-cloud para backup em nuvem (RC2) e corrigiram um bug de dupla contagem no Web of Trust (RC1).

Mostro Mobile v1.2.0: Carteira Lightning Embutida

Mostro Mobile, o cliente mobile para a exchange P2P de Bitcoin Mostro (v1.1.0 coberta na semana passada), lançou v1.2.0 com uma carteira Lightning embutida por meio de integração completa com NWC (NIP-47). Compradores e vendedores não precisam mais alternar entre apps para gerenciar invoices. O app detecta hold invoices para vendedores e as paga automaticamente pela carteira conectada, enquanto compradores recebem geração automática de invoice. O lançamento segue o v1.1.1 do início da semana, que adicionou suporte a múltiplos nós Mostro com um registro curado de instâncias confiáveis, busca de metadados kind 0 para exibição de nós, gerenciamento de nós personalizados por pubkey e fallback automático quando o nó selecionado fica offline.

No lado servidor, o Mostro v0.16.2 chegou com correções para pagamentos duplicados de taxa de desenvolvimento, limitação de taxa no endpoint RPC de validação de senha e limpeza adequada de disputas em cancelamento cooperativo.

Um novo projeto complementar, mostro-skill, permite que agentes negociem no Mostro via Nostr.

Aerith v0.2

Aerith, o gerenciador de imagens Blossom, lançou v0.2 com rótulos de imagem para organizar mídia, operações em massa de espelhamento/marcação/exclusão entre servidores, filtragem por rótulo e tipo de arquivo, além de suporte inicial a cache local. Veja a seção de Notícias para contexto sobre a tendência mais ampla de cache local.

Mapnolia: Tiles de Mapa Descentralizados via Nostr

Mapnolia é um novo servidor de dados geoespaciais que divide arquivos de mapa PMTiles em regiões geográficas e as anuncia via Nostr para descoberta descentralizada. Ele publica eventos substituíveis parametrizados kind 34444 em relays Nostr contendo um índice completo de fragmentos de tiles de mapa com metadados de camadas, regiões de geohash, referências de arquivos e detalhes de servidor Blossom.

Clientes descobrem e recuperam dados de mapa pela rede Nostr em vez de servidores centralizados de tiles, com eventos de anúncio carregando metadados suficientes para solicitar apenas as regiões geográficas necessárias dos servidores Blossom listados. Mapnolia é o primeiro projeto a trazer distribuição de dados geoespaciais para o Nostr, abrindo possibilidades para aplicações de mapeamento com suporte offline.

Pika: Mensagens Criptografadas Baseadas em Marmot

Pika é um novo app de mensagens criptografadas ponta a ponta para iOS e Android usando o protocolo Marmot, que camada o Messaging Layer Security (MLS) sobre relays Nostr. A arquitetura separa as responsabilidades em um núcleo Rust (pika_core) que gerencia o estado MLS e a criptografia/descriptografia de mensagens sobre relays Nostr, com camadas nativas finas de UI em SwiftUI (iOS) e Kotlin (Android). O estado flui unidirecionalmente: a UI despacha ações para o ator Rust, que muta o estado e emite snapshots com números de revisão de volta para a UI via bindings UniFFI e JNI.

Pika se junta a um campo crescente de mensageiros MLS-sobre-Nostr ao lado de White Noise, Vector e 0xchat. Todos usam relays Nostr como camada de transporte para texto cifrado criptografado por MLS, mantendo os operadores de relay incapazes de ler o conteúdo das mensagens. Pika usa o Marmot Development Kit (MDK) para sua implementação MLS e nostr-sdk para conectividade com relays.

Keep: Assinatura de Limiar FROST para Android

Keep é um novo aplicativo Android para assinatura de limiar FROST onde nenhum dispositivo único detém a chave privada completa. Ele implementa NIP-55 (Android Signer) e NIP-46 (assinatura remota), de modo que clientes Nostr compatíveis podem solicitar assinaturas enquanto o material de chave permanece distribuído entre dispositivos. As configurações padrão são 2-de-3 e 3-de-5, embora qualquer limiar t-de-n seja suportado.

A cerimônia de geração distribuída de chaves (DKG) do Keep é executada sobre relays Nostr usando kinds de evento personalizados: kind 21101 para anúncios de grupo, kind 21102 para polinômios de comprometimento da rodada 1 (difundidos publicamente) e kind 21103 para compartilhamentos secretos da rodada 2 (criptografados ponto a ponto com NIP-44 entre participantes). O escalar da chave privada do grupo nunca é calculado ou montado em nenhum lugar durante o DKG. Cada dispositivo mantém apenas sua avaliação de polinômio, e quaisquer t compartilhamentos podem produzir uma assinatura Schnorr válida por meio de um protocolo de comprometer-depois-assinar em duas rodadas. A assinatura resultante de 64 bytes é indistinguível de uma assinatura Schnorr de signatário único. Por baixo, Keep usa o crate frost-secp256k1-tr da Zcash Foundation com ajuste Taproot, de modo que a chave pública do grupo funciona diretamente como um npub Nostr.

Keep se junta à família Frostr de projetos ao lado de Igloo Desktop, Igloo para Android, Frost2x e Igloo para iOS, expandindo as opções de gerenciamento de chaves por limiar no Nostr.

Prism: Compartilhe Qualquer Coisa no Nostr a Partir do Android

Prism é um novo app Android (Kotlin/Jetpack Compose, API 26+) que se registra como destino de compartilhamento do sistema, permitindo que usuários publiquem textos, URLs, imagens e vídeos no Nostr a partir de qualquer app do celular. URLs compartilhadas passam por um removedor de parâmetros de rastreamento antes de serem compostas em notas. Prism busca metadados OpenGraph para gerar pré-visualizações ricas de links e renderiza referências Nostr nativas (note1, nevent1) inline.

O mecanismo de agendamento usa uma abordagem híbrida AlarmManager/WorkManager para contornar as otimizações de bateria do Android: AlarmManager gerencia o tempo preciso de wake-up enquanto tarefas expedidas do WorkManager garantem a entrega, com retry exponencial para cenários offline. Uploads de mídia passam por servidores Blossom configuráveis com geração de miniaturas para imagens e frames de vídeo. Toda assinatura de eventos é delegada a assinadores externos NIP-55 como o Amber, com suporte a múltiplas contas para alternar entre identidades. Prism também suporta posts de NIP-84 (Highlights). Do mesmo desenvolvedor do Aerith.

Hashtree: Armazenamento Endereçado por Conteúdo com Integração Nostr

Hashtree é um sistema de armazenamento de blobs endereçado por conteúdo baseado em sistema de arquivos que publica raízes Merkle no Nostr para criar endereços mutáveis npub/caminho. O sistema usa “armazenamento burro” que funciona com qualquer store chave-valor, dividindo o conteúdo em blocos de 2MB otimizados para uploads Blossom. Ao contrário do BitTorrent, não é necessário computação ativa de prova Merkle - basta armazenar e recuperar blobs por hash.

A integração Nostr possibilita URLs remotas git como htree://npub.../nome-do-repo para clonar repositórios, com comandos como htree publish mydata <hash> para publicar hashes de conteúdo em endereços npub.../mydata. A CLI abrangente suporta modos de armazenamento criptografado (padrão) e público, fixação de conteúdo, envio a servidores Blossom e gerenciamento de identidades Nostr. Cada item armazenado é ou bytes brutos ou um nó de árvore, fornecendo uma base para distribuição descentralizada de conteúdo pela rede de relays do Nostr.

Espy: Captura de Paleta de Cores no Shakespeare

Espy, construído na plataforma Shakespeare, permite que usuários capturem paletas de cores de fotos e as compartilhem como eventos Nostr. Shakespeare é um construtor de apps com IA que autentica usuários via extensões de navegador NIP-07 e fornece conectividade integrada com relays Nostr, de modo que desenvolvedores publicam apps sem implementar seu próprio gerenciamento de chaves ou pool de relays. Espy extrai cores dominantes da câmera em cartões de paleta compartilháveis descobríveis por feeds Nostr padrão.

Flotilla 1.6.4

Flotilla, o cliente Nostr semelhante ao Discord de hodlbod que organiza relays como grupos, lançou 1.6.4. A família de projetos Coracle migrou do GitHub para uma instância Gitea auto-hospedada. Este lançamento adiciona notificações push via NIP-9a e um fluxo de recebimento de carteira, além de listagens classificadas e suporte a URL de espaço. Melhorias de interface incluem modais e tratamento de notificações simplificados. Silenciamento de salas e insets de área segura em mobile complementam as mudanças, junto com correções para uploads de imagem no Safari e detalhes de eventos de calendário.

Shosho v0.12.0

Shosho, o app mobile de transmissão ao vivo com integração Nostr, lançou v0.12.0. Este lançamento adiciona Clips de vídeo com respostas dentro do player e integração de emoji personalizado. A proteção de thread bloqueia spam de menções indiretas, e um novo recurso de compartilhamento por QR permite que usuários troquem perfis offline. Um novo modo de reprodução horizontal oferece uma experiência de visualização estilo Twitch, e a tela de navegação agora apresenta clips de criadores ao lado de transmissões ao vivo.

Granary v10.0

Granary, uma biblioteca de tradução de redes sociais que converte dados entre Nostr, Bluesky, ActivityPub e outras plataformas em um formato comum, lançou v10.0 com mudanças que quebram compatibilidade. O lançamento muda os IDs ActivityStreams 1 padrão do Nostr de bech32 para hex e adiciona suporte expandido ao Nostr, incluindo parsing de menções NIP-27 e tags de artigo. Uma nova opção de saída múltipla nos conversores permite que desenvolvedores traduzam entre protocolos em lote.

Nostr MCP Server v3.0.0

Nostr MCP Server, um servidor de Model Context Protocol que permite a agentes de IA interagirem com a rede Nostr, lançou v3.0.0. Este lançamento principal adiciona ações sociais (follows, reações, reposts, respostas) e gerenciamento de lista de relays com suporte a NIP-65 mais autenticação opcional NIP-42. Mensagens diretas via NIP-17 e NIP-44 também são novidades. O lançamento se complementa com as propostas de NIP para agentes de IA desta semana como ferramental prático para agentes que operam no Nostr.

Aegis v0.3.8

Aegis, o assinador Nostr multiplataforma, lançou v0.3.8 com suporte a UI multilíngue e um gerenciador de atualização incremental para seu navegador de apps Nostr embutido. O novo mecanismo de atualização faz diff incremental contra o estado local, mantendo o diretório interno de apps web Nostr atualizado com menor uso de largura de banda. O lançamento também introduz cache de 5 minutos para material de chave, reduzindo as idas ao banco de dados ao assinar múltiplos eventos em sequência.

SNSTR v0.3.1

SNSTR (Secure Nostr Software Toolkit for Renegades), uma biblioteca TypeScript para o protocolo Nostr, lançou v0.3.1. O lançamento adiciona verificações de pacote garantindo que todos os pontos de entrada estejam incluídos nos tarballs npm, com aplicação por CI no Node e Bun. O v0.3.0 foi lançado na mesma semana.

Citrine v2.0.0-pre1

Citrine, o relay Nostr Android de greenart7c3, lançou v2.0.0-pre1 com melhorias de desempenho por meio de índices de banco de dados otimizados e melhor tratamento de coroutines Kotlin. O lançamento também aprimora o suporte para hospedagem de web apps, com cada app agora rodando em sua própria porta.

Atualizações de Projetos

Primal Android: Expansão da Infraestrutura NWC

Primal Android fez merge de 11 PRs relacionados a NWC esta semana, continuando a construção iniciada há duas semanas. Este lote adiciona suporte a NWC para carteira dupla, início/parada automática do serviço vinculada a notificações do backend, roteamento de conexão por tipo de carteira e limpeza adequada de dados ao excluir carteira. O serviço NWC agora gerencia seu próprio ciclo de vida com base no estado de conexão da carteira, reduzindo a intervenção manual do usuário.

Notedeck: Preparação para Android App Store

Notedeck, o cliente Nostr multiplataforma da equipe Damus, fez merge da preparação para lançamento na Android App Store esta semana. O PR adiciona um plano de conformidade UGC (Conteúdo Gerado pelo Usuário) exigido pelo Google Play, incluindo uma tela de aceitação dos Termos de Serviço, bloqueio de usuários via menus de contexto e configurações, funcionalidade NIP-56 (Reporting) que publica eventos de denúncia em relays, e uma seção de configurações de Conteúdo e Segurança. Infraestrutura de build foi adicionada para geração de APKs e AABs (Android App Bundles) de lançamento assinados via novos targets Makefile. Um documento EULA estabelece requisito de idade de 17 anos e isenções de responsabilidade específicas do Nostr sobre conteúdo descentralizado. Os próprios recursos de conformidade serão entregues em PRs subsequentes; este merge estabelece as bases de documentação e assinatura.

No lado iOS do Damus, foi lançada uma correção para uma regressão de spinner de carregamento infinito onde o spinner persistia indefinidamente após o conteúdo ter sido carregado.

Nostria: Relays de Descoberta e Correções de DM

Nostria, o cliente Nostr multiplataforma focado em escala global, fez merge de 9 PRs esta semana. O mais notável adiciona inicialização automática de Relays de Descoberta para busca de perfis, dando a novos usuários conectividade funcional com relays sem configuração manual. Outras correções tratam de quebra de linha na área de texto de DM, preenchimento de viewport em vídeo fullscreen, extração de metadados de artigos em pré-visualizações de repost e resolução de URI nostr: em notificações.

Camelus: Migração para Riverpod v3

Camelus, o cliente Nostr baseado em Flutter, fez merge de 5 PRs esta semana centrados em uma migração de API para Riverpod v3 e refatoração de feed genérico. Um cache de notas embutidas evita buscas redundantes em relays para notas citadas.

Atualizações de NIPs

Mudanças recentes no repositório de NIPs:

Mergeado:

NIP-85: Descoberta de Provedores de Serviço: vitorpamplona adicionou orientações sobre descoberta pelo cliente de provedores de serviço de NIP-85 Trusted Assertions, incluindo dicas de relay e chaves de serviço específicas por algoritmo. Veja o deep dive abaixo para cobertura completa.
NIP-11: Limpeza de Informações de Relay: fiatjaf removeu privacy_policy, o array retention, relay_countries e o bloco de preferências de comunidade do NIP-11. Operadores de relay raramente populavam esses campos e os clientes não agiam sobre eles.
NIP-52: Tag de Timestamp com Granularidade de Dia: staab adicionou uma tag D obrigatória ao NIP-52 para eventos de calendário baseados em tempo (kind 31923) representando o timestamp Unix com granularidade de dia, calculado como floor(unix_seconds / 86400). Múltiplas tags D cobrem eventos de vários dias, habilitando indexação temporal eficiente sem precisar analisar timestamps completos.
NIP-47: Simplificação: O PR de simplificação discutido no Compass #9 foi mergeado esta semana, removendo multi_pay_invoice e multi_pay_keysend do NIP-47 (Nostr Wallet Connect). Veja o Compass #8 para o deep dive completo do protocolo NWC.

PRs Abertos e Discussões:

NIP-74: Podcasts: Coberto no Compass #8, esta proposta de especificação de podcast gerou discussão acalorada esta semana. staab observou que já existem pelo menos três padrões concorrentes de podcast em uso, e derekross apontou para uma implementação existente de seis meses com apps e podcasts ativos. O caminho a seguir exige convergência entre implementações antes que um número de NIP possa ser atribuído.
NIP-XX: AI Agent Messages: joelklabo propõe um protocolo completo de comunicação de agentes de IA com kinds de evento para prompts, respostas, streaming, telemetria de ferramentas, erros e descoberta de capacidades. Veja a seção de Notícias para cobertura de todas as propostas de IA desta semana.
NIP-PNS: Private Note Storage: O sistema de notas privadas de jb55 define eventos kind 1080 para armazenar notas pessoais criptografadas em relays sem revelar quem as escreveu. O esquema deriva um par de chaves pseudônimo determinístico a partir do nsec do usuário via HKDF: pns_key = hkdf_extract(ikm=device_key, salt="nip-pns"), depois gera um par de chaves secp256k1 a partir dessa chave derivada. Uma segunda derivação produz uma chave de criptografia simétrica: pns_nip44_key = hkdf_extract(ikm=pns_key, salt="nip44-v2"). As notas internas são criptografadas com NIP-44 v2 usando essa chave e publicadas sob a pubkey pseudônima, de modo que relays veem eventos kind 1080 de uma identidade desvinculada da chave principal do usuário. Ao contrário dos gift wraps do NIP-59, o PNS não é passível de spam (a chave pseudônima é determinística, não aleatória) e não carrega metadados públicos (nenhuma tag p é necessária, pois não há destinatário). Esta semana, jb55 publicou descobertas da implementação do PNS no backend Rust do Notedeck (módulo enostr::pns). Ele identificou que a chamada hkdf_extract da especificação é ambígua porque o HKDF RFC 5869 tem duas fases (Extract e Expand) que produzem saída diferente, e a maioria das bibliotecas espera ambas. Ele esclareceu que pns_nip44_key contorna o acordo de chaves ECDH normal do NIP-44 e é usada diretamente como a chave de conversa, um detalhe que implementadores precisam saber, pois a maioria das bibliotecas NIP-44 usa ECDH por padrão. Ele também sinalizou uma variável indefinida na implementação de referência TypeScript. O PR, originalmente de abril de 2025, está agora sendo ativamente implementado.
NIP-AE: Agents: pablof7z define quatro kinds de evento para identidade de agente no Nostr, extraídos de seu trabalho no TENEX. O template base é kind 4199 (Agent Definition), carregando título, descrição de papel, instruções do sistema, declarações de ferramentas e versão. Modificadores comportamentais ficam no kind 4201 (Agent Nudge), que usa as tags only-tool, allow-tool e deny-tool para controle de capacidades em tempo de execução. Agentes publicam o que aprendem como eventos kind 4129 (Agent Lesson), categorizados e vinculados de volta à definição pai via tags e, refinável por meio de threads de comentário NIP-22. A verificação de propriedade usa kind 14199, um evento substituível onde operadores humanos listam seus pubkeys de agente, estabelecendo uma cadeia bidirecional quando combinado com a tag p do perfil kind 0 do agente.
NIP-AD: MCP Server and Skill Announcements: pablof7z define eventos para anunciar servidores do Model Context Protocol e habilidades individuais no Nostr. Anúncios de servidor MCP carregam a URL de endpoint do servidor e a versão de protocolo suportada junto com uma lista de ferramentas disponíveis com seus schemas de entrada. Comentários NIP-22 são suportados em anúncios de servidor, de modo que a comunidade pode discutir e avaliar servidores MCP diretamente no Nostr.
NIP-73: Tag de Kind OSM: DestBro propõe adicionar identificadores OpenStreetMap ao NIP-73 (External Content IDs), que padroniza como eventos Nostr referenciam conteúdo externo como livros (ISBN), filmes (ISAN), feeds de podcast (GUID), geohashes e URLs via tags i e k. O kind OSM proposto permitiria que eventos referenciem recursos de mapa específicos (edifícios, estradas, parques) por seu ID de nó ou via OpenStreetMap, conectando conteúdo Nostr ao banco de dados geográfico aberto.
NIP-XX: Variantes de Imagem Responsiva: woikos propõe estender eventos de metadados de arquivo NIP-94 com tags para variantes de imagem responsiva em diferentes resoluções. Clientes poderiam selecionar a variante apropriada com base no tamanho da tela e nas condições de rede, reduzindo largura de banda para usuários de dispositivos móveis visualizando imagens de alta resolução hospedadas em servidores Blossom.

Deep Dive de NIP: NIP-85 (Trusted Assertions)

O NIP-85 define um sistema para delegar cálculos custosos a provedores de serviço confiáveis que publicam resultados assinados como eventos Nostr. Pontuações de Web of Trust e métricas de engajamento exigem rastrear muitos relays e processar grandes volumes de eventos, trabalho que é impraticável em dispositivos móveis. O merge desta semana adicionou orientações sobre o processo de descoberta de provedores pelo cliente.

Delegação:

Calcular a pontuação de Web of Trust de um usuário exige rastrear grafos de follows com múltiplos saltos em muitos relays, e calcular contagens precisas de seguidores significa desduplicar em toda a rede de relays. Dispositivos móveis e clientes de navegador não conseguem executar essas operações, mas os resultados são essenciais para filtragem de spam e ranqueamento de conteúdo. O NIP-85 preenche essa lacuna permitindo que usuários designem provedores confiáveis para executar os cálculos e publicar resultados como eventos Nostr padrão.

Design do Protocolo:

O NIP-85 usa quatro kinds de evento para asserções sobre diferentes tipos de sujeito. Asserções de usuário (kind 30382) carregam contagem de seguidores, contagens de posts/respostas/reações, volumes de zap, rank normalizado (0-100), tópicos comuns e horas ativas:

{
 "id": "<event hash>",
 "pubkey": "<service pubkey>",
 "created_at": 1739836800,
 "kind": 30382,
 "tags": [
 ["d", "e88a691e98d9987c964521dff60025f60700378a4879180dcbbb4a5027850411"],
 ["rank", "89"],
 ["followers", "4521"],
 ["first_created_at", "1609459200"],
 ["post_cnt", "1283"],
 ["reply_cnt", "647"],
 ["reactions_cnt", "8920"],
 ["zap_amt_recd", "850000"],
 ["zap_amt_sent", "320000"],
 ["zap_cnt_recd", "412"],
 ["zap_cnt_sent", "198"],
 ["zap_avg_amt_day_recd", "1150"],
 ["zap_avg_amt_day_sent", "430"],
 ["reports_cnt_recd", "2"],
 ["reports_cnt_sent", "0"],
 ["t", "nostr"],
 ["t", "bitcoin"],
 ["active_hours_start", "14"],
 ["active_hours_end", "22"]
 ],
 "content": "",
 "sig": "<service key signature>"
}

Asserções de evento (kind 30383) avaliam notas individuais com contagem de comentários, citações, reposts, reações e dados de zap:

{
 "id": "<event hash>",
 "pubkey": "<service pubkey>",
 "created_at": 1739836800,
 "kind": 30383,
 "tags": [
 ["d", "<target event id>"],
 ["rank", "72"],
 ["comment_cnt", "45"],
 ["quote_cnt", "12"],
 ["repost_cnt", "89"],
 ["reaction_cnt", "310"],
 ["zap_cnt", "23"],
 ["zap_amount", "125000"]
 ],
 "content": "",
 "sig": "<service key signature>"
}

Para eventos endereçáveis (artigos de forma longa, páginas wiki), o kind 30384 aplica as mesmas métricas de engajamento em todas as versões coletivamente. O kind 30385 avalia identificadores externos (livros, filmes, sites, locais, hashtags) referenciados via NIP-73 (External Content IDs), que padroniza como eventos Nostr referenciam conteúdo externo via tags i e k:

{
 "id": "<event hash>",
 "pubkey": "<service pubkey>",
 "created_at": 1739836800,
 "kind": 30385,
 "tags": [
 ["d", "isbn:9780765382030"],
 ["k", "isbn"],
 ["rank", "94"],
 ["comment_cnt", "67"],
 ["reaction_cnt", "203"]
 ],
 "content": "",
 "sig": "<service key signature>"
}

Cada asserção é um evento endereçável substituível onde a tag d contém o sujeito: um pubkey, ID de evento, endereço de evento ou identificador NIP-73. Provedores de serviço assinam esses eventos com suas próprias chaves, e clientes os avaliam com base nas relações de confiança.

Descoberta de Provedores:

Usuários declaram quais provedores de asserção confiam publicando eventos kind 10040. Cada entrada especifica o tipo de asserção com o pubkey do provedor e dica de relay, mais variantes de algoritmo opcionais:

{
 "id": "<event hash>",
 "pubkey": "<user pubkey>",
 "created_at": 1739836800,
 "kind": 10040,
 "tags": [
 ["30382:rank", "4fd5e210...", "wss://nip85.nostr.band"],
 ["30382:rank", "3d842afe...", "wss://nostr.wine"],
 ["30382:zap_amt_sent", "4fd5e210...", "wss://nip85.nostr.band"],
 ["30383:rank", "4fd5e210...", "wss://nip85.nostr.band"]
 ],
 "content": "",
 "sig": "<user signature>"
}

Usuários podem criptografar a lista de tags em .content usando NIP-44 para manter suas preferências de provedor privadas. Clientes constroem uma lista de provedores verificando quais provedores as contas que seguem confiam, criando uma camada de reputação descentralizada para os próprios provedores de asserção.

Modelo de Segurança:

Provedores devem usar chaves de serviço diferentes para algoritmos distintos, e uma chave única por usuário quando os algoritmos são personalizados, evitando correlação cruzada de consultas entre usuários. Cada chave de serviço recebe um evento de metadados kind 0 descrevendo o comportamento do algoritmo, dando aos usuários transparência sobre o que estão confiando. Eventos de asserção só devem ser atualizados quando os dados subjacentes realmente mudam, evitando tráfego desnecessário de relay e permitindo que clientes armazenem resultados em cache com segurança.

Adoção Atual:

O NIP-85 formaliza um padrão que já estava surgindo de forma informal. O servidor de cache do Primal computa métricas de engajamento e pontuações de Web of Trust. Antiprimal, coberto no Compass #9, faz bridge desses cálculos para clientes Nostr padrão usando kinds de evento NIP-85. Nostr.band opera o relay wss://nip85.nostr.band referenciado nos próprios exemplos da spec, servindo eventos de asserção para seus dados de índice de busca. No lado do cliente, Amethyst (de autoria de vitorpamplona, que também escreveu este NIP) tem suporte experimental a Trusted Assertions em sua biblioteca quartz, analisando eventos de asserção e declarações de provedores de serviço. Vertex computa métricas similares de Web of Trust, mas escolheu uma abordagem diferente, usando uma API direta em vez de eventos NIP-85, citando o problema de descoberta e o overhead computacional de arquiteturas baseadas em asserção. Com o NIP-85, qualquer cliente pode consumir asserções de qualquer provedor por meio de um formato de evento padrão, e provedores competem em precisão enquanto usuários escolhem em quem confiar.

Deep Dive de NIP: NIP-52 (Eventos de Calendário)

O NIP-52 define eventos de calendário no Nostr, dando aos clientes uma forma padrão de representar e descobrir ocorrências em momentos específicos ou entre momentos. O merge da tag D desta semana adicionou indexação com granularidade de dia, completando uma peça ausente na infraestrutura de consulta da spec.

Dois Tipos de Evento:

O NIP-52 separa eventos de calendário em dois kinds com base na precisão temporal. Eventos baseados em data (kind 31922) representam ocorrências de dia inteiro como feriados ou festivais de vários dias. Eles usam strings de data ISO 8601 em suas tags start e end opcionais, sem consideração de fuso horário:

{
 "id": "<event hash>",
 "pubkey": "<event creator pubkey>",
 "created_at": 1735689600,
 "kind": 31922,
 "content": "Annual celebration of Bitcoin's genesis block",
 "tags": [
 ["d", "bitcoin-independence-day-2026"],
 ["title", "Bitcoin Independence Day"],
 ["start", "2026-01-03"],
 ["end", "2026-01-04"],
 ["location", "Worldwide"],
 ["g", "u4pruydqqv"],
 ["t", "bitcoin"],
 ["p", "<organizer-pubkey>", "wss://relay.example.com", "host"],
 ["r", "https://bitcoinindependenceday.com"]
 ],
 "sig": "<event creator signature>"
}

Eventos baseados em tempo (kind 31923) representam momentos específicos com timestamps Unix em suas tags start e end opcionais, mais identificadores de fuso horário IANA (start_tzid, end_tzid) para exibição. Ambos os kinds são eventos substituíveis parametrizados, de modo que organizadores atualizam detalhes publicando um novo evento com a mesma tag d.

Calendários e RSVPs:

Eventos kind 31924 definem calendários como coleções, referenciando eventos via tags a que apontam para eventos kind 31922 ou 31923 por suas coordenadas de endereço:

{
 "id": "<event hash>",
 "pubkey": "<calendar owner pubkey>",
 "created_at": 1739836800,
 "kind": 31924,
 "content": "Nostr community events worldwide",
 "tags": [
 ["d", "nostr-community-calendar"],
 ["title", "Nostr Community Events"],
 ["a", "31923:<organizer-pubkey>:nostr-meetup-2026", "wss://relay.example.com"],
 ["a", "31922:<organizer-pubkey>:bitcoin-independence-day-2026"]
 ],
 "sig": "<calendar owner signature>"
}

Usuários podem manter múltiplos calendários (pessoal, trabalho, comunidade) e clientes podem assinar calendários de pubkeys específicos. Eventos de calendário podem incluir uma tag a referenciando um calendário para solicitar inclusão, habilitando gerenciamento colaborativo onde múltiplos usuários contribuem com eventos para calendários que não possuem.

RSVPs usam kind 31925, onde usuários publicam seu status de presença junto com um indicador opcional de livre/ocupado:

{
 "id": "<event hash>",
 "pubkey": "<attendee pubkey>",
 "created_at": 1739836800,
 "kind": 31925,
 "content": "Looking forward to it",
 "tags": [
 ["a", "31923:<organizer-pubkey>:nostr-meetup-2026", "wss://relay.example.com"],
 ["e", "<kind 31923 event id>", "wss://relay.example.com"],
 ["d", "<unique-rsvp-id>"],
 ["status", "accepted"],
 ["fb", "busy"],
 ["p", "<organizer-pubkey>", "wss://relay.example.com"]
 ],
 "sig": "<attendee signature>"
}

Os valores válidos de status são “accepted”, “declined”, “tentative”, e a tag opcional fb marca o usuário como livre ou ocupado naquele período. Eventos de RSVP referenciam a tag a do evento de calendário e carregam a tag p do organizador, de modo que o cliente do organizador pode agregar respostas entre relays.

A Adição da Tag D:

Antes do merge desta semana, clientes que consultavam eventos em um intervalo de datas precisavam buscar todos os eventos de um pubkey ou calendário e filtrar no lado do cliente. A nova tag D obrigatória em eventos baseados em tempo (kind 31923) contém um timestamp Unix com granularidade de dia calculado como floor(unix_seconds / 86400). Eventos de vários dias carregam múltiplas tags D, uma por dia. Relays agora podem indexar eventos por dia e responder a consultas filtradas de forma eficiente, transformando o que era um problema de filtragem no lado do cliente em uma busca por índice no lado do relay.

{
 "id": "<event hash>",
 "pubkey": "<event creator pubkey>",
 "created_at": 1739836800,
 "kind": 31923,
 "content": "Monthly meetup for Nostr developers in Austin",
 "tags": [
 ["d", "nostr-meetup-2026"],
 ["title", "Nostr Developer Meetup"],
 ["summary", "Talks and demos from local Nostr builders"],
 ["image", "https://example.com/meetup-banner.jpg"],
 ["start", "1740067200"],
 ["end", "1740078000"],
 ["start_tzid", "America/New_York"],
 ["end_tzid", "America/New_York"],
 ["D", "20139"],
 ["location", "Bitcoin Commons, Austin TX"],
 ["g", "9v6knb2pg"],
 ["p", "<organizer-pubkey>", "wss://relay.example.com", "host"],
 ["p", "<speaker-pubkey>", "wss://relay.example.com", "speaker"],
 ["t", "nostr"],
 ["t", "meetup"],
 ["r", "https://bitcoincommons.com"]
 ],
 "sig": "<event creator signature>"
}

O valor D de 20139 é igual a floor(1740067200 / 86400), posicionando este evento em 20 de fevereiro de 2025. Clientes que consultam “todos os eventos desta semana” enviam um filtro com o intervalo D correspondente, e os relays retornam apenas os eventos correspondentes.

Decisões de Design:

O NIP-52 omite intencionalmente eventos recorrentes. A spec deixa de fora as regras de recorrência (RRULE do iCalendar) completamente, delegando essa complexidade aos clientes. Um organizador publica eventos individuais para cada ocorrência, mantendo o modelo de dados no lado do relay simples. Tags de participante carregam papéis opcionais (“host”, “speaker”, “attendee”), e tags de localização podem incluir tags de geohash g para consultas espaciais junto com endereços legíveis por humanos.

Implementações:

Flockstr é o principal cliente de calendário construído sobre NIP-52. Coracle exibe eventos de calendário em seu feed social. A adição da tag D esta semana habilita indexação temporal no lado do relay que ambos os clientes podem usar para reduzir largura de banda ao consultar eventos em um intervalo de datas específico.

É isso por esta semana. Construindo algo ou tem novidades para compartilhar? Quer que cobramos seu projeto? Entre em contato via NIP-17 DM ou nos encontre no Nostr.

Nostr Compass #9

Wed, 11 Feb 2026 00:00:00 +0000

Bem-vindo de volta ao Nostr Compass, seu guia semanal sobre o Nostr.

Esta semana: Mostro lança seu primeiro beta público após três anos de desenvolvimento, trazendo negociação P2P de Bitcoin para mobile via Nostr. OpenSats concede sua décima sexta onda de grants Bitcoin, com Minibits Wallet recebendo renovação de grant. Zapstore alcança o lançamento estável 1.0, marcando a maturação da loja de apps Android descentralizada. Coracle 0.6.29 adiciona tópicos e comentários em highlights. Igloo Desktop v1.0.3 entrega endurecimento de segurança com assinatura de limiar Frostr. Amber v4.1.2-pre1 migra a arquitetura Flow. Angor alcança v0.2.5 com UI de financiamento renovada e configuração de servidor de imagens NIP-96. NostrPress surge como ferramenta que converte perfis Nostr em blogs estáticos. Antiprimal entrega gateway compatível com padrões que faz bridge do servidor de cache proprietário do Primal a NIPs padrão do Nostr. Primal Android faz merge de 18 PRs expandindo infraestrutura NWC com suporte a carteira dupla, logging de auditoria e o método lookup_invoice. diVine entrega feeds de vídeo API-first. O SDK TypeScript do Marmot separa seu app de chat de referência em repositório independente e começa migração a ts-mls v2. O repositório de NIPs faz merge de contagem aproximada HyperLogLog no NIP-45 e extrai tags de identidade do kind 0. Propostas de vitorpamplona começam a sistematicamente reduzir eventos de metadados kind 0. Novas propostas de protocolo incluem Nostr Relay Connect (traversal de NAT) e Nostr Web Tokens (claims web assinados). Os deep dives cobrem a contagem aproximada HyperLogLog do NIP-45 e o protocolo de armazenamento de arquivos HTTP do NIP-96, agora depreciado em favor do Blossom, enquanto projetos navegam a transição entre os dois padrões de mídia.

Notícias

Mostro Lança Primeiro Beta Público

Mostro, a exchange peer-to-peer de Bitcoin construída sobre Nostr, lançou seu app mobile v1.1.0, o primeiro beta público do projeto após três anos de desenvolvimento. O app permite que usuários negociem Bitcoin diretamente usando Nostr na coordenação de ordens, com Lightning na liquidação e nenhum intermediário custodial.

O lançamento introduz notificações push com confiabilidade em background melhorada no Android, sistema opcional de logging que permite capturar e compartilhar dados de diagnóstico quando surgem problemas, atualizações de relay mais suaves usando inicialização aditiva, e refinamentos de UI da Fase 2 com suporte a internacionalização. O app está disponível na Zapstore e como download direto do GitHub.

Mostro se junta a Shopstr e Plebeian Market como aplicação de comércio nativa do Nostr, com a distinção de que foca em coordenação de troca fiat-Bitcoin. O daemon Mostro subjacente lida com correspondência de ordens e resolução de disputas através de relays Nostr.

Décima Sexta Onda de Grants Bitcoin da OpenSats

OpenSats anunciou grants a 17 projetos open-source. O destaque relevante ao Nostr: Minibits Wallet, a carteira Android Cashu com suporte a eventos de carteira NIP-60 e integração de nutzap, recebeu grant de renovação. Minibits usa eventos Nostr no armazenamento de estado de tokens ecash, tornando backups de carteira portáveis entre dispositivos através de sincronização via relay.

NostrPress: Perfil Nostr em Blog Estático

NostrPress (blog.besoeasy.com) é ferramenta nova que converte perfil Nostr em blog completamente estático implantável em qualquer lugar. Usuários publicam artigos no Nostr através de qualquer cliente, e o NostrPress gera site independente a partir desses eventos, completo com hospedagem local de mídia e feeds RSS.

Construído com templates Nunjucks e JavaScript, o NostrPress produz sites sem lock-in de plataforma. A saída gerada é HTML/CSS puro que pode ser hospedado em qualquer servidor de arquivos estáticos, GitHub Pages, Netlify ou VPS pessoal. A ferramenta se junta a Npub.pro e Servus como opções na conversão de conteúdo Nostr em sites tradicionais.

Antiprimal: Gateway Compatível com Padrões ao Cache do Primal

antiprimal (antiprimal.net), novo projeto de Alex Gleason e a equipe Soapbox, é gateway WebSocket que faz bridge do servidor de cache proprietário do Primal a mensagens padrão do protocolo Nostr. Primal oferece recursos como estatísticas de eventos, busca de conteúdo e cálculos de Web of Trust através de wss://cache.primal.net/v1, mas acessar estes requer formato de mensagem proprietário com campo cache não-padrão que aplicações Nostr padrão não conseguem usar. Antiprimal traduz requisições NIP padrão ao formato do Primal e converte as respostas de volta.

O gateway suporta consultas COUNT NIP-45 (reações, respostas, reposts, contagens de zap, contagens de seguidores), busca NIP-50, informações de relay NIP-11 e NIP-85 Trusted Assertions com dados pré-computados de Web of Trust do Primal. Bot complementar publica eventos NIP-85 kind 30382 (estatísticas de usuário) e kind 30383 (engajamento de eventos) em relays configuráveis. O projeto é construído com TypeScript no Bun e usa a biblioteca Nostrify. Criado em 6 de fevereiro, tem 53 commits nos primeiros três dias de desenvolvimento e está ao vivo em antiprimal.net.

Ikaros: Gateway de Mensagens de Agentes de IA com Signal e Nostr

Ikaros, novo projeto da equipe Soapbox, é gateway de mensagens que permite agentes de IA se comunicarem através de DMs criptografadas tanto do Signal quanto do Nostr. A bridge usa o Agent Client Protocol (ACP) na conexão de qualquer assistente de codificação IA compatível com ACP a redes de mensagens reais. Três pull requests constituem a construção inicial do projeto nesta semana.

O PR #1 implementa adaptador completo de DM criptografada NIP-04 com suporte a envio/recebimento, buffer de resposta com flush explícito na conclusão, formatos de chave privada nsec e hex, publicação multi-relay com reconexão automática e assistente de configuração interativo. O adaptador usa nostr-tools v2.23.0 e atualiza o ACP SDK a v0.14.1.

O PR #2 corrige descarte silencioso de mensagens causado por condição de corrida na atualização de sessão: notificações recebidas antes de registro no mapa eram silenciosamente perdidas, e a correção armazena essas notificações em buffer até que o registro seja concluído. O PR #3 adiciona metadados de nome/UUID de usuário e grupo do Signal nas interações com agentes, de modo que o agente de IA saiba com quem está falando e em qual grupo. O projeto abre novo espaço de design: agentes de IA endereçáveis via DMs Nostr que podem ser alcançados do Signal, ou vice-versa.

Campanha de Redução do Kind 0

vitorpamplona abriu série de PRs nesta semana propondo extração sistemática de dados de eventos kind 0 (metadados de usuário) em kinds de evento dedicados. A campanha aborda problema crescente: eventos kind 0 acumularam campos ao longo do tempo que a maioria dos aplicativos não usa, inflando o tamanho de cada busca de perfil.

O PR #2216 (mergeado) move tags de identidade (tags i) do kind 0 a novo kind 10011, já que a adoção dessas tags foi mínima. O PR #2213 propõe mover verificação NIP-05 ao kind 10008, o que permitiria que usuários tivessem múltiplos identificadores NIP-05 e possibilitaria filtrar eventos por endereço NIP-05. O PR #2217 propõe extrair endereços Lightning (lud06/lud16) em novo kind, impedindo que todos os usuários de kind 0 carreguem campos relacionados a zap que só importam em aplicações com integração Lightning.

As propostas reacenderam a discussão sobre a questão mais ampla da estrutura do kind 0, incluindo o PR #1770, a proposta de longa data que substitui JSON stringificado no conteúdo do kind 0 por tags estruturadas.

Suporte a NIP-70 em Relays é Crítico na Segurança de Mensagens Criptografadas

A implementação White Noise do protocolo Marmot identificou lacuna crítica no suporte de relays ao NIP-70 (Eventos Protegidos) e NIP-42 (Autenticação). Testes revelaram que relays públicos importantes incluindo Damus, Primal e nos.lol rejeitam eventos protegidos diretamente com erros blocked: event marked as protected em vez de iniciar o desafio de autenticação obrigatório.

Isso quebra recurso de segurança chave: NIP-70 permite exclusão segura de KeyPackages MLS gastos, prevenindo ataques “coletar agora, descriptografar depois”. Sem suporte de relay, protocolos de mensagens criptografadas não conseguem proteger usuários contra comprometimento futuro de chaves. White Noise desabilitou NIP-70 por padrão em resposta, mantendo flag opcional com relays compatíveis.

Chamado à ação de operadores de relay: Implementem o fluxo completo de autenticação NIP-42. Ao receber eventos protegidos, desafiem os remetentes a provar propriedade e então aceitem escritas validadas. Rejeitar eventos protegidos sem autenticação quebra garantias de segurança do protocolo das quais aplicações de mensagens criptografadas dependem.

Lançamentos

Coracle 0.6.29

Coracle (coracle.social), o cliente web de hodlbod, lançou 0.6.29. O lançamento adiciona exibição de tópicos e comentários em highlights kind 9802. Novo item de navegação de listas dá acesso rápido a listas curadas pelo usuário a partir da UI principal. Internamente, Coracle atualizou a nova versão do Welshman, a biblioteca Nostr compartilhada que alimenta o gerenciamento de relay e tratamento de eventos do Coracle. A lista padrão de relays foi atualizada, e o rastreamento de erros Glitchtip foi removido do codebase.

Igloo Desktop v1.0.3

Igloo Desktop, o assinador de limiar baseado em FROST e aplicação de gerenciamento de chaves, lançou v1.0.3 com extenso endurecimento de segurança. O lançamento introduz validação IPC, isolamento Electron e verificações de relay com proteção contra SSRF (server-side request forgery). Novo fluxo de onboarding e importação de shares simplifica a distribuição de chaves, o planejamento de relay agora inclui normalização e merge de prioridade, e arquitetura de API Electron baseada em preload melhora a barreira de segurança entre o renderer e o processo principal. Sistema de keep-alive do assinador mantém estabilidade de sessão de assinatura de limiar, e melhorias de UX de recuperação reduzem a fricção de restauração de chaves.

Amber v4.1.2-pre1

Amber, o assinador de eventos Android, lançou v4.1.2-pre1 corrigindo a exibição ausente de pontuação de confiança de relay introduzida na v4.1.1, resolvendo problemas de parsing JSON em requisições de encrypt/decrypt não-Nostr, e migrando o modelo de conta de LiveData a Flow com gerenciamento de estado mais previsível. O lançamento muda segredos do bunker a UUIDs completos e atualiza ao Gradle plugin 9.

Mostro Mobile v1.1.0 e Daemon v0.16.1

Veja a seção de Notícias acima com cobertura completa do lançamento mobile. No lado servidor, o daemon Mostro lançou v0.16.1, adicionando publicação automática de metadados NIP-01 kind 0 na inicialização (PR #575), de modo que o daemon agora anuncia sua identidade na rede quando fica online. A documentação de cálculo de taxas de desenvolvimento foi igualmente corrigida (PR #571).

Angor v0.2.5

Angor (angor.io), o protocolo descentralizado de financiamento P2P construído sobre Bitcoin e Nostr, lançou v0.2.5 com três PRs mergeados. O PR #649 redesenha a seção de gerenciamento de Fundos (V2), substituindo o layout anterior por nova interface que rastreia UTXOs individuais e posições de investimento. O PR #651 reformula o InvoiceView com estilos de botão atualizados, diálogos fecháveis, novo comando “Copiar Endereço”, suporte a cancelamento no monitoramento de endereço e tratamento melhorado de fluxo de investimento. O PR #652 adiciona servidores de imagem NIP-96 (spec) configuráveis nas configurações, permitindo que usuários escolham qual endpoint de upload de mídia lida com suas imagens de projeto e documentação. A versão v0.2.4 foi lançada na semana anterior.

Ridestr v0.2.2 e v0.2.3

Ridestr, a plataforma descentralizada de compartilhamento de caronas coberta na semana passada, continuou iteração rápida com v0.2.2 (Bridge Payment Hotfix) e v0.2.3 após o v0.2.0 “RoadFlare Release”. O hotfix v0.2.2 corrige bug onde pagamentos bridge Cashu cross-mint estavam auto-cancelando corridas enquanto o pagamento ainda estava processando ou eventualmente teria sucesso, prevenindo cancelamento prematuro de corridas em liquidações mais lentas. Corrige igualmente flickering de UI e hitboxes de toque quebradas no botão “minha localização”. A versão v0.2.3 entrega correções de bugs adicionais. Ambos os lançamentos incluem APKs separados, Ridestr (app do passageiro) e Drivestr (app do motorista).

Nostr PHP 1.9.4

Nostr PHP (nostr-php.dev), a biblioteca helper PHP do protocolo Nostr, lançou 1.9.4 adicionando propriedade timeout configurável à classe de requisição (PR #106). Isso permite que desenvolvedores definam durações de timeout personalizadas em conexões de relay e requisições de mensagem, prevenindo travamentos indefinidos quando relay não responde ou demora a responder.

Zapstore v1.0.0

Zapstore (zapstore.dev), a loja de apps Android sem permissão construída sobre Nostr, alcançou seu marco de lançamento estável 1.0 nesta semana após meses de release candidates.

O lançamento 1.0 inclui melhorias críticas de estabilidade: tratamento de estado do botão de instalação que garante que Excluir apareça imediatamente após a instalação ser concluída, mensagens de erro amigáveis com detalhes técnicos expansíveis, e botão “Reportar problema” que envia DMs criptografadas via Nostr usando chaves efêmeras. Entrega ainda nova tela de atualizações com polling e rastreamento em lote, melhor watchdog de download em transferências travadas, limites dinâmicos de downloads concorrentes baseados em desempenho do dispositivo, sincronização mais frequente de pacotes instalados e lógica de comparação de versão aprimorada. A equipe corrigiu problema crítico do flutter_secure_storage e melhorou o tratamento de casos extremos do gerenciador de pacotes.

O marco representa a maturação da primeira plataforma dedicada de distribuição de apps do Nostr, permitindo que desenvolvedores publiquem aplicações Android diretamente a usuários sem gatekeeping de loja de apps centralizada.

ZSP v0.3.1

ZSP, a ferramenta CLI Go da equipe Zapstore que substitui as ferramentas de publicação anteriores do Zapstore na assinatura e upload de apps Android a relays Nostr, lançou v0.3.1. ZSP lida com aquisição de APK do GitHub, GitLab, Codeberg, F-Droid ou arquivos locais, depois analisa metadados, assina eventos Nostr (via chave privada, bunker NIP-46 ou extensão de navegador NIP-07), e faz upload de artefatos a servidores Blossom. A versão adiciona modo offline completo na vinculação de keystore sem conexão de rede, headers Content-Digest em uploads Blossom em conformidade com o protocolo, detecção corrigida de APK arm64-v8a de repositórios F-Droid, correções de parâmetros trailing de query do GitLab, e suporte completo a arquivo .env na configuração.

Damus iOS 1.17

Damus, o cliente iOS Nostr, atualizou a versão 1.17 (PR #3606). O lançamento corrige problema no RelayPool onde conexões fechavam após liberação de lease efêmero (PR #3605), o que podia causar queda inesperada de subscrições. Resolve ainda bug onde a timeline de favoritos não exibia eventos ao alternar entre abas (PR #3603).

nak v0.18.3

nak, o canivete suíço Nostr CLI, lançou v0.18.3 com três correções de estabilidade: prevenindo panic quando tags de desafio AUTH são nil ou curtas demais, verificando erros de dateparser antes de usar o valor analisado, e lidando com URLs de mint Cashu que não possuem separador ://.

Mi: Relay Local no Navegador

Mi (mi.shakespeare.wtf), novo MiniApp do Shakespeare, é relay local no navegador que arquiva eventos Nostr do usuário em IndexedDB. Mi busca perfis (kind 0), listas de contatos (kind 3), listas de relay (kind 10002) e eventos de carteira de relays conectados e os armazena localmente, dando aos usuários acesso offline aos seus próprios dados. Construído com React e nostr-tools 2.15.0.

Agora v1.0.2

Agora (agora.spot), plataforma descentralizada de ativismo e arrecadação de fundos da equipe Soapbox, lançou v1.0.2 com APK Android disponível em instalação direta. Esta é a primeira menção do Agora no Compass, que foi lançado em 17 de janeiro com declaração de missão: “Junte-se ao movimento global pela liberdade. Envie apoio a ativistas no campo internacionalmente e participe de ações locais.”

A plataforma é centrada em mapa-múndi onde usuários navegam por país, criam “ações” geolocalizadas (protestos, campanhas, organização comunitária) e as discutem através de comentários em thread. Todo o conteúdo se propaga através de relays Nostr, de modo que nenhum servidor central pode ser derrubado ao silenciar a coordenação. Agora suporta múltiplos idiomas com paridade de tradução obrigatória via CI, integra servidores de mídia Blossom em uploads, e inclui busca, navegação por hashtag com alternância global/regional, perfis de usuário e sistemas de reação. O lançamento v1.0.2 é a build Android atual, disponível como download direto de APK.

xonos v0.1.6

xonos, o cliente Nostr 3D experimental construído com o motor de jogo Bevy, lançou v0.1.6. xonos renderiza eventos Nostr em ambiente espacial 3D com capacidades de text-to-speech, explorando como dados de protocolos sociais podem funcionar fora de interfaces 2D convencionais.

Atualizações de Projetos

Primal Android Expande Infraestrutura NWC

Primal Android fez merge de 18 PRs nesta semana, continuando a construção NWC iniciada na semana passada. O PR #883 adiciona suporte a conexões NWC em ambas as carteiras (Spark e externa), e o PR #879 implementa o método NWC lookup_invoice na verificação de status de pagamento.

O PR #880 adiciona logging de auditoria de requisição-resposta NWC na depuração de interações de carteira. O PR #877 traz suporte multi-conta ao PrimalNwcService, permitindo que usuários com múltiplos perfis mantenham conexões de carteira separadas. O PR #882 implementa limpeza periódica de reservas de orçamento expiradas, prevenindo que reservas de pagamento obsoletas bloqueiem operações de carteira.

Trabalho de UI inclui redesign de tela de upgrade de carteira (PR #889), FAQ de upgrade de carteira (PR #885), configuração de endereço Lightning durante onboarding (PR #888) e correção de transações de zap aparecendo como pagamentos regulares em tipos não-Lightning (PR #887).

diVine Entrega Feeds de Vídeo API-First

diVine, o cliente de vídeos curtos, fez merge de 19 PRs nesta semana, movendo a arquitetura API-first. O PR #1468 introduz feeds de vídeo API-first, e o PR #1466 adiciona endpoints de API de trending, recentes e home. O PR #1433 indexa controladores de vídeo específicos na renderização eficiente de feeds.

Tratamento de perfil melhorou com o PR #1440 implementando padrão cache-plus-fresh na visualização de outros perfis, reduzindo tempos de carregamento enquanto garante atualização dos dados. A equipe entregou correções de notificação (PR #1437), refatoração de fluxo de comentários (PR #1431) e swipe de abas na tela de Notificações (PR #1388).

White Noise: Unificação de Keyring e Busca de Usuário

O backend White Noise do protocolo Marmot fez merge de 4 PRs nesta semana. Dois PRs melhoraram tratamento de keyring: o PR #468 torna o identificador de serviço de keyring configurável via WhitenoiseConfig, e o PR #475 unifica a implementação em crate única keyring-core com stores nativos de plataforma, substituindo código fragmentado específico de plataforma. Separadamente, o PR #470 adiciona funcionalidade de busca de usuário.

Marmot TS Extrai App de Chat de Referência

O SDK TypeScript do Marmot (marmot-ts) fez merge do PR #40, removendo a aplicação de chat de referência embutida e separando-a em repositório independente: marmots-web-chat. O novo repositório, criado em 6 de fevereiro, é implementação de referência do SDK TypeScript do Marmot com seu próprio pipeline de CI, visualização de chat com abas e sistema de build independente. A separação permite que o SDK foque em questões de biblioteca enquanto o app de chat itera em UX independentemente.

PR aberto (#41) migra o marmot-ts a ts-mls v2.0.0, trazendo API redesenhada com objetos de contexto unificados, novos utilitários de tratamento de mensagem (criação de evento, leitura, desserialização), helpers de metadados de key package e suporte a eventos de exclusão.

Atualizações do Alby Hub

Alby Hub fez merge de 5 PRs nesta semana. O PR #2049 adiciona CLI Alby à interface da loja de apps. O PR #2033 corrige tratamento de dados de zap inválidos na lista de transações, e o PR #2046 remove o método ListTransactions não utilizado da interface LNClient.

Notedeck Entrega Dashboard e Agentium

Notedeck, o cliente Nostr cross-platform da Damus, fez merge de 6 PRs nesta semana. O PR #1247 adiciona app de dashboard inicial. O PR #1293 introduz Agentium, ambiente de desenvolvimento multi-agente que transforma o assistente de IA Dave em sistema com modos de IA duais e gerenciamento de agentes baseado em cenas. O PR #1276 adiciona compositor de mensagem multilinha com keybindings estilo Signal, e o PR #1278 entrega melhorias de desempenho de mídia. PRs abertos de destaque incluem infraestrutura outbox e planejamento de Git App NIP-34.

Agora Entrega Grande Reformulação de UI

Agora fez merge de 7 PRs nesta semana junto com seu lançamento v1.0.2. O PR #106 é o maior, fechando 11 tarefas de UI em configurações, edição de perfil, interações de mapa, resultados de busca, filtragem de comentários e gerenciamento de servidor Blossom. O merge desabilitou botões de reação de usuários não autenticados (que antes recebiam falhas silenciosas ao tentar reagir a posts no mapa), corrigiu panning de mapa na date-line e adicionou texto em negrito nos resultados de busca.

O PR #108 adiciona contagem de comentários sob posts de feed e em páginas de thread. O PR #107 traz retry automático em falhas de carregamento de eventos com botão de reload explícito quando retries se esgotam. O PR #104 muda navegação de hashtag ao escopo global por padrão, já que o escopo anterior por país frequentemente retornava zero resultados.

O PR #109 adiciona etapa de CI que verifica paridade de tradução em todos os idiomas, falhando a build se qualquer chave estiver sem valor. O PR #110 recorta notas grandes em feeds ao preservar ritmo de scroll, e o PR #111 corrige problema de zoom em iOS mobile ao comentar em ações causado por tamanhos de fonte pequenos.

Clawstr Entrega CLI e Botões de Lightning Zap

Clawstr, a plataforma inspirada no Reddit onde agentes de IA criam e gerenciam comunidades no Nostr, fez merge de 3 PRs nesta semana. O PR #11 substitui todos os comandos nak manuais nas definições de habilidades do agente de IA pelo novo pacote @clawstr/cli (npx -y @clawstr/cli@latest), removendo construção manual de eventos JSON em favor de comandos CLI e adicionando operações de carteira (init, balance, zap, npc) e busca de texto completo NIP-50.

O PR #13 adiciona página de documentação “For Humans” e componente ProfileZapDialog. O botão de zap aparece em páginas de perfil quando usuário tem endereço Lightning configurado e funciona sem login, usando LNURL-pay diretamente com valores pré-definidos de sats e exibição de QR code. O PR #12 documenta o comando wallet sync, explicando como pagamentos em endereços Lightning são retidos pelo NPC até que agentes explicitamente sincronizem suas carteiras.

Atualizações de NIPs

Mudanças recentes no repositório de NIPs:

Mergeado:

NIP-45: Resposta HyperLogLog de Relay - NIP-45 (Contagem de Eventos) agora suporta contagem aproximada HyperLogLog (HLL). Relays podem retornar valores de registros HLL de 256 bytes junto com respostas COUNT. Ao fazer merge desses registros de múltiplos relays, aplicações computam cardinalidade aproximada sem baixar conjuntos completos de eventos. O caso de uso principal são contagens de seguidores e reações sem depender de relay único como fonte autoritativa. Até dois eventos de reação consomem mais largura de banda que o payload HLL de 256 bytes. Aplicações podem aplicar correções HyperLogLog++ em cardinalidades pequenas.
NIP-39: Tags de Identidade Movidas do Kind 0 - As tags de claim de identidade NIP-39 (tags i) foram extraídas de eventos de metadados kind 0 a novo kind 10011 dedicado. A razão: quase nenhum cliente suporta essas tags, que adicionam tamanho a cada busca de kind 0 sem fornecer valor. Primeiro de série de PRs de extração do kind 0 de vitorpamplona (veja seção de Notícias).

PRs Abertos e Discussões:

NIP-XX: Nostr Relay Connect (NRC) - woikos propõe protocolo de acesso a relays Nostr através de tunelamento criptografado via relay rendezvous público. O mecanismo permite acesso a relays atrás de NAT ou firewalls, incluindo relays pessoais rodando em servidores domésticos ou dispositivos móveis. O tunelamento usa eventos kind 24891/24892 com criptografia NIP-44 através de relay rendezvous que não pode descriptografar o tráfego. Aplicação prática: qualquer cliente Nostr pode expor armazenamento local (IndexedDB, SQLite) como endpoint de relay na sincronização entre dispositivos. Semânticas padrão NIP-01 (REQ, EVENT, CLOSE, COUNT) passam pelo túnel de forma transparente. Existem referências em Go (ORLY Relay) e TypeScript (Smesh).
Nostr Web Tokens (NWT) - pippellia-btc propõe Nostr Web Tokens, formato de evento Nostr que transmite claims assinados entre partes web, inspirado em JSON Web Tokens (JWTs). NWT pode representar tanto NIP-98 (HTTP Auth) quanto eventos de autorização Blossom, dando flexibilidade em como e por quanto tempo tokens permanecem válidos. Biblioteca de referência em Go está disponível. Explicação em vídeo e comparação detalhada com NIP-98 e Blossom Auth estão linkadas no PR.
Simplificação do NIP-47 - rolznz propõe remover os métodos multi_ do NIP-47 (Nostr Wallet Connect), que eram complexos de implementar e não ganharam adoção. O PR reduz duplicação em tratamento de criptografia e compatibilidade retroativa, limpando a spec após a adição de hold invoice da semana passada.
NIP-05: Mover ao Kind de Evento Próprio - vitorpamplona propõe mover verificação NIP-05 do kind 0 ao novo kind 10008, permitindo múltiplos identificadores NIP-05 por usuário e filtragem por endereço NIP-05. Parte da campanha de redução do kind 0.
NIP-57: Endereços Lightning do Kind 0 - vitorpamplona propõe extrair lud06/lud16 (endereços Lightning) do kind 0 em kind de evento dedicado conforme NIP-57, continuando o esforço de redução do kind 0.
Hiperpersonalização de Perfil - fiatjaf propõe capacidades estendidas de personalização de perfil além do que o kind 0 atualmente suporta.

Deep Dive de NIP: NIP-45 (Contagem de Eventos) e HyperLogLog

NIP-45 (spec) define como aplicações podem pedir a relays a contagem de eventos que correspondem a filtro sem transferir os eventos em si. O merge do suporte a HyperLogLog nesta semana adiciona estrutura de dados probabilística que resolve problema fundamental: como contar coisas em múltiplos relays independentes.

O Problema:

Contar eventos em relay único é simples: envie requisição COUNT, receba número de volta. Contar pela rede é mais difícil. Se o relay A reporta 50 reações e o relay B reporta 40, o total não é 90 porque muitos eventos existem em ambos os relays. Baixar todos os eventos e deduplicar seria a alternativa, mas aplicações não conseguem fazer isso em escala.

HyperLogLog:

HyperLogLog (HLL) é algoritmo probabilístico que estima o número de elementos distintos em conjunto usando quantidade fixa de memória. A versão do NIP-45 usa 256 registros de um byte cada, consumindo exatamente 256 bytes independente de quantos eventos são contados. O algoritmo funciona examinando a representação binária de cada ID de evento e rastreando a posição dos zeros iniciais. Eventos cujos IDs começam com muitos zeros são estatisticamente raros, e sua ocorrência indica conjunto grande.

Como Funciona no NIP-45:

Relay respondendo a requisição COUNT pode incluir campo hll contendo valores de registro codificados em base64:

["COUNT", "<subscription_id>", {"count": 4527, "hll": "<base64 encoded 256 bytes>"}]

A aplicação coleta valores HLL de múltiplos relays e faz merge deles tomando o valor máximo em cada posição de registro. O HLL mergeado representa a união de todos os conjuntos de eventos entre relays, tratando deduplicação automaticamente. A estimativa final de cardinalidade é computada a partir dos registros mergeados.

Precisão:

Com 256 registros, o erro padrão é aproximadamente 5,2%. Contagem verdadeira de 1.000 tipicamente produz estimativa entre 948 e 1.052. Em contagens maiores, o erro relativo permanece constante: contagem verdadeira de 100.000 será estimada em aproximadamente 94.800-105.200. Correções HyperLogLog++ melhoram a precisão em cardinalidades pequenas (abaixo de ~200), onde o algoritmo básico tende a superestimar.

Por Que Importa:

Métricas sociais (contagens de seguidores, reações, reposts) são recurso central de aplicações de mídia social. A alternativa ao HLL é consultar relay único “confiável” (centralizando a contagem) ou baixar todos os eventos de todos os relays (desperdiçando largura de banda). HLL permite obter boa contagem aproximada de múltiplos relays com overhead total de 256 bytes por relay, independente da contagem real. Até dois eventos de reação consomem mais largura de banda que payload HLL completo.

A spec fixa o número de registros em 256 por interoperabilidade. Todos os relays produzem valores HLL que podem ser mergeados, independente de qual software de relay executam. Essa padronização permite que aplicações implementem suporte HLL uma vez e se beneficiem de cada relay que o suporta.

Status Atual:

O PR foi aberto por fiatjaf e esteve em discussão por vários meses antes de ser mergeado nesta semana. Relays precisarão adicionar computação HLL aos seus handlers COUNT. Aplicações precisarão adicionar merge HLL à sua lógica de agregação de contagem.

Deep Dive de NIP: NIP-96 (Armazenamento de Arquivos HTTP) e a Transição ao Blossom

NIP-96 (spec) definiu como aplicações Nostr fazem upload, download e gerenciam arquivos em servidores de mídia HTTP. Agora marcado como “não recomendado” em favor do Blossom (hospedagem de mídia baseada em BUD), o NIP-96 permanece relevante nesta semana porque Angor v0.2.5 adicionou configuração de servidor NIP-96 e ZSP v0.3.1 faz upload a servidores Blossom, ilustrando transição de protocolo em andamento.

Como o NIP-96 Funciona:

A aplicação descobre as capacidades de servidor de arquivos buscando /.well-known/nostr/nip96.json, que retorna a URL da API, tipos de conteúdo suportados, limites de tamanho e transformações de mídia disponíveis:

{
 "api_url": "https://file-server.example/api",
 "download_url": "https://cdn.example/files",
 "content_types": ["image/jpeg", "video/webm", "audio/*"],
 "plans": {
 "free": {
 "is_nip98_required": true,
 "max_byte_size": 10485760,
 "media_transformations": {
 "image": ["resizing"]
 }
 }
 }
}

O upload consiste em POST multipart/form-data à URL da API com header de autorização NIP-98 (evento Nostr assinado provando a identidade de quem faz o upload). O servidor retorna estrutura de metadados de arquivo NIP-94 contendo a URL do arquivo, hashes SHA-256 originais e transformados, tipo MIME e dimensões:

{
 "status": "success",
 "nip94_event": {
 "tags": [
 ["url", "https://cdn.example/files/<hash>.png"],
 ["ox", "<original-file-hash>"],
 ["x", "<transformed-file-hash>"],
 ["m", "image/png"],
 ["dim", "800x600"]
 ]
 }
}

Downloads usam requisições GET a <api_url>/<sha256-hash>, com parâmetros de query opcionais em transformações do lado do servidor como redimensionamento de imagem. Exclusão usa DELETE com auth NIP-98, e somente quem fez o upload original pode excluir seus arquivos. Endpoint de listagem de arquivos retorna resultados paginados dos uploads de dado usuário.

Usuários publicam eventos kind 10096 declarando seus servidores de upload preferidos, permitindo que aplicações selecionem automaticamente o servidor correto sem configuração manual.

Por Que Foi Depreciado:

NIP-96 vinculava URLs de arquivo a servidores específicos. Se files.example.com caísse, toda nota Nostr referenciando as URLs daquele servidor perdia sua mídia. O servidor era o endereço, e o endereço era frágil.

Blossom (Blobs Stored Simply on Mediaservers) inverte isso tornando o hash SHA-256 do conteúdo do arquivo o identificador canônico. URL Blossom se parece com https://blossom.example/<sha256>.png, mas qualquer servidor Blossom hospedando o mesmo arquivo o serve no mesmo caminho de hash. Se servidor desaparece, a aplicação consulta outro servidor pelo mesmo hash. Endereçamento por conteúdo torna os dados portáveis entre servidores por padrão.

Blossom simplifica a API. NIP-96 usava uploads multipart form com respostas JSON, políticas de transformação e endpoint de descoberta. Blossom usa PUT simples em uploads, GET em downloads e eventos Nostr assinados (não headers HTTP) na autorização. A especificação do Blossom é dividida em documentos modulares: BUD-01 cobre protocolo de servidor, autorização e recuperação, BUD-02 cobre upload de blob, BUD-03 cobre servidores de usuários, e BUD-04 cobre espelhamento entre servidores.

A depreciação aconteceu em setembro de 2025 via PR #2047, que marcou NIP-96 como “não recomendado” no índice de NIPs.

A Transição na Prática:

Servidores como nostr.build e void.cat suportavam NIP-96 e adicionaram ou migraram a endpoints Blossom. As aplicações estão em vários estágios: o lançamento v0.2.5 do Angor adicionou configuração de servidor NIP-96 em imagens de projeto, enquanto o lançamento v0.3.1 do ZSP faz upload de artefatos exclusivamente a servidores Blossom com headers Content-Digest em conformidade com o protocolo. Amethyst e Primal suportam uploads Blossom. A coexistência provavelmente continuará até que os softwares NIP-96 restantes completem sua migração.

O Que Permanece:

Eventos de preferência de servidor kind 10096 continuam úteis na seleção de servidor Blossom. Metadados de arquivo NIP-94 (eventos kind 1063) ainda descrevem propriedades de arquivo independente de qual protocolo de upload os criou. O hashing SHA-256 que NIP-96 usava em URLs de download se tornou a base do endereçamento por conteúdo do Blossom. O design do NIP-96 informou o que o Blossom simplificou: a lição foi que hospedagem de mídia em rede descentralizada requer armazenamento endereçado por conteúdo ao nível da resistência à censura da camada de relay.

É isso por esta semana. Compartilhe notícias, sugira cobertura de projeto ou envie feedback via DM NIP-17, ou nos encontre no Nostr.

Nostr Compass #8

Wed, 04 Feb 2026 00:00:00 +0000

Bem-vindo de volta ao Nostr Compass, seu guia semanal sobre o Nostr.

Esta semana: rust-nostr entrega um grande redesign de API com 21 PRs reformulando a arquitetura do SDK. Nostria 3.0 lança com navegação em painel duplo, gerenciamento de listas e uma reformulação completa da UI. Vector adiciona aceleração SIMD alcançando speedups de 65x-184x e entrega suporte ao protocolo Marmot para mensagens de grupo criptografadas. Frostr traz assinatura de limiar para iOS via TestFlight. Damus implementa dicas de relay NIP-19 (Entidades Codificadas em Bech32) para descoberta de conteúdo cross-relay. Primal Android adiciona criptografia NWC e exportações de transações de carteira. nostr-tools e NDK recebem melhorias de confiabilidade. NIP-82 (Aplicações de Software) expande para cobrir 98% das plataformas de dispositivos. O repositório de NIPs faz merge de suporte a hold invoice para NIP-47 (Nostr Wallet Connect). Novas propostas de protocolo incluem NIP-74 para podcasting, NIP-DB para bancos de dados de eventos em navegador, e uma suíte TRUSTed Filters para curadoria descentralizada de conteúdo. Novos projetos incluem Instagram to Nostr v2 para migração de conteúdo, Pod21 lançando um marketplace descentralizado de impressão 3D, Clawstr introduzindo comunidades gerenciadas por agentes de IA, e Shosho e NosCall expandindo capacidades de streaming ao vivo e chamadas de vídeo.

Notícias

rust-nostr Entrega Grande Redesign de API

O SDK rust-nostr passou por uma reformulação arquitetural significativa esta semana com 21 PRs mergeados introduzindo breaking changes em toda a biblioteca. O redesign afeta APIs centrais das quais a maioria dos desenvolvedores Rust depende.

PR #1245 redesenha APIs de notificação, enquanto PR #1244 substitui RelayNotification::Shutdown por RelayStatus::Shutdown para tratamento de estado mais limpo. As APIs de signer agora se alinham com outros padrões do SDK via PR #1243. Métodos de Client e Relay receberam limpeza em PR #1242, e opções de cliente agora usam um padrão builder (PR #1241).

APIs de envio de mensagens foram redesenhadas em PR #1240, cancelamento de subscrição REQ em PR #1239, e remoção de relay em PR #1229. Um PR aberto #1246 adiciona suporte para APIs bloqueantes para completar o redesign.

As mudanças trazem consistência ao SDK mas exigirão esforço de migração de projetos existentes. Desenvolvedores construindo sobre rust-nostr devem revisar o changelog cuidadosamente antes de atualizar.

Instagram to Nostr v2 Permite Migração de Conteúdo

Uma nova ferramenta permite que criadores migrem seu conteúdo existente de plataformas centralizadas para o Nostr. Instagram to Nostr v2 suporta importação do Instagram, TikTok, Twitter e Substack sem exigir acesso às chaves privadas do usuário.

A ferramenta aborda uma barreira comum de onboarding: usuários hesitantes em começar do zero em uma nova plataforma podem agora preservar seu histórico de conteúdo. Ela também suporta presentear contas Nostr para novos usuários ou propor conteúdo para contas existentes, tornando-a útil para ajudar outros na transição para o protocolo.

Pod21: Rede Descentralizada de Impressão 3D

Pod21 (pod21.com) conecta operadores de impressoras 3D com compradores usando Nostr para coordenação de marketplace. A plataforma inclui um bot de DM compatível com NIP-17 (Mensagens Diretas Privadas) que lida com interações de marketplace, permitindo que compradores solicitem impressões e negociem com makers através de mensagens diretas criptografadas.

Makers listam sua capacidade e recursos de impressão; compradores navegam nas listagens e iniciam pedidos via o bot. A arquitetura segue um padrão similar a outras aplicações de comércio Nostr: descoberta baseada em relay, mensagens criptografadas para coordenação de pedidos, e Lightning para liquidação. Pod21 se junta a Ridestr e Shopstr como aplicações Nostr coordenando transações do mundo real através do protocolo.

Clawstr lança como uma plataforma inspirada no Reddit onde agentes de IA criam e gerenciam comunidades no Nostr. A plataforma permite que agentes autônomos estabeleçam comunidades temáticas, curem conteúdo e interajam com usuários. Comunidades funcionam como subreddits mas com moderadores e curadores de IA guiando discussões. A arquitetura usa o protocolo aberto do Nostr para interações agente-para-agente e agente-para-humano, estabelecendo um novo modelo para formação de comunidades em mídias sociais descentralizadas.

Lançamentos

Ridestr v0.2.0: RoadFlare Release

Ridestr entregou v0.2.0, apelidada de “RoadFlare Release”, introduzindo redes pessoais de compartilhamento de caronas. O recurso permite que passageiros adicionem motoristas favoritos a uma rede de confiança. Motoristas aprovam seguidores e compartilham localizações criptografadas, permitindo que passageiros vejam quando motoristas de confiança estão online e próximos. Solicitações de corrida vão diretamente para motoristas conhecidos.

A confiabilidade de pagamento melhorou com recuperação automática de escrow, melhor sincronização de carteira entre dispositivos, e processamento de pagamento mais rápido via polling progressivo. PR #37 adiciona a infraestrutura da Fase 5-6 suportando esses recursos. v0.2.1 seguiu com hotfixes para bugs de diálogo de pagamento e o fluxo de “Adicionar aos Favoritos” pós-corrida.

Nostria 3.0

Nostria, o cliente cross-platform de sondreb construído para escala global, entregou a versão 3.0 com uma reformulação completa da UI, novo logo e centenas de correções. O lançamento representa um ciclo de desenvolvimento intensivo de seis semanas.

Navegação em painel duplo é a maior mudança de UX, permitindo que usuários desktop reduzam troca de contexto ao navegar entre listas, detalhes e threads. Uma nova seção Home fornece uma visão geral de todos os recursos disponíveis, e todas as telas compartilham uma barra de ferramentas, layout e funcionalidade unificados.

Gerenciamento de listas é a atualização de recurso mais significativa, integrando-se em toda a aplicação. Usuários podem gerenciar listas de perfis e filtrar conteúdo em qualquer recurso: Streams, Music ou Feeds. Cansado de spam em threads? Filtre por favoritos para ver apenas suas respostas. Quick Zaps adiciona zapping com um toque com valores configuráveis. Copy/Screenshot gera screenshots para a área de transferência para compartilhar eventos em qualquer lugar. Muted Words agora filtra em campos de perfil (name, display_name, NIP-05), permitindo que usuários bloqueiem todos os perfis bridgeados com uma única palavra banida. Configurações se tornaram pesquisáveis para mudanças de configuração mais rápidas.

O lançamento adiciona renderização de solicitações de pagamento BOLT11 e BOLT12, seleção de tamanho de texto e fonte, e mensagens “Nota para Si Mesmo” na seção de Mensagens com renderização de conteúdo referenciado como artigos e eventos. O novo diálogo de Compartilhar permite compartilhamento rápido via email, websites ou mensagens diretas para múltiplos destinatários. Recursos adicionais incluem conjuntos de emoji personalizados, Interests (listas de hashtags como feeds dinâmicos), Bookmarks, Public Relay Feeds e personalização completa de menu incluindo qual opção o ícone do Nostria abre.

Disponível no Android, iOS, Windows e web em nostria.app.

Applesauce v5.1.0

A suíte de bibliotecas Applesauce de hzrd149 lançou v5.1.0 em todos os pacotes. applesauce-signers adiciona suporte para métodos switch_relays e ping em remote signers Nostr Connect, útil para gerenciar conexões de signer programaticamente. applesauce-loaders introduz loadAsyncMap para carregamento async paralelo. applesauce-react adiciona argumentos de padding para useAction().run(). applesauce-core atualiza mapeamento de evento para store para lidar com strings diretamente sem exigir onlyEvents.

nak v0.18.3

nak (Nostr Army Knife) de fiatjaf alcançou v0.18.3 com correções de estabilidade de mattn. O lançamento previne panics quando URLs de mint carecem do separador ://, valida erros de dateparser antes de usar valores de data e lida com casos extremos em parsing de tags de desafio AUTH. Essas correções defensivas tornam o CLI mais resiliente ao processar inputs malformados.

Aegis v0.3.7

Aegis, o signer desktop cross-platform, entregou v0.3.7 adicionando suporte a Nostr App Browser com assinatura NIP-07 (Interface de Extensão de Navegador). O lançamento registra eventos de criptografia NIP-04 (Mensagens Diretas Criptografadas) e NIP-44 (Criptografia Versionada), permitindo que usuários rastreiem quais aplicações solicitam operações de criptografia. O segmento de navegador agora filtra por plataforma para mostrar apenas web apps.

Bitchat v1.5.1 (iOS)

Bitchat, o aplicativo de mensagens com capacidade offline usando Nostr e mesh Bluetooth, lançou v1.5.1 com endurecimento de segurança iOS. PR #1012 valida assinaturas de evento Nostr antes do processamento, rejeita giftwraps e pacotes incorporados inválidos, limita payloads superdimensionados e bloqueia IDs de remetente de anúncio BLE falsificados. PR #998 corrige autenticação de mesh BLE iOS vinculando IDs de remetente a UUIDs de conexão, prevenindo spoofing de identidade na rede mesh. PR #972 adiciona limitação de taxa de notificação para prevenir floods de descoberta de peer quando múltiplos dispositivos mesh estão próximos.

KeyChat v1.39.2

KeyChat lançou v1.39.2 adicionando suporte NIP-47 Nostr Wallet Connect via PR #148. Usuários agora podem conectar carteiras Lightning externas para pagamentos dentro do aplicativo de mensagens. O lançamento também adiciona notificações desktop macOS.

Nostrmo v3.5.0

Nostrmo, o cliente Flutter cross-platform, entregou v3.5.0 reformulando seu sistema de feed. A atualização substitui feeds fixos por alternativas personalizáveis: General Feed, Mentioned Feed e Relay Feed, cada um configurável através de novas páginas de edição. O lançamento implementa suporte ao modelo outbox para melhor roteamento de eventos e expande funcionalidade de relay local com limites de tamanho configuráveis e suporte a subscrição.

Shosho v0.11.1

Shosho, o aplicativo de streaming ao vivo para Nostr, lançou v0.11.1 com capacidades de gravação e VOD. A atualização adiciona indicadores de presença de sala mostrando quem está assistindo streams, conversas de chat com threads para melhor organização de discussão, e suporte Nostr Connect no iOS via NIP-46. Streamers agora podem salvar suas transmissões para visualização posterior enquanto mantêm interações de chat em tempo real com sua audiência.

NosCall v0.5.0

NosCall, o aplicativo de chamadas de áudio e vídeo para Nostr, entregou v0.5.0 com grupos de contato para organizar chamadas por categoria, gerenciamento de relay para otimização de conexão, e configurações de servidor ICE configuráveis para melhor traversal de NAT. O lançamento também adiciona suporte a modo escuro. NosCall usa Nostr para sinalização e coordenação de chamadas, permitindo chamadas peer-to-peer sem servidores centralizados.

diVine 1.0.4

diVine, o cliente de vídeos curtos em loop de rabble, lançou 1.0.4 como um alpha pré-lançamento Android antes de sua submissão na Zapstore. O lançamento foca em testar gerenciamento de chave Nostr, incluindo importação de nsec, assinatura remota NIP-46 (Nostr Connect) com nsecBunker e Amber, e tratamento de URL nostrconnect://. A equipe está solicitando feedback sobre compatibilidade de relay e interoperabilidade de vídeo com outros clientes. PR #1265 corrige tratamento de caminho de arquivo iOS que causava clipes de vídeo se tornarem inutilizáveis após atualizações do app armazenando caminhos relativos em vez de caminhos de container absolutos. PR #1251 corrige problemas de navegação ao visualizar perfis de comentários.

Zeus v0.12.2

Zeus entregou v0.12.2 como um lançamento estável, consolidando as correções NWC cobertas em edições anteriores.

Frostr Igloo iOS TestFlight

Frostr (frostr.org) lançou Igloo para iOS no TestFlight, expandindo assinatura de limiar para dispositivos Apple. Frostr usa assinaturas FROST (Flexible Round-Optimized Schnorr Threshold) para dividir chaves nsec em shares distribuídos entre dispositivos, permitindo assinatura k-de-n com tolerância a falhas. Usuários entrando em “modo demo” participam de um experimento de assinatura de limiar 2-de-2 ao vivo, demonstrando as capacidades de coordenação em tempo real do protocolo. O lançamento iOS se junta ao Igloo para Android (v0.1.2), que foi entregue em dezembro com suporte NIP-55 (Android Signer) para solicitações de assinatura cross-app. Ambos os clientes móveis complementam o Igloo desktop e a extensão de navegador Frost2x.

Atualizações de Projetos

Damus Implementa Dicas de Relay NIP-19

Damus fez merge do PR #3477, implementando consumo de dicas de relay NIP-19 para busca de eventos. O recurso permite visualizar notas em relays não presentes no pool configurado do usuário extraindo dicas de referências NIP-10 (Reply Threads), NIP-18 (Reposts) e NIP-19. A implementação usa conexões de relay efêmeras com limpeza por contagem de referência, evitando expansão permanente do pool de relay.

Correções adicionais incluem parsing de Lightning invoice (PR #3566), carregamento de visualização de carteira (PR #3554), timing de lista de relay (PR #3553), e preloading de perfil para reduzir “popping” visual (PR #3550). Um draft PR #3590 mostra suporte a DM privado NIP-17 em progresso.

Primal Android Entrega Criptografia NWC

Primal Android teve uma semana muito ativa com 18 PRs mergeados focados em infraestrutura de carteira. O app agora se integra com Spark, o protocolo Lightning auto-custodial da Lightspark. PR #874 adiciona suporte a criptografia NWC, enquanto PR #872 envia eventos de info NWC quando conexões são estabelecidas.

PR #870 permite exportação CSV para transações de carteira, útil para contabilidade e propósitos fiscais. PR #716 adiciona um alternador de conta local no Editor de Notas. Múltiplas correções de restauração de carteira (PR #876, PR #875, PR #873) abordam casos extremos para usuários com configurações de carteira não-Spark.

SDK TypeScript Marmot Adiciona Histórico de Mensagens

A implementação TypeScript do protocolo Marmot continua em desenvolvimento. PR #38 por hzrd149 implementa persistência de histórico de mensagens com paginação para a aplicação de chat de referência, enquanto PR #39 melhora a ergonomia da biblioteca.

No lado Rust, PR #161 implementa tratamento de estado com retry para preservar contexto de mensagem em falhas, e PR #164 muda para std::sync::Mutex para evitar panics do tokio com SQLite. O backend whitenoise-rs adiciona integração Amber (PR #418), atualiza para MDK e nostr-sdk 0.44 (PR #467), e introduz streaming de notificação em tempo real via PR #460 com tipos de evento NewMessage e GroupInvite.

HAVEN Adiciona Atualização Periódica de WoT

HAVEN, o relay pessoal, fez merge do PR #108 adicionando atualização periódica de Web of Trust. O recurso garante que pontuações de confiança permaneçam atualizadas conforme os grafos sociais dos usuários evoluem, melhorando a precisão da filtragem de spam ao longo do tempo.

nostr-tools

nostr-tools, a biblioteca JavaScript principal, recebeu múltiplas melhorias esta semana. Commits incluem uma correção para parsing de hashtag após quebras de linha em menções NIP-27 (Referências em Notas de Texto), poda automática de objetos de relay quebrados com rastreamento de inatividade para limpeza de conexão, remoção de fila de mensagens para otimização de desempenho single-threaded, e exportações de arquivos fonte para melhores imports TypeScript.

NDK

NDK entregou beta.71 com uma correção para reconexão após ciclos de sleep/wake do dispositivo e tratamento de conexão obsoleta, abordando problemas de confiabilidade para aplicações móveis.

Notedeck

Notedeck, o cliente desktop da equipe Damus, tem um PR aberto #1279 adicionando um visualizador NIP-34 (Colaboração Git). Isso permitiria navegar repositórios git, patches e issues publicados em relays Nostr diretamente dentro do cliente, tornando Notedeck um potencial front-end para fluxos de trabalho baseados em ngit.

njump

njump, o gateway web Nostr, adicionou suporte para dois tipos de evento NIP-51 (Listas) via PR #152. O gateway agora renderiza kind:30000 Follow Sets, que são agrupamentos categorizados de usuários que clientes podem exibir em diferentes contextos, e kind:39089 Starter Packs, que são coleções de perfis curadas projetadas para compartilhamento e seguimento em grupo. Essas adições permitem que njump exiba listas curadas pela comunidade quando usuários compartilham links nevent.

Amethyst

Amethyst, o cliente Android, corrigiu um bug prevenindo compartilhamento de vídeo da visualização do player (PR #1695). A opção “Compartilhar vídeo” estava falhando em aparecer porque o parâmetro de conteúdo não estava sendo passado para o componente de botões de controle. Usuários agora podem compartilhar conteúdo de vídeo Nostr para outros apps diretamente do player. PR #1693 corrige crashes de desserialização Jackson JSON que ocorriam ao analisar certos eventos malformados.

Jumble

Jumble, o cliente web focado em navegação de feed de relay, adicionou uploads de arquivo de áudio via clipboard em PR #743. Usuários agora podem colar arquivos de áudio diretamente no editor de post, que faz upload para servidores de mídia configurados e incorpora a URL na nota. O recurso espelha a funcionalidade de colar imagem existente.

Flotilla

Flotilla, o cliente de comunidades NIP-29 (Grupos Baseados em Relay) de hodlbod, entregou notificações via PR #270. A atualização refatora o sistema de alertas de polling baseado em âncora para notificações pull locais para web e notificações push para mobile. A arquitetura implementa o padrão NIP-9a proposto (veja PR #2194 abaixo), onde usuários registram callbacks de webhook com relays e recebem payloads de evento criptografados quando filtros correspondem.

Formstr

Formstr, a aplicação de formulários nativa do Nostr, adicionou importação de formulário e suporte a formulário criptografado em PR #422. Usuários agora podem importar formulários existentes por meio de um link de resposta ou outras instâncias Formstr. O recurso de criptografia permite que criadores de formulário restrinjam respostas para que apenas destinatários designados possam ler submissões, útil para pesquisas coletando informações sensíveis.

Pollerama

Pollerama (pollerama.fun), construído em nostr-tools, adicionou compartilhamento NIP-17 DM para enquetes via PR #141 e PR #142. Usuários agora podem compartilhar enquetes diretamente para contatos através de mensagens diretas criptografadas.

Nostrability Schemata

Nostrability schemata, a coleção de esquemas de verificação JSON para eventos Nostr, adicionou cobertura NIP-59 (Gift Wrap) via PR #59. A atualização inclui esquemas para eventos kind 13 (seal) e kind 1059 (gift wrap), complementando a cobertura de esquema NIP-17 existente.

Vector

Vector, o mensageiro desktop focado em privacidade usando NIP-17, NIP-44 e NIP-59 para criptografia com zero metadados, fez merge do PR #39 introduzindo otimizações de desempenho aceleradas por SIMD. Codificação hex roda 65x mais rápido, geração de preview de imagem até 38x mais rápido, e buscas de mensagem 184x mais rápido via indexação de busca binária. O PR adiciona intrinsics ARM64 NEON para Apple Silicon e AVX2/SSE2 x86_64 com detecção em runtime para Windows e Linux. Uso de memória caiu com structs de mensagem reduzidas de 472 para 128 bytes e armazenamento de npub cortado em 99,6% através de interning.

Vector v0.3.0 (dezembro de 2025) integrou MDK (Marmot Development Kit) para mensagens de grupo baseadas em protocolo MLS, trazendo grupos criptografados de ponta a ponta com forward secrecy para o cliente. Compartilhamento de arquivo MIP-04 agora lida com anexos imeta para grupos MLS, projetado para interoperabilidade com White Noise. O lançamento também introduziu uma plataforma Mini Apps com jogos multiplayer P2P baseados em WebXDC, uma loja de apps descentralizada chamada The Nexus, integração de carteira PIVX para pagamentos in-app, edição de mensagens com rastreamento de histórico completo, e redução de memória de 4x durante uploads de imagem.

Atualizações de NIPs

Mudanças recentes no repositório de NIPs:

Mergeado:

NIP-47: Suporte a Hold Invoice - NIP-47 (Nostr Wallet Connect) agora suporta hold invoices, permitindo fluxos de pagamento avançados onde receptores devem explicitamente liquidar ou cancelar pagamentos. O PR adiciona três novos métodos RPC: make_hold_invoice cria um hold invoice usando uma preimage e hash de pagamento pré-gerados, settle_hold_invoice reivindica pagamento fornecendo a preimage original, e cancel_hold_invoice rejeita pagamento usando seu hash de pagamento. Uma nova notificação hold_invoice_accepted dispara quando um pagador bloqueia o pagamento. Isso permite casos de uso como conteúdo pay-to-unlock, sistemas de escrow de marketplace e gating de pagamento. Implementações já estão em andamento em Alby Hub, Alby JS-SDK e dart NDK.
NIP-05: Requisito de Minúsculas - NIP-05 (Verificação de Domínio) agora explicitamente exige minúsculas tanto para chaves públicas hex quanto para nomes locais no arquivo nostr.json. Isso estava implícito na spec mas não declarado, causando problemas de interoperabilidade quando algumas implementações usavam maiúsculas e minúsculas misturadas enquanto outras normalizavam para minúsculas. Clientes validando identificadores NIP-05 agora devem rejeitar quaisquer respostas nostr.json contendo caracteres maiúsculos em chaves ou nomes.
NIP-73: Códigos de País - NIP-73 (Geotags) agora suporta códigos de país ISO 3166 como alternativa a geohashes. Eventos podem incluir tags ["g", "US", "countryCode"] para indicar localização em nível de país sem exigir coordenadas precisas. Isso permite filtragem e descoberta de conteúdo baseada em país para aplicações onde localização exata é desnecessária ou indesejável. O PR também adicionou um exemplo de geohash faltante à documentação da spec.

PRs Abertos e Discussões:

NIP-82: Aplicações de Software - franzap anunciou uma grande atualização para esta especificação draft, que define como aplicações de software são distribuídas via Nostr usando eventos kind 30063 de release. A atualização agora cobre aproximadamente 98% das plataformas de dispositivos globalmente, incluindo macOS, Linux, Windows, FreeBSD, ambientes WASM, extensões VS Code, extensões Chrome e Web Bundles/PWAs. A equipe está focando em seguida no suporte Android, PWA e iOS, convidando desenvolvedores a convergir neste padrão compartilhado. Zapstore planeja migrar para o novo formato nas próximas semanas.
NIP-74: Podcasts - Define eventos endereçáveis para shows de podcast (kind 30074) e episódios (kind 30075). Shows incluem metadados como título, descrição, categorias e imagens de capa. Episódios referenciam seu show pai e incluem URLs de enclosure, durações e marcadores de capítulo. A spec se integra com padrões de metadados Podcasting 2.0 e inclui tags de valor para monetização V4V (value-for-value) via Lightning. Plataformas como transmit.fm, uma plataforma de publicação de podcast nativa do Nostr, podem publicar diretamente para relays usando este formato, permitindo que podcasters distribuam conteúdo sem intermediários.
NIP-FR: Notas Apenas para Amigos - Propõe um mecanismo para publicar notas visíveis apenas para uma lista de amigos definida pelo usuário usando uma chave simétrica compartilhada chamada ViewKey. O autor criptografa notas (kind 2044) com a ViewKey usando NIP-44. A ViewKey em si é distribuída a cada amigo uma vez via NIP-59 (Gift Wrap). Amigos que possuem a ViewKey podem descriptografar e ler as notas; todos os outros veem apenas texto cifrado. Quando o autor remove um amigo, a ViewKey é rotacionada: uma nova chave é gerada e redistribuída a todos os amigos restantes via gift wrap, garantindo que o amigo removido perde acesso a posts futuros. Esta abordagem separa criptografia de conteúdo (simétrica, eficiente) de distribuição de chaves (assimétrica, por amigo), mantendo o protocolo leve enquanto habilita um recurso de privacidade frequentemente solicitado.
NIP-DB: Interface de Banco de Dados de Eventos Nostr para Navegador (spec) - Propõe uma interface padrão window.nostrdb para extensões de navegador que fornecem armazenamento local de eventos Nostr. A API inclui métodos para adicionar eventos, consultar por ID ou filtro, contar correspondências e assinar atualizações. Aplicações web podem usar esta interface para ler de eventos cacheados localmente sem fazer requisições de relay, reduzindo largura de banda e latência. A extensão de navegador nostr-bucket de hzrd149 fornece uma implementação de referência, injetando a interface em todas as abas do navegador. Uma biblioteca polyfill complementar implementa a mesma API usando IndexedDB para ambientes sem a extensão.
TRUSTed Filters - Uma suíte de cinco propostas relacionadas para curadoria descentralizada de conteúdo, construindo sobre o mesclado PR #1534 Trusted Assertions de vitorpamplona. A especificação principal introduz eventos kind 17570 para declarar Preferências de Provedor de Confiança, permitindo que usuários especifiquem quais serviços eles confiam para filtragem e ranking de eventos. Provedores de confiança publicam assertions (kind 37571), estatísticas (kind 37572) e rankings (kind 37573) que clientes podem assinar. O sistema usa uma arquitetura de plugin com tags W/w para especificar tipos de filtro e transformações. Isso permite que operações computacionalmente caras como detecção de spam, scoring de reputação e ranking de conteúdo rodem em infraestrutura dedicada enquanto usuários mantêm controle sobre quais provedores eles confiam. A suíte inclui specs separadas para presets de filtro, rankings de usuário, eventos confiáveis e definições de plugin.
NIP-9a: Notificações Push - hodlbod propõe um padrão para notificações push baseadas em relay usando eventos kind 30390 de registro. Usuários criam um registro contendo filtros para eventos que eles querem receber e uma URL de callback de webhook. O registro é criptografado para a pubkey do relay (do campo self do seu NIP-11). Quando eventos correspondentes ocorrem, relays fazem POST para o callback com o ID do evento (plaintext para deduplicação) e o evento em si (criptografado NIP-44 para o usuário). Esta arquitetura permite que relays enviem notificações push enquanto protegem conteúdo de evento de servidores push intermediários. O PR #270 do Flotilla implementa este padrão.
Catallax - Propõe um protocolo de trabalho contratual descentralizado com escrow usando eventos kind 33400. O sistema define três papéis: árbitros anunciam disponibilidade e termos, patrocinadores criam tarefas financiadas com Bitcoin em escrow, e agentes livres completam trabalho para reivindicar pagamento. Árbitros resolvem disputas quando necessário. O protocolo permite coordenação de trabalho freelance trustless onde fundos são bloqueados até que entregas sejam aceitas ou arbitragem conclua.

Deep Dive de NIP: NIP-47 (Nostr Wallet Connect)

NIP-47 define Nostr Wallet Connect (NWC), um protocolo para controle remoto de carteira Lightning usando Nostr como camada de comunicação. Com a adição de suporte a hold invoice desta semana, NWC agora cobre toda a gama de operações Lightning.

O protocolo funciona através de uma troca simples. Uma aplicação de carteira publica um evento “wallet info” (kind 13194) descrevendo suas capacidades. Aplicações cliente enviam requisições criptografadas (kind 23194) pedindo à carteira para executar operações como pagar invoices, criar invoices ou verificar saldos. A carteira responde com resultados criptografados (kind 23195).

NWC usa criptografia NIP-44 entre cliente e carteira, com um par de chaves dedicado para operações de carteira, mantendo-o separado da identidade principal do usuário. Esta separação significa que comprometer uma conexão NWC não expõe a identidade Nostr do usuário.

Métodos Suportados:

A spec define métodos para operações Lightning principais: pay_invoice envia pagamentos, make_invoice gera invoices para recebimento, lookup_invoice verifica status de pagamento, get_balance retorna o saldo da carteira, e list_transactions fornece histórico de pagamentos. O recém-mergeado pay_keysend permite pagamentos sem invoices, e hold_invoice suporta pagamentos condicionais.

Eventos de Exemplo:

O serviço de carteira publica um evento info (kind 13194) anunciando suas capacidades:

{
 "kind": 13194,
 "pubkey": "<wallet service pubkey>",
 "content": "pay_invoice get_balance make_invoice lookup_invoice list_transactions notifications",
 "tags": [
 ["encryption", "nip44_v2"],
 ["notifications", "payment_received payment_sent"]
 ],
 "created_at": "<unix timestamp>",
 "id": "<event hash>",
 "sig": "<wallet service signature>"
}

Um cliente envia uma requisição criptografada (kind 23194) para pagar um invoice:

{
 "kind": 23194,
 "pubkey": "<client ephemeral pubkey from connection URI secret>",
 "content": "<NIP-44 encrypted: {\"method\": \"pay_invoice\", \"params\": {\"invoice\": \"lnbc50n1...\"}}>",
 "tags": [
 ["p", "<wallet service pubkey>"],
 ["encryption", "nip44_v2"]
 ],
 "created_at": "<unix timestamp>",
 "id": "<event hash>",
 "sig": "<client ephemeral key signature>"
}

O serviço de carteira responde (kind 23195) com o resultado do pagamento:

{
 "kind": 23195,
 "pubkey": "<wallet service pubkey>",
 "content": "<NIP-44 encrypted: {\"result_type\": \"pay_invoice\", \"result\": {\"preimage\": \"...\"}, \"error\": null}>",
 "tags": [
 ["p", "<client ephemeral pubkey>"],
 ["e", "<request event id>"]
 ],
 "created_at": "<unix timestamp>",
 "id": "<event hash>",
 "sig": "<wallet service signature>"
}

A tag e na resposta referencia a requisição original, permitindo que clientes correspondam respostas às suas requisições.

Hold Invoices:

O PR #1913 desta semana adicionou suporte a hold invoice, permitindo pagamentos estilo escrow. Diferente de invoices padrão onde o receptor imediatamente reivindica o pagamento liberando a preimage, hold invoices permitem que o receptor adie esta decisão. Quando um pagador envia para um hold invoice, fundos são bloqueados ao longo da rota de pagamento. O receptor então escolhe liquidar (liberar a preimage e reivindicar fundos) ou cancelar (rejeitar o pagamento, retornando fundos ao pagador). Se nenhuma ação ocorrer, o pagamento expira e fundos retornam automaticamente. O PR adiciona três métodos NWC: make_hold_invoice, settle_hold_invoice e cancel_hold_invoice, mais uma notificação hold_invoice_accepted. Este mecanismo alimenta aplicações como o escrow de compartilhamento de caronas do Ridestr e resolução de disputas de marketplace.

Implementações Atuais:

Principais carteiras suportam NWC: Zeus, Alby e Primal (a partir do PR #874 desta semana) todos implementam suporte do lado da carteira. No lado do cliente, Damus, Amethyst e a maioria dos principais clientes Nostr podem conectar a carteiras NWC para zapping e pagamentos.

O protocolo permite uma separação de responsabilidades: usuários podem rodar sua carteira em um dispositivo enquanto interagem com o Nostr de outro, com relays Nostr servindo como canal de comunicação. Esta arquitetura significa que clientes móveis não precisam manter fundos diretamente, melhorando a segurança ao manter infraestrutura de carteira separada de clientes sociais.

Considerações de Segurança:

Conexões NWC devem ser tratadas como sensíveis. Enquanto a criptografia protege o conteúdo das mensagens, a pubkey da carteira e o segredo de conexão devem ser guardados. Aplicações devem permitir que usuários revoguem conexões e definam limites de gastos. O protocolo suporta restrições de capacidade, então carteiras podem limitar quais operações uma conexão específica pode executar.

Deep Dive de NIP: NIP-59 (Gift Wrap)

NIP-59 define um protocolo para encapsular qualquer evento Nostr em múltiplas camadas de criptografia, escondendo a identidade do remetente de relays e observadores. As propostas desta semana para notas apenas para amigos (NIP-FR) e notificações push (NIP-9a) ambas dependem de gift wrapping, tornando-o uma primitiva de privacidade fundamental que vale a pena entender.

As Três Camadas:

Gift wrapping usa três estruturas aninhadas:

Rumor (evento não assinado): O conteúdo original como um evento Nostr sem assinatura. O rumor não pode ser enviado diretamente para relays porque relays rejeitam eventos não assinados.
Seal (kind 13): O rumor é criptografado usando NIP-44 e colocado em um evento kind 13. O seal É assinado pela chave real do autor. Esta é a prova criptográfica de autoria.
Gift Wrap (kind 1059): O seal é criptografado e colocado em um evento kind 1059 assinado por um par de chaves aleatório de uso único. O gift wrap inclui uma tag p para roteamento ao destinatário.

Um Equívoco Comum: Negabilidade

A spec menciona que rumors não assinados fornecem “negabilidade”, mas isso é enganoso. A camada seal É assinada pelo autor real. Quando o destinatário descriptografa o gift wrap e então o seal, eles têm prova criptográfica de quem enviou a mensagem. O destinatário poderia até construir uma prova de conhecimento zero revelando a identidade do remetente sem expor sua própria chave privada.

O que gift wrap realmente fornece é privacidade do remetente para observadores: relays e terceiros não podem determinar quem enviou a mensagem porque eles só veem o gift wrap assinado por uma chave aleatória. Mas o destinatário sempre sabe, e pode provar.

Eventos de Exemplo:

Aqui está a estrutura completa de três camadas da spec (enviando “Você vai na festa hoje à noite?”):

O rumor (não assinado, não pode ser publicado em relays):

{
 "created_at": 1691518405,
 "content": "Are you going to the party tonight?",
 "tags": [],
 "kind": 1,
 "pubkey": "611df01bfcf85c26ae65453b772d8f1dfd25c264621c0277e1fc1518686faef9",
 "id": "9dd003c6d3b73b74a85a9ab099469ce251653a7af76f523671ab828acd2a0ef9"
}

O seal (kind 13, assinado pelo autor real, contém rumor criptografado):

{
 "kind": 13,
 "pubkey": "611df01bfcf85c26ae65453b772d8f1dfd25c264621c0277e1fc1518686faef9",
 "content": "AqBCdwoS7/tPK+QGkPCadJTn8FxGkd24iApo3BR9/M0uw6n4RFAFSPAKKMgkzVMo...",
 "created_at": 1703015180,
 "tags": [],
 "id": "28a87d7c074d94a58e9e89bb3e9e4e813e2189f285d797b1c56069d36f59eaa7",
 "sig": "02fc3facf6621196c32912b1ef53bac8f8bfe9db51c0e7102c073103586b0d29..."
}

O gift wrap (kind 1059, assinado por chave efêmera aleatória, contém seal criptografado):

{
 "kind": 1059,
 "pubkey": "18b1a75918f1f2c90c23da616bce317d36e348bcf5f7ba55e75949319210c87c",
 "content": "AhC3Qj/QsKJFWuf6xroiYip+2yK95qPwJjVvFujhzSguJWb/6TlPpBW0CGFwfuf...",
 "created_at": 1703021488,
 "tags": [["p", "166bf3765ebd1fc55decfe395beff2ea3b2a4e0a8946e7eb578512b555737c99"]],
 "id": "5c005f3ccf01950aa8d131203248544fb1e41a0d698e846bd419cec3890903ac",
 "sig": "35fabdae4634eb630880a1896a886e40fd6ea8a60958e30b89b33a93e6235df7..."
}

Note: a pubkey do seal é o autor real (611df01...), enquanto a pubkey do gift wrap é uma chave de uso único aleatória (18b1a75...). Relays só veem o gift wrap, então eles não podem atribuir a mensagem ao autor real.

O Que Cada Camada Protege:

O rumor não é assinado e não pode ser publicado em relays diretamente. O seal é assinado pelo autor real e prova autoria para o destinatário. O gift wrap é assinado por uma chave de uso único aleatória, escondendo o autor real de relays e observadores. Apenas o destinatário pode descriptografar através de ambas as camadas para alcançar o conteúdo original e verificar a assinatura do autor no seal.

Aplicações Atuais:

NIP-17 (Mensagens Diretas Privadas) usa gift wrap para DMs criptografadas, substituindo o esquema NIP-04 mais antigo. O proposto NIP-FR (notas apenas para amigos) usa gift wrapping para distribuir ViewKeys aos amigos, que então descriptografam notas cifradas com essas chaves. NIP-9a (notificações push) criptografa payloads de notificação usando princípios de gift wrap.

Proteção de Metadados:

Timestamps devem ser randomizados para frustrar análise de timing. Relays devem exigir AUTH antes de servir eventos kind 1059 e só servi-los para o destinatário marcado. Ao enviar para múltiplos destinatários, crie gift wraps separados para cada um.

É isso para esta semana. Construindo algo? Tem notícias para compartilhar? Quer que cubramos seu projeto? Entre em contato via DM NIP-17 ou nos encontre no Nostr.

Nostr Compass #7

Wed, 28 Jan 2026 00:00:00 +0000

Bem-vindo de volta ao Nostr Compass, seu guia semanal sobre o Nostr.

Esta semana: Ridestr traz compartilhamento de caronas descentralizado para o Nostr com pagamentos Cashu e compartilhamento de localização criptografado. Pomade introduz recuperação baseada em e-mail para signatários multisig. Damus lança negentropy para sincronização confiável de DMs. O aplicativo desktop do Amethyst adiciona busca, favoritos e zaps. Amber v4.1.1 exibe pontuações de confiança de relays. Marmot faz merge do MIP-03 e constrói um aplicativo de chat de referência em TypeScript. diVine adiciona autenticação por QR via NIP-46 e suporte a menções. Novas propostas de NIP abordam gerenciamento de comunidades, sincronização baseada em sequência e armazenamento de arquivos criptografados. Também olhamos para cinco anos de janeiros do Nostr, traçando a evolução do protocolo desde um punhado de adotantes iniciais em 2021 até o lançamento explosivo do Damus na App Store em 2023 e o ecossistema de clientes amadurecido de 2025.

Notícias

Ridestr Traz Compartilhamento de Caronas Descentralizado para o Nostr

Ridestr está desenvolvendo um aplicativo de compartilhamento de caronas peer-to-peer construído inteiramente no Nostr, permitindo transações diretas entre motoristas e passageiros com pagamentos em Bitcoin e Cashu. O protocolo usa kinds de evento personalizados (30173, 3173-3175, 30180/30181) para coordenar corridas enquanto mantém a privacidade através de divulgação progressiva de localização e criptografia NIP-44.

O sistema funciona através de um fluxo cuidadosamente coreografado: motoristas transmitem disponibilidade usando localizações codificadas em geohash (~5km de precisão) via eventos kind 30173, passageiros solicitam corridas com estimativas de tarifa através de kind 3173, e pagamentos são garantidos usando tokens de escrow HTLC antes do início da corrida. A privacidade da localização é preservada através de divulgação progressiva, onde detalhes de embarque só são revelados quando os motoristas chegam e destinos são compartilhados após verificação de PIN. Toda comunicação entre as partes usa criptografia NIP-44 para privacidade.

Ridestr implementa segurança de pagamento através de escrow HTLC com assinaturas P2PK. Quando um passageiro aceita a oferta de um motorista, ele bloqueia tokens Cashu com um hash de pagamento que apenas o motorista pode reivindicar após a conclusão da corrida. O protocolo atualmente opera com arquitetura de mint único, exigindo que passageiros e motoristas usem o mesmo mint Cashu. A implementação Android baseada em Kotlin do projeto lida com verificação de provas e recuperação de provas obsoletas através de verificações de estado NUT-07.

Ridestr enfrenta desafios que a maioria dos aplicativos Nostr evita: coordenação de localização em tempo real, escrow de pagamento com resolução de disputas e sistemas de reputação para interações no mundo físico. O projeto está em beta e demonstra que o modelo de eventos do Nostr pode suportar marketplaces de serviços peer-to-peer, não apenas compartilhamento de conteúdo.

Pomade Lança Sistema de Recuperação Alpha para Signatários Multisig

Pomade, desenvolvido por hodlbod, se baseia no ecossistema FROSTR existente para fornecer um serviço de assinatura de limiar focado em recuperação. Usando assinaturas FROST (Flexible Round-Optimized Schnorr Threshold) através da biblioteca @frostr/bifrost, Pomade adiciona fluxos de recuperação baseados em e-mail em cima da criptografia de limiar. O sistema fragmenta a chave secreta do usuário usando Shamir Secret Sharing, distribuindo fragmentos entre múltiplos signatários independentes com um limiar configurável (2-de-3, 3-de-5, etc.).

O protocolo opera inteiramente sobre o Nostr usando um único kind de evento (28350) com payloads criptografados NIP-44. Ao assinar, o cliente solicita assinaturas parciais de pelo menos threshold signatários, então agrega essas em uma assinatura Schnorr válida. Para criptografia, signatários colaboram para derivar segredos compartilhados via ECDH sem que nenhuma parte aprenda a chave completa.

A recuperação funciona através de dois métodos de autenticação: baseado em senha (usando argon2id com a pubkey do signatário como salt) ou OTP por e-mail. Para prevenir ataques MITM durante recuperação por OTP, cada signatário gera seu próprio código de verificação com um prefixo fornecido pelo cliente, exigindo que usuários se autentiquem independentemente com cada signatário. O protocolo requer prova de trabalho em eventos de registro (20+ bits por NIP-13) para prevenir spam.

O modelo de confiança é explícito: se threshold signatários conspirarem, eles podem roubar a chave. Provedores de e-mail são totalmente confiáveis já que podem interceptar OTPs. Usuários não podem recuperar independentemente sua chave secreta completa; fazer isso requer cooperação de threshold signatários. O protocolo é projetado para integrar novos usuários não familiarizados com gerenciamento de chaves, com a recomendação explícita de que usuários migrem para auto-custódia uma vez confortáveis. Pomade alerta sobre potencial “perda de chave, roubo, negação de serviço ou vazamento de metadados” dado seu status alpha não auditado.

Lançamentos

Damus Lança Negentropy para Sincronização Confiável de DMs

Damus v1.13 lança a implementação de negentropy que previsualizamos como PR aberto na semana passada. PR #3536 adiciona suporte base de negentropy à camada de rede, habilitando reconciliação de conjuntos com relays que suportam o protocolo. Um PR #3547 complementar adiciona sincronização de DM por pull-to-refresh que usa negentropy para recuperar mensagens perdidas quando assinaturas REQ padrão falham.

A implementação segue uma abordagem conservadora: o carregamento normal de DM continua inalterado, com negentropy disponível como mecanismo de recuperação quando usuários atualizam manualmente. Testes automatizados demonstram a correção gerando uma DM com timestamp antigo que consultas padrão perderiam, então usando sincronização negentropy para recuperá-la com sucesso. Embora o suporte a negentropy requeira relays compatíveis, a implementação lida graciosamente com ambientes de relay mistos usando o protocolo onde disponível.

Amber v4.1.1 - Pontuações de Confiança de Relay

Amber v4.1.1 lança exibição de pontuação de confiança de relay (PR #289), implementando os conceitos de avaliação de relay discutidos na cobertura de Trusted Relay Assertions da semana passada. Pontuações de confiança agora aparecem na página de Relays e para solicitações de conexão NostrConnect, ajudando usuários a avaliar a confiabilidade do relay antes de autorizar conexões. O lançamento também inclui uma UI redesenhada de login/eventos/permissões e suporte para o método switch_relays. Melhorias de desempenho fazem cache de operações de keystore, abordando relatos de tempos de carregamento de 20+ segundos em dispositivos mais antigos.

nak v0.18.2 - Integração MCP

nak (Nostr Army Knife) de fiatjaf v0.18.2 adiciona suporte ao Model Context Protocol via nak mcp, permitindo que agentes de IA busquem pessoas no Nostr, publiquem notas, mencionem usuários e leiam conteúdo usando o modelo outbox. O lançamento também introduz um instalador de uma linha (curl -sSL https://raw.githubusercontent.com/fiatjaf/nak/master/install.sh | sh) que baixa binários pré-compilados, eliminando o requisito de toolchain Go para usuários finais. O modo Bunker agora suporta Unix sockets e switch_relays.

Zeus v0.12.2 Beta - Correções NWC

Zeus v0.12.2-beta1 lança múltiplas correções NWC abordando problemas cobertos na cobertura do Zeus da semana passada.

Atualizações de Projetos

Amethyst Desktop - Fase 2A Lançada

Amethyst lançou a Fase 2A de seu aplicativo desktop, adicionando Busca, Favoritos, Zaps, visualizações de Thread e conteúdo de formato longo (Reads) à experiência desktop. Um PR #1683 complementar adiciona feedback transparente de transmissão de eventos para que usuários agora vejam status em tempo real por relay enquanto seus eventos se propagam pela rede, facilitando o diagnóstico de problemas de conectividade.

Progresso do Notedeck: Aplicativo de Calendário e Polimento de UX

O cliente desktop Notedeck da equipe Damus fez merge do comportamento de auto-ocultar barra de ferramentas (PR #1268) que responde à velocidade de rolagem para mais espaço de tela em visualizações móveis. Um draft PR #1271 adiciona um aplicativo de Calendário NIP-52 completo com visualizações de mês/semana/dia/agenda, suporte a RSVP e comentários NIP-22 em eventos de calendário, atualmente com feature flag para testes.

Jumble Adiciona Modo Comunidade

Jumble, o cliente web focado em relay, adicionou modo comunidade e suporte para presets de conjunto de relays via variáveis de ambiente, facilitando o deploy de instâncias temáticas como nostr.moe.

Dashboard de Pedidos do Shopstr

Shopstr substituiu seu gerenciamento de pedidos baseado em chat por um Dashboard de Pedidos dedicado. A nova interface fornece uma visualização centralizada para comerciantes rastrearem status de pedidos, marcarem mensagens como lidas e gerenciarem fulfillment sem rolar através de threads de chat. A atualização descontinua cache IndexedDB em favor de APIs de status de pedido server-side e revisa como DMs de pedido são tagueadas para melhor filtragem.

Formstr Adiciona Perguntas de Grade

Formstr, o aplicativo de formulários nativo do Nostr, adicionou perguntas de grade e reescreveu seu SDK com suporte a embed. Uma [correção para signatários não-NIP-07](https://github.com/abh3po/nostr-forms/pull/418) resolveu problemas para usuários com bunker ou signatários locais tentando enviar formulários com sua identidade.

nostr-tools Atualiza Dependências de Criptografia

nostr-tools, a biblioteca JavaScript principal, atualizou para @noble/curves v2.0.1, abordando mudanças de API quebradas em 27 arquivos e adotando as últimas bibliotecas noble auditadas. fiatjaf também adicionou suporte switch_relays ao NIP-46, permitindo que clientes bunker mudem dinamicamente conexões de relay.

Zeus Trabalhando em Reviews de Mint NIP-87

Zeus tem um [PR aberto para reviews de mint NIP-87](https://github.com/ZeusLN/zeus/pull/3576), permitindo que usuários descubram e avaliem mints Cashu filtrados por follows do Nostr. Reviews incluem classificações por estrelas e podem ser enviadas anonimamente ou com a nsec do usuário.

Camelus Lança Suporte Completo a DM

Camelus, um cliente Android baseado em Flutter construído com Dart NDK para desempenho móvel eficiente em bateria, adicionou mensagens diretas abrangentes com 20+ commits esta semana. A atualização inclui categorias de chat, datas de mensagens, UI de envio otimista, funcionalidade de nota para si mesmo e tratamento adequado de relay de DM.

Atualizações do Protocolo Marmot

A resolução determinística de commit MIP-03 que cobrimos como PR aberto na semana passada agora foi mergeada. MDK PR #152 garante que todos os chats de grupo baseados em MLS convirjam para o mesmo estado quando múltiplos commits válidos chegam para a mesma epoch.

Um spec PR #28 complementar adiciona requisitos de ciclo de vida de init_key abordando lacunas de auditorias de implementação: material de chave privada de mensagens Welcome deve ser excluído com segurança após processamento (zeroização, limpeza de armazenamento), e novos membros devem realizar auto-atualizações dentro de 24 horas para forward secrecy.

O SDK TypeScript (marmot-ts) está construindo um aplicativo de chat de referência. PR #37 adiciona criação/listagem de grupos, gerenciamento de key package com fluxos de publicar/transmitir/excluir e convites por QR code. Um PR aberto #38 por hzrd149 implementa persistência de histórico de mensagens com paginação. O backend whitenoise-rs fez merge de 15 PRs esta semana incluindo suporte multi-idioma (PR #455) e referências de mídia MIP-04 v2 (PR #450).

diVine Adiciona Recursos de Integração Nostr

diVine, o aplicativo de vídeos curtos, continua rápida integração com Nostr.

PRs abertos incluem autenticação por QR code NIP-46 (PR #1019) e mensagens diretas criptografadas NIP-17 (PR #834). A atividade desta semana focou em suporte a menções convertendo URIs nostr: e @menções em links de perfil clicáveis, fallbacks de avatar Classic Viners usando perfis Nostr, e ferramentas de edição de vídeo incluindo desenho, filtros e stickers.

Atualizações de NIPs

Mudanças recentes no repositório de NIPs:

Mesclados:

Trusted Relay Assertions - A proposta para padronizar pontuação de confiança de relay que cobrimos na semana passada foi mesclada. A especificação define eventos kind 30385 para asserções de confiança de relay com pontuação em confiabilidade, qualidade e acessibilidade. O debate que levou à mesclagem centrou-se em se pontuações de confiança devem ser “globais” (computadas uma vez para todos os usuários) ou “personalizadas” (relativas ao grafo social de cada observador). Algoritmos estilo PageRank como o Trust Rank do nostr.band e GrapeRank resistem a ataques sybil dividindo qualquer rank passado através de contas falsas pelo tamanho da fazenda de bots.

PRs Abertos e Discussões:

Communikeys - Uma proposta abrangente para gerenciamento de comunidades que usa npubs existentes como identificadores de comunidade em vez de abordagens baseadas em relay. Qualquer npub pode se tornar uma comunidade publicando um evento kind 10222; publicações visam comunidades via eventos kind 30222. Controle de acesso usa badges NIP-58, permitindo gerenciamento de membros delegado com armazenamento cold para chaves de comunidade.
NIP-CF: Changes Feed - Um rascunho propondo sincronização de eventos baseada em sequência como alternativa a filtros since baseados em timestamp. O problema: sincronização Nostr padrão usando timestamps since pode perder eventos quando múltiplos eventos compartilham o mesmo timestamp de precisão de segundo, relógios de cliente e relay divergem, ou checkpointing é impreciso. NIP-CF resolve isso fazendo relays atribuírem números de sequência monotonicamente crescentes a eventos armazenados, fornecendo ordenação total estrita. Clientes solicitam mudanças desde um número de sequência específico e recebem eventos em ordem garantida, com checkpointing preciso que nunca perde eventos. A proposta também suporta modo ao vivo/contínuo onde assinaturas permanecem abertas após sincronização inicial para atualizações em tempo real.
NIP-XX: Encrypted File Sync - Um protocolo definindo kinds 30800 (arquivos criptografados), 30801 (índices de vault) e 30802 (documentos compartilhados) para sincronizar conteúdo criptografado entre dispositivos usando relays Nostr. O protocolo permite que aplicativos de anotações local-first forneçam sincronização criptografada de ponta a ponta sem servidores centralizados. Conteúdos de arquivo, caminhos, nomes e estrutura de pastas são todos criptografados usando auto-criptografia NIP-44, então relays armazenam blobs que não podem ler. Anexos binários como imagens usam servidores Blossom com criptografia client-side. Kind 30802 permite compartilhamento de documentos entre usuários criptografando para a chave pública do destinatário.

Cinco Anos de Janeiros do Nostr

O newsletter do mês passado traçou os marcos de dezembro do Nostr desde o primeiro lançamento de cliente de fiatjaf até a doação catalítica de Jack Dorsey. Esta retrospectiva mapeia o que aconteceu em cada janeiro de 2021 até 2025, focando em desenvolvimentos técnicos verificados.

Janeiro de 2021: Desenvolvimento Inicial

O terceiro mês do Nostr viu desenvolvimento contínuo no Branle, o cliente Vue.js de fiatjaf que havia lançado em dezembro de 2020. Um pequeno grupo de adotantes iniciais, provavelmente menos de 15 pessoas, se coordenava através do grupo Telegram @nostr_protocol (criado em 16 de novembro de 2020), testando o protocolo em um ou dois relays experimentais. O cliente de linha de comando noscl fornecia interação baseada em terminal.

A fundação técnica já estava definida: usuários identificados por chaves públicas secp256k1, posts assinados criptograficamente com assinaturas Schnorr, e relays servindo como armazenamento burro que não se comunicam entre si. Isso era deliberadamente criptografia nativa do Bitcoin, uma escolha de design que moldaria padrões de adoção anos depois.

Janeiro de 2022: Descoberta por Desenvolvedores

Janeiro de 2022 abriu com o Nostr ainda agitado por sua primeira aparição no Hacker News (31 de dezembro de 2021), que gerou 110 pontos e 138 comentários. Na época daquele post, apenas cerca de sete relays alimentavam toda a rede, com comentaristas notando que “spam ainda não é um problema porque nostr é super novo e ninguém usa ainda.” Robert C. Martin (“Uncle Bob”) havia endossado o Nostr como potencialmente “a solução final para comunicação social.” A discussão continuou em janeiro, com desenvolvedores debatendo arquitetura de relay versus P2P verdadeiro, resistência à censura versus moderação, e se a simplicidade poderia escalar.

O post do HN provocou uma onda de novas implementações. O próprio Uncle Bob começou more-speech, um cliente desktop Clojure, em 18 de janeiro. A biblioteca go-nostr de fiatjaf (criada em janeiro de 2021) e o cliente de linha de comando noscl forneciam ferramentas Go, enquanto nostr-tools oferecia suporte JavaScript. Até dezembro de 2022, aproximadamente 800 perfis tinham bios. Branle permaneceu o cliente web principal, recebendo atualizações incluindo importação de chave privada e suporte multi-relay. Desafios técnicos eram evidentes: chaves hex de 64 caracteres se mostraram pouco intuitivas, atrasos de mensagens frustravam usuários, e a comunidade questionava se a arquitetura poderia lidar com tráfego em escala Twitter.

Janeiro de 2023: A Explosão

Janeiro de 2023 transformou o Nostr de experimento em movimento. Damus, o cliente iOS de William Casarin (jb55), lutou contra o processo de aprovação da App Store da Apple. Rejeitado em 1º de janeiro, rejeitado novamente em 26 de janeiro, foi finalmente aprovado em 31 de janeiro. Essa aprovação desencadeou uma cascata: Damus imediatamente alcançou o #10 em Redes Sociais nos EUA. Jack Dorsey chamou isso de “um marco para protocolos abertos.”

Oito dias antes, em 23 de janeiro, Edward Snowden anunciou sua presença no Nostr: “Uma das coisas legais sobre o Nostr… além da resistência à censura, é que você não está limitado a 280 caracteres.” Seu endosso de um denunciante da NSA carregava peso em círculos conscientes de privacidade, e usuários imediatamente começaram a enviar zaps de sats via Lightning.

Clientes web correram para integrar o influxo. Snort, criado por kieran em dezembro de 2022, emergiu como um cliente React cheio de recursos; em 13 de janeiro, Snort integrou registro NIP-05 via API Nostr Plebs, permitindo que novos usuários reivindicassem identidades legíveis por humanos durante o onboarding. Iris, desenvolvido em tempo integral por Martti Malmi (um contribuidor inicial do Bitcoin que recebeu a segunda transação de Bitcoin de Satoshi), oferecia interfaces web e móvel com identidades NIP-05 gratuitas em iris.to. Astral, construído por monlovesmango com Quasar (Vue.js) como fork do Branle, focava em gerenciamento de relay com seu recurso de agrupamento de relay que permitia usuários organizarem relays em conjuntos para postar e filtrar. Betas TestFlight para clientes iOS lotavam em horas, e Amethyst dominava o Android.

A infraestrutura lutou para acompanhar. Todos os relays eram operados por entusiastas pagando do próprio bolso. Relays pagos usando micropagamentos Lightning criavam filtragem natural de spam mas introduziam fricção de acesso. Damus foi removido da App Store da China apenas dois dias após aprovação, supostamente a pedido do principal órgão de vigilância da internet da China.

Janeiro de 2024: Endurecimento do Protocolo

Janeiro de 2024 focou em padronização de protocolo e construção de comunidade. Nostr PHX começou o ano com um encontro em 5 de janeiro em Phoenix, reunindo cypherpunks locais. Este foi o primeiro de muitos eventos comunitários naquele ano incluindo BTC Prague (junho), Nostriga em Riga (agosto) e Nostrasia.

O desenvolvimento de protocolo mais significativo foi NIP-59 (Gift Wrap) sendo mergeado em 29 de janeiro, fornecendo proteção de metadados para comunicações criptografadas. Gift Wrap se baseia no padrão de criptografia NIP-44 (que havia sido auditado pela Cure53 em dezembro de 2023) para esconder a identidade do remetente dos relays. O protocolo envolve mensagens criptografadas dentro de um evento externo assinado por um par de chaves aleatório de uso único. Relays veem apenas a pubkey descartável, enquanto a identidade real do remetente está enterrada no payload criptografado que apenas o destinatário pode descriptografar. Isso impede que operadores de relay e observadores de rede saibam quem está enviando mensagens para quem. Timestamps também podem ser randomizados para derrotar análise de timing.

O ecossistema expandiu além de mídia social. Plebeian Market tornou-se totalmente nativo do Nostr com conformidade NIP-15, permitindo carrinhos de compras cross-stall e um navegador de stalls para descobrir comerciantes. Shopstr emergiu como um marketplace sem permissão facilitando comércio Bitcoin. Zap.stream, construído por kieran, trouxe streaming ao vivo para o Nostr com pagamentos Lightning a 21 sats/minuto. Ferramentas de desenvolvimento amadureceram com NDK fornecendo abstrações TypeScript e rust-nostr oferecendo bindings Rust. Zeus v0.8.1 lançou com importação de contatos Nostr e LND persistente, preparando o terreno para integração Nostr Wallet Connect em lançamentos posteriores.

No entanto, a sustentabilidade da infraestrutura permanecia desafiadora. Pesquisa acadêmica deste período encontrou que 95% dos relays lutavam para cobrir custos operacionais, com 20% experimentando downtime significativo. A taxa de admissão para relays pagos era em média menos de 1.000 sats (~$0,45), insuficiente para sustentar operações.

Uma nota sobre golpes: O “Nostr Assets Protocol” e o token “$NOSTR” associado que lançaram por volta desta época foram publicamente denunciados por fiatjaf como “100% fraudulentos” e “um golpe de afinidade” sem conexão com o protocolo Nostr real.

Janeiro de 2025: Maturação de Clientes

Janeiro de 2025 viu desenvolvimento contínuo de clientes em todo o ecossistema. Nostur 1.17.0 lançou em 13 de janeiro com sincronização cross-device para estados de leitura, suporte a login multi-sig FROST, e desempenho otimizado de banco de dados local. Amethyst continuou sua transição para o modelo outbox, compilando automaticamente conjuntos de relay baseados em listas de follows em vez de exigir configuração manual.

Principais clientes começaram a se afastar do NIP-04 para mensagens diretas, migrando para NIP-17 e o proposto NIP-104 para criptografia aprimorada e proteção de metadados. O modelo Gossip (comunicação outbox/inbox) ganhou adoção conforme o ecossistema convergiu para padrões de uso de relay mais eficientes. Observadores da indústria previram que este seria o ano em que o Nostr transicionaria de protocolo de nicho para reconhecimento mainstream, com uma potencial migração de plataforma de alto perfil que poderia dobrar a atividade diária.

Janeiro de 2026: Segurança e Infraestrutura de Assinatura

Janeiro de 2026 trouxe avanços significativos em segurança e infraestrutura de assinatura. Primal Android 2.6.18 lançou assinatura remota NIP-46 e suporte a signatário local NIP-55, juntando-se a Amber e Aegis como um hub de assinatura completo para outros aplicativos Android. Bitchat completou uma auditoria de segurança da Cure53, a mesma firma que auditou Signal e NIP-44, com 17+ PRs corrigindo descobertas críticas incluindo limpeza de segredo DH e problemas de thread safety. Tanto Bitchat quanto Damus migraram de C Tor para Rust Arti para confiabilidade e segurança de memória aprimoradas.

O trabalho de protocolo continuou com NIP-71 (eventos de vídeo endereçáveis) sendo mergeado e um NIP de criptografia pós-quântica abrindo discussão sobre proteger o Nostr contra ataques quânticos. O rascunho Trusted Relay Assertions propôs padronizar pontuação de confiança de relay através de atestações assinadas. O Protocolo Marmot endureceu suas mensagens criptografadas baseadas em MLS com 18 PRs mergeados abordando descobertas de auditoria.

Aplicações do mundo real expandiram com Ridestr desenvolvendo compartilhamento de caronas descentralizado usando escrow Cashu e criptografia NIP-44, e Pomade adicionando fluxos de recuperação baseados em e-mail à assinatura de limiar FROST. Damus lançou negentropy para sincronização confiável de DM, enquanto o aplicativo desktop do Amethyst alcançou a Fase 2A com busca, favoritos e zaps.

Olhando Adiante

Seis anos de janeiros revelam a evolução do Nostr desde desenvolvimento inicial (2021) até descoberta pública (2022) até crescimento explosivo (2023) até endurecimento de protocolo (2024) até maturação de clientes (2025) até infraestrutura de segurança (2026). O padrão é familiar para qualquer um que assistiu protocolos abertos crescerem: anos de construção silenciosa, uma explosão repentina quando as condições se alinham, então o trabalho mais longo de tornar tudo confiável. O que começou com sete relays e um thread no Hacker News agora é infraestrutura auditada com aplicações reais. A questão para 2027: quando alguém chamar uma carona, enviar uma mensagem criptografada, ou recuperar uma chave perdida usando Nostr, eles sequer saberão que estão usando?

É isso para esta semana. Construindo algo? Tem notícias para compartilhar? Quer que cubramos seu projeto? Entre em contato via DM NIP-17 ou nos encontre no Nostr.

Nostr Compass #6

Wed, 21 Jan 2026 00:00:00 +0000

Bem-vindo de volta ao Nostr Compass, seu guia semanal sobre Nostr.

Esta semana: Bitchat substitui C Tor pela implementação Rust Arti para melhor confiabilidade e desempenho. nostrdb-rs ganha consultas fold streaming que habilitam operações de banco de dados com alocação zero. Listr recebe uma grande refatoração com migração para NDK 3 beta e manutenção assistida por IA após um ano de inatividade. Zeus entrega 17 PRs mesclados focados em correções de NIP-47 (Nostr Wallet Connect para controle remoto do Lightning) e melhorias no Cashu, enquanto Primal Android adiciona fluxos de backup de carteira e suporte a NIP-92 (dimensões de mídia para proporções adequadas). Um novo rascunho de NIP propõe Trusted Relay Assertions para pontuação padronizada de confiança de relays.

Notícias

Bitchat Migra para Rust Arti para Suporte Tor

Bitchat migrou do C Tor para Arti, a implementação Rust do protocolo Tor. PR #958 remove a dependência do C Tor e integra Arti, trazendo garantias de segurança de memória e confiabilidade aprimorada. A mudança elimina tentativas de despertar em modo dormente que causavam reinicializações de serviço em primeiro plano, um problema persistente com a implementação em C.

O que isso significa para os usuários: Mensagens criptografadas mais estáveis com menos desconexões, especialmente em dispositivos móveis. A implementação em Rust reduz riscos de falhas e drenagem de bateria devido a tentativas constantes de reconexão.

Arti é uma reescrita completa do Tor em Rust, desenvolvida pelo Tor Project para fornecer melhor segurança através de segurança de memória e integração mais fácil em aplicações. Para o Bitchat, as propriedades de segurança de memória reduzem a superfície de ataque ao lidar com mensagens criptografadas e conexões de relay. A migração segue a recente auditoria de segurança Cure53 da equipe (coberta no Newsletter #5), continuando suas melhorias de segurança.

O PR também introduz cobertura de testes abrangente para ChatViewModel e BLEService, remove código morto e estabiliza a suite de testes. Melhorias de confiabilidade da malha Bluetooth Low Energy acompanham as mudanças do Tor, abordando falhas de transferências grandes. Juntas, essas mudanças melhoram a resiliência do Bitchat para cenários de rede mesh offline onde o Tor fornece conectividade com a internet junto com comunicação BLE local.

Listr Revitalizado com Manutenção Assistida por IA

JeffG anunciou uma grande refatoração do Listr, o aplicativo de gerenciamento de listas Nostr disponível em listr.lol, após o projeto ter ficado inativo por mais de um ano. Usando assistência de IA, ele completou uma atualização abrangente incluindo migração para NDK 3 beta, atualizações para as versões mais recentes de Svelte e Vite, e todas as dependências atualizadas. A refatoração adiciona suporte de primeira classe para seguir pacotes, implementa paginação para listas excedendo 50 itens, e corrige inúmeros bugs que haviam se acumulado durante o período inativo.

O que isso significa para os usuários: Listr está de volta online com desempenho aprimorado e novos recursos para gerenciar listas de seguidores, coleções de conteúdo e curadoria de tópicos. A correção de paginação torna listas grandes realmente utilizáveis.

JeffG observou que sem assistência de IA, este trabalho de manutenção provavelmente nunca teria acontecido, impedindo que o projeto fosse abandonado. Listr habilita curadoria de conteúdo no Nostr, permitindo que usuários criem, gerenciem e compartilhem listas de perfis, tópicos e recursos. A atualização mantém o aplicativo compatível com os padrões atuais do Nostr e expectativas dos clientes à medida que o gerenciamento de listas se torna mais central para descoberta de conteúdo no protocolo.

Atualizações de NIP

Mudanças recentes no repositório de NIPs:

Mesclado:

NIP-29 (Grupos baseados em relay) - Esclarecimento de Chave de Relay (#2190 - mesclado) esclarece que a chave do relay é a própria URL do relay, não uma pubkey. A especificação agora afirma explicitamente “A chave do relay é a URL WebSocket do relay (por exemplo, wss://groups.example.com)” para evitar confusão. Isso afeta como os clientes identificam qual relay hospeda um determinado grupo, garantindo que os grupos sejam atribuídos adequadamente aos seus relays de hospedagem.

PRs Abertos e Discussões:

Trusted Relay Assertions - Um rascunho de NIP propõe padronizar a pontuação de confiança de relay através de eventos kind 30385 contendo pontuações de confiança (0-100) calculadas a partir de métricas de NIP-66 (descoberta e monitoramento de relay), reputação do operador e relatórios de usuários. A especificação divide a confiança em componentes de confiabilidade (tempo de atividade, latência), qualidade (TLS, documentação, verificação do operador) e acessibilidade (jurisdição, barreiras, risco de vigilância). A verificação do operador inclui assinaturas criptográficas via NIP-11 (documentos de informações de relay), registros DNS TXT e arquivos .well-known. Usuários declaram provedores de assertivas confiáveis via eventos kind 10385, habilitando clientes a consultar múltiplos provedores para perspectivas diversas. A proposta complementa a descoberta de NIP-66 com avaliação, ajudando NIP-46 (assinatura remota/Nostr Connect) a avaliar a confiabilidade do relay em URIs de conexão.
Criptografia Pós-Quântica - PR #2185 (aberto) continua evoluindo desde que o Newsletter #5 introduziu a proposta para algoritmos resistentes a quantum. A discussão desta semana focou em detalhes de implementação para cripto-agilidade: como clientes lidam com assinaturas duplas durante a migração, compatibilidade retroativa para clientes mais antigos e implicações de desempenho de assinaturas quânticas resistentes maiores. Contribuidores debateram se mandatar apenas ML-DSA-44 ou suportar múltiplos algoritmos (ML-DSA-44, Falcon-512, Dilithium) para flexibilidade. O consenso inclina-se para uma abordagem faseada: assinaturas quânticas opcionais inicialmente, tornando-se obrigatórias apenas após suporte generalizado do cliente e emergência de ameaça quântica real.

Mergulho Profundo em NIP: NIP-11 e NIP-66

Esta semana examinamos dois NIPs que trabalham juntos para habilitar descoberta e avaliação de relay: NIP-11 define como relays se descrevem, e NIP-66 padroniza como medimos o comportamento do relay. Juntos, eles formam a fundação para sistemas de avaliação de confiança de relay.

NIP-11: Documento de Informações de Relay

NIP-11 define um documento JSON que relays servem via HTTP para descrever suas capacidades, políticas e informações do operador. Quando um cliente se conecta a `wss://relay.example.com`, ele pode buscar `https://relay.example.com` (substituindo `wss://` por `https://`) para recuperar o documento de informações do relay.

O documento usa negociação de conteúdo HTTP padrão com o cabeçalho `Accept: application/nostr+json`. Isso permite que relays sirvam seu site normal para navegadores enquanto fornecem metadados legíveis por máquina para clientes Nostr. A resposta inclui nome e versão do software do relay, informações de contato do operador (pubkey, email, contato alternativo), NIPs suportados e parâmetros operacionais como requisitos de pagamento ou restrições de conteúdo.

Importante, documentos básicos NIP-11 são JSON não assinado servido via HTTPS, confiando apenas em certificados TLS para autenticidade. Isso significa que qualquer pessoa controlando o servidor web do relay pode modificar o documento, tornando as alegações do operador não verificáveis. A proposta Trusted Relay Assertions aborda essa lacuna introduzindo atestados assinados através do campo `self` pubkey de um relay, habilitando prova criptográfica de identidade do operador similar a como relays usam eventos assinados para mecanismos de autenticação.

```json { “name”: “relay.example.com”, “description”: “Um relay público de propósito geral”, “pubkey”: “79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798”, “contact”: “admin@example.com”, “supported_nips”: [1, 2, 4, 9, 11, 12, 16, 20, 22], “software”: “git+https://github.com/relay/relay.git”, “version”: “1.2.3”, “limitation”: { “max_message_length”: 16384, “max_subscriptions”: 20, “max_filters”: 100, “max_limit”: 5000, “max_subid_length”: 100, “min_prefix”: 4, “max_event_tags”: 2000, “max_content_length”: 8196, “min_pow_difficulty”: 0, “auth_required”: false, “payment_required”: false }, “payments_url”: “https://relay.example.com/payments", “fees”: { “admission”: [{“amount”: 5000, “unit”: “msats”}], “subscription”: [{“amount”: 1000, “unit”: “msats”, “period”: 2592000}], “publication”: [] } } ```

O objeto `limitation` informa aos clientes quais restrições o relay aplica. `max_message_length` limita o tamanho do quadro WebSocket, `max_subscriptions` limita assinaturas REQ simultâneas por conexão, `max_filters` limita filtros por REQ, e `max_limit` restringe quantos eventos um único filtro pode solicitar. Esses parâmetros ajudam clientes a adaptar seu comportamento às capacidades do relay, evitando desconexões por exceder limites.

Informações de pagamento aparecem em `fees` e `payments_url`. Relays podem cobrar por admissão (acesso único), assinatura (acesso recorrente) ou publicação (taxas por evento). O `payments_url` aponta para detalhes sobre métodos de pagamento, tipicamente faturas Lightning ou mints de ecash. Relays pagos usam esses campos para comunicar preços antes que clientes tentem autenticação.

O array `supported_nips` permite que clientes descubram capacidades do relay. Se um relay lista NIP-50, clientes sabem que podem enviar consultas de busca de texto completo. Se NIP-42 aparecer, clientes devem esperar desafios de autenticação. Esta publicidade declarativa de capacidade habilita aprimoramento progressivo: clientes podem usar recursos avançados onde disponíveis enquanto degradam graciosamente em relays com suporte limitado.

Informações do operador constroem responsabilidade. O campo `pubkey` identifica o operador do relay no Nostr, habilitando comunicação direta via DMs de NIP-17 ou menções públicas. O email de `contact` fornece um backup fora do protocolo. Juntos, esses campos ajudam usuários a alcançar operadores para relatórios de abuso, solicitações de acesso ou problemas técnicos.

Documentos NIP-11 são auto-relatados: relays descrevem o que alegam suportar, não necessariamente o que realmente fazem. É aqui que NIP-66 se torna importante.

NIP-66: Descoberta de Relay e Monitoramento de Disponibilidade

NIP-66 padroniza a publicação de dados de monitoramento de relay no Nostr. Serviços de monitoramento testam continuamente relays para disponibilidade, latência, conformidade com o protocolo e NIPs suportados. Eles publicam resultados como eventos kind 30166, fornecendo status de relay em tempo real independente do auto-relato do relay.

Monitores verificam disponibilidade do relay conectando e enviando assinaturas de teste. Medições de latência rastreiam tempo de conexão, tempo de resposta de assinatura e atraso de propagação de eventos. Testes de conformidade de protocolo verificam se o comportamento do relay corresponde às especificações, capturando bugs de implementação ou desvios intencionais. Verificação de suporte a NIP vai além das alegações de NIP-11 testando realmente se recursos anunciados funcionam corretamente.

```json { “id”: “a34b5c7d89e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7”, “pubkey”: “4e2d0bc6f8e7c3a5b9f1d2e3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4”, “created_at”: 1736784000, “kind”: 30166, “tags”: [ [“d”, “wss://relay.example.com”], [“rtt”, “open”, “143”, “1736784000”], [“rtt”, “read”, “89”, “1736784000”], [“rtt”, “write”, “92”, “1736784000”], [“nips”, “1”, “2”, “4”, “9”, “11”, “12”], [“geo”, “US”, “United States”, “New York”], [“other”, “network”, “clearnet”], [“other”, “payment_required”, “false”], [“other”, “auth_required”, “false”] ], “content”: “{\“last_check\”: 1736784000, \“checks\”: 8760}”, “sig”: “8b9c4d5e6a7f8b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b” } ```

A tag `d` contém a URL do relay, tornando este um evento substituível parametrizado. Cada monitor publica um evento por relay, atualizado conforme as medições mudam. Múltiplos monitores podem rastrear o mesmo relay, fornecendo redundância e validação cruzada. Clientes consultam múltiplas pubkeys de monitores para obter perspectivas diversas sobre a saúde do relay.

Tags de tempo de ida e volta (rtt) medem latência para diferentes operações. `rtt open` rastreia estabelecimento de conexão WebSocket, `rtt read` mede tempo de resposta de assinatura, e `rtt write` testa velocidade de publicação de eventos. Todos os valores estão em milissegundos. Clientes usam essas métricas para preferir relays de baixa latência para operações sensíveis ao tempo ou despriorizar relays lentos.

A tag `nips` lista suporte a NIP realmente verificado, não apenas suporte alegado. Monitores testam cada NIP exercitando sua funcionalidade. Se um relay alega busca NIP-50 em seu documento NIP-11 mas consultas de busca falham, monitores omitirão NIP-50 da lista verificada. Isso fornece verdade fundamental sobre capacidades do relay.

Informações geográficas ajudam clientes a selecionar relays próximos para melhor latência e resistência à censura. A tag `geo` contém código do país, nome do país e região. A tag `network` distingue relays clearnet de serviços ocultos Tor ou endpoints I2P. Juntas, essas tags habilitam diversidade geográfica: clientes podem se conectar a relays em múltiplas jurisdições para resistir à censura regional.

Dados de monitor alimentam seletores de relay em clientes, sites exploradores e a proposta Trusted Relay Assertions. Combinando documentos auto-relatados NIP-11 com dados medidos de NIP-66 e assertivas de confiança computadas, o ecossistema caminha para seleção informada de relay em vez de confiar em padrões codificados ou recomendações de boca a boca.

Lançamentos

0xchat v1.5.3 - Recursos de Mensagens Aprimorados

0xchat v1.5.3 traz melhorias significativas ao cliente de mensagens Nostr estilo Telegram. O lançamento aborda problemas de conformidade com NIP-55 (aplicativo assinador Android) que estavam impedindo assinatura adequada de eventos através de assinadores externos como Amber. Conformidade completa significa que 0xchat agora delega corretamente operações de assinatura, melhorando a segurança mantendo chaves privadas isoladas.

A atualização integra tanto FileDropServer quanto BlossomServer como opções de armazenamento de mídia padrão, dando aos usuários redundância para uploads de arquivo. Blossom fornece armazenamento endereçado por conteúdo onde arquivos são referenciados por seus hashes SHA-256, garantindo integridade e habilitando deduplicação através da rede. Salvamento automático de rascunho para Moments previne perda de dados ao compor conteúdo longo, abordando reclamações de usuários sobre posts perdidos durante trocas de aplicativo ou interrupções de conectividade.

Integração de carteira Cashu recebe polimento com filtragem automática de prova que remove tokens gastos da visualização da carteira. Isso resolve a UX confusa onde usuários viam provas inválidas ao lado de ecash válido, tornando cálculos de saldo não confiáveis. A filtragem acontece no lado do cliente, mantendo privacidade enquanto melhora a experiência de pagamento para transações peer-to-peer dentro de chats.

Amber v4.1.0 Pré-lançamentos - Reformulação de UI

Amber v4.1.0-pre1 até v4.1.0-pre3 introduzem uma interface redesenhada para o popular assinador de eventos Android. A tela de login agora exibe claramente qual aplicativo está solicitando permissões de assinatura, abordando confusão do usuário sobre fluxos de autorização. A nova tela de eventos fornece inspeção detalhada de quais dados aplicativos querem assinar, permitindo aos usuários tomar decisões de segurança informadas antes de aprovar operações.

Gerenciamento de permissões recebe atenção significativa com uma interface reformulada mostrando exatamente quais capacidades cada aplicativo conectado recebeu. Usuários podem revogar permissões específicas sem desconectar completamente, habilitando controle de granularidade fina sobre delegação de assinatura. Os contadores de relay refatorados usando a biblioteca quartz atualizada fornecem estatísticas em tempo real sobre throughput de eventos e desempenho do relay. Conexões bunker de NIP-46 (Nostr Connect) agora exibem mensagens de erro detalhadas quando conexões falham, substituindo erros de timeout crípticos por diagnósticos acionáveis.

Mudanças notáveis em código e documentação

Estes são pull requests mesclados e desenvolvimentos em estágio inicial que vale a pena acompanhar. Alguns são recursos experimentais que podem evoluir antes do lançamento.

Zeus (Carteira Lightning com Nostr Wallet Connect)

Zeus mesclou 17 pull requests esta semana, fortalecendo sua posição como implementação líder de NIP-47 Nostr Wallet Connect. As correções mais significativas abordam problemas de consistência de dados e conformidade de protocolo que estavam causando problemas de interoperabilidade com clientes Nostr.

Correção de Histórico de Transações - PR #3542 resolve um bug crítico onde listas de transações NWC exibiam entradas incorretas ou duplicadas. O problema ocorria quando Zeus armazenava em cache dados de transação sem lidar adequadamente com atualizações de eventos, fazendo usuários verem transações fantasma ou pagamentos faltando. A correção implementa deduplicação adequada de eventos e invalidação de cache, garantindo que o histórico de transações reflita com precisão o estado do nó Lightning.

Conformidade de Protocolo - PR #3548 aborda respostas incompletas de `getInfo` que quebravam compatibilidade com clientes esperando conformidade completa com NIP-47. Alguns clientes Nostr travavam ao receber respostas parciais faltando campos como `block_height` ou `network`. O PR garante que todos os campos obrigatórios retornem com padrões sensatos mesmo quando a implementação Lightning subjacente não os fornece, melhorando a compatibilidade do Zeus através do ecossistema.

Resiliência de Conexão - PR #3543 implementa notificações de timeout para conexões Nostr paralisadas. Anteriormente, usuários esperavam indefinidamente quando conexões de relay caíam silenciosamente. Agora Zeus exibe mensagens claras de timeout após 30 segundos de inatividade, permitindo aos usuários tentar novamente ou trocar relays. PR #3541 adiciona validação de backend para prevenir ativação de NWC em implementações Lightning incompatíveis, capturando erros de configuração antes que causem travamentos em tempo de execução.

Condição de Corrida Cashu - PR #3531 corrige um bug de concorrência no gerenciamento de tokens Cashu onde operações de mint simultâneas poderiam corromper o banco de dados de tokens. A condição de corrida ocorria quando múltiplas threads atualizavam contagens de tokens sem bloqueio adequado, ocasionalmente resultando em saldos incorretos. A correção adiciona proteção mutex ao redor de seções críticas, garantindo atualizações atômicas ao estado de token.

Primal Android (Cliente)

Primal Android entregou 12 PRs mesclados com melhorias significativas à segurança da carteira e manuseio de mídia. A implementação de backup de carteira aborda um dos recursos mais solicitados, enquanto suporte a NIP-92 melhora a experiência visual através do aplicativo.

Sistema de Backup de Carteira - Uma série de quatro PRs (#844, #845, #846, #848) implementa funcionalidade abrangente de backup de frase semente. Usuários agora podem exportar seu mnemônico de 12 palavras através de um fluxo seguro que previne capturas de tela, exibe status de backup no painel da carteira e guia usuários existentes através da migração. A implementação segue padrões BIP-39 e inclui validação para prevenir que usuários percam fundos devido à gravação incorreta de frases.

Dimensões de Mídia (NIP-92) - PR #718 implementa suporte a NIP-92 para proporções adequadas de imagem e vídeo. Sem metadados de dimensão, clientes devem baixar imagens para determinar seu tamanho, causando saltos de layout conforme o conteúdo carrega. NIP-92 adiciona tags `dim` (como `[“dim”, “1920x1080”]`) a eventos de metadados de arquivo, permitindo que Primal reserve espaço correto antes de baixar mídia. Isso elimina refluxos bruscos em galerias de imagem e melhora desempenho percebido.

Confiabilidade de Assinador Remoto - PR #841 corrige problemas de conexão NIP-46 onde prefixos `wss://` faltando causavam falhas silenciosas. O PR valida URIs de relay durante configuração de conexão bunker, adicionando o prefixo de protocolo automaticamente quando usuários colam domínios nus. PR #843 aborda um bug de threading onde condições de rede ruins causavam respostas a postar como notas raiz, quebrando fluxo de conversa. A correção garante que IDs de evento pai persistam através de interrupções de rede.

Protocolo Marmot: White Noise (Biblioteca de Chat de Grupo Criptografado)

White Noise, a biblioteca Rust alimentando chats de grupo criptografados do Marmot Protocol, mesclou seis PRs melhorando experiência do usuário e segurança. As mudanças aproximam Marmot da paridade de recursos com aplicativos de mensagens mainstream enquanto mantém sua arquitetura com privacidade em primeiro lugar.

Confirmações de Leitura - PR #433 e #436 implementam rastreamento de leitura de mensagens para conversas de grupo. O sistema armazena posições de leitura por usuário por grupo dentro de um único dispositivo, habilitando emblemas de contagem não lida. A implementação usa timestamps monotônicos para rastrear a última posição de mensagem lida para cada conversa. Este recurso fundamental habilita indicadores de UI mostrando contagens de mensagens não lidas por conversa.

Fixação de Conversa - PR #442 adiciona fixação de conversa persistente através de um campo `pin_order` na tabela de junção `accounts_groups` que liga contas a grupos. Conversas fixadas mantêm sua posição no topo de listas de chat independentemente de atividade de mensagem, correspondendo expectativas do usuário do Signal e WhatsApp. A implementação usa ordenação inteira para permitir fixações ilimitadas com ordenação determinística.

Resolução Determinística de Commit (MIP-03) - PR #152 (aberto) implementa Marmot Improvement Proposal 03, resolvendo o problema crítico de condições de corrida de commit em chats de grupo distribuídos. Quando múltiplos membros enviam mudanças de estado de grupo (adicionar/remover membros, mudar permissões) simultaneamente, clientes poderiam divergir na ordenação de commits, fragmentando o grupo em estados incompatíveis. MIP-03 introduz snapshots de época e uma seleção determinística de vencedor: o commit com o timestamp `created_at` mais cedo vence, com ID de evento lexicográfico como desempate. Isso permite que todos os clientes convirjam no mesmo estado através de rollback e replay, mantendo coerência de grupo mesmo durante partições de rede.

Endurecimento de Segurança - PR #443 previne cópia desnecessária de segredos criptográficos usando referências em `resolve_group_image_path`. Isso reduz a janela para ataques de memória onde segredos poderiam ser recuperados de alocações de heap liberadas. PR #438 habilita criptografia de banco de dados SQLCipher através de parâmetros de chaveiro, protegendo histórico de mensagens em repouso. A integração de chaveiro permite armazenamento seguro de chaves em chaveiros de plataforma em vez de arquivos de configuração.

nostrdb-rs (Biblioteca de Banco de Dados) - PR Aberto

Implementação de Consultas Streaming - PR #58 (aberto) propõe consultas fold streaming para habilitar operações de banco de dados com alocação zero. A implementação adiciona métodos `fold`, `try_fold`, `count`, `any`, `all` e `find_map` que processariam resultados de banco de dados um de cada vez sem materializar conjuntos de resultados inteiros em vetores. Esta abordagem reduziria consumo de memória e habilitaria terminação antecipada para padrões de consulta comuns.

A implementação técnica expõe callbacks de resultado de consulta de baixo nível (`ndb_query_visit`) como visitantes Rust com estado que mapeiam variantes `ControlFlow` para ações de visitante C. Uma vez mesclado, código de aplicação lerá como lógica de iterador enquanto roda perto da camada de banco de dados. Por exemplo, contar notas correspondentes transmitiria através de resultados em vez de coletá-los, e `find_map` retornaria o primeiro resultado útil sem processar linhas restantes.

nostrdb alimenta Damus e Notedeck, ambos clientes iOS/macOS e desktop respectivamente. As consultas streaming habilitariam padrões eficientes como paginação, filtragem condicional e verificações de existência. O PR muda 3 arquivos com +756 adições e -32 deleções, uma refatoração substancial da camada de consulta. Usuários de aplicativos baseados em nostrdb-rs veriam uso de memória reduzido ao navegar timelines grandes ou buscar através de bancos de dados extensos de eventos.

nak (Ferramenta CLI)

nak, ferramenta Nostr de linha de comando de fiatjaf, mesclou seis PRs focados em melhorias de sistema de build e nova funcionalidade. PR #91 implementa um recurso de espelho Blossom, permitindo que nak sirva como um espelho para servidores de mídia Blossom. Blossom é um protocolo de armazenamento de mídia endereçado por conteúdo que funciona junto com eventos Nostr.

Os PRs restantes abordam compatibilidade de sistema de build através de plataformas Windows, macOS e Linux, habilitando suporte a sistema de arquivos FUSE para montar eventos Nostr como diretórios locais.

Damus (Cliente iOS) - PRs Abertos

Damus tem 11 PRs abertos explorando melhorias arquiteturais significativas. Embora estes ainda não tenham sido mesclados, eles sinalizam direções importantes para desenvolvimento de cliente Nostr iOS, particularmente em torno de privacidade, eficiência de sincronização e otimização de dados móveis.

Integração Tor - PR #3535 embute o cliente Arti Tor diretamente no Damus, habilitando conexões de relay anônimas sem dependências externas. Diferente de abordagens Orbot ou Tor Browser, embutir Arti fornece integração perfeita com sandboxing iOS e limites de execução em segundo plano. A implementação Rust traz segurança de memória para anonimização de rede, reduzindo superfície de ataque comparada ao C Tor. Usuários poderiam alternar modo Tor por relay ou globalmente, com o cliente lidando com gerenciamento de circuito de forma transparente.

Protocolo de Sincronização Negentropy - PR #3536 implementa Negentropy, um protocolo de reconciliação de conjunto que melhora radicalmente a eficiência de sincronização. Em vez de baixar todos os eventos desde a última conexão, Negentropy troca impressões digitais compactas (árvores Merkle) para identificar exatamente quais eventos diferem entre cliente e relay. Para usuários seguindo centenas de pubkeys, isso reduz largura de banda de sincronização de megabytes para kilobytes. A implementação integra com RelayPool e SubscriptionManager, habilitando sincronização eficiente automática através de todos os relays conectados.

Modo de Dados Baixos - PR #3549 adiciona recursos de conservação de dados celulares respondendo a feedback de usuários sobre consumo de largura de banda. O modo desabilita carregamento automático de imagem, pré-busca de vídeo e reduz limites de assinatura. Usuários com conexões medidas podem navegar conteúdo de texto sem medo de exceder limites de dados. A implementação respeita configurações de modo de dados baixos do iOS e fornece controles granulares para diferentes tipos de mídia.

Otimizações de Banco de Dados - PR #3548 refaz armazenamento de snapshot nostrdb para consultas mais rápidas e uso de disco reduzido. A otimização muda como snapshots de banco de dados persistem em disco, melhorando tanto desempenho de leitura quanto amplificação de escrita. Isso aborda reclamações de drenagem de bateria de usuários com grandes bancos de dados de eventos.

É isso para esta semana. Construindo algo? Tem notícias para compartilhar? Quer que cubramos seu projeto? Entre em contato via DM NIP-17 ou nos encontre no Nostr.

Nostr Compass #5

Tue, 13 Jan 2026 00:00:00 +0000

Bem-vindo de volta ao Nostr Compass, seu guia semanal para o Nostr.

Esta semana: O Bitchat passa por uma auditoria de segurança profissional pela Cure53, a mesma empresa que auditou o Signal e o NIP-44, com mais de 17 PRs já mesclados corrigindo descobertas críticas. O NIP-71 é mesclado, trazendo eventos de vídeo endereçáveis para o protocolo. Um NIP de criptografia pós-quântica abre discussão sobre como preparar o Nostr para o futuro contra ataques quânticos. O Amethyst v1.05.0 lança listas de favoritos, notas de voz e uma versão inicial para desktop, enquanto o Nostur v1.25.3 melhora as DMs do NIP-17 com reações e respostas. Em notícias de bibliotecas, o rust-nostr expande o suporte ao NIP-62 para os backends SQLite e LMDB, e o NDK corrige um bug de rastreamento de assinaturas.

Notícias

Bitchat Conclui Auditoria de Segurança da Cure53

O Bitchat, o mensageiro criptografado para iOS que combina Nostr com Cashu, passou por uma auditoria de segurança profissional pela Cure53, uma das empresas de segurança mais respeitadas do setor. A Cure53 auditou anteriormente o Signal, o Mullvad VPN e, notavelmente, a especificação de criptografia NIP-44 que sustenta as mensagens privadas modernas do Nostr.

A auditoria encontrou mais de 12 problemas de segurança (BCH-01-002 até BCH-01-013). A equipe do Bitchat respondeu com mais de 17 pull requests. As principais correções incluem:

Limpeza de Segredo DH do Protocolo Noise - O PR #928 corrige seis locais onde os segredos compartilhados Diffie-Hellman não estavam sendo zerados após o acordo de chaves, restaurando as garantias de forward secrecy. Quando os segredos persistem na memória por mais tempo do que o necessário, um dump de memória ou ataque cold boot poderia comprometer comunicações passadas.

Verificação de Assinatura - Múltiplos PRs fortalecem os caminhos de verificação criptográfica, garantindo que as verificações de autenticidade das mensagens não possam ser contornadas através de entradas malformadas.

Thread Safety - O PR #929 adiciona sincronização de barreira às filas de confirmação de leitura no NostrTransport, prevenindo condições de corrida que poderiam causar corrupção de dados ou travamentos sob alto volume de mensagens.

Segurança de Memória - O PR #920 otimiza o deduplicador de mensagens para melhor desempenho com alto throughput de mensagens, evitando esgotamento de memória.

Validação de Entrada - O PR #919 fortalece a análise de strings hexadecimais para prevenir travamentos por entrada malformada, um vetor de ataque comum para negação de serviço.

O Bitchat lida com ecash Cashu, tornando a revisão de segurança profissional essencial. A auditoria segue a auditoria do Protocolo Marmot do ano passado e a auditoria do NIP-44 que verificou a camada de criptografia.

Atualizações de NIPs

Mudanças recentes no repositório de NIPs:

Mesclados:

NIP-71 - Eventos de Vídeo Endereçáveis (#1669) introduz os kinds 34235 (vídeo horizontal) e 34236 (vídeo vertical) como eventos endereçáveis. Uma tag d obrigatória fornece identificadores únicos, para que os metadados do vídeo possam ser atualizados sem republicar o evento inteiro. Uma tag origin opcional rastreia fontes de importação. Já implementado no Amethyst e nostrvine.

PRs Abertos:

Criptografia Pós-Quântica - O PR #2185 propõe adicionar algoritmos criptográficos resistentes a quantum ao Nostr. A especificação introduz ML-DSA-44 e Falcon-512 para assinaturas digitais, visando “eventos de valor super alto” como aplicações e autoridades, em vez de usuários individuais. Enquanto a criptografia simétrica do NIP-44 (ChaCha20) é resistente a quantum, sua troca de chaves usa secp256k1 ECDH que é vulnerável ao algoritmo de Shor. A proposta inclui ML-KEM para acordo de chaves para resolver essa lacuna. Esta é uma proposta em estágio inicial abrindo discussão sobre agilidade criptográfica para a segurança de longo prazo do Nostr.
BOLT12 para NIP-47 - Após 137 comentários e discussão extensiva, a comunidade decidiu que as ofertas BOLT12 merecem sua própria especificação em vez de estender o NIP-47. As ofertas BOLT12 fornecem melhorias significativas sobre faturas BOLT11, incluindo reutilizabilidade, melhor privacidade através de caminhos cegos e informações opcionais do pagador. O novo NIP definirá métodos como make_offer, pay_offer e list_offers para implementações do Nostr Wallet Connect.
NIP de Faixa de Áudio - O PR #1043 propõe kinds 32100 para faixas de música e 32101 para episódios de podcast, dando ao conteúdo de áudio o mesmo tratamento de primeira classe que o NIP-71 fornece para vídeo. Atualmente, plataformas de áudio como Wavlake, Zapstr e Stemstr usam formatos de eventos proprietários, fragmentando o ecossistema. Um padrão comum permitiria interoperabilidade para que os usuários pudessem descobrir e reproduzir áudio de qualquer cliente compatível.
NIP-A3 Alvos de Pagamento Universais - O PR #2119 propõe eventos kind 10133 usando URIs payto: RFC-8905 para expor opções de pagamento através de múltiplas redes. Em vez de criar kinds de eventos separados para Bitcoin, Lightning, Cashu ou trilhos de pagamento tradicionais, essa abstração permite que os clientes analisem tags padronizadas e invoquem manipuladores de pagamento nativos. A abordagem é à prova de futuro, já que novos métodos de pagamento precisam apenas de um esquema de URI payto:.

Aprofundamento em NIPs: NIP-51 e NIP-65

Esta semana cobrimos dois NIPs que armazenam preferências do usuário: NIP-51 para organizar conteúdo e NIP-65 para organizar conexões de relay. Ambos usam eventos substituíveis, o que significa que cada nova publicação sobrescreve a versão anterior.

NIP-51: Listas

O NIP-51 define múltiplos tipos de lista para organizar referências a eventos, usuários, hashtags e outros conteúdos. O Amethyst v1.05.0 adiciona suporte a favoritos, tornando este um bom momento para entender como as listas funcionam.

A especificação define vários kinds de lista, cada um servindo a um propósito diferente. O Kind 10000 é sua lista de silenciados para ocultar usuários, threads ou palavras. O Kind 10001 fixa eventos para destacar em seu perfil. O Kind 30003 armazena favoritos, que é o que o Amethyst agora suporta. Outros kinds lidam com conjuntos de seguidos (30000), coleções de artigos curados (30004), interesses de hashtags (30015) e conjuntos de emojis personalizados (30030).

As listas referenciam conteúdo através de tags. Uma lista de favoritos usa tags e para eventos específicos e tags a para conteúdo endereçável como artigos:

{
 "id": "ae3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1736784000,
 "kind": 30003,
 "tags": [
 ["d", "saved-articles"],
 ["e", "abc123def456...", "wss://relay.example"],
 ["a", "30023:author-pubkey:article-id", "wss://relay.example"]
 ],
 "content": "<encrypted-private-bookmarks>",
 "sig": "908a15e46fb4d8675bab026fc230a0e3542bfade63da02d542fb78b2a8513fcd0092619a2c8c1221e581946e0191f2af505dfdf8657a414dbca329186f009262"
}

A tag d fornece um identificador único, para que você possa manter múltiplos conjuntos de favoritos como “saved-articles”, “read-later” ou “favorites” sob o mesmo kind.

As listas suportam itens públicos e privados. Itens públicos aparecem no array de tags, visíveis para qualquer pessoa que busque o evento. Itens privados vão no campo content, criptografados usando NIP-44 para você mesmo. Essa estrutura dupla permite que você mantenha favoritos públicos enquanto anexa notas privadas, ou mantenha uma lista de silenciados sem revelar quem você silenciou. Para criptografar para você mesmo, use o NIP-44 com sua própria pubkey como destinatário.

Os kinds da série 10000 são substituíveis, o que significa que os relays mantêm apenas um evento por pubkey. Os da série 30000 são substituíveis parametrizados, permitindo um evento por combinação de pubkey e tag d. Em ambos os casos, atualizar uma lista significa publicar uma substituição completa; você não pode enviar mudanças incrementais. Os clientes devem preservar tags desconhecidas ao modificar listas para evitar sobrescrever dados adicionados por outras aplicações.

NIP-65: Metadados de Lista de Relays

O NIP-65 define eventos kind 10002 que anunciam quais relays um usuário prefere para leitura e escrita. Isso ajuda outros usuários e clientes a encontrar seu conteúdo.

{
 "id": "bd2217a96b5835b59f9a6a42d8d8a36f8c9b7d4e5f0a1b2c3d4e5f6a7b8c9d0e1",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1736784000,
 "kind": 10002,
 "tags": [
 ["r", "wss://relay.damus.io", "read"],
 ["r", "wss://nos.lol"],
 ["r", "wss://relay.nostr.band", "write"]
 ],
 "content": "",
 "sig": "f1c2d3e4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2"
}

Cada tag r contém uma URL de relay e um marcador opcional. Um marcador write designa sua outbox: relays onde você publica seu conteúdo. Um marcador read designa sua inbox: relays onde você verifica menções, respostas e tags. Omitir o marcador indica ambos.

Quando Alice quer encontrar os posts de Bob, seu cliente busca o kind 10002 de Bob, extrai seus relays de escrita (sua outbox) e se inscreve lá. Quando Alice responde a Bob, seu cliente publica em seus relays de leitura (sua inbox) para que ele veja a menção. Esse roteamento consciente de relays é o “modelo outbox”, e ele distribui os usuários entre muitos relays em vez de concentrar todos em poucos servidores centrais.

O NIP-65 lida com roteamento de conteúdo público, mas mensagens privadas usam uma lista separada. O NIP-17 define o kind 10050 para relays de inbox de DM, usando tags relay em vez de tags r. Ao enviar a alguém uma mensagem privada, os clientes procuram o evento kind 10050 do destinatário e publicam a mensagem gift-wrapped criptografada lá. Essa separação mantém o roteamento de DM distinto do roteamento de conteúdo público e permite que os usuários especifiquem relays diferentes para comunicação privada versus pública.

O modelo outbox melhora a resistência à censura, já que nenhum relay único precisa armazenar ou servir o conteúdo de todos. Os clientes mantêm conexões com relays listados nos eventos NIP-65 de seus usuários seguidos, conectando-se dinamicamente a novos relays conforme descobrem novas contas. O NIP-65 complementa as dicas de relay encontradas em outros NIPs. Quando você marca alguém com ["p", "pubkey", "wss://hint.relay"], a dica informa aos clientes onde procurar essa referência específica. O NIP-65 fornece a lista autoritativa controlada pelo usuário, enquanto as dicas oferecem atalhos incorporados em eventos individuais.

Para melhores resultados, mantenha sua lista de relays atualizada, já que entradas desatualizadas tornam você mais difícil de encontrar. A especificação recomenda de dois a quatro relays por categoria. Listar muitos relays sobrecarrega cada cliente que deseja buscar seu conteúdo, diminuindo sua experiência e aumentando a carga da rede. Os clientes armazenam em cache os eventos NIP-65 e os atualizam periodicamente para se manterem atualizados conforme os usuários atualizam suas preferências.

Lançamentos

Amethyst v1.05.0 - O popular cliente Android lança uma atualização importante com várias funcionalidades de destaque. As listas de favoritos NIP-51 kind 30003 permitem que os usuários salvem posts para referência posterior, sincronizando entre clientes compatíveis. As notas de voz agora funcionam em DMs e posts regulares com visualização de forma de onda, seleção de servidor de mídia e indicadores de progresso de upload. As pontuações de Web of Trust agora são visíveis na interface, ajudando os usuários a entender como o algoritmo avalia contas em relação ao seu grafo social. A migração do banco de dados Quartz melhora o desempenho de consultas como parte do trabalho de Kotlin Multiplatform financiado pela OpenSats. Uma versão inicial para desktop traz o Amethyst para Windows, macOS e Linux via Compose Multiplatform, compartilhando a mesma base de código do aplicativo Android. Novos fluxos de onboarding suavizam a experiência para usuários de primeira viagem no Nostr.

Nostur v1.25.3 - O cliente iOS e macOS foca em mensagens privadas com melhorias no NIP-17. As conversas de DM agora suportam reações e respostas, trazendo a interatividade dos posts públicos para mensagens criptografadas. A visualização de conversa foi reformulada com melhor threading para que trocas de múltiplas mensagens sejam mais fáceis de seguir, e os timestamps mostram “tempo atrás” na lista de DM para escaneamento rápido. Usuários de desktop ganham layouts de múltiplas colunas para visualizar múltiplos feeds ou conversas lado a lado. O suporte a assinante remoto NIP-46 permite que os usuários mantenham suas chaves privadas em aplicativos de assinatura dedicados como Amber ou nsec.app. Correções adicionais restauram a funcionalidade de DM no iOS 15 e iOS 16, resolvem atrasos de notificação e adicionam a capacidade de configurar quais relays recebem DMs publicadas.

Mudanças notáveis de código e documentação

Estes são pull requests abertos e trabalhos em estágio inicial, perfeitos para obter feedback antes de serem mesclados. Se algo chamar sua atenção, considere revisar ou comentar!

Citrine (Relay Android)

O PR #89 corrige uma vulnerabilidade de injeção SQL no aplicativo de relay pessoal para Android. O problema permitia que dados de eventos malformados executassem consultas arbitrárias ao banco de dados, uma falha séria para qualquer aplicativo que armazena e processa entrada não confiável. A correção sanitiza adequadamente todas as operações de banco de dados usando consultas parametrizadas. Nenhuma versão foi marcada ainda, então os usuários precisarão esperar pela próxima versão ou compilar a partir do código-fonte. O PR #90 otimiza o desempenho de consultas do ContentProvider com filtragem e paginação em nível de banco de dados, reduzindo a latência quando aplicativos externos como o Amethyst acessam o banco de dados de eventos do Citrine através da camada de comunicação entre processos do Android.

rust-nostr (Biblioteca)

O suporte ao NIP-62 (Vanish Requests) está se expandindo pelos backends de banco de dados do rust-nostr. O PR #1180, mesclado há duas semanas, adicionou suporte ao NIP-62 para SQLite, lidando com requisições vanish ALL_RELAYS já que a camada de banco de dados não conhece URLs de relay específicos. O PR #1210 estende isso para o backend LMDB, garantindo que as requisições vanish sejam persistidas no disco e sobrevivam a reinicializações do relay. Uma implementação IndexedDB para ambientes de navegador também está em andamento. Juntas, essas mudanças dão aos desenvolvedores suporte consistente ao NIP-62 através de SQLite, LMDB e em breve armazenamento de navegador.

NDK (Nostr Development Kit)

O PR #375 corrige um bug no sistema de rastreamento seenEvents. O problema fazia com que certos padrões de assinatura marcassem incorretamente eventos como já vistos, levando à perda de conteúdo quando os usuários abriam novas assinaturas ou reconectavam a relays. A correção garante que os eventos sejam rastreados com precisão ao longo dos ciclos de vida das assinaturas, o que é particularmente importante para aplicações que assinam e cancelam assinaturas dinamicamente com base na navegação do usuário. O NDK foi atualizado para beta.70 com essa correção incluída.

Damus (iOS)

O PR #3515 corrige um travamento de inicialização afetando usuários do iOS 17. O problema decorreu de um overflow aritmético em NdbUseLock, uma classe de fallback usada porque Swift Mutexes não estão disponíveis no iOS 17. A correção substitui a abordagem de sincronização anterior por NSLock, que está disponível no iOS 17 e lida corretamente com as condições de corrida restantes. Usuários do iOS 18+ não foram afetados, já que têm acesso à implementação nativa de Swift Mutex.

Separadamente, um lote de melhorias para artigos longos foi implementado via PR #3509. Barras de progresso de leitura rastreiam sua posição nos artigos, tempos estimados de leitura aparecem nas previews, e o modo sépia com configurações ajustáveis de altura de linha proporcionam leitura mais confortável. O modo de foco oculta automaticamente o chrome de navegação ao rolar para baixo e o restaura ao tocar, reduzindo a desordem visual para leitura sem distrações. Várias correções resolvem a exibição de imagens em conteúdo markdown e garantem que os artigos abram no topo em vez de no meio.

Zap.stream (Transmissão ao Vivo)

A integração de chat do YouTube e Kick faz ponte de mensagens de plataformas de streaming externas para o Nostr. Streamers que transmitem simultaneamente para YouTube, Kick e Zap.stream agora podem ver todas as mensagens de chat em uma visualização unificada, com mensagens de cada plataforma aparecendo ao lado de comentários nativos do Nostr. Isso remove um grande ponto de atrito para criadores que desejam usar o Nostr para streaming, mas não podem abandonar audiências em plataformas estabelecidas. A integração exibe de qual plataforma cada mensagem se originou e lida com o fluxo de autenticação para conectar contas externas.

Chachi (Grupos NIP-29)

O cliente de chat em grupo NIP-29 lançou seis PRs mesclados esta semana. Uma atualização de segurança resolve o CVE-2026-22029, uma vulnerabilidade XSS no react-router que poderia permitir ataques de redirecionamento aberto; a correção atualiza para react-router-dom 6.30.0. O PR #92 adiciona carregamento paginado de mensagens para chats em grupo, para que conversas longas carreguem incrementalmente em vez de todas de uma vez. O PR #91 corrige vários bugs do NIP-29 incluindo uma condição de corrida que causava nomes de grupo em branco no carregamento inicial e listas de participantes indefinidas que travavam as visualizações de membros. A cobertura de tradução agora abrange todos os 31 locales suportados com 1060 chaves cada.

0xchat (Mensagens)

O cliente de mensagens estilo Telegram melhorou a conformidade com o NIP-55 salvando corretamente os nomes de pacote do assinante ao usar aplicativos de assinatura externos, corrigindo problemas onde o aplicativo perdia o rastro de qual assinante usar após reinicializações. O tratamento de respostas do NIP-17 agora inclui corretamente a tag e para threading, garantindo que as respostas apareçam no contexto de conversa correto entre clientes. Otimizações de desempenho resolvem lag de rolagem em listas de mensagens, um ponto de dor comum ao carregar históricos de chat longos. O salvamento automático de rascunhos previne perda de mensagem se você navegar para longe no meio da composição, e as opções de armazenamento de arquivos agora incluem endpoints padrão de FileDropServer e BlossomServer.

Primal (iOS)

O suporte a assinante remoto NIP-46 chega ao iOS via PR #184, completando o lançamento multiplataforma que começou com Android há várias semanas. Os usuários agora podem manter suas chaves privadas em serviços bunker dedicados como nsec.app ou instâncias nsecBunker auto-hospedadas, conectando através de relays Nostr para assinar eventos sem expor chaves ao aplicativo cliente. Essa separação melhora a postura de segurança para usuários que desejam usar os recursos do Primal enquanto mantêm práticas de gerenciamento de chaves mais rigorosas. A implementação inclui escaneamento de código QR para URIs de conexão bunker e lida com o fluxo de requisição/resposta do NIP-46 através de mensagens de relay criptografadas.

É isso para esta semana. Construindo algo? Tem notícias para compartilhar? Quer que a gente cubra seu projeto? Entre em contato via DM NIP-17 ou nos encontre no Nostr.

Nostr Compass #4

Wed, 07 Jan 2026 00:00:00 +0000

Bem-vindo de volta ao Nostr Compass, seu guia semanal para o ecossistema do protocolo Nostr.

Esta semana: O Primal Android lança suporte para assinatura remota NIP-46 e assinatura local NIP-55, tornando-se um hub completo de assinatura para outros aplicativos Android. A equipe do Marmot Protocol abordou descobertas de uma auditoria de segurança com 18 PRs mesclados, fortalecendo a mensageria criptografada baseada em MLS. O Citrine atinge a v1.0 e o Applesauce lança a v5.0 em toda sua suíte de bibliotecas. O TENEX desenvolve supervisão de agentes de IA no Nostr, e o Jumble adiciona pooling inteligente de relays. Uma correção na especificação NIP-55 esclarece os campos de retorno do nip44_encrypt, e um PR do NIP-50 propõe extensões de expressões de consulta para busca avançada. Em nosso aprofundamento, explicamos NIP-04 e NIP-44: por que a criptografia legada tem falhas de segurança e como a substituição moderna as corrige.

Notícias

Primal Android se Torna um Hub Completo de Assinatura - A versão 2.6.18 adiciona tanto assinatura remota NIP-46 quanto assinatura local NIP-55, transformando o Primal em um assinador completo para outros aplicativos Nostr. A assinatura remota via NIP-46 permite que usuários se conectem a serviços bunker através de relays Nostr, mantendo as chaves completamente fora do dispositivo. A assinatura local via NIP-55 expõe o Primal como um provedor de conteúdo Android, para que aplicativos como Amethyst ou Citrine possam solicitar assinaturas sem nunca tocar na chave privada. Vários PRs de acompanhamento corrigiram problemas de compatibilidade com o requisito de pubkey hexadecimal da especificação NIP-55 e melhoraram o parsing de URIs nostrconnect:// malformadas. O lançamento também inclui pré-cache de mídia para rolagem mais suave, tempos de carregamento de threads aprimorados e pré-cache de avatares.

Marmot Protocol Fortalece Segurança Após Auditoria - O Marmot Development Kit (mdk), que implementa mensageria criptografada de ponta a ponta baseada em MLS do NIP-104, recebeu extensas correções de segurança esta semana. Dezoito pull requests mesclados abordaram descobertas da auditoria, incluindo: verificação de hash para imagens de grupo criptografadas para prevenir ataques de substituição de blob no nível de armazenamento, paginação para boas-vindas pendentes para prevenir esgotamento de memória, vazamento de Group ID MLS em mensagens de erro, e aplicação de codificação base64 para pacotes de chaves. A própria especificação Marmot foi atualizada com versionamento MIP-04 v2 e melhorias de segurança. PRs ativos continuam abordando reutilização de nonce, zeroização de segredos e vetores de poluição de cache.

Nostrability Rastreia Suporte a Relay Hints - Um novo rastreador de compatibilidade de relay hints documenta como os clientes constroem e consomem relay hints em todo o ecossistema. O rastreador revela que, embora a maioria dos clientes agora construa hints conforme o NIP-10 e NIP-19, o consumo varia amplamente: alguns clientes incluem hints em eventos de saída, mas não usam hints de entrada para busca. Seis clientes ganharam status de nível “Completo” por implementação completa. O rastreador é útil para desenvolvedores verificando interoperabilidade e para usuários se perguntando por que alguns clientes encontram conteúdo que outros não conseguem.

Nostria 2.0 Lança Reformulação de Recursos Multiplataforma - O cliente Nostria lançou a versão 2.0 em 30 de dezembro com adições significativas em iOS (TestFlight), Android (Play Store), Web e Windows. O lançamento adiciona suporte nativo a música com criação de playlists, upload de faixas, pagamentos de artistas via zap e um player estilo WinAmp com equalizador funcional. Transmissões ao vivo ganham integração com Game API mostrando metadados ricos durante streams de gameplay. Um novo recurso de Resumo gera digestos de atividade por hora, dia ou semana como visualizações de timeline comprimidas. A seção Descobrir oferece listas curadas para encontrar conteúdo e perfis. A publicação de mídia é simplificada com geração automática de posts curtos para descoberta entre clientes. Conexões com assinadores remotos agora funcionam via escaneamento de QR code sem configuração manual. A descoberta de perfis aborda um problema comum do Nostr: quando usuários migram entre relays sem trazer seus metadados, o Nostria localiza seu perfil e o republica nos relays atuais. Assinantes premium ganham integração com canais do YouTube, Memos privados, painéis de análise e backups automáticos de lista de seguidos com opções de mesclagem/restauração.

Atualizações de NIPs

Mudanças recentes no repositório de NIPs:

Mesclados:

NIP-55 - Corrigido o campo de retorno para o método nip44_encrypt (#2184). Assinadores Android agora devem retornar o payload criptografado no campo signature (correspondendo ao nip44_decrypt) em vez de um campo separado. Isso alinha a especificação com implementações existentes no Amber e Primal.

PRs Abertos:

NIP-50 - Extensões de Expressões de Consulta (#2182) propõe estender a busca do NIP-50 com expressões de consulta estruturadas. O PR adiciona operadores como kind:1, author:npub1... e combinações booleanas (AND, OR, NOT), permitindo consultas de busca mais precisas além da simples correspondência de texto. Isso permitiria que clientes construíssem interfaces de busca avançada mantendo compatibilidade com strings de busca básicas.

Aprofundamento em NIPs: NIP-04 e NIP-44

Esta semana cobrimos os padrões de criptografia do Nostr: o legado NIP-04 que você ainda encontrará, e sua substituição moderna NIP-44 que corrige falhas críticas de segurança.

NIP-04: Mensagens Diretas Criptografadas (Legado)

O NIP-04 foi a primeira tentativa do Nostr de mensageria criptografada, usando eventos kind 4. Embora simples de implementar, possui fraquezas de segurança conhecidas e está deprecado em favor do NIP-44.

Como funciona: O NIP-04 usa ECDH (Elliptic Curve Diffie-Hellman) para derivar um segredo compartilhado entre remetente e destinatário, depois criptografa com AES-256-CBC.

{
 "id": "<event-id>",
 "pubkey": "<sender-pubkey>",
 "created_at": 1736200000,
 "kind": 4,
 "tags": [["p", "<recipient-pubkey>"]],
 "content": "base64-ciphertext?iv=base64-iv",
 "sig": "<signature>"
}

O fluxo de criptografia:

Computar ponto compartilhado: shared = ECDH(sender_privkey, recipient_pubkey)
Derivar chave: key = SHA256(shared_x_coordinate)
Gerar IV aleatório de 16 bytes
Criptografar: ciphertext = AES-256-CBC(key, iv, plaintext)
Formatar conteúdo: base64(ciphertext)?iv=base64(iv)

Problemas de segurança:

Sem autenticação: AES-CBC fornece confidencialidade mas não integridade. Um atacante que controla um relay poderia modificar bits do ciphertext, causando mudanças previsíveis no plaintext (ataques de bit-flipping).
IV em claro: O vetor de inicialização é transmitido junto com o ciphertext, e o modo CBC com IVs previsíveis permite ataques de plaintext escolhido.
Sem validação de padding: Implementações variam em como lidam com padding PKCS#7, potencialmente permitindo ataques de padding oracle.
Exposição de metadados: A pubkey do remetente, pubkey do destinatário e timestamp são todos visíveis para os relays.
Reutilização de chave: O mesmo segredo compartilhado é usado para todas as mensagens entre duas partes, para sempre.

Por que ainda existe: Muitos clientes e relays mais antigos suportam apenas NIP-04. Você o encontrará ao interagir com sistemas legados. Assinadores como Amber e aplicativos como Primal ainda implementam nip04_encrypt/nip04_decrypt para compatibilidade retroativa.

NIP-44: Criptografia Versionada

O NIP-44 é o padrão moderno de criptografia, projetado para corrigir as falhas conhecidas do NIP-04. Uma auditoria de segurança da Cure53 das implementações do NIP-44 identificou 10 problemas (incluindo ataques de timing e preocupações com forward secrecy) que foram abordados antes da especificação ser finalizada. Ele usa ChaCha20-Poly1305 com derivação de chave adequada e criptografia autenticada.

Principais melhorias sobre o NIP-04:

Aspecto	NIP-04	NIP-44
Cifra	AES-256-CBC	XChaCha20-Poly1305
Autenticação	Nenhuma	MAC Poly1305
Derivação de chave	SHA256(shared_x)	HKDF com salt
Nonce	IV de 16 bytes, padrão reutilizado	Nonce aleatório de 24 bytes
Padding	PKCS#7 (vaza tamanho)	Preenchido para potência de 2
Versionamento	Nenhum	Prefixo de byte de versão

Fluxo de criptografia:

Chave de conversa: Deriva uma chave estável para cada par remetente-destinatário:

shared_x = ECDH(sender_privkey, recipient_pubkey).x
conversation_key = HKDF-SHA256(
 ikm = shared_x,
 salt = "nip44-v2",
 info = ""
)

Chaves de mensagem: Para cada mensagem, gera um nonce aleatório de 32 bytes e deriva chaves de criptografia/autenticação:

keys = HKDF-SHA256(
 ikm = conversation_key,
 salt = nonce,
 info = "nip44-v2"
)
chacha_key = keys[0:32]
chacha_nonce = keys[32:44]
hmac_key = keys[44:76]

Preencher plaintext: Preenche até a próxima potência de 2 (mínimo 32 bytes) para ocultar o tamanho da mensagem:
```
padded = [length_u16_be] + [plaintext] + [zeros até próxima potência de 2]
```

Criptografar e autenticar:

ciphertext = XChaCha20(chacha_key, chacha_nonce, padded)
mac = HMAC-SHA256(hmac_key, nonce + ciphertext)

Formatar payload:

payload = [version=0x02] + [nonce] + [ciphertext] + [mac]
content = base64(payload)

Byte de versão: O primeiro byte (0x02) indica a versão da criptografia. Isso permite atualizações futuras sem quebrar mensagens existentes. A versão 0x01 foi um rascunho anterior que nunca foi amplamente implantado.

Descriptografia:

Decodificar base64, verificar se o byte de versão é 0x02
Extrair nonce (bytes 1-32), ciphertext e MAC (últimos 32 bytes)
Derivar chave de conversa usando a chave privada do destinatário e a chave pública do remetente
Derivar chaves de mensagem a partir da chave de conversa e nonce
Verificar MAC antes de descriptografar (rejeitar se inválido)
Descriptografar ciphertext, extrair prefixo de tamanho, retornar plaintext sem padding

Propriedades de segurança:

Criptografia autenticada: O MAC Poly1305 garante que qualquer adulteração seja detectada antes da descriptografia
Forward secrecy (parcial): Cada mensagem usa um nonce único, então comprometer uma mensagem não revela outras. No entanto, comprometer uma chave privada ainda revela todas as mensagens passadas (sem ratcheting).
Ocultação de tamanho: Padding para potência de 2 obscurece o tamanho exato da mensagem
Resistência a ataques de timing: Comparação em tempo constante para verificação de MAC

Uso na prática: O NIP-44 é a camada de criptografia para:

Mensagens diretas privadas do NIP-17 (dentro do gift wrap)
Comunicação com assinador remoto do NIP-46
Criptografia de seal do NIP-59
Mensagens de grupo do Marmot Protocol, onde o NIP-44 envolve conteúdo criptografado por MLS usando uma chave derivada do segredo exportador MLS
Qualquer aplicação que necessite criptografia segura ponto a ponto

Orientação de migração: Novos aplicativos devem usar NIP-44 exclusivamente. Para compatibilidade retroativa, verifique se o cliente de um contato suporta NIP-44 (via metadados de app do NIP-89 ou suporte do relay) antes de recorrer ao NIP-04. Ao receber mensagens, tente primeiro a descriptografia NIP-44, depois recorra ao NIP-04 para conteúdo legado.

Lançamentos

Primal Android v2.6.18 - O lançamento completo adiciona assinatura remota NIP-46 e assinatura local NIP-55, transformando o Primal em um hub de assinatura para outros aplicativos Android. Melhorias de desempenho incluem pré-cache de mídia, pré-cache de avatares e carregamento mais rápido de threads. Correções de bugs abordam auto-menções em bios, crashes na galeria de mídia e fallbacks de título de stream. No iOS, o Primal usa reprodução de áudio em segundo plano para manter o aplicativo ativo para receber solicitações de assinatura NIP-46; usuários podem alterar o som ou silenciá-lo completamente nas configurações.

Mostro v0.15.6 - O último lançamento da plataforma de negociação P2P de Bitcoin NIP-69 completa a implementação do fundo de desenvolvimento com eventos de auditoria da Fase 4. Pagamentos de taxa de desenvolvimento agora são rastreados via eventos Nostr kind 38383 publicados após cada pagamento bem-sucedido, permitindo verificação de terceiros e análises. Os cálculos de valores foram corrigidos para mensagens de comprador/vendedor, e a lógica de premium foi alinhada com a implementação de referência do lnp2pbot.

Aegis v0.3.5 - O assinador multiplataforma adiciona modo escuro, exibição melhorada de ícones de aplicativo e layouts de UI mais limpos. Correções de bugs abordam conflitos com o iCloud Private Relay do iOS e problemas de parsing de eventos. O lançamento também melhora como o JSON de eventos é passado para a função de assinatura Rust.

Citrine v1.0.0 - O aplicativo de relay Android atinge a versão 1.0. O Citrine permite executar um relay Nostr pessoal diretamente no seu dispositivo Android, útil para cache local, backup ou como complemento NIP-55. Este lançamento adiciona um handler de relatório de crash, melhora a eficiência de consultas ao banco de dados e atualiza traduções via Crowdin.

Applesauce v5.0.0 - A suíte de bibliotecas TypeScript do hzrd149 lança uma versão major com breaking changes focadas em correção e simplicidade. O pacote core agora verifica assinaturas de eventos por padrão e renomeia métodos de coordenadas para usar terminologia mais clara de “address” (parseCoordinate -> parseReplaceableAddress). O pacote relay reduz tentativas padrão de 10 para 3 e ignora relays inalcançáveis por padrão, além de adicionar createUnifiedEventLoader para busca de eventos simplificada. O pacote wallet ganha descoberta de mint Cashu do NIP-87. Dependências diretas do nostr-tools foram removidas dos pacotes, reduzindo tamanho do bundle e conflitos de versão.

Mudanças notáveis de código e documentação

Estes são pull requests abertos e trabalho em estágio inicial, perfeitos para obter feedback antes de serem mesclados. Se algo chamar sua atenção, considere revisar ou comentar!

Damus (iOS)

Uma série de PRs melhora a experiência de artigos longos. Melhorias de UX de leitura adicionam uma barra de progresso, tempo estimado de leitura, modo sépia, altura de linha ajustável e modo de foco que oculta a navegação durante a rolagem. Correções de imagem garantem que imagens em conteúdo markdown sejam exibidas com proporções adequadas, pré-processando imagens isoladas como elementos de nível de bloco. Cards de preview de artigos longos substituem texto inline @naddr1... por cards de preview ricos mostrando título e metadados do artigo. Uma nova suíte de testes de integração de relay adiciona 137 testes relacionados à rede, incluindo verificação do protocolo NIP-01 e comportamento sob condições de rede degradadas (simulação 3G).

Bitchat (Mensageria Criptografada)

Fortalecimento de segurança no mensageiro iOS Nostr+Cashu. Limpeza de segredo DH do protocolo Noise corrige seis locais onde segredos compartilhados não estavam sendo zerados após acordo de chave Diffie-Hellman, restaurando garantias de forward secrecy. Thread safety para filas de confirmação de leitura adiciona sincronização de barreira para prevenir condições de corrida no NostrTransport. Otimização do deduplicador de mensagens melhora o desempenho com altos volumes de mensagens, e hardening de parsing de string hexadecimal previne crashes de entrada malformada.

Frostr (Assinatura por Threshold)

O protocolo de assinatura por threshold baseado em FROST adicionou exibição de QR code para credenciais de grupo e credenciais de share durante o onboarding e na interface do assinador. Isso permite configuração mais fácil ao distribuir shares de chave entre múltiplos dispositivos, permitindo que usuários escaneiem credenciais em vez de copiar manualmente strings longas.

Marmot mdk (Biblioteca)

Além das correções de segurança mencionadas acima, PRs ativos abordam descobertas restantes da auditoria: Tipo Secret para zeroização introduz um tipo wrapper que automaticamente zera dados sensíveis ao ser descartado, paginação de consulta de mensagens previne esgotamento de memória ao carregar histórico de chat, e armazenamento criptografado adiciona criptografia em repouso para o banco de dados SQLite que armazena estado do grupo e mensagens.

Amethyst (Android)

Uma semana movimentada de correções de estabilidade no cliente Android. Parsing JSON leniente previne crashes de eventos malformados tornando a serialização Kotlin mais tolerante. A validação de eventos agora verifica o tamanho do campo kind antes do processamento para evitar exceções de valores oversized. A UI de score de confiança ganhou um ícone menor para reduzir interferência visual, e logging de erros melhorado ajuda a diagnosticar problemas de conexão com relays. Atualizações de tradução chegaram via Crowdin, e vários avisos do SonarQube foram tratados.

TENEX (Agentes de IA)

O framework de agentes de IA nativo do Nostr teve 81 commits esta semana desenvolvendo capacidades autônomas. O novo sistema de supervisão de agentes implementa heurísticas comportamentais para monitorar ações de agentes e intervir quando necessário. Transparência de delegação adiciona logging de intervenção do usuário aos transcripts de delegação, para que usuários possam auditar o que os agentes fizeram em seu nome. O registro de provedores LLM foi modularizado para integração mais fácil de diferentes backends de IA. Suporte a conversas entre projetos permite que agentes mantenham contexto através de múltiplos projetos baseados em Nostr.

Jumble (Cliente Web)

O cliente web focado em relays adicionou várias melhorias de experiência do usuário. Pool de relay inteligente gerencia conexões de forma inteligente com base em padrões de uso. Toggle de feed ao vivo permite que usuários alternem entre streaming em tempo real e atualização manual. Auto-mostrar novas notas no topo exibe conteúdo fresco sem exigir recarregamento da página. Cache persistente para feed de seguidos e notificações melhora os tempos de carregamento em visitas de retorno. Usuários agora podem alterar relays padrão através das configurações.

Isso é tudo para esta semana. Está construindo algo? Tem notícias para compartilhar? Quer que cobramos seu projeto? Entre em contato via DM NIP-17 ou nos encontre no Nostr.

Nostr Compass #3

Wed, 31 Dec 2025 00:00:00 +0000

Bem-vindo de volta ao Nostr Compass, seu guia semanal do ecossistema do protocolo Nostr.

Esta semana: Ao encerrar 2025, olhamos para trás para cinco anos de marcos de dezembro na evolução do Nostr. Desde o primeiro lançamento do cliente de fiatjaf em dezembro de 2020, passando pela doação fundamental de Jack Dorsey de 14 BTC em dezembro de 2022, até a proliferação de NIP-55 signer este mês e a aceleração de cache de 162x do NDK, dezembro consistentemente marcou pontos de virada para o protocolo. Esta edição especial traça a história técnica através de cada dezembro, documentando o crescimento do protocolo de dois relays experimentais para mais de 2.500 nós em 50 países. Além disso: O módulo desktop do Amethyst toma forma através do Quartz, Notedeck ganha mensagens, Citrine hospeda aplicações web, e NIP-54 corrige a internacionalização para scripts não latinos.

Resumo de Dezembro: Cinco Anos de Dezembros do Nostr

Nostr completa cinco anos este ano. fiatjaf iniciou o protocolo em 7 de novembro de 2020, e cada dezembro desde então marcou uma fase distinta em sua evolução: de prova de conceito a movimento global a ecossistema de produção. Este é um retrospectivo técnico de dezembro de 2020 até dezembro de 2025, os anos formativos que estabeleceram a fundação do Nostr e catalisaram seu momento de explosão.

Dezembro 2020: Gênese

O primeiro mês completo de existência do Nostr viu fiatjaf lançar Branle, o primeiro cliente do protocolo, construído com Quasar (Vue.js) e absurd-sql para armazenamento local. fiatjaf já havia estabelecido a arquitetura central: usuários identificados por chaves públicas secp256k1, todas as postagens assinadas criptograficamente, relays servindo como armazenamento simples que não se comunicam entre si. Um ou dois relays experimentais serviam um punhado de primeiros adotantes coordenando no grupo do Telegram @nostr_protocol, que foi lançado em 16 de novembro. A documentação original descrevia “o protocolo aberto mais simples que é capaz de criar uma rede social global resistente à censura”, uma premissa que levaria mais dois anos para ser provada.

Dezembro 2021: Desenvolvimento Inicial

Em 31 de dezembro de 2021, Nostr chegou à primeira página do Hacker News com 110 pontos e 138 comentários, submetido por Cameri. Isso marcou a primeira exposição significativa do protocolo à comunidade mais ampla de desenvolvedores. A rede funcionava com aproximadamente sete relays com menos de 1.000 usuários. Branle recebeu atualizações incluindo importação de chave privada (31 de dezembro) e suporte multi-relay. Um cliente de linha de comando, noscl, fornecia interação baseada em terminal. As especificações do protocolo existiam na documentação de fiatjaf, embora o repositório formal de NIPs não fosse criado até maio de 2022. O protocolo era, como fiatjaf descreveu, “um trabalho em progresso”.

Dezembro 2022: O Ponto de Virada

Dezembro de 2022 transformou Nostr de um experimento de nicho em um movimento mainstream. O catalisador veio em 15 de dezembro, quando Jack Dorsey doou 14.17171699 BTC (~$245.000-$250.000) para fiatjaf após descobrir o protocolo e declarar que era “100 por cento o que queríamos do Bluesky, mas não foi desenvolvido por uma empresa”. Em 16 de dezembro, fiatjaf anunciou a divisão de fundos com o desenvolvedor do Damus William Casarin (jb55), e Dorsey verificou sua conta Nostr (npub: npub1sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m). O financiamento legitimou o projeto da noite para o dia.

Na mesma semana, o caos do Twitter acelerou a adoção. De 14 a 15 de dezembro houve suspensões de jornalistas proeminentes do New York Times, CNN e Washington Post. Em 18 de dezembro, o Twitter anunciou banimentos de contas promovendo Nostr, Mastodon e outras plataformas. A política foi revertida no dia seguinte após reação negativa. O êxodo levou os usuários a explorar alternativas.

O desenvolvimento do protocolo acelerou. Em 16 de dezembro, NIP-19 foi mesclado (#57), introduzindo identificadores codificados em bech32 (npub, nsec, note, nprofile, nevent) que tornavam as chaves legíveis por humanos e distinguíveis. O repositório de NIPs registrou mais de 36 commits naquele mês, incluindo atualizações de NIP-40 e NIP-07. Os clientes proliferaram: Damus preencheu seu beta TestFlight em horas, Astral bifurcou Branle para criação de perfis, Snort foi lançado como um cliente web “rápido e resistente à censura”, e Vitor Pamplona começou o desenvolvimento do Amethyst. Alby v1.22.1 “Kemble’s Cascade of Stars” foi lançado em 22 de dezembro com suporte a NIP-19. Até 7 de dezembro, Nostr tinha aproximadamente 800 usuários com perfis; quando Damus chegou à App Store em 31 de janeiro de 2023, as comportas se abriram, impulsionando o crescimento para mais de 315.000 usuários até junho de 2023.

Dezembro 2023: Maturação do Ecossistema

Dezembro de 2023 marcou um ponto de inflexão crítico para a segurança do protocolo Nostr. Em 20 de dezembro, a revisão 3 do NIP-44 foi mesclada após uma auditoria de segurança independente da Cure53 (NOS-01) que identificou 10 problemas nas implementações TypeScript, Go e Rust, incluindo ataques de timing e preocupações de forward secrecy. A especificação atualizada substituiu a criptografia defeituosa do NIP-04 por ChaCha20 e HMAC-SHA256, estabelecendo a fundação criptográfica que agora sustenta os DMs privados do NIP-17 e o gift wrapping do NIP-59. Na mesma semana, OpenSats anunciou sua quarta onda de grants em 21 de dezembro, financiando sete projetos incluindo Lume, noStrudel, ZapThreads, e uma auditoria independente do NIP-44. Isso seguiu a primeira onda em julho de 2023 que havia financiado Damus, Coracle, Iris, e outros, trazendo a alocação total do Fundo Nostr para aproximadamente $3,4 milhões através de 39 grants.

O mês também expôs tensões de sustentabilidade no ecossistema. Em 28 de dezembro, William Casarin (jb55) postou no Stacker News que 2024 seria “provavelmente o último ano do Damus”, citando que “clientes nostr não geram dinheiro” após as restrições da Apple sobre zaps in-app limitarem severamente o potencial de receita. A equipe do Damus havia anteriormente rejeitado financiamento de VC. Enquanto isso, Nostr Wallet Connect v0.4.1 foi lançado em 26 de dezembro, estendendo NIP-47 com métodos pay_keysend, make_invoice, lookup_invoice, list_transactions, get_balance, e get_info, preparando o terreno para as integrações de wallets que se tornariam padrão em todos os clientes.

Dezembro 2024: Avanço do Protocolo

Dezembro de 2024 abriu com o lançamento Alpha do Notedeck em 30 de novembro, o cliente desktop baseado em Rust da equipe Damus com uma interface multi-coluna com suporte para múltiplas contas. Construído para Linux, macOS e Windows (Android planejado para 2025), Notedeck foi inicialmente enviado para assinantes do Damus Purple e representou uma expansão estratégica além do iOS. Duas semanas depois, OpenSats anunciou sua nona onda de grants em 16 de dezembro, financiando AlgoRelay (o primeiro relay algorítmico para feeds personalizados), Pokey (app Android com mesh Bluetooth para internet restrita), Nostr Safebox (armazenamento de tokens Cashu com NIP-60), e LumiLumi (cliente web leve e acessível), levando a alocação total do Fundo Nostr para aproximadamente $9 milhões, um aumento de 67% ano a ano.

O mês viu maturação significativa de clientes em todo o ecossistema. Gossip 0.13.0 chegou em 23 de dezembro com suporte a File Metadata (NIP-92/NIP-94), integração Blossom, e busca em relay com NIP-50. Coracle 0.5.0 foi lançado em 12 de dezembro com onboarding reformulado e integração nostr-editor. O desenvolvimento do protocolo permaneceu ativo com 30 pull requests submetidos entre 9 e 22 de dezembro (10 mesclados), incluindo reescritas do NIP-46 para usar apenas criptografia NIP-44 e trabalho contínuo no NIP-104 para criptografia double ratchet no nível do Signal. Estatísticas de rede mostraram mais de 224.000 eventos diários de pubkeys confiáveis, crescimento de 4x ano a ano em novos perfis com listas de contatos, e um aumento de 50% em eventos de escrita pública.

Dezembro 2025: Expansão do Ecossistema

Dezembro de 2025 trouxe maturação contínua do protocolo e expansão do ecossistema. Em 21 de dezembro, OpenSats anunciou sua décima quarta onda de grants Nostr, financiando três projetos: YakiHonne (um cliente multiplataforma com portal de criadores para conteúdo de formato longo e integração de pagamentos Cashu/Nutzaps), Quartz (biblioteca Kotlin Multiplatform de Vitor Pamplona que alimenta Amethyst e permitirá uma versão iOS), e Nostr Feedz (integração bidirecional RSS-para-Nostr por PlebOne). Renovações de grants foram para Dart NDK e nostr-relay de Mattn.

A evolução do protocolo continuou com NIP-BE (mensagens Bluetooth Low Energy, #1979) mesclado em novembro, habilitando sincronização offline de dispositivos. NIP-A4 (Mensagens Públicas, kind 24, #1988) chegou mais tarde no mês, definindo mensagens de tela de notificação que usam tags q para evitar complicações de threading. NIP-29 recebeu grande clarificação (#2106), introduzindo a tag hidden para grupos verdadeiramente privados e não descobríveis. A especificação do NIP-55 também viu refinamento (#2166), abordando um erro comum de implementação onde desenvolvedores chamavam get_public_key de processos em segundo plano.

No lado do cliente, Primal Android se tornou um signer NIP-55 completo através de oito PRs mesclados implementando LocalSignerContentProvider, juntando-se a Amber e Aegis como opções de assinatura no Android. A biblioteca NDK alcançou consultas de cache 162x mais rápidas (de ~3.690ms para ~22ms) eliminando escritas duplicadas e buscas desnecessárias de cache LRU (PR #371, PR #372). Shopstr introduziu Zapsnags para vendas relâmpago via zaps. White Noise lançou notificações push que preservam a privacidade com MIP-05. Veja Newsletter #1 e Newsletter #2 para cobertura completa.

Cinco anos atrás, fiatjaf lançou Branle para um punhado de usuários através de dois relays experimentais. Hoje, o protocolo suporta mais de 140 clientes, mais de 2.500 relays em 50 países, e uma crescente rede de confiança ligando centenas de milhares de keypairs. O padrão de dezembro de grandes lançamentos continuou este mês com mensagens Bluetooth, proliferação de signers no Android, e grants de infraestrutura sinalizando investimento sustentado em ferramentas multiplataforma.

Notícias

Amethyst Desktop Toma Forma - O grant do Quartz da décima quarta onda do OpenSats já está produzindo resultados. PR #1625 cria um módulo :desktopApp completo para Amethyst usando Compose Multiplatform, com telas de login e feed global funcionais no Desktop JVM. A arquitetura converte o módulo :commons para Kotlin Multiplatform com uma estrutura de source set limpa (commonMain, jvmAndroid, androidMain, jvmMain), permitindo componentes de UI compartilhados entre Android e desktop enquanto deixa decisões específicas de plataforma para cada target. Isso estabelece a fundação para a eventual versão iOS através da mesma abordagem Kotlin Multiplatform.

Amethyst Respostas de Voz - Uma entrega de Natal de davotoula: PR #1622 adiciona telas dedicadas de resposta de voz com visualização de forma de onda, suporte para regravar, seleção de servidor de mídia, e indicadores de progresso de upload. Usuários agora podem responder tanto a mensagens de voz raiz quanto a respostas de voz com áudio.

Notedeck Adiciona Mensagens - Notedeck, o cliente desktop do Damus, ganhou um recurso de mensagens em PR #1223, expandindo além da navegação do timeline para comunicação direta.

Citrine Hospeda Aplicações Web - Citrine agora pode hospedar aplicações web, transformando seu telefone em um servidor web Nostr local-first. Um PR #85 separado adiciona reconexão automática e broadcasting de eventos quando a conectividade de rede retorna, com cobertura de testes abrangente através dos níveis de API do Android.

Registro de Kits de Desenvolvimento Nostrability - O rastreador de Developer Kits & Tooling mantém um registro curado de SDKs, bibliotecas e ferramentas de desenvolvimento através de linguagens (TypeScript, Rust, Python, Go, Dart, Swift, e mais). Se você é novo no desenvolvimento Nostr, este é um ponto de partida útil para encontrar o toolkit certo para seu stack.

Atualizações de NIPs

Mudanças recentes no repositório de NIPs:

NIP-54 - Correção crítica de internacionalização para normalização de d-tag wiki (#2177). Regras anteriores convertiam todos os caracteres não ASCII para -, quebrando suporte para japonês, chinês, árabe, cirílico e outros scripts. A especificação atualizada preserva letras UTF-8, aplica minúsculas apenas a caracteres com variantes de maiúsculas, e inclui exemplos abrangentes: "ウィキペディア" permanece "ウィキペディア", "Москва" se torna "москва", e scripts mistos como "日本語 Article" normalizam para "日本語-article".

Lançamentos

Zapstore 1.0-rc1 - A loja de aplicativos sem permissões baseada em Nostr lança o primeiro release candidate de sua nova arquitetura, apresentando uma atualização completa de UI, gerenciador de pacotes reescrito com melhor tratamento de erros, App Stacks para descoberta curada, telas de perfil redesenhadas, verificação de atualizações em segundo plano, e rolagem infinita em listas de lançamentos.

KeyChat v1.38.1 - O app de mensagens criptografadas baseado em MLS adiciona suporte UnifiedPush para notificações push de Android e Linux, mais autenticação biométrica para operações de privacidade. Disponível para Android, Windows, macOS e Linux.

Alby Go v2.0.0 - O companheiro de wallet Lightning móvel lança um redesign visual com novo logo, paleta de cores atualizada, agenda de endereços redesenhada, e teclado de entrada de valores melhorado. BTC Map agora é acessível da tela inicial, e descrições de transações aparecem em notificações.

nak v0.17.4 - A ferramenta de linha de comando Nostr de fiatjaf lançada, seguindo a correção de restrição LMDB Linux da v0.17.3 da semana passada.

Mudanças notáveis de código e documentação

Pull requests abertos e trabalho em estágio inicial que vale a pena acompanhar.

Damus (iOS)

NIP-19 relay hints implementa consumo de relay hints para busca de eventos. Quando usuários abrem links nevent, nprofile ou naddr, Damus agora extrai relay hints dos dados TLV bech32 e se conecta a relays efêmeros para buscar conteúdo que não está no pool de relays do usuário. A implementação inclui limpeza com contagem de referências para prevenir condições de corrida durante buscas concorrentes. Detecção de URL de imagem converte automaticamente URLs de imagem coladas em miniaturas de preview no compositor, com badge de posição de carrossel para múltiplas imagens. Conversão de colagem npub transforma strings npub/nprofile coladas em links de menção com resolução de perfil assíncrona.

Amethyst (Android)

Payment targets adiciona uma interface de evento para splits de zap NIP-57, permitindo que posts especifiquem múltiplos destinatários que compartilham zaps recebidos (útil para colaborações, divisão de receita, ou dar gorjetas tanto para criadores de conteúdo quanto para as ferramentas que eles usam). Documentação de paridade de recursos Quartz adiciona uma tabela detalhada rastreando quais recursos estão implementados através dos targets Android, Desktop JVM e iOS, notando que iOS está faltando criptografia central (Secp256k1Instance), serialização JSON e estruturas de dados.

Notedeck (Desktop)

Reconstrução de filtro de timeline corrige um bug onde contas deixadas de seguir continuavam aparecendo em feeds. Filtros de timeline eram construídos uma vez da lista de contatos e nunca atualizados; a correção adiciona rastreamento de contact_list_timestamp e um método invalidate() para acionar reconstruções quando o estado de seguimento muda.

Citrine (Android Relay)

ContentProvider API expõe o banco de dados de eventos do relay local para outros apps Android via ContentResolver. Diferente da interface WebSocket (que requer que apps mantenham uma conexão persistente e falem o protocolo relay Nostr), ContentProvider oferece acesso direto síncrono ao banco de dados através do mecanismo IPC nativo do Android. Apps externos podem consultar eventos por ID, pubkey, kind ou intervalo de datas, inserir novos eventos com validação, e deletar eventos sem gerenciar conexões de socket.

rust-nostr (Library)

Suporte NIP-40 em nível de relay adiciona tratamento de expiração no nível do relay builder. Eventos expirados agora são rejeitados antes do armazenamento e filtrados antes de enviar para clientes, eliminando a necessidade de cada implementação de banco de dados tratar verificações de expiração independentemente.

nak (CLI)

Blossom mirror implementa funcionalidade de espelhamento de blobs para a ferramenta de linha de comando.

Mostro (P2P Trading)

Dev fee audit events adiciona trilhas de auditoria transparentes para pagamentos ao fundo de desenvolvimento através de eventos Nostr kind 8383. A implementação publica eventos de auditoria não bloqueantes após pagamentos de fees bem-sucedidos, incluindo detalhes de ordem e hashes de pagamento enquanto exclui pubkeys de comprador/vendedor por privacidade.

MDK (Marmot Development Kit)

Três correções de auditoria de segurança chegaram: Verificação de autor força que pubkeys de rumor correspondam às credenciais do remetente MLS, prevenindo ataques de impersonação. KeyPackage identity binding verifica que a identidade da credencial corresponda aos assinantes de eventos. Validação de atualização de admin previne conjuntos de admin vazios e atribuições de admin a não membros.

Shopstr (Marketplace)

HODL invoice escrow implementa um sistema de pagamento que minimiza confiança para bens físicos. A arquitetura usa makeHoldInvoice do Alby para bloquear fundos do comprador em sua própria wallet, com liquidação acionada apenas após verificação de inventário do comerciante. O protocolo de handshake flui através de DMs criptografados NIP-17: comprador envia solicitação de pedido, comerciante responde com HODL invoice, comprador paga (fundos bloqueados), comerciante confirma estoque e envio, então a liquidação libera os fundos. Suporte de carrinho multi-comerciante divide pagamentos entre vendedores.

Jumble (Web Client)

Modo de descoberta por relay adiciona um toggle para ocultar posts de usuários seguidos em relays específicos, habilitando feeds de descoberta baseados em idioma (ex., nostr.band/lang/*). O recurso filtra posts onde o pubkey do autor aparece na lista de seguidos do usuário, persistindo o estado do toggle por URL de relay no localStorage.

White Noise (Encrypted Messaging)

Retry de upload de mídia adiciona opções de retry para uploads falhos. Avisos de edição de perfil alerta usuários sobre mudanças de perfil. No backend, whitenoise-rs corrige uma condição de corrida na criação de AccountGroup.

npub.cash (Lightning Address Service)

Reescrita v3 migra para Bun para o monorepo e servidor, adiciona suporte SQLite, remove compatibilidade v1, implementa LUD-21, e adiciona atualizações de mint quote em tempo real.

nostr-java (Library)

v1.1.1 lança refatorações de tratamento WebSocket e robustez de testes melhorada através de dois PRs.

NIPs Repository

Migração NIP-54 para Djot propõe uma mudança separada para a especificação wiki: mudar o formato de conteúdo de Asciidoc para Djot, uma linguagem de marcação leve com sintaxe mais limpa. O PR introduz links de estilo referência para wikilinks, tornando referências cruzadas entre artigos wiki mais legíveis na forma fonte. NIP-XX Quorum introduz governança de multi-assinatura threshold para grupos Nostr usando FROST (Flexible Round-Optimized Schnorr Threshold signatures). Um Quorum é um nsec compartilhado entre membros através de um esquema T-de-N onde membros podem representar a si mesmos ou delegar a um conselho de representantes. Quando o conselho muda, o nsec antigo se torna obsoleto e um novo é distribuído—o ato final de qualquer conselho é assinar o evento de transição de governança. A especificação define membresía (pública ou privada), eleições e enquetes (votos populares, votos de desconfiança), “leis” opcionais em linguagem natural, e crucialmente, ontologias de quorum onde quorums podem ser membros de outros quorums, habilitando estruturas hierárquicas como localidades se juntando a corpos regionais. Casos de uso abrangem desenvolvimento de código fonte, conselhos de empresas, HOAs, e comunidades moderadas.

Isso é tudo por esta semana e este ano. Construindo algo? Tem notícias para compartilhar? Quer que cubramos seu projeto? Entre em contato via NIP-17 DM ou encontre-nos no Nostr.

Nostr Compass #2

Wed, 24 Dec 2025 00:00:00 +0000

Bem-vindo de volta ao Nostr Compass, seu guia semanal do ecossistema do protocolo Nostr.

Esta semana: Três implementações de assinadores NIP-55 recebem atualizações: Amber adiciona cache de performance, Aegis ganha suporte a URI nostrsigner:, e Primal Android se junta a eles como um assinador local completo. Shopstr introduz “Zapsnags” para vendas relâmpago via zaps. Mostro adiciona um fundo de desenvolvimento. Quatro atualizações de NIP chegam incluindo Mensagens Públicas (kind 24) e melhorias de privacidade de grupos. Consultas de cache do NDK aceleram 162x, Applesauce adiciona reações e suporte a carteira NIP-60, e Tenex introduz arquitetura RAL para delegação de agentes IA. Em nosso aprofundamento, explicamos NIP-02 (listas de seguidos) e NIP-10 (threading de respostas), especificações fundamentais para construir timelines sociais e conversas.

Notícias

Primal Android Se Torna um Assinador NIP-55 - Construindo sobre o suporte a Nostr Connect da semana passada, Primal implementou capacidades completas de assinatura local através de oito pull requests merged. A implementação inclui um LocalSignerContentProvider completo que expõe operações de assinatura para outros apps Android via a interface de content provider do Android, seguindo a especificação NIP-55. A arquitetura separa responsabilidades de forma limpa: SignerActivity lida com fluxos de aprovação voltados ao usuário, LocalSignerService gerencia operações em background, e um novo sistema de permissões permite que usuários controlem quais apps podem solicitar assinaturas. Isso torna o Primal uma alternativa viável ao Amber para usuários Android que querem manter suas chaves em um app enquanto usam outros para diferentes experiências Nostr.

Shopstr Zapsnags: Vendas Relâmpago via Lightning - O marketplace nativo Nostr introduziu “Zapsnags”, uma funcionalidade de venda relâmpago que permite compradores adquirirem itens diretamente do seu feed social com um único zap. A implementação filtra notas kind 1 tagueadas com #shopstr-zapsnag e as renderiza como cards de produto com um botão “Zap para Comprar” ao invés do fluxo de carrinho padrão. Quando um comprador zapeia, o sistema gera uma solicitação de pagamento usando NIP-57, consulta o recibo de zap kind 9735 para confirmar o pagamento, então encripta informações de envio usando gift wrapping NIP-17 antes de enviá-las de forma privada ao vendedor. A funcionalidade armazena detalhes do comprador localmente para compras repetidas e inclui um painel de comerciante para criar listagens de venda relâmpago. É uma combinação inteligente de primitivas sociais, de pagamento e privacidade que demonstra como o design componível do Nostr permite padrões de comércio novos.

Mostro Introduz Fundo de Desenvolvimento - A plataforma de trading P2P Bitcoin NIP-69 implementou taxas de desenvolvimento configuráveis para apoiar manutenção sustentável. Operadores podem definir dev_fee_percentage entre 10-100% da taxa de trading do Mostro (padrão 30%), que automaticamente é direcionada a um fundo de desenvolvimento em cada trade bem-sucedido. A implementação adiciona três colunas de banco de dados (dev_fee, dev_fee_paid, dev_fee_payment_hash) para rastrear contribuições e valida a porcentagem na inicialização do daemon. Documentação técnica em docs/DEV_FEE.md explica o sistema. Este modelo opt-in permite que operadores apoiem desenvolvimento contínuo enquanto mantêm total transparência sobre alocação de taxas.

Atualizações de NIP

Mudanças recentes no repositório de NIPs:

Novos NIPs:

NIP-A4 (Mensagens Públicas, kind 24) - Um novo kind para mensagens de tela de notificação projetadas para amplo suporte de clientes (#1988). Diferente de conversas threaded, estas mensagens não têm conceito de histórico de chat ou cadeias de mensagem. Elas usam tags q (citações) ao invés de tags e para evitar complicações de threading, tornando-as ideais para notificações públicas simples que aparecem no feed de notificações de um destinatário sem criar estado de conversa.

Mudanças Significativas:

NIP-29 - Clarificação maior de semântica de grupos (#2106). A tag closed agora significa “incapaz de escrever” (somente leitura para não-membros), desacoplada da mecânica de entrada. Uma nova tag hidden previne que relays sirvam metadados ou eventos de membros para não-membros, permitindo grupos verdadeiramente privados que são indescobríveis sem convite fora de banda. A tag private controla visibilidade de mensagens enquanto ainda permite metadados públicos para descoberta.
NIP-51 - Adicionado kind 30006 para conjuntos de imagens curadas (#2170), seguindo o padrão de 30004 (artigos) e 30005 (vídeos). Já implementado no Nostria.
NIP-55 - Clarificado início de conexão para assinadores Android (#2166). Desenvolvedores implementando sessões multi-usuário estavam usando mal get_public_key chamando-o de processos em background. A especificação atualizada recomenda chamá-lo apenas uma vez durante a conexão inicial, prevenindo um footgun de implementação comum.

Aprofundamento NIP: NIP-02 e NIP-10

Esta semana cobrimos dois NIPs essenciais para funcionalidade social: como clientes sabem quem você segue e como conversas são threaded.

NIP-02: Lista de Seguidos

NIP-02 define eventos kind 3, que armazenam sua lista de seguidos. Este mecanismo simples potencializa o grafo social que torna timelines possíveis.

Estrutura: Um evento kind 3 contém tags p listando pubkeys seguidas:

{
 "id": "d7a8f...",
 "pubkey": "a3b9c...",
 "created_at": 1734912000,
 "kind": 3,
 "tags": [
 ["p", "91cf9..af5f", "wss://alicerelay.example.com", "alice"],
 ["p", "14aeb..8dad", "wss://bobrelay.example.com", "bob"],
 ["p", "612ae..982b", "", ""]
 ],
 "content": "",
 "sig": "e4f8a..."
}

Cada tag p tem quatro posições: o nome da tag, a pubkey seguida (hex), uma dica de URL de relay opcional, e um “petname” opcional (um apelido local). A dica de relay diz a outros clientes onde encontrar os eventos daquele usuário. O petname permite que você atribua nomes memoráveis a contatos sem depender dos nomes de exibição auto-declarados deles.

Comportamento substituível: Kind 3 cai no intervalo substituível (0, 3, 10000-19999), então relays mantêm apenas a versão mais recente por pubkey. Quando você segue alguém novo, seu cliente publica um novo kind 3 completo contendo todos os seus seguidos mais o novo. Isso significa que listas de seguidos devem ser completas a cada vez; você não pode publicar atualizações incrementais.

Construindo timelines: Para construir um feed home, clientes buscam o kind 3 do usuário, extraem todas as pubkeys das tags p, então se inscrevem em eventos kind 1 desses autores:

["REQ", "home", {"kinds": [1], "authors": ["91cf9...", "14aeb...", "612ae..."], "limit": 50}]

O relay retorna notas correspondentes, e o cliente as renderiza. As dicas de relay no kind 3 ajudam clientes a saber quais relays consultar para cada usuário seguido.

Petnames e identidade: O campo petname habilita um esquema de nomes descentralizado. Ao invés de confiar em qualquer nome que um usuário declare em seu perfil, você pode atribuir seu próprio rótulo. Um cliente pode exibir “alice (Minha Irmã)” onde “alice” vem do perfil kind 0 dela e “Minha Irmã” é seu petname. Isso fornece contexto que nomes de usuário globais não podem.

Considerações práticas: Porque eventos kind 3 são substituíveis e devem ser completos, clientes devem preservar tags desconhecidas ao atualizar. Se outro cliente adicionou tags que seu cliente não entende, sobrescrever cegamente perderia esses dados. Anexe novos seguidos ao invés de reconstruir do zero.

NIP-10: Threading de Notas de Texto

NIP-10 especifica como notas kind 1 referenciam umas às outras para formar threads de resposta. Entender isso é essencial para construir views de conversa.

O problema: Quando alguém responde a uma nota, clientes precisam saber: A que isso é uma resposta? Qual é a raiz da conversa? Quem deve ser notificado? NIP-10 responde essas perguntas através de tags e (referências de evento) e tags p (menções de pubkey).

Tags marcadas (preferidas): Clientes modernos usam marcadores explícitos em tags e:

{
 "id": "f9c2e...",
 "pubkey": "a3b9c...",
 "created_at": 1734912345,
 "kind": 1,
 "tags": [
 ["e", "abc123...", "wss://relay.example.com", "root"],
 ["e", "def456...", "wss://relay.example.com", "reply"],
 ["p", "91cf9..."],
 ["p", "14aeb..."]
 ],
 "content": "Ótimo ponto! Concordo.",
 "sig": "b7d3f..."
}

O marcador root aponta para a nota original que iniciou o thread. O marcador reply aponta para a nota específica sendo respondida. Se respondendo diretamente à raiz, use apenas root (nenhuma tag reply necessária). A distinção importa para renderização: o reply determina indentação em uma view de thread, enquanto root agrupa todas as respostas juntas.

Regras de threading:

Resposta direta à raiz: Uma tag e com marcador root
Resposta a uma resposta: Duas tags e, uma root e uma reply
O root permanece constante através do thread; reply muda baseado no que você está respondendo

Tags pubkey para notificações: Inclua tags p para todos que devem ser notificados. No mínimo, tagueie o autor da nota que você está respondendo. A convenção é também incluir todas as tags p do evento pai (para que todos na conversa fiquem por dentro), mais quaisquer usuários que você @mencione em seu conteúdo.

Dicas de relay: A terceira posição em tags e e p pode conter uma URL de relay onde aquele evento ou conteúdo do usuário pode ser encontrado. Isso ajuda clientes a buscar o conteúdo referenciado mesmo se não estiverem conectados ao relay original.

Tags posicionais depreciadas: Implementações antigas do Nostr inferiam significado da posição de tag ao invés de marcadores: primeira tag e era root, última era reply, do meio eram menções. Esta abordagem está depreciada porque cria ambiguidade. Se você vir tags e sem marcadores, provavelmente são de clientes antigos. Implementações modernas devem sempre usar marcadores explícitos.

Construindo views de thread: Para exibir um thread, busque o evento root, então consulte por todos eventos com uma tag e referenciando aquela raiz:

["REQ", "thread", {"kinds": [1], "#e": ["<root-event-id>"]}]

Ordene resultados por created_at e use marcadores reply para construir a estrutura de árvore. Eventos cujo reply aponta para a raiz são respostas de primeiro nível; eventos cujo reply aponta para outra resposta são respostas aninhadas.

Lançamentos

Zeus v0.12.0 - Construindo sobre o suporte a pagamentos paralelos NWC da semana passada, o lançamento maior da carteira Lightning entrega um serviço completo NIP-47 Nostr Wallet Connect com suporte a relay personalizado e rastreamento de orçamento. Uma correção de recarga de orçamento garante que conexões usem limites atuais. Cópia de endereço Lightning não inclui mais o prefixo lightning:, corrigindo problemas de colagem em campos de perfil Nostr.

Amber v4.0.6 - O assinador NIP-55 Android adiciona cache de performance a operações de assinatura e melhora tratamento de erros ao decriptar conteúdo malformado. Confiabilidade de conexão melhorou com lógica de retry para eventos de conexão de relay, e várias correções de crash abordam casos extremos em torno de URIs nostrconnect:// inválidas e interações de tela de permissão.

nak v0.17.3 - O último lançamento da ferramenta de linha de comando Nostr restringe builds LMDB ao Linux, corrigindo problemas de compilação cross-platform.

Aegis v0.3.4 - O assinador Nostr cross-platform adiciona suporte para o esquema de URI nostrsigner: definido em NIP-55, correspondendo ao fluxo de conexão do Amber. Dados de relay local agora podem ser importados e exportados para backup, e o lançamento inclui correções de bugs para erros de socket de relay e melhorias de UI para a interface de relay local.

Mudanças notáveis de código e documentação

Estes são pull requests abertos e trabalho em estágio inicial, perfeitos para obter feedback antes de serem merged. Se algo chamar sua atenção, considere revisar ou comentar!

Damus (iOS)

Persistência de lista de silenciados corrige um problema onde listas de silenciados eram apagadas em cold start. A correção adiciona guardas para prevenir sobrescritas acidentais durante a inicialização do app. Timing de stream de perfil elimina um delay de ~1 segundo antes de perfis em cache aparecerem. Anteriormente, views esperavam por tarefas de inscrição reiniciarem; agora streamProfile() imediatamente retorna dados em cache do NostrDB, removendo a janela onde pubkeys abreviadas e imagens placeholder apareciam.

White Noise (Mensagens Encriptadas)

Streaming de mensagens em tempo real substitui o mecanismo de polling anterior com uma arquitetura baseada em stream. O novo ChatStreamNotifier consome o stream de mensagens do SDK Rust diretamente, mantendo ordem cronológica e lidando com atualizações incrementais eficientemente. Testes mostraram melhoria significativa em responsividade. Uma API de lista de chat adiciona get_chat_list para recuperar resumos de conversas, e uma correção de ordenação estável previne loops de reordenação de mensagens usando createdAt com ID de mensagem como desempate.

NDK (Biblioteca)

Dois pull requests entregaram melhorias dramáticas de performance de cache. PR #371 corrigiu um bug onde eventos lidos do cache SQLite eram imediatamente escritos de volta, causando 100% de escritas duplicadas no boot do app. A correção adiciona uma guarda fromCache e implementa verificação de duplicatas O(1) via um Set em memória. Para conjuntos de resultado pequenos (<100 eventos), transferência JSON direta substitui overhead de codificação binária. PR #372 removeu chamadas desnecessárias seenEvent para eventos em cache. A busca no cache LRU custava 0.24-0.64ms por evento; para 5,700 eventos em cache, isso adicionava ~1.4 segundos de overhead. Resultado: consultas de cache caíram de ~3,690ms para ~22ms (162x mais rápido).

rust-nostr (Biblioteca)

Suporte a REQ multi-filtro foi restaurado após ser removido em um refactor anterior. O SDK novamente aceita Vec<Filter> para solicitações de inscrição, permitindo consultas eficientes que combinam múltiplas condições de filtro com lógica OR. Proveniência de relay foi adicionada a métodos stream_events*, então cada evento em stream agora inclui o RelayUrl de onde veio e um Result indicando sucesso ou falha, útil para rastrear confiabilidade de relay e debugar problemas de conexão. Uma correção de segurança removeu a dependência url-fork seguindo RUSTSEC-2024-0421, eliminando uma vulnerabilidade conhecida.

Applesauce (Biblioteca)

A biblioteca TypeScript que potencializa noStrudel viu desenvolvimento significativo esta semana. Novos modelos incluem um sistema de reações e casting de grupos de usuários. Funcionalidade de carteira expandiu com suporte NIP-60, uma aba de envio, e ferramentas melhoradas de recuperação de token. Uma nova propriedade user.directMessageRelays$ expõe configuração de relay DM. Todas as ações foram refatoradas para usar interfaces async (removendo geradores async), e correções de bugs abordaram restauração de conteúdo encriptado e casos extremos de filtro de eventos baseados em tempo.

Tenex (Agentes IA)

O sistema de coordenação multi-agente construído sobre Nostr introduziu arquitetura RAL (Request-Action-Lifecycle) em cinco PRs merged. RAL permite que agentes pausem quando delegando tarefas e retomem quando resultados chegam, com persistência de estado no escopo da conversa. Ferramentas de delegação (delegate, ask, delegate_followup, delegate_external) agora publicam eventos Nostr e retornam sinais de parada ao invés de bloquear. O refactor inclui migração para AI SDK v6, infraestrutura de teste VCR para gravação determinística de interação LLM, e suporte a imagens multimodal.

Isso é tudo por esta semana. Construindo algo? Tem notícias para compartilhar? Quer que a gente cubra seu projeto? Entre em contato via NIP-17 DM ou nos encontre no Nostr.

Nostr Compass #1

Mon, 15 Dec 2025 00:00:00 +0000

Bem-vindo ao Nostr Compass, um boletim semanal dedicado ao ecossistema do protocolo Nostr. Nossa missão é manter desenvolvedores, operadores de relays e construtores informados sobre desenvolvimentos importantes em toda a rede. Documentamos a evolução do protocolo com precisão técnica, neutralidade e profundidade, cobrindo desde propostas de NIP até lançamentos de clientes e melhores práticas de implementação.

O Nostr Compass é inspirado no Bitcoin Optech, cujo trabalho dedicado ao longo dos anos avançando o conhecimento técnico do Bitcoin estabeleceu o padrão para boletins focados em protocolos. Somos gratos pelo exemplo deles e esperamos trazer o mesmo rigor ao ecossistema Nostr.

Esta edição inaugural estabelece nosso formato semanal. Toda quarta-feira traremos atualizações de NIP, notas de lançamento, destaques de desenvolvimento e orientação técnica. Seja você construindo um cliente, operando um relay ou contribuindo para o protocolo, o Nostr Compass pretende ser sua fonte confiável sobre o que está acontecendo no ecossistema.

O que é Nostr?

Como esta é nossa primeira edição, começamos com uma introdução sobre como o Nostr funciona. Leitores regulares podem pular para frente.

Nostr (Notes and Other Stuff Transmitted by Relays) é um protocolo descentralizado para redes sociais e mensagens. Diferente das plataformas tradicionais, o Nostr não tem servidor central, nenhuma empresa o controla e não tem ponto único de falha. Os usuários possuem sua identidade através de pares de chaves criptográficas, e o conteúdo flui através de servidores relay independentes que qualquer pessoa pode executar.

Como funciona: Os usuários geram um par de chaves (uma chave privada chamada nsec e uma chave pública chamada npub). A chave privada assina mensagens chamadas “eventos”, e a chave pública serve como sua identidade. Os eventos são enviados para relays, que os armazenam e encaminham para outros usuários. Como você controla suas chaves, pode trocar entre clientes ou relays sem perder sua identidade ou seguidores.

Por que importa: O Nostr fornece resistência à censura através da diversidade de relays (se um relay te banir, outros ainda podem servir seu conteúdo), portabilidade (sua identidade funciona em qualquer app Nostr) e interoperabilidade (todos os clientes Nostr falam o mesmo protocolo). Não há algoritmo decidindo o que você vê, sem anúncios e sem coleta de dados.

O ecossistema hoje: O Nostr suporta microblogging (como Twitter/X), conteúdo longo (como Medium), mensagens diretas, marketplaces, streaming ao vivo e mais. Os clientes incluem Damus (iOS), Amethyst (Android), Primal, Coracle e dezenas de outros. A integração com Lightning Network permite pagamentos instantâneos através de “zaps”. O protocolo continua a evoluir através de NIPs (Nostr Implementation Possibilities), especificações impulsionadas pela comunidade que estendem a funcionalidade.

Notícias

NIP-BE Merged: Suporte Bluetooth Low Energy - Uma nova capacidade significativa chegou ao protocolo. NIP-BE especifica como aplicações Nostr podem se comunicar e sincronizar sobre Bluetooth Low Energy. Isso permite que apps capazes de funcionar offline sincronizem dados entre dispositivos próximos sem conectividade com internet. A especificação adapta padrões de relay WebSocket às restrições do BLE, usando compressão DEFLATE e mensagens fragmentadas para lidar com os pequenos tamanhos de MTU do BLE (20-256 bytes). Os dispositivos negociam papéis baseados na comparação de UUID, com o UUID mais alto se tornando o servidor GATT.

MIP-05: Notificações Push que Preservam Privacidade - O Protocolo Marmot publicou MIP-05 (especificação), uma especificação para notificações push que mantêm a privacidade. Sistemas push tradicionais exigem que servidores conheçam tokens de dispositivo e identidades de usuário; MIP-05 resolve isso encriptando tokens de dispositivo com ECDH+HKDF e ChaCha20-Poly1305, usando chaves efêmeras para prevenir correlação. Um protocolo gossip de três eventos (kinds 447-449) sincroniza tokens encriptados entre membros do grupo, e as notificações usam gift wrapping NIP-59 com tokens chamariz para esconder tamanhos de grupo. Isso permite que WhiteNoise e outros clientes Marmot entreguem notificações oportunas sem comprometer a privacidade do usuário.

Blossom BUD-10: Novo Esquema URI - O protocolo de mídia Blossom está ganhando um esquema URI personalizado via BUD-10 (especificação). O novo formato blossom:<sha256>.ext incorpora hash de arquivo, extensão, tamanho, múltiplas dicas de servidor e pubkeys de autor para descoberta de servidor BUD-03. Isso torna links de blob mais resilientes que URLs HTTP estáticas ao permitir fallback automático entre servidores.

Atualizações do Marketplace Shopstr - O marketplace nativo Nostr implementou Nostr Wallet Connect (NIP-47) para pagamentos, adicionou expiração de listagens usando NIP-40, e introduziu códigos de desconto para vendedores.

Atualizações de NIP

Mudanças recentes no repositório de NIPs:

Novos NIPs:

NIP-BE - Mensagens Bluetooth Low Energy e sincronização de dispositivos (#1979)
NIP-63 - Padrão de Paywall/Conteúdo Premium para lidar com conteúdo restrito dentro do protocolo (#2156)

Mudanças Significativas:

NIP-24 - Adicionado array opcional languages aos metadados de usuário Kind 0, permitindo que usuários especifiquem múltiplos idiomas preferidos usando tags IETF BCP 47 para melhor descoberta de conteúdo e correspondência de relay (#2159)
NIP-69 - Adicionado suporte de expiração de ordem para trading P2P com tags expires_at e expiration (#2118)
NIP-59 - Eventos gift wrap agora podem ser deletados via requisições NIP-09/NIP-62 (#2131)
NIP-51 - Removidas tags de hashtag e URL de marcadores genéricos; hashtags agora usam kind 30015 (#2133)
NIP-18 - Melhorados reposts genéricos para eventos substituíveis com suporte a tag a (#2132)
NIP-17 - Redação refinada e adicionado suporte a reação kind 7 para DMs (#2098)
NIP-11 - Adicionado campo self para identificação de chave pública do relay (#1764)

Aprofundamento em NIP: NIP-01 e NIP-19

Para esta edição inaugural, cobrimos dois NIPs fundamentais que todo desenvolvedor Nostr deve entender. Consulte nossas páginas de tópicos para NIP-01 e NIP-19.

NIP-01: Protocolo Básico

NIP-01 define o protocolo central. Tudo no Nostr é construído sobre esta especificação.

Eventos são o único tipo de objeto. Cada evento contém:

id: Hash SHA256 do evento serializado (o identificador único do evento)
pubkey: A chave pública do criador (hex de 32 bytes, secp256k1)
created_at: Timestamp Unix
kind: Inteiro categorizando o tipo de evento
tags: Array de arrays para metadados
content: O payload (interpretação depende do kind)
sig: Assinatura Schnorr provando que a pubkey criou este evento

Kinds determinam como relays armazenam eventos:

Eventos regulares (1, 2, 4-44, 1000-9999): Armazenados normalmente, todas as versões mantidas
Eventos substituíveis (0, 3, 10000-19999): Apenas o mais recente por pubkey é mantido
Eventos efêmeros (20000-29999): Não armazenados, apenas encaminhados para assinantes
Eventos endereçáveis (30000-39999): Mais recente por combinação pubkey + kind + d-tag

Kind 0 são metadados de usuário (perfil), kind 1 é uma nota de texto (o post básico), kind 3 é a lista de seguidos.

Kind 1: Notas de Texto são o coração do Nostr social. Um evento kind 1 é um post curto, similar a um tweet. O campo content contém o texto da mensagem (texto puro, embora clientes frequentemente renderizem markdown). Tags permitem respostas, menções e referências:

{
 "id": "<32-byte-hex>",
 "pubkey": "<32-byte-hex>",
 "created_at": 1734480000,
 "kind": 1,
 "content": "Olá Nostr! Confira o trabalho do @jb55 no Damus.",
 "tags": [
 ["e", "<replied-to-event-id>", "wss://relay.example.com", "reply"],
 ["p", "<jb55-pubkey>"]
 ],
 "sig": "<64-byte-hex>"
}

A tag e com marcador “reply” indica que isso é uma resposta (veja NIP-10 para convenções de threading). A tag p menciona um usuário, permitindo que clientes o notifiquem e renderizem seu nome ao invés da pubkey crua. Clientes buscam o evento kind 0 do usuário mencionado para obter seu nome de exibição e foto.

Para construir uma timeline, um cliente se inscreve em eventos kind 1 de pubkeys seguidas: ["REQ", "feed", {"kinds": [1], "authors": ["<pubkey1>", "<pubkey2>", ...], "limit": 50}]. O relay retorna notas correspondentes, e o cliente as renderiza cronologicamente.

Eventos endereçáveis (30000-39999) funcionam como eventos substituíveis mas usam uma tag d como identificador adicional. O relay mantém apenas a versão mais recente de cada combinação pubkey + kind + d-tag. Isso permite artigos editáveis, listagens de produtos, ou qualquer caso onde você precisa de múltiplos itens substituíveis por usuário.

Tags são arrays onde o primeiro elemento é o nome da tag. Tags padrão de uma única letra (e, p, a, d, t) são indexadas por relays para consultas eficientes. Por exemplo, ["e", "<event-id>"] referencia outro evento, ["p", "<pubkey>"] referencia um usuário.

Comunicação Cliente-Relay usa conexões WebSocket com arrays JSON como mensagens. O primeiro elemento identifica o tipo de mensagem.

De cliente para relay:

["EVENT", <event>] - Publica um evento no relay
["REQ", <sub-id>, <filter>, ...] - Inscreve-se em eventos correspondentes ao(s) filtro(s)
["CLOSE", <sub-id>] - Encerra uma inscrição

De relay para cliente:

["EVENT", <sub-id>, <event>] - Entrega um evento correspondente à sua inscrição
["EOSE", <sub-id>] - “Fim de eventos armazenados” - o relay enviou todos os correspondentes históricos e agora só enviará novos eventos conforme chegarem
["OK", <event-id>, <true|false>, <message>] - Confirma se um evento foi aceito ou rejeitado (e por quê)
["NOTICE", <message>] - Mensagem legível por humanos do relay

O fluxo de inscrição: cliente envia REQ com um ID de inscrição e filtro, relay responde com mensagens EVENT correspondentes, então envia EOSE para sinalizar que está em dia com o histórico. Após EOSE, qualquer nova mensagem EVENT é em tempo real. Cliente envia CLOSE quando terminar.

Filtros especificam quais eventos recuperar. Um objeto filtro pode incluir: ids (IDs de evento), authors (pubkeys), kinds (tipos de evento), #e/#p/#t (valores de tag), since/until (timestamps), e limit (máximo de resultados). Todas as condições dentro de um filtro usam lógica AND. Você pode incluir múltiplos filtros em um REQ, e eles se combinam com lógica OR - útil para buscar diferentes tipos de evento em uma inscrição.

NIP-19: Identificadores Codificados em Bech32

NIP-19 define os formatos amigáveis para humanos que você vê em todo lugar no Nostr: npub, nsec, note e mais. Estes não são usados no protocolo em si (que usa hex), mas são essenciais para compartilhamento e exibição.

Por que bech32? Chaves hex brutas são propensas a erros ao copiar e difíceis de distinguir visualmente. A codificação bech32 adiciona um prefixo legível por humanos e checksum. Você pode distinguir imediatamente um npub (chave pública) de um nsec (chave privada) ou note (ID de evento).

Formatos básicos codificam valores brutos de 32 bytes:

npub - Chave pública (sua identidade, segura para compartilhar)
nsec - Chave privada (manter em segredo, usada para assinar)
note - ID de evento (referencia um evento específico)

Exemplo: A pubkey hex 3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d se torna npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6.

Identificadores compartilháveis incluem metadados usando codificação TLV (Type-Length-Value):

nprofile - Perfil com dicas de relay (ajuda clientes a encontrar o usuário)
nevent - Evento com dicas de relay, pubkey do autor e kind
naddr - Referência de evento endereçável (pubkey + kind + d-tag + relays)

Estes resolvem um problema-chave: se alguém compartilha um ID de nota, como você sabe qual relay o tem? Um nevent agrupa o ID do evento com relays sugeridos, tornando o compartilhamento mais confiável.

Importante: Nunca use formatos bech32 no protocolo em si. Eventos, mensagens de relay e respostas NIP-05 devem usar hex. Bech32 é puramente para interfaces humanas: exibição, copiar/colar, códigos QR e URLs.

Lançamentos

Amber v4.0.4 - O app assinador Android corrige um NullPointerException, melhora performance na tela de atividade e adiciona traduções para alguns tipos de evento. O lançamento anterior v4.0.3 adicionou UI renovada de encriptação/decriptação, exportação/importação de contas, tratamento de relay por conta, suporte a ping bunker e relatório de crashes. Lançamento

Coracle 0.6.28 - Lançamento de correção de bugs para o cliente web. Corrigidos feeds de tópicos, tratamento de imagens quando imgproxy está desabilitado, e linkificação de fontes de destaque que não são links. Lançamento

Flotilla v1.6.2 - O cliente de comunidades estilo Discord corrige scroll modal e problemas de estilo. Lançamentos anteriores neste ciclo adicionaram badges e sons opcionais para notificações, renderização de links melhorada, escaneamento de código QR para links de convite e configuração de carteira simplificada. Lançamento

nak v0.17.2 - A ferramenta de linha de comando Nostr adicionou um novo comando nip para consulta rápida de referência NIP, além de correções para tratamento de repositório git e processamento de eventos stdin. Lançamento

White Noise v0.2.1 - Lançamento maior para o app de mensagens encriptadas baseado em MLS adicionando compartilhamento de imagens via Blossom, sincronização em background, notificações push, localização em 8 idiomas e gerenciamento de membros de grupo. Lançamento

Amethyst v1.04.2 - Lançamento com novas funcionalidades introduzindo listas/packs de seguidos, novos filtros de timeline, galeria de imagens e compressão de vídeo H.265 (arquivos 50% menores). Migração completa para Kotlin Multiplatform. Lançamento

Mostro v0.15.5 - Atualização da plataforma de trading P2P com suporte a expiração de ordem NIP-69 e respostas melhoradas de histórico de trades. Lançamento

Nosflare v8.9.26 - Relay Nostr serverless construído na infraestrutura Cloudflare. Este lançamento entrega um hotfix crítico abordando um bug que poderia causar falhas de websocket, garantindo conexões mais estáveis para usuários e aplicações que dependem do relay. Lançamento

Noscall v0.4.1 - App de chamadas de áudio e vídeo seguras baseado em Nostr. Este lançamento melhora a UI pop-up na página Me e corrige vários problemas conhecidos, resultando em melhor estabilidade e confiabilidade de chamadas. Lançamento

Gitplaza v0.25.0 - Cliente de desktop Nostr focado em atividade relacionada a Git. Este lançamento introduz um filtro de kind avançado para o feed de inbox, inclui zaps regulares em filtros e simplifica a formatação de texto de abas. Melhorias de performance otimizam o carregamento da árvore de comentários, reduzem consultas desnecessárias ao banco de dados e usam branches de comentários em cache para exibição mais rápida. Lançamento

Mudanças notáveis de código e documentação

Damus (iOS)

Foco em estabilidade com correções de crash e UI: correção de pulo de cursor para a view de composição, redesign da interface NostrDB usando tipos ~Copyable do Swift para segurança de transações, estabilidade de UI de threads corrigindo reinstanciação da barra de ações, congelamento de lista de silenciados por ciclos de AttributeGraph, e crash de perfil por limpeza de transação entre threads. Também adicionou diretrizes AGENTS.md para agentes de código IA.

Notedeck (Desktop/Mobile)

Armazenamento seguro de chaves move nsec para o armazenamento seguro do SO com migração automática. Filtragem de notas futuras esconde eventos datados 24+ horas à frente (anti-spam). Cópia de nevent agora inclui dicas de relay. Também: adição rápida de coluna de perfil, navegação por teclado, otimização de carregamento de mídia.

Amethyst (Android)

Suporte a assinatura remota NIP-46 para Nostr Connect. Organização de marcadores com gerenciamento de lista pública/privada. Correção de compatibilidade strfry para casos extremos de parsing de info de relay.

Primal (Android)

Deep links de Nostr Connect para URLs nostrconnect://. Login remoto via scan de QR para conexões bunker. Correção de condição de corrida de conexão.

White Noise (Mensagens Encriptadas)

Correção de retenção de dados do app desabilita auto-backup do Android para privacidade. Comportamento de scroll do chat preserva posição ao ler histórico.

Zeus (Carteira Lightning)

Pagamentos paralelos NIP-47 para melhor throughput de zaps em lote.

Melhores Práticas para Desenvolvedores

Valide Eventos Auth Defensivamente - go-nostr corrigiu um panic na validação NIP-42 quando a tag relay estava faltando. Sempre verifique as tags requeridas antes de acessá-las, mesmo em fluxos auth onde você espera eventos bem formados.

Limite Taxa por Estado de Autenticação - khatru adicionou limitação de taxa baseada em NIP-42, permitindo que relays apliquem limites diferentes para conexões autenticadas vs anônimas. Considere limites escalonados baseados em status auth ao invés de restrições gerais.

Use Paginação por Cursor para Listas - Blossom substituiu paginação baseada em data com paginação baseada em cursor no endpoint /list. Paginação baseada em data quebra quando itens compartilham timestamps; cursores fornecem iteração confiável.

Validação de Schema para Tipos de Evento - O projeto nostrability/schemata fornece schemas JSON para validar eventos compatíveis com NIP. Considere integrar validação de schema em desenvolvimento para capturar eventos malformados antes que cheguem aos relays.

Isso é tudo por esta semana. Construindo algo? Tem notícias para compartilhar? Quer que a gente cubra seu projeto? Entre em contato via NIP-17 DM ou nos encontre no Nostr.