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

Esta semana: Amethyst 1.13.1 dá continuidade ao lançamento dos aplicativos Nostr da versão 1.13.0 com autenticação do relay anfitrião NIP-29 e novas tentativas autenticadas de download no Blossom. Code Call mantém sessões remotas de programação em andamento a partir de um telefone, GitWorkshop coordena mantenedores e a sincronização de repositórios, e Mosaico oferece aos agentes de programação uma camada compartilhada de percepção pelo Nostr. Nostrology mapeia como os perfis dividem as funções de leitura e escrita entre suas listas de relays publicadas. Os lançamentos para Android de Mafrend, Hanami e Cordn lideram os lançamentos etiquetados, enquanto o FIPS adiciona uma camada de acesso para OpenWrt e um PR aberto propõe um port para FreeBSD. A cobertura de protocolos apresenta NIPs, BUDs, NAPs, Marmot, Gamma Markets, Concord e NWC, enquanto Seis anos de julhos do Nostr acompanha as mudanças de julho desde as primeiras consultas de domínio até o estado dos grupos em relay.

Matérias principais

Amethyst 1.13.1 dá continuidade ao lançamento de seus aplicativos Nostr com acesso autenticado a grupos e ao Blossom

Amethyst 1.13.0, lançada em 28 de julho para o cliente Nostr para Android e outras plataformas, abre napplets e nsites NIP-5A dentro de um processo de navegador isolado e sem chaves. Uma ponte window.nostr condicionada ao consentimento pode assinar e usar recursos selecionados por meio da conta ativa, enquanto telas de permissão por site e por conta permitem que os usuários revisem ou revoguem essas concessões. Os aplicativos favoritos podem permanecer fixados na barra inferior sem compartilhar cookies, estado de login ou concessões entre contas.

O mesmo lançamento 1.13.0 adiciona árvores de repositórios Git, issues e pull requests ao lado de comunidades Concord, grupos de relay NIP-29, chat em grupo Buzz, páginas wiki e feeds RSS. Essas superfícies permitem que o usuário transite entre visualizações de código, comunidade, publicação e redes sociais sob a mesma identidade Nostr.

Os pagamentos e a identidade também se ampliaram na versão 1.13.0. Amethyst pode criar e pagar ofertas BOLT12, iniciar automaticamente contas com assinante remoto, adicionar servidores fallback do Blossom e ampliar os controles de Web of Trust para badges, comunidades e grupos de relay. A atualização 1.13.1, de 29 de julho, adiciona um selo de dissolução CORD-02, exclusão de grupos e canais com kind 9008, autenticação do relay anfitrião NIP-29 e novas tentativas BUD-01 autenticadas para downloads protegidos no Blossom.

Code Call 0.2.68 adiciona um navegador de pastas do worker depois que a 0.2.66 introduziu a recapitulação

Code Call 0.2.68, um controle remoto Android para sessões de programação executadas no computador, substitui sua lista específica de espaços de trabalho por um navegador de pastas com raiz no diretório do worker. O usuário pode navegar por pastas permitidas e aninhadas, selecionar uma para uma sessão do OpenCode e retornar às pastas superiores; a versão 0.2.67 abre esse navegador quando uma sessão é criada.

O lançamento 0.2.66 anterior pode solicitar a um worker roteado uma recapitulação concisa desde a última mensagem enviada pelo telefone. Outros lançamentos da mesma semana mantêm várias sessões independentes, aceitam respostas apenas do remetente esperado e mantêm a caixa de entrada conectada a todos os relays de worker configurados para entrega em segundo plano. As solicitações e respostas trafegam em NIP-17 (Mensagens Diretas Privadas), enquanto os anexos do Blossom criptografados localmente mantêm seu tipo de arquivo original após a descriptografia.

GitWorkshop coordena mantenedores e mantém a sincronização de repositórios independente

O lançamento assinado do GitWorkshop em 27 de julho adiciona login no Android por meio do NIP-55 (Aplicativo de Assinatura Android) ao forge NIP-34 (git stuff) baseado em navegador. Seu repositório de código-fonte agora coordena mantenedores principais recursivamente, preserva os relay hints de cada mantenedor e mantém a sincronização de repositórios independente da aceitação de convites. Referências a itens de trabalho entre repositórios conectam trabalhos relacionados em diferentes repositórios, enquanto o GRASP copia dados do repositório para endpoints Git selecionados sem vincular essa transferência à entrega de convites. A atualização 3.1.1, assinada pelo desenvolvedor, corrige a entrega de intents do assinante Android, a resolução recursiva de mantenedores e links de repositório que preservam o caminho.

Mosaico 0.1.2 permite que agentes de programação compartilhem status pelo Nostr

Mosaico 0.1.2 permite que sessões de agentes de programação no Claude Code, Codex, Goose, Hermes, OpenCode e Grok publiquem atualizações curtas de status por meio de NIP-29 (Grupos baseados em relay). As sessões podem encontrar trabalhos ativos relacionados em diferentes hosts sem compartilhar suas transcrições ou contexto.

