Nostr Compass #37 | Nostr Compass

Bem-vindos de volta ao Nostr Compass, o seu guia semanal do Nostr.

Esta semana: o Shopstr mantém segredos de assinador remoto e de carteira fora do armazenamento do navegador, o Routstr SDK verifica a descoberta de provedores vinda de relays, o Postr é lançado como um compositor pequeno para Android, o Infans cifra o acompanhamento familiar e a sincronização entre responsáveis, o walls.rip transporta chat cifrado com PGP por relays públicos do Nostr, e o pakstr torna explícita a publicação no Zapstore. O nostr-tools vincula os rumors de gift wrap aos seus seals. Os lançamentos cobrem isolamento de assinaturas, status de perfil e marcadores de saída por relay. O trabalho de protocolo alcança a implantação de tópicos de comentários, rascunhos de teto de taxa e consulta de pagamentos no wallet connect, pedidos de display para napplets e uma inscrição experimental pela mesma conta. A edição encerra com Seis anos de agostos do Nostr.

Histórias principais

Postr é lançado como um compositor pequeno para Android

O Postr é um compositor deliberadamente pequeno para notas kind 1 no Android. A custódia da chave privada permanece no Amber, um assinador NIP-55 (assinador local) e NIP-46 para Android. A versão 1.0.0 traz uma caixa de saída durável que sobrevive à perda de conectividade e à morte do processo, rascunhos privados por conta e anexos Blossom com hashes verificados e autorização de upload delimitada.

Uma publicação só é bem-sucedida depois de o Postr reler o evento assinado idêntico e conferir sua assinatura. As novas tentativas mantêm o mesmo id de evento. A publicação usa os relays de escrita da lista NIP-65 (lista de relays) do autor mais relays de bootstrap cifrados, ou uma lista personalizada por conta. Um anúncio de repositório NIP-34 (git sobre Nostr) assinado e um perfil de projeto kind 0 correspondente são publicados em relay.ngit.dev. Feeds, analytics, publicidade e armazenamento de chaves ficam fora do aplicativo.

Infans cifra o acompanhamento familiar e a sincronização entre responsáveis sobre Nostr

Responsáveis podem manter registros de alimentação, sono e crescimento nos próprios celulares e compartilhá-los sem um fornecedor de dados familiares. O Infans é um rastreador de bebês para Android que trata um banco Room local como fonte da verdade e publica eventos cifrados kind 30078 de NIP-78 (dados específicos de aplicação) para backup e sincronização com o parceiro. Seu repositório rotula a cifra local como NIP-44 (cifragem de payload), mas a implementação usa AES-256-GCM enquanto o NIP-44 v2 exige ChaCha20 com HMAC-SHA256, então os payloads em modo local não deveriam ser apresentados como compatíveis com NIP-44.

A sincronização com o parceiro usa a d-tag baby-tracker-sync, enquanto os backups próprios usam baby-tracker-backup. Notas assíncronas viajam dentro do payload do parceiro. O caminho documentado do Amber NIP-55 (assinador local) delega assinatura e cifragem ao assinador, mas o repositório não fornece nenhum teste de interoperabilidade mostrando que cada caminho de backup e de sincronização produz texto cifrado NIP-44 v2. O repositório não apresenta nem alegação de dispositivo médico nem auditoria de segurança de terceiros.

O Ghost Chat do walls.rip leva chat cifrado com PGP para relays públicos do Nostr

O walls.rip é um kit de comunicação anônima cujo modo Ghost Chat cria ou importa uma identidade OpenPGP no navegador. Seu cliente de código aberto cifra cada mensagem com a chave pública PGP do destinatário. A conversa legível permanece no armazenamento de sessão local do dispositivo; o aplicativo não tem conta de chat nem banco central de mensagens.

O transporte é Nostr de verdade, mas é deliberadamente específico do aplicativo. O Ghost Chat publica texto cifrado em formato armored como eventos kind 1 para cinco relays padrão e marca cada evento com uma tag de sala estável derivada da impressão digital PGP do destinatário. Isso dá aos desenvolvedores um exemplo concreto de uso de relays como transporte de mensagens resistente à censura, e também mostra por que a entrega descentralizada sozinha não protege metadados nem é interoperável com as mensagens diretas NIP-17.

