Nostr Compass #28 | Nostr Compass

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

Esta semana: o Sprout muda de nome para Buzz e começa a publicar personas, equipes e registros de agentes gerenciados como eventos em relays do Nostr, com estado de leitura entre dispositivos e marcadores por mensagem substituindo o antigo modelo de fronteira de emblemas. O Napplets, da sandwich.farm, é lançado como um protocolo de limite de confiança para aplicativos Nostr componíveis distribuídos pelo Nostr e Blossom. O Conduit, um monorepo de marketplace com três aplicativos no Nostr (mercado para compradores, portal do comerciante e construtor de lojas, com diretórios próprios de NIPs e especificações no repositório), incorpora 17 PRs que reforçam o MVP do marketplace, passa a usar seu relay público por padrão e adiciona analytics que preservam a privacidade. O BitBlik entrega um protocolo de câmbio P2P de BLIK para Lightning por DMs cifradas do Nostr, com um coordenador que liquida atomicamente entre moeda fiduciária e invoices hold da Lightning. O Amethyst dá continuidade ao lançamento de carteiras, podcasts e exercícios da semana passada com Health Connect Workouts, Road Events, respostas recolhíveis, monitoramento da saúde da latência de relays com um classificador e uma correção de notarização no macOS. O Amber implementa a extensão de metadados de cliente do NIP-46 proposta na semana passada, exibindo ícones e identidade de aplicativos nativos nas telas de solicitação do assinador. O Haven lança compartilhamento privado de localização sobre o protocolo de mensagens cifradas Marmot. O CodeDeck permite controlar pelo celular sessões do Claude Code em seu laptop através de relays Nostr cifrados, depois reduz o pareamento a uma única leitura de QR e adiciona seleção de modelo por sessão. O Grain entrega uma biblioteca cliente Nostr importável em Go que implementa o modelo outbox. Mostro Core, Wisp e Dark Wisp, Citrine, FIPS, Kubo (canais do YouTube selecionados pelos pais e um feed infantil obrigatório controlado por confiança) e Pollerama (uma pontuação de web of trust, um mecanismo de relay no dispositivo e uma faixa “Pessoas que talvez você conheça”) lançam patches de acompanhamento. O trabalho ainda não lançado abrange um coordenador MLS baseado no navegador da sandwich.farm, a rodada de melhorias de UX do nostter, a correção NIP-46 entre projetos e a reformulação do compositor no Zap Cooking, o ciclo de escrow Cashu do Shopstr, divine.video e Nostur. Entre os novos projetos acompanhados estão o Social Agents Prototype, o PRana para triagem de issues de git sobre Nostr e o routstr-chat. No protocolo, o NIP-99 recebe uma proposta de checkout e escrow on-graph que se conecta diretamente ao trabalho de comércio do Conduit, BitBlik e Shopstr. Como este é o último Compass de junho, a edição termina com Seis anos de junhos do Nostr.

Histórias principais

Amethyst v1.12.1 a v1.12.6 dão continuidade ao lançamento da v1.12.0

O Amethyst seguiu o lançamento da v1.12.0 da semana passada com seis patches rápidos entre quarta e sexta-feira. A v1.12.1 adiciona Health Connect Workouts e uma ação Share-as-Image, além de tornar determinística a flag Active do Tor para que o callback de bootstrap não possa disputar o gate. A v1.12.2 adiciona Road Events e respostas recolhíveis, a v1.12.3 traz monitoramento da saúde da latência de relays com um classificador e uma interface de dashboard, além de uma correção de notarização no macOS, e da v1.12.4 à v1.12.6 chegam rodadas de tradução pelo Crowdin e automação dos créditos de tradutores.

Sprout muda de nome para Buzz e publica personas, equipes e agentes gerenciados como eventos em relays

O Sprout, workspace auto-hospedável da Block onde humanos e agentes de IA colaboram nos mesmos canais e cada mensagem, reação, etapa de workflow, aprovação de revisão e evento git é escrito como um evento Nostr assinado, mudou de nome para Buzz nesta semana. O GitHub agora redireciona o antigo slug block/sprout para block/buzz; o repositório, a licença e a direção do produto não mudaram. Todas as referências ao Sprout em edições anteriores tratam do mesmo projeto.

A semana trouxe trabalho substancial no produto junto com a mudança de nome. Personas, equipes e registros de agentes gerenciados agora são publicados como eventos em relays do Nostr pelo PR #1189, permitindo que a mesma identidade de agente apareça em vários workspaces e logs de auditoria sem duplicar estado. Um novo painel no desktop mostra atestados de proprietário NIP-OA nos perfis (PR #1198); a fronteira de emblemas não lidos em threads de canais foi substituída por marcadores de leitura por mensagem, para manter contagens corretas entre dispositivos (PR #1178); e a caixa de entrada passa a mostrar atribuição de autor e origem nos eventos de lembrete (PR #1176).

