Esta semana foi carregada de trabalho em assinadores, protocolos de negociação P2P e lançamentos de clientes de destaque. O Amethyst v1.12.0 traz mais de 170 PRs que adicionam carteiras Cashu NIP-60, nutzaps NIP-61, feeds de aplicativos NIP-82, suporte a podcasts NIP-F4, verificação de zaps on-chain via CLINK, migração KMP fases 1 e 2 para iOS e um driver de auto-recuperação do Tor. O Clave v1.0.0 (build 102) foi submetido à App Store, levando ao iOS a assinatura em segundo plano acordada por push e a verificação de assinaturas recebidas. O Mostro Core v0.13.0 traz o Protocolo v2, substituindo a comunicação de ordens baseada em relays por mensagens diretas com gift wrap NIP-44, e o Mostro v0.17.5 tornou a caução antiabuso do lado do operador opcional e configurável. O Signet v1.11.0 corrige um desvio de verificação de assinatura em comandos administrativos NIP-17 (DMs privadas com gift wrap) que permitia a qualquer pessoa com informações públicas forjar comandos de kill switch. O Chama lançou sete versões de escrow em seis dias, transformando a sala de negociação de um paredão de controles em uma conversa por papel. Do lado dos assinadores, o Amber v6.2.1, o Clave (builds 100, 101 e 102) e o Nostur 1.29.0 implementam todos o novo método de logout NIP-46 incorporado esta semana (PR #2373). O Zeus v13.1.0-rc1 e o Amethyst trazem ambos suporte a noffers CLINK, a interface Lightning comum proposta para chaves Nostr. Os grupos de relay NIP-29 receberam cinco propostas abertas cobrindo tags de banner, códigos de convite, fixação de mensagens, denúncia de grupos por DMs NIP-17 e controle de acesso baseado em papéis.

Histórias principais

O Amethyst é o cliente Nostr Android dominante, criado por Vitor Pamplona. A v1.12.0 agrupa os 93 PRs cobertos como trabalho não lançado na Newsletter #25 (rotulagem de hashtags NIP-32, tela de podcasts NIP-F4, faixas musicais, assinadores efêmeros, zaps on-chain com filtro NIP-05) e na Newsletter #26 (continuação do NIP-F4, base do watchdog do Tor), mais um lote novo e substancial esta semana. O trabalho novo se concentra em uma superfície de Cashu e nutzaps, um driver CLINK para zaps on-chain, um conjunto de auto-recuperação do Tor e a migração KMP para iOS.

O suporte a carteiras Cashu NIP-60 e a renderização de nutzaps NIP-61 chegam no PR #3075, com uma visão de saldo por mint (PR #3115) e uma interface unificada de cartão de pagamento (PR #3191) que consolida endereços Lightning, zaps on-chain, mints Cashu e NWC em uma única tela de pagamentos do perfil (PR #3185). Um driver CLINK para verificação de zaps on-chain chega no PR #3039, no PR #3177 e no PR #3182. CLINK é a Common Lightning Interface for Nostr Keys, a mesma interface noffer que o Zeus v13.1.0-rc1 traz esta semana, e o Amethyst acrescenta uma máquina de estados de verificação, um driver de reverificação e um valor mínimo para zaps on-chain (PR #3030). O PR #3201 introduz notas privadas ao aplicar gift wrap a respostas kind 1 para usuários com tag p conforme o NIP-17, de modo que o compositor produz uma nota pública ou uma resposta selada em grupo dependendo de para quem ela é dirigida.

Um conjunto de confiabilidade do Tor chega como uma pilha completa de auto-recuperação: o PR #3053 atualiza o Arti para a v2.3.0 com um watchdog e testes de integração, o PR #3223 bloqueia conexões a relays roteadas por Tor até o Tor estar pronto, o PR #3224 limita o bootstrap do Arti com um timeout de 60 segundos para que uma rede hostil não possa travar o laço, e o PR #3231 se auto-recupera quando o Tor está ativo mas todos os circuitos estão mortos. O resultado é uma pilha Tor que se recupera de mudanças de rede e de ciclos de suspensão e retomada sem intervenção manual. As fases 1 e 2 da migração KMP para iOS chegam no PR #3047 e no PR #3050, desbloqueando a CI de iOS para os módulos quartz e commons e assentando a base para uma build iOS do Amethyst.

Mostro Core v0.13.0 corta o intermediário do relay com o Protocolo v2

O Mostro é uma corretora P2P de Bitcoin liquidada por Lightning que usa o Nostr como livro de ordens e como camada de comunicação de negociações. A v0.13.0 do mostro-core, a biblioteca Rust que define o protocolo de fio, substitui o modelo de mensagens roteadas por relay pelo que o changelog descreve como Protocolo v2, um transporte direto NIP-44 que viaja sobre eventos kind 14. Ações específicas de negociação agora trafegam como mensagens kind 14 embrulhadas conforme o NIP-44 e vinculadas à chave por negociação que o participante gerou na criação da ordem, sem levar a conversa da negociação por eventos endereçáveis públicos.

No modelo anterior, toda a superfície da conversa de negociação vazava para cada relay que carregava os eventos. O transporte direto kind 14 mantém a montagem da ordem, o fluxo de disputa e os metadados de liquidação entre as duas partes e o daemon do Mostro, com os relays vendo apenas envelopes cifrados. Junto com a mudança de transporte, a v0.13.0 também vincula a prova de identidade v2 à chave de negociação (log de commits), fechando uma classe de riscos de replay contra o novo protocolo. Do lado do daemon, o Mostro v0.17.5 tornou a caução antiabuso opcional e configurável pelo operador: antes de iniciar certas negociações, cada lado pode precisar travar uma pequena caução devolvida na conclusão normal e perdida em caso de travamento, ausência ou má-fé. A caução é habilitada no nível do operador do nó, não imposta em toda a rede, então o Mostro segue não custodial e cada operador escolhe o tradeoff entre atrito no mercado e resistência a abuso. Do lado do cliente, o Mostro Mobile v1.2.8 trouxe 17 recursos que sustentam o novo caminho, incluindo descoberta de relays por bootstrap no lugar de relays padrão fixados (PR #610), caução antiabuso do criador na abertura da ordem como fase 5 da implantação da caução (PR #608) e cancelamento de ordem persistido no histórico de notificações com contexto (PR #602). A v1.2.9 veio dois dias depois, expondo a política de caução antiabuso a partir do evento de informação do nó para que o usuário possa ver as regras de caução da instância do Mostro antes de abrir uma ordem (PR #617).

Signet v1.11.0 corrige um desvio de assinatura em comandos administrativos NIP-17

O Signet é um assinador bunker remoto com uma superfície de kill switch que permite a um administrador entrar em pânico, revivê-lo ou verificá-lo pelo Nostr sem tocar na máquina host. A v1.11.0 corrige uma falha de segurança nessa superfície em que o caminho de comandos administrativos por gift wrap NIP-17 checava apenas o autor alegado no rumor interno não assinado, sem nunca verificar o seal assinado. Como as chaves de conversa NIP-44 são simétricas, um atacante de posse apenas de informações públicas (a pubkey do assinador, o npub do administrador, um relay administrativo) podia forjar um gift wrap de fora e executar qualquer comando de kill switch, incluindo panic, resumeall ou alive. A correção chama verifyEvent no seal e vincula o autor do rumor à assinatura do seal, então falsificações não assinadas passam a ser rejeitadas na entrada. Operadores do Signet devem atualizar sem demora: a especificação e o caminho de código corrigido, juntos, dão a um atacante uma receita clara de reprodução.

Chama v3.2.0 a v3.5.0 redesenham a sala de negociação e reforçam o caminho do dinheiro

O Chama é um cliente de escrow P2P nativo do Nostr que combina ecash Fedimint com compartilhamento de segredo de Shamir 2 de 3 para liquidação de negociações sem servidor. A Newsletter #26 cobriu a sequência da v2.0.0 à v3.1.0 que cruzou a linha do aplicativo autônomo e adicionou vitrines por vendedor. Os seis lançamentos seguintes desta semana começam na v3.2.0 e terminam na v3.5.0 em 15 de junho, redesenhando a interface da sala de negociação em torno de uma única pergunta por papel (o que eu faço agora) e reforçando o caminho do dinheiro contra falhas parciais. A v3.2.0 deu a comprador, vendedor e árbitro seus próprios avisos de ação codificados por cor, de modo que cada papel vê seu próximo movimento em cada estado da negociação. A v3.3.0 apertou duas regras de consenso no motor de negociação e exigiu adoção coordenada pelos clientes para entrar em vigor. A v3.3.1 localizou preços e métodos de pagamento para a moeda da comunidade do negociador. A v3.4.0 acrescentou cinco correções de reforço ao caminho do dinheiro para que um soluço, uma corrida ou uma aba fechada não custem sats ao usuário sem aviso. A v3.5.0 acrescentou duas salvaguardas do lado do cliente em torno do papel de árbitro, o único papel que poderia de outra forma inclinar uma negociação sem alarde.

Clave 1.0 chega à App Store com assinatura em segundo plano acordada por push

O Clave é um assinador remoto NIP-46 para iOS que mantém a chave privada Nostr do usuário no Keychain do iPhone. Aplicativos pedem assinaturas por um canal cifrado ponta a ponta e nunca recebem a chave em si. A v1.0.0 build 102 foi submetida à App Store esta semana, marcando o marco 1.0 depois de oito meses de betas no TestFlight. O lançamento traz a assinatura em segundo plano acordada por push: o Clave consegue decifrar uma requisição, checar permissões, assinar e responder com o aplicativo fechado, então a exigência de primeiro plano do iOS que antes limitava a responsividade do assinador desapareceu. A verificação de assinaturas recebidas é aplicada com Schnorr BIP-340 sobre o formato canônico de serialização de eventos do NIP-01 (a especificação base que define como todo evento Nostr assinado é hasheado), mais uma proteção de frescor contra replay, de modo que um aplicativo malicioso não consegue contrabandear um evento reassinado pelo canal de resposta.

O lançamento também entrega a camada de cifragem NIP-44 atualizada com um modelo de permissões por kind e três níveis de sensibilidade, corrige o caso limite de assinatura de baixa confiança em que uma requisição do tipo “perguntar sempre” retornava um erro antes de o usuário poder aprovar, e adiciona pareamento multiconta para que um único pareamento de aplicativo possa fluir por várias identidades. Pareamentos de bunker agora expõem a identidade real do aplicativo por meio da extensão de metadados de conexão NIP-46 que o Clave propôs no PR #2381. O fluxo de desconexão limpa usa o novo método logout do NIP-46 incorporado no PR #2373, então um aplicativo pareado pode encerrar sua sessão de forma limpa sem desparear manualmente. Níveis de confiança por aplicativo (alto, médio, baixo) com exceções por kind de evento, um registro de atividade para cada assinatura e proxy de push próprio completam a superfície; a pilha de proxy é licenciada sob MIT e a matriz de interoperabilidade por cliente é acompanhada em docs/nip46-compatibility.md.

Lançamentos

Amber v6.2.1 adiciona logout NIP-46 e reduz o consumo de bateria do assinador

O Amber é o assinador Nostr Android dominante. A v6.2.1 reduz o consumo de bateria causado por reconexões a relays e pings de websocket, tira relays mortos do pool de assinaturas e para de acordar o dispositivo ao atualizar a notificação de relay. O lançamento também adiciona suporte ao método de logout NIP-46 para que clientes possam encerrar sessões de assinador remoto de forma limpa (o mesmo método incorporado à especificação esta semana no PR #2373) e adiciona parsing do evento kind 39701 (marcador web público) para que usuários possam assinar eventos de marcador direto do Amber. As configurações foram reconstruídas com cartões agrupados em Material 3 e ícones distintos, um crash de navegação na tela de permissões de aplicativos foi corrigido, e um vazamento de conexão de banco de dados por conta foi fechado com a construção atômica dos bancos.

Nostur 1.29.0 traz respostas anônimas e logout de assinador remoto

O Nostur é um cliente Nostr para iOS criado por Fabian. A 1.29.0-desktop adiciona suporte a responder recibos de zap e a enviar respostas anônimas. Do lado do assinador, o lançamento melhora o fluxo de conexão com bunker remoto, envia um logout NIP-46 ao assinador remoto quando o usuário sai de uma conta, e corrige um indicador de carregamento travado quando uma conexão com assinador remoto falha. O lançamento também corrige problemas de carregamento de DMs causados por conflitos entre relays de DM e relays do aplicativo, corrige publicações duplicadas ao navegar para uma resposta e voltar, e mostra uma miniatura de mídia nas linhas de notificação.

Citrine v3.0.0 traz Negentropy, AUTH NIP-42 e filtragem de relays onion

O Citrine é um agregador de relay local para Android. A v3.0.0 é um salto de versão maior que adiciona suporte a Negentropy NIP-77 para sincronizações por reconciliação de conjuntos, suporte a assinador externo e AUTH NIP-42 no agregador de relays, e respeito a listas de silenciamento NIP-51 nas buscas do agregador. O agregador limita as buscas a três relays por autor, com relays de origem e de indexação configuráveis, reutiliza follows, silenciamentos e metadados em cache entre reinícios e mudanças de rede, pausa em redes limitadas ou restritas, e filtra URLs de relays onion quando o proxy de saída está desabilitado. Reposts que embutem eventos protegidos são rejeitados, e listas de silenciamento são preservadas da exclusão por idade por padrão.

FIPS v0.4.0-rc1 adiciona transporte pela mixnet Nym e descoberta mDNS na LAN

O FIPS é a implementação do protocolo de sincronização em mesh FIPS. A v0.4.0-rc1 é compatível no formato de fio com a v0.3.0, então meshes mistos interoperam e não há atualização em bloco obrigatória. O lançamento adiciona duas novas formas de os nós se encontrarem e se alcançarem: um transporte de saída pela mixnet Nym com uma demonstração em contêiner único e um exemplo de relay de mixnet, e descoberta mDNS / DNS-SD opcional no enlace local. Uma nova consulta show_metrics somente de contadores habilita um coletor Prometheus sem custo no hot path, e o rekey de FMP e FSP foi reforçado para ocorrer sem interrupção sob perda de pacotes em ambas as direções.

Calendar by Formstr v1.6.1 e v1.6.2 adicionam notificações por evento

O Calendar by Formstr é um cliente de calendário NIP-52. A v1.6.1 adiciona preferências de notificação por evento (PR #109) para que um usuário possa ativar ou desativar lembretes de cada evento de calendário individualmente. A v1.6.2 corrige o login com o Amber (PR #185) para que o novo handshake NIP-46 do Amber 6.2.x funcione de ponta a ponta.

Bitchat v1.5.2 e v1.5.3 reforçam o transporte por Nostr e BLE

O Bitchat é um cliente de chat em mesh por Bluetooth e Nostr. A v1.5.2 limita a taxa de notificações de pares no iOS para evitar inundação (PR #972) e reforça a validação Nostr e as checagens de anúncio BLE (PR #1012), de modo que o caminho de ingestão Nostr do lado do relay agora rejeita mensagens malformadas antes que cheguem ao manipulador do mesh local. A v1.5.3 é um hotfix para um crash na inicialização causado por um dispatch_once recursivo entre NostrRelayManager e NetworkActivationService (PR #1343).

Keep v1.0.5 move a superfície de políticas do assinador para o núcleo Rust auditado

O Keep é um assinador Android que encapsula o núcleo Rust keep. A v1.0.5 fixa a versão do keep v0.4.8 e traz uma correção de corrida na inicialização do bunker (PR #296) para que o handshake não perca mais o primeiro evento sob carga, popula a tela de Clientes Autorizados a partir do callback onConnect do bunker (PR #291) e consolida o kill switch em uma única fonte da verdade no keep-mobile (PR #284). O núcleo Rust upstream lançou a v0.4.9 em 13 de junho, que move a superfície de políticas de assinador NIP-55 e NIP-46 (decisão de permissão, limite de duração para kinds sensíveis, expiração, cadeia de auditoria à prova de adulteração com HMAC com chave, confiança no primeiro uso do chamador, limitador de taxa de assinatura persistente) para o núcleo Rust auditado que antes duplicava a lógica em Kotlin, mais uma implementação do cifrador NIP-44 v3; esse núcleo chegará na próxima atualização do keep-mobile.

O ants é a ferramenta de busca e leitura Nostr do dergigi. A v0.4.5 adiciona ações no cartão de artigos para publicações de formato longo, incluindo links de portal de artigo, compartilhamento por naddr específico do artigo, cópia de nevent e acesso ao JSON bruto. O conjunto de portais de artigo foi renovado com a restauração do Habla, a substituição de destinos extintos e a remoção do portal imwald. O lançamento também restaura a renderização de notas de rodapé de artigos com a navegação por âncoras internas preservada, e espera uma conexão com relay antes de buscar o perfil durante a restauração de login, para que o avatar do cabeçalho seja resolvido corretamente.

Morganite v0.0.3 traz um cache Blossom local para Android com Tor sob demanda

O Morganite é um novo cache Blossom local para Android criado pelo greenart7c3 (autor do Amber e do Citrine). O cache atua como um espelho local BUD-08 que poda os blobs menos usados assim que ultrapassa 1 GB. A v0.0.3 inicia o Tor sob demanda e o encerra quando ocioso para poupar bateria, desconecta do relay Nostr após a busca de autor para parar o consumo em segundo plano, corrige o consumo de bateria causado por um fluxo de logcat sem filtro e por clientes HTTP vazados, e libera clientes OkHttp substituídos fora da thread principal. O lançamento também busca os relays de entrada do usuário antes de consultar a lista de servidores Blossom (para que a descoberta de blobs siga o modelo outbox) e baixa o blob em requisições HEAD quando ele não está em cache localmente, o que mantém o aquecimento do cache atrelado à demanda real dos clientes.

Coracle 0.6.34 e 0.6.35 corrigem login NIP-46, feeds obsoletos e alternância de respostas

O Coracle é um cliente Nostr web criado pelo hodlbod. A 0.6.34 corrige o login NIP-46, um estado de feed obsoleto em que a timeline inicial não atualizava depois de trocar de visão, e um alternador de respostas que filtrava tudo quando ligado. O lançamento também reconstrói as visões de feed e de lista, corrige um problema de inset de área segura em um toast e melhora o carregamento de imagens. A 0.6.35 é um pequeno seguimento que corrige reposts sendo ocultados quando respostas estão desabilitadas, para que o filtro de reposts não aplique mais o filtro de respostas em excesso.

O Zeus é uma carteira Bitcoin e Lightning de autocustódia com uma superfície Nostr para wallet connect e pagamentos por noffer. A v13.1.0-rc1 adiciona pagamentos Nostr Wallet Connect NIP-47 sem fila no iOS (em colaboração com a Primal), para que uma fatura NWC paga não fique mais esperando em uma fila em segundo plano, traz suporte a pagamento por noffer CLINK com o Zeus Pay gerando um noffer CLINK para cada conta, para que um remetente possa pagar qualquer usuário do Zeus apenas pela chave Nostr, e adiciona uma opção de recusa de Nostr Zaps no Zeus Pay, para que um recebedor possa desabilitar o caminho de recibos kind 9735 sem desabilitar o NWC.

Alby Extension v3.14.3 migra as pilhas de cripto noble/scure usadas pelo assinador NIP-07

A Alby Extension é a extensão de navegador que oferece assinatura NIP-07 e Nostr Wallet Connect ao lado de sua superfície Lightning. A v3.14.3 migra as pilhas @noble/curves, @noble/hashes, @noble/ciphers, @noble/secp256k1, @scure/bip32 e @scure/base para as versões maiores 2 e 3. Essas são as bibliotecas criptográficas das quais o caminho do assinador NIP-07 depende para assinar eventos e para a cifragem NIP-44, então um salto de versão maior toca o formato de fio que a extensão produz para cada requisição de evento assinado vinda de um cliente Nostr web.

Mostro Mobile v1.2.8 e v1.2.9 dão suporte ao Protocolo v2 e expõem a política de caução

O Mostro Mobile é o cliente móvel do Mostro. A v1.2.8 entrega o suporte do lado do cliente ao Protocolo v2 do mostro-core v0.13.0 (coberto na história principal acima) e adiciona 17 recursos no total, incluindo a caução antiabuso do criador vinda do PR #608, a descoberta de relays por bootstrap vinda do PR #610, o cancelamento de ordem persistido no histórico de notificações vindo do PR #602 e os limites de valor em fiat na tela de criação de ordem vindos do PR #605. A v1.2.9 expõe a política de caução antiabuso a partir do evento de informação do nó (PR #617) para que um usuário possa ver as regras de caução da instância do Mostro antes de abrir uma ordem.

ZapBook builds 4 a 27 trazem multiconta, publicação de chaves Marmot e reconvites de círculos

O ZapBook é um aplicativo de leitura social nativo do Nostr criado pelo codeswot para iOS e Android, organizado em torno de círculos de leitura de 1 a 100 pessoas que compartilham marcos e enviam sats por zap umas às outras como incentivo. Entre a build 4 em 11 de junho e a build 27 em 15 de junho, o projeto lançou 17 builds com tag e incorporou 7 PRs. O suporte a multiconta com troca fluida de contas chegou no PR #25, para que um usuário possa manter várias identidades Nostr no aplicativo e migrar sessões entre elas. A publicação inicial do key package Marmot (kind 443) agora é disparada automaticamente na conclusão do onboarding (PR #20), que é a pré-condição para mensagens de grupo restritas a convidados nos círculos de leitura. O tratamento de membros removidos do círculo agora processa reconvites novos de forma limpa (PR #24), fechando uma classe de falhas em que membros readicionados não recebiam novos convites depois de removidos. A linha de lançamentos também transfere a inferência de embeddings ONNX para um isolate em segundo plano (PR #19) para a busca semântica dentro do leitor, e integra o serviço NWC com um APP_ID_SUFFIX para configurações específicas de ambiente, de modo que um único hub possa servir várias builds do ZapBook.

Alby Hub v1.23.0 corrige a publicação NIP-47 para apps excluídos e migra o Bitrefill para NWC

O Alby Hub é um hub Lightning e Nostr auto-hospedado. A superfície não Nostr da v1.23.0 é grande (canais Just-in-Time, uma página de Cartões para recargas de cartão de débito, um backend experimental de pagamentos Ark e uma página inicial de stories) e fica fora do escopo do Compass. No lado NIP-47, o lançamento para de reenviar a publicação de informações NIP-47 para apps excluídos, de modo que uma conexão removida não fica mais republicando seu evento de informações kind 13194 (PR #2391), e remove a entrada de app personalizado do Bitrefill em favor de uma conexão NWC padrão (PR #2420). A opção somente leitura para apps da loja (PR #2415) aperta os escopos de permissão para apps NWC publicados pela loja interna do hub.

Também lançado

Lançamentos menores desta semana com conteúdo relevante para Nostr mas com substância limitada por versão: Nostria v3.1.48 a v3.1.50, continuando a implantação de Web Bookmarks com confiabilidade de notificações e otimização do banco de dados de threads de eventos na v3.1.50; Deepmarks v0.7.0 a v0.7.5, iterando sobre o cliente de marcadores sociais NIP-B0 (o projeto também incorporou o link do seu site esta semana no PR #96); Keep v1.1.1 a v1.1.4, com quatro correções de build reproduzível para o F-Droid em cima do lançamento do assinador v1.0.5 coberto acima; NoorNote v0.11.1, v0.12.0, v0.13.0 e v0.13.1 no cliente de notas para desktop; Boris v0.12.2 no leitor Boris; Nostr Mail Client v0.13.0; Feeder 2.21.1; nak v0.19.13 como um salto de manutenção vazio na CLI do Nostr; Hashtree v0.2.68 a v0.2.71, renovando caches de raiz mutável de gateway para o publicador de lançamentos endereçado por hash tree; NYM v3.72.501 e v3.72.502, atualizando a implementação de relay baseada em Nostrify; swift-nostr-client 0.3.0, 0.4.0 e 0.5.0, cortando três lançamentos menores respaldados por 85 PRs incorporados no cliente Nostr para iOS; lawallet-nwc v0.11.0 com 18 PRs incorporados na ponte Nostr Wallet Connect da LaWallet; e Astraea v5.35.59 a v5.35.62, iterando sobre o cliente Nostr Astraea; e os bots de DM Nostr verificados por NIP-05 BTC Recharge e giftcardshop, adicionados ao diretório de projetos sob uma nova categoria Shops.

Alterações não lançadas

diVine incorpora 119 PRs rumo à próxima entrega de vídeo curto

O diVine é um cliente nativo do Nostr de vídeos curtos em loop que restaura o acervo do Vine sobre uma espinha dorsal Nostr. O projeto incorporou 119 PRs esta semana sem cortar um lançamento com tag. O trabalho substantivo na superfície Nostr cobre um caminho de publicação de vídeo REST-first, para que um OK de relay ausente não apareça mais como falha (PR #5221 e PR #5220), refiltragem da blocklist nas grades curadas e curtidas quando a blocklist ampla muda (PR #5208), recuperação da lista de conversas de DM após uma regressão de reinstalação (PR #5202), restauração da exibição do emblema Nostr nos perfis (PR #5218) e referências nostr: transformadas em links nas citações de comentários (PR #5225). A pilha do editor de vídeo ganhou junção ou exclusão de clipes com seleção múltipla, canvas com zoom por pinça e faixa letterbox que acompanha o zoom, além de transformações de corte, rotação e espelhamento de clipes.

Pollerama incorpora 15 PRs na janela com retrabalho do assinador e uma onda de recursos

O Pollerama (repositório formstr-hq/nostr-polls) é o cliente nativo do Nostr de enquetes e feeds da família Form*, irmão do Calendar by Form*, que lançou a v1.6.2 esta semana. O último lançamento com tag no nostr-polls é a v1.6.4, de março, então o trabalho da janela está na fila para a próxima tag e ainda não foi lançado, mas o fluxo de incorporações é pesado: quinze pull requests entraram entre 9 e 16 de junho, com contribuições de abh3po, geralt-debugs e SIDDHANTCOOKIE. Do lado do assinador, o projeto substituiu a superfície de assinatura existente no PR #198 e atualizou a substituta no PR #201, e o PR #200 impede que atualizações de metadados kind 0 disparem no login, de modo que uma entrada nova não publique mais um evento de perfil que o usuário não pediu. A onda de recursos cobre um editor de perfil com publicação a partir da visão de perfil (PR #205), um fluxo de repost melhorado (PR #209) e um caminho mais fácil de descoberta de tópicos (PR #202). O próximo lançamento com tag recolherá tudo isso.

Trabalho de bibliotecas e ferramentas

O PR #375 do NDK e o trabalho incorporado nos repositórios rust-nostr e nostr-tools ficaram quietos esta semana, com um ou dois PRs incorporados cada e nenhum lançamento com tag. A atividade no ContextVM SDK (1 PR incorporado), no mesh-llm (37 PRs incorporados, 8 PRs abertos), no Zap Cooking (26 PRs incorporados) e no Routstrd (2 PRs incorporados) continuou sem uma tag de lançamento dentro da janela.

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

O trabalho de protocolo desta semana se concentra em dois lugares: reforço de assinadores e governança de grupos NIP-29.

Incorporados esta semana:

  • NIP-46 (Nostr Connect). O PR #2373 adiciona um método logout que permite a um cliente encerrar uma sessão de assinador remoto de forma limpa. Amber, Clave e Nostur trouxeram suporte todos na mesma semana.
  • NIP-CC (Community Chat). O PR #2365 atualiza o NIP-CC para referenciar a especificação moderna NIP-GC (Group Chat) quanto à maquinaria do lado do cliente, alinhando a especificação de salas comunitárias à primitiva canônica de chat em grupo.

Cluster NIP-29 aberto (governança de grupos baseada em relay):

  • Tags de banner. O PR #2383 adiciona uma tag banner ao evento de metadados de grupo kind 39000.
  • Sufixo de código de convite. O PR #2380 introduz um sufixo de código de convite no identificador do grupo, de modo que um convite de uso único possa ser codificado no próprio ID do grupo.
  • Fixação de mensagens. O PR #2379 adiciona uma ação de moderação para atualizar a lista de mensagens fixadas e um evento kind 39005 para transmitir o conjunto fixado.
  • Denúncia de grupos por DMs NIP-17. O PR #2377 define um fluxo de denúncia em que membros reportam abuso no grupo ao contato administrativo do relay por DMs com gift wrap NIP-17, mantendo o tráfego de moderação fora do fluxo público de eventos do grupo.
  • Controle de acesso baseado em papéis. O PR #2376 adiciona uma superfície de papéis RBAC em cima da divisão existente entre administrador e membro.

Desdobramentos NIP-46 abertos:

  • Metadados do cliente na requisição de conexão. O PR #2381 permite que o cliente que se conecta envie campos opcionais name, url e icon em sua requisição de conexão, para que o assinador possa exibir a identidade do aplicativo na tela de pareamento. A build 101 do Clave implementa a proposta.
  • Evitar timeouts silenciosos. O PR #2375 aperta a especificação para que um assinador que precisa de entrada do usuário mantenha a requisição aberta até o usuário decidir, corrigindo o modo de falha que a build 100 do Clave remendou do lado da implementação.

Outros trabalhos abertos:

  • NIP-100 Sovereign Agent Identity Network (SNIN). O PR #2378 propõe um protocolo agente-para-agente de identidade e descoberta de capacidades de agentes autônomos. A proposta é ampla e provavelmente será dividida em partes menores durante a revisão.

Especificação Blossom. O PR #108 do BUD-00 foi incorporado em 15 de junho, ampliando a definição de BUD para cobrir convenções do lado do cliente e formatos de dados construídos sobre blobs Blossom que os servidores não implementam. A mudança traz BUDs como o BUD-10 (o esquema de URI blossom:) e o BUD-08 (convenções de cache local que o Morganite implementa esta semana) para dentro da superfície canônica de numeração, onde antes eram tratados como extensões fora de banda.

Mergulho profundo em NIP: NIP-77 (Negentropy)

O NIP-77 define um protocolo de reconciliação de conjuntos para relays Nostr. Duas partes (um cliente e um relay, ou dois relays em uma ponte) mantêm cada uma um conjunto de eventos que corresponde a um filtro e querem convergir para a união sem reenviar tudo. A abordagem ingênua é despejar todos os IDs de evento pela conexão e comparar: para um filtro movimentado, esse custo escala com o tamanho do conjunto maior, independentemente de quanto do conjunto difere. O NIP-77 reduz esse custo a algo proporcional à diferença simétrica.

A especificação se apoia em duas mensagens de relay, NEG-OPEN e NEG-MSG. Um cliente abre uma sessão de reconciliação com ["NEG-OPEN", <subscription_id>, <filter>, <initial_message>], em que <initial_message> é um payload Negentropy codificado em hex que descreve a visão do cliente sobre o conjunto. As respostas chegam como quadros NEG-MSG, e os dois lados trocam mensagens até chegarem a um ponto fixo. Cada NEG-MSG ou estreita a discordância (dividindo um intervalo em subintervalos com suas próprias impressões digitais) ou encerra uma folha (listando os IDs em um intervalo pequeno, para que o receptor possa calcular a diferença diretamente). Quando um lado conclui que o outro tem eventos que lhe faltam, ele envia um REQ normal para esses IDs; quando ele tem eventos que faltam ao outro, a especificação deixa o caminho de envio para uma publicação EVENT normal do outro lado.

A estrutura de dados por baixo é uma variante de árvore de Merkle sequenciada. Cada evento do conjunto local é indexado por (created_at, id) e agrupado em intervalos; cada intervalo carrega uma pequena impressão digital calculada a partir dos IDs que contém. Quando uma impressão digital coincide entre cliente e relay, aquele intervalo está convergido e é pulado. Quando difere, o lado que responde divide o intervalo em metades (ou subintervalos) e envia impressões digitais para cada um, descendo recursivamente na discordância. Intervalos folha (abaixo de um limiar pequeno de eventos) são enviados na íntegra. A propriedade central é que intervalos convergidos custam quase nada para confirmar, independentemente de quantos eventos estão dentro deles.

O enquadramento na ordem de created_at importa por duas razões. Primeiro, a paginação já existente do Nostr usa until e since contra o mesmo timestamp, então um reconciliador pode retomar entre sessões sem ressincronizar todo o acervo: ele guarda em cache o limite superior e começa a próxima sincronização a partir dali. Segundo, as divisões de intervalo são determinísticas dada uma chave ordenada, então cliente e relay sempre concordam sobre qual fronteira usar em seguida, sem necessidade de uma mensagem de negociação separada. O custo de uma sincronização é aproximadamente O(d log n), em que d é o tamanho da diferença simétrica e n é o conjunto maior, bem abaixo do custo O(n) de um despejo ingênuo de IDs e bem abaixo das O(n) idas e voltas de emitir N REQs.

Três tradeoffs de implementação se destacam. O tamanho da impressão digital (a especificação usa 32 bytes por intervalo) é um tradeoff entre probabilidade de colisão e largura de banda: impressões menores economizam bytes mas aumentam a chance de uma coincidência espúria que deixa eventos pelo caminho. O limiar de folha (quando parar de dividir e despejar IDs na íntegra) é um tradeoff entre idas e voltas e largura de banda por mensagem: limiares menores significam mais rodadas, limiares maiores significam mensagens de folha maiores. E o protocolo assume que as duas partes conseguem calcular a mesma impressão digital sobre o mesmo intervalo; isso exige uma serialização estável dos pares (created_at, id) com a qual as duas implementações concordem, e é por isso que a especificação é pedante quanto à ordem dos bytes na construção da impressão digital.

Um relay que anuncia o NIP-77 em seu supported_nips do NIP-11 permite que clientes reconciliem no lugar de (ou ao lado de) uma sincronização baseada em REQ. O cliente escolhe o protocolo com base no que precisa: uma assinatura nova que quer o tráfego de cauda usa REQ porque não há estado anterior a reconciliar; um espelho de longa duração que quer se atualizar depois de uma indisponibilidade usa NEG-OPEN porque a diferença simétrica é pequena em relação ao acervo. Os dois caminhos se complementam em contextos de implantação diferentes.

Exemplo de troca NEG-OPEN:

→ ["NEG-OPEN", "sync-1", {"kinds":[1],"authors":["abc..."]}, "<hex initial Negentropy message>"]
← ["NEG-MSG", "sync-1", "<hex relay response>"]
→ ["NEG-MSG", "sync-1", "<hex client refinement>"]
← ["NEG-MSG", "sync-1", "<hex leaf with IDs the relay has and client lacks>"]
→ ["REQ", "fetch-1", {"ids":[...]}]
← [...EVENT messages...]
← ["EOSE", "fetch-1"]
→ ["CLOSE", "sync-1"]

O Citrine v3.0.0 traz suporte a NIP-77 no agregador de relays esta semana, a primeira vez que a superfície de relay local no Android pode reconciliar contra relays externos em vez de puxadas em massa por REQ.

Mergulho profundo em NIP: NIP-61 (Nutzaps)

O NIP-61 define pagamentos em ecash Cashu ponto a ponto entregues como eventos Nostr. Um remetente publica um token Cashu travado à chave pública derivada do Nostr do destinatário, e o destinatário o resgata no mint quando for conveniente. Diferente dos zaps do NIP-57, que exigem que o recebedor esteja alcançável por Lightning no momento do pagamento, um nutzap é um token ecash autocontido que o destinatário pode resgatar no seu próprio ritmo.

A especificação compõe três kinds de evento com a primitiva de trava P2PK do Cashu. O kind 10019 é a recomendação de mints do destinatário: um evento substituível que lista um ou mais mints dos quais o destinatário aceita nutzaps, mais a chave pública Cashu usada para travar as proofs para ele. Essa chave é distinta da chave de identidade Nostr do destinatário; é uma chave com escopo de carteira derivada para recebimento de nutzaps, de modo que a chave de identidade nunca precisa tocar segredos de ecash. Remetentes leem o kind 10019 antes de enviar, para que o token que constroem seja um que o destinatário possa resgatar em um mint em que já confia.

O kind 9321 é o evento de pagamento. Ele carrega uma ou mais tags proof do Cashu (cada uma contendo uma proof travada por P2PK vinculada à pubkey de nutzap do destinatário vinda do kind 10019), uma tag u com a URL do mint, tags opcionais e e a que identificam uma nota zapeada, e uma tag p para o destinatário. O destinatário recebe o kind 9321 por sua assinatura Nostr normal, valida que as proofs estão travadas para sua pubkey de nutzap em um mint listado em seu próprio kind 10019, destrava as proofs com a chave privada correspondente e ou as mantém em sua carteira NIP-60 ou as converte para Lightning. O kind 7375 registra as proofs resgatadas na cadeia de eventos da carteira do destinatário, para que uma carteira que ressincroniza a partir dos relays não contabilize duas vezes as mesmas proofs de nutzap da mesma origem.

O modelo de confiança é o preço explícito do desenho. Mints Cashu detêm o valor subjacente; um mint malicioso ou apreendido pode recusar o resgate. O NIP-61 herda esse risco de custódia do NIP-60 e não tenta removê-lo. O que o desenho compra são micropagamentos com finalidade instantânea e capacidade offline: o token é o pagamento, o destinatário não precisa rodar um nó Lightning nem aceitar HTLCs recebidos em tempo real, e um remetente que detém proofs no mesmo mint pode pagar sem um único salto de rede até um custodiante. O anúncio kind 10019 é o portão na camada social: remetentes que escolhem um mint fora do conjunto confiável do destinatário arriscam um token irresgatável, o que mantém previsível a superfície de resgate do destinatário.

Comparado ao NIP-57, o caminho de verificação também é mais simples. Um recibo de zap NIP-57 é um kind 9735 publicado pelo serviço LNURL do destinatário, exigindo que o verificador busque o endpoint LNURL e confirme que a chave de assinatura do recibo corresponde ao que o endpoint declarou. Um nutzap carrega a prova criptográfica do pagamento embutida (as próprias proofs travadas por P2PK), então qualquer verificador com as chaves públicas do mint pode confirmar que as proofs são válidas sem uma ida e volta a um terceiro. O tradeoff é que a verificação de nutzap exige entender os keysets do mint, enquanto a verificação NIP-57 exige apenas infraestrutura LNURL padrão.

Os dois formatos de zap coexistem como complementares. Zaps NIP-57 seguem sendo a escolha certa para recebedores com roteamento Lightning em funcionamento e para remetentes que querem denominação em sats com semântica de liquidação Lightning. Zaps NIP-61 se tornam a escolha certa para recebedores offline, para fluxos com muitos micropagamentos em que as taxas da Lightning engolem o valor transferido, e para clientes voltados a usuários sem infraestrutura Lightning.

Exemplo de evento de nutzap:

{
  "id": "a5f87fe2d4c8b9a0e3f1c4d5e6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f",
  "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
  "created_at": 1750162800,
  "kind": 9321,
  "tags": [
    ["proof", "{\"amount\":21,\"secret\":\"...\",\"C\":\"...\",\"id\":\"...\"}"],
    ["u", "https://mint.example.com"],
    ["e", "8b39f4e5d6c7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3"],
    ["p", "c5d8a4e3b2a1f0e9d8c7b6a5949382716050403020100ffeeddccbbaa99887766"]
  ],
  "content": "Great post!",
  "sig": "f1e2d3c4b5a6978869504132c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5"
}

O Amethyst v1.12.0 traz renderização nativa de nutzaps NIP-61 esta semana ao lado de sua superfície de carteira NIP-60 (PR #3075), tornando o Amethyst o primeiro cliente Android dominante a renderizar nutzaps recebidos na timeline e a expor visões de saldo por mint na carteira.