pakstr 0.13.0 a 0.15.0 torna explícita a publicação no Zapstore

Depois do trabalho de empacotamento e Amber da 0.3.1 em julho, o pakstr é uma CLI que transforma uma pasta de recursos web em um APK Android assinado e o publica no Zapstore com uma chave Nostr. A 0.13.0 adiciona versionamento automático de releases. As versões 0.13.1 a 0.13.3 consertam a publicação no Blossom: a autorização agora usa base64url, os uploads carregam um Content-Digest, e o evento de aplicação do Zapstore é publicado antes do upload ao Blossom.

A 0.14.0 valida o publicador do Zapstore antes de a publicação seguir adiante. A 0.15.0 escreve metadados de listagem em eventos de aplicação kind 32267 e coloca as notas de lançamento no content de eventos de release kind 30063, de modo que o registro no Zapstore de um app empacotado pode carregar nome, resumo e notas sem uma etapa manual de listagem separada.

O Heterodyne é uma família de protocolos orientada a especificação para personas portáteis, comunicação autenticada, controle do próprio dispositivo e interação social. Seu README atual compõe quatro camadas existentes: eventos Nostr assinados, Radicle (git ponto a ponto) como armazenamento durável, Marmot (mensageria de grupo MLS sobre Nostr) para conversas cifradas diretas e em grupo, e registros de eventos de chave KERI (Key Event Receipt Infrastructure) para rotação de identidade. Uma persona é descrita como um npub Nostr de raiz fria mais um registro KERI aceito; a assinatura de rotina usa chaves de época rotativas, enquanto identidades de nó Radicle são delegadas com prova dupla.

A família divide esse trabalho em quatro rascunhos 0.x versionados de forma independente. O Core detém identidade, verificação de registros de eventos de chave, bytes canônicos do Nostr e o substrato de repositório Radicle; o Comms detém envelopes nativos do Nostr, níveis de privacidade, publicação e conversas Marmot; e o Social detém seguir público, interações e listas. O Control, para inscrição e concessões do próprio dispositivo, está incompleto e não pode ser reivindicado. Esses documentos seguem rascunhos que podem quebrar antes da 1.0, e esta edição apresenta a família antes de qualquer lançamento de cliente Heterodyne.

Lançamentos

Nostr Java v2.0.8: isolamento de assinaturas e NIP-44 portátil

Uma consulta de gift wrap contra um relay com cinco eventos retornava zero, dois ou seis eventos aleatoriamente, porque o Nostr Java, uma biblioteca Java para conversar com relays e cifrar payloads Nostr, entregava cada frame recebido a todos os listeners da conexão. A versão 2.0.8 roteia EVENT, EOSE e CLOSED para a assinatura que esses frames nomeiam, de modo que o sinal de fim de eventos armazenados de uma consulta não pode mais encerrar outra. Frames de escopo de conexão como NOTICE, OK e AUTH ainda alcançam todos os listeners.

O NIP-44 (cifragem de payload) no mesmo lançamento já não precisa de um provedor JCE registrado no processo. A cifragem só funcionava depois de gerar uma chave naquela JVM, o que registrava o BouncyCastle como efeito colateral, e falhava no Android, onde adicionar um provedor chamado “BC” não faz nada. Ambos os caminhos de cifra agora usam o motor leve ChaCha20 do BouncyCastle, e a geração de chaves já não altera o estado JCE de todo o processo. Quem dependia da biblioteca para registrar o provedor precisa registrá-lo por conta própria. A dependência do NIP-44 em relação ao provedor JCE é a issue que isso fecha.

NoorNote v1.3.6: status de perfil e anúncios classificados

O NoorNote é um cliente Nostr para desktop, web e Android. Uma semana depois de a 1.3.4 adicionar entradas cifradas em comunidades, a versão 1.3.6 mostra o NIP-38 (status de usuário) sob o nome NIP-05 (verificado por domínio) de um perfil: os eventos endereçáveis kind 30315, com expiração opcional, que carregam um status geral ou musical de uma linha. Clicar nessa linha define o próprio status de quem visualiza.

Os anúncios classificados do NIP-99 (ofertas de mercado kind 30402) agora são renderizados em todo o aplicativo, então o complemento de mercado só é necessário para comprar e vender. Notas privadas de apelido nos perfis também aparecem em laranja de alerta, com ícone de nota preenchido e um anel laranja no avatar.