Canais temporários agora expiram em sete dias por padrão (PR #1182); substituições de relay por agente respeitam o relay configurado antes de recorrer ao padrão do workspace (PR #1131); e a compilação para Windows agora inclui um conjunto completo de ferramentas do Git for Windows para a ferramenta de shell (PR #1145).

Napplets: aplicativos Nostr componíveis com um limite de confiança definido

A sandwich.farm anunciou o napplet.run nesta semana como um protocolo para applets Nostr componíveis, ou napplets: pequenos programas que fazem uma única coisa, rodam em ambientes isolados e são resolvidos pelo Nostr e Blossom usando o mesmo formato de evento dos nsites. O projeto é distribuído em três repositórios: napplet/web, que contém os pacotes web e criou 51 tags de versão de subpacotes nesta semana em um lançamento coordenado (@napplet/core, @napplet/sdk, @napplet/nap, @napplet/shim, @napplet/conformance); napplet/naps, a linha de especificações NAPs, com 15 PRs incorporados; e kehto/web, o runtime web, com 41 PRs incorporados e um playground em kehto.github.io/web/playground. O PR de especificação correspondente é o NIP-5D #2303, aberto por dskvr (sandwich.farm).

A premissa arquitetônica é um limite de confiança definido na camada de protocolo. Um shell intermedeia operações perigosas (assinatura, acesso a chaves e escrita em relays), um runtime cuida da implementação e da UX de nível mais alto, e os napplets permanecem portáteis, descartáveis e mais difíceis de serem capturados por um único host. Napplets podem se comunicar entre si no mesmo shell, e o projeto evita lock-in de runtime. O autor situa os napplets em diálogo com o NMP, de Pablof7z, e o Tiles, da Soapbox, como abordagens paralelas para o mesmo problema, e observa que o suporte do Amethyst v1.12.6 ao NIP-5A e ao NIP-5D dá aos napplets pelo menos um cliente em produção no lançamento. Há também um fio histórico: o antigo napp.run da sandwich.farm, um protótipo de aplicativo nativo NIP-07, e o navegador dryft, derivado do Thorium, ajudaram a informar o desenho atual antes de serem deixados de lado.

Conduit reforça o MVP do marketplace e passa a usar seu relay público por padrão

O Conduit é o monorepo de marketplace com três aplicativos em conduit.market, Market para compradores, Merchant Portal e Store Builder, sob a organização Conduit-BTC. O repositório contém diretórios próprios nips/ e specs/ que definem primitivas de comércio Nostr específicas do Conduit, e por baixo roda a extensão Scope-2 de khatru Conduit-BTC/conduit-relay. Os dois repositórios foram abertos no começo deste ano; nesta semana, o projeto incorporou 17 PRs que reforçam o MVP do marketplace.

Os PRs entregues se concentram na correção do marketplace: estados de segurança de anúncios (PR #110) e reforço de preços de produtos e zonas de envio no lado do comerciante (PR #115). No lado do relay, o PR #102 corrige a detecção de capacidades de comércio, o PR #112 ignora dicas inseguras de relays de terceiros e o PR #128 define o domínio público do relay do Conduit como padrão para novos clientes. Analytics que preservam a privacidade chegam nos PR #109 e PR #129, e uma atualização do dompurify fecha um alerta OSV (PR #116). O trabalho faz parte de uma onda mais ampla de comércio NIP-99 nesta semana: o PR #2323 propõe uma camada de checkout on-graph para mercados NIP-99 que cobre fluxo de pedidos, escrow e disputas; a antiga Gamma Markets Market Spec, que estende o NIP-99 para e-commerce completo, torna-se a camada de especificação sobre a qual Conduit e outros constroem; e o Shopstr entregou um ciclo de escrow Cashu na mesma semana.

BitBlik lança um protocolo P2P de câmbio de BLIK para Lightning sobre o Nostr

O BitBlik foi aberto nesta semana como um protocolo peer-to-peer de câmbio BLIK ↔ Lightning construído sobre o Nostr. BLIK é o sistema polonês de pagamentos instantâneos emitido por bancos; o coordenador do BitBlik liquida atomicamente entre moeda fiduciária BLIK, paga pelos takers, e invoices hold da Lightning, financiadas pelos makers, com o ciclo da negociação rodando sobre o Nostr. O aplicativo Flutter, a CLI e o coordenador compartilham um pacote core, e o projeto é distribuído pelo monorepo bit-blik/bitblik no GitHub, pela versão web em www.bitblik.app e pelo aplicativo app.bitblik no Zapstore.

O protocolo usa mensagens diretas Nostr cifradas pelo NIP-44 para RPC entre cliente e coordenador. Ofertas são publicadas como eventos substituíveis parametrizados no kind 38383, solicitações RPC no kind 25195, respostas RPC no kind 25196 e atualizações de status no kind 25197. O coordenador retém uma invoice hold da Lightning enquanto um taker envia um código BLIK, libera a preimage quando a transferência BLIK é confirmada e encaminha a liquidação da invoice ao maker.

Lançamentos com tag

Amber v6.2.2 implementa metadados de cliente NIP-46

O Amber, principal assinador remoto NIP-46 para Android, mantido por greenart7c3, lançou a v6.2.2 na mesma semana em que o PR correspondente da especificação foi incorporado. A versão exibe ícones de aplicativos nativos e os novos campos de metadados de cliente nas telas de solicitação e na lista de aplicativos, persiste metadados de cliente a cada conexão e captura o ícone e o nome do aplicativo nativo ao conectar e aceitar. A mudança se conecta diretamente ao PR #2381 do NIP-46, de DocNR, que adiciona metadados opcionais de cliente à solicitação de conexão para que os assinadores exibam nome e ícone significativos de quem solicita. O Amber v6.2.2 também adiciona suporte ao kind de evento 30618 e separa relays padrão e de conexão na tela Active relays.

A versão reforça a superfície de segurança do assinador. Corpos de solicitações e respostas NIP-46 decifrados não são mais enviados aos logs, e payloads de cifragem e decifragem são armazenados como texto cifrado e decifrados sob demanda. Toda saída do logcat é limitada a BuildConfig.DEBUG, chamadores do navegador, com pacote nulo, são forçados a sempre pedir autorização, e cópias de nsec, ncryptsec e seed words para a área de transferência são marcadas como confidenciais e apagadas após um intervalo. Exclusões explícitas de backup e extração de dados foram adicionadas como defesa em profundidade. A versão também corrige um crash causado por rolagem aninhada em Active relays, um crash de chave duplicada em LazyColumn provocado por uma corrida na deduplicação de solicitações bunker e uma corrida de EOSE na verificação de atualizações.

O Haven foi aberto nesta semana como um aplicativo privado e resistente à censura de compartilhamento de localização para Android e iOS, executado sobre o Nostr com o protocolo Marmot. O repositório publicou cinco versões entre a v0.1.0 e a v0.1.4 em quatro dias, os primeiros lançamentos de um projeto novo. O Haven é desenvolvido em Dart e Flutter e publicado no Zapstore como um aplicativo assinado pelo desenvolvedor. Marmot, a camada de mensagens com cifragem ponta a ponta baseada em MLS para o Nostr, fornece o estado de grupo e a distribuição de texto cifrado; o Haven estende esse padrão das mensagens ao compartilhamento de localização, com o estado cifrado de cada grupo transportando as atualizações de localização que o grupo consentiu em compartilhar.

CodeDeck: programação agêntica remota sobre o Nostr

O CodeDeck foi aberto nesta semana como uma interface de programação agêntica com várias sessões para Android e desktop, construída com Tauri v2, React 19 e um backend Rust. Ela permite controlar pelo celular sessões do Claude Code executadas em um laptop por relays Nostr cifrados. O projeto lançou a v2026.06.17, a v2026.6.18 e a v2026.6.20 no mesmo intervalo de quatro dias. O modelo de transporte usa o Nostr como plano de controle cifrado: um celular com CodeDeck publica comandos como eventos cifrados, a ponte executada junto ao laptop subscreve esses eventos, e o laptop publica a saída da sessão de volta pelos mesmos relays.

A v2026.06.17 incorpora a malha FIPS do nostr-vpn como serviço VPN do aplicativo Android, para que um laptop possa compilar, instalar, iniciar e controlar builds de desenvolvimento em um celular físico de teste de qualquer lugar, com o CodeDeck como único software instalado no aparelho de teste. A v2026.6.18 reduz o pareamento e o convite à malha a uma única leitura de QR, e a v2026.6.20 adiciona seleção de modelo por sessão para que cada sessão comece com o modelo escolhido.

Grain v0.8.0-rc1 entrega um mecanismo completo de cliente Nostr

O Grain, relay em Go mantido por 0ceanSlim, criou a tag v0.8.0-rc1 e agora é ao mesmo tempo um relay Nostr e a biblioteca cliente Go importável sobre a qual ele próprio é construído. Enquanto a linha v0.7.x se concentrou em operar o relay pelo navegador, a linha v0.8 entrega client/core, um mecanismo independente e puro em Go de cliente Nostr baseado no modelo outbox, sem dependências de cgo ou HTTP. O mecanismo mantém um pool compartilhado de relays, resolve as listas de relays de cada usuário e encaminha toda leitura e publicação pelo modelo gossip / outbox: as notas de um usuário são lidas de seus relays outbox, e uma resposta publicada chega aos relays inbox do autor do conteúdo original. O frontend web do Grain agora é o consumidor de referência dessa biblioteca, então a interface funciona como aplicativo e como exemplo completo para projetos Go que a adotem.

A versão inclui cifragem nativa NIP-44 nas versões v2 e v3, autenticação AUTH de relay NIP-42, listas de relays NIP-65, NIP-17, NIP-51 e NIP-37, tags de cliente NIP-89 e suporte a mídia por Blossom e NIP-96. Aplicativos Go que antes precisavam reimplementar o roteamento por relays agora podem usar import diretamente no mecanismo.

Mostro Core v0.13.1 dá continuidade ao Protocolo v2

O Mostro Core lançou a v0.13.1 como continuação da implantação do Protocolo v2 da semana passada, introduzindo uma variante de erro PriceTooStale para o contrato de feed de preços do protocolo. No daemon, nesta semana, o PR #752 faz IDs de ordem inválidos aparecerem aos clientes como erro CantDo(NotFound) em vez de serem descartados silenciosamente; o PR #785 faz a versão interna do protocolo acompanhar o transporte ativo; o PR #778 entrega a fase 3 do provedor de câmbio fiduciário El Toque para CUP e MLC; e o PR #782 renomeia a tag de informação NIP-33 protocol_versions para protocol_version, alinhando-a à especificação.

Wisp v1.1.2 e a variante Dark Wisp

O Wisp, cliente Android de barrydeen construído em Kotlin e Jetpack Compose, lançou a v1.1.2. Ela mantém separadas as etapas de envio para si mesmo na ordem determinística de transações (PR #586), cria players de vídeo inline de forma lazy para sobreviver a notas com muita mídia (PR #592), corrige uma ConcurrentModificationException no conjunto de relays de eventos (PR #595) e corrige a medição intrínseca do conteúdo de balões de chat para evitar um crash de SubcomposeLayout (PR #596). A versão também entrega um filtro incremental de feed com pontuação de spam fora do lock. A equipe do Wisp publicou também o Dark Wisp v1.1.0 no Zapstore nesta semana, uma variante multimoeda que adiciona alvos de zap em ZEC, DASH, BCH e LTC, além de um modo anônimo.

Citrine v3.0.1

O Citrine, relay Nostr local para Android de greenart7c3, lançou a v3.0.1 com uma única correção: cancelar o registro de um receiver Pokey que não estava registrado não derruba mais o relay.

FIPS v0.4.0-rc2

O FIPS, Free Internetworking Peering System, criou a tag v0.4.0-rc2 como release candidate para validar o empacotamento sobre o formato de fio v0.3.x. A linha v0.4.0 adiciona um transporte Nym mixnet e descoberta mDNS opcional na LAN para alcançar peers, reformula o plano de dados para maior throughput em um único nó e menor uso de CPU por pacote, retira a superfície de leitura do operador do caminho crítico do plano de dados para que a observabilidade continue responsiva sob carga, entrega uma TUI fipstop refeita e reforça o rekey de FMP e FSP para ocorrer sem interrupção sob perda de pacotes. Esta é uma release candidate; o lançamento estável da v0.4.0 estava provisoriamente marcado para 2026-06-21.

Kubo v2026.06.12 e v2026.06.20 restringem o feed infantil controlado por confiança e adicionam YouTube selecionado pelos pais

O Kubo, alternativa nativa do Nostr ao YouTube Kids criada por JeroenOnNostr sobre o Trust Extended Permissions Protocol (TEPP), lançou duas versões nesta semana. A v2026.06.12, com versionamento por calendário e versionCode derivado no formato YYYYMMDD, torna obrigatório o feed infantil controlado por confiança: cada publicação, perfil, reação e repost que a criança pode ver ou com que pode interagir agora passa pelo TEPP, limitado às pessoas que os pais admitiram. Novas instalações começam com o controle de confiança ativado e o círculo da criança preenchido durante o onboarding, para que o feed seja seguro desde a primeira abertura. A versão também entrega chat gerenciado em grupo para os pais, encaminha eventos de confiança ao conjunto privado de relays da família e falha de forma fechada, sem mostrar nada, em vez de vazar conteúdo não aprovado quando os dados de confiança não podem ser carregados.

A v2026.06.20 adiciona canais do YouTube selecionados pelos pais: eles podem buscar um canal e adicioná-lo ao feed infantil, para que as crianças vejam apenas vídeos de canais aprovados, com um caminho rápido por HTTP e interface otimista substituindo o processo de cerca de dez segundos. A versão também remove a opção de desativar o Trust Extended Permissions, pois o projeto é construído em torno da confiança obrigatória e o controle agora fica sempre ligado; adiciona uma página dedicada de suporte; corrige @mentions no chat em grupo para que marcar alguém mostre o @nome clicável em vez de um nostr:npub1… bruto; adiciona autocompletar de menções; e corrige a publicação de confiança para usar como gate o estado real de aplicação da regra, e não uma flag espelho. As duas versões são acompanhadas pelo Zapstore como o aplicativo Android com.kubo.app, assinado pelo desenvolvedor.

Pollerama v1.9.0 a v1.9.4 adicionam pontuação de web of trust, mecanismo de relay no dispositivo e uma faixa “Pessoas que talvez você conheça”

O Pollerama, de abh3po, cliente de enquetes e feeds Nostr da família Form* em pollerama.fun, lançou cinco versões no Zapstore nesta semana. A v1.9.0 traz um novo mecanismo de relay no dispositivo: um relay local integrado armazena tudo o que o usuário já viu e responde ao aplicativo primeiro pelo cache local, para que feeds, perfis e threads carreguem imediatamente, mesmo offline, e permaneçam sincronizados com a rede em segundo plano. Todo o tráfego de relay, leituras e escritas, passa por esse mecanismo fora da thread principal, e notas, perfis, reações e zaps já carregados vêm diretamente do armazenamento local, sem uma nova busca.

A v1.9.2 corrige feeds Home e Notes, e qualquer visão Following ou Network, que às vezes não mostravam nada ao iniciar ou retomar o aplicativo. Isso é feito mantendo a lista de seguidos em cache independentemente do mecanismo de sincronização. A versão também faz notas compartilhadas dentro de DMs carregarem de forma confiável, buscando a nota referenciada pelas dicas de relay mesmo quando o usuário não segue o autor, e adiciona um painel Network nas configurações que mostra conexões a relays, tamanho do cache e estado de sincronização, com controles para reconectar ou limpar o cache local. A v1.9.3 corrige um crash na inicialização e uma regressão de carregamento no feed Home.

A v1.9.4 introduz uma pontuação de confiança baseada na web of trust nos perfis, isto é, quantas pessoas que você segue também seguem aquela pessoa, exibida como um chip de rede, e uma faixa “Pessoas que talvez você conheça”, com sugestões tiradas de sua web of trust e classificadas por quantas pessoas seguidas também as seguem. As configurações de rede agora mostram o tamanho da web of trust e a hora do último cálculo, com um botão para recalcular sob demanda. As pontuações de confiança e recomendações são calculadas em segundo plano pelo worker da web of trust para não bloquear o aplicativo.

Lançamentos menores com tag

O nogringo/nostr-mail-client v0.13.1 restaura o login por aplicativo assinador NIP-55 com Amber, Aegis e Primal, e deixa de pedir repetidamente que aplicativos assinadores assinem contatos. O Cameri/nostream v3.0.0 remove unsafe-inline da fábrica do aplicativo web e implementa nonces de script. O LaWallet NWC v1.0.0 chega ao primeiro 1.0 do projeto com ativação de cartões por links QR compartilháveis, reconhecimento de Remote Wallet e provisionamento automático de Lightning Address. Do Formstr Nostr Calendar v2.0.0 ao v2.0.2, as versões adicionam um PWA, corrigem eventos substituíveis offline (PR #194) e vinculam métodos do assinador para que o envio de formulários privados funcione (PR #199). Lançamentos menores de Spl0itable/NYM, codeswot/ZapBook, 77elements/noornote, mattn/nostr-relay, mattn/algia, mouse484/astraea, dergigi/boris, fiatjaf/nak, Spl0itable/nosflare e nostrord/nostrord completam a semana.

Mudanças ainda não lançadas

Cordn Ad-hoc CVM: um coordenador MLS baseado no navegador

O Cordn Ad-hoc, novo aplicativo web da sandwich.farm, foi aberto ao público nesta semana como um coordenador MLS executado em uma aba do navegador para grupos Cordn ad hoc. O padrão é incomum: uma aba do navegador executa o processo coordenador Nostr ContextVM, publica sua pubkey de coordenador, recebe solicitações MCP por relays do Nostr e armazena key packages MLS, welcomes, solicitações de entrada e mensagens de grupo no armazenamento do navegador, sem backend. O aplicativo impede que vários coordenadores com a mesma pubkey sejam executados ao mesmo tempo e fornece ao operador um log de depuração com eventos Nostr brutos, solicitações decodificadas e heartbeats de instâncias.

SnowCait/nostter entrega 19 PRs de melhorias de UX

O nostter, cliente web Nostr de SnowCait, incorporou 19 PRs nesta semana sem criar uma versão. A substituição de nostrapp.link por app-manager.nostter.app (PR #2234) e a inclusão de deck.nostter.app na allowlist de frame-ancestors (PR #2233) consolidam a superfície do projeto sob o domínio nostter.app. Eventos substituíveis das pessoas seguidas passam a ser armazenados em cache no IndexedDB (PR #2231), e o estado seen-on do relay recupera a reatividade com opções separadas de seen-on e via (PR #2230).

Zap Cooking corrige um bug NIP-46 entre projetos e reformula o compositor

O Zap Cooking, cliente de compartilhamento de receitas no Nostr, incorporou 16 PRs nesta semana. A mudança de maior alcance é o PR #452: assinadores remotos do Primal marcavam eventos com a própria pubkey do assinador, o que quebrava uploads, zaps e autenticação para qualquer cliente que encaminhasse pelo Primal. O Zap Cooking identificou e corrigiu esse caminho; a correção é local ao cliente, mas o bug existe em todo o espaço do NIP-46. O compositor foi reconstruído no PR #458 com contador regressivo, uma interface unificada de resposta e comentário e abas Write e Preview. Três correções de SSR, nos PR #460, PR #461 e PR #462, junto com o PR #454, estabilizam as rotas de perfis e receitas. A experiência de exploração recebe fileiras que podem ser roladas por arraste, um cursor de avatar com link para o perfil e uma correção nas abas fixas de comunidades (PR #456).

Shopstr entrega um ciclo de escrow Cashu e ferramentas para vitrines

O Shopstr, marketplace NIP-99, incorporou uma série de PRs substanciais nesta semana. O PR #512 implementa um ciclo completo de escrow Cashu P2PK para o marketplace, conectado à onda mais ampla de comércio da mesma semana pelo PR #2323 do NIP-99, a proposta de camada de checkout on-graph, e pelo lançamento do Conduit. Ferramentas de leitura chegam no PR #543 para listar empresas, obter detalhes de uma empresa, recuperar uma vitrine e consultar a reputação de um vendedor. O PR #229 adiciona suporte para colar URLs de imagens de perfis e lojas, e o PR #359 atualiza a busca de estatísticas do marketplace para incluir um timestamp.

Trabalho no divine.video para dispositivos móveis e desktop

O divine.video, cliente de vídeos curtos em loop de rabble que restaurou arquivos do Vine, incorporou nesta semana PRs concentrados em reprodução e edição: vídeos endereçáveis são deduplicados no feed (PR #5465); filtros locais de tags Nostr agora fazem correspondência exata para evitar resultados indevidos (PR #5463); o editor de vídeo recupera rascunhos com camadas de stickers sem travar (PR #5474); e o emblema Messages conta chats não lidos de pessoas seguidas que ainda não receberam resposta (PR #5473).

Nostur entrega metadados de cliente NIP-46 e correções de atualização de DMs

O Nostur, cliente iOS de Fabian, incorporou quatro PRs no repositório canônico depois do lançamento 1.29.0 da semana passada. O PR #74 adiciona metadados de cliente às solicitações de conexão com bunker NIP-46, no mesmo formato proposto por DocNR e entregue pelo Amber v6.2.2 nesta semana. Os PR #75 e PR #76 corrigem caminhos de atualização de DMs e recuperação ao voltar ao primeiro plano depois de uma transição do iPhone, e o PR #78 adiciona leitura de QR à configuração personalizada de NWC.

Novos projetos acompanhados e descobertos

O Social Agents Prototype é uma ferramenta experimental de IA construída sobre o Nostr que explora a comunicação descentralizada entre agentes. Os agentes transmitem perguntas atômicas pela rede, apenas agentes relevantes respondem, e toda mensagem enviada ou recebida passa por um gate de aprovação humana antes do trânsito. O autor é Sruly Rosenblat. O projeto ocupa o mesmo espaço de colaboração entre agentes que Buzz e NIP-100 SNIN nesta semana, mas adota um formato diferente: o Social Agents Prototype modela os agentes como participantes que transmitem e escutam, e cujas mensagens precisam ser aprovadas por uma pessoa. Várias abordagens paralelas ao mesmo problema aparecem nesta semana.

PRana: uma lista de trabalho para issues NIP-34

O PRana, de DocNR, é uma lista de trabalho de issues NIP-34 abertas corretamente em repositórios opt-in de git sobre Nostr. A ferramenta fica uma camada acima da pilha de git sobre Nostr: consome eventos de issue NIP-34 dos repositórios participantes e os apresenta como fila de triagem. O lançamento chega na mesma semana em que o PR #2384 do NIP-34 propõe remover a tag maintainers para resolver problemas de expiração, o que afeta diretamente como ferramentas como o PRana determinam a autoridade de issues entre repositórios.

routstr-chat: acesso local a LLMs pelo protocolo Routstr no Nostr

O routstr-chat, da equipe Routstr, é uma interface de chat totalmente local que usa o protocolo Routstr para acessar qualquer modelo LLM pelo Nostr. O protocolo Routstr encaminha solicitações de inferência por anúncios de provedores publicados no Nostr, no kind 38421, e liquida pagamentos com Cashu, como descrito na Newsletter #20. O cliente de chat é a superfície voltada ao usuário sobre esse protocolo; o daemon de roteamento Routstrd cuida da descoberta e do pagamento, enquanto o aplicativo oferece a interface de conversa.

Trabalho de protocolo

Atualizações de NIPs

A atividade de NIPs nesta semana foi excepcionalmente intensa: duas incorporações e uma onda de propostas abertas substanciais.

Metadados de cliente NIP-46 chegam ao Amber e Nostur

O PR #2381 do NIP-46, proposto pelo Clave na semana passada, agora tem implementações em produção nos dois lados. O Amber v6.2.2 lê o novo campo opcional optional_client_metadata nas solicitações de conexão com bunker e exibe ícones e metadados de aplicativos nativos nas telas de solicitação e na lista de aplicativos. O PR #74 do Nostur adiciona o campo no lado do cliente. Juntos, os três projetos fecham a lacuna de identidade no pareamento com bunker: um pareamento bunker:// agora transporta os mesmos name, url e image que um aplicativo já podia anunciar por nostrconnect://.

`signevent` no NIP-86 e um evento complementar de papéis do relay

O PR #2389, de staab, incorporou uma operação signevent ao NIP-86, a API de gestão de relays, permitindo que administradores gerenciem eventos NIP-43 em nome do relay. A proposta aberta complementar, o PR #2390, de staab, define um evento de papéis do relay para que relays possam declarar definições de papéis e administradores possam atribuir ou remover membros desses papéis. Os dois PRs foram projetados para se compor: o NIP-86 fornece as operações aos administradores, e o evento de papéis fornece o modelo de autorização.

NIP-99: camada de checkout on-graph para marketplaces

O PR #2323, de Colabonate, é o principal elo central da semana. A proposta é apresentada como um pedido de feedback de design e identifica duas lacunas na pilha do NIP-99 e da Gamma Market Spec: um fluxo de checkout que vive on-graph, com estado após o buy-now, criação de pedido, pagamento e confirmação de entrega como eventos Nostr públicos e endereçáveis que qualquer cliente pode ler; e escrow com resolução de disputas para o subconjunto de transações em que sinais de web of trust não bastam, como itens de alto valor, contrapartes em uma primeira negociação, marketplaces anônimos e entregas físicas. A proposta fecha os silos entre clientes nos marketplaces da mesma forma que o NIP-99 fechou silos de anúncios. Ela chega na mesma semana que o lançamento do Conduit, que traz diretórios próprios nips/ e specs/; o PR #512 do Shopstr, com um ciclo completo de escrow Cashu; o BitBlik, câmbio P2P BLIK ↔ Lightning com primitivas próprias de escrow; e o repositório independente da Gamma Markets Market Spec, que entrou no acompanhamento ativo.

NIP-34: remoção da tag maintainers para resolver problemas de expiração

O PR #2384, de dhalsim, remove a tag maintainers dos anúncios de repositório NIP-34, resolvendo a issue #2382. A tag maintainers não tinha uma semântica definida de expiração, o que dificultava para ferramentas posteriores saber quando uma atribuição de mantenedor ainda era válida. A mudança tem amplo alcance: afeta patches do flotilla-budabit, o único repositório NIP-34 acompanhado com atividade substancial de patches nesta semana; a configuração de distribuição NIP-34 em oito repositórios da equipe Iris; o espelho NIP-34 do BitBlik; o novo espelho NIP-34 do Amber; e a ferramenta de lista de issues PRana, de DocNR. Entre os revisores do PR estão DanConwayDev (ngit), vitorpamplona (Amethyst), TheAwiteb e chebizarro.

Estados de grupos NIP-29, trabalho em andamento

O PR #2372, de dtonon, propõe um enquadramento de estados de grupos para o NIP-29, compartilhado como trabalho em andamento para receber feedback. Isso dá continuidade à evolução do NIP-29 coberta na edição #27, agora com um novo enquadramento.

Stories NIP-79 e Reels Feed NIP-76, ambos de anaskmh

Duas especificações de mídia curta do mesmo autor chegaram nesta semana. O PR #2386 propõe NIP-79 Stories: slides efêmeros de foto, vídeo e texto em tela cheia que expiram após 24 horas, com kind 19 para slides individuais, kind 34237 como evento endereçável contendo tags e ordenadas para sequenciar histórias com vários slides e um recibo opcional de visualização no kind 15750 que preserva a privacidade. O PR #2385 propõe o NIP-76 para um Reels Feed de vídeos curtos. As duas são especificações paralelas ao que clientes de vídeo existentes, como o divine.video, já entregam, não implementações dele.

kind 1111 como resposta a notas kind 1

O PR #2358, de zhoreeq, remove a linha do conjunto de NIPs que antes desaconselhava o uso de respostas de threads de comentários kind 1111, do NIP-22, em notas kind 1 (issue #2250). A mudança é pequena no diff, mas ampla no efeito: qualquer cliente que queira usar o formato de comentários encadeados do NIP-22 em notas comuns kind 1 da timeline agora tem suporte explícito para isso.

Seis anos de junhos do Nostr

O histórico do repositório em junho acompanha o Nostr desde a infância do protocolo até uma base para aplicativos componíveis. Em 2021, o trabalho ainda cabia em um único repositório de protocolo. Em 2022, o processo de padronização e os primeiros clientes relevantes se tornaram projetos separados. A onda pública de 2023 tornou urgentes os relays, os pagamentos e identidades mais ricas; 2024 substituiu atalhos iniciais de assinatura e mensagens; 2025 levou esses contratos a grupos privados, colaboração por git, mídia e comércio; e 2026 lançou produtos que usam o Nostr como uma camada dentro de workspaces de agentes, corretoras e ferramentas para desenvolvedores. A progressão parte da prova de que eventos assinados podem circular por relays e chega ao ponto em que esse fato se torna um detalhe de implementação.

Junho de 2021: infância do protocolo

O Nostr tinha cerca de sete meses. O post original sobre o protocolo, de fiatjaf, e o repositório fiatjaf/nostr ainda continham quase todo o projeto público. Um pequeno grupo de desenvolvedores podia revisar cada mudança, e a implementação de referência era um script Python. Ainda não era um ecossistema de clientes; era a tese de que usuários podiam assinar eventos e escolher relays sem que uma plataforma lhes atribuísse identidade.

Não havia um repositório dedicado de NIPs, então propostas e exemplos de implementação ainda compartilhavam o histórico principal do protocolo. Esse escopo compacto era uma vantagem naquele estágio: alguém começando a implementar podia entender o protocolo de ponta a ponta. O custo era que cada novo comportamento ainda dependia do mesmo pequeno grupo, limite que a separação do repositório e a onda de clientes de 2022 começariam a remover.

Junho de 2022: formação do repositório de NIPs

Em meados de 2022, o Nostr já tinha proponentes suficientes para justificar o repositório separado nostr-protocol/nips, criado em maio. Cerca de vinte especificações cobriam o formato básico de eventos, listas de seguidos, DMs cifradas, metadados de relays e identificadores bech32. Retirar os documentos do repositório de código original mudou a governança do projeto: clientes podiam evoluir de forma independente, enquanto o comportamento compartilhado no fio recebia propostas e revisões explícitas.

Os primeiros clientes web públicos, incluindo Astral e Anigma, estavam disponíveis em formas iniciais, e o repositório do Damus, de William Casarin, avançava rumo à distribuição pelo TestFlight. A base de usuários ainda era pequena e formada principalmente por desenvolvedores, mas o sistema agora tinha duas superfícies multiplicadoras: mais pessoas podiam criar aplicativos sem manter a especificação, e mais pessoas podiam melhorar a especificação sem serem responsáveis pelo cliente original.

Junho de 2023: aumento da adoção após o Damus

Em junho de 2023, a onda pública que seguiu o lançamento do Damus na App Store tinha mudado o problema de engenharia. Primal e Iris construíam para pessoas que não haviam acompanhado as primeiras conversas sobre o protocolo, enquanto o strfry oferecia um relay de alto desempenho para operadores com mais tráfego. A rede não precisava apenas de mais implementações; precisava de clientes e relays que continuassem responsivos à medida que cresciam os usuários, os seguidos e os históricos de eventos.

O trabalho de protocolo se concentrou, portanto, em roteamento e transferência de valor. As listas de relays NIP-65 deram ao modelo outbox emergente uma fonte portátil da verdade, enquanto os zaps NIP-57 conectaram eventos e identidades a recibos Lightning. A mudança de estágio foi prática: identidade e publicação atraíram usuários, mas o roteamento seletivo por relays e a interoperabilidade de carteiras permitiram que a rede maior se comportasse como algo além de um único feed público sobrecarregado.

Junho de 2024: assinadores, gift wrap e a atualização das mensagens

Em junho de 2024, a assinatura começava a sair dos clientes individuais. A especificação NIP-46, o nsecBunker e o Amber deram a aplicativos web e Android formas de solicitar assinaturas sem importar a chave secreta do usuário. Isso inverteu uma premissa inicial: portabilidade já não significava copiar um nsec para cada cliente, mas permitir que assinadores especializados aplicassem um limite ao redor dele.

As mensagens mudaram pelo mesmo motivo. O NIP-17 combinou a cifragem NIP-44 com gift wrapping NIP-59 para reduzir os metadados expostos pelo NIP-04, enquanto o NIP-89 permitiu que clientes recomendassem handlers para tipos de eventos que não renderizavam. As discussões sobre MLS sobre Nostr começaram nesse ambiente. Privacidade e descoberta de aplicativos se tornavam contratos entre clientes, preparando o terreno para grupos privados e aplicativos mais ricos e específicos a tipos de eventos, em vez de um único cliente tentar conter todos os recursos.

Junho de 2025: Marmot, maturidade do git sobre Nostr e a longa cauda de clientes

Em junho de 2025, o MLS sobre Nostr já tinha a especificação formal Marmot e o White Noise como implementação pública. Os eventos git NIP-34, ngit e GitWorkshop também tinham amadurecido até formar um fluxo utilizável de revisão de código. Esses projetos compartilhavam um estágio de design: usavam relays para coordenação enquanto levavam estado confidencial de grupos ou objetos de repositório para camadas específicas, em vez de tratar um cliente de notas de texto como todo o aplicativo.

Comércio e mídia seguiram o mesmo padrão. Carteiras NIP-60 e nutzaps NIP-61 levaram estado Cashu a eventos portáteis; Wavlake, Divine e implementações de marketplace NIP-99 usaram kinds de evento dedicados para música, vídeo e anúncios. O Nostr parecia cada vez menos “uma rede social” à medida que os aplicativos preservavam a base de identidade e relays, mas introduziam armazenamento, pagamentos, moderação e apresentação específicos de cada domínio.

Junho de 2026: um mês de muitos lançamentos

Junho de 2026 trouxe lançamentos que tratavam o Nostr como um componente dentro de produtos maiores. O Buzz abriu um padrão auto-hospedado de workspace como relay para humanos e agentes; o Napplets definiu um limite de confiança para aplicativos componíveis sobre Nostr e Blossom; e o Conduit colocou aplicativos de marketplace ao lado dos próprios documentos de protocolo. Esses projetos já não perguntavam se eventos assinados podiam sustentar colaboração. Eles decidiam qual trabalho pertencia aos eventos, qual pertencia a blobs ou estado local e quais permissões um host deveria manter.

O BitBlik usou o Nostr em um câmbio peer-to-peer entre moeda fiduciária e Lightning, o CodeDeck transportou sessões de programação por relays cifrados e o Haven aplicou o Marmot fora de um mensageiro convencional. A distância em relação ao repositório do protótipo de 2021 não é apenas uma quantidade maior de projetos. É uma mudança de abstração: equipes podiam começar com identidade portátil, descoberta de relays, cifragem e pagamentos como componentes existentes, e então dedicar o esforço de design ao limite específico do aplicativo acima deles.