A descoberta de perfis nomeados do Codex e a visualização Top Of Mind do Goose exibem esse status compartilhado dentro dos dois ambientes (PR #618, PR #619). O lançamento restaura a capacidade dos agentes hospedados de ingressar na camada pública de percepção, e a configuração agora exige a escolha explícita de um relay (PR #626, PR #629). Mosaico continua sendo uma camada de percepção, não um host de agentes, orquestrador ou combinador de transcrições.

Nostrology mapeia a concentração das listas de relays a partir de events publicados do NIP-65

O observatório de relays do Nostrology deriva seu conjunto de dados do event kind 10002 mais recente de cada perfil, definido pelo NIP-65 (Metadados de lista de relays), e segue a especificação publicada. Ele separa as funções de relay de leitura, escrita e combinadas, apresenta em gráficos quantos relays cada perfil lista e expõe as contagens subjacentes em uma tabela ordenável. Na revisão para publicação de 29 de julho, a página continha 34.430 valores distintos de URL de relay e agrupava 520.468 perfis com exatamente um relay listado, em comparação com 150.657 com três e 60.710 com quatro.

O mesmo instantâneo do Nostrology mostra uma concentração sobreposta em torno de relay.momostr.pink, com 298.859 perfis, relay.damus.io, com 287.181, nos.lol, com 279.468, e relay.primal.net, com 225.336. Essas contagens medem entradas publicadas em listas de relays, não disponibilidade: a tabela bruta pode incluir URLs malformadas e endereços locais, enquanto a especificação NIP-65 define metadados de roteamento e não testa o estado operacional dos relays. O observatório torna visíveis os problemas de adoção e qualidade dos dados sem tratar um relay listado como se estivesse em funcionamento.

Lançamentos com tag

Kairos 0.1.1 adiciona lembretes e uma instrução local para Astraea

Kairos 0.1.1 adiciona lembretes de prazo, uma instrução local explícita para Astraea e tratamento mais rigoroso de relays e URLs. O lançamento assinado 0.1.0 introduziu o gerenciador de tarefas offline-first, cuja camada opcional de sincronização grava registros criptografados com NIP-44 (Payloads criptografados) em relays selecionados pelo usuário. Kairos usa coordenadas determinísticas de tarefas e tombstones criptografadas com solicitações de exclusão do NIP-09 (Solicitação de exclusão de event), enquanto as tarefas exclusivamente locais nunca saem do dispositivo.

Bray 2.3.0 oferece à sua CLI gift wrapping geral e uma superfície local de testes do Blossom

Bray 2.3.0, um SDK Nostr e kit de ferramentas de linha de comando, pode aplicar e remover gift wrap de events arbitrários por meio do NIP-59 (Gift Wrap), com a assinatura roteada pelo NIP-46 (Nostr Connect) quando um bunker mantém a chave. O PR #75 também oferece ao relay de testes incluído desafios do NIP-42 (Autenticação de clientes em relays) e expõe os comandos restantes do cliente Blossom. O PR #77 adiciona um servidor BUD-01/02 em memória cuja autorização assinada vincula cada upload ou exclusão a um blob, enquanto o PR #76 adiciona event kinds nomeados, tags abreviadas e flags de reconciliação de IDs do NIP-77 que evitam o download de events que o solicitante já possui.

Buzz Desktop 0.5.0 reforça convites, busca e atualizações da identidade no relay

Após a cobertura dos espaços de trabalho Armada e Buzz na semana passada, Buzz Desktop 0.5.0 adiciona links de convite com limite de usos (PR #3141) e filtros de busca por autor, canal e limites de tempo (PR #2871). O PR #2862 recupera políticas de ingresso pela camada de rede nativa do aplicativo desktop, e o PR #2607 republica o registro de identidade de um agente depois que a renomeação de uma persona chega ao relay. O lançamento também atualiza sua dependência Nostr devido a um aviso de negação de serviço remota no NIP-44 e corrige a recuperação do armazenamento local, o posicionamento de conversas, a reconexão de relays e os caminhos de execução no Linux e Windows.

Shosho 1.0.0 amplia seu mercado de transmissões ao vivo

Shosho 1.0.0 reformula o mercado de transmissões ao vivo em torno de criadores, sessões ao vivo, clipes e produtos que os usuários podem encontrar por uma busca configurável em relays. Um feed unificado de notificações agora reúne menções, reações, republicações e zaps e permite respostas sem sair do feed. Os espectadores podem publicar clipes de transmissões ao vivo ou reprises, enquanto o lançamento também melhora o chat em conversas encadeadas, as respostas a clipes, o carregamento de perfis e o uso da rede.

Mafrend v1.0 apresenta uma prévia do chat Nostr baseado em lugares no Android

Mafrend v1.0 é a primeira versão alfa pública para Android de um aplicativo planejado de chat Nostr baseado em lugares. Sua página de projeto classifica o conjunto de funcionalidades como ainda em desenvolvimento ativo e descreve cada localização no mapa como uma sala de chat dedicada a conversas sobre um lugar. Um repositório público de lançamentos contém o pacote instalável do Zapstore, enquanto o aplicativo principal permanece privado.

Hanami 0.1.0 oferece aos servidores Blossom um caminho Android mediado por assinante

Hanami 0.1.0, um aplicativo Android complementar para servidores Blossom, permite que as pessoas entrem, enviem e baixem arquivos pelo telefone. O aplicativo usa NIP-55 (Aplicativo de Assinatura Android) para assinatura mediada por aprovação e um handshake nativo do NIP-98 (HTTP Auth) para a sessão com o servidor. Hanami restringe seu shell web e a ponte de assinatura à origem escolhida do servidor, mantendo as credenciais com o assinante enquanto a interface web existente do servidor fornece a experiência do aplicativo. O primeiro lançamento público exige Android 8 ou posterior, um servidor Hanami acessível e um aplicativo assinante compatível.

Cordn lança seu chat em grupo com identidade Nostr no Android

Cordn, um cliente privado de mensagens em grupo, agora oferece aos usuários do Android configuração inicial de identidade Nostr, links de perfil por meio do NIP-05 (Mapeamento de chaves Nostr para identificadores de Internet baseados em DNS) e links verificados que abrem destinos do Cordn no aplicativo. O lançamento 0.2.1 publicado em 24 de julho introduz essa versão nativa ao lado do cliente web existente. As mensagens usam MLS, um protocolo de criptografia de grupo, com entrega assistida por coordenador, de modo que os grupos mantenham conversas criptografadas ordenadas sem exigir endereço de e-mail ou número de telefone.

Nostur 1.30.1 corrige cadeias de respostas e publicações duplicadas depois que a 1.30.0 ampliou o compartilhamento

Nostur 1.30.1, um cliente Nostr para iPhone, iPad e Mac, permite que as pessoas percorram cadeias aninhadas de respostas sem as falhas de expansão e recolhimento que prejudicavam o novo layout. Também impede que o mesmo rascunho seja publicado duas vezes, inclusive quando callbacks de upload de mídia se repetem. O lançamento sucede a 1.30.0, que adicionou mensagens diretas temporárias e uma opção na folha de compartilhamento para enviar mídia ao Nostr, de modo que o aplicativo agora combina novos caminhos de mensagens e publicação com correções para seus fluxos cotidianos de conversas e publicações.

Formstr Drive 0.0.2 combina metadados de arquivos Nostr com blobs do Blossom

Formstr Drive 0.0.2, um gerenciador de arquivos nativo do Nostr, oferece aos usuários visualizações prévias no aplicativo e a opção de abrir documentos de escritório no Nostr Docs. Na camada de armazenamento, ele divide arquivos grandes em blobs no Blossom e exclui o blob remoto quando o usuário remove um arquivo. Um relay local mantém os metadados Nostr do aplicativo à mão, enquanto o Blossom guarda os dados dos arquivos, separando a organização dos arquivos de seu conteúdo volumoso.

NoorNote 1.3.1

NoorNote 1.3.1, um cliente Nostr para web, desktop e Android, adiciona temporizadores para mensagens que desaparecem e configura relays padrão funcionais para DMs em contas recém-criadas. Ele filtra artigos globais sem imagens de capa e direciona notificações de republicação para o leitor de artigos. O lançamento 1.3.0 anterior adicionou cartões do NIP-53 (atividades ao vivo), tags de pessoas do NIP-68 (Feeds que priorizam imagens), um silenciamento suave do NIP-78 (dados de aplicativos) e a indicação dos relays em que cada nota foi vista.

algia 0.0.133

algia 0.0.133, um cliente de linha de comando em Go para Nostr, sucede a 0.0.132, que adicionou listagem, linhas do tempo, publicação, reações, exclusões e fluxos de ingresso e saída do NIP-29 (Grupos baseados em relay). O mesmo lançamento adicionou pré-autenticação do NIP-42 (Autenticação de clientes em relays) para relays configurados para exigi-la. A versão 0.0.133 então adicionou o envio de imagens locais aos comandos de publicação regular, em canais e em grupos, anexando as URLs resultantes e tags do NIP-92 (Anexos de mídia) a cada event. Publicações somente com imagens também funcionam, e publicações em grupo usam por padrão o armazenamento de mídia do relay do grupo, enquanto as demais usam os servidores de arquivos configurados.

swift-nostr 0.7.0

Para aplicativos Swift, swift-nostr 0.7.0, uma biblioteca Nostr para plataformas Apple, permite que um assinante remoto NIP-46 controle todos os recursos do cliente por meio de sua abstração de assinatura. O lançamento adiciona suporte ao NIP-98 (HTTP Auth) e ao NIP-29 (Grupos baseados em relay), incluindo fluxos de ingresso, publicação e moderação em grupos. Também valida o padding do NIP-44 (Payloads criptografados, com versão) com base nos vetores oficiais, rejeitando payloads que contêm um MAC válido sobre padding não canônico.

lawallet-nwc 2.0.0

LaWallet NWC 2.0.0, uma carteira conectada ao Nostr e serviço do NIP-47 (Nostr Wallet Connect), adiciona login com passkey que deriva a chave de assinatura Nostr no navegador por meio da extensão PRF do WebAuthn. O servidor nunca recebe esse segredo, e a mesma passkey pode recuperar a mesma chave em outro dispositivo sincronizado. As contas agora podem vincular e combinar várias pubkeys Nostr, enquanto o serviço opcional de escuta retransmite events de conexão da carteira e tenta novamente a entrega de webhooks quando um endpoint está inacessível.

MDK 0.9.10

MDK 0.9.10, a implementação em Rust do protocolo Marmot, mantém envios pendentes enquanto um transporte está inativo e supervisiona o encaminhamento de notificações de relay para que a entrega de entrada seja retomada após atraso, panic ou encerramento. O PR #1159 adiciona histórico de conversas durável e paginado e contexto completo das respostas para agentes locais, e o PR #1167 republica o event KeyPackage assinado atual em vez de gerar um substituto. O lançamento também preserva a ordenação manual dos chats, permite a dissolução definitiva de grupos e amplia a busca classificada por Web of Trust, as APIs de política de relay e as vinculações de linguagem.

pakstr 0.3.1

pakstr 0.3.1 permite que equipes web que empacotam um cliente Nostr para Android forneçam configuração em tempo de execução e um proxy de API sem reconstruir o shell do aplicativo. Sua série de lançamentos do mesmo dia adicionou uma ponte para o assinante Amber, criptografia e descriptografia com NIP-44 (payloads criptografados) e corrigiu a injeção de permissões do Android antes do trabalho de configuração em tempo de execução da série 0.3.x. A estrutura-base mantém os recursos web incluídos localmente enquanto as configurações específicas da implantação chegam em tempo de execução, e o proxy oferece ao aplicativo encapsulado uma rota controlada para solicitações de API ao lado de suas conexões comuns com relays.

Ditto 2.34.2

Ditto 2.34.2, um cliente social Nostr personalizável, renderiza status de usuários como cartões em feeds, páginas de detalhes e citações incorporadas, incluindo emoji personalizado, expiração e prévias opcionais de links. Zaps com comentários agora aparecem como respostas abaixo da publicação referenciada. O lançamento também mantém o botão opcional de globo no perfil da versão 2.34.1 para proprietários que publicam um site raiz NIP-5A (manifesto de website) e corrige a navegação da página inicial, a busca de transmissões ao vivo, o tratamento de links externos e emojis personalizados quebrados.

Earthly 0.0.9

Earthly 0.0.9, um editor colaborativo de mapas construído sobre Nostr, agora mantém as curtidas visíveis quando a gaveta de uma entidade do mapa é fechada, reaberta ou atualizada. Seu fluxo do NIP-57 (zaps Lightning) envia JSON válido de solicitação de zap para que provedores Lightning possam publicar recibos verificados em relays publicamente acessíveis, inclusive durante o desenvolvimento local. As faturas geradas permanecem visíveis durante mudanças na interface da entidade, e o aplicativo exibe uma confirmação após a chegada de um recibo verificado.

Em desenvolvimento

Keep adiciona assinatura NIP-44 v3 com escopo por kind e reforça a política de aprovação

Keep incorporou cinco mudanças no assinante Android que transportam solicitações de criptografia e descriptografia do NIP-44 (Payloads criptografados) v3 pelos dois transportes do NIP-55 (Aplicativo de Assinatura Android) e por seu bunker do NIP-46 (Nostr Connect). Os PRs #451, #452 e #453 mantêm as concessões v3 separadas das v2, definem seu escopo por event kind, rejeitam kinds ausentes ou inválidos e preservam solicitações de aprovação abertas a partir de notificações. Os PRs #454 e #455 deixam de tratar a política de assinatura Basic como Auto e movem a seleção global para o armazenamento criptografado controlado pelo núcleo. Os mantenedores do Keep incorporaram as cinco mudanças após o lançamento Android com tag mais recente.

Routstrd altera o endereço de escuta padrão após uma exposição sem autenticação

O PR #56 do Routstrd altera o endereço de escuta padrão do roteador local de inferência Nostr de todas as interfaces de rede para 127.0.0.1. O padrão anterior expunha endpoints sem autenticação de saldo da carteira, histórico, acesso, envio, reembolso, chave de API, provedor, cliente, uso e interrupção do daemon a qualquer host que pudesse alcançar a porta. Os operadores ainda podem configurar explicitamente um endereço de escuta não local, mas a mudança incorporada torna uma nova implantação exclusivamente local por padrão e ainda não apareceu em um lançamento com tag.

Imwald Android esclarece o status da publicação offline

Imwald Android, um cliente Nostr para Android, agora trata a confirmação de um relay local como publicação concluída apenas quando todos os destinos configurados são locais. Sua correção de publicação offline e outbox mantém a entrega remota pendente quando um relay local aceitou o event, mas os relays remotos configurados não, de modo que o relatório de publicação diferencia o armazenamento local no dispositivo da entrega em relay.

FIPS adiciona uma camada de acesso para OpenWrt; uma versão para FreeBSD continua em análise

O Free Internetworking Peering System nativo do Nostr agora permite que um roteador OpenWrt exponha uma rede de acesso aberta !FIPS por meio do PR #126 incorporado. O PR #129 para FreeBSD, paralelo e ainda aberto, propõe portar o daemon, o caminho de dados TUN, a resolução de nomes .fips, o gerenciamento do serviço e a compilação de pacotes nativos. A incorporação para OpenWrt amplia o acesso hoje, enquanto o trabalho para FreeBSD o estenderia a outro sistema operacional de uso geral.

Uma atualização do projeto FIPS em 26 de julho relatou mais de 300 nós em sua rede sobreposta UDP pública e uma malha mais ampla próxima de 2.000 nós. O repositório do FIPS passou a mesma semana reforçando testes de concorrência de rede, continuidade de troca de chaves, comportamento de limite de saltos, verificações de firewall e isolamento do laboratório de NAT. O trabalho no repositório oferece aos operadores verificações reproduzíveis desses comportamentos à medida que a rede cresce.

Zap Cooking programa publicações e vincula solicitações do scanner

Zap Cooking, um aplicativo Nostr para compartilhar receitas e planejar refeições, agora pode manter uma publicação programada em armazenamento criptografado e publicá-la no momento previsto por meio de uma varredura periódica dos relays (PR #566, PR #569). Isso oferece aos usuários um caminho de publicação programada sem deixar o conteúdo não assinado exposto no banco de dados do agendador.

Seu scanner de geladeira agora autentica o corpo exato da solicitação com autenticação HTTP do NIP-98, de modo que as verificações de associação dependam da chave que assinou a solicitação de escaneamento, não de uma pubkey fornecida em seu corpo (PR #599).

Citrine transforma um dispositivo Android em um relay gerenciável

Citrine, um relay Nostr hospedado no Android, agora pode enviar os events armazenados para relays externos, oferecendo ao operador uma forma de retransmitir o histórico local (PR #179). Também adiciona comandos do NIP-86 (API de gerenciamento de relay) para que clientes compatíveis possam administrar o relay (PR #150).

Os operadores de grupos podem administrar grupos baseados em relay do NIP-29 por meio da assinatura Amber no PR #178, enquanto o PR #174 mantém a configuração de relays via Tor e o estado do ciclo de vida alinhados entre reinicializações.

Wired recupera conversas completas no navegador

Wired, um cliente Nostr baseado em navegador, agora segue as raízes dos feeds, as respostas e os events referenciados até a conclusão, em vez de parar em limites fixos de abrangência ou de quantidade de resultados (PR #148, PR #147, PR #146). Assim, os usuários podem recuperar conversas mais profundas e o contexto dos feeds quando os events relevantes estão disponíveis em seus relays.

O navegador também preserva relay hints nos events referenciados e os usa apenas para o contexto que ainda falta, restaurando conversas que os relays configurados não contêm (PR #145, PR #144). Uma recuperação incompleta permanece distinta de um instantâneo completo, para que uma resposta parcial não substitua a visualização anterior em cache.

Trabalho em protocolos e especificações

NIPs: limite de hospedagem do NIP-34, migração de grupos e três rascunhos ativos

Duas mudanças de especificação foram incorporadas nesta semana. O commit 6d2979b do NIP-34 remove as instruções de hospedagem do GRASP da descrição de pull request do kind:1618, deixando o comportamento de hospedagem e fallback fora do contrato do event. O commit db5fe3d do NIP-29 define como os metadados de grupos em relay migram para outro relay e como os clientes distinguem uma mudança válida de um fork que continua de forma independente.

O PR #2424 propõe declarações mútuas de conjuntos de chaves com kind:10045. O requisito recíproco impediria uma identidade de vincular unilateralmente outra chave. O PR #2421 propõe intenções de zap BOLT12 e provas do pagador que os clientes podem validar em relação ao destino, valor, oferta e pagamento liquidado sem depender de um servidor de recibos operado pelo destinatário.

O PR #2425 permitiria que os favoritos NIP-B0 preservassem esquemas diferentes de HTTP, como nostr:, ao lado de URLs web. Isso manteria intactos identificadores Nostr nativos, solicitações de pagamento e outros esquemas de aplicativos dentro das mesmas listas privadas ou públicas de favoritos que já contêm endereços web.

Mill implementa um rascunho para backup de chaves em contas na nuvem

Mill anunciou a implementação de um rascunho de backup de chaves em contas na nuvem que combina um identificador de conta Google OIDC com uma senha de alta entropia para derivar uma chave de backup descartável. Sua implementação de referência criptografa a chave real do usuário como um ncryptsec do NIP-49 (Criptografia de chave privada) e a armazena em um event provisório de kind 30049, do tipo substituível parametrizado, nos relays configurados. O projeto incorporou o fluxo de backup à main, mas nenhum lançamento posterior à v1.0.0 o inclui, e o fluxo de backup permanece desabilitado a menos que um operador forneça backupRelays dedicados. Um conjunto de relays com versão permanece provisório, e o rascunho alerta que o texto cifrado publicado continua disponível para tentativas offline de adivinhação da senha. Os leitores devem tratar o design como um experimento implementado que depende de uma senha de alta entropia.

BUDs: servidores Blossom podem identificar envios desconhecidos por seus bytes

O PR #110 do BUD-02 propõe recomendar a detecção do MIME pelo servidor quando quem envia o arquivo omite Content-Type ou usa application/octet-stream. Um servidor Blossom inspecionaria os primeiros bytes com uma biblioteca mantida de tipos de arquivo, preservaria um tipo específico fornecido pelo cliente e usaria como fallback o tipo binário genérico quando a detecção falhasse. Isso manteria imagens, áudio, vídeo e arquivos produzidos por agentes renderizáveis sem tornar obrigatória a inspeção de bytes em todos os envios.

NAPs: convenções substituem trilhas numeradas enquanto contratos de captura e sistema de arquivos evoluem

O PR #87 remove a trilha numerada de protocolo entre napplets e mantém as capacidades do ambiente de execução em contratos nomeados enquanto as mensagens dos aplicativos convergem para URIs da convenção napplet:<archetype>/<intent>. A mudança incorporada de identidade de tópico separa um caminho de convenção estável e sem parâmetros de consulta dos dados do payload de cada mensagem, e o PR #90 aplica essa regra de transposição aos metadados de descoberta e dos manipuladores.

Dois rascunhos de NAP ampliam a fronteira do shell confiável. O PR #94 do NAP-CAPTURE mantém consentimento do microfone, permissão da plataforma, limites, retenção e encerramento no ambiente de execução, enquanto retorna um artefato de mídia sujeito a limites para um napplet em sandbox. O PR #88 do NAP-FS é a proposta paralela de sistema de arquivos virtual, com handles sujeitos a políticas em vez de caminhos irrestritos do host.

Marmot: a especificação define um estado final para o grupo

O PR #409 do Marmot adiciona um estado Disbanded autenticado e irreversível porque o próprio MLS não possui uma operação de exclusão de grupos. Um commit autorizado do administrador move um grupo para fora de Active, impede que branches antigas, mensagens e Welcomes o reativem e oferece aos grupos existentes um caminho explícito de compatibilidade antes que possam se dissolver. A revisão anterior das issues da especificação também conciliou autoridade do estado do grupo, convergência, pacotes de chaves, confirmações, regras de mídia, linguagem do registro e 200 issues de especificação rastreadas.

Gamma Markets: nenhuma mudança pública de especificação foi incorporada

O repositório da especificação Gamma Markets não registrou commits públicos nem atividade de pull requests de 21 a 28 de julho. Seus documentos publicados de ordens, liquidação e dados de mercado continuam sendo a referência atual; esta entrada sem mudanças mantém Gamma visível na revisão semanal de especificações.

Concord: capacidades de leitura e escrita podem se separar dentro de um único plano

O PR #12 do Concord continua sendo um rascunho aberto para planos nos quais nem todos os leitores devem ser escritores. Ele orienta o Control Plane para capacidades separadas de streams de leitura e escrita e esboça canais com escrita restrita, convites e escopos de troca de chaves. A chave de escrita funciona como barreira contra spam no rascunho, enquanto atores internos assinados e verificações da lista de membros continuam detendo a autoridade.

NWC: um método de carteira pode escolher entre BOLT11 e BOLT12

O PR #2 do NWC propõe métodos opcionais pay e receive para URIs de pagamento BIP-321. Um serviço de carteira pode anunciar suporte, escolher uma fatura BOLT11 ou oferta BOLT12 compatível em uma URI, rejeitar uma rede Bitcoin incompatível antes do pagamento e informar qual tipo de instrução usou. A proposta permanece fora do núcleo do NWC, para que carteiras sem suporte a BIP-321 ou BOLT12 não precisem implementá-la.

Seis anos de julhos do Nostr

Esta história de julho acompanha problemas recorrentes do Nostr: identificadores legíveis, filtragem de relays, dados portáteis de aplicativos, privacidade e interoperabilidade. Ao longo de seis anos, cada camada transforma uma correção pontual em infraestrutura compartilhada: os nomes se tornam perfis, os filtros se tornam contratos de aplicativos e o estado transportado por relays se expande de notas para salas e grupos ao vivo. Ela começa com a primeira implementação do NIP-05 e termina com a incorporação da descoberta endereçável deste mês, examinando em seguida as mudanças de julho que desenvolveram esses temas.

Julho de 2021

Em 19 de julho de 2021, o commit 1ce00bd do nostr-tools adicionou um módulo nip05.js e elevou o pacote à versão 0.5.0. Sua função keyFromDomain montava uma solicitação DNS TXT para _nostrkey.<domain>, enviava a consulta binária a um dos oito provedores de DNS-over-HTTPS em rotação e retornava a primeira chave da resposta. Assim, um cliente no navegador podia traduzir um domínio controlado por uma pessoa em uma chave pública sem operar um resolvedor DNS nem depender de um único provedor fixo.

Essa primeira abordagem resolveu a consulta, mas não os nomes dentro de um domínio, e sua fronteira de confiança abrangia o DNS e o resolvedor selecionado. A especificação NIP-05 moderna transferiu a descoberta para /.well-known/nostr.json, onde um domínio mapeia nomes locais para pubkeys e pode anexar relay hints. O código de 2021 registra a pressão de design anterior: as chaves públicas eram portáteis, mas as pessoas ainda precisavam de identificadores que pudessem ler, verificar e mover entre clientes.

Julho de 2022

Em 10 de julho, o commit 3771186 do NIP-12 limitou as consultas genéricas aos relays a tags de uma única letra. Essa decisão tornou filtros como #r, #g e #t úteis para referências de URL, geohashes e hashtags sem exigir que os relays indexassem todas as chaves arbitrárias de metadados. Dez dias depois, o primeiro rascunho de comentários web do NIP-20 usou diretamente esse modelo de consulta: um comentário kind 34 carregava uma URL normalizada de página web em uma tag r, permitindo que um site e clientes independentes recuperassem a mesma discussão nos relays.

Em seguida vieram políticas de relay e feedback social. O commit original do NIP-22 permitiu que os relays rejeitassem events cujo timestamp created_at fosse implausivelmente antigo, e o commit 8bef0e9 adicionou timestamps futuros à mesma política. Em 30 de julho, o commit dcbd504 do NIP-25 definiu reações kind 7 com tags de destino e e p; o commit seguinte atribuiu - a uma reação negativa, e o commit 6903ff5 tornou + a curtida genérica explícita. Juntos, esses commits especificaram a rejeição de timestamps por relays, a recuperação baseada em tags, comentários web e tags de reação para os clientes que adotaram os rascunhos.

Julho de 2023

Julho de 2023 levou a coordenação além das notas curtas. O rascunho sobre perda de chaves do NIP-37 explorou a aposentadoria irreversível de chaves, limiares de recuperação social e chaves substitutas definidas de antemão, recusando explicitamente chamar o resultado de rotação universal de chaves. Cinco dias depois, o NIP-53 introduziu atividades ao vivo endereçáveis kind 30311 e mensagens de chat kind 1311, oferecendo a streams, palcos e salas ao vivo um modelo compartilhado de event para hosts, participantes, status e conversas.

Os aplicativos também começaram a anunciar trabalho e comércio. O primeiro rascunho de Data Vending Machine descreveu solicitações de trabalho kind 68001, resultados kind 68002, ofertas, expirações, encadeamento e provedores concorrentes para tarefas como transcrição, resumo e tradução. Em 13 de julho, o rascunho de anúncios classificados adicionou ofertas endereçáveis kind 30402 com metadados de título, resumo, preço, localização e status. Esses rascunhos se tornaram depois NIP-90 e NIP-99, mas suas formas de julho já separavam uma solicitação ou anúncio do servidor que o exibia.

O roteamento de pagamentos também se tornou componível. A incorporação da divisão de zaps do NIP-57, de 31 de julho, transformou um único destino de zap em uma lista ponderada de pubkeys destinatárias e relay hints. Um cliente podia dividir um zap entre colaboradores, omitir destinatários sem peso quando alguns pesos estivessem presentes e mostrar a divisão antes do pagamento. A mudança padronizou uma representação em event assinado para destinatários ponderados de zap e relay hints, permitindo que clientes compatíveis apresentassem a divisão antes do pagamento.

Julho de 2024

Em 4 de julho, o commit c60ca88 do NIP-29 adicionou a ação de moderação de relay kind:9007 para criar um grupo. Seis dias depois, o NIP-70 definiu events protegidos: uma tag - instrui um relay a aceitar a publicação apenas do autor autenticado do event. Uma mudança ofereceu aos relays uma transição explícita de estado do grupo; a outra permitiu que os autores impedissem terceiros de republicar events assinados que, de outro modo, seriam válidos nos relays.

Em 16 de julho, um commit da especificação Cashu introduziu tanto as carteiras NIP-60 quanto os nutzaps NIP-61. O NIP-60 colocou metadados da carteira no kind 37375, provas não gastas em events kind 7375 criptografados e um histórico opcional de transações no kind 7376. O NIP-61 combinou as preferências de mint e relay do destinatário, no kind 10019, com nutzaps kind 7337 bloqueados por P2PK. O estado da carteira e os tokens ao portador podiam então circular pelos relays, enquanto o resgate ainda dependia das provas do mint Cashu e da prevenção cuidadosa de resgates duplicados.

Duas edições no fim de julho reforçaram o estado determinístico. O commit 9c54549 do NIP-01 exigiu IDs de event como critério de desempate após timestamps created_at iguais, para que os clientes pudessem ordenar conjuntos de resultados idênticos da mesma maneira. A incorporação da exclusão do NIP-09 esclareceu que solicitações kind 5 podem ter IDs de event ou coordenadas endereçáveis como alvo e deveriam incluir tags k que identifiquem os kinds que os relays deveriam excluir. As duas mudanças reduziram os pontos nos quais duas implementações corretas poderiam discordar.

Julho de 2025

A descoberta de ecash ganhou seu próprio diretório social em 16 de julho. O commit 1afb6da do NIP-87 definiu registros kind 38172 de mints Cashu, registros kind 38173 do Fedimint e recomendações kind 38000 que podem apontar para esses registros com relay hints. As carteiras podiam consultar recomendações de autores confiáveis antes de se conectar a um mint, enquanto a especificação alertava que a descoberta global sem filtros poderia direcionar os usuários para operadores maliciosos.

Uma semana depois, um rascunho especificou registros portáteis de events Nostr para mensagens de voz. O primeiro commit do NIP-A0 atribuiu o kind 1222 à raiz de uma mensagem de voz e o kind 1244 a uma resposta, transportando uma URL de áudio e metadados de mídia. A atualização de formato, de 27 de julho, recomendou Opus em um contêiner Ogg e padronizou uma forma de onda comprimida. Os clientes podiam trocar áudios curtos sem precisar concordar com um único gravador, host ou representação da forma de onda.

As mensagens privadas e as conexões de carteira acrescentaram então estados de protocolo para rastrear leituras, selecionar criptografia e acompanhar o andamento de pagamentos. O commit 3d76da3 do NIP-17 definiu um registro substituível kind 30016 cujas tags seen ordenadas permitem que o cliente diferencie mensagens lidas de lacunas que possa ter perdido. Em 31 de julho, a negociação de criptografia do NIP-47 permitiu que os serviços de carteira anunciassem NIP-44 v2 ou o NIP-04 legado, enquanto o commit de estados de transação adicionou os estados pending, settled, accepted, expired e failed. A entrega, a criptografia e o andamento do pagamento tornaram-se dados explícitos do protocolo em vez de inferência local.

Julho de 2026

Este mês de julho começou conectando endereços web comuns a consultas em relays. O commit 2f4b093 da descoberta endereçável define uma consulta /.well-known/nostr.json?ad=<path> cuja resposta contém um filtro Nostr e uma lista de relays. Um navegador comum ainda pode abrir a URL original como HTML, enquanto um cliente Nostr pode consultar o endpoint /.well-known/nostr.json?ad=<path> correspondente para obter um filtro e uma lista de relays que resolvem o endereço para um grupo, nsite, feed, event ou outro objeto nativo. O padrão retoma o problema de 2021 de converter domínios em chaves em uma camada mais ampla: uma única URL legível agora pode identificar tanto uma identidade quanto uma consulta.

O NIP-29 então evoluiu de grupos simples em relays para espaços estruturados. O commit de subgrupos, de 16 de julho, adicionou relações de pai e filhos ordenados; commits adjacentes adicionaram sufixos de códigos de convite, banners, instantâneos ordenados de itens fixados e itens fixados de events endereçáveis. Em 22 de julho, o esclarecimento sobre migrações e forks definiu quando os metadados transferem legitimamente um grupo para outro relay e quando uma branch ainda ativa constitui um fork independente. O identificador do grupo permaneceu simples, enquanto hierarquia, apresentação e mudanças de relay se tornaram estado explícito.

Duas edições menores esclareceram os limites de implementação. O commit f0af204 do NIP-46 exige que um assinante remoto retorne um erro para métodos desconhecidos ou não suportados, em vez de deixar o tempo limite do cliente expirar sem resposta. O commit 6d2979b do NIP-34 remove da descrição do event de pull request as orientações de hospedagem específicas do GRASP. Um oferece aos solicitantes uma resposta conclusiva; o outro impede que um event git portátil herde silenciosamente um protocolo de servidor.

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