nostrord v2.9.0: estado de grupo e mídia por relay

Sair de um grupo NIP-29 (grupos gerenciados por relay) em um servidor antes suprimia o mesmo id de grupo em todos os outros relays, porque o nostrord, um cliente multiplataforma para comunidades hospedadas em relays, indexava seus marcadores de saída e exclusão pelo id puro. Os marcadores de saída e exclusão delimitados por relay mantêm essas supressões no servidor que as produziu, então um grupo que compartilha um id entre dois relays já não é abandonado nem descartado em par. Uma entrada que o relay rejeita por já haver associação agora conta como sucesso e limpa o marcador local, que havia sido um estado absorvente: a autorrecuperação limpava um slot enquanto a partida a frio restaurava o outro.

A versão 2.9.0 também renderiza imagens embutidas em markdown que outros clientes escrevem como ![alt](url), em vez de exibir a pontuação markdown ao redor de uma URL já detectada. As mensagens diretas passam a suportar NIP-17 (DMs privadas com gift wrap) e rumors de arquivo kind 15, então um anexo cifrado enviado do Jumble é baixado, decifrado e exibido, e anexos de saída são cifrados antes do upload. Esta tag já entrega o trabalho de chave de cifragem NIP-4e coberto na semana passada. A proposta segue não incorporada, e o nostrord diz que sua implementação segue o comportamento do Jumble em produção onde esse comportamento difere do rascunho.

Alterações não lançadas

Shopstr mantém segredos de assinador remoto e de carteira fora do armazenamento do navegador

O Shopstr é um mercado web para anúncios classificados NIP-99. Depois do trabalho de integridade de pagamentos do mês passado, ele para de escrever no localStorage os segredos serializados do assinador bunker. Um payload de bunker NIP-46 (assinatura remota) havia incluído a URL bunker:// ativa e a chave privada de aplicação gerada, então qualquer script na origem do Shopstr podia retomar a sessão de assinatura remota. Os dados do bunker agora ficam na memória durante a sessão atual, payloads de bunker residuais são removidos quando encontrados, e tipos de assinador que não são bunker mantêm seu comportamento de armazenamento anterior.

A mudança correspondente no NWC faz o mesmo com as credenciais NIP-47 (wallet connect). O Shopstr havia armazenado a string nostr+walletconnect:// completa, incluindo o segredo usado para ações de carteira, como dados comuns de navegador, e a reutilizava no checkout. Strings de conexão e metadados de carteira agora ficam na memória, e cópias antigas armazenadas são apagadas ao ler os dados locais. Scripts que já rodam na origem do Shopstr durante uma sessão ativa ainda podem ver esses valores em memória.

Routstr verifica a descoberta de provedores vinda de relays

Um único relay malicioso podia antes decidir em quais provedores de inferência um cliente Routstr confiava. O Routstr SDK é a biblioteca TypeScript por trás do Routstr, um mercado que descobre provedores de IA no Nostr e os paga com Cashu. A correção de descoberta desta semana verifica cada anúncio de provedor, lista de modelos e avaliação entregues por relays (kinds 38421, 38423 e 38425) antes de qualquer consumidor vê-los, então uma avaliação que nomeia um pubkey confiável mas carrega uma assinatura inválida já não entra no ranking.

Timestamps muito no futuro são descartados antes da seleção da “avaliação mais recente”. Eventos mais de quinze minutos à frente do relógio local são removidos no caminho ao vivo e ao ler o armazenamento persistente, o que impede que um created_at falsificado supere avaliações validamente assinadas entre reinícios. Se avaliações confiáveis não estiverem disponíveis, o gate de avaliações falha fechado e exclui provedores sem avaliação do ranking de pagamento até que avaliações cheguem. Operadores ainda podem habilitar um provedor manualmente.

nostr-tools vincula os rumors de gift wrap aos seus seals

