Nostr Compass #46

Nesta semana: Mostro adiciona revinculação de identidade assinada. Amethyst traz enquetes privadas para grupos Marmot e sincronização criptografada de configurações entre dispositivos. swift-nostr lança uma verificação que se recusa a assinar events cuja chave pública não corresponde à do signer. Fechamos com Seis Anos de Outubros do Nostr, 2021–2026.

Principais notícias

Mostro

Mostro, o daemon de câmbio peer-to-peer coordenado via Nostr, lançou a versão 0.20.1. Ela adiciona a revinculação de identidade assinada, que a edição da semana passada descreveu como não implementada, e entrega as exportações de reputação que antes existiam apenas no código-fonte. A identidade vinculada assina uma autorização de uso único que nomeia o nó e a nova identidade, válida por no máximo uma hora. O daemon registra o ID do event e faz a troca com um compare-and-swap, de modo que uma assinatura com falha ou uma disputa perdida não altera nada. Os operadores também contam com um RPC auditado, restrito a loopback, que exige um token de autenticação e um motivo. A revinculação não revoga atestações já emitidas.

Merges posteriores ainda não estão confirmados em um lançamento. Um provedor opcional de paridade fixa com o USD adiciona USDT, USDC e DOC ao feed mostro-rates do Nostr somente quando o operador o habilita. Provedores de rede e cotações de moedas retransmitidas não o ativam implicitamente. Uma alteração subsequente renomeia o provedor e sua chave de configuração para pegged, substituindo a chave stablecoins, que nunca chegou a ser lançada. Ela também cota BTC, LBTC e RBTC a uma taxa fixa de 1:1 em sats e publica as taxas como events de kind 30078. Essas premissas de paridade configuradas não garantem nem a paridade nem a liquidação. Verificações de paridade em tempo real continuam fora desse mecanismo. O provedor vem desativado por padrão. As moedas aceitas continuam controlando quais ordens são permitidas; o trabalho de cliente, de protocol-book e de peg-guard é feito à parte. Os timelocks das cauções agora funcionam separadamente do escrow. A expiração anunciada das ordens passa a ser limitada, e a janela para aceitar ordens no livro de ordens fecha antes que uma caução possa expirar. As cauções de maker de 144 blocos já existentes expiram na atualização, e essas ordens precisam ser recriadas. Negociações em andamento e o modo Cashu não são afetados, mas algumas configurações de operador se recusam a iniciar até que o timelock da caução seja ajustado.

Extensão Nostr WoT

A extensão Nostr WoT, um signer de navegador com recursos de web-of-trust, lançou a 0.8.15 com a opção de criar a chave de recuperação a partir de 256 bits de entropia gerada pelo próprio usuário com dados ou moedas. Os lançamentos de dados passam por hash com SHA-256, e os lançamentos de moeda são usados como bits brutos, em uma aba isolada que não exibe a frase de recuperação. O onboarding agora expira quando os relays estão inacessíveis. A versão 0.8.16 adicionou permissões permanentes para autenticação em relay (NIP-42), permitindo que os usuários aprovem o AUTH uma única vez para todos os relays de um site ou para todos os sites conectados (implementação da autenticação em relay). Negações por relay ou por site prevalecem sobre essas permissões, e as revogações são verificadas novamente antes que as solicitações na fila sejam resolvidas. Escopos amplos são sempre uma escolha explícita do usuário e nunca se aplicam ao HTTP Auth (NIP-98). O limite da fila continua em cinco, então as solicitações excedentes ainda falham e são tentadas de novo. Já a versão 0.8.18 une importação e recuperação em um único fluxo que detecta formatos de chave e mostra uma prévia da identidade, e a recuperação compatível com Nosskey mantém a mesma identidade, as contas existentes e as passkeys originais.

O SDK separado para desenvolvedores, nostr-wot-sdk, lançou a 3.0.1 com suporte estável à identidade 1.1. A recuperação por passkey, inclusive via Nosskey, mantém a pubkey original, e o código de provider, de recuperação e de assinatura agora compartilha uma única implementação (código-fonte de recuperação e provider do SDK). Pacotes forwarder obsoletos ainda funcionam, mas os integradores devem migrar para os pontos de entrada mantidos.

Amethyst

Amethyst, o cliente Nostr para Android e desktop, lançou a versão 1.20.0 com enquetes privadas e outros recursos de grupos criptografados Marmot. Entre eles estão votos privados substituíveis, emojis personalizados criptografados, remoção de mensagens por administradores e denúncias, além de mídia fixada à época atual do grupo. O autor não executou novamente as verificações de interoperabilidade entre clientes após a revisão e não testou a alteração manualmente no Android. Ainda há chaves de cache compartilhadas entre ramificações concorrentes que têm o mesmo número de época, e chaves de mídia criptografada podem sobreviver a mensagens efêmeras. A sincronização de configurações armazena seis grupos de configurações do app como dados NIP-78 criptografados. Chaves, signers, carteiras, notificações, decks e marcadores de leitura permanecem em cada dispositivo. A primeira edição de configurações publica os seis grupos. Uma conta somente leitura mantém suas configurações locais, e o comportamento com dois dispositivos de assinatura não foi verificado.

No desktop, as notificações do sistema seguem o filtro de Notificações e ignoram gift wraps externos descartáveis e DMs silenciadas. Tags d não confiáveis com mais de 255 bytes não causam mais erros. Buscas por kind consultam apenas relays conectados e relays de busca da conta, até 200 events em cada um. Os apps usam o tratamento de JSON Kite do Quartz para frames, events, filtros e mensagens NIP-46 e NIP-55, embora a assinatura por esses dois protocolos não tenha sido verificada em dispositivos. Uma divisão de bibliotecas posterior move para bibliotecas compartilhadas as regras de protocolo do Marmot e do cordn de que outros clientes precisariam.

Código-fonte mesclado após a 1.20.0, ainda não incluído em um lançamento, executa o caminho de recebimento Marmot do app sobre a biblioteca compartilhada. Cada mensagem descriptografada é persistida de forma idempotente. Ao entrar em um grupo, o app registra uma linha de base para que a primeira mudança de associação exiba sua linha. Uma mensagem de kind 445 que chega antes do seu commit fica retida e é reproduzida depois, e o catch-up de administrador faz o commit das saídas pendentes. amy cordn migrate export desativa os comandos de sessão da instalação antiga até que haja uma importação ou seja usado o novo comando de retomada. O autor executou testes do amy em loopback e testes das bibliotecas com checkouts locais. Ele não exercitou manualmente o caminho de recebimento do app ao vivo nem executou a suíte de interoperabilidade Marmot. Uma atualização incompatível do formato de napplet NIP-5D proposto lê o hash do manifesto de um napplet como um único artefato /index.html, substituindo o antigo agregado de caminhos, de modo que bundles legados precisam ser republicados. Domínios NAP obrigatórios que estejam indisponíveis falham de forma fechada, e os opcionais simplesmente ficam ausentes. Ícones passam por verificações de hash e de decodificador, o armazenamento é particionado por kind de manifesto, artefato e snapshot, e blobs de recursos usam base64 canônico. Não foram feitos testes manuais em dispositivos, testes entre clientes nem publicação em relays ao vivo.

Recusas em um signer externo agora são tratadas em corrotinas que não tinham proteção, então não derrubam mais o app. Ebooks, revistas e edições do PressStr (kinds 33953, 34609 e 39731) agora são renderizados. PDFs abrem no leitor interno do app, e EPUBs vão para o manipulador do sistema. Os cards mostram tipo e tamanho do arquivo, nunca baixam um PDF grande só para exibir a prévia e buscam edições apenas do autor da revista. O autor não relatou testes em dispositivo Android para essa alteração. Com as prévias avançadas desativadas, invoices e LNURLs aparecem como rótulos compactos copiáveis sem botão Pagar, e os cards de invoice agora mostram horários de expiração. amy gift wrap agora data o seal e o wrap em momentos aleatórios distintos, cada um até dois dias no passado. --no-backdate desativa esse comportamento. O caminho normal de DM recebe sua correção separadamente no Quartz. No desktop, cada card de vídeo controla sua própria reprodução, então cards com a mesma URL não tomam mais o vídeo uns dos outros. O autor testou isso no macOS, mas não com cache frio. Uma correção proposta para links no Windows abre links pelo rundll32 usando seu caminho completo e recorre ao AWT como alternativa. Como a causa raiz não foi reproduzida, trata-se de uma correção provável, e não confirmada.

Myco adiciona armazenamento criptografado para napplets e avisos de atualização assinados

Myco, um host Android para napplets Nostr, lançou as versões 0.12.0 e 0.12.1. Os napplets agora podem armazenar dados NIP-44 autocriptografados por meio do runtime, mas apps com permissões de leitura de relay, outbox ou mesh conseguem ver o texto em claro, então os dados não ficam isolados por app. Usuários que fizeram login com o Amber anteriormente precisam fazer login de novo para conceder as novas permissões de criptografia e descriptografia. Os avisos de atualização são assinados por um publicador fixado e chegam apenas a dispositivos que já executam a 0.12. Online, o Myco pode verificar o Zapstore diariamente e também o Circle, enquanto o modo somente mesh consulta apenas o Circle, substituindo a pausa inicial. Um trilho Blossom local escolhido explicitamente mantém os arquivos no dispositivo, sem servidor, com limite de 64 MiB por app por dia. Uploads com falha para um servidor padrão aprovado também mantêm uma cópia local. Nenhum dos dois caminhos remove metadados EXIF. Os lançamentos também adicionam suporte ao Android TV e um seletor de arquivos NAPFS no qual o próprio usuário escolhe os arquivos.

Lançamentos com tag

Monostr

Monostr, um cliente social Nostr para Android, lançou a 0.26.0, sua versão mais recente. Vídeos de até dois minutos agora são comprimidos no próprio dispositivo, e os metadados de localização são removidos. As telas de descoberta, busca e onboarding oferecem listas de follows curadas. Threads e notificações agora mostram respostas do Fediverso enviadas como comentários NIP-22.

Os recursos da 0.25.0 continuam presentes. Quando o post pai de uma resposta não está disponível, o app pesquisa as dicas de relay da resposta e os relays do autor do post pai, o que significa conectar-se brevemente a relays fora da lista do próprio usuário. Os relays e as inscrições de mensagens em tempo real também se reconectam sempre que o dispositivo muda de rede.

Sidecar

Sidecar, uma extensão de navegador e signer Nostr, lançou a 1.16.3. O compositor e a ferramenta de destaques agora publicam nos relays da própria conta e contam apenas os relays que confirmam o recebimento do event, e em seguida exibem links para esses relays. Uma confirmação mostra que o relay aceitou o event, não que vai mantê-lo. O compositor expandido não recorre mais aos relays padrão definidos nas Configurações. Cada relay tem seu próprio prazo de 12 segundos. Somente uma publicação que falha em todos os relays é tentada de novo, uma única vez, em sockets novos. Os resultados de enquetes também consultam quatro relays públicos em busca de votos. Uma alteração mesclada após a tag adiciona mais um relay para captar votos registrados fora dos relays habituais. Em uma enquete ao vivo, isso elevou a contagem de 21 para 23 votos. Esse é o resultado de uma única enquete e não diz nada sobre a completude em toda a rede. A contagem continua permitindo um voto por pessoa e ignora votos dados após o encerramento da enquete. A versão anterior, 1.16.1, limita as permissões permanentes de assinatura à conta e ao site que as aprovaram, e a um único registro endereçável quando o event tem uma tag d. As permissões nunca abrangem criptografia nem descriptografia. Listas de perfil, follows, silenciados e relays ficam fora de qualquer permissão. Exclusões, zap requests, AUTH de relay e controle de carteira também ficam de fora. Uma extensão bloqueada ainda pede o PIN. Revogar uma permissão ou esquecer um site apaga as respectivas permissões e janelas de aprovação.

Um pull request aberto separado faria com que o pagamento de uma oferta CLINK contasse como zap. Ele está na fila em Unreleased no changelog e não implementa Debits. O painel da oferta passaria um zap request assinado de kind 9734 com payer_data, para que o serviço possa publicar um recibo de kind 9735. Os recibos iriam primeiro para o relay da oferta e depois para os relays do destinatário, sem duplicatas e com limite de seis. Os relays do pagador não são usados. Se uma oferta responder com o código 3 e uma oferta sucessora que possa ser decodificada, o Sidecar a seguiria uma vez, com uma nova solicitação e uma nova assinatura. Ele nunca escreveria no perfil do destinatário. No fechamento desta edição, a alteração ainda não havia sido mesclada.

Roadbeacon

O Roadbeacon, um cliente de relato de localização antes chamado Roadstr e distinto do app independente Roadstr, lançou a versão 0.4.0 com o novo nome como um novo pacote, com um novo formato de event. Relatos e votos agora usam os kinds compartilhados e interoperáveis 1315 e 1316, as coordenadas usam quadros inteiros exatamente reconstruíveis, e a versão web valida assinaturas. O pacote é instalado ao lado do antigo, sem migrar dados. Os events mais antigos continuam válidos nos relays, mas o novo cliente não consegue lê-los.

Jumble

O Jumble, um cliente web de Nostr, lançou a v26.10.1. Entre os novos recursos estão um editor de artigos longos, palavras silenciadas que sincronizam entre dispositivos, notificações do sistema e leitores para conteúdo de grupos e de Git. As mudanças de posts pendentes e de layout abordadas em uma edição recente chegam como parte desta versão.

Um commit incorporado após o lançamento adiciona uma configuração opcional de resposta NIP-22. Ela vem desativada por padrão e é salva como preferência local. Quando ativada, as respostas a notas de texto kind 1 são enviadas como comentários kind 1111. Threads kind 1111 já existentes mantêm sua raiz, e comentários em outros kinds ou em conteúdo externo continuam como kind 1111. Com a configuração desativada, as respostas mantêm o comportamento legado de kind 1. O app avisa que alguns clientes podem não exibir esses comentários.

nostr-idb

A nostr-idb, uma biblioteca que armazena em cache events Nostr no IndexedDB do navegador, lançou a versão 5.1.1 com correções de consultas. Buscas por ID exato agora funcionam para events substituíveis e endereçáveis, e todas as restrições de filtro e os limites por filtro passam a valer, inclusive para gravações pendentes e para o histórico de assinaturas. A poda do cache e os events com timestamp zero foram corrigidos. O tamanho do cache em memória, maxMemoryEvents, tem padrão maxEvents, e o valor zero o desativa.

Manent

O Manent, um caderno criptografado que sincroniza via Nostr, lançou a versão 3.0.0 com notas de voz. As gravações sincronizam criptografadas como as demais notas, e as transcrições são geradas offline com o Whisper depois que o app baixa um modelo. A versão também traz a recuperação de autenticação de relay abordada antes como trabalho no código-fonte, que agora chega pela versão 0.10.1 do NDK, a biblioteca Nostr Development Kit.

NoorNote

O NoorNote, um cliente Nostr para desktop e web, lançou a versão 1.9.2 com busca de texto completo local no dispositivo em notas e mensagens diretas, além de um modo somente cache. A versão 1.9.3 restaura a legibilidade de menus suspensos, menus e toasts após uma regressão de vidro transparente na 1.9.2. Essas versões também trazem o filtro de timestamps futuros que antes existia apenas no código-fonte. Perfis que falham ao carregar agora permanecem em carregamento até que a falha seja confirmada.

Earthly

O Earthly, um cliente Nostr de criação de mapas, lançou a versão 0.1.22 com correções de relay e de pagamento. A autenticação de relay agora está vinculada à conta ativa. Assinaturas e contagens recuperadas distinguem uma contagem indisponível de um zero real e preservam as contagens entre revisões do mapa. Os totais de zap vêm de recibos de zap reais, e o app espera a sincronização da carteira terminar antes de gastar. Pagamentos ao vivo via Nostr Wallet Connect e via mint continuam sem teste (integração da versão).

Chama

O Chama, um cliente de negociação com custódia (escrow) construído sobre events Nostr, lançou a versão 6.4.31, que verifica os backups de seed antes do financiamento. Antes que a chave de negociação on-chain deste dispositivo entre em termos assinados de CREATE, JOIN ou depósito, um relay precisa retornar o backup de seed assinado que o dispositivo abriu; um backup ausente, retirado ou conflitante interrompe a negociação. As novas tentativas reenviam exatamente o backup salvo, sem gerar uma nova seed. A releitura mostra disponibilidade naquele momento, não persistência. Anúncios com várias unidades agora usam pedidos por quantidade. A versão 6.4.30 só contabiliza pedidos de vitrine quando os termos assinados pelo comprador correspondem ao anúncio assinado e protege contra events tardios de terceiros em negociações cujo CREATE assinado tenha data de 1º de dezembro de 2026 ou posterior, enquanto negociações anteriores mantêm o comportamento antigo de expiração (validação de expiração de negociações e de vitrine).

Um pull request aberto, ainda não incorporado até o nosso corte de fontes, permitiria um backup de seed de carteira por identidade. Na inicialização, a primeira criação seria serializada com uma fila na página e Web Locks, e em seguida o estado do relay seria relido. Navegadores separados dependem apenas dessa releitura. Um lock distribuído e o reparo de backups conflitantes já existentes ficam fora desta mudança. Não testamos nenhum caminho que envolva dinheiro.

Linky

O Linky, uma carteira Cashu que sincroniza via Nostr, adicionou transferências on-chain experimentais, protegidas por uma flag, na versão 26.10.7 e no build Android 26.10.8. Um operador humano configurado conclui as solicitações de envio e recebimento em até 24 horas mediante uma taxa, portanto as transferências não são atômicas nem trustless. A mudança de coordenação usa mensagens de app Nostr personalizadas, configuração de operador via NIP-78 e um novo escopo de sincronização de link. Esse escopo sincroniza os envios de ecash pendentes do operador para que os demais dispositivos dele não possam pagar, reembolsar ou liquidar o mesmo envio duas vezes. Um recebimento só é concluído quando a carteira do usuário recebe o valor Cashu correspondente. Operador e usuário se encontram apenas em relays recomendados, e não por meio de listas de relays NIP-65 nem de listas de caixa de entrada de DM; por isso, perder todos os relays em comum pode quebrar a coordenação.

LaWallet

A LaWallet, uma carteira e serviço de contas construído sobre o Nostr Wallet Connect, lançou a versão 2.9.0 e o beta 1.2.0 para Android, ambos adicionando recuperação assistida por cartão NFC para um novo login Nostr (fluxo nativo de recuperação). A recuperação exige um toque de cartão novo e verificado criptograficamente, além de um QR code de recuperação de uso único válido por 15 minutos. Os ativos são movidos em uma única transação, os papéis não são transferidos, as concessões OAuth antigas são revogadas e o login antigo fica vazio. A recuperação por cartão vem ativada por padrão; os titulares de conta podem desativá-la nas configurações de Segurança e revogar códigos pendentes. Uma carteira inacessível agora mostra saldo zero, o que não significa que ela esteja vazia. O beta para Android força a ativação do relato de erros do Sentry em builds que têm um endpoint de relato, mesmo após uma recusa anterior; builds locais e do F-Droid não têm endpoint.