Desembrulhar um evento NIP-59 (gift wrap) antes decifrava o wrap, decifrava o seal e devolvia o rumor interno sem verificar de quem vinha o seal. O nostr-tools é uma biblioteca JavaScript de utilitários do protocolo Nostr. A correção de desembrulho desta semana exige que o wrap seja kind 1059, que o seal seja kind 13 com assinatura válida, e que o pubkey do rumor seja igual ao pubkey do seal. Decifrar o seal já prova o controle de seal.pubkey. Sem a última verificação, qualquer pessoa poderia selar um rumor nomeando outra pessoa como autora e fazer um cliente atribuir a mensagem a essa vítima.

O NIP-17 (DMs privadas com gift wrap) usa o mesmo caminho de desembrulho, então o vínculo se aplica às DMs privadas. O desembrulho em lote agora ignora um wrap que falhe nessas verificações em vez de lançar exceção, porque gift wraps não são solicitados e um único evento hostil descartaria o resto de uma consulta ao relay.

Haven adiciona administração de relay assinada e um navegador local de notas

O Haven é um relay Nostr auto-hospedado e um servidor de mídia Blossom. Seu console de administração recém-incorporado expõe chamadas de gestão NIP-86 em cada endpoint do relay, com cada requisição autenticada por um evento NIP-98 do proprietário configurado. Operadores podem gerenciar bloqueios, listas de permissão, regras de kind, nomes de relay e mídia armazenada sem dar ao relay uma chave de assinatura. Um navegador de notas somente leitura mantém kinds cifrados opacos e carrega mídia remota apenas após um clique, evitando uma requisição automática que revelaria o endereço IP do operador a um servidor externo.

A mesma mudança no Haven adiciona gráficos de tráfego persistentes e corrige uma falha com o LMDB padrão em que contar eventos armazenados podia entrar em laço infinito, fixar um núcleo de CPU e bloquear chamadas posteriores de estatísticas. O Haven agora usa o contador do backend onde ele termina e uma varredura limitada de eventos nos outros casos. O projeto adicionou seus primeiros 23 testes sobre paginação de eventos, exclusão, persistência de métricas, verificações de proprietário e assinaturas de requisição vinculadas à URL.

Amethyst tira a autorização do Blossom das threads de carregamento de imagens

O Amethyst, um cliente Nostr para Android, para de esperar a autorização de leitura do Blossom nas threads do dispatcher do OkHttp. O interceptor agora inicia a assinatura fora da thread de rede, enquanto o carregador de imagens aguarda uma assinatura compartilhada por servidor e repete a requisição do blob protegido. Uma rajada de imagens com controle de acesso portanto já não ocupa todos os slots de conexão por servidor enquanto um assinador responde.

O mesmo patch do Amethyst alinha a codificação do token com o BUD-11: Base64url sem preenchimento, escopo server e nenhuma tag x específica de blob, permitindo que um token cubra vários blobs no mesmo servidor. Novos testes de concorrência exercitam cache, expiração, novas tentativas assinadas e dezesseis chamadores simultâneos compartilhando uma assinatura.

Trabalho de protocolo e especificação

NIPs

Snort e Ditto agora usam NIP-22 (tópicos de comentários) para respostas de texto comuns, convergindo no kind 1111 mantendo caminhos de compatibilidade; isso não estabelece um kind de resposta único para todo o protocolo. Depois de a emenda de junho remover a proibição de usar NIP-22 contra notas kind 1, uma adição incorporada ao NIP-30 (emoji personalizado) lista o kind 1111 entre os eventos que podem carregar tags emoji, com um shortcode em content resolvido por essa tag. O Snort, um cliente Nostr web, agora escreve toda resposta como kind 1111, carrega esses comentários por tags de escopo raiz E/A em maiúsculas, e ainda aceita um caminho opcional NIP-10 (tags de resposta kind 1) para notas antigas. O Ditto, um servidor Mastodon e relay Nostr combinados, publica toda resposta como comentário NIP-22, kind 1111 para texto e kind 1244 para voz, enquanto continua renderizando as respostas kind 1 existentes. Clientes que só entendem NIP-10 não verão a nova forma. Publicações de nível superior seguem kind 1.

Uma requisição pay_invoice do NIP-47 (Nostr Wallet Connect) atualmente não tem uma forma padrão de o cliente especificar um teto de taxa de roteamento. Uma proposta aberta de teto de taxa adiciona um parâmetro opcional max_fee, em milissatoshis, a pay_invoice. Carteiras que respeitem o orçamento NÃO DEVEM enviar um pagamento cujo custo de roteamento exceda amount + max_fee e DEVEM retornar FEE_LIMIT_EXCEEDED, definido como nenhum débito e nenhuma tentativa de pagamento. Implementações que ofereçam suporte DEVEM incluir fees_paid na resposta para que o cliente possa reconciliar. Implementações sem suporte a limite de taxa ignoram o parâmetro desconhecido, e clientes devem tratar a ausência do campo fees_paid como sinal de que o teto pode não ter sido aplicado. A mudança não adiciona kinds de evento e segue proposta até ser incorporada.

Uma proposta aberta de rótulos de idioma no NIP-32 padronizaria ["l", "<BCP-47>", "lang"] para o idioma do texto declarado pelo autor. Como a tag l de uma letra já é indexável por relays, clientes poderiam pedir um feed em japonês com {"#l":["ja"]} sem atualizar o relay nem recorrer a detecção de idioma pouco confiável após o download. O rascunho também migra os exemplos de idioma nos relatórios de relay do NIP-66, nos metadados de imagem do NIP-68 e nas faixas de áudio do NIP-71 para o mesmo namespace. Rótulos seguem afirmações não verificadas do autor, e a mudança não está incorporada.

Nostr Wallet Connect

Após um tempo esgotado, uma reconexão ou uma notificação perdida, um cliente de wallet connect precisa de uma forma de pedir um único registro de pagamento sem saber qual protocolo de pagamento Bitcoin o criou. Um rascunho aberto de consulta de pagamentos no repositório de extensões do NWC define o opcional NWC-09 lookup_payment ao lado do núcleo do NIP-47. A requisição usa exatamente um seletor: um transaction_id estável no escopo da carteira, os campos payment_hash e/ou invoice compatíveis com BOLT11 já usados por lookup_invoice, ou um payment_type mais um objeto lookup tipado definido por outra extensão. Um resultado bem-sucedido devolve um envelope comum (transaction_id, type, state, payment_type, amount em msats, timestamps, fees_paid e metadata opcionais, e um objeto details discriminado) e DEVE resolver para exatamente um registro visível àquela conexão. A carteira NÃO DEVE revelar se existe um registro inacessível, e um seletor que corresponda a vários registros visíveis retorna MULTIPLE_MATCHES. Os estados são pending, accepted, settled, failed, expired e canceled. A mesma proposta adiciona detalhes de oferta e pagamento BOLT12 no NWC-12 que reutilizam esse envelope. Ambos os documentos seguem rascunhos.

NAPs

Um rascunho aberto de NAP-DISPLAY permitiria a um napplet pedir ao seu host os displays de pixels que tem permissão de usar. Ele se apoia na proposta de web applets NIP-5D, não incorporada e tramitada separadamente, que a Newsletter #17 apresentou e que segue fora do conjunto de NIPs incorporados. O rascunho define display.list, que devolveria identificadores estáveis opacos com largura e altura lógicas e um tipo escolhido em tempo de execução (lcd, eink, led-matrix ou other), e display.push, que enviaria um lote não vazio de pixels sRGB de três bytes endereçados por coordenadas. A descoberta em tempo de execução mapearia o RGB lógico para a profundidade de cor nativa, a orientação e a atualização, e PODE rotacionar, reordenar, quantizar, aplicar dither ou fundir atualizações. A política do shell controlaria quais displays um napplet pode listar ou escrever e PODE rejeitar, limitar a taxa ou impor teto aos lotes. Antes de aplicar qualquer pixel, o runtime validaria todo o lote, então um push falho não mudaria nada no dispositivo. Sucesso significaria que o lote foi aceito, não que a atualização do hardware terminou.

Marmot