No código-fonte incorporado após a tag, o callback do cartão pode retornar OK antes da liquidação via NWC quando o saldo cobre o pagamento, então sistemas de ponto de venda precisam confirmar a própria fatura. Um limite fixo de pagamento substitui o limite baseado no saldo. Um pull request aberto, ainda não incorporado até o nosso corte de fontes, permitiria o login com passkeys compatíveis de outros apps por meio de um provedor configurado ou da recuperação Nosskey, confirmando a conta antes de emitir uma sessão temporária com expiração (#386). Um provedor pode assinar sem importar a chave privada, e a importação é uma escolha separada e confirmada. As capturas de tela do pull request mostram respostas de demonstração simuladas, não uma prova de login cross-origin ao vivo.

Outro merge, também não confirmado em uma versão lançada, impede que o callback de NWC e de Lightning address substitua a carteira remota de um usuário apenas por causa de um erro de make_invoice. Em vez disso, uma verificação de disponibilidade e de saldo pode manter a carteira e retornar um 503. O serviço também memoriza saldos e o estado de fundos protegidos, e adiciona uma opção Restore. Seus limiares e o histórico anterior desconhecido restringem o que ele consegue proteger, então ele não garante que todos os fundos estejam seguros. Não se alega nenhuma implantação nem nenhuma conta de usuário restaurada.

KithMoot

O KithMoot, um app baseado em Nostr para chat em salas e chamadas, agora funciona sem os serviços públicos de seu publicador. Entre 21 e 23 de outubro, o publicador desativou os códigos públicos de reunião, o serviço TURN compartilhado, os uploads de arquivos e as leituras de arquivos armazenados. Links de convite substituem os códigos de reunião, e os arquivos públicos passam a usar o Yakihonne por padrão, com um aviso no primeiro envio, embora os usuários possam escolher o próprio servidor. As chamadas ainda tentam primeiro uma conexão direta, enquanto o Hide IP exige um servidor TURN funcional e nunca recorre à conexão direta. No desktop 0.1.102 e no Android 0.6.106, o STUN público da Cloudflare substitui o do publicador, e os usuários podem definir o seu próprio. As cópias de backup servidas foram excluídas, enquanto as cópias criptografadas offline permanecem. O desktop 0.1.109 e o Android 0.6.121 bloqueiam o chat quando as credenciais do dispositivo expiram, preservando os rascunhos, e leem o nome de perfil do próprio usuário separadamente das consultas opcionais ao diretório. O mecanismo comum de chamadas não migrou para a prévia experimental do realtime SDK, e o candidato de grupo MLS continua desativado por padrão.

O desktop 0.1.110 adiciona visualizadores de anexos em sandbox para imagens, áudio, vídeo e PDFs no desktop e na web. No desktop, eles rodam em um renderer Electron dedicado e não persistente, sem acesso ao Node, sem armazenamento do aplicativo e sem acesso à rede externa. O streaming é limitado, e os visualizadores são descartados ao serem fechados ou quando uma mensagem é retirada. A execução em WebKit do pull request e uma execução extra empacotada com SVG hostil travaram e não são apresentadas como verificadas, e nada disso constitui uma certificação de segurança. O build para macOS é notarizado, enquanto o de Windows continua sendo uma prévia sem assinatura.

Um merge posterior, que não se demonstrou estar na 0.1.110, renova credenciais de dispositivo expiradas com base no horário do relógio após a suspensão e antes do envio, mantendo o rascunho enquanto o signer responde. Ele vem depois de a credencial de um testador expirar durante a noite em um laptop suspenso. Uma solicitação ao signer que nunca retorna ainda mantém a renovação em aberto, e o Android tem uma lacuna de renovação separada e não resolvida. Um pull request aberto, ainda não incorporado até o nosso corte de fontes, pausaria o recurso Help other people connect. Segundo o autor, o app aceita um par de assistência entre pares sem transportar a mídia dele, o que pode impedir o fallback para um encaminhador ou TURN e resultar em uma chamada silenciosa. O padrão da biblioteca permaneceria inalterado.

Marmot TS

A marmot-ts, uma biblioteca TypeScript para o protocolo de mensagens em grupo criptografadas Marmot, lançou a v0.8.0 e a v0.9.0 com mudanças incompatíveis. A mídia criptografada V2 adiciona vinculação à origem e descriptografa mídia atrasada após uma reinicialização, e os descritores de upload do Blossom, os destinos e o texto cifrado são validados antes da assinatura. Grupos persistidos fazem backfill em páginas, com nova tentativa para commits incertos. Os apps agora precisam fornecer stores duráveis de ingestão e de rewind cujos adaptadores rejeitem leituras que falharam ou excederam o tempo limite. Grupos V1 legados precisam ser recriados, já que os helpers V1 permanecem apenas para histórico.

Código-fonte incorporado posteriormente dá aos observadores de key-package, de convites e de histórico um AbortSignal opcional. Os listeners deles são limpos prontamente no retorno, em um throw ou no descarte, mesmo enquanto uma leitura de armazenamento ainda está pendente. Mudanças que chegam enquanto um consumidor está pausado ficam retidas e são mescladas em uma única atualização. A leitura subjacente no backend continua após o cancelamento. Falhas de consulta ainda resultam em rejeição, e a mudança não certifica interoperabilidade em tempo de execução.

Cliente de e-mail Nostr

O nostr-mail-client, um cliente de e-mail construído sobre Nostr, lançou a v0.19.0 com um único fluxo de login para bunker, nsec e ncryptsec, incluindo a aprovação do auth_url de um signer remoto. Agora ele acompanha mudanças nas listas de relays de DM, de caixa de entrada, de caixa de saída e privados sem exigir um novo login, elimina notificações de e-mail duplicadas durante a sincronização e sincroniza assinaturas de e-mail entre dispositivos de forma criptografada. Anexos de e-mail acima do limite de 25 MB são descartados com um aviso, e um endereço somente Nostr não pode receber respostas enviadas por e-mail.

CLI de conformidade do Napplet

O napplet/web, os pacotes web e as ferramentas para napplets (apps web distribuídos como events Nostr assinados), agora entrega o trabalho de verificação da edição passada no versionado @napplet/conformance-cli 0.4.0. Antes de uma execução headless, a CLI verifica o ID do event do manifesto, a assinatura e o hash exato do HTML bruto, e relata falhas de binding de runtime, de namespace e de instalação separadamente dos erros do napplet. O fallback embutido cobre apenas RESOURCE e GAMEPAD, então hosts personalizados precisam passar explicitamente as entradas de origem e de snapshot.

O comando deploy do Napplet agora prepara listagens no Zapstore por padrão, capturando screenshots de cada build selecionado e preparando um event kind 32267 Software Application; --no-screenshot e --no-zapstore desativam essas etapas. Preparar metadados não é publicar uma versão, e a mudança não adiciona nenhum event de release de pacote nem de asset.

napplet-soy

napplet-soy, um workspace para criar e publicar napplets, marcou sua ferramenta de linha de comando soyli com as tags v0.31.2 e v0.31.3, que não constituem uma implantação do Studio. Depois que a entrega via Git é confirmada, a publicação marca como mescladas as propostas de colaboração Git (NIP-34) incluídas, após verificar a ancestralidade exata e o alvo junto com a revisão atual, e reaproveita status pré-assinados ao retomar. Revisões mais novas das propostas continuam abertas. Uma tag que contém um commit não é tomada como prova de que o branch de destino o mesclou. O código-fonte por trás dessas tags também adiciona uma visualização inicial de carteira Cashu (NIP-60) em um workspace Manage unificado e mantém os napplets em execução ativos durante trocas de aba. Já o atualizador anterior, da v0.31.1, acompanha o ID estável do repositório no GitHub, de modo que as instalações mantêm suas contas e projetos na mudança para a Soytec. Instalações com o atualizador mais antigo precisam executar o instalador uma vez.

A carteira Cashu NIP-60 resgata nutzaps NIP-61 e salva as saídas de mint preparadas e as atualizações de relay assinadas antes de executá-las, para que solicitações incertas possam ser recuperadas sem repetir um pagamento. As carteiras permanecem isoladas por conta, e abas do navegador não conseguem gastar ao mesmo tempo. Os testes, porém, usaram mints falsos, e a interoperabilidade com dinheiro real não foi verificada. As páginas de contribuição agora aceitam zaps direcionados ao autor, pagando ao autor que assinou a versão ou a proposta escolhida.

As notas da tag soyli v0.31.4 citam histórico de contribuições do autor e zaps, além de mudanças de prontidão para NIP-5D, de áudio e de testes. Chamadas de domínio não esperam mais que o shell informe que está pronto. Um host compartilhado coordena o áudio que os napplets controlam por meio de NAPMEDIA, sem afrouxar o isolamento dos iframes. Esta tag também não é uma implantação do Studio. Das verificações configuradas, cinco passaram e cinco foram puladas. A conformidade total continua não comprovada, e os apps corrigidos aguardam republicação.

Pakstr

Pakstr, uma ferramenta de linha de comando que compila apps Android e os publica no Nostr, lançou a tag v0.29.1. Antes de publicar, ela lê o certificado de assinante que um APK declara em seu bloco de assinatura v2 ou v3 e compara o SHA-256 desse certificado com o sidecar esperado e com a prova de identidade (revisão de publicação). APKs sem assinatura, malformados ou com múltiplos certificados são recusados. Sidecars obsoletos são removidos na recompilação, e uma nsec de publicação inválida falha antes da compilação. O parser não verifica a assinatura do APK em si, tarefa deixada para o Android e o apksigner; assim, ele detecta builds obsoletos, sem assinatura ou com o certificado errado, mas não consegue provar que um build não foi forjado. ZIP64, múltiplos assinantes e rotação de chaves não são suportados.

MDK

O MDK, SDK e runtime para os grupos criptografados do Marmot, lançou a v0.14.0 estável. A versão traz handoff e armazenamento de arquivos de mídia, recuperação ordenada do que chegou enquanto o app estava offline, preservação da lista de seguidos e rekeying do SQLCipher com chave bruta, sem mudanças no MLS nem no formato de transmissão. O guia de lançamento da 0.14.0 e o guia de integração da 0.14.0 exigem que os apps distribuam um conjunto correspondente de bindings, biblioteca nativa e headers, que o MarmotKit 0.14.0 empacota para Apple e Android. Nas plataformas da Apple, o binário é um XCFramework estático bruto. Por isso, os apps o combinam com o binding Swift correspondente e copiam o recurso PrivacyInfo.xcprivacy dele para o produto wrapper que definirem; passar nas verificações de archive do release não prova que uma exportação para a App Store terá sucesso. O banco de dados e o armazenamento migram em um único sentido, com o rekeying de cada página uma única vez. Downgrades continuam sem suporte. As mídias da conta e os dados de handoff devem ficar fora dos backups. O agente WN continua em pré-lançamento, e os crates não estão no crates.io. Limitações conhecidas persistem: um histórico que chega com mais de cinco epochs de atraso se torna indecifrável sem aviso. Mídias perdidas em trânsito durante um avanço de epoch continuam sem correção, e um problema de compatibilidade na ordenação do contexto de grupo também permanece.

A ancestralidade das tags mostra que a tag estável também inclui cinco mudanças de sincronização e mídia. As atualizações de assinatura de grupo reempacotam apenas as famílias de lotes REQ que mudaram. Uma família que falhou mantém suas rotas ativas para a próxima sincronização, enquanto o commit parcial ainda informa uma sincronização com falha. Envios e alterações de grupo continuam entrando na fila durável quando uma atualização anterior ao envio falha, embora a conclusão possa ficar como CompletionUnknown. O REQ de um relay inacessível continua pendente sob o mesmo ID até a reconexão, então uma cobertura degradada não equivale a um histórico completo. A aprovação de reparo no onboarding aguarda todas as fontes de descoberta e retorna RetryableFailure quando uma fonte declarada excede o tempo limite. Com a retenção de mídia por conta, opcional, que vai de “Manter para sempre” até 30 dias, as mídias são limpas pelo horário de recebimento ou do último novo download explícito, e não pela última visualização, sem apagar o histórico de mensagens. Os hosts precisam tratar o novo valor de FFI CleanedBySetting.

Depois da tag, o código-fonte mesclado deu continuidade a trabalhos de múltiplos dispositivos e push que nenhum release ainda reivindica. As solicitações de histórico feitas após a entrada no grupo persistem entre commits e reinicializações, fechando uma lacuna entre o Welcome e as mensagens ao vivo. Contar membros por conta acaba com avisos falsos sobre uma pessoa quando um segundo dispositivo entra ou sai. Além disso, o tratamento de Welcome ignora entregas destinadas a dispositivos irmãos sem fazer a entrada falhar nem consumir uma chave. No push, o MDK propaga via gossip registros e tombstones assinados pelo dono após commits em um novo armazenamento de gossip de push, recompartilha tokens após adições de membros e notifica todos os dispositivos de um destinatário, embora os próprios dispositivos do remetente ainda não recebam notificação. Um preenchimento aleatório novo a cada gatilho impede que a desduplicação suprima despertares. A publicação de KeyPackages adota as listas de relays da própria conta e falha, preservando a lista armazenada, se uma lista estiver incompleta ou não tiver nenhum relay utilizável. Status de mídia tipados para epoch obsoleto e para estado de grupo ainda não resolvido indicam aos apps se devem fazer o upload de novo ou sincronizar e reenviar. Já as mudanças de estado de transferência chegam imediatamente, com o progresso em bytes agrupado em lotes.

O código-fonte mais recente de account-device representa progresso rumo a um release posterior, e não uma 0.15 estável. Três nightlies de 28 de outubro, rotuladas como apenas para testes, estão fixadas no commit b8d0a49, que é anterior a merges posteriores, então seus assets não contêm todo esse trabalho. O MDK seleciona KeyPackages compatíveis por dispositivo para até 20 dispositivos recentes por conta, e sair da conta retira apenas o slot de publicação deste dispositivo. Pacotes novos duram 30 dias mais uma hora e são renovados de seis a sete dias após a publicação. A descoberta procura todos os dispositivos, mas falhas de relay podem deixar alguns de fora; convidar de novo pode ajudar, sem garantia de recuperação automática. Verificações de capacidade autenticadas por folha substituem o cache por conta. Novos grupos exigem o componente account-devices 0x800d quando todos os fundadores o suportam, e dispositivos atualizados agora o anunciam. Esses grupos rejeitam dispositivos mais antigos que não têm o componente, enquanto os grupos existentes permanecem inalterados. Sob essa exigência, o MDK rejeita dados de componente, folhas sem suporte, mais de 20 folhas por conta e tentativas de remover a exigência, deixando grupos legados e grupos sem a exigência como estavam. Separadamente, ele recusa dados iniciais fornecidos pelo host para componentes de app cujo schema não tem dados antes que qualquer grupo, Welcome ou event seja criado.

Em grupos 0x800d, o engine ganha autoridade para adicionar e remover dispositivos da própria conta, com uma classificação de commits que considera o estado pai. Ela separa commits de autoatualização, de autorremoção, da mesma conta e de admin, e o privilégio de mesma conta exige propostas por valor. O tratamento de Welcome correspondente aceita Welcomes da mesma conta apenas nesses grupos e somente após as verificações de estado do componente e de assinatura; outros grupos ainda precisam de um admin ativo. Intenções de envio para adicionar e remover dispositivos da própria conta recebem uma vez justa no agendador, mas as APIs de app ainda não expõem intenções de envio da mesma conta. A remoção da própria folha de um dispositivo agora define sua associação local, de modo que a presença de um irmão não mantém mais as ações de membro de um dispositivo removido.

O gossip de push adiciona anúncios kind 447 em fila durável, com prefixos de digest de 8 bytes de registros e tombstones, enviados na entrada, quando um registro muda e em uma cadência de mensagens de sete dias. Os pares reparam registros assinados pelo dono que estejam faltando por meio de respostas classificadas e escalonadas, com supressão de duplicatas e um limite de 24 horas por folha. Na recuperação, as operações de corte e cancelamento não inventam mais perdas novas, e 24 tentativas sem progresso estacionam uma obrigação atrás de um aviso de histórico incompleto. O registro de cobertura funciona apenas como gravador sombra. Enquanto isso, uma varredura fatiada no tempo retoma fatias começando pelas mais antigas, ainda sem um agendador de produção. Arquivos de auditoria opcionais expiram 30 dias após a última gravação, com limpeza na inicialização e a cada hora. A exclusão pode ocorrer um dia depois; o log de segurança separado de revelação de chaves fica fora dessa expiração.

Um crate de pareamento usa X25519 efêmero, um commitment, uma comparação de sete emojis que o usuário confere nas duas telas e confirmações HMAC que terminam em um ConfirmedLink. Seu adaptador de transmissão cobre apenas o transporte e fica desativado por padrão até que exista uma especificação. A UI e as etapas seguintes de Welcome e de vínculo de grupo estão inacabadas, e a interoperabilidade desta implementação continua não verificada. O código-fonte do device-roster 0x800e aplica atualizações por diff a um grupo oculto de conta única, mas anunciar 0x800e exige uma substituição da política de teste, então builds de produção ainda não conseguem criar um grupo de dispositivos nem entrar em um.

Outras propostas do MDK continuam abertas. Uma delas deixaria de tratar o término de um NIP-67 como prova de cobertura completa, porque a varredura não agendada não oferece garantia de completude. Outras adicionariam replay de checkpoint, reentrada automática e ativação de 0x800d em grupos existentes. Em uma verificação de status recente, três propostas anteriores de API nativa ainda estão abertas. A recuperação de anexos históricos inspecionaria os slots de origem e verificaria o digest autenticado e a expiração antes de gravar os bytes verificados em um arquivo privado sob lease, mantendo a linha do tempo sem acesso à rede; uma cópia entregue é um snapshot que não pode ser revogado. Handles de seleção de chats que abrangem o filtro inteiro cobririam todos os chats que correspondem a um filtro, além da página carregada, excluindo os que chegarem depois. Por fim, a seleção de admins fundadores na criação de grupos pelo wn-agent escolheria admins fundadores convidados e rejeitaria não membros antes do upload.

nosfry

O nosfry, um relay Nostr escrito em Rust, lançou o nosfry v0.2.0 para suas edições nativa e Workers/SQL. A versão traz recursos que não tinham sido lançados na v0.1: exclusão NIP-09, expiração NIP-40, AUTH NIP-42 com events protegidos NIP-70, COUNT NIP-45, sincronização Negentropy NIP-77, solicitações de desaparecimento NIP-62 e a API de administração NIP-86. Também adiciona assinaturas limitadas, com um orçamento de saída e uma política de escrita, e descreve o permessage-deflate como ativado por padrão. Suas alegações de desempenho e conformidade não foram reproduzidas de forma independente, e o projeto não afirma interoperar com todas as implementações.

Quatro mudanças de hardening foram mescladas em 25 de outubro, depois da tag 0.3, e não estão em nenhum binário lançado. Os buckets de conexão e de limite de taxa do Worker agregam IPv6 por /64, enquanto a blocklist de IPs do NIP-86 ainda corresponde a endereços exatos (#78). As varreduras NEG-OPEN debitam o orçamento global de memória de sincronização em passos de 1024 registros durante a coleta (#73). Grupos de empate com o mesmo timestamp mantêm um heap limitado pelo limite da consulta (#72). Snapshots de moderação do NIP-86 se aplicam a leituras armazenadas e à entrega ao vivo tal como foram capturados no momento da requisição, então uma requisição aberta não incorpora novos banimentos instantaneamente (#68).

Um merge adicional, também não lançado, limita o escritor a um orçamento de 64 MiB em bytes e esvazia os backlogs de publicação em transações maiores, cada uma limitada pelo trabalho realizado, mantendo a sincronização durável do LMDB. Os números de benchmark do projeto vêm de suas próprias variantes de sonda, e não de medições nossas.

nostream

O nostream, um relay Nostr em TypeScript, lançou o nostream 3.7.0 e o nostream 3.8.0. A versão 3.7.0 traz as operações administrativas, os logs de auditoria, os webhooks assinados e as métricas que antes relatamos como disponíveis apenas no código-fonte. Ela também acrescenta um ciclo de vida opcional (opt-in) para escritas pagas e corrige a interpretação de horários ISO e a expiração para o LNbits 1 e versões posteriores. O espelhamento estático foi removido, e suas configurações agora são ignoradas com um aviso, em favor da sincronização via NIP-77. A imagem de contêiner da 3.7.0 não foi publicada porque sua tag Docker continha um @ inválido; a 3.8.0 corrige as tags e adiciona novas execuções para builds de imagem que falharam. Na API administrativa e no console, a versão 3.8.0 também traz listas de pubkey e de kind, além de controles de bypass de IP e de limite de taxa, com estatísticas sobre os principais publicadores, IPs e ocorrências de limite de taxa. Além disso, corrige uma colisão de chaves no Redis ao trocar a estratégia de limite de taxa ou ao atualizar. Só o código-fonte não confirma que as imagens agora são publicadas, e nenhuma cobrança implantada é alegada.

Uma reescrita separada em Rust, no branch rewrite/main, mesclou em 740ef69 seu primeiro núcleo de protocolo de rede capaz de responder a um cliente real, e em 2b2287f o registro de estratégias implementa os 14 ramos de estratégia restantes. Esse protótipo, que não é o padrão, permanece separado do main em TypeScript e das versões estáveis 3.x, e seus resultados de revisão e de CI vêm do próprio autor. O tratamento de NIP-43 e de NIP-56 continua desativado por padrão. Uma solicitação de vanish ainda pode perder uma condição de corrida para uma publicação concorrente, portanto o vanish não é uma garantia de privacidade. Continua de pé o pedido do autor por revisão manual do código de acesso e de identidade.

swift-nostr

O swift-nostr, um SDK Nostr em Swift, publicou a 0.9.0 em 27 de outubro. A versão adiciona chaves, IDs de event, URLs, timestamps, coordenadas e IDs de subscription tipados, EventTemplates que qualquer signatário local ou remoto pode assinar, erros tipados, subscriptions pertencentes ao pool e roteamento RelayRoute pelo pool, por relays exatos ou pelo outbox da NIP-65. Event.verify agora lança um erro diante de uma assinatura inválida, então migrar da 0.8 exige mudanças no código-fonte. A versão anterior, 0.8.0, foi uma versão de endurecimento cujas notas dizem que ela verifica events substituíveis, remetentes de gift wrap e respostas NIP-46 e NWC, remove duplicatas de respostas vindas de múltiplos relays e adiciona criptografia NIP-44 conduzida pelo signatário ou com chave compartilhada, com verificações de zap mais rígidas como mudança incompatível. Essas são alegações do autor, não uma auditoria.

As correções posteriores à 0.8 que cobrimos antes agora são distribuídas na 0.9.0. Os signatários recusam events cuja chave pública difere da sua própria, e cancelar uma subscription não abre mais um relay desconectado para enviar CLOSE. A chamada de envio principal lança notConnected e a abertura de subscriptions conecta explicitamente, embora os transportes NWC e NIP-46 ainda reconectem um relay que caiu quando há uma nova solicitação. Chamadas NWC e de signatário remoto recebem erros tipados e cancelamento imediato, embora uma solicitação já enviada ainda possa ser executada. Os fluxos de notificação NWC e de desafio de autenticação terminam quando os relays encerram, as esperas de conexão falham assim que todos os fluxos de relay terminam e as consultas de tag em filtros são armazenadas uma única vez, com uma chave JSON por tag. Um WalletConnectRequest genérico suporta métodos NIP-47 personalizados de resposta única com as verificações usuais de result_type e de erro, enquanto multi_pay permanece separado. Já um RemoteSignerMethod extensível chama métodos NIP-46 além do conjunto embutido e retorna a string de resultado; em ambos os casos, a carteira ou o signatário precisa suportar o método. Com EventTemplate com signer.sign, signatários remotos NIP-46 podem usar auxiliares, como pedidos de zap, que antes exigiam um EventSigner local, com mudanças complementares em vários modelos de dados e nos builders de NIP-29 e de NIP-98. Essa mudança altera a API, não o formato de transmissão.

O código mesclado depois da tag 0.9.0 não faz parte dessa versão. Agora, um chamador que cancela um envio mantém os relays saudáveis, e os tipos de abertura e de resultado de DM ficaram mais simples, com o autor do rumor vinculado ao signatário. FileAttachment unifica os metadados de arquivos criptografados. Um único par setSigner e removeSigner impede que uma definição remota obsoleta desfaça o logout; removeSigner interrompe as respostas AUTH, mas não revoga solicitações remotas já enviadas. As configurações de reconexão e de deduplicação ganham seus próprios tipos de configuração.

haps

O haps, um instalador de software assinado com chaves Nostr, lançou o haps v0.1.22. Ele se baseia no haps v0.1.18, que executava builds a partir do código-fonte no Linux e no macOS em um diretório home privado e em um checkout gravável, com acesso à rede desativado por padrão. As opções explícitas allow-build-network e allow-host-build podem substituir esse comportamento. No Windows, builds a partir do código-fonte exigem host-build. Os apps instalados ficam fora do sandbox. O haps v0.1.19 adicionou uma única confirmação de auditoria e instalação que vincula o código-fonte fixado e a receita de build ao hash do payload compilado, de modo que um binário correspondente do publicador possa ser instalado sob a política desse build revisado. Reutilizar uma revisão confiável não conta como mais uma auditoria independente. Instalações a partir de catálogos assinados imutáveis ainda exigem uma auditoria, e avisos publicados precisam de um consentimento separado cujo padrão é Não. A versão 0.1.22 adiciona consultas limitadas e verificações de publicador com código-fonte completo. As consultas agora compartilham prazos curtos, com o cliente iniciando as consultas depois que o primeiro relay se conecta, e as buscas de snapshot retornam os resultados verificados encontrados dentro de um único orçamento de 3 segundos. Antes de alterar qualquer ref de código-fonte, a publicação se recusa a rodar a menos que encontre um helper git empacotado qualificado, um helper instalado separadamente que corresponda ao binário companheiro fixado ou um helper que anuncie complete-blob-dag-v1. Foram mantidas a cobertura básica de revisão de dependências, as proteções contra symlinks e de tamanho e as novas tentativas limitadas, o que não constitui uma nova auditoria independente. Uma única instalação a frio bem-sucedida não demonstra que os timeouts intermitentes de transferência foram corrigidos, e os pacotes de helpers fixados ainda dependem da toolchain do host.

O Swarm protege sua API administrativa com autenticação NIP-98

O Swarm, um servidor de publicação e administração conectado ao Nostr, lançou a v0.2.0 com autenticação HTTP NIP-98 para sua API administrativa, ao lado do cookie já existente do painel. O servidor verifica a assinatura do event de kind 27235, uma janela de timestamp que vai de cinco minutos no passado a um minuto no futuro, o método HTTP, o caminho e a query, a pubkey fixada do operador e um hash de payload opcional. Aceitar um host encaminhado pressupõe um proxy confiável à frente. O endpoint /environment, antes público, agora exige autenticação administrativa.

Uma mesclagem posterior, não confirmada em nenhuma versão lançada, adiciona crossposting opcional para o X das notas de kind 1 dos membros vinculados da equipe. Notas agendadas e notas que chegam via WebSocket passam pelo mesmo caminho. Respostas com tags e são ignoradas, nada é publicado retroativamente e duplicatas são removidas pelo ID do event. No lado do CMS, usa-se autenticação NIP-98. A publicação depende de OAuth local ou de um serviço delegado confiável, portanto não é descentralizada nem livre de confiança. A publicação no serviço X de produção não foi testada.

O fips2go ativa links diretos para domínios de malha verificados

O fips2go, um cliente de malha para Android que encontra pares e reivindicações de domínio por meio de anúncios Nostr, lançou as versões 0.9.6 até a 0.10.0. A versão 0.10 ativa links diretos por padrão para os servidores de até dois domínios verificados mais recentemente, contando apenas domínios fixados via DNSSEC ou por múltiplos resolvedores. Esses links expõem a esses servidores o endereço IP público do celular e os horários em que ele fica online, além de revelar a escolha de servidor aos relays públicos, mas os usuários podem desativá-los. Um registro TXT já fixado para um servidor e uma porta exatos agora é resolvido sem uma nova reivindicação Nostr, enquanto servidores novos, portas alteradas e registros sem porta ainda aguardam. Quando uma troca de rede exige novas rotas de VPN mas a configuração não mudou, o app substitui apenas o túnel e mantém seu nó, seus links e suas sessões. Mudanças de hotspot, outras mudanças de configuração e o fallback em caso de falha ainda reconstroem o nó.

O fips-pub-domains responde a consultas fixadas antes de buscar reivindicações

O fips-pub-domains, que resolve vínculos assinados via Nostr entre domínios públicos e endereços de malha, lançou a 0.2.9 e a 0.2.10. Um registro TXT fixado para um servidor e uma porta exatos agora pode responder antes que termine a busca de reivindicação em segundo plano, sob a mesma política de fixação, enquanto um servidor ou uma porta novos ainda aguardam uma reivindicação. Na inicialização do desktop e após mudanças de rede, o resolvedor pré-aquece até 16 servidores fixados, revelando a presença online a eles e aos nós de roteamento. Durante o primeiro backoff de 20 segundos, ele tenta novamente a cada três segundos e termina mais cedo assim que um servidor responde.

Duas mudanças mescladas depois dessas tags ainda não foram lançadas. Uma adiciona um papel ServiceClaim fips-ca sem porta, com sua própria cadeia DNSSEC e atestação, separado de fips-dns, sem lançar uma nova PKI nem alterar a política de vinculação DNS. A outra adiciona os comandos de CLI verify e zone, que leem arquivos de fixação sem gravá-los. Nesse código, uma atestação carrega apenas sua própria testemunha anterior, e as demais entradas de papel são reverificadas. Uma opção require-previous recusa dados ausentes, mas não consegue distinguir uma indisponibilidade de um registro inexistente.

Codr

O Codr v0.8.0, uma ponte para controlar sessões de programação no desktop por meio de chats criptografados do White Noise, adiciona uma atualização do worker que é confirmada no chat e precisa ocorrer em até dez minutos. Essa atualização obtém registros ngit de um mantenedor fixado e bytes do Blossom verificados por checksum, sem fallback para o GitHub. Mudanças de conector ou de coorte de armazenamento são recusadas e, se a inicialização falhar, o executável antigo é restaurado. Até agora, a atualização só foi executada contra fixtures de teste. Arquivos e mídia agora chegam a uma sessão ocupada sem interrompê-la, com limite de 25 MiB e quatro anexos. A transcrição opcional pelo Gemini envia notas de voz descriptografadas ao Google e vem desativada por padrão. As versões 0.4 a 0.7 passaram a entregar texto do celular em sessões ocupadas, adicionaram /cancel e menus de projeto, agente e modelo e migraram para o MDK 0.14. A migração a partir da 0.13 funciona em uma única direção e exige backup e aprovação.

Um chat de controle opcional, exclusivo do proprietário (control_chat=true, desativado por padrão), cria seu grupo na próxima inicialização do worker. /new inicia uma sessão de projeto antes que qualquer chat seja vinculado. Se a criação for incerta, ela não é repetida automaticamente.

Um pull request aberto, ainda não mesclado no nosso corte de fontes, permitiria que a criação de grupo para uma nova sessão de programação tratasse como vazia uma transcrição que ainda não foi gravada. Transcrições inválidas ou ambíguas continuariam sendo rejeitadas. Com isso, voltariam a funcionar os convites pelo celular para sessões /new novas antes do primeiro prompt, sem mudar a forma como as sessões são autorizadas.

nostr-media

O nostr-media 0.17, um plugin de WordPress para hospedar mídia Nostr, reforça o espelhamento do Blossom. Agora ele verifica a autorização de hash assinada de kind 24242 antes de buscar uma URL de espelho, recusando solicitações não autorizadas sem baixar nada. As buscas usam a API HTTP segura do WordPress, que permite apenas hosts HTTP(S) públicos e valida redirecionamentos, com limite de 20 segundos, três redirecionamentos e 128 MiB, e os bytes baixados continuam passando por hash e verificação. Os cabeçalhos Authorization, X-SHA-256 e X-Content-Type são comparados sem diferenciar maiúsculas de minúsculas. A proteção contra falsificação de solicitação do lado do servidor é apenas tão forte quanto a API segura do WordPress.

NosTube

O NosTube, um site de vídeos construído sobre o Nostr, lançou o servidor 0.1.25 e o desktop 0.2.51 para deixar de confiar em uma autoridade certificadora comprometida. O relay em Rust do servidor não confia mais nela para conexões WebSocket ou HTTPS, e os builds de imagem agora exigem um pacote fixo de CAs do sistema Debian. A versão desktop aplica a mesma mitigação à sua camada TLS e ao sidecar almond. Essas alegações de segurança vêm das notas de versão. As notas posteriores do servidor 0.1.27 dizem para NÃO USAR essa imagem porque ela inclui um libbrotli1 desatualizado, e apontam para a 0.1.28, cujo lançamento não confirmamos.

bitchat

O bitchat, um mensageiro que funciona sobre malha Bluetooth e Nostr, lançou a 1.8.0 com melhorias de desempenho para os chats de localização do Nostr (geochat) e timestamps limitados em rumors de DM. O app agora reconhece as mensagens do próprio usuário pelo ID do remetente, e não pelo apelido (correção de identidade do remetente). Grupos privados fixam seu criador, e o ID de par da malha fica fora das DMs por geohash. Os números de desempenho são do próprio projeto e não foram reproduzidos por nós.

Um pull request aberto, ainda não incorporado na data de corte das nossas fontes, manteria o chat geográfico conectado durante quedas de relay ao rotear pelos cinco relays mais próximos e por mais cinco backups compartilhados, com limite de dez conexões por rota (#1822). As mensagens entrariam em fila antes de o diretório de relays carregar, e as assinaturas e gravações pendentes migrariam sem troca de identidade. A validação foi feita pelo próprio autor, e a alteração correspondente para Android está em um pull request separado.

Outro pull request aberto, também não incorporado, adicionaria vídeo ao vivo pela mesh Bluetooth do iOS e do macOS usando um formato LIVE_VIDEO_V1 personalizado, não um transporte Nostr. Os quadros públicos seriam assinados e passariam por verificação de atualidade. Já os quadros de DM trafegariam dentro da criptografia Noise; as gravações seriam enviadas como mensagens. Segundo o autor, uma transmissão de um Android para um iPhone foi recebida. Não foram testados o envio a partir de um iPhone, a combinação entre dois dispositivos iOS nem o vídeo ao vivo por DM.

ngit

O ngit, ferramenta de linha de comando para colaboração em Git sobre Nostr, lançou a v3.0.4. As conexões com relays, assim como o HTTPS no Android, deixaram de confiar em uma autoridade certificadora comprometida. Os prompts interativos agora se protegem contra entradas em branco, e os comandos respeitam os filtros offline. Commits que ainda não foram publicados são preservados nas atualizações de rastreamento remoto. O diagnóstico também passa a distinguir uma fonte ausente de uma consulta que não retornou resultados.

Hasheus

A ferramenta de verificação de arquivos antes chamada verify agora se chama Hasheus e lançou a 2.0.0. Ela confere arquivos com hashes publicados no Nostr e agora obtém descrições e URLs de verificadores confiáveis, além de calcular o hash de arquivos grandes em blocos. O selo de verificado aparece apenas no arquivo exato que foi publicado. A ferramenta também lida com perfis malformados, elimina verificadores duplicados e retorna erro quando falta um relay. Um checksum coincidente confirma o arquivo, não as alegações do publicador sobre ele.

Alby JS SDK

O SDK JavaScript da Alby lançou a 9.0.0. Agora, os clientes NWC dão a cada requisição publicada uma espera fixa de 5 segundos pelo OK do relay e falham com Nip47PublishTimeoutError quando ele não chega, enquanto os timeouts de resposta por método permanecem inalterados. Uma resposta que não pode ser descriptografada passa a ser rejeitada, e o texto de falha do relay é preservado (tratamento de erros de requisição). A mudança incompatível remove os métodos multi_* obsoletos, e o código que usa Nip47SingleMethod deve migrar para Nip47Method. Um OK do relay significa que o relay aceitou a requisição, não que um pagamento foi bem-sucedido.

Alby Hub

O Alby Hub, um nó Lightning auto-hospedado que atende carteiras via Nostr Wallet Connect, lançou a 1.24.4. O patch remove a confiança em uma autoridade certificadora comprometida das conexões TLS nativas de LDK e Go, das quais depende o serviço de carteira NWC do hub. Ele também corrige a inicialização do plugin de hold invoice do CLN.

Orchard

O Orchard, um catálogo de software Flatpak, lançou a 0.3.0. A versão conecta a interoperabilidade de lançamentos de software com a NIP-82 à preparação de assets Flatpak para publicação via ngit ou outras ferramentas NIP-82. A NIP-82 é uma especificação proposta de catálogo de software que ainda não foi atribuída nem aceita, de modo que o Orchard implementa um rascunho que ainda pode mudar.

Bell

O Bell, um agregador Android de conversas Nostr, reúne respostas e citações de várias contas em uma única lista cronológica. Suas notas da 0.1.0 excluem curtidas, zaps, reposts simples e menções genéricas, e as contas assinam pelo Amber ou ficam apenas em modo de observação. As versões de 0.6.0 a 0.9.0 adicionaram regras de silenciamento por conta e uma visualização só de não lidas, com seleção múltipla para marcar como lido. Segundo as notas dessas versões, a recuperação mantém exatamente as respostas e reações assinadas, sem duplicatas automáticas. Com a 0.10.0 e a 0.10.1, é possível ocultar posts individuais no dispositivo, com opções de desfazer e restaurar. Ocultar não apaga nada dos relays, e novas respostas continuam aparecendo. As denúncias de spam abrangem tanto o post quanto seu autor, são enviadas publicamente a partir de uma conta escolhida explicitamente e não funcionam como bloqueios privados. A 0.11.0 adiciona reposts depois que o usuário revisa o post original e a conta de envio. Um avatar de conta define quem responde, reage ou faz o repost. Poder publicar reposts não significa que as notificações de reposts simples agora sejam agregadas. Threads em cache podem ficar incompletas, e a escuta em segundo plano, que é opcional, depende das regras de energia e de rede do Android, sem promessa de entrega sempre ativa ou imediata.

SkateSpots

O SkateSpots é um mapa comunitário de picos e lojas de skate. A versão 1.7.4 adicionou um chat comunitário com criptografia de ponta a ponta, no qual um bot da comunidade aprova novos dispositivos automaticamente e os admins também podem aprová-los. Já a 1.7.0 tornou o relay da comunidade a fonte oficial de picos e lojas. A 1.7.3 corrigiu os QR codes de convite no Android para o chat privado da crew, introduzido em versões anteriores. As versões 1.7.8, 1.7.10, 1.7.15, 1.7.19, 1.7.20, 1.7.21 e 1.7.22 ampliam esse chat da crew. Diferentemente da aprovação por bot do chat comunitário, ali um membro existente da crew aprova novos dispositivos por QR, membros e dispositivos podem ser removidos, e promover um fundador republica a tag de admin. Reações, tombstones de exclusão e confirmações de leitura trafegam como controles MLS criptografados. Os tombstones não são exclusões definitivas nos relays, e confirmações automáticas vêm apenas de signers silenciosos. Um monitor em segundo plano usa a própria chave do membro, nunca uma chave de admin, e transforma pedidos de entrada em DMs NIP-17 ou avisos no sino aproximadamente uma vez por minuto. Para usuários do Amber, os avisos de entrada aguardam até que o sino seja aberto, enquanto signers silenciosos podem pré-carregá-los, de modo que o Amber não recebe solicitações em segundo plano. As contagens de não lidas usam os IDs de envelopes NIP-17 pendentes sem descriptografá-los, excluem as cópias enviadas pelo próprio usuário e não revelam nem confirmam um assunto de conversa. Não há garantia de entrega instantânea ou contínua em segundo plano. As versões 1.7.19 a 1.7.22 também adicionam uma busca global no conjunto de dados, executada apenas enquanto a paleta de comandos está aberta, e passam a lembrar o estado do mapa e das camadas. Não testamos essas mudanças em dispositivos nem as submetemos a auditoria de segurança de forma independente.

Emanator

O Emanator, um cliente Nostr multicontas, agora pode iniciar conversas privadas NIP-17 na 1.5.0, enquanto versões anteriores apenas respondiam a threads existentes. Os usuários escolhem uma conta de envio com mensagens habilitadas e, em seguida, buscam contatos por nome ou NIP-05 ou colam um npub ou nprofile. Conversas existentes são reaproveitadas e, se o destinatário não listar nenhuma caixa de entrada de DM, o app oferece entrega por melhor esforço e também uma opção legada. Na 1.4.1. As novas tentativas mantêm events assinados que já foram aceitos. Somente events antigos que nenhum relay aceitou podem ser assinados novamente e receber nova data.

Feather

O Feather, um cliente Nostr para Android abordado pela última vez na edição #45, durante sua série 0.9, chegou desde então à 1.8.4. As notas da série 1.x adicionam navegação e abertura nativas de issues NIP-34 pelos relays anunciados de um repositório. Ações assinadas agora aguardam em uma caixa de saída no dispositivo, que o WorkManager entrega em segundo plano, enviando os eventos pais antes das respostas. A 1.8.0 adiciona posts de imagem kind 20 com rascunhos salvos e entrega offline, e a 1.8.4 adiciona silenciamento opcional após uma denúncia bem-sucedida. Desde a 1.7.0, a tradução passa pelo app separado Offline Translator e por seus pacotes de idioma, sem fallback na nuvem.

OUTKAST

O OUTKAST, um cliente Nostr para Android, adiciona na 2.2.1 a descoberta Network no próprio dispositivo, que exibe notas de contas que você não segue e que pessoas que você segue curtiram ou repostaram nas últimas 48 horas. Segundo as notas de versão, o ranking conta reações, respostas e zaps pela quantidade (não pelo valor em sats) e depois pondera o número de amigos e a novidade, sem servidor de ranking. Quando você segue 40 contas ou mais, uma nota precisa ter pelo menos dois amigos por trás dela. Os resultados param em 100 notas, sem páginas mais antigas. As notas de versão também descrevem feeds personalizados a partir de pessoas ou listas escolhidas e um editor de fotos que salva as edições como JPEGs sem metadados, enquanto os originais não alterados são enviados intactos.

CustID

O CustID, um app signer Nostr, agora exige na 0.2.2-beta aprovação biométrica para solicitações ASK da NIP-46 em identidades protegidas por biometria, embora uma autenticação recente possa satisfazer o prompt. Regras lembradas de aprovação e rejeição, incluindo aprovações mais antigas, agora se aplicam silenciosamente tanto pela NIP-46 quanto pela NIP-55. Ao ativar a aprovação automática, aparece primeiro um aviso de confirmação, e cancelá-lo não altera nada. A beta também adiciona tags de cliente NIP-89 aos events que publica. Elas vêm ativadas por padrão e mostram aos leitores qual app publicou um event, e uma configuração de Privacidade as desativa.

Nostr Vault

O Nostr Vault, um cliente Nostr, adiciona na 3.0.0 conexões opcionais entre dispositivos via FIPS, pareadas por endereço ou QR code, para que um Mac ou um celular reserva em casa possa funcionar como cofre. O cofre sincroniza notas e histórico, busca fotos existentes pela mesh e, depois que a mesh é ativada, inicia junto com o relay após uma reinicialização. A publicação de mídia pública ainda exige um servidor de mídia público. A versão também corrige condições de corrida entre contas envolvendo follows e cadastro, aguarda a confirmação dos próprios relays de escrita do usuário antes de informar que um post foi publicado com sucesso e mantém as DMs de desconhecidos retidas em Requests.

Holoboard

Holoboard, um mural em que as pessoas pagam para colocar publicações, lança o Android 1.1.0 junto com um fluxo guiado de Adicionar ao mural no site e no backend, que termina em pagamento. Visitantes podem enviar texto e links ou uma publicação Nostr já existente. Faturas preparadas são retomadas no mesmo perfil de navegador, no mesmo dispositivo, e o QR da fatura continua disponível sem conta nem carteira conectada. Sozinho, o APK apenas atualiza o ícone do launcher e a tela de abertura, então as mudanças no mural dependem do site e do backend correspondentes. Não há login por e-mail ou senha.

Hopp

Hopp, um app de podcasts com boosts no modelo value-for-value, avança além do trabalho de identidade e pagamento da série 0.2.x, abordado na edição #45. A versão 0.3.0 adiciona sincronização e restauração criptografadas entre dispositivos via Nostr, sem servidor do Hopp, abrangendo assinaturas, progresso, favoritos, Up Next, hábitos de escuta e configurações de download. A restauração mantém a biblioteca existente, e uma tela de status mostra o estado dos relays e o que está pendente. Segundo as notas, compartilhamentos de boost com resultado desconhecido são protegidos contra novas tentativas duplicadas, e os orçamentos agora levam em conta Release Boosting e Boost2Unlock.

Nostrautica

Nostrautica, um app de apoio a eventos, adiciona na 0.15.1 pacotes de evento offline que salvam pessoas, apresentações entre participantes, palestras, a página do evento, publicações e fotos de perfil para locais com sinal fraco. O chat ganha nomes nas menções e edições com exclusões, e envios pendentes podem ser tentados de novo ou descartados. Já a versão 0.16.0 passa a usar o MarmotKit 0.14, uma biblioteca de mensagens em grupo Marmot, para recuperar o que ficou para trás durante o período offline com menos conexões a relays de grupo, e mantém as mensagens não lidas durante a limpeza de retenção. A migração de armazenamento é de mão única, portanto versões anteriores do app deixam de ser suportadas depois dela. As notas afirmam que não há mudança na interoperabilidade com o mensageiro White Noise nem com a web.

Staircase

Staircase, um app de chat em grupo Nostr da relay.tools, adiciona na 0.1.25 um modo de notificação Frequent, que verifica aproximadamente a cada 5 ou 10 minutos e depois se desconecta. Em sono profundo, quem decide o momento é o agendamento do Android, então a entrega em segundo plano não é instantânea nem garantida. Os modos Periodic e Frequent executam uma única verificação limitada quando a rede volta, no máximo a cada dois minutos; o modo Instant não mudou. O status de entrada em grupo para de aguardar assim que uma solicitação é processada ou expira, sem dizer qual dos dois ocorreu. Relays coordenadores personalizados permanecem sob controle do usuário, sem serem sobrescritos por uma lista publicada.

Em desenvolvimento

Coracle

Coracle, um cliente web Nostr, incorporou uma correção de roteamento na master. Clicar em um item de menu como Lists ou Groups enquanto esse mesmo modal já está em primeiro plano agora não faz nada. Antes, cada clique empilhava outro painel idêntico. A tecla Escape os fechava um de cada vez. Modais distintos e a navegação normal entre páginas funcionam como antes. Trata-se de código-fonte incorporado, não vinculado a um lançamento.

nostter

nostter, um cliente web Nostr, incorporou cinco correções ao seu fluxo de zap. Uma resposta pay_invoice do Nostr Wallet Connect agora só conta como sucesso com o tipo de resultado correto e um preimage válido, com o campo de erro nulo ou omitido. Respostas malformadas são rejeitadas. O cliente rx-nostr dedicado é sempre liberado, mesmo quando a configuração falha. Dez segundos sem resposta da carteira são tratados como resultado desconhecido, e não como falha. Erros de fatura e de assinatura aparecem inline e preservam o valor e o comentário para uma nova tentativa, e falhas de fatura são informadas separadamente das falhas de NWC. O botão de zap continua habilitado para zaps repetidos. A marca laranja dele também aparece quando uma fatura em QR é exibida, o que não confirma que um pagamento manual foi concluído. Reabrir a caixa de diálogo só a redefine quando ela está ociosa. Fechá-la depois que a fatura ou a assinatura chega impede um novo pagamento por NWC, mas um pagamento já enviado continua.

Um pull request aberto exibiria um aviso para verificar o histórico da carteira antes de pagar pelo QR de fallback após um resultado desconhecido, e suprimiria a abertura automática da carteira. Um timeout não significa que a carteira deixou de fazer a cobrança.

Pollerama

Pollerama, um cliente de enquetes e feed, incorporou uma fila de requisições por relay. A fila ajusta quantas requisições rodam ao mesmo tempo, recua quando um relay aplica limite de taxa, divide filtros grandes demais e normaliza URLs de relays. A visualização Mine packs agora mantém uma subscription permanente, de modo que respostas lentas de relays ainda aparecem. Problemas conhecidos de novas requisições no app continuam em aberto, e mensagens diretas não foram testadas com essa mudança.

Grimoire

Grimoire, um cliente social Nostr, incorporou correções na sincronização de mensagens diretas. O cursor de histórico não avança mais em páginas mescladas de relays que só retrocedem parcialmente, e uma proteção contra abortamento impede que uma passagem de descriptografia volte a preencher mensagens e marcadores de visto depois que o logout os apaga. Um backfill abortado para antes de mover o cursor ou de marcar o histórico como esgotado. Ainda há lacunas: um único relay que responde ainda pode marcar o histórico como esgotado enquanto faltam outros, e uma recusa permanente de um signer ainda faz o cursor avançar.

nostr-vpn

nostr-vpn, uma VPN que usa chaves Nostr para descoberta de pares, incorporou uma correção de reconexão no mobile. Quando uma sonda de descoberta já está prevista para rodar, o cliente agora rearma caminhos esgotados até pares conhecidos. Isso só acontece quando nada foi recebido recentemente e não existe caminho conectado ou pendente, e no máximo uma vez a cada 300 segundos. Caminhos saudáveis e pendentes não são tocados, e o formato de transmissão não mudou. O autor testou a correção com uma fixture nativa isolada, não em redes celulares. Uma segunda mudança incorporada remove segredos de entrada na rede dos doctor bundles, deixando o segredo de entrada do enrollment e o estado bruto do daemon fora da saída de diagnóstico. A chave privada Nostr já era ocultada ali. Bundles compartilhados antes dessa mudança continuam expostos, então quem compartilhou um deve rotacionar os segredos de entrada afetados.

Várias mudanças relacionadas ainda são propostas abertas e não foram incorporadas nem lançadas. No caso dos segredos armazenados, uma delas manteria os segredos de entrada na rede no armazenamento seguro da plataforma por meio do caminho de migração existente. Outra restringiria os segredos sidecar de máquina do Windows a SYSTEM e Administrators, abrangendo os arquivos DPAPI que guardam as chaves de nó Nostr. Essa restrição só vale a partir da próxima vez que um arquivo for gravado, e há um breve intervalo entre a criação do arquivo e a ACL. Caminhos de configuração personalizados não são cobertos, e o autor não testou em uma máquina Windows multiusuário. Quanto à associação assinada, uma proposta rejeitaria aprovações de entrada cujo snapshot do roster não corresponda mais ao disco, para que o admin recarregue e tente de novo, preservando dispositivos aprovados simultaneamente. Outra permitiria cinco minutos de diferença no relógio do admin e sempre exigiria um signer de entrada configurado, mesmo quando a lista local de admins estiver vazia, mantendo o vínculo com o segredo da solicitação. Uma terceira desempataria rosters com timestamps iguais pelo hash do artefato. Pares que veem os dois rosters escolheriam o mesmo roster único; cada roster mantém seu próprio conteúdo de associação. Uma última proposta exigiria confirmação para solicitações de entrada por deep link e para provedores de saída pagos. Links de entrada no macOS e no Linux aguardariam uma etapa explícita de Add-device. O macOS também reteria links de provedores pagos até a confirmação. A execução nativa em qualquer das duas plataformas não foi demonstrada. Todos os resultados de testes são relatados pelo autor.

Buzz

Buzz, um relay comunitário com clientes desktop e mobile, incorporou trabalho em grupos e agentes. Agentes podem se autenticar segundo a NIP-FI do projeto, uma especificação de JWT que verifica o dono humano declarado pelo emissor; negar ou desconectar esse dono encerra as sessões dos agentes dele, e a participação do dono na comunidade pode admitir um agente. Os Huddles também aceitam registros verificados de agentes gerenciados vindos do usuário atual ou do dono do Huddle, além da função de bot por atestação de dono da NIP-OA. Esse fallback é uma política de compatibilidade e não confia em registros desconhecidos de terceiros. Não é prova de identidade. Nenhuma das duas especificações é uma NIP aceita.

Canais de anúncio abertos podem admitir convidados somente leitura por meio de join_role=guest, e canais abertos não listados ficam ocultos da descoberta para quem não é membro, mas podem ser lidos por qualquer pessoa que tenha o ID do canal. Events de admissão podem adicionar até 100 membros, com possibilidade de sucesso parcial. A correção das configurações de canal, noticiada na semana passada como proposta aberta, agora foi incorporada: as mudanças são confirmadas em uma única transação junto com suas solicitações e avisos. Uma troca de público para privado que falhe é revertida por completo, o que impede que membros removidos reapareçam por meio dessa reversão. No mobile, falhas na configuração de push não quebram mais o app, que tenta novamente um número limitado de vezes e oferece recuperação manual; os testes usam canais simulados e o comportamento em dispositivos com APNs não foi verificado. Mutes sincronizados não causam mais uma inicialização em branco, já que agora são conferidos com as subscriptions reais de push de DM; essa correção se baseia em um único log de iPhone. Na malha de relays, registros de pares inativos expiram após cinco minutos sem heartbeats, enquanto conexões ativas ficam isentas.

As incorporações mais recentes não têm lançamento confirmado. Adições de membros de kind 9000 agora são confirmadas junto com suas gravações no roster: uma mudança que falha não armazena nenhuma das duas, e o mesmo event assinado pode ser reenviado. Os kinds 9001, 9021 e 9022 mantêm a lacuna antiga. Os diagnósticos do modo sombra da NIP-FI agora registram a chave Nostr verificada e um motivo privado fixo nos casos em que haveria negação, sem registrar tokens ou claims. Isso não altera nenhuma admissão nem a aplicação de regras. A NIP-AP do próprio Buzz, uma especificação de agentes que é documento do projeto e fica fora das NIPs aceitas, agora exige nas configurações um agentType definido pelo cliente. Inicializações com configurações de outro tipo são recusadas, um campo ausente mantém seu significado legado e trocar o tipo pode descartar as configurações aninhadas do tipo antigo. A seleção de agente solo falha de forma fechada diante de políticas de agentes gerenciados de kind 30177 mais recentes que estejam malformadas. Dados mais antigos continuam excluídos. Ela identifica os agentes pelo nome gerenciado pelo dono, enquanto a arte e os autores de mensagens continuam usando perfis.

No mobile, criar, listar e excluir agentes hospedados usa prova de dono NIP-OA e registros de kind 30177 com novas tentativas duráveis sob a mesma identidade, e guarda as instruções privadas em armazenamento seguro. A trava de recurso hospedado, definida em tempo de build, fica desativada nas builds da App Store e nas internas, então isso não significa disponibilidade pública. A inicialização a frio por convite hospedado no iOS preserva a intenção do convite, importa uma chave correspondente e se recupera a partir do backup. Apenas o autor testou o caminho principal, e o endpoint de fallback de associação e o cadastro do zero continuam sem solução. A recuperação da inscrição em push aguarda com backoff exponencial e então substitui uma solicitação salva que foi rejeitada com 401 por um novo desafio limitado e uma nova chave App Attest. Ela mantém as intenções após erros 400 ou transitórios e trata um 404 comum normalmente. Essa recuperação não foi verificada em dispositivos reais. Links de mensagens para canais públicos em que o usuário não entrou buscam metadados de kind 39000 e abrem em modo somente leitura, enquanto as barreiras de canais privados e de DMs continuam inalteradas. Durante reconexões, os links entram em fila, e uma única consulta lenta pode atrasar os links seguintes em até oito segundos.

Vários pull requests abertos ainda não tinham sido mesclados na data de corte das nossas fontes. Uma capacidade buzz_v1, desativada por padrão, substituiria o estado de leitura do lado do cliente por APIs de barra lateral, estado de leitura e cobertura via NIP-98, privadas para quem faz a chamada, além de revisões por pessoa e pings de invalidação de kind 24300 exclusivos do relay. Relays sem essa capacidade continuam com o NIP-RS, e bancos de dados grandes precisam primeiro construir seus índices de forma concorrente. Os resumos de thread examinariam apenas as 1.000 respostas mais recentes, retornariam os 10 autores mais recentes e enviariam atualizações ao vivo no máximo uma vez por segundo por pod; por isso, não listariam todos os participantes anteriores. Respostas de agentes a reações seriam encadeadas sob a mensagem que recebeu a reação, usando a última tag e válida do NIP-25 e recorrendo à âncora antiga como alternativa. Agentes baseados no Hermes ganhariam um shell MCP com escopo de agente para publicar em canais e DMs. Ele se recusa a rodar sem sua bridge e oculta credenciais, mas a instalação, a reinicialização e a publicação ao vivo não foram verificadas. Uma correção no adaptador ACP enviaria os nomes de inicialização da v1 e da v2, recorreria à v1 estável e fixaria a versão principal validada. Isso repara o transporte dos agentes e não constitui uma mudança no protocolo Nostr. No celular, a função Ler em voz alta usaria o mecanismo de conversão de texto em fala do telefone e pularia código, links e anexos. É o mecanismo escolhido pelo usuário que define onde a fala é processada. Um gerador de carga para relays independente simularia humanos e agentes NIP-OA e reprovaria execuções que ultrapassassem limites definidos de erro e latência. Ele não altera nenhum código de relay e não comprova escala de produção.

Mosaico

O Mosaico, um daemon que coordena agentes em grupos baseados em relay (NIP-29), mesclou a presença baseada em heartbeat. Agora, um agente só conta como presente em um canal enquanto publica um event de status com um timestamp de expiração (NIP-40) definido para 90 segundos à frente e renovado a cada 30 segundos. Um processo rodando localmente deixou de contar, por si só, como presença. A condição de membro persiste enquanto o agente está offline, para que ele possa retomar. Um modelo de leitura de grupo reconstruído é montado uma vez a cada mudança de relay, com um cursor canônico de chegada, de modo que o chat não se perde mais quando uma assinatura ampla de grupo é substituída.

Três merges posteriores não estão confirmados em nenhuma release. As assinaturas de substituição agora usam IDs de REQ novos e são abertas antes que a antiga seja fechada. Um perfil desativado é publicado fora do caminho crítico de latência, e um agente que sai de um canal retira sua presença enquanto ainda é membro no NIP-29. As sondagens que embasam essas mudanças são do autor, e não medições nossas. A contabilização de novas tentativas com reivindicação prévia é armazenada de forma durável no schema 27 e sobrevive ao replay do relay. Ela aplica recuo exponencial de 30 segundos até uma hora em um único temporizador serial e desiste após 10 falhas. Um event ausente não é tratado como exclusão, e, como a janela retida comporta 4.096 entradas, a entrega de todos os events não é garantida. Os snapshots exclusivos de grupo agora despertam os consumidores de grupo, e substituições com timestamps iguais mantêm o menor ID de event, como especifica o NIP-01. Mudanças apenas de conteúdo ainda despertam o consumidor geral. Um fallback delimitado para um pai ausente pode aguardar a próxima mudança de grupo ou um timeout de 15 segundos.

Sonar

O Sonar, um mensageiro que combina Nostr, criptografia MLS e malha Bluetooth Low Energy, mesclou uma correção de inicialização para conexões celulares. O PR atribui a lentidão da primeira renderização ao acoplamento do relay de push, que mantinha um lock do armazenamento. No Android, a inicialização pula esse lock quando o nó local já está aberto, como acontece quando o registro de push o abriu antes da inicialização a frio. No iOS, o app instrui a extensão do serviço de notificações a parar de se conectar e de drenar, para que o app possa renderizar.

Shopstr

O Shopstr, um marketplace Nostr, mesclou o suporte à exclusão de anúncios que havia sido proposto na semana passada. Uma solicitação de exclusão de event (NIP-09) assinada pelo vendedor agora remove o anúncio do cache e o marca com tombstone, para que um item excluído não reapareça nem possa ser comprado a partir do cache, enquanto republicações mais recentes continuam aparecendo. Algumas exclusões ainda passam despercebidas: uma exclusão que chega antes do seu anúncio é ignorada, solicitações mais antigas sem a tag k não correspondem à consulta ao relay e exclusões passadas não são preenchidas retroativamente. Os relays também podem manter os events excluídos. Em outra frente, mensagens gift-wrapped malformadas não travam mais as telas Orders e My Listings, e os vendedores agora podem ver seus próprios pedidos, enquanto os demais usuários continuam recebendo um 403.

Três pull requests abertos, ainda não mesclados na data de corte das nossas fontes, tratam da integridade dos pedidos. O #665 registraria os participantes de cada pedido uma única vez por meio de registro via NIP-98, obtendo o comprador a partir da autenticação e o vendedor a partir do anúncio assinado, e gravações posteriores não poderiam alterá-los. Uma falha no registro não interromperia o checkout, e novos pedidos não resolvidos não seriam deduzidos a partir de tags. Pedidos legados só são cobertos até um limite de corte restrito, e uma lacuna na forma como o status é armazenado por ID de pedido continua sem correção. O #666, que depende do #665, só aplicaria mensagens de status de pedido gift-wrapped (NIP-59) quando viessem do comprador ou do vendedor registrado no pedido, e não de qualquer remetente autenticado. Pedidos não resolvidos continuam pendentes, a confirmação do comprador após o pagamento não conta como confirmação do vendedor, e mensagens forjadas permanecem como chat sem alterar o estado do pedido. O #664 leria os metadados de token de keyset v2 do Cashu para o registro de escrow e para as decisões sem consultar o keyset pela rede, além de corrigir a soma das provas. A decodificação do token na criação do pedido ainda precisa de uma correção separada.

Conduit

O Conduit, um marketplace Nostr com apps pareados para compradores e lojistas, mesclou um registro de conta único e criptografado. Metadados da carteira, seed, identidade nativa, endereço, preferências e progresso da configuração agora ficam em um único registro de dados arbitrários personalizados de app (NIP-78), criptografado com payloads criptografados versionados (NIP-44) e verificado quanto a assinatura, dono e identidade derivada; os dois apps o encontram assim que o signer aprova. A transição não é retrocompatível: caminhos antigos de backup e recuperação são ignorados, e backups legados permanecem onde estão, sem migração automática. Outros merges adicionam login com uma nsec existente, guardada no armazenamento local do navegador, passam a exigir termos de envio exatos e assinados ao editar famílias de produtos e movem a recuperação do checkout para o IndexedDB, com releitura antes de marcá-la como salva.

O Conduit também migrou para o NWC SDK 8.1.1, trazendo as correções desse SDK para validação de valores, tentativas de conexão limitadas, tratamento de pools fechados e respostas em andamento. A escolha de carteira, a criptografia e a política de pagamentos do Conduit não mudaram. A implantação dos apps continua não confirmada. Dois pull requests em rascunho continuavam sem merge na data de corte das nossas fontes. A ativação de pagamento persistiria, leria de volta e entregaria o estado do pagamento dentro de uma janela de execução fixa de dois minutos, que as novas tentativas não reiniciam. Recibos Nostr, recuperação privada de conta e mudanças de estoque ou de atendimento precisariam, cada um, de evidência assinada própria. Recibos mantidos por 24 horas depois disso não restauram a autoridade de pagamento, e as verificações com fundos reais, em dispositivos e pelos mantenedores ainda estão em aberto. Os produtos exclusivos de eventos marcariam anúncios de kind 30402 do NIP-99 como ocultos com uma extensão conduit_event_only. Eles ficariam fora do catálogo normal e do checkout e precisariam de uma atribuição exata e autorizada a uma ocorrência do evento. Os dados assinados ocultos continuam públicos, e outros clientes só oferecem suporte à flag padrão de oculto.

LNbits

O LNbits, servidor de carteira e contas Lightning, mesclou uma opção para enviar suas notificações Nostr como mensagens privadas NIP-17. Os administradores podem escolher entre as mensagens criptografadas legadas do NIP-04 e as mensagens diretas privadas do NIP-17, que são o padrão para novas configurações. No caso do NIP-17, o servidor busca a lista de relays de caixa de entrada de DM do destinatário, usando os relays do NIP-05 como dicas de descoberta e como destino quando não existe lista. Uma lista vazia publicada faz o envio falhar. Cada envio é limitado a 30 segundos e exige que pelo menos um relay de caixa de entrada o aceite, e nunca recorre ao NIP-04 como alternativa.

Zeus

A Zeus, carteira móvel de Bitcoin e Lightning, incluiu sua correção da contabilização de orçamento do Nostr Wallet Connect quando a atualização pós-pagamento falha no pré-lançamento v13.2.4-rc1, junto com a correção anterior que faz o make_invoice do Nostr Wallet Connect retornar sua própria fatura. Antes da correção, um erro de atualização após um envio via NIP-47 pulava a contabilização do orçamento e retornava erro para um pagamento que podia ter sido bem-sucedido. Agora, uma preimage retornada debita o orçamento pelo fallback existente, e um timeout mantém o valor como gasto pendente mesmo que o pagamento não apareça na lista. Outras lacunas, incluindo pagamentos LND em andamento, podem persistir. A v13.2.4-rc2 veio em seguida, apenas com atualizações de dependências.

Duas correções mais recentes já foram mescladas no código-fonte e não estão confirmadas em nenhum dos dois release candidates. A correção da expiração padrão faz o decodificador BOLT11 local aplicar a expiração padrão da especificação, de 3600 segundos, quando uma fatura não tem campo de expiração. Essas faturas vinham sendo tratadas como se nunca expirassem, então a verificação que bloqueia o pagamento de faturas expiradas não se aplicava, e a validação de faturas NWC em NostrConnectUtils tinha a mesma lacuna. A correção do backup por carteira redefine o timestamp do backup de mints no Nostr para cada carteira de ecash. Antes dessa correção, uma carteira recuperada a partir da seed na mesma sessão que outra carteira de ecash podia herdar o timestamp dessa outra carteira. Com isso, ela podia descartar como obsoletos seus próprios backups mais antigos em relays e salvar uma lista de mints vazia, o que desativava a restauração automática. Um backup que termina após uma troca de carteira ainda pode gravar seu timestamp na carteira errada. Carteiras já afetadas mantêm a lista vazia salva e precisam da restauração manual em Mint sync ou de que suas URLs de mint sejam adicionadas novamente. O ecash delas permanece no mint. Os dois pull requests informam que nenhum teste em dispositivo foi feito.

npub.cash

O npub.cash recebe pagamentos Lightning para identidades Nostr e os converte em ecash Cashu. Ele mesclou uma mudança no servidor que publica recibos de zap nos relays solicitados pelo pagador. O servidor já interpretava os relays indicados em uma solicitação de zap, mas os ignorava ao publicar os recibos pagos. Agora, os recibos vão para esses relays quando a solicitação indica pelo menos um, enquanto solicitações com lista de relays ausente ou vazia continuam usando os relays padrão configurados.

eHagaki

O eHagaki, um cliente web Nostr que também é distribuído como Web Component incorporável, lançou as versões 1.31.0 e 1.31.1. A versão 1.31.0 adiciona reposts (NIP-18), reações (NIP-25) e gerenciamento de mídia enviada, conclui o roteamento outbox (NIP-65) antes que um event siga para um signer externo e pode manter o histórico de posts e um cache em um relay Citrine local. Sua migração do IndexedDB redefine o histórico de posts exibido localmente, mas preserva os rascunhos e as solicitações de exclusão salvas; o histórico mantido nos relays pode ser buscado novamente, enquanto posts que existem apenas localmente precisam de backup ou exportação antes da atualização. A versão 1.31.1 sincroniza os servidores de upload do NIP-96 por meio do kind 10096, junto ao kind 10063 do Blossom, mantém configurações parciais de relay que sejam utilizáveis e traz as correções da lista de servidores de upload e da sincronização de servidores de mídia. A busca da lista de servidores de upload pelos relays de leitura declarados mantém a lista válida e assinada mais recente apesar de timeouts em outros relays e deixa as configurações inalteradas quando nenhuma lista chega. A sincronização de servidores de mídia trata as preferências do Blossom e do NIP-96 separadamente e nunca publica uma lista reduzida após uma consulta malsucedida.

Outras correções de confiabilidade incorporadas ainda não foram confirmadas em uma versão publicada. Após um erro 401 ou 403, os usuários podem se registrar nos servidores NIP-96 yabu.me ou nostrcheck.me a partir da tela de mídia; a assinatura NIP-98 cobre a URL real do POST e o hash do corpo, mudanças de conta ou de destino cancelam a solicitação, uma proteção bloqueia envios duplicados e solicitações com resultado desconhecido não são reenviadas. O eHagaki nunca fornece uma senha, e as etapas de código de convite ou de pagamento levam ao site oficial do provedor. Listas grandes de arquivos do Blossom são paginadas de 24 em 24 itens a partir de um snapshot local limitado, rejeitando respostas acima de 8 MiB ou de 10.000 entradas e descartando o snapshot quando há mudança de conta, sessão ou servidor; chegar ao fim significa que o snapshot se esgotou, não que o servidor não tenha mais arquivos. A recuperação do assinador remoto NIP-46 reconstrói a conexão e rejeita explicitamente solicitações pendentes antigas após 30 segundos, sem reenviá-las. Uploads para o servidor Blossom do Primal codificam a autorização assinada existente em Base64 padrão com preenchimento, enquanto os demais servidores continuam com Base64URL.

Duas incorporações mais recentes também não foram confirmadas em uma versão publicada. A publicação agora compartilha esperas limitadas e verificadas pelas solicitações aos relays e mantém a entrega e o progresso vinculados à sessão, substituindo vários temporizadores separados. A primeira confirmação válida de um relay conta como sucesso, enquanto a entrega aos relays restantes continua. Em nenhum momento o progresso afirma que houve entrega a todos os relays, e trocar de conta ou sair da conta interrompe a entrega em segundo plano. Sob demanda, o histórico de posts pode atualizar respostas, reações e exclusões relacionadas dentro de um limite de três segundos. Os resultados já recebidos são mantidos após um timeout parcial, e uma exclusão que não chega não é tratada como prova de que nenhuma exista.

Formstr Drive

O Formstr Drive, um app de compartilhamento de arquivos criptografados construído sobre Nostr e Blossom, incorporou seu trabalho de recuperação da DriveKey, que noticiamos anteriormente como uma proposta em aberto. Antes de gravar um keyring combinado, o app lê todos os relays alcançáveis, de modo que as chaves antigas convergem à medida que se tornam visíveis. Uma nova chave só é criada quando dois dos quatro relays do app não retornam nada e não há histórico nem versão. Um relay de escrita que não responde ainda pode ocultar uma chave antiga por algum tempo, e builds mais antigos não conseguem ler o novo formato JSON.

O projeto também passou a manter separados os arquivos descriptografados, os compartilhamentos, as pastas e a caixa de saída de cada conta. Trocar de conta bloqueia as assinaturas e importações pendentes da conta anterior, embora um blob já preparado possa ficar sem referência. Novas contas agora precisam escolher explicitamente um servidor de upload, sem failover silencioso, enquanto os padrões automáticos anteriores são mantidos. O servidor ainda vê a pubkey, o momento dos uploads e os bytes criptografados. Avisos de duplicata agora exigem bytes ativos idênticos no mesmo servidor e na mesma pasta. Os fluxos do Android para separação de contas e confirmação de duplicatas não foram testados, e não confirmamos que nada disso esteja em uma versão publicada.

diVine

O diVine, um cliente de vídeos curtos para Nostr, incorporou mudanças em mensagens, contas e desafios. Suas primeiras versões beta trazem apenas notas genéricas, então nada disso está estabelecido em builds distribuídos. Snapshots de conta criptografados por campo sincronizam preferências, decisões e dispensas de badges, refazem localmente as alterações pendentes e bloqueiam publicações inseguras quando as leituras estão incompletas. Os marcadores de leitura de DMs mantêm o protocolo existente, as leituras de notificações usam a API do servidor e marcar tudo como lido exige conexão; permissões do sistema operacional, credenciais e consentimento de idade permanecem no dispositivo.

Nas DMs, o editor de mensagens e o painel de compartilhamento se fecham assim que uma mensagem é colocada na fila com segurança; a entrega em segundo plano não é executada enquanto o app está encerrado, e a entrega só conta após a confirmação do relay. Novas tentativas que falham passam a contar de forma consistente para o limite de tentativas. Mensagens legadas NIP-04 com formato inválido são descartadas e registradas em um ledger, embora os balões vazios já armazenados permaneçam e a compatibilidade com assinadores externos e outros dispositivos não esteja estabelecida. Prévias desfocadas opcionais para DMs de vídeo de remetentes confiáveis vêm desativadas por padrão e são sempre desfocadas com um aviso de conteúdo; o vídeo ainda é baixado, então o desfoque não oferece privacidade de rede. Em grupos, bloquear um membro oculta apenas as mensagens dele; um aviso informa que ele ainda recebe as suas. A saída de uma sala fica salva de forma persistente. A criação de novos grupos continua atrás de uma flag desativada por padrão. Essas mudanças se aplicam a grupos existentes; a revisão de confiança e segurança está pendente.

Dois recursos que estavam em aberto foram incorporados. O cache de vídeos recebidos por DM guarda arquivos descriptografados por conta por até 30 dias ou 300 MB; o carregamento automático em chats confiáveis e de usuários seguidos revela ao host de mídia o horário de visualização, e vídeos de desconhecidos exigem um toque. Uma remoção (takedown) feita pelo servidor não revoga imediatamente os bytes em cache, que podem ser expulsos do cache antes disso. A consulta de titularidade de nomes de usuário verifica o diretório NIP-05 do servidor de nomes nas buscas por handles do Divine na primeira página e fixa apenas um titular ativo; os nomes consultados aparecem nos logs do servidor, e isso não é uma validação NIP-05 geral.

As listas de pessoas passam a ter disponibilidade geral, com base no trabalho combinado de descoberta e gerenciamento. Os links de apoio no perfil vêm ativados por padrão, e o editor aguarda uma leitura estrita do kind 0 bruto em todos os relays, preservando provedores ocultos e edições não salvas; a promoção do build pelo canal de lançamento da loja e a implantação no backend ainda não aconteceram. As tags de atribuição de cliente seguem a preferência atual do NIP-89 em novas tentativas e edições de metadados, removendo a tag de um cliente alheio antes da assinatura, ao passo que posts agendados já assinados nunca mudam. Links curtos externos autenticados, desativados por padrão, assinam exatamente o POST e o corpo NIP-98 em até dois segundos e recorrem às URLs canônicas, que as DMs e os events Nostr sempre mantêm; a criação no gateway foi implantada desligada, com etapas de liberação ainda pela frente.

Os criadores podem permitir a reutilização de um vídeo público com uma tag explícita, desativada por padrão e travada como desativada no momento da publicação quando há áudio licenciado sem permissão de obras derivadas; trata-se de uma convenção do cliente, não de DRM. O trabalho de desafios, restrito a testes, abrange uma base de protocolo assinada, a assinatura de inscrições com verificação de regras e consentimento, o armazenamento durável por conta e fluxos nativos de revisão e retirada em builds de teste especiais. A confirmação de um relay não significa aprovação do organizador. A descoberta em produção está desativada. Continuam pendentes a entrega no backend, os testes de aceitação com contas reais e uma sequência de lançamento entre clientes.

Incorporações mais recentes também não foram confirmadas em uma versão publicada. Quando a caixa de entrada de DMs kind 10050 de um destinatário não pode ser lida, a fila de envios retidos do NIP-17 agora reutiliza o ID do gift wrap do destinatário que um relay já aceitou, preservando a identidade desse wrap entre as novas tentativas. Se uma nova tentativa encontrar a caixa de entrada, o cliente pode republicar nos relays anunciados. Caso nenhuma caixa de entrada apareça, ele se contenta com a cópia aceita e depende dos relays para mantê-la. As mensagens ainda podem aparecer como Failed. A entrega ao destinatário ou a leitura por ele continuam sem comprovação; as novas tentativas de reações e exclusões ficam fora desta mudança. O pré-carregamento de notificações públicas e a atualização de fuso horário usam um cache limitado de miniaturas e um índice SQLite compartilhado, excluindo DMs e campanhas. Eles exigem uma versão nativa normal junto com uma mudança coordenada no serviço, e a execução em segundo plano não é garantida. O editor de vídeo ganha cinco transições, chegando a 20 no total, renderizadas nativamente na prévia e na exportação. No modo de movimento reduzido, os blocos de prévia são deliberadamente limitados. Já o espaçamento do flash pode recorrer a um dissolve. Não testamos em campo a implementação nativa.

Quatro pull requests abertos não haviam sido incorporados até a data de corte das nossas fontes. Stickers sociais em vídeo, empilhados sobre o trabalho anterior de stickers informativos, gravariam tags de sticker pequenas e planas com metadados de menção (p), hashtag (t) e link (r). O player sobreporia regiões tocáveis e avisaria antes de abrir links externos. Outros clientes veem apenas os stickers gravados no vídeo, a menos que implementem as tags, que não são um NIP aceito. Menções em chats do Concord protegidos por flag manteriam as identidades dentro de mensagens criptografadas autenticadas. Os alertas dentro do app viriam apenas de remetentes seguidos e não bloqueados, em salas que o usuário já abriu, limitados a 50 linhas com estado de leitura salvo. Eles não acionariam notificações push do sistema operacional nem um lançamento público do chat, e as verificações de colisão de identidade, replay e bloqueio são cobertas apenas por testes de escopo restrito. As tags de rumor do NIP-17 nomeariam o autor da reação uma única vez, com o kind real, e as exclusões embrulhadas deixariam de incluir tags p enganosas. Os gift wraps já eram endereçados aos destinatários corretos, então isso não corrige um vazamento de destinatário. Rumors já enfileirados permanecem inalterados, o comportamento em outros clientes não foi testado e ainda resta uma contrapartida no arquivamento por sala. O próximo build nativo ativaria por padrão o compartilhamento já existente por links curtos, enquanto a versão web continua desativada. Os caminhos desativado, sem login e de erro manteriam as URLs canônicas completas. A distribuição pelas lojas, a prontidão do serviço e as verificações em dispositivos não estão comprovadas.

rust-nostr

O rust-nostr, um conjunto de bibliotecas do protocolo Nostr em Rust, incorporou uma mudança incompatível na forma como as subscriptions são reemitidas. SubscriptionData agora mostra o estado atual de EOSE de cada relay. A reemissão enfileira o CLOSE e o REQ com o filtro armazenado em uma única etapa atômica, mesmo enquanto desconectado, o que garante como eles são enfileirados, mas não que os dois frames cheguem ao relay. Ao se recuperar de uma lacuna de notificações, a biblioteca não descarta mais silenciosamente uma subscription nem envia uma solicitação duplicada. Mensagens EOSE ou events atrasados do REQ anterior ainda podem se sobrepor ao novo, porque nada na comunicação os diferencia. Isto é código-fonte incorporado, e não confirmamos que esteja em uma versão publicada.

nostr-sdk-ffi

O nostr-sdk-ffi, os bindings que permitem que outras linguagens usem o SDK do rust-nostr, incorporou acesso direto às chaves de conversa do NIP-44 v2, de modo que os hosts do Concord não precisam mais embutir seu próprio código de ECDH e HKDF. Trata-se de um invólucro fino sobre a derivação existente, sem nenhuma criptografia nova. O autor relatou um build em Python e um teste de ida e volta que produziu a mesma chave nos dois lados, mas não acrescentou testes unitários dedicados. Isto é apenas código-fonte incorporado.

NDK

O NDK, um kit de desenvolvimento Nostr para Dart, publicou a 0.11.0-dev.2, uma pré-versão com mudanças incompatíveis. Ela não é uma 0.11.0 estável e não tem relação com o NDK em JavaScript. A versão adiciona o NIP-49: chaves ncryptsec criptografadas por senha, com uma UI de exemplo. Segundo suas notas, a descriptografia limita o logN, rejeita bytes de segurança desconhecidos e zera os buffers derivados; essas afirmações se baseiam nas notas e no código-fonte incorporado, e não vimos uma auditoria independente nem uma execução de vetores de teste. As solicitações agora relatam um resultado notSent que carrega a falha de conexão ou de envio, e as solicitações a relays inalcançáveis terminam assim que nenhum relay ou filtro restante puder responder, sem esperar o fim de um timeout. Os broadcasts verificam se há um signer antes de marcar um event como em andamento, os IDs de zap request usam o created_at armazenado, e os metadados de relay do NIP-11 são buscados sob demanda por meio de um cache compartilhado, então deixam de bloquear cada sincronização.

A pré-versão também inclui mudanças que antes existiam apenas no código-fonte. Listas NIP-65 que repetem uma URL de relay agora são mescladas corretamente, combinando os marcadores de leitura e escrita e preservando o conjunto de relays de escrita do outbox; o autor viu 5 listas lidas incorretamente entre 932 perfis, em uma única observação. Uma verificação prévia opcional de upload do BUD-06 pergunta ao servidor, usando a própria autorização do upload, se ele aceitaria um blob e informa o status e o motivo, como agora também fazem as recusas reais de upload. Um 404 significa que o suporte é desconhecido, e passar na verificação não garante que o upload terá sucesso. Uma mudança incompatível nos timeouts de reconciliação do NIP-77 divide o timeout único em timeouts de abertura e de ociosidade, com um erro tipado, excluindo o tempo gasto aguardando autenticação. Não existe um prazo geral, então uma sincronização que continua progredindo pode rodar indefinidamente, e não vimos a mudança ser verificada contra um relay ativo.

Pull requests abertos propõem cache de NIP-05 indexado por identificador, com cache negativo, uma API de cache que retorna IDs e timestamps para NIP-77, tratamento da prontidão do WebSocket, campos completos de NIP-11 e conclusão quando uma conexão é recusada. Outra proposta, ainda aberta segundo uma verificação recente de status, criaria e recuperaria contas com passkeys de plataforma no navegador e no Flutter. Ela segue um design preliminar de identidade por passkey com modos de chave derivada e armazenada, além de metadados legados explícitos. Handles desconhecidos são recusados e nunca tratados como conta nova, e a recuperação precisa ser verificada de forma independente antes que um registro armazenado seja mantido. O autor observa que a interoperabilidade não foi validada em todos os provedores de passkey.

Applesauce

O Applesauce, um conjunto de bibliotecas TypeScript para Nostr, tem novas alterações de código-fonte com changesets, e não afirmamos que exista uma versão correspondente. Clientes de mensagens independentes e autenticação explícita em relays adicionam clientes NIP-04 e NIP-17 para uma conta fixa, que fazem solicitações explícitas de auth NIP-42 e repetem envios assinados já preparados. Conversas encapsuladas e stores de rumors com escopo expõem rumors de kind 14 e modelos de thread sem iniciar trabalho de signer ou de rede. A descriptografia vem desativada por padrão. Envios encapsulados exigem relays de kind 10050 para cada participante, incluindo o remetente, e a aceitação por um relay não equivale ao recebimento pelo par. A restauração limitada do cache de conteúdo descriptografado usa concorrência 8 por padrão, o que pode reordenar events, a menos que seja definida como 1. Cabe aos próprios apps aplicar escopo e criptografia a esses caches de texto puro. Em seguida vêm o transporte NDR e um cliente coordenador Cordn separado. O NDR precisa persistir seu próprio estado de ratchet, separado, e Submitted significa repasse local, não recebimento pelo par. Já o Cordn cuida apenas do transporte, está engavetado no exemplo e não implementa MLS. A integração do Kehto com ContextVM por janela dá a cada janela de napplet uma identidade ContextVM efêmera, sem auth de conta nem pagamentos. Com depósitos duráveis pertencentes ao app e recuperação de nutzaps, novos depósitos e resgates na carteira exigem um store de recuperação fornecido pelo app consumidor e restauração NUT-09 pela mint. O journal persiste proofs gastáveis, segredos e fatores de blinding, por isso deve ser criptografado e ter escopo por conta. A retomada só é executada quando chamada explicitamente, reutiliza IDs assinados e mantém o journal até haver aceitação positiva pelo relay; cancelar não invalida a invoice. Snapshots de timeline em lote com estado de carteira síncrono agrupam atualizações da timeline em janelas de 16 ms, enquanto o estado dos tokens da carteira continua síncrono. O agendador de requisições COUNT, proposto na semana passada, agora foi mesclado. Ele começa em 8 sob um limite de concorrência e dobra até o primeiro erro de rate limit ou de transporte, e cada erro reduz o limite pela metade e acrescenta um cooldown. Timeouts aparecem como CountFailure sem reduzir o limite. A latência só orienta a escolha de relays; o benchmark com três relays continua insuficiente para afirmações gerais de desempenho.

eventstore

O eventstore, biblioteca de fiatjaf com backends de armazenamento para events Nostr, mesclou duas correções de consulta. Nenhuma versão com tag que as contenha foi verificada. Todos os backends agora seguem a regra da NIP-01 para listas de filtro vazias: uma lista vazia de ids, authors, kinds ou tag não corresponde a nada, enquanto uma lista de tag ausente (nil) continua sem impor restrição. Uma correção na contagem de events no LMDB avança o cursor do HyperLogLog após uma correspondência, de modo que as contagens não travam mais indefinidamente. Além disso, a contagem deixou de aplicar verificações de autor, kind ou tag quando o filtro não as tem, o que antes fazia com que retornasse zero.

zsp

O zsp, ferramenta de linha de comando do Zapstore para publicar apps Android no Nostr, lançou a versão 2.0.0. O README nessa tag oferece um assistente em que uma pessoa comprova a posse do certificado de assinatura C1, além de um comando zsp skill que dá a agentes instruções de publicação. Ele proíbe entregar aos agentes o keystore, sua senha ou quaisquer chaves privadas, para que a comprovação continue sendo humana. A versão também detecta keystores JKS e PKCS12 pelo conteúdo, então stores PKCS12 nomeados .jks ou .keystore são carregados tanto no assistente quanto no fluxo de publicação. Não testamos a publicação com ela.

nsite-gateway

O nsite-gateway, que serve sites estáticos publicados no Nostr, lançou a versão 3.6.6. A alteração no código-fonte atualiza para o Applesauce 7 e restaura a expiração de events. Versões anteriores substituíam deliberadamente o gerenciador de expiração por um desativado, para contornar um bug upstream de limitação (clamping) de timers, e por isso events de sites expirados podiam permanecer ativos indefinidamente no store do gateway. Com a correção upstream aplicada, o gateway volta a usar o event store normal. Aqui, a expiração determina o que o gateway mantém e serve, e não apaga events de relays nem de caches de terceiros. Não testamos um gateway implantado.

44billion

O 44billion, um lançador de apps Nostr, mudou a forma como lembra permissões. As concessões salvas agora ficam vinculadas ao app, ao nome da permissão, ao kind do event e ao escopo, e uma concessão curinga de kind -1 não autoriza mais kinds específicos. Os escopos só são granulares para pares registrados de kind e escopo com rótulos traduzidos; escopos desconhecidos recaem em um escopo vazio que abrange o kind inteiro, e o registro começa vazio. A versão 5 do esquema do IndexedDB redefine intencionalmente as concessões da versão 4 e remove, na inicialização, concessões com escopo não suportadas, preservando os demais dados dos apps. A API personalizada de criptografia pessoal inclui helpers no estilo NIP-44 v3 que não constituem um padrão aceito. Trata-se de uma alteração de código-fonte sem versão ou implantação identificada.

Código-fonte mais recente adiciona configurações de Acesso a Dados de Apps, que agrupam as concessões lembradas por app e permitem aos usuários revogar uma concessão ou um app inteiro sem recarregar. A revogação afeta apenas solicitações protegidas futuras. Dados já armazenados ou copiados não são apagados, e trabalhos já em andamento podem não ser interrompidos. Uma alteração no cache de assets do Blossom só considera completo um asset em cache depois que o SHA-256 do corpo inteiro confere e um marcador de validação correspondente é armazenado. Chunks provisórios de caches mais antigos são revalidados, e o streaming não informa mais um falso chunk final. Isso não significa que nenhum byte seja exposto antes da validação, e não há nova versão binária.

Blossom Servers

O diretório Blossom Servers adicionou relatórios de capacidades da comunidade para cada URL de servidor, cada um atribuído a quem o contribuiu. Declarações manuais e observações feitas pelo navegador são mantidas separadas e deixam de contar nos filtros após 90 dias e 24 horas, respectivamente. As verificações examinam respostas HTTP e métodos anunciados, além de desafios de auth e de pagamento. Verificações anônimas pelo navegador enviam uma requisição HEAD propondo metadados de um PNG de 68 bytes sem fazer upload de nada, então uma resposta 200 não prova que um upload real funcione. O carregamento das discussões agora tem escopo, e a atribuição ao contribuidor substitui a autoridade de operador que antes ficava implícita. Um relatório não prova quem opera um servidor e não diz nada sobre disponibilidade global nem sobre conformidade total com BUD; contribuidores podem discordar ou estar errados. Não verificamos implantação nem versão.

Código-fonte mais recente adiciona relays de app e de lookup configuráveis e lê contas e outboxes por meio da NIP-65. Uma lista pública de lookup de kind 10086 já existente tem precedência. Salvar só atualiza a lista pública se ela já existir; caso contrário, a alteração permanece local. O registro local de publicação só é atualizado depois que pelo menos um relay confirma o event, o que não significa que todos os relays o receberam. Nenhuma versão ou implantação está confirmada.

Ditto

O Ditto, cliente Nostr da Soapbox, corrigiu metadados H.264 produzidos por encoders WebCodecs malformados para que vídeos transcodificados possam ser reproduzidos no iOS. Ele detecta bytes de cabeçalho NAL de SPS e PPS duplicados e bits reservados incorretos no registro avcC e os corrige antes que o muxer Mediabunny grave os metadados MP4, deixando inalterados os registros bem formados ou não reconhecidos. A versão 2.45.1 já saiu, mas não confirmamos que ela contém a correção nem testamos a reprodução em um dispositivo iOS físico. A alteração mira essa falha do H.264, não todos os codecs ou vídeos.

Signer desktop do Amber e correção de NIP-46 no Android

O Amber, signer Nostr para Android, mesclou em 27 de outubro código-fonte de um signer NIP-46 para desktop em Compose (Windows/macOS/Linux) que espelha o modelo de permissões por app e por kind do Android (commit). A NIP-55 continua exclusiva do Android. O código para desktop suporta várias contas e conexões nostrconnect/bunker com relays e histórico por app, além de Tor e notificações na bandeja do sistema. As chaves ficam em armazenamento PKCS12 criptografado, protegido por uma passphrase Argon2id obrigatória, com bancos de dados criptografados por conta. Não verificamos o empacotamento para desktop nem o comportamento em execução.

Uma alteração separada, também mesclada, no app Android, e não no signer para desktop, atualiza as subscriptions de relays NIP-46 e os filtros de conexão depois que uma conta faz logout. Com isso, o Amber deixa de escutar as chaves de uma conta excluída. A notificação com conteúdo ocultado na tela de bloqueio agora também mostra a descrição da solicitação. Isso torna a notificação mais útil, mas não acrescenta privacidade. Nenhuma nova versão estável com qualquer uma das alterações do Android está confirmada.

Intents de napplets e dados de app sincronizados no noStrudel

O cliente web noStrudel mesclou várias alterações de código-fonte, sem tag ou implantação confirmada. Intents entre napplets são resolvidos pelo catálogo e pelas declarações de manifesto z/i, e os payloads aceitos são entregues depois que o frame de destino carrega, com um ID de remetente atestado em runtime; intents não suportados são rejeitados, e handlers com destino explícito exigem confirmação do usuário (commit). Napplets instalados e handlers padrão são sincronizados por conta em dados de app de kind 30078 criptografados com NIP-44, com merge de três vias (commit), e os monitores de relay da NIP-66 selecionados são sincronizados por meio de dados de app NIP-78 criptografados (commit). Mensagens NIP-17 hidratam gift wraps em cache e reconciliam trinta dias a partir dos relays de DM uma vez por sessão, usando NIP-77 onde houver suporte, com o histórico mais antigo disponível sob demanda (commit).

Nostr Feedz arquivado

O Nostr Feedz, que combinava RSS com conteúdo long-form e vídeo do Nostr, agora informa em seu README que está arquivado e não recebe mais manutenção (commit). O aviso aponta o Readstr, de PrivKey, como um fork que dá continuidade ao desenvolvimento. Trata-se de uma mudança no status de manutenção, e não verificamos se o GitHub marca o repositório como arquivado nem se contas e dados são transferidos.

Zap Cooking: listas protegidas, correções de signer e cadastro com passkey

O Zap Cooking, cliente Nostr de compartilhamento de receitas, mesclou um grande lote de alterações no código-fonte web; implantação ou versão não estão confirmadas. As gravações de listas salvas de kind 30001 agora leem primeiro e são serializadas por conta, preservando tags alheias e conteúdo criptografado a partir da base completa mais recente, e são recusadas quando a lista de relays é desconhecida ou falta quórum (#869). O quórum exige pelo menos duas respostas EOSE de relays capazes de lidar com listas, mais metade dos relays de escrita capazes do usuário, e uma resposta vazia do nostr.wine não pode provar ausência (#878). Coleções personalizadas compartilham o gravador protegido, operações antigas na fila são reexecutadas sob novas proteções (#885), e um EOSE agregado vazio, por si só, não faz mais uma lista aparecer vazia (#872).

Um método de auth explícito corrige um bug de minificação em produção que confundia as classes de signer. Assim, a criptografia via NIP-46 e NIP-07 usa o signer ativo, e não uma chave local obsoleta; o backup da carteira em relays continua bloqueado para NIP-46 (#896). Um login iniciado a partir de um salvamento ou de uma reação retoma essa ação. Um zap pendente mantém o valor e o destino, mas ainda exige acionar Send. Recusas do signer exibem um erro, sem reassinar silenciosamente com a chave de um estranho (#867).

O cadastro cria a identidade localmente, com a sincronização do cofre criptografado por passkey ativada por padrão; uma chave de backup é exigida se a sincronização estiver desativada ou se o upload falhar, e o Google Drive serve apenas para restauração (#893). A configuração do WebAuthn PRF com um único prompt deixa o cofre não confirmado e a nsec em texto puro no navegador até que uma descriptografia bem-sucedida posterior do cofre o confirme e remova a chave em texto puro (#907). Estender esse prompt ao cadastro depende de um registro não assinado que não constitui autenticação: qualquer pessoa com um desafio novo do servidor pode forjar um registro aprovado, e um atacante que conheça o ID da credencial pode substituir uma entrada não confirmada (TTL de 30 dias) e negar a sincronização ao usuário real (#911). Trata-se de compromissos documentados, não de garantias de segurança.

Os links de notas são codificados como nevent do NIP-19 com até três dicas de relay observadas, o que ajuda os clientes a encontrar events pouco replicados sem garantir disponibilidade (#873). As Respostas do perfil incluem comentários kind 1111 do NIP-22 enraizados em events (#877), e uma correção no parser de coordenadas mantém receitas com d-tags de URL em pacotes e planos (#888). O experimento de paywall para receitas premium foi aposentado depois que uma auditoria feita pelo próprio autor do código encontrou um bypass via pubkey na consulta; as postagens legadas de kind 35000 continuam legíveis como conteúdo armazenado (#862).

Uma proposta aberta, ainda não mesclada, trata das listas de silenciamento (#921). Uma busca indisponível da lista de silenciamento continuaria distinta de uma busca bem-sucedida que retorna uma lista ou nenhuma lista. A mudança deixaria de armazenar em cache, por cinco minutos, uma busca indisponível como lista vazia. Falhas de parsing seriam tentadas novamente, com um aviso quando silenciamentos privados não puderem ser descriptografados. Abrir o sino de notificações recarregaria a lista. O objetivo é impedir que uma lista de silenciamento vazia, desatualizada sem nenhum aviso, deixe autores silenciados entrarem nas notificações. Ela não faz com que todas as falhas bloqueiem conteúdo, e não está implantada.

Pagamentos de zap via NWC no Lumilumi

O Lumilumi, um cliente web de Nostr, tem um pull request em rascunho que pagaria invoices de zap pelo Nostr Wallet Connect (NIP-47) com um toque (#1120). A URI da conexão de gasto é armazenada apenas localmente e fica de fora do backup de configurações kind 30078 em texto puro. Quando a carteira anuncia nip44_v2, as requisições usam NIP-44; caso contrário, recorrem ao NIP-04. O autor testou com uma carteira simulada, sem nenhum pagamento real, e o rascunho não estava mesclado na data de corte das nossas fontes.

Busca por identificadores no Wisp

Um pull request aberto para o cliente Nostr Wisp, não mesclado na data de corte das nossas fontes, faria a busca reconhecer identificadores NIP-19 e NIP-05 colados, chaves hex e links de entidades web antes de recorrer a uma consulta de texto do NIP-50 (#681). As buscas usam dicas de relay e o cache local. Os resultados chegariam em streaming enquanto a busca aguarda o EOSE dos relays consultados, com limite de 15 segundos, de modo que relays lentos deixam de ser descartados. O autor relata testes apenas em emulador, não em dispositivo físico.

Suporte a Android TV no Zapstore

O Zapstore, a loja de apps baseada em Nostr, tem um pull request v2 aberto para Android TV, não mesclado na data de corte das nossas fontes (#407). Ele faria a correspondência de ABIs de 32 bits e daria suporte ao foco Leanback apenas por controle remoto, com um fallback quando a tela de permissão de instalação não estiver disponível. Builds de 32 bits sem Arti mostram explicitamente uma conexão somente Direct, enquanto builds de 64 bits sem Arti falham de forma fechada (fail closed). O build de TV usa um signer de depuração local para testes, e não para distribuição. No único teste do autor em TV, foi usado um relay compilado localmente porque o bundle público estava indisponível.

Propostas de hardening e de NIP-11 no strfry

O strfry, o relay Nostr em C++, tem duas propostas não mescladas na data de corte das nossas fontes. O #281 responde aos achados SF-01 a SF-13 da auditoria do relay limitando a profundidade de JSON, os payloads descomprimidos, as filas e os rótulos de métricas, corrigindo um crash com filtro negentropy vazio e aplicando hash aos índices de tags longas. Ele passa para o formato de DB 4, então quem adotar a mudança teria de exportar e reimportar os dados. Os testes aprovados são do próprio autor. Já o rascunho #278 anunciaria apenas as limitações do NIP-11 efetivamente aplicadas, além de fees e payments_url opcionais, com payment_required definido como false por padrão e preços configurados que não implementam pagamentos.

Pagamentos Bark no nostrcheck-server

O nostrcheck-server, um servidor de hospedagem de mídia Nostr, tem um pull request em rascunho que adiciona um provedor de pagamento barkd (Bark) (#62). Ele criaria invoices Lightning pela API REST do barkd e, opcionalmente, anexaria às respostas 402 uma URI BIP-321 X-Ark por arquivo, com a mesma invoice Lightning como fallback. Uma carteira no mesmo servidor Ark paga via Ark, as demais usam Lightning, e um pagamento liquidado desbloqueia o arquivo uma única vez. Os testes usam um barkd simulado, e a mudança depende do pull request aberto #61 do BUD-07. Ela não estava mesclada na data de corte das nossas fontes e não é um recurso disponível em share.yabu.me.

Escritas pagas no nostr-relay de mattn

Um pull request em rascunho para o nostr-relay de mattn, não mesclado na data de corte das nossas fontes, adicionaria escritas pagas opcionais por meio de uma carteira Bark, desativadas por padrão (#37). Pubkeys pagariam antecipadamente as taxas de escrita via barkd, com um filtro de kind opcional, e quem tentar escrever sem crédito recebe uma resposta restricted: com uma URL de pagamento. As recargas usariam Ark ou Lightning via URIs BIP-321 ou NWC, com as taxas listadas no NIP-11. Os testes usam um daemon simulado. Ainda não está decidido se isso pertence à árvore principal ou deve ficar atrás de um hook.

Proteção contra replay na reconexão do ContextVM

O ContextVM, que transporta MCP sobre Nostr, tem um pull request aberto para seu SDK TypeScript que evitaria execução duplicada após reconexões a relays (#113). O transporte do servidor manteria os IDs de events verificados até ser fechado, e um cache de envelopes separado e limitado bloqueia duplicatas reempacotadas. A memória cresce conforme os events verificados únicos ao longo da vida útil do transporte. A correção não estava mesclada na data de corte das nossas fontes e não consta em nenhum pacote publicado.

Reprodução de mídia e aprovações no shell Kehto

O Kehto, um shell web para napplets Nostr, mesclou a reprodução NAP-MEDIA em 28 de outubro. Os hosts Paja e playground agora compartilham um player de áudio e vídeo mediado por política. Ele usa os codecs do navegador para fontes finitas de URL e Blossom e reproduz streams ao vivo HTTPS em MP3 ou ADTS AAC onde o MediaSource suporta o codec, começando antes de a resposta terminar. A autoridade da sessão continua vinculada ao endpoint, à janela de origem e à ACL. Revogação ou desmontagem aposenta as URLs Blob, interrompe a reprodução e cancela os streams. Exclusivo do host, o método ResourceService.openStream usa as concessões e a política existentes por origem do endpoint, sem adicionar nenhuma mensagem de recurso no protocolo. A entrega terminal permanece. O alias legado sendCommand continua funcionando. Separadamente, callbacks detectáveis de dois argumentos seguem funcionando, com um aviso. Callbacks legados unários passam para objetos de comando. O resolvedor do navegador rejeita URLs não HTTPS, credenciais e literais de IP privado. Também desativa redirecionamentos e referrers. Como não consegue inspecionar o DNS, ele não garante proteção contra endereços privados no momento da resolução: resolvedores de produção precisam de verificações no momento do DNS, e o padrão do navegador depende de CORS e da proteção de rede privada. HLS, DASH, Ogg ao vivo, fontes Nostr, filas, persistência e retomada automática ao ganhar foco continuam sem suporte. O autor relata 155 testes no Chromium e 112 segundos de reprodução de rádio a partir de um artefato Funclet não modificado, o que não executamos novamente. Trata-se de trabalho apenas no código-fonte. O pacote Napplet 0.32 publicado não tem alguns dos tipos do rascunho. O NAP-MEDIA continua em rascunho; nenhuma conformidade em versão publicada é reivindicada.

Uma segunda mudança mesclada torna as aprovações de assinatura e de publicação específicas por versão. Cada aprovação fica vinculada ao publicador verificado, ao hash do artefato e ao signer ativo. As aprovações podem ser revogadas, e as aprovações apenas de assinatura e apenas de publicação são separadas. Uma permissão legada nunca é promovida silenciosamente. O consentimento para uma URL de desenvolvimento mutável vale somente para aquele carregamento, e uma troca de endpoint ou de conta rejeita as solicitações pendentes. O NAP-LINK só abre um link após um clique explícito em um modal do host, usando noopener. A mudança não alega testes universais com fontes de rádio CVM externas, e uma mesclagem no código-fonte não indica um release no npm.

Pact

O Pact, um protocolo Nostr para relações entre agentes e consentimento de operadores, agora autentica as respostas do Nostr Wallet Connect. Cada resultado precisa trazer a assinatura da carteira e referenciar sua requisição, e o Pact verifica o tipo de resultado e o hash de pagamento, além de qualquer preimage retornada. O resgate ganha gravações atômicas no ledger, além de proteções no consumo e na repetição de requisições, e mais caminhos de falsificação de consentimento foram fechados. Um acompanhamento que limita os pagamentos MCP os mantém desativados, a menos que PACT_MCP_ALLOW_PAYMENTS=1 esteja definido, e verifica um limite padrão de 1.000 sats tanto no valor declarado quanto no valor do BOLT11. A janela da caixa de entrada privada agora para em 200 wraps e sinaliza o truncamento. Os testes do autor dependem de mocks.

nostr.watch

O nostr.watch, um monitor de relays Nostr, adiciona suporte explícito à descoberta e ao transporte FIPS, e as consultas de overlay não recorrem mais ao DNS-over-HTTPS público. Os hosts ainda fornecem o DNS e o roteamento IPv6, já que o monitor não inclui daemon nem proxy FIPS e não oferece anonimato. Uma verificação de npub mais rígida aceita npubs apenas dentro de hostnames .fips analisados. As sondagens automáticas de NIP-11 e NIP-05 passam para um ServiceWorker controlado pelo app, o que remove o contexto da aba proprietária do caminho de navegação observado, conduzido por extensão; isso foi verificado no Firefox 155 padrão com um fixture de extensão controlado. A suíte de conformidade reúne quinze verificações delimitadas do NIP-01, com uma camada de conversa que suporta conexões independentes. O autor relata testes aprovados e execuções isoladas em mesh, não uma auditoria em relay público nem de segurança de navegador.

Bitcredit Core

O Bitcredit Core, um protocolo peer-to-peer de crédito e títulos que usa Nostr, agora verifica se pelo menos um relay de escrita está conectado antes que uma operação de bloco persista qualquer coisa localmente ou dispare seus efeitos. A recuperação também é reinicializada de forma limpa. A validação de cadeia candidata, relatada como aberta na semana passada, já foi mesclada, de modo que as cadeias são validadas e preparadas antes de serem persistidas. Essas etapas reduzem a chance de estado local inconsistente. Um relay conectado não garante que os relays aceitem o event nem que a liquidação seja concluída, e essa verificação, por si só, não torna a persistência local durável.

Uma mesclagem mais recente, não confirmada em release, adiciona um gerenciador de transações ao serviço de identidade. Blocos de identidade, estado e confirmação de e-mail agora passam por um commit atômico antes que qualquer coisa se propague pelo Nostr, e novos testes verificam que nada é enviado quando o commit falha. Isso abrange apenas o serviço de identidade. A persistência de títulos e de empresas não tem esse commit atômico, e a aceitação pelos relays e a liquidação continuam sem garantia.

Compatibilidade entre MLS-KMP e Marmot

O MLS-KMP, a biblioteca MLS em Kotlin subjacente ao marmot-kmp, já havia corrigido vários comportamentos de wire para se alinhar a outras implementações de MLS; por isso, membros na 1.2.0 e nesse código mais novo divergem nos casos listados, e os grupos precisam atualizar juntos. O estado salvo passou para a versão 10, que releases mais antigas não conseguem restaurar. O job de compatibilidade downstream com o Marmot não é bloqueante. Seus testes não rodaram no ambiente em que essa mudança foi escrita; o Marmot ainda precisa se adaptar a authorizeProposal e ao GREASE. Uma mudança anterior em app-components impõe os componentes de que o Marmot precisa para acompanhar o MDK v0.14. Não verificamos a adoção no Amethyst.

Código-fonte mais novo já mesclado, não atribuído à 1.3.0 publicada, repara a compilação do runner noturno de interoperabilidade e informa aprovado, reprovado ou ignorado para cada script. Nossa nota anterior de que o runner ao vivo nunca havia rodado está, portanto, desatualizada: os autores relatam execuções funcionando, embora a execução final ainda estivesse em andamento quando a mudança foi aberta e não tenhamos conferido um resultado final de CI. O job do OpenMLS continua não bloqueante, pula 22 cenários sem suporte ou que causam panic e cobre apenas o ciphersuite 0x0001, portanto não certifica interoperabilidade. Essa mudança também corrige a busca de PSK do ReInit pelo ID de grupo retido, o transcript interino da época zero, o segredo aleatório da primeira época e o tratamento do PSK de retomada em external commits. No caso do transcript da época zero, o código agora segue a seção 11 da RFC 9420 para se alinhar ao OpenMLS; assim, external joins na época 0 diferem da 1.3.0 e de releases anteriores, e grupos antigos salvos mantêm o hash antigo até o primeiro commit. O motor original derivava o segredo da primeira época a partir de zero. Os autores não identificaram nenhum exploit, porque os commits posteriores carregam um UpdatePath novo, e a correção não mostra que todos os problemas de segurança estejam resolvidos.

Obelisk Relay

O Obelisk Relay mesclou em seu branch padrão uma correção para grupos NIP-29 privados. Admins globais do relay já podiam enviar REQs para grupos privados, mas o filtro de visibilidade de events ainda rejeitava os events correspondentes. Agora os admins do relay conseguem ler esses events, e as verificações de acesso de membros continuam em vigor. Grupos privados no nível do relay não têm criptografia de ponta a ponta, e a mudança torna explícita a visibilidade do admin do servidor. A correção é trabalho de código-fonte mesclado, voltado a desenvolvedores e operadores.

Plume

Plume, o cliente desktop em Rust e Tauri, incorporou uma mudança que mantém um único WebSocket persistente e com reconexão por relay. As operações de feed, perfil, publicação e mensagens diretas compartilham essa conexão. Inscrições (subscriptions) e IDs de event são multiplexados por ela. As tentativas de reconexão usam backoff; as conexões são fechadas quando o app é encerrado. Antes da mudança, cada operação abria um socket novo, que depois nunca era fechado nem liberado. A mudança revisada é trabalho de código-fonte já incorporado; nenhuma medição de desempenho é estabelecida aqui. Ela não promete recuperação sem perdas nem entrega garantida.

Hashtree

O runtime TypeScript 0.5.22 do Hashtree permite que provedores de navegador mantenham até 256 anúncios públicos de peers, atuais e assinados, no IndexedDB, com escopo por identidade e por app. Os provedores podem recarregá-los antes da descoberta pela rede. REQs comuns de peers podem reproduzir esse cache onde as regras de admissão existentes permitirem, e a descoberta privada continua em um escopo de proprietário separado. Em outra frente, uma mudança incorporada no adaptador Rust cancela leituras de índice abandonadas, de modo que os comandos não precisam mais esperar o tempo limite completo do transporte. O pull request informa que o hashtree-nostr-pubsub 0.2.87 foi publicado, e esse pacote tem versionamento separado do runtime TypeScript. Commits do cliente Rust, presentes apenas no código-fonte, adicionam origens Blossom legadas, de leitura e de escrita combinadas para leituras e uma nova tentativa para resets de conexão tipados na etapa de requisição por fonte, sem armazenar respostas parciais em cache. Uma única instalação a frio em um Mac não prova que os timeouts intermitentes de transferência foram corrigidos.

nostr-pubsub

O nostr-pubsub TS 0.5.20 mantém um armazenamento limitado de events assinados e adiciona persistência em IndexedDB, transações atômicas entre abas, expiração e replay local para REQs Nostr comuns. À parte, a mesma fonte descreve uma API opcional de armazenamento em arquivo, nativa em Rust, com snapshots atômicos e uma concessão exclusiva de escritor, distinta do pacote TypeScript. Na implementação do armazenamento durável de events, os recarregamentos verificam novamente as assinaturas e os vencedores de events substituíveis do NIP-01, além de rejeitar events efêmeros e timestamps mais de cinco minutos à frente do horário atual. Os armazenamentos nunca são abertos implicitamente, e quem faz a chamada escolhe o escopo dos anúncios públicos. O FIPS restaura anúncios assinados de kind 37195 antes da descoberta pela rede e continua verificando atualidade, esquema e namespace. Caches de descoberta anônima ou privada precisam ficar separados do replay público, e um roteador que busca dados na rede não deve ser usado como fonte de replay. Como a retenção é limitada, isso não oferece bootstrap offline por tempo indefinido.

FIPS-TS

O runtime FIPS-TS 0.0.57 aceita um provedor de descoberta durável pertencente à aplicação, que publica anúncios assinados de kind 37195 e se inscreve neles pela interface existente. Com um provedor injetado, o transporte não abre nenhum cliente de relay Nostr e aceita uma lista de relays vazia, e o encerramento drena as inscrições pendentes. Quem faz a chamada é responsável pelo ciclo de vida do provedor e pelo armazenamento restaurado. As verificações de namespace, assinatura e expiração continuam valendo. A autorização de peers segue obrigatória. Anúncios em cache não garantem bootstrap offline, porque o novo roteamento autenticado e a sinalização WebRTC ainda precisam de um carrier FIPS alcançável.

Flotilla

O Flotilla incorporou três mudanças no código-fonte. O Compartilhar no chat permite que os usuários compartilhem notas avulsas e comentários NIP-22 em qualquer sala ou conversa. Citar algo em uma conversa não adiciona mais o autor citado às p-tags nem bifurca a lista de membros. A retomada de uploads interrompidos restaura uploads de anexos a partir de rascunhos e, ao exibir um erro, permite que os usuários se recuperem de uploads com falha. Se a compressão falhar, recorre-se ao arquivo original, que pode manter seus metadados. A espera pelos marcadores de leitura armazenados segura as gravações de marcadores de leitura da página até que o estado de leitura armazenado seja carregado, para que atualizações de leitura feitas logo no início não se percam na inicialização.

following.space

Um pull request aberto para o following.space, ainda não incorporado na data de corte das nossas fontes, restauraria a criação, a edição e a exclusão de follow packs, além de permitir seguir os membros de um pack. Ele usaria o Applesauce para a descoberta de contas e de relays outbox e compartilharia packs como endereços naddr. Há suporte a signers de extensão de navegador, a um segredo mantido apenas na memória e a signers bunker. O código e os testes descritos pelo autor não demonstram um serviço implantado nem compatibilidade com todos os signers.

Routstr

Três pull requests do Routstr estavam abertos e não incorporados na data de corte das nossas fontes. No serviço principal, a descoberta de saúde de provedores rejeitaria URLs anunciadas e redirecionamentos que resolvem para endereços não globais, mantendo o tratamento de proxy onion. Os autores descrevem uma exposição a server-side request forgery (SSRF) e testes, mas isso não é uma correção implantada nem um exploit confirmado. No SDK, o crédito do provedor por uma URL seguiria a chave que assinou o event de kind 38421. Uma pubkey escrita no conteúdo continua sem verificação. Entre os 81 events que o autor verificou no relay padrão, nenhum tinha listas de provedores baseadas no conteúdo; portanto, não se afirma que URLs conhecidas tenham sido exploradas nem que todos os provedores estejam seguros agora. O auto-pinning de caminhos de modelo deixaria as constantes embutidas e passaria a usar snapshots assinados em events endereçáveis confiáveis de kind 38427. O SDK manteria o último snapshot válido e marcas d’água contra rollback, e um snapshot vazio funcionaria como kill switch. A mudança quebra a API de adaptadores personalizados. Nenhum event de política foi publicado, e o rollout ainda é uma etapa a cargo do operador.

SatSigner

Um pull request aberto para o SatSigner, não incorporado na data de corte das nossas fontes, reformula sua camada de relays, cache e sincronização Nostr. Não encontrar um event (a resposta de fim de events armazenados de um relay) seria tratado separadamente de timeouts e da ausência total de relay. Conteúdo em cache desatualizado seria sinalizado. Os events seriam armazenados antes que o processamento avançasse os cursores; os IDs de rumor de gift-wrap seriam verificados. Remover uma identidade apagaria suas tabelas Nostr, mas uma sincronização de kind 0 pode sobrescrever uma edição local de perfil. Um complemento empilhado sobre ele adicionaria diagnósticos com dados ocultados, pôsteres de vídeo carregados ao toque no feed Nostr com no máximo três players e atualização ao retomar o app, sem desmontar o pool de relays. Ele também adiciona testes de relay que injetam falhas. O novo módulo nativo de vídeo exige recompilar o app, e a validação em dispositivos está pendente. Nenhuma das duas mudanças foi lançada nem passou por uma verificação em tempo de execução.

Bray

O Bray 3.5.4 adiciona autenticação de relay NIP-42 ao seu cliente e daemon bunker NIP-46. Relays privados que exigem AUTH agora podem ser usados para ler mensagens endereçadas ao bunker. Mudanças posteriores no código-fonte não são estabelecidas por esta tag.

Em código-fonte incorporado depois, o servidor MCP do Bray inicia em modo somente leitura quando nenhum signer está configurado ou quando BRAY_READ_ONLY é forçado, e toma essa decisão antes de abrir quaisquer segredos. Nesse modo, nenhuma carteira é carregada, assinatura, criptografia e descriptografia são recusadas, e apenas 111 das suas 261 ferramentas, as de consulta, ficam disponíveis. A CLI e o SDK ainda exigem um signer, e um arquivo de segredo configurado, mas vazio, continua sendo um erro. Novas atestações agora usam um namespace de rótulos de atestação NIP-32, no lugar de nip-va. A consulta existente pelo tipo #l encontra tanto os rótulos antigos quanto os novos, enquanto o signet-protocol mantém sua própria cópia 2.5.5. Isso não é uma aceitação oficial como NIP e não significa que todas as bibliotecas aninhadas tenham migrado. Não há comprovação de que qualquer uma das duas mudanças esteja na 3.5.4.

Extensão de navegador Alby

Um pull request aberto para a extensão de navegador Alby Lightning, não incorporado na data de corte das nossas fontes, faria com que seu auxiliar de permissões rejeitasse entradas bloqueadas memorizadas em uma única leitura. Isso fecha uma condição de corrida em que remover uma entrada de negação poderia permitir que um handler Nostr agisse sem pedir confirmação. O caminho equivalente de entradas bloqueadas para BTC e Liquid não está acessível atualmente. Isso não é uma correção implantada, e nenhum exploit foi confirmado.

Política de escrita do relay do MintRadar

O código-fonte do MintRadar adiciona uma política de escrita do operador para o relay Nostr do projeto. Ela limita anúncios públicos de kind 38172 e avaliações de kind 38000 a 16.384 caracteres de JSON serializado por event e a 120 por hora por /64 IPv6, com prefixos IPv6 comprimidos convertidos para a forma canônica. Um teto flexível de 3.000 por hora se aplica a fontes de alto volume, e um limite absoluto de 6.000 por hora conta apenas events aceitos, somando todas as fontes. Chaves privilegiadas não têm limite. Novas conexões são limitadas a 120 por minuto, com burst de 60. Trata-se de código e configuração do operador, não de prova de implantação em produção nem de proteção completa contra negação de serviço.

Novos projetos

bosstro

O Bosstro é um novo cliente Android para solucionadores de disputas do Mostro. O código-fonte do MVP foi publicado, com front-end em Flutter sobre o núcleo Rust do Mostro. Os solucionadores assinam com uma chave de solucionador dedicada, nunca com a chave do nó, e o nó concede a cada um autoridade de leitura ou de leitura e escrita. Solucionadores autorizados podem assumir disputas, entrar em chats criptografados entre comprador e vendedor que incluem imagens e PDFs, e pagar o comprador ou reembolsar o vendedor. As chaves ficam em armazenamento respaldado pelo Android Keystore, mas as builds de desenvolvimento para Linux e web não contam com essas proteções. Checksums publicados não comprovam quem é o publicador.

cordn-kmp

O cordn-kmp é uma nova implementação Cordn em Kotlin Multiplatform, construída sobre Quartz e mls-kmp para JVM, Android, iOS, macOS e Linux. Seu CordnGroupManager headless cria grupos, convida, entra, envia e recupera o que ficou para trás por meio de um coordenador MCP sobre Nostr, um modelo diferente da entrega via relay do Marmot. Os frontends fornecem a própria persistência, e a afirmação de interoperabilidade com ts-mls no README vem do autor.

Desde então, o projeto publicou a 1.1.0, que compila contra o Quartz 2.4.0 já lançado; assim, a exigência anterior de um checkout local de um Quartz não lançado, atrás de uma flag de build, não se aplica mais às releases com tag. A 1.2.0 remove o método público CordnExposure.differsFromMarmot() e deixa a comparação com um binding diferente a cargo dos frontends. Apesar do número de versão minor, essa é uma mudança que quebra a API. Uma proposta havia chamado esta versão de 2.0.0, e a release real usa 1.2.0.

emosphere

O EmoSphere é um mapa de humor Nostr cujo código-fonte agora é público, e seu README descreve a versão 0.5.1. Cada dispositivo gera sua própria chave e publica events assinados de kind 1074 com uma emoção e uma intensidade, uma nota curta opcional e uma localização aproximada que os usuários podem desativar. As postagens aparecem em um mapa-múndi com replay temporal e um feed de quem se segue. Esses sinais são públicos e pseudônimos, então os relays podem ler humor e localização e vinculá-los a uma chave ao longo do tempo. No Android, as chaves ficam em armazenamento seguro, enquanto a versão web usa localStorage.

matrix-appservice-nostr

O matrix-appservice-nostr é código-fonte de protótipo de um application service Matrix pareado com um relay Nostr. Usuários Matrix podem criar ou importar identidades Nostr e publicar, seguir, responder, reagir e enviar DMs a partir de salas Matrix, com handles NIP-05 no domínio da ponte. Conteúdo e mídia ficam no backend Matrix, e o relay reconstrói os events a partir dos originais salvos. As chaves são criptografadas com AES-GCM sob um segredo configurado ou mantidas remotamente via NIP-46. Os usuários precisam confiar no operador, e uma remoção de conteúdo (redaction) no Matrix remove apenas a cópia da ponte.

Sete commits mais recentes adicionam identidades Nostr sombra. A ponte as cria automaticamente para usuários Matrix com permissão que interagem para fora, com perfis que espelham o Matrix. Criar um perfil completo faz o upgrade da conta existente no próprio lugar e mantém a mesma chave. Administradores da ponte podem conceder a usuários ou homeservers externos acesso completo ou sombra, ou ainda acesso passivo com escopo de sala para responder, reagir e votar. Uma concessão ou um banimento para um usuário específico prevalece sobre as regras de homeserver, que por sua vez prevalecem sobre as regras de sala. A permissão completa permite criar um perfil, mas não publica um automaticamente. Revogar o acesso preserva chaves, histórico e salas, mas interrompe as publicações para fora onde elas não são mais permitidas. Identidades importadas nunca são sobrescritas com um perfil espelhado. As verificações têm código e testes, mas não passaram por verificação de interoperabilidade em tempo de execução nem de segurança, e continua sendo preciso confiar no tratamento de chaves feito pelo operador. Figurinhas agora são enviadas como imagens.

nostr-scrutiny

Nostr Scrutiny publica fichas de fatos e de código-fonte datadas de 24 de outubro que comparam cinco clientes Nostr: Amethyst, Damus, Nostrich, Primal e Quill. Cada ficha cobre as declarações de privacidade do cliente nas lojas de aplicativos e o código publicado, além das requisições de rede observadas na primeira visita pelo navegador. Construído como HTML estático simples, o site afirma não ter rastreamento próprio. As fichas são um inventário datado de fatos, não uma certificação de segurança nem uma auditoria criptográfica. Em um conflito de interesses declarado, o autor também desenvolve o Quill.

v2

Solid Chat v2 é um código-fonte de cliente recém-publicado que usa uma única chave did:nostr para escrever em salas de pods Solid com autenticação HTTP NIP-98 e para enviar DMs com gift wrap NIP-17. A assinatura funciona via NIP-07, NIP-46 ou uma nsec local, com criptografia NIP-44 e wraps de kind 1059. As salas ficam em texto puro, protegidas apenas pela ACL de cada pod. Mídias de DMs criptografadas são enviadas ao Blossom, e as consultas de perfil vão para um diretório nostr.social. Uma nsec local fica guardada no localStorage, então um signer externo é mais seguro.

witchat

Witchat é o código-fonte de um cliente não oficial do bitchat para Windows e Linux. Ele conversa por uma malha Bluetooth de dispositivos próximos e recorre a gift wraps do Nostr entre favoritos mútuos. Também entra em canais públicos de geohash no Nostr, usando events de kind 20000 para mensagens e de kind 20001 para presença. A interoperabilidade com os transportes do bitchat é uma afirmação do autor, e os binários para Windows não são assinados. Relays Nostr podem ver endereços IP e metadados de canais, e as transmissões para dispositivos próximos atualmente trafegam apenas por Bluetooth.

wn-notify

wn-notify é uma CLI Python não oficial, feita só com a biblioteca padrão, que envia mensagens e arquivos para grupos do White Noise por meio de um wn-agent local pelo socket Unix marmot.agent-control.v2; o conector guarda as chaves, o estado MLS e os relays. A CLI verifica final_sent e os IDs das mensagens. Diante de um resultado desconhecido, ela encerra com código diferente de zero, sinalizando o resultado como desconhecido, e mantém a chave de idempotência para uma nova tentativa manual, já que nunca tenta de novo por conta própria. Uma confirmação de recebimento atesta a publicação no relay, não que alguém tenha lido a mensagem. Apenas o wn-agent 0.13.0 foi testado.

xmradar

XMRadar é uma extensão de navegador que copia posts da web e artigos do X para o Nostr. Cada publicação é aprovada por meio de um signer NIP-07 externo. A versão 0.2.0 adiciona gorjetas em Monero no X para autores que têm uma identidade Nostr.

A implementação publica um recibo de kind 9042 somente depois que o usuário diz ter enviado uma gorjeta e confirma. O recibo torna públicos os npubs de ambos os participantes, o valor e o endereço. Ele não inclui ID de transação, chave de transação nem prova de pagamento. Um pequeno valor aleatório em piconeros permite que a carteira do destinatário identifique o pagamento e publique uma confirmação de kind 9044. Essa confirmação é assinada pelo destinatário e não constitui prova onchain independente. A interface distingue gorjetas confirmadas pelo destinatário de alegações não confirmadas. As gorjetas do próprio usuário ficam pendentes por 30 minutos. Alegações não confirmadas contam uma vez por pagador, pelo menor recibo enviado ao endereço atual; essas alegações podem ser forjadas. Os totais são mantidos por autor, não por post. A descoberta de endereços via NIP-A3 e provas do X da NIP-39 vem desativada por padrão. Quando ativada, relays e o X podem ver quais identidades o usuário visualiza.

agent-inbox

agent-inbox é uma nova ferramenta que permite a agentes de IA se comunicarem entre si por handles curtos pelo Nostr. Um único arquivo Python envia gift wraps NIP-17 padrão com criptografia NIP-44 v2, pode postar em um mural público e inclui fixtures dos vetores de teste oficiais. Os handles são sufixos truncados de chaves públicas, não identidades certificadas. O README alerta que sua criptografia em Python puro não é de tempo constante, e nós não a auditamos. Qualquer cliente NIP-17 ainda pode enviar mensagens ao npub de um agente.

CarryChat

CarryChat é um novo mensageiro store-and-forward que transporta pacotes limitados de mensagens por qualquer caminho disponível. Seu transporte pela internet é o Nostr, e links locais como Bluetooth LE e a simples troca de arquivos cobrem os casos offline. O código-fonte inclui o transporte Nostr junto com testes para ele. No README, isto é descrito como uma versão 0.2 inicial, com a ressalva de que os testes de campo de LoRa em hardware físico não foram concluídos. Não o testamos em dispositivos.

Treze commits mais recentes, até 311f176, substituem marcadores provisórios do roadmap por código-fonte funcional. Eles abrangem Wi-Fi Direct, um adaptador de rádio MeshCore, links Reticulum, cartões de contato NFC e um transporte por áudio, com código Kotlin, Rust e de interface. No áudio, o receptor verifica as assinaturas dos cartões de contato e aceita frames normais de mensagem, mas recusa fragmentos de arquivo. O NFC troca apenas cartões de contato, não mensagens. Trata-se de desenvolvimento de código-fonte posterior à versão 0.2.0 anterior, não de um novo binário verificado. O README diz que MeshCore e LoRa, Reticulum, Wi-Fi Direct e NFC ainda aguardam testes de campo ou com dois celulares. As mudanças não alegam compatibilidade de hardware, anonimato nem segurança. O áudio de alta frequência depende do hardware e não é inaudível em todos os casos. O Nostr continua sendo um transporte via relay pela internet, ao lado dos links locais.

Cosign e Marble

Cosign é um novo protocolo e biblioteca em beta que divide uma chave de assinatura Nostr em shares de limiar FROST. O dispositivo do usuário pode assinar em conjunto com um servidor, mas os servidores não conseguem assinar sozinhos. Uma share de backup em papel dá suporte aos fluxos de recuperação e de renovação de shares descritos no README, cuja segurança não foi verificada. O Marble, um cliente para Android e navegador, usa o Cosign para feeds e assinatura. A biblioteca FROST subjacente foi auditada, mas o protocolo próprio do Cosign não passou por nenhuma revisão independente.

Em código-fonte mais recente, o cliente de navegador do Marble vincula notas não enviadas à conta conectada. Antes de publicar, ele percebe quando outra aba ou uma sessão remota encerrou o login, e uma solicitação vinda de um cliente desconectado exibe Signed out. A busca instantânea consulta o Ditto e relays, não a web em geral. Ao buscar os posts de um autor, ela verifica os posts já carregados antes de consultar os relays. Prováveis spams ficam recolhidos atrás de um aviso expansível. Uma exceção Not Spam vale apenas naquele navegador e apenas para aquele autor. Esses recursos auxiliares de busca não são evidência de uma revisão de segurança.

O Cosign 0.12.7 faz com que mesclagens da lista de membros só possam vir de servidores, o que impede que uma share de backup em papel seja promovida a outra função. Após uma sincronização de epoch, servidores desatualizados são marcados como atrasados. Resultados parciais inválidos são recusados; o reparo automático continua desativado. Os parciais de descriptografia agora trazem provas de Chaum-Pedersen, que são verificadas antes de os parciais serem combinados. Clientes mais antigos ignoram as provas, e a parte Android do Marble as recebe em seu próximo build. Essas descrições de segurança vêm do autor da versão, e não auditamos a criptografia.

Código-fonte NIP-55 para Android registrado em commit após a tag 0.12.7 corrige uma condição de corrida na primeira conexão, quando a autorização do servidor ainda está chegando pelos relays. As consultas de chave pública agora respondem de imediato. Assinatura e descriptografia aguardam fora da thread de UI e tentam de novo uma vez, e somente quando uma conexão recém-autorizada recebe uma resposta de revogação. O código também diferencia um servidor inacessível de um que responde com uma recusa. Essa correção posterior no código-fonte não está estabelecida na tag 0.12.7 nem em um binário atual do Marble.

Dream Nests

Dream Nests é um novo diretório somente leitura de salas de áudio Nostr ao vivo que reúne salas do Nests e events de atividade ao vivo junto com seus chats. Para leitores de tela, o app web usa cabeçalhos e anúncios em regiões dinâmicas (live regions) no modo polite, e earcons curtos servem como sinais sonoros. Ele reproduz streams HLS públicos apenas para escuta. Salas do Nests abrem no Nests, enquanto salas do Corny Chat e do HiveTalk abrem nos próprios sites, de modo que a fala permanece nesses apps. Os indicadores de microfone vêm de metadados de presença, não de detecção de atividade de voz. Não testamos a acessibilidade em dispositivos. O repositório documenta uma URL pública ao vivo.

fips-pub-pki

fips-pub-pki é um novo código-fonte para certificados Nostr assinados que permitem a um domínio delegar a subemissores, com validação de caminho offline. As âncoras de confiança vêm do projeto complementar fips-pub-domains, que combina declarações DNSSEC com pins e testemunhas. O verificador nunca consulta o DNS. A revogação depende de expiração e de marcadores explícitos, não da exclusão de events dos relays. O README diz que os testes de malha ao vivo com um domínio público e um celular não foram concluídos. Sem nenhuma NIP submetida nem kind registrado, isto é um experimento, não um substituto do TLS.

Magnetar

Magnetar é uma nova stack de busca para events de torrent da NIP-35. Ela combina um crawler e um backend de busca com um app Android que mantém um cache SQLite local, constrói a confiança nos publicadores a partir de follows e verifica se os swarms estão ativos. O primeiro pré-lançamento 0.1 inclui o código do crawler e testes tanto para o Android quanto para o servidor. O autor o validou apenas com testes automatizados e um emulador, não em celulares reais. A confiança baseada em follows não torna um torrent legal ou seguro, e o backend não é um índice autoritativo.

Magnitude Relay

Magnitude Relay é um novo relay Nostr em Rust da VectorPrivacy, ajustado para as DMs com gift wrap do Vector e para o tráfego do Concord, com sincronização NIP-77 e indicadores de digitação. Os operadores dizem que ele substituiu o strfry em dois endpoints existentes do Vector. O repositório inclui harnesses de testes adversariais e de benchmarking, mas os números de velocidade publicados vêm das execuções do próprio autor e não foram reproduzidos de forma independente.

Desde então, o projeto incorporou empacotamento com Docker e Compose para operadores. Ele roda como usuário sem privilégios, com um volume de dados, um bind apenas local e um healthcheck. As observações de produção e de importação do pull request vêm do autor, e o arm64 não foi testado. O empacotamento, por si só, não demonstra conformidade com o protocolo.

Código-fonte mais recente limita por padrão as novas conexões por IP a um burst de 300 e, depois, a 60 por minuto. Definir o limite como 0 o desativa, e o loopback fica isento. O cabeçalho de IP real de um proxy só é considerado confiável quando vem do localhost, e conexões rejeitadas recebem HTTP 429 antes de o WebSocket abrir. Publicamente, as recusas do relay são informadas apenas de forma agregada, e o detalhamento por IP fica disponível só no socket de administração. A sincronização NIP-77 em massa deixa de fora events efêmeros e events que expiram em até 600 segundos, enquanto a entrega ao vivo continua transportando events de vida curta. Quando os links confiáveis mudam, o relay pula sondagens redundantes de visibilidade de gift wraps, mas os gift wraps continuam sendo sincronizados. São mudanças de código-fonte sem nenhum benchmark de produção medido.

nostr_doctor

nostr_doctor é uma nova biblioteca Dart, com uma CLI e um front-end em Flutter, que verifica se os clientes conseguem descobrir os dados de uma conta. Ela começa pelos metadados de perfil e pelas listas de relays NIP-65 e depois abrange relays de DMs privadas e rascunhos, além de servidores Blossom e configurações de nutzap. Para verificar a descoberta da lista de relays, ela sonda a lista substituível. Revisamos a ferramenta de diagnóstico como código-fonte e não verificamos nenhuma versão do app. Seus resultados refletem apenas os relays que ela consulta e não mostram disponibilidade global.

nostr-indexer-relay

nostr-indexer-relay é um novo relay em Go que armazena apenas listas de relays NIP-65. Seu crawler encontra relays citados nessas listas, sonda se eles suportam a NIP-77 e sincroniza com outros indexadores ativos via negentropy. O projeto inclui uma página pública de consulta e uma interface de administração, e se descreve como em estágio inicial. É um índice focado em listas de relays, não um arquivo do Nostr nem um relay de conteúdo geral.

nostr2gh

nostr2gh é uma nova ponte que leva events de patch e de pull request da NIP-34, junto com suas atualizações, do Nostr para o GitHub por meio de um relayer em lista de permissões. Um contribuidor envia um branch para um local acessível via fetch e assina um event Nostr; então um amigo com uma conta do GitHub funcional abre o PR por ele. A ferramenta ajuda contribuidores sem acesso ao GitHub, mas não contorna um banimento automaticamente nem dá permissão para executar patches não confiáveis automaticamente.

Relay Radio

Relay Radio é um novo app web somente leitura que transforma um feed Nostr ao vivo em som, com earcons e conversão de texto em fala do navegador, além de uma região dinâmica (live region) opcional no modo polite para usuários de leitores de tela. Os ouvintes escolhem uma estação global com curadoria ou uma montada a partir das pessoas que seguem, abrangendo notas, respostas, reposts, reações e zaps. Ele nunca publica nem paga em nome do ouvinte. A filtragem de conteúdo é feita na base do melhor esforço, então não há garantia de que tudo o que é lido em voz alta seja seguro.

Hibiki

Hibiki é um napplet de feed independente para o Torii, e seu código-fonte chama a versão 0.2.1 de seu primeiro feed funcional. Um nó busca posts e mídias públicos, enquanto a classificação baseada no gosto do usuário roda no navegador. O feed é executado em um iframe isolado (sandbox), sem acesso direto à rede, e trata a reputação de spam assinada apenas como sugestão. Não verificamos de forma independente a fronteira de privacidade.

O código-fonte mesclado até a versão 0.2.6 adiciona respostas inline e resumos extrativos de notícias, e as curtidas não reordenam mais os posts. Uma release com tag continua não confirmada. O suporte a pré-visualização no player do Watch adiciona quadros de pré-visualização. Zaps chegam junto com as páginas de perfil. O nó verifica o valor e o hash de descrição de cada invoice. Todo pagamento exige confirmação do dono; quem paga usa WebLN ou um QR code. O nó não guarda fundos nem chaves. Invoices de endereços da Primal não têm o hash de descrição, por isso uma alteração posterior passa a aceitá-las quando o valor coincide exatamente. Elas são marcadas como bound:false, e o dono recebe um aviso de que a carteira pode não confirmar. Isso enfraquece o vínculo entre a invoice e o pedido de zap e não as torna confirmações válidas de NIP-57. Erros 5xx e timeouts da carteira são tentados novamente uma vez e exibem o motivo informado pelo LNURL. O autor não relatou nenhum zap de ponta a ponta bem-sucedido com uma carteira real.

wax

wax é um novo signer em Common Lisp que deriva chaves por função a partir de uma seed BIP-39 e submete cada requisição a uma proteção de política, negando por padrão a menos que um callback de aprovação ou uma allowlist a permita. Sequências de envelopes por chamador protegem contra replay. Os nomes dos métodos lembram os do NIP-46, mas o núcleo não fornece transporte de rede. Não fizemos uma auditoria de segurança do signer.

WhatZaps

WhatZaps é uma nova extensão de navegador que paga contatos do WhatsApp via Lightning por meio do suporte a WebLN da extensão Nostr WoT. Ela associa um contato a um perfil Nostr, verifica o endereço de pagamento dele e sempre pede confirmação explícita antes de pagar. O comando /zap não é enviado como mensagem no chat, e o caminho por reação ou botão paga sem publicar nada. São pagamentos Lightning que usam o Nostr para consultar identidades, e não recibos de zap NIP-57 assinados. Não testamos a correspondência de mensagens no navegador.

Enquetes criptografadas do Agora

Agora é um protótipo para navegador de enquetes em grupo criptografadas. Ele combina o aval entre membros com tickets de votação cegos e transporta o tráfego por relays Nostr e WebRTC. O README apresenta o design como “uma pessoa real, um voto”, mas isso depende de confiar no emissor dos tickets, que pode fabricar tickets, e do aval como forma de confiança social. O design não oferece resistência a coerção. Os relays podem ver horários e endereços IP; os resultados dependem de quais events um cliente recebe. O projeto não tem relação com o antigo projeto de chat ghobs91/Agora.

Cinderous SDK

O Cinderous SDK v0.83.0 é um novo protótipo em código-fonte que atribui a cada dispositivo sua própria chave e sincroniza documentos com histórico ao estilo Git por Nostr e WebRTC, recorrendo a relays quando necessário. Quem chama escolhe e implanta os relays, e o SDK não vem com nenhum relay público padrão. A criptografia usa um esquema experimental, o CinderEK, com Double Ratchet, que não passou por auditoria externa. A troca de chaves híbrida não torna as assinaturas secp256k1 seguras contra computação quântica, e o README descreve o SDK como não pronto para produção.

evil-napplets

evil-napplets adicionou os níveis 02 a 08 da escada de ataques para testar hosts que executam napplets sob o modelo de origem opaca do rascunho NIP-5D. Os napplets maliciosos sondam as fronteiras de capacidades e da ponte e relatam o que o host permitiu. O modo de demonstração é o padrão, e os modos ativos precisam ser habilitados explicitamente. Testes ativos só devem ser executados contra hosts que o testador esteja autorizado a sondar. Como a suíte é um fixture de red team, um host que passa nela não teve sua segurança demonstrada. Trata-se de um projeto separado do evil-napps, que visa uma arquitetura de apps diferente.

evil-napps

evil-napps é uma nova suíte em código-fonte que sonda as fronteiras de autoridade em launchers NAPP. Ela cobre a ponte do launcher e o signer NIP-07 exposto aos apps. O armazenamento SharedDB também está no escopo. Os pacotes NAPP combinam metadados com um arquivo de índice, um formato diferente do artefato HTML único usado pelos napplets NIP-5D. Segundo o README, a suíte roda em modo de demonstração por padrão e só executa sondagens ativas quando isso é solicitado explicitamente. Seus testes e seu harness não certificam um launcher.

Feedstr

Feedstr é um novo leitor de RSS em Rust que sincroniza feeds, estado de leitura e favoritos pelo Nostr de forma criptografada. A sincronização pode ser desativada para feeds individuais. Ele permite importar e exportar OPML e lida com artigos longos do NIP-23. O repositório tem árvores de código-fonte para o núcleo, Android, web e Flatpak. O README diz que o software mal foi testado e não é recomendado para uso, e que instruções de instalação e uso virão em breve.

Toolkit de recibos de depósito NKIP

KYC-rip/nkip-0001 é um novo toolkit em TypeScript, mantido por XBToshi, para recibos de depósito NKIP-0001. O NKIP-0001 é um formato de recibo de aplicação, e não um NIP aceito do Nostr. O toolkit lida com recibos de depósito assinados com Ed25519, commitments com salt, events testemunha do Nostr e recuperação do salt por meio de criptografia NIP-44. Sua proteção depende de a aplicação reter o endereço de depósito até que a testemunha tenha sido observada. O SDK não condiciona a liberação de pedidos e não garante os repasses. Os detalhes estão no README.

nostr-parse

nostr-parse é um novo parser em Rust da VectorPrivacy para events Nostr assinados. Ele impõe estritamente o formato de event com sete campos, exige inteiros não negativos, limita os kinds à faixa de u16, verifica campos hexadecimais e valida strings com escape. Os erros são relatados com offsets. Quem chama pode gerar alocações próprias compactas ou spans emprestados que apontam para a entrada, e parse_unsigned aceita rumors NIP-59 não assinados. O parsing não recalcula o ID do event nem verifica a assinatura Schnorr, então quem chama ainda precisa fazer essas verificações por conta própria.

cl-deposits

cl-deposits é uma nova implementação em Common Lisp do Bitcoin Deposits. Nesse design, um operador mantém, sobre o Nostr, ledgers em cadeia de hashes assinados e coassinados por quórum, lastreados em reservas Taproot. O repositório inclui o código-fonte e uma devnet com testes de inspeção. Segundo o README e o ROADMAP, o autor reproduziu os fixtures de referência, rodou uma devnet em signet e testou a interoperabilidade com o deposits-rust nos dois sentidos. O autor também relata que o caminho de recebimento via Lightning funciona e lista InvoiceLock e Fulfill de pagamento como próximos passos. Os usuários dependem do operador, do quórum de coassinatura e das premissas sobre as reservas.

Streets

O Streets, um cliente web Nostr baseado em colunas que mostra timelines, notificações e busca lado a lado, mesclou uma alteração que salva o emoji de reação padrão no documento de deck NIP-78 da conta (kind 30078). Os usuários não precisam mais escolhê-lo de novo depois de fazer login novamente ou ao usar outro dispositivo. Antes, a escolha ficava armazenada apenas no localStorage do dispositivo. O documento de deck é criptografado com NIP-44, então a sincronização entre dispositivos exige login com uma extensão ou um signer que suporte criptografia. Outros modos de login mantêm a configuração no dispositivo. Se a conta não tiver uma reação salva, é usado o valor já existente no dispositivo, de modo que a configuração não volta para o coração. Um valor salvo inválido é descartado sem que o restante do deck seja descartado. A alteração está no código-fonte, e as notas de release da 1.22.0 ainda são um rascunho.

Labradorite

Labradorite é um app Android para controlar sessões de agentes de programação em um computador Linux pareado, e publicou as versões 0.1.0 e 0.2.0. O celular é apenas a interface de controle. Um daemon no computador executa o agente e troca mensagens MLS do Marmot por relays Nostr comuns, com um grupo por sessão. Ele só aceita npubs de uma allowlist que vem vazia por padrão (código-fonte). A versão 0.1.0 inicia ou retoma sessões aprovadas, transmite em streaming texto, chamadas de ferramentas e diffs, e lida com aprovações e perguntas. Também oferece controles de Git e navegação de arquivos somente leitura. Já a versão 0.2.0 enfileira mensagens de acompanhamento como turnos separados, permite cancelá-las pelo celular, mantém o trabalho enfileirado entre reinicializações do daemon e reproduz o histórico perdido após a reconexão. Essas são alegações do publicador, e não auditamos sua segurança de forma independente.

Nomisma

Nomisma é um livro-razão de despesas compartilhadas para Android, em beta de protótipo, que pareia dois participantes por mensagens privadas do Nostr. Ele apenas registra saldos e não movimenta nem liquida dinheiro. A versão 0.1.3 reconecta automaticamente dispositivos pareados, tenta reenviar alterações persistidas com intervalos crescentes e adiciona autenticação de relay NIP-42. Também reenvia operações ausentes. Os dois dispositivos comparam uma impressão digital SHA-256 de lançamentos, pagadores e divisões somente quando seus relógios vetoriais por autor coincidem. Ambos os dispositivos precisam da 0.1.3 e de configurações de relay correspondentes, porque o relay padrão mudou. Os checkpoints são embrulhados com gift wrap e têm expiração NIP-40 de 15 minutos, o que pede aos relays que os descartem, mas não garante o apagamento. As notas relatam correções no carregamento da biblioteca nativa, na ordem dos argumentos Schnorr e na derivação de chaves NIP-44, e não auditamos sua segurança de forma independente. A assinatura do usuário passa pelo Amber, mas também existem chaves efêmeras no dispositivo. As notas de distribuição são conflitantes quanto ao certificado de assinatura do APK, por isso não qualificamos aqui a compatibilidade de atualização.

Onyx

Onyx é um protótipo de diário privado disponível como código-fonte, e não uma release qualificada. Ele mantém arquivos Markdown datados no dispositivo como fonte da verdade e faz backup deles em relays como events kind 30078 criptografados. As d-tags com salt evitam expor diretamente as datas das entradas. A restauração exige a chave de criptografia local separada, então os usuários precisam fazer backup dela, porque a npub sozinha não consegue restaurar o diário. Um patch de 27 de outubro adiciona uma proteção que verifica a integridade dos campos da requisição antes de publicar: o kind do event, o conteúdo, a pubkey, as tags e o timestamp devolvidos pelo signer precisam corresponder à requisição. O patch também rejeita downloads do autor errado, preserva edições locais mais recentes e substitui os dados de forma atômica durante a restauração. Os autores e timestamps dos events continuam públicos. O texto em claro passado ao comando de criptografia pode aparecer brevemente para a inspeção de processos local, e apagar uma entrada não apaga as cópias nos relays.

Zzub

Zzub 0.0.41 é um cliente comunitário derivado (fork) do Buzz. Segundo as notas curtas do publicador, esta versão adiciona RSVPs de calendário com suporte a fusos horários, zaps em perfis, exibição de badges NIP-58 e um botão de huddle que entra em uma reunião ao vivo. Os controles de agentes ganham uma opção de reinício, edição de uma lista isenta de orçamento e novos tipos de cartão de tarefa. A inicialização agora usa canais em cache.

Trabalho em protocolo e especificações

NIP-CD define comandos invocados como texto simples

A especificação NIP-CD, inicialmente intitulada Commands e agora intitulada Slash Commands, foi mesclada no repositório de NIPs em 21 de outubro (revisão da proposta). Um executor anuncia um comando em um event kind 31992 que lista seu gatilho, título, descrição, argumentos posicionais tipados e escopos. Os usuários o invocam como texto simples no início do conteúdo do event, opcionalmente qualificado pela npub do executor, de modo que não são necessárias tags específicas de comando nem suporte do cliente. Um gatilho isolado pode corresponder a vários executores. Os clientes podem oferecer preenchimento automático, mas não podem exigi-lo.

Marmot adota vários dispositivos por conta

Marmot, um protocolo de mensagens em grupo criptografadas baseado em MLS para Nostr, incorporou suas regras de contas com múltiplos dispositivos (revisão da proposta) em 26 de outubro, numa forma revisada em relação ao rascunho anterior. Quem convida pode adicionar no máximo 20 KeyPackages de uma mesma conta em um Commit. Cada dispositivo mantém exatamente um slot de publicação escolhido aleatoriamente e fixo por toda a vida útil do dispositivo e nunca copia estado MLS nem KeyPackages privados. Os pacotes devem durar 30 dias, com renovação de 7 dias. Quem convida envia a cada dispositivo elegível seu próprio Welcome, e remover uma conta remove todas as suas folhas.

Marmot permite que membros gerenciem as folhas da própria conta

O Marmot adotou um componente de associação da mesma conta, marmot.group.account-devices.v1 (ID 0x800d), que não carrega dados. Quando a negociação do grupo exige o componente, um membro pode fazer commit de Adds e Removes para a própria conta sem autoridade de administrador. Sob esse componente, o membro não pode remover a folha do próprio autor do commit nem remover outras contas, e o status de administrador da conta não muda. Grupos existentes precisam ativar o componente e cumprir seus invariantes de suporte.

Gatilhos de push do Marmot ganham padding novo

O Marmot agora exige padding novo em todo gatilho de push, incorporado em 26 de outubro. Cada gatilho kind 446 carrega pelo menos um bloco novo de padding CSPRNG de 1.084 bytes, o que deixa no máximo 31 tokens criptografados reais dentro do orçamento de 32 blocos. Sem padding novo, bytes de token idênticos permitiriam que a deduplicação por hash de conteúdo suprimisse notificações legítimas posteriores. Os servidores calculam o hash de todos os blocos e não devem rejeitar um gatilho estruturalmente válido por não conseguirem detectar o padding. O padding oculta a contagem de tokens de relays e observadores, mas o servidor de notificações que faz a descriptografia ainda consegue vê-la.

Marmot adiciona reparo de tokens de push para novos membros

O Marmot incorporou o reparo de tokens de push para novos membros em 26 de outubro, e um ajuste posterior esclareceu sua redação final. O dono do Commit que adiciona um novo integrante deve enviar snapshots de tokens ativos kind 448 e tombstones de remoção kind 449. Um conjunto opcional de fingerprints em um announce kind 447 permite que os pares enviem apenas os registros que faltam. As três folhas mais bem ranqueadas respondem com temporizadores escalonados, sob um limite de taxa de 24 horas por folha anunciante. Registros assinados retransmitidos e tombstones de remoção retidos reparam o estado de tokens ausente mesmo enquanto os donos estão offline.

Proposta de chaves Nostr guardadas em passkeys

Uma proposta de chaves Nostr guardadas em passkeys se baseia no Nosskey, um esquema existente para usar passkeys com chaves Nostr. Handles marcados separam uma identidade derivada por PRF/HKDF de uma chave armazenada, e registros de relay kind 31778 criptografados vinculam a relying party, o autor e a credencial. Metadados ausentes ou desconhecidos não devem criar silenciosamente uma nova identidade. A autorização de origem da relying party continua valendo, e dados legados do Nosskey precisam de um leitor de migração explícito. Uma identidade derivada se perde junto com sua passkey, a menos que tenha um backup separado.

Proposta de delegação DNS para identificadores NIP-05

Uma proposta de delegação DNS ainda não incorporada para identificadores NIP-05 baseados em DNS adiciona um fallback que se aplica somente quando a consulta HTTPS original retorna 404 ou 410. Nesse caso, os clientes leem um registro TXT _nip05 que aponta para um provedor HTTPS. Timeouts, falhas de TLS ou CORS, redirecionamentos e divergências de chave nunca acionam o fallback, e o DNS não armazena chaves. O DNSSEC é recomendado, mas opcional; assim, com DNS não assinado, o TLS do provedor não consegue autenticar de forma independente a autorização do domínio original. Clientes mais antigos não conseguem resolver identificadores que dependem apenas de delegação.

Catálogo de aplicativos de software proposto como NIP-82

Uma proposta de catálogo de aplicativos de software usa NIP-82 como número proposto nesse pull request aberto e não incorporado; o número não foi atribuído nem adotado. Ela reúne kinds para apps (32267), releases (30063), assets (3063), curadoria (30267), provas de posse de certificado (30509) e uma lista de relays do catálogo (10067). Os assets identificam sua plataforma e seu runtime, além de um hash do arquivo. Assets Android acrescentam um hash do certificado de assinatura. Uma assinatura de prova mostra que o publicador controla o certificado, e os leitores ainda precisam verificar sua expiração e revogação.

URIs BIP 321 propostas como destinos de pagamento NIP-A3

Uma proposta que adiciona um tipo de pagamento bip321, ainda não incorporada, aos destinos de pagamento NIP-A3 permite que um event kind 10133 carregue uma URI bitcoin: completa como instruções de pagamento estáticas e reutilizáveis. Como o destino é reutilizado, a proposta proíbe um valor e um parâmetro de fatura BOLT11 lightning de uso único. Quem paga escolhe o valor, e a carteira escolhe um método de pagamento que suporte, mantendo o fallback para Lightning address.

Proposta de zaps pagos por meio de destinos BIP 321

Uma proposta de zaps pagos por meio de destinos BIP 321 faz com que o remetente pague o destino bip321 NIP-A3 reutilizável de um destinatário via Ark (um protocolo Bitcoin offchain), Lightning ou onchain e depois publique um zap kind 9740. O detentor da chave de recibo confirma a liquidação com kind 9741. Os dois números de kind continuam provisórios. A referência de pagamento é criptografada com criptografia versionada NIP-44 para uma chave de recibo que o destinatário opta por usar, e somente essa chave pode confirmar o pagamento. Terceiros não conseguem verificar os detalhes do pagamento, então a confirmação depende de confiar na assinatura do destinatário. A proposta não substitui os zaps Lightning NIP-57.

Pagamentos Ark propostos para o Nostr Wallet Connect

Uma proposta de extensão Ark ainda não incorporada para o Nostr Wallet Connect, o protocolo NIP-47 que permite que apps controlem uma carteira remota, adiciona uma instrução Ark ao suporte existente para pagar e receber via BIP 321 e um registro de pagamento Ark para lookup_payment, sem métodos novos. Uma carteira só usa a instrução quando suporta a versão de endereço e a rede e compartilha o mesmo servidor Ark. Caso contrário, tenta outra instrução da URI. Os valores devem ser satoshis inteiros, sem arredondamento de milissatoshis, e os registros distinguem um pagamento cossinado pelo servidor de fundos que o destinatário coletou e pode gastar.

Header de pagamento Ark proposto para servidores Blossom

Uma proposta de header de pagamento Ark no Blossom, o protocolo para armazenar blobs de mídia em servidores HTTP, adiciona X-Ark às respostas HTTP 402 de pagamento exigido do BUD-07. O header carrega uma URI BIP 321 com um endereço Ark novo por requisição e o valor. Opcionalmente, a URI também carrega o mesmo pagamento como fatura Lightning. Como prova, os clientes repetem a requisição com o endereço Ark pago após a liquidação. Clientes que usaram o fallback repetem com a preimage Lightning. Uma requisição HEAD não é repetida com prova, e os clientes seguem para o GET ou o PUT.

Proposta de cashtag para menções a ativos em notas

Uma proposta de cashtag define a tokenização opcional de $ seguido de duas a seis letras ASCII, excluindo código, URLs e referências Nostr. Uma única tag cashtag define o modo de exibição e pode anexar um ID de ativo escolhido pelo autor, já que um ticker sozinho não identifica um ativo de forma única. Os leitores verificam se o símbolo corresponde à chain e ao endereço e sinalizam divergências sem trocar seus rótulos. Tags opcionais t no formato $ticker permitem a busca padrão em relays.

Especificação de gamepad dos Napplets retirada

O repositório NAPs, onde as especificações Napplet são publicadas, incorporou a remoção da especificação de gamepad em 27 de outubro. A mudança apaga o NAP-GAMEPAD.md e desfaz a adoção anterior. Nenhum NAP de gamepad está adotado atualmente.

Tags de altura do Cyberspace evitam colisões com tags de grupo

O Cyberspace, um protocolo espacial construído sobre o Nostr, incorporou várias de suas próprias especificações, chamadas DECKs. Elas são specs do projeto, não NIPs oficiais. A spec agora renomeia a tag de altura em bolsas e chat de h para H. A tag em minúsculas colidia com as tags de grupo do NIP-29 e fazia com que events fossem rejeitados ou arquivados no lugar errado. Os leitores recorrem a uma h legada somente quando H está ausente. Isso muda apenas a spec do projeto. Não altera o NIP-29 nem prova que clientes implantados interoperam.

Áudio oculto no Cyberspace

O DECK-0007 define áudio oculto como um arquivo Blossom criptografado, referenciado por um rumor não assinado dentro de uma bolsa ou baú assinado. Isso significa que quem o escondeu não recebe atribuição por meio de uma postagem pública reproduzível assinada separadamente. Cada posicionamento usa uma chave e um texto cifrado novos, mas qualquer pessoa ainda pode compartilhar a chave. A spec não afirma que a criptografia garante a privacidade de quem encontra o áudio nem que suas regras de URL bloqueiam todo SSRF, e o suporte nos leitores ainda está em andamento.

Modelos públicos e animação no Cyberspace

Os itens agora podem referenciar modelos SNO públicos com animações bob e spin e voltam à renderização antiga quando um modelo é inválido ou está indisponível. Modelos ativos podem mudar ou desaparecer, e não se afirma que haja ampla adoção.

Especificações de itens, chat e comentários do Cyberspace

Os DECKs opcionais 0004 a 0006 documentam código existente para itens, baús, listagens, chat local criptografado e comentários selados, com vetores de teste sintéticos. Vários problemas continuam em aberto. As assinaturas de bolsas e baús diferem, e os comentários selados expõem o ID e o kind do pai por meio de tags públicas. Detentores podem sobrescrever listagens. O chat tem lacunas de replay e de vinculação de contexto, e as referências a baús não estão implementadas. A documentação não corrige nenhum problema de segurança e não constitui uma implantação.

Proposta de events com múltiplos autores

Um artigo longo assinado, Multi-Author Nostr Events as a Soft Fork, propõe events cujo hash de ID cobre várias pubkeys de autores, com cada autor assinando o mesmo ID. Clientes mais antigos veriam um wrapper compatível com secp256k1 que carrega os dados no novo formato e tags Q como dicas de busca. Os pares negociariam o novo formato por conexão. O artigo generaliza a proposta pós-quântica anterior do autor, que adicionaria uma chave futura como mais um coautor. Trata-se de uma proposta sem número, não de um NIP aceito. A substituição de naddr em coautoria e o transporte binário continuam sendo questões em aberto.

Subscriptions de sync NIP-AR do Buzz enviam um snapshot completo antes dos heads ao vivo

Um pull request aberto do Buzz propõe subscriptions de sincronização via WebSocket do NIP-AR (#8522). O relay enviaria um conjunto consistente de artefatos lido sob REPEATABLE READ e emitiria EOSE somente quando esse conjunto estivesse completo, para depois transmitir os heads atuais ao vivo; o registro ao vivo no Redis acontece antes da leitura inicial. Desconexão ou atraso do Redis encerra a subscription com CLOSED e exige uma ressincronização, assim como mudanças de acesso, remoções de conteúdo (redactions) ou uma fila cheia. As subscriptions têm limite de 4.096 artefatos, e a mudança não estava incorporada na data de corte de nossas fontes, sem disponibilidade em produção.

Leituras incrementais de artefatos NIP-AR via HTTP no Buzz

Um pull request separado e aberto do Buzz adiciona leituras HTTP incrementais para artefatos NIP-AR (#8523). Os clientes paginam pelos timestamps de modificação no banco de dados e por IDs estáveis, com uma sobreposição de 120 segundos, e recebem a revisão atual ou uma remoção. Eles podem recuperar IDs conhecidos. Os resultados seguem um modelo de consistência eventual. A proposta não promete um snapshot completo, e a ausência de um artefato não significa exclusão nem perda de acesso. Sua revisão mais recente exige ser membro ou um escopo #h explícito para canais abertos não listados, e uma mudança de listagem reinicia o progresso incremental. O feature gate, BUZZ_ARTIFACT_INCREMENTAL_ENABLED, está desligado e exige que todos os writers e migrações (agora de 0074 a 0076) estejam implantados. Esse atraso de 120 segundos é uma premissa operacional. Na data de corte de nossas fontes, a mudança continuava aberta.

Rascunho de texto do NIP-AM para leitores delegados de métricas

Um pull request de documentação do Buzz, ainda em rascunho, especifica leitores delegados para métricas do NIP-AM sem alterar a autorização em tempo de execução (#8582). O event kind 44200 criptografado para o dono permanece inalterado, e o agente emite uma cópia NIP-44 separada para cada concessão ativa, vinculada ao ID exato do event de concessão criado pelo dono. O kind de concessão proposto, 30180, e os limites de leitores continuam sendo questões em aberto, assim como histórico, revogação e vinculação pública. Uma revogação assinada não consegue apagar cópias que um destinatário já tem, e o rascunho não estava incorporado na data de corte de nossas fontes.

O DECK-0003 permite que um pai carregue os objetos que posiciona

Um pull request aberto do Cyberspace propõe a §1.10 do DECK-0003, uma tabela raiz de payloads de objetos SNO inline (#81). Uma entrada presente na cópia do pai prevalece sem busca na rede, mesmo quando é inválida. Cada entrada tem escopo restrito à pubkey do autor, com limites de tamanho e profundidade, além de limites de ciclo. Leitores mais antigos buscam os objetos ausentes e exibem um placeholder. A proposta descreve implementações que aguardam essa mudança, que não estava incorporada na data de corte de nossas fontes.

O DECK-0004 define portas vinculadas à altura com chaves de sala derivadas

Um pull request aberto no Cyberspace adiciona as seções §3.6 e §3.7 ao DECK-0004, sobre aparências (looks) e portas (#82). As portas são vinculadas à altura, e a chave da sala é SHA-256(separador de domínio ‖ chave de localização ‖ segredo da porta), com a bolsa da sala criptografada sob essa chave. Uma sala pode ter várias portas ou portas aninhadas, e definir uma nova fechadura rotaciona a chave. O texto não terá vetores de teste até que exista uma primeira implementação, e o pull request ainda não havia sido mesclado no nosso corte de fontes.

Extensão de anúncio de peering no NIP-11 do nostream

Um pull request aberto no nostream estenderia o documento NIP-11 do relay com uma seção de peering (#999). Essa seção anuncia kinds de feed com limites de tempo e termos de liquidação, além de um endpoint de contato e de prova de trabalho para peering. Somente enabled: false desativa a seção, e termos vazios significam peering sem liquidação. Uma oferta anunciada não equivale a um par aceito. A mudança não implementa nenhum acordo entre pares nem federação paga. Ela ainda não havia sido mesclada no nosso corte de fontes.

NIP-CD adiciona listas opcionais de comandos instalados

Uma continuação do NIP-CD foi mesclada no branch padrão dos NIPs em 27 de outubro (mesclagem), e a especificação agora se chama Slash Commands. Ela define uma lista opcional de kind 10992, seguindo o NIP-51, na qual o usuário mantém tags de endereço que apontam para definições de comando de kind 31992. Cada uma é identificada pela pubkey do executor e pelo valor d, com uma dica de relay opcional. Os usuários podem manter a lista, e os clientes devem usá-la para o autocompletar e para os chips renderizados. A lista é uma preferência de exibição e descoberta. Ela não autoriza executores, e a invocação em texto simples continua funcionando sem ela, sem tags específicas de comando e sem exigir suporte do cliente. O NIP-CD continua sendo um rascunho opcional, e a mesclagem não mostra quais clientes adotaram a lista.

Marmot restringe sua regra de preparação justa para dispositivos de conta

Em 28 de outubro, o Marmot mesclou uma correção em sua regra de agendamento para grupos que exigem dispositivos de conta. Depois que uma passagem de convergência limitada atinge Stable, uma intenção enfileirada autorizada por um admin, ou uma intenção permitida vinda da mesma conta, recebe uma tentativa de preparação antes que o trabalho de entrada enfileirado, por si só, possa forçar outra passagem. SelfUpdate e Leave ficam fora dessa garantia extra de justiça, embora qualquer membro ainda possa fazer o commit deles. A mudança corrige a redação anterior, que abrangia todas as intenções autorizadas. Grupos que não exigem dispositivos de conta mantêm o agendamento anterior. Não há mudança no formato de transmissão, e uma tentativa de preparação não garante um Commit válido, aceito ou canônico.

Marmot propõe um roster oculto de dispositivos para grupos de conta

Uma proposta aberta do Marmot, ainda não mesclada, adicionaria um componente device-roster-v1 com ID 0x800e para um grupo oculto cujas folhas pertencem todas a uma única conta. Ou o grupo carrega o roster desde a criação, ou nunca o carrega. O roster registra dispositivos, slots rejeitados, KeyPackages rejeitados e mapas de folhas. É também o primeiro componente a usar atualizações por diff explícitas e independentes de ordem, aplicadas ao pai candidato. Slots removidos podem manter mapas de folhas para grupos dos quais seus irmãos não conseguem removê-los. Um dispositivo só confia em um grupo de dispositivos se tiver criado esse grupo ou se tiver entrado nele por meio de um Welcome autenticado por um vínculo confirmado, de modo que o marcador 0x800e, por si só, não concede confiança alguma. O Add fundador nomeia o KeyPackage exato do vínculo confirmado. Um dispositivo vinculado que tenha sido roubado pode editar o roster até ser removido. O limite de dispositivos se aplica aos dispositivos. Os registros de mapas de folhas e de rejeições têm limites de tamanho por entrada, mas nenhum limite de quantidade de registros. Os dados do roster nunca são copiados para outras contas, e o grupo permanece oculto de chats, contagens, notificações e destinos. Segundo o texto da proposta, o MDK mantém os bytes do roster atrás de um interruptor de teste, sem nenhuma nova UI comum.

Marmot propõe feedback mais claro quando a ativação de dispositivos de conta falha

Outra proposta aberta do Marmot, também não mesclada, permitiria que os clientes explicassem falhas de ativação de dispositivos de conta. Um cliente pode informar que um grupo não consegue ativar dispositivos de conta. Esse feedback em nível de grupo não pode nomear os membros ou dispositivos que bloqueiam a ativação. Um membro que não seja admin ativo fica sabendo apenas que não tem status de admin. Se uma seleção de branch se perder ou se uma verificação de ativação regenerada falhar, o usuário precisa fazer uma nova solicitação. O cliente nunca tenta a ativação novamente de forma automática. Continua inalterada a regra existente segundo a qual a ativação exige uma nova solicitação do usuário, feita a partir de um cliente autorizado. Trata-se de texto normativo em rascunho, que não demonstra comportamento implementado nem implantado.

Marmot propõe verificação por emoji para parear novos dispositivos

Uma proposta aberta do Marmot, ainda não mesclada, descreve o pareamento de um novo dispositivo por meio de uma troca inspirada no m.sas.v1 do Matrix, usando X25519, HKDF e HMAC. O usuário compara sete emoji rotulados nas duas telas, sem ler nem digitar nenhum código. A posse da chave da conta nunca autentica um dispositivo. Cinco rumors não assinados (Request, Answer, Reveal, Confirm e Cancel) são encapsulados (wrapped) para a pubkey da conta e vinculam a conta, a sessão, o novo KeyPackageRef, o slot do dispositivo existente e chaves recém-geradas. O dispositivo existente confirma primeiro e adiciona exatamente o KeyPackageRef confirmado. Já o novo dispositivo só confirma depois de verificar, e aceita um Welcome apenas para o ID de grupo autenticado pela troca confirmada. São propostos os kinds 452 a 456, com 457 a 489 reservados. Quem detém a chave da conta ainda pode forjar um Cancel para negar o serviço, mesmo após a confirmação. O limite de Answers por hora não persiste entre reinicializações. Os relays conseguem ver a rajada de wraps e o endereço da conta; alguns casos de merge e de Welcome continuam adiados. As implementações mantêm esses formatos desativados por padrão, e dois vetores de resposta conhecida fornecidos pelos autores não constituem uma auditoria independente de segurança ou de interoperabilidade.

Proposta de napplet do NIP-5D torna mais rígidos os campos de mídia e de código-fonte

A proposta aberta de napplet do NIP-5D já foi descrita anteriormente. Suas mudanças de 28 de outubro agora foram mescladas no branch da proposta, e não no branch padrão dos NIPs, revisando campos opcionais de mídia e de código-fonte introduzidos em 17 de outubro. As tags de screenshot e de preview agora reutilizam campos chave-valor do NIP-92, com um valor x obrigatório em SHA-256 com letras minúsculas e os campos opcionais m, dim, size, alt e duration. Antes de renderizar, os leitores devem verificar o hash e decodificar o formato real. Se houver um campo m válido, o formato decodificado também precisa corresponder a esse tipo MIME. Entradas com x ausente, repetido ou inválido são ignoradas; campos opcionais inválidos são descartados sem eliminar outras mídias utilizáveis, e múltiplos previews são ignorados. Um source-commit deve resolver para um ID Git completo e exato, e arquivos de código-fonte via HTTPS exigem correspondência SHA-256 exata em nível de bytes. Campos de código-fonte duplicados ou malformados são ignorados, e dados de código-fonte inutilizáveis não devem bloquear a reprodução do HTML. Um commit ou arquivo correspondente não prova que o build seja reproduzível, e não se alega nenhuma conformidade de cliente.

Seis anos de outubros no Nostr

Ao longo de seis outubros, as mudanças datadas do Nostr foram se deslocando para fora, do enquadramento de mensagens para os aplicativos construídos sobre ele. Em 2021, a especificação básica estabeleceu que as mensagens do cliente são enquadradas como arrays JSON de nível superior. Os outubros seguintes trouxeram busca no cliente e invoices Lightning, evidências de timestamp e solicitações de trabalho, variantes de mídia e carteiras de ecash e, depois, colaboração em código e metadados de mensagens privadas. Outras mudanças nos mesmos meses tornaram identidades e conexões mais fáceis de levar de um programa a outro, do status visível dos relays a chaves de assinatura separadas e ao pareamento de carteiras. Neste outubro, o mesmo documento definiu o que corresponde a uma lista de filtros vazia, e assim relays que leem o mesmo JSON agora compartilham uma regra sobre quais events ela seleciona.

Outubro de 2021: tornando o transporte inequívoco

Em 4 de outubro, o NIP-01, a especificação básica do protocolo, foi revisado para que as mensagens do cliente fossem arrays JSON de nível superior. Os prefixos informais EVENT, REQ e CLOSE passaram a ser o primeiro elemento de cada array, e a exigência do caminho fixo /ws foi abandonada, de modo que qualquer endpoint WebSocket passou a servir. Isso esclareceu uma especificação que já tinha código por trás. Clientes escritos de forma independente precisam de um enquadramento exato antes que qualquer coisa mais sofisticada consiga interoperar.

Em 23 de outubro, a direção do relay para o cliente ganhou mensagens EVENT e NOTICE explícitas. Um EVENT enviado pelo relay carrega o identificador de uma subscription REQ existente, para que um cliente que mantém várias subscriptions em uma única conexão possa associar os resultados às solicitações; NOTICE, por sua vez, carrega texto legível por humanos. Um vocabulário tão pequeno é viável de implementar mais de uma vez, o que convém a relays operados separadamente.

O texto de 23 de outubro do NIP-01 também mostra o que uma assinatura abrange. Nele, o ID de um event é um digest de um array JSON UTF-8 compacto que contém um zero inicial, a chave pública do autor, o timestamp, o kind, as tags e o conteúdo, e o autor assina esse digest com uma assinatura Schnorr na curva secp256k1. Já o envelope WebSocket e o identificador da subscription ficam fora desses dados assinados. Decorre desse texto que o mesmo event assinado pode chegar por subscriptions diferentes, ou por conexões diferentes, sem precisar ser assinado de novo. Um REQ primeiro retorna os events armazenados que correspondem e depois permanece ativo até que o cliente envie CLOSE, feche o socket ou reutilize o ID da subscription para um novo REQ. Todas as condições dentro de um filtro precisam ser satisfeitas, ao passo que vários filtros em um mesmo REQ selecionam events que satisfaçam qualquer um deles. Os nomes dos filtros naquela versão diferem dos atuais. O comportamento de NOTICE ficou sem especificação, e nada garantia por quanto tempo os relays guardam os events nem que uma consulta retorne todos eles. Cinco anos depois, a mesma especificação voltaria ao significado dos filtros dentro do REQ.

Outubro de 2022: um feed se torna utilizável no celular

Em 8 de outubro, o Damus, um cliente Nostr para iOS, adicionou busca por hashtags, perfis e events. A mudança alterou a view de resultados de busca e o modelo de threads, permitindo que o leitor saltasse para uma identidade assinada ou para um event específico, além de rolar o texto que chegava. Essa busca funcionava dentro da própria navegação do cliente e não era uma busca de texto completo no lado do relay.

Oito dias depois, o Damus substituiu as linhas simples de sua configuração de relays por uma view que mostra o estado de cada conexão. Um ponto colorido reflete a leitura do pool de relays do cliente. Verde significa conectado e amarelo, conectando ou reconectando; vermelho vale para qualquer outro caso, e cinza aparece antes da primeira leitura. A view é atualizada quando aparece e, depois disso, a cada dois segundos. O gesto de deslizar para excluir, que já existia, foi transferido para a nova view. Com os pontos visíveis, um feed parado não precisava mais ser interpretado como silêncio de um autor, porque o leitor podia ver qual de várias conexões independentes estava ativa e qual estava tentando novamente. Um ponto verde indica um socket aberto. Ele não indica que um relay aceitou ou guardou um event. Tampouco indica que uma consulta retornou tudo o que o relay contém. O commit registra a implementação no código-fonte mesclado. Essa mudança no código-fonte não estabelece nenhuma data de lançamento na App Store.

Em 19 de outubro, o Damus adicionou um parser de invoices Lightning BOLT11 e widgets de invoice em posts, chats e mensagens diretas. O widget mostra a descrição da invoice e o valor em satoshis, e seu botão Pay repassa a URI lightning:, por meio do iOS, a um handler instalado. O cliente social apresenta o post assinado, e quem paga é uma carteira separada. Esses widgets são anteriores à convenção de recibos de zap, que veio depois; portanto, são exibições de invoices, e não zaps padronizados.

Outubro de 2023: events carregam evidências e pedidos de trabalho

Em 11 de outubro, as atestações OpenTimestamps do NIP-03, que ancoram no Bitcoin evidências sobre events, passaram de um campo ots no event para um event separado de kind 1040. Esse event nomeia o original com uma tag e e carrega no conteúdo o arquivo OpenTimestamps completo em base64, com pelo menos uma atestação Bitcoin. O próprio id do event referenciado é o digest que a prova atesta, de modo que um verificador fica sabendo que o event já existia no momento atestado. Esse momento vem do Bitcoin, e não do created_at do autor. A prova data o event e não afirma nada sobre o seu conteúdo.

Em 12 de outubro, independentemente da mudança de timestamp, a derivação de chaves do NIP-06 ganhou dois vetores de teste. Um mnemônico é uma sequência de palavras que codifica uma seed de recuperação. Os vetores cobrem um mnemônico de 12 palavras e outro de 24 palavras, cada um com as chaves privada e pública esperadas em hexadecimal e nas codificações nsec e npub. O NIP-06 já usava o BIP-39 para transformar o mnemônico em uma seed binária e o caminho BIP-32 m/44'/1237'/<account>'/0/0 para derivar uma chave, tendo a conta zero como a escolha básica de chave única. A adição de outubro forneceu respostas conhecidas, e não recuperação de mnemônico nem um novo algoritmo de derivação. Agora um cliente pode verificar se sua derivação e suas codificações reproduzem a identidade documentada. Corresponder aos vetores torna as implementações comparáveis. Isso não certifica nenhuma implementação específica, nem prova que todas as importações em carteiras e clientes concordam entre si. Proteger uma seed contra roubo é uma questão à parte, que os vetores não abordam.

Em 29 de outubro, a NIP-90, o padrão de máquinas de venda de dados (data vending machines), foi incorporada ao repositório de NIPs com kinds de job fixos. Ela reservou os kinds 5000 a 5999 para requisições de job e definiu o kind de cada resultado como o kind da requisição mais 1000. Para feedback, usava-se o kind 7000. Uma requisição pode apontar para texto, URLs ou jobs anteriores. Também pode indicar a saída esperada e oferecer um lance opcional. A tarefa, portanto, vive em events assinados que qualquer provedor pode responder, fora da API de qualquer fornecedor individual. Um rascunho anterior havia usado os kinds 68001 e 68002.

Outubro de 2024: alternativas de mídia e ecash portátil

Em 15 de outubro, os events de vídeo da NIP-71 adotaram tags imeta para variantes de vídeo. Nos kinds endereçáveis então vigentes, 34235 e 34236, a URL, as dimensões, o tipo MIME, a imagem de prévia e os fallbacks de cada variante ficavam juntos em uma única tag. Um cliente que escolhe uma resolução precisa saber qual miniatura e qual fallback pertencem a ela, e metadados achatados não conseguiam informar isso. Esses números de kind são históricos: a NIP-71 atual usa os kinds 21 e 22.

Dez dias depois, as carteiras Cashu da NIP-60 e os nutzaps da NIP-61, ambos introduzidos em rascunhos anteriores, foram incorporados juntos como especificações. Eles se apoiam no Cashu, um protocolo de ecash cujos tokens são emitidos por mints. A NIP-60 mantém provas de carteira criptografadas em relays, de modo que aplicativos compatíveis possam acessar o mesmo estado da carteira. Pela NIP-61, o event kind 10019 de um destinatário lista mints confiáveis, relays e uma chave de bloqueio, e o event kind 9321 de um remetente carrega provas bloqueadas a essa chave para que o destinatário as resgate. Os usuários continuam dependendo dos mints que emitem os tokens, e cabe aos aplicativos se proteger contra o resgate duplo das mesmas provas.

Em 29 de outubro, a assinatura remota da NIP-46, na qual um serviço separado guarda a chave que assina em nome do usuário, foi revisada para que uma string de conexão bunker:// carregue a chave pública do assinante remoto. A identidade do usuário é obtida separadamente: o texto revisado exige que os clientes distingam as duas chaves e chamem get_public_key após a conexão. O cliente gera seu próprio par de chaves para a conversa e endereça suas requisições criptografadas à chave do assinante, enquanto sign_event retorna um event assinado com a chave do usuário. Essas duas chaves podem coincidir, mas não precisam. A chave na string de conexão identifica apenas o serviço assinante. Já a conta do usuário é a chave pública que get_public_key retorna. Quatro dias antes, a NIP-60 havia tratado do estado compartilhado de carteira; esta revisão trata de uma questão distinta, a identidade do assinante. Os exemplos naquele commit ainda usam o transporte criptografado que a NIP-46 especificava na época, e a mudança nem torna um assinante remoto livre de confiança nem prova quem detém a chave do usuário.

Outubro de 2025: atualizações de colaboração e metadados de mensagens privadas

Em 8 de outubro, o Nostr Wallet Connect da NIP-47 ganhou deep links para parear um app com uma carteira. Uma carteira pode registrar nostrnwc://connect ou um nostrnwc+{app_name}://connect específico do app, e o app solicitante abre esse link com seu ícone codificado em URI, seu nome e um esquema de callback. Depois que a carteira cria a conexão, ela abre o callback com um parâmetro value contendo o código de pareamento, uma URI nostr+walletconnect://. Três anos depois de o Damus repassar faturas a uma carteira pelo iOS, parear em um único celular deixou de exigir a leitura de um QR code exibido na mesma tela ou a cópia de uma string longa entre apps. O acréscimo cobre apenas essa passagem. Não altera nenhum método de pagamento e, por si só, não paga nada. Ambos os apps precisam implementar os handlers, e o texto da especificação não é evidência de que todas as carteiras o façam. Tampouco resolve limites de gasto, telas de consentimento ou qual app pode, com segurança, ser dono de um esquema de callback.

Em 16 de outubro, a colaboração git da NIP-34 ganhou events kind 1618 de pull request e kind 1619 de atualização, ao lado de seus events de patch já existentes. Um pull request indica um commit de ponta e locais de clonagem, e uma atualização move essa ponta. Recomendam-se patches abaixo de 60 kB, com pull requests para submissões maiores. Com isso, o caminho recomendado para submissões maiores passou de corpos de patch carregados dentro de events para referências assinadas a commits, enquanto mudanças menores ainda podem circular como patches. O Nostr carrega a coordenação e as referências assinadas, e os servidores Git continuam fornecendo os objetos de commit para os quais essas referências apontam.

Em 27 de outubro, o gift wrap da NIP-59 ganhou orientação para randomizar de forma independente os timestamps do seal e do gift wrap quando tags de expiração são adicionadas. O gift wrap envolve uma mensagem nessas duas camadas, e dar a cada camada seu próprio timestamp aleatório reduz o quanto o tempo das camadas pode ser correlacionado. Aqui a atenção passou da criptografia do conteúdo para a limitação do que a correlação de metadados pode revelar. A criptografia esconde a própria mensagem, mas o tempo e outros metadados em torno do envelope continuam observáveis, e são as escolhas de implementação que determinam com que facilidade eles podem ser vinculados. A orientação não acrescenta nova criptografia e não torna os participantes anônimos.

Outubro de 2026: significados compartilhados de consultas e serviços acionados por texto

Em 5 de outubro, os anexos de mídia da NIP-92 estenderam as tags imeta aos perfis kind 0, permitindo que um perfil descreva seu picture e seu banner com URLs de fallback, um blurhash (uma codificação compacta de uma prévia desfocada), dimensões, texto alternativo e outros metadados de anexo. A NIP-92 já existia antes dessa mudança; a novidade é que os metadados agrupados que a NIP-71 aplicou às variantes de vídeo em 2024 agora chegam às imagens de perfil. A associação é exata. Uma tag só se aplica quando sua URL é igual à URL do picture ou do banner, os clientes DEVERIAM (SHOULD) ignorar tags que não correspondam a nenhuma das duas e DEVERIAM (SHOULD) tentar os fallbacks quando a URL principal falhar. Como um novo event kind 0 substitui o perfil anterior, um publicador DEVERIA (SHOULD) manter os metadados de uma imagem inalterada e descartar as tags de imagens que não são mais usadas, para que texto alternativo ou dimensões desatualizados não passem a descrever silenciosamente outra imagem. Essa regra de atualização importa tanto quanto os novos campos. Uma tag imeta não garante que uma imagem continue disponível nem que carregue mais rápido. Ela também não oferece nenhuma proteção de privacidade, e os clientes não precisam renderizar todos os campos.

Em 17 de outubro, a NIP-01 foi esclarecida para que uma lista vazia em um filtro não corresponda a nenhum event, o que é diferente de omitir o atributo. Uma alteração posterior removeu a redação inconsistente “um ou mais” e recomendou que os clientes evitem enviar listas que não podem corresponder a nada. Em outubro de 2021, este documento estabeleceu um acordo sobre o enquadramento JSON da mensagem REQ: a mensagem REQ é um array, e cada filtro é um objeto JSON dentro dele. Neste outubro, ele definiu a semântica dos filtros, fixando o que significa uma lista vazia dentro de um filtro desse tipo, já que relays que interpretam o mesmo enquadramento de forma idêntica ainda poderiam retornar resultados diferentes.

Em 21 de outubro, a NIP-CD, então intitulada Commands, passou de proposta a especificação em rascunho incorporada; ela descreve comandos de barra (slash commands). Events kind 31992 definem comandos, e uma invocação é texto simples que começa no primeiro caractere do conteúdo de um event, de modo que os clientes não precisam de suporte especial para enviá-la. Uma proposta de acompanhamento, com um commit anterior em um branch separado, foi incorporada em 27 de outubro. Ela renomeou a especificação para Slash Commands e acrescentou listas opcionais de comandos instalados, de kind 10992, que os clientes deveriam usar para autocompletar e renderização. As listas registram uma preferência do usuário e não autorizam executores nem condicionam a invocação em texto simples. Enquanto os jobs da NIP-90 usam events estruturados de requisição e resultado, um comando continua legível como texto comum.