Um experimento aberto do Marmot substituiria o rascunho retirado de External Commit para inscrição pela mesma conta por uma forma de Commit delimitada. O Marmot, o protocolo de mensageria de grupo MLS sobre Nostr, atribui nesse rascunho o componente sem dados 0x800d (marmot.same-account-membership.v1) como marcador de comportamento negociado. Enquanto for obrigatório, uma folha atual pode redigir exatamente um Add inline da mesma conta ou de um a quatro Removes inline de irmãos, cada um com um UpdatePath normal e prioridade de convergência comum, e cada Commit DEVE deixar no máximo cinco folhas atuais por conta. O pareamento usa um QR efêmero exibido pelo patrocinador (marmot-pairing-v1:) cujo segredo alimenta HKDF-SHA256 e ChaCha20-Poly1305 sobre um canal independente do portador. Provas kind 453 somente locais vinculam a sessão à chave de conta compartilhada e nunca são enviadas por relays. Após um Welcome correspondente, o primeiro payload de aplicação de quem entra é uma confirmação kind 452 não renderizada vinculada aos digests de Welcome e GroupInfo, de modo que um Welcome idêntico byte a byte pode ser recuperado sem consumir o KeyPackage novamente. O patrocinador pareado é a raiz de confiança de quem entra para esse ramo e não prova finalidade global. Um documento acompanhante de sincronização de contas segue exploratório e não interoperável. O experimento não faz parte do perfil base adotado.

Seis anos de agostos do Nostr

Os agostos seguem um único problema de interoperabilidade: como um cliente nomeia um alvo e anexa retorno a ele. O repositório original do protocolo não registrou commits em agosto de 2021, então o núcleo de eventos assinados ficou parado. O NIP-25 (reações) então saiu da caixa restrita ao kind 1 em 2022. Registros substituíveis regulares ganharam coordenadas naddr e a com identificador vazio em 2023; em 2024, a classe substituível parametrizada separada foi renomeada para eventos endereçáveis sem mudança no formato de fio. As reações migraram para mídia externa em 2025. O kind 1111 do NIP-22 (tópicos de comentários) chegou a clientes em produção em 2026. A progressão vai de um documento de protocolo parado a um vocabulário compartilhado de respostas e reações que funciona em notas, registros substituíveis e objetos fora da rede.

Agosto de 2021

A janela de commits de agosto de 2021 no repositório original do protocolo está vazia. A última mudança antes desse mês inativo foi o rascunho do NIP-05 de 18 de junho, que adicionou identificadores de domínio DNS como ponteiro legível por humanos para uma chave pública. O NIP-05 (identificadores de domínio) depois migrou para um arquivo JSON well-known, mas em meados de 2021 ainda era uma consulta TXT de DNS. Agosto não estendeu esse trabalho de identificadores nem adicionou um novo kind de evento ou mensagem de relay.

A mesma janela vazia aparece nas ferramentas que já existiam ao lado da especificação. O noscl, um cliente de linha de comando criado em janeiro de 2021, não registrou commits em agosto; nem o go-nostr nem o nostr-tools. A atividade do protocolo só retomou no fim do ano, quando o repositório atribuiu o NIP-09 (pedidos de exclusão de eventos) e substituiu o esquema DNS por um arquivo JSON well-known de identificadores. Agosto de 2021 é o estágio inativo entre o rascunho de identificadores de junho e o trabalho de exclusão e JSON well-known de dezembro, enquanto o modelo de eventos assinados e relays se manteve como escrito.

Agosto de 2022

Em 19 de agosto, uma edição do NIP-25 ampliou os alvos das reações kind 7 das notas de texto kind 1 para outras notas. O evento kind 7 e a convenção +/- já estavam no rascunho. Essa mudança de interoperabilidade permitiu que um like, dislike ou emoji se anexasse a um perfil, a uma lista de seguidos ou a qualquer kind de evento posterior que reutilizasse as mesmas tags e e p.

A especificação atual do NIP-25 mantém essa generalização: uma reação indica reações de usuário a outros eventos, e um alvo endereçável recebe também uma tag a com coordenadas kind:pubkey:d-tag. O Amethyst, um cliente Android, implementa esse contrato em seu construtor de reações. O construtor aceita qualquer evento, escreve tags e, p e k, e adiciona uma tag a quando o alvo é um evento endereçável. Isso generalizou os alvos de reação além do kind 1; mudanças posteriores de agosto adicionaram coordenadas estáveis e tags de contexto de comentário.

O software de relay também estava transformando regras de tags em comportamento de armazenamento. Em 17 de agosto, o nostr-rs-relay parou de tratar todo valor de tag com aparência hexadecimal como chave de índice binária. Limitou essa otimização a tags de uma letra e valores hexadecimais em minúsculas, preservando tags de texto comuns em vez de decodificá-las para uma forma que os filtros não conseguiam casar. Aquele mês uniu assim dois lados da interoperabilidade: as especificações ampliaram o que uma interação podia alvejar, enquanto um relay corrigia como essas tags de alvo eram indexadas e recuperadas.

Agosto de 2023

Em 24 de agosto, o NIP-19 (identificadores bech32) definiu como codificar um evento substituível não parametrizado como naddr. O campo de identificador, a tag d, tornou-se uma string vazia para kinds que substituem apenas por pubkey e kind, como metadados e listas de contatos. Cinco dias depois, o NIP-01 (o protocolo base de eventos e relays) adicionou o formato de a-tag correspondente: kind:pubkey: com dois-pontos ao final e sem identificador. Clientes podiam agora apontar para um registro substituível sem esperar um id de evento específico que a próxima substituição invalidaria.

O texto atual do NIP-19 ainda instrui quem implementa a usar uma string vazia para esses eventos substituíveis. O nostr-tools, a biblioteca JavaScript de identificadores, codifica esse campo por naddrEncode, então quem chama pode passar um identificador vazio e produzir uma coordenada compartilhável. O trabalho de agosto de 2023 transformou o estado substituível em algo que um comentário, uma reação ou um link de compartilhamento podia nomear depois de o evento subjacente ter sido substituído. O agosto seguinte padronizou a terminologia da classe substituível parametrizada relacionada, enquanto tags de comentário posteriores reutilizaram a gramática de coordenadas como A e a.

Payloads privados estavam se tornando portáteis ao mesmo tempo. Em 24 de agosto, o rust-nostr adicionou funções de cifragem e decifragem NIP-44 aos seus bindings JavaScript, expondo o esquema versionado de chave de conversa a aplicações web ao lado de chamadores Rust nativos. Em 22 de agosto, o Amethyst separou a cifragem NIP-44 do formato do evento de mensageria, refletindo a separação de protocolo entre como o conteúdo é cifrado e como um aplicativo o transporta. Coordenadas estáveis tornaram objetos públicos mais fáceis de referenciar; APIs de cifragem reutilizáveis tornaram conteúdo privado mais fácil de mover entre implementações sem acoplá-lo a um kind de mensagem.

O mesmo mês trouxe também financiamento para trabalho adjacente de isolamento de chaves, interface e educação. Uma rodada de subsídios da OpenSats de 17 de agosto destinou seus subsídios do Nostr Fund ao Amber, ao design compartilhado de interface do Nostr e à educação sobre casos de uso do Nostr. O subsídio do Amber focou em manter chaves de assinatura em um aplicativo Android dedicado via NIP-46, enquanto os subsídios de design e educação trataram de onboarding e padrões reutilizáveis de aplicação. O sistema Nostr mais amplo avançava por commits de especificação, isolamento de chaves, trabalho de interface e educação de desenvolvedores financiada como infraestrutura compartilhada.

Agosto de 2024

Em 20 de agosto, as especificações renomearam “evento substituível parametrizado” para “evento endereçável” no NIP-01 e em outros dezesseis documentos, incluindo artigos de formato longo, atividades ao vivo, listas, calendários e anúncios classificados. O formato de fio não mudou. kind:pubkey:d-tag permaneceu a coordenada. O que mudou é que cada especificação que já usava essas coordenadas passou a usar a mesma palavra para elas.

Esse vocabulário é o que as implementações atuais entregam. O NIP-01 armazena eventos endereçáveis como o registro mais recente por kind, pubkey e tag d. O NIP-19 chama um naddr de “a nostr addressable event coordinate”. O caminho de reações do Amethyst, citado acima, tipa o alvo como AddressableEvent antes de escrever a tag a. A extensão de coordenadas de 2023 e a mudança de terminologia de 2024 usam ambas a gramática de coordenadas kind:pubkey:d-tag, enquanto o NIP-01 continua distinguindo eventos substituíveis regulares de eventos endereçáveis. Um comentário posterior pode portanto buscar uma discussão endereçável por A maiúsculo sem se importar com qual id de evento ocupa esse endereço no momento.

Protocolos de armazenamento aplicavam a mesma preferência por identificadores explícitos. Em 27 de agosto, o BUD-04 do Blossom permitiu que um evento de autorização carregasse várias tags x de hash de blob, de modo que um cliente pudesse autorizar um lote delimitado de uploads, espelhamentos ou exclusões sem fingir que os hashes descreviam um único objeto. Quatro dias depois, o projeto esclareceu seu descritor de blob e adicionou um exemplo. Eventos Nostr coordenavam operações sobre mídia endereçada por conteúdo enquanto os bytes permaneciam em servidores de mídia, separando autorização assinada do transporte de armazenamento.

Em 29 de agosto, a assinatura remota tornou-se mais tolerante a conjuntos de relays imperfeitos. O go-nostr mudou seu cliente NIP-46 para que um relay defeituoso não pudesse bloquear uma requisição enviada por outros relays configurados: conexões a relays e tentativas de publicação rodam de forma independente, e a chamada segue assim que qualquer conexão tem sucesso. Em 19 de agosto, a OpenSats também anunciou apoio de longo prazo ao criador do Amethyst, Vitor Pamplona, incluindo trabalho nas mensagens privadas NIP-17, em bibliotecas multiplataforma e no modelo outbox. O vocabulário do protocolo, o transporte resiliente, o trabalho de privacidade e o financiamento sustentado de manutenção convergiam para o mesmo objetivo: clientes que pudessem continuar funcionando entre dispositivos e condições irregulares de relay.

Agosto de 2025

Em 22 de agosto, o NIP-25 ganhou reações a conteúdo externo. Uma reação a algo que não é um evento Nostr nativo deve ser kind 17 e deve carregar tags k e i do NIP-73 (identificadores de conteúdo externo), substituindo a antiga tag r de site. Os exemplos no texto incorporado são uma URL web (k=web) e um episódio de podcast identificado por GUID do programa e GUID do item, com URLs do Fountain como dicas. As reações haviam saído do kind 1 em 2022. Agora saíram do conjunto de eventos Nostr.

O Fountain 1.3, publicado em 15 de agosto de 2025, entregou esses likes antes da incorporação da especificação e disse que eles funcionam com Nostr para que outros apps de podcast possam lê-los. O documento do NIP-25 de hoje ainda usa o exemplo de GUID de podcast do Fountain. Em agosto de 2025, uma coordenada de reação já podia nomear um episódio de podcast ou uma página web com a mesma gramática de identificadores que um comentário usa depois para uma raiz externa.

Agosto de 2026

Este agosto levou os tópicos de comentários aos clientes que escrevem respostas comuns. A emenda de junho, incorporada depois, removeu a linha que havia dito aos clientes para não usar comentários NIP-22 em notas curtas. O NIP-30 (emoji personalizado) então adicionou o kind 1111 ao lado de notas, reações e status de usuário, então um comentário pode carregar as mesmas tags de emoji que esses outros kinds já usavam. O trabalho de especificação é a permissão. O trabalho de cliente é a implantação.

O Snort, um cliente web, agora publica comentários NIP-22 para alvos kind 1 por padrão, assina tópicos por tags raiz E/A em maiúsculas, e aceita kind 1111 nas notificações. O Ditto, um cliente web comunitário, publica toda resposta como comentário NIP-22, kind 1111 para texto e 1244 para voz, incluindo respostas a notas kind 1, enquanto ainda lê respostas NIP-10 (encadeamento de notas). A virada de seis anos aparece nesses padrões: 2022 generalizou a reação, 2023 e 2024 nomearam a coordenada, 2025 apontou reações para fora da rede, e 2026 fez do comentário o evento de resposta compartilhado para esses mesmos alvos.

A infraestrutura de grupos privados definia a recuperação como requisito de interoperabilidade. O contrato de durabilidade e reinício de 13 de agosto do Marmot especifica qual estado local de MLS e de publicação deve sobreviver a um reinício, e exige que clientes reconciliem o estado persistido antes de continuar operações de grupo. Isso estende a progressão de agosto além de nomear um alvo: um cliente maduro precisa também preservar estado criptográfico e de entrega suficiente para retomar com segurança após uma interrupção. Formas de evento compartilhadas só servem quando as implementações conseguem recuperar o estado necessário para usá-las.

Envie uma DM NIP-17 para compartilhar um projeto ou uma notícia por meio do projeto Nostr Compass.