Amethyst v1.11.0 traz uma implementação completa de calendário NIP-52 com lembretes, splits de zap Bitcoin on-chain e suporte a respostas em grupos Marmot. White Noise v2026.5.22 lança notificações push no iOS através de uma Notification Service Extension, junto com UX de bloqueio e um botão para adicionar membros. Vector v0.4.0 traz uma reescrita completa do vector-core, Tor com um clique e bridges, signers remotos NIP-46, sincronização de grupos MLS com negentropy completo, e um servidor MCP de 21 ferramentas para agentes de IA. Applesauce v6.1.0 introduz listas de relay de lookup NIP-51 (kind 10086) e um conjunto completo de factories git-cast NIP-34. MDK adiciona mensagens efêmeras NIP-40 entre iOS e Android através de uma superfície UniFFI unificada, e Mostro v0.17.4 fecha o loop de bond anti-abuso com payouts Fase 3 de bonds slashed para o vencedor. Notedeck faz merge de reconciliação negentropy NIP-77 completa para giftwraps e backfill de threads, Cordn surge como um messenger MLS mediado por coordenador que troca uma dependência de disponibilidade de ponto único por ordenação de época mais rígida e um modelo operacional mais simples, uma implementação de referência NIP-B0 chamada deepmarks lança um cliente de bookmarks monetizado por curador, e a equipe do Formstr abre quatro propostas coordenadas de NIP de calendário cobrindo auto-remoção de participantes, eventos privados, recorrência e agendamento descentralizado de compromissos.

Matérias principais

Amethyst v1.11.0: calendários, splits de zap on-chain e respostas no Marmot

Amethyst, o cliente Nostr para Android mantido por Vitor Pamplona, lançou v1.11.0. PR #2994 adiciona uma implementação de evento de calendário NIP-52 com uma UI dedicada e um sistema de lembretes, para que eventos de calendário agora sejam renderizados em sua própria categoria de linha do tempo, separada da visualização long-form genérica de kind-30023. PR #3018 estende zaps Bitcoin on-chain com suporte a splits, distribuindo uma única transação Bitcoin entre múltiplos destinatários conforme a tag zap-split existente, para que um pagamento on-chain se comporte da mesma forma que um split Lightning. PR #2974 adiciona uma tela paginada de histórico de transações on-chain que apresenta cada zap liquidado com status de confirmação de bloco.

Mensageria de grupo ganha paridade com chat um-para-um: PR #2995 adiciona suporte a respostas para mensagens de grupo Marmot/MLS, para que threads dentro de grupos criptografados agora sejam renderizados com a mesma UI de referência de pai que notas públicas. PR #2984 fortalece a validação de recibo de zap NIP-57 verificando se o provedor LNURL corresponde ao lud16 declarado do destinatário, fechando uma classe de falsificação onde um LNURL de terceiros poderia forjar um recibo para um pagamento que nunca chegou. PR #2968 aceita dimensões de ponto flutuante em tags imeta NIP-92, alinhando o Amethyst com clientes que publicam valores de densidade de pixel fracionários de dispositivos como o display Retina do iPhone. A release também conecta Payment Targets, uma nova pote de gorjetas multi-trilho de evento substituível coberto na seção de protocolo abaixo.

White Noise v2026.5.22: push no iOS, UX de bloqueio e adicionar membros

White Noise, o messenger de grupo do protocolo Marmot, lançou v2026.5.22 com notificações push no iOS como recurso em destaque. PR #673 implementa uma iOS Notification Service Extension (NSE) que descriptografa mensagens MLS dentro do processo de extensão e as apresenta como notificações do sistema, para que usuários de iPhone não precisem mais ter o app em primeiro plano para receber mensagens. A infraestrutura de push-token do Android é roteada através do mesmo pipeline de backend, com a NSE por plataforma mantendo ciphertext fora do broker.

PR #676 adiciona uma UX completa de bloqueio e desbloqueio com fluxos de confirmação e filtragem de lista de contatos. PR #679 adiciona o botão há muito solicitado “Add members” à tela de info do grupo, fechando uma lacuna de UX onde admins de grupo tinham que recorrer a links de compartilhamento. PR #688 introduz uma tela dedicada de configurações de notificação para iOS, e PR #687 conecta compartilhamento via toque longo para mídia e mensagens.

MDK adiciona mensagens efêmeras NIP-40 entre plataformas

O Marmot Development Kit, o core Rust compartilhado usado por White Noise iOS, White Noise Android, e qualquer cliente Marmot futuro, mesclou PR #306 para expor validação de mensagens efêmeras e tratamento de expiração NIP-40 através da ponte UniFFI. O PR é o segundo de uma série de três partes. iOS e Android agora compartilham uma implementação Rust da lógica de expiração; as regras de temporização vivem em um único caminho de código auditado consumido por ambas as plataformas via UniFFI. PR #307 limita o comprimento armazenado dos motivos de falha de welcome e os sanitiza antes da persistência, uma passagem de fortalecimento separada que complementa o tratamento de eventos de welcome lançado na semana passada.

Mensagens efêmeras em MLS não são apenas uma comodidade de UI. A tag de expiração é publicada com o envelope de mensagem criptografada, então um destinatário que nunca abre a mensagem ainda tem o ciphertext subjacente expirando na camada de relay junto com qualquer cópia em cache no cliente receptor. Com o MDK detendo o caminho de validação, o comportamento permanece consistente entre clientes: qualquer implementação Marmot conforme impõe a mesma semântica de expiração, então um cliente honrando a expiração enquanto outro faz cache para sempre deixa de ser um risco de portabilidade.

Mostro v0.17.4: Fase 3 fecha o loop de bond slashed

Mostro, o protocolo de câmbio Bitcoin peer-to-peer construído no Nostr, lançou a Fase 3 de seu rollout de bond anti-abuso em v0.17.4. PR #738 traz o fluxo de payout para bonds slashed, pegando o colateral perdido do perdedor e distribuindo-o para o vencedor da disputa. PR #743 adiciona a Fase 3.5, uma mensagem explícita de confirmação de payout para o vencedor para que ele saiba que os sats slashed foram liquidados, com o evento de confirmação chegando na mesma sessão Nostr da resolução de disputa. A Fase 2, coberta na semana passada, introduziu slashing como uma ação de admin; a Fase 3 é a diferença entre ameaçar uma penalidade e aplicá-la.

PR #746 permite ao daemon finalizar disputas que não têm uma linha de solver, um caso de borda que anteriormente travava a resolução em disputas legadas. PR #748 tolera taxas nulas na resposta /exrates/BTC do Yadio para que uma breve interrupção no Yadio não quebre mais o caminho de conversão fiat do Mostro. PR #745 documenta a especificação para provedores de preço multi-fonte, a base para remover o Yadio como um ponto único de falha. O cliente mobile do Mostro conectou o caminho de claim correspondente da Fase 3 no PR #596.

Applesauce v6.1.0: relays de lookup e git casts NIP-34

Applesauce, o toolkit Nostr modular que alimenta a stack de Coracle, noStrudel e Pablo F7z, lançou v6.1.0 em seus pacotes. A release adiciona suporte de primeira classe a listas de relay de lookup NIP-51: eventos kind 10086 permitem que um usuário sinalize “pergunte a esses relays se quiser me encontrar”, ficando ao lado de listas de outbox NIP-65 como uma primitiva de descoberta. Aplicações construídas em applesauce-core obtêm um observável reativo User.lookupRelays$ e um loader correspondente em applesauce-relay.

Factories git-cast NIP-34 chegam em applesauce-factory, dando a cada cliente construído em Applesauce um caminho de uma linha para publicar anúncios de repositório (kind 30617), patches (kind 1617) e issues (kind 1621). Propriedades reativas User.favoriteGitRepos$, User.gitAuthors$ e User.graspServers$ permitem que aplicações listem repos seguidos por um usuário, mantenedores de repo e servidores GRASP configurados diretamente do mesmo objeto User. A release também corrige métodos manuais de pool que silenciosamente descartavam relays offline no PR #73.

Notedeck faz merge de negentropy NIP-77 para giftwraps e backfill de threads

Notedeck, o cliente desktop nativo multi-coluna do Damus, mesclou PR #1459 em 25 de maio para conectar reconciliação negentropy NIP-77 completa ao caminho de outbox compartilhado. O PR adiciona frames de cliente e relay NIP-77, sessões negentropy relay-local, e um rastreador de histórico completo de outbox que dirige reconciliação de conjunto local e buscas de eventos faltantes. Giftwraps de mensagens obtêm reconciliação negentropy para que envelopes de mensagem privada possam ser recuperados dos relays de leitura da conta selecionada. Visualizações de thread não são mais limitadas pelo limite de resposta de assinatura ao vivo. Dave PNS substitui sua implementação negentropy local do Dave pelo caminho de outbox compartilhado enquanto preserva seu comportamento existente de histórico limitado.

Assinaturas ao vivo e negentropy agora usam filtros separados. Um fluxo pode manter uma pequena solicitação ao vivo enquanto emite um filtro negentropy mais amplo para reconciliar o que o relay já tem. O PR intencionalmente não habilita sync negentropy amplo para linhas do tempo home ou perfil, o que mudaria características de custo de cold-start. Cobertura de teste foi adicionada para reconciliação, entrega de giftwrap, backfill de thread, restauração Dave PNS, troca de conta, redirecionamento de relay, retries de fetch e comportamento de relay NIP-77.

Vector v0.4.0: reescrita do vector-core, Tor, NIP-46, MLS com negentropy completo, e uma superfície de agente MCP

Vector, o messenger cross-platform focado em privacidade construído em DMs NIP-17 e grupos Marmot, lançou v0.4.0 como sua maior release até hoje. O destaque é uma reescrita completa do motor: toda a lógica do Vector agora vive em uma única crate desacoplada, vector-core, compartilhada entre desktop, Android e qualquer cliente futuro, com mais de 440 testes no próprio core e a shell da aplicação com milhares de linhas removidas. A reescrita é a base para um CLI do Vector, bots e SDKs que dirigem o mesmo código de protocolo que a GUI.

Integração com Tor vem com roteamento de tráfego com um clique e suporte a bridge para contornar censura. Suporte multi-conta chega com um switcher in-app. Login com signer remoto chega via NIP-46 com pareamento bunker por QR ou URI colada, para que usuários possam fazer login sem nunca expor sua nsec. Delete-for-everyone funciona tanto em DMs NIP-17 quanto em chats de grupo Marmot, com o Vector mantendo a chave efêmera de assinatura como uma divergência deliberada da especificação que as notas de release destacam explicitamente: “um desvio das especificações tradicionais NIP-17/Marmot para controles aprimorados de privacidade do usuário.” A chave efêmera retida dá aos clientes Vector prova local de que uma exclusão foi sancionada pelo remetente original, mas também significa que qualquer outro cliente que toque no Vector vê uma superfície de verificabilidade de exclusão diferente dos clientes NIP-17/Marmot de referência.

Sync de grupo MLS agora é totalmente reconciliado sobre negentropy NIP-77, a mesma direção que o Notedeck tomou para giftwraps e threads esta semana. O uploader Blossom faz failover entre múltiplos servidores, aprende as capacidades de cada servidor e sincroniza a lista de servidores entre dispositivos. Pacotes de emoji customizados são criáveis pelo usuário, compartilháveis e cross-compatíveis com outros clientes Nostr. A memória SQLite caiu de aproximadamente 308MB para 5MB. O painel de emoji abre a partir de cache em disco e shortcodes estilo Discord (:smile:) mais ranking de frequência Unicode apresentam o glifo certo primeiro.

A adição mais nova é vector-agent, um servidor MCP (Model Context Protocol) que expõe 21 ferramentas para que agentes de IA possam dirigir o Vector: enviando DMs, gerenciando grupos, fazendo upload de arquivos, editando perfis. Este é o segundo projeto Nostr esta semana (junto com o Shopstr) a lançar uma superfície MCP, e a primeira aplicação de classe messenger a fazê-lo. Combinado com o AgentNoise (coberto na semana passada), o padrão de clientes Nostr controlados por agente está passando de experimentos pontuais para uma direção deliberada de plataforma.

Cordn aparece como um messenger MLS mediado por coordenador

Cordn (cliente web em cordn.net, repos em Cordn-msg/cordn e Cordn-msg/cordn-web) é um novo messenger MLS que adota uma abordagem arquitetural diferente do Marmot. Onde o Marmot é totalmente baseado em relay sem coordenador privilegiado (cada membro do grupo escreve diretamente para relays e qualquer relay conforme pode carregar o tráfego), o Cordn introduz um papel de coordenador por grupo implementado como um serviço ContextVM. O coordenador ordena commits MLS e lida com distribuição de welcome.

O argumento do Cordn, declarado em sua página /why, é que MLS como implantado em messengers de produção “não é livre de coordenação” e que “disseminação pública fracamente ordenada” torna a convergência de estado de grupo “muito mais difícil” sem um ponto forte de coordenação. Um design mediado por coordenador fornece avanço de época previsível e resolução mais simples de commits concorrentes. Participantes se conectam ao coordenador usando chaves efêmeras, então o coordenador aprende o ID do grupo e o timing do tráfego de commit mas não quais pubkeys de longo prazo são membros. Qualquer parte consultando relays para um grupo Marmot já pode ver a mesma superfície: atividade de grupo por ID de grupo, com timing inferível pela chegada de eventos. Cordn também reconhece que “confiança de disponibilidade permanece” com auto-hospedagem: um coordenador auto-hospedado evita a preocupação de centralização na camada do operador mas introduz um ponto único de falha para a liveness do grupo. Marmot evita esse ponto único deixando a ordenação para o próprio MLS (épocas e mensagens Commit lidam com ordenação dentro do protocolo) e distribuindo eventos Welcome via gift wrap NIP-59, ao custo de disciplina do lado do admin: admins devem esperar pelo reconhecimento do relay de um Commit antes de enviar o Welcome correspondente, e clientes devem reconciliar commits concorrentes quando a entrega do relay compete com uma transição de estado.

O contraste vale a pena examinar para qualquer equipe escolhendo uma stack de mensageria privada. Marmot troca alguma complexidade de implementação por uma implantação agnóstica a relay sem ator privilegiado no caminho. Cordn troca uma dependência de disponibilidade de ponto único por ordenação mais apertada e um modelo operacional mais simples. Ambos os projetos são construídos em MLS e usam Nostr como camada de identidade e transporte. A discordância é sobre onde vive o custo de coordenação. Os repos cordn-msg mostram cadência estável de commits com o serviço coordenador implementado sobre ContextVM e a camada MLS construída em ts-mls.

deepmarks: bookmarks NIP-B0 com publicação monetizada por curador

deepmarks-public é um cliente de referência para a especificação de bookmark proposta NIP-B0 (kind 39701), com uma arquitetura de três caixas (curador, indexador, visualizador) e um sistema de níveis financiado por zaps NIP-57 diretos ao curador. O cliente implementa NIP-B0, NIP-07, NIP-46, NIP-57, NIP-44, NIP-98, NIP-65 e Blossom BUD-01 e BUD-04 para armazenamento de arquivo. Um nível vitalício de 21.000 sats converte leitores pagantes em destinatários recorrentes de zap para o curador. O curador publica eventos de bookmark, o indexador os enriquece com metadados legíveis por máquina e o visualizador renderiza o feed; cada papel é um serviço implantável separado.

Releases

Amber v6.1.0 GA: backup criptografado por conta

Amber passou de v6.1.0-pre3 para GA v6.1.0 esta semana. PR #444 lança backup e restore criptografados para o banco de dados de permissões de aplicação, e PR #446 divide o backup por conta, para que usuários com múltiplas identidades Nostr possam fazer backup e restaurar cada conjunto de grants de app independentemente. O trabalho de assinatura PSBT coberto na semana passada está no corte GA.

Citrine: assinaturas por relay e prevenção de vazamento de URL onion

Citrine, o relay pessoal no dispositivo que vem com o Amethyst, lançou duas correções neste ciclo. PR #157 alterna de uma única assinatura global para assinaturas taggeadas por relay, para que dois relays de origem compartilhando um filtro kinds: [1] não colidam mais no lado do agregador. PR #162 filtra URLs de relay onion quando o proxy Tor de saída está desabilitado, evitando que endereços onion vazem para o caminho de roteamento clearnet.

Angor v0.2.27 e v0.2.28: confiabilidade de relay e reconexão Boltz

Angor lançou v0.2.27 e v0.2.28. PR #874 corrige um bug de dedup de relay onde apenas um relay estava conectado por vez, uma regressão que silenciosamente degradava a confiabilidade para projetos com múltiplos endpoints de relay. PR #876 adiciona lógica de reconexão WebSocket para monitoramento de submarine-swap Boltz, para que uma breve desconexão não deixe mais um swap em estado desconhecido.

Nostrord v1.1.0: zaps NIP-57 e distinção de papéis NIP-29

Nostrord lançou v1.1.0 com suporte a zaps Lightning NIP-57 para mensagens e perfis (PR #98) e uma distinção adequada no feed de atividade entre mudanças de papel NIP-29 e adições de membro (PR #92), que costumavam renderizar identicamente e obscureciam quem havia sido promovido versus quem havia sido convidado.

ぬるぬる v1.5.x: keystore MLS SQLCipher e catch-up de época

ぬるぬる (nurunuru, por tami1A84), um cliente Nostr em japonês que implementa mensageria de grupo MLS (kind 443) junto com NIP-44, busca avançada NIP-50, NIP-55 e NIP-70, lançou cinco releases esta semana. PR #184 introduz criptografia SQLCipher para o keystore MLS na camada rust-engine. PR #187 e PR #188 estendem SQLCipher para Android e iOS respectivamente, com uma etapa de purga de plaintext legacy e guards de CI. PR #189 e PR #191 adicionam catch-up de época de par MLS com um cache de replay e um banner de recuperação em ambas as plataformas, para que um cliente que fica para trás em commits de grupo possa se recuperar sem perder a conversa. ぬるぬる é um cliente Marmot construído em mdk-core, mdk-sqlite-storage e mdk-storage-traits de marmot-protocol/mdk, então o trabalho SQLCipher e catch-up de época chega dentro do mesmo runtime MDK que o White Noise usa.

Bitcredit Core v0.5.10: correção de propagação de bloco com raiz Nostr

Bitcredit Core lançou v0.5.10 com uma correção para um campo Nostr-node-id ausente durante propagação de bloco, que estava quebrando fluxos de criação de empresa que incluíam upload de identidade. Bitcredit é um protocolo de e-bill que usa identidades Nostr como raiz de confiança para eventos de propagação de empresa e bill.

Mudanças não lançadas

Jumble abriu PR #797 para login Google via o signer de threshold Pomegranate, permitindo a um usuário dividir sua chave Nostr entre múltiplas partes para que nenhum signer único detenha o segredo completo. Este é um passo significativo além dos fluxos bunker ou nsec-import: um usuário pode recuperar sua conta mesmo se uma parte signer for comprometida, sem que essa parte jamais detenha a chave privada completa.

Shopstr abriu PR #492 inicializando um servidor MCP (Model Context Protocol), com PR #494 construindo a infraestrutura de suporte (fetch de relay, parsers, validação, erros, dedup, log de auditoria) e PR #472 adicionando uma allowlist de relay para o gerenciador de relay MCP. Isso torna o Shopstr o primeiro marketplace Nostr a se expor como um servidor MCP, para que agentes de IA possam navegar e agir em listagens NIP-99 como uma ferramenta estruturada.

Keydex, o vault de compartilhamento de segredo Shamir, abriu uma migração substancial no PR #226 movendo kinds customizados 1337-1345 para a faixa 713-721, junto com PR #239 adicionando AEAD sobre shares Shamir e PR #234 migrando para aritmética GF256. A migração de faixa de kind alinha o Keydex com a forma como o repositório NIPs aloca kinds customizados, saindo de uma faixa auto-declarada.

Mill (nostr-mill) é uma nova UI de signer Nostr drop-in do OceanSlim (mantenedor do relay Go grain), lançado como um Web Component de tag de script único no npm e jsDelivr. Uma tag <script> dá a um app web todos os seis pontos de entrada de signer comuns por trás de uma UI unificada: extensão de navegador NIP-07, bunker NIP-46 (colar URL ou pareamento QR com relays especificáveis pelo usuário, incomum entre integrações bunker in-page), Amber NIP-55 via intents Android, nsec criptografada armazenada em sessionStorage via AES-256-GCM com PBKDF2, npub somente leitura, e geração de par de chaves no navegador. O componente é tematizável através de 29 propriedades customizadas CSS escopadas no Shadow DOM e expõe uma pequena API rastreada por SemVer (MILL.open, eventos mill:connected / mill:disconnected, exports de tema nomeados). A motivação do mantenedor é que fluxos de login bunker foram reimplementados um app web por vez em todo o Nostr. Consolidar em um componente compartilhado permite que clientes convirjam em como o UX do signer deve se comportar, e transforma fluxos opcionais (como login com chave delegada através de signers de threshold, espelhando o login Google baseado em Pomegranate do Wisp coberto acima) em uma superfície reutilizável que qualquer app pode adicionar. Mill está em npm v1.5.0, mantenedor único, estágio alpha, com grain como o primeiro integrador planejado.

moStard, um fork Monero-first do noStrudel por roguehashrate, chegou à v1.0.1 esta semana com um conjunto de recursos reduzido e uma identidade temática Monero em camadas na mesma stack Applesauce + worker-relay. O trabalho desta semana trouxe renderização para eventos de software-application kind 32267 do Zapstore (cards embutidos na linha do tempo mostrando nome do app, ícone, screenshots, plataforma, licença e um link de launch para zapstore.dev/apps/<d-tag>), enquetes via kind 20 e kind 21, gorjetas baseadas em Payment Targets NIP-A3 com QR codes por método, renderização de markdown em notas, suporte a picker GIF para teclados GIF externos, e correções de pareamento de signer Amber. O enquadramento Monero se estende ao fluxo de gorjeta: entradas payto NIP-A3 para endereços monero obtêm botões de primeira classe na mesma UI junto com lightning e bitcoin. O cliente é de mantenedor único e estágio alpha, mas o trabalho de 27 de maio mostra um construtor puxando NIP-A3 dos anúncios de especificação de protocolo desta semana direto para um fork em produção em dias.

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

Stack NIP de calendário: quatro propostas da equipe Formstr

Ix2 (@geralt-debugs) abriu quatro PRs de NIP coordenados em 17 de maio, todos referenciando a implementação calendar.formstr.app já lançada sob o mesmo autor. PR #2350 propõe kind 84 como um evento generalizado de “auto-remoção de participante”: um participante taggeado em qualquer evento pode publicar um kind 84 referenciando o original via tags e, a e k para sinalizar opt-out. Relays devem validar que o signer do kind 84 aparece em uma tag p do evento referenciado antes de honrar a remoção, e uma exclusão kind 5 sempre tem precedência. O PR generaliza um padrão que anteriormente era descrito apenas dentro do contexto de calendário NIP-52, tornando o kind 84 a maneira padrão para não-autores se retirarem de qualquer evento de participante.

PR #2351 é a fundação da stack de calendário: NIP-52E para eventos de calendário privados (kinds 32678 time-based, 32681 day-event, 32123 lista de calendário privado, 31926 lista de ocupado, 1052 gift wrap, 52 rumor) e NIP-52R para eventos recorrentes. No centro arquitetural está o padrão view-key: um par de chaves gerado aleatoriamente criptografa o conteúdo do evento com NIP-44, e a metade secreta (codificada em bech32 como nsec) é gift-wrapped para cada participante. O signer detém apenas a tag d pública; todo o resto vive em content criptografado. Desacoplar a criptografia de conteúdo da identidade dessa forma significa que editar um evento não requer re-envio de chaves para destinatários. NIP-52R define duas tags opcionais nos kinds existentes 31923 e 31922 para declarar recorrência usando valores RRULE RFC 5545 brutos, com o índice de dia D tornando-se opcional quando RRULE está presente. Forward secrecy está explicitamente ausente: uma view key vazada revela todas as versões passadas e futuras do evento sob a mesma tag d.

PR #2352 constrói sobre NIP-52E com uma especificação descentralizada de agendamento de compromissos que a descrição do PR chama de “uma alternativa drop-in para Calendly/Cal.com sem intermediário central.” Kind 31927 anuncia uma página de agendamento com janelas de disponibilidade criptografadas; kind 32680 é um registro de recuperação auto-criptografado do lado do host para a view key; kinds 1057 e 1058 são a solicitação e resposta de reserva gift-wrapped. O mecanismo inteligente: o reservante gera tanto a tag d quanto a view key para o futuro evento privado antes de enviar a solicitação, para que o reservante possa adicionar o compromisso ao seu próprio calendário imediatamente com a chave correta, e o host nunca precise fazer round-trip de chave de volta. Respostas de reserva carregam uma tag status não criptografada no wrap externo para que relays possam filtrar sem descriptografar.

Uma implementação de referência já está no ar em calendar.formstr.app e como o app Calendar Android no Zapstore. PR #2351 fecha o PR #2027 em seu favor, consolidando uma proposta anterior de calendário privado que estava aberta desde o início do ano.

Payment Targets e Silent Payments

Mais duas propostas de NIP circularam esta semana em documentos long-form kind:30023.

Uma proposta de Payment Targets (NIP-A3 / payto) define um evento substituível kind 10133 carregando uma ou mais tags ["payto", "<type>", "<authority>"] que mapeiam para URIs payto: RFC 8905. Tipos suportados incluem bitcoin, lightning, ethereum, monero, nano, cashme, revolut e venmo. A intenção é padronizar um pote de gorjetas multi-trilho que complementa (não substitui) zaps NIP-57 baseados em lud16. Amethyst v1.11.0 é o primeiro implementador; PRs mesclados #2953 e #3009 trazem a superfície de assinatura e observação, e PR #3011 conecta a UI para PaymentTargetsEvent.

Duas propostas concorrentes de Silent Payments vieram de autores diferentes. A primeira variante deriva chaves de scan e spend de silent-payment BIP-352 de nsec via tweaks aditivos públicos, para que qualquer remetente possa construir um endereço sp1q... de uma npub sem configuração. O aviso do autor é explícito na especificação: “bscan e bspend DEVEM ser tratados com exatamente o mesmo cuidado que nsec”, porque a chave de scan revela a nsec. Uma segunda variante toma a abordagem inversa, adicionando um campo sp_address aos metadados de perfil kind 0 contendo um endereço padrão de silent-payment BIP-352 cujas chaves são mantidas independentes da identidade Nostr. A variante dois é estruturalmente mais segura. Ambas as propostas atraíram uma thread de revisão ponderada; erskingardner (líder do Marmot) postou um comentário detalhado no gist trbouma rastreando a proposta. Sua preocupação central é que a variante 1 deriva a chave privada de scan de nsec mais um tweak publicamente computável, o que significa que qualquer um segurando a chave de scan (incluindo um serviço de scan de terceiros ao qual o usuário tem que delegar na prática) pode recuperar a nsec completa subtraindo esse tweak. A mesma chave que permite a um serviço remoto escanear pagamentos recebidos para você também permite a esse serviço roubar sua identidade e quaisquer fundos derivados dela.

No lado git-over-Nostr NIP-34, hzrd149 publicou 2 patches para schemata. O próprio gitworkshop.dev atraiu dois relatos de issues: um sinalizando que sessões de login são perdidas no refresh da página ao usar um signer remoto NIP-46, o outro pedindo por estilo distinto de link em previews de README.

Seis anos de maios do Nostr

A última newsletter de maio de 2026 recua das releases da semana para percorrer o mês de maio ao longo da história do Nostr. Cada ano teve um centro de gravidade diferente: 2021 foi um único commit, 2022 foi a formação do próprio repositório NIPs, 2023 foi a explosão de especificações de protocolo, 2024 foi o ciclo de consolidação, 2025 foi quando negentropy foi mesclado e o Notedeck do Damus se graduou para Beta, e 2026 é o mês coberto neste e nos três issues anteriores.

Maio de 2021

O Nostr tinha seis meses. O único código Nostr vivia em fiatjaf/nostr e o mês inteiro produziu exatamente um commit, mas esse commit se tornou uma das partes mais usadas do protocolo. Em 22 de maio, fiatjaf redirecionou o NIP-02 como o NIP de lista de contatos. A mensagem do commit diz: “repurpose NIP-02 and add NIP authorship”, e o crédito explícito é para PR #16 por arcbtc (Ben Arc do LNbits), aberto em 9 de fevereiro e fechado no dia anterior ao fiatjaf incorporar a ideia no NIP-02. A proposta do arcbtc era pequena: um kind para “enviar lista de seguidores para relays” que seria “útil para restaurar contas e recomendar chaves públicas para seguir.” fiatjaf generalizou isso em um único evento kind:3 cujas tags servem três propósitos ao mesmo tempo. Elas são uma lista de follows (o grafo social), um store de petname (apelidos locais para amigos) e uma fonte de recomendação de relay (quais relays um follow usa). O mesmo evento, substituível por autor, tornou-se a resposta canônica para “quem essa pessoa segue”, “como ela os chama” e “onde ela lê.” Cada cliente construído nos próximos cinco anos lê kind:3. A convenção adicionada no mesmo commit, de que cada NIP nomeia seu autor, é a razão pela qual cada especificação agora tem assinatura.

Maio de 2022

O mês em que o repositório NIPs se tornou um projeto comunitário. Em 1º de maio, fiatjaf migrou as especificações de fiatjaf/nostr para um repositório dedicado nostr-protocol/nips e em 2 de maio adicionou critérios formais de aceitação. Dois dias depois, Robert C. Martin (Uncle Bob) abriu PR #1, o primeiro pull request externo, propondo convenções de threading para tags e e p. O PR foi originalmente numerado NIP-13, então renumerado para NIP-10 para abrir espaço para proof-of-work. Três dos primeiros seis NIPs são do Uncle Bob: NIP-10 (marcadores de threading), NIP-14 (a tag Subject), e o commit de 21 de maio que fixou kind:1 como o kind canônico de nota de texto curta. Em 5 de maio, William Casarin fez seus primeiros commits de NIP: NIP-13 Proof of Work e o evento kind:2 recommend-relay. No dia seguinte, fiatjaf publicou NIP-07 window.nostr, vinte linhas de markdown que definiram a interface de signer de extensão de navegador ainda usada hoje. O aviso CORS do NIP-05 por David A. Harding e o filter.limit do NIP-01 chegaram na mesma semana. nostr-tools lançou sua primeira build ESM importável no navegador em 8 de maio. Semisol rascunhou NIP-15 (End Of Stored Events) e NIP-16 (faixas de kind de evento) no final do mês, os documentos que ainda governam a semântica de sync de relay e a classificação regular-vs-substituível-vs-efêmero.

Maio de 2023

A explosão de especificação de protocolo. Sessenta e quatro PRs de NIP foram abertos naquele mês, com várias das propostas que definiram a superfície do Nostr para os próximos dois anos todas chegando em 31 dias, e o maior anúncio de financiamento que o Nostr já havia recebido chegou em 4 de maio com o grant OpenSats de $10 milhões do #startsmall de Jack Dorsey, o dinheiro que sustentou cada onda de grants Nostr desde então. NIP-47 (Nostr Wallet Connect) foi mesclado em 2 de maio, trazendo a especificação wallet-connect do Alby para o protocolo principal. Dois dias depois, Vitor Pamplona propôs NIP-53 Live Activities com salas kind:30311 e mensagens de chat kind:1311, a fundação para cada superfície de livestreaming Nostr que seguiu. Pablo Fernandez abriu NIP-84 Highlights em 5 de maio e NIP-89 Recommended Application Handlers em 14 de maio. v0l (Kieran Babich, autor do Snort) propôs NIP-98 HTTP Auth em 8 de maio, a primitiva de autenticação da qual NIP-96 e Blossom ambos depois dependeram. Jonathan Staab propôs NIP-32 Labels em 15 de maio, e NIP-30 Custom Emoji foi mesclado no mesmo dia. Arthur Franca propôs NIP-96 HTTP File Storage Integration em 21 de maio. Dois dias depois, Vitor adicionou zap splits ao NIP-57 e verbiricha adicionou rascunhos long-form kind:30024 ao NIP-23, a especificação que se tornou a fundação para fluxos de trabalho modernos de autoria long-form Nostr em Habla, YakiHonne e Highlighter. fiatjaf propôs NIP-29 Simple Groups no final do mês, o mesmo NIP-29 que Wisp, Flotilla, Chachi e 0xChat implementam em produção hoje.

Maio de 2024

O ciclo de consolidação. Menos propostas chamativas, mais entregas. NIP-54 Decentralized Wikis foi mesclado em 2 de maio com artigos kind:30818 e tags d normalizadas por caso. Três dias depois, NIP-56 foi estendido para que relatos de abuso pudessem sinalizar ameaças digitais (malware, phishing) junto com categorias apenas de conteúdo. Em 6 de maio, reações NIP-25 foram simplificadas para parar de incluir a thread de resposta inteira como tags e. Arthur Franca propôs NIP-22 Comment em 12 de maio, introduzindo kind:1111 para que respostas a eventos não-kind:1 (artigos, arquivos, produtos) obtenham uma forma estruturada de threading. Em 19 de maio, fiatjaf reformulou o NIP-46 para abandonar o NIP-04 inteiramente e mudar todo o tráfego bunker para criptografia NIP-44, o movimento de descontinuação que moldou cada implementação bunker desde. Em 20 de maio, NIP-71 Video Events foi mesclado com kind:21 e kind:22, e NIP-10 adicionou o argumento opcional de pubkey em tags e para que clientes possam resolver autores de thread sem primeiro buscar o evento referenciado. NIP-35 Torrents de Kieran Walsh foi mesclado em 22 de maio, e em 24 de maio o README dos NIPs referenciou pela primeira vez CIP-01 como uma proposta off-repo, sinalizando o início do padrão “NIPs como um de vários locais de proposta”. Em 25 de maio, um PR de limpeza removeu a tag aes-256-gcm do NIP-71 antes que implementações downstream a congelassem. NIP-96 adicionou list files e removeu o requisito de transformação em 27 de maio. Em 28 de maio, Jonathan Staab propôs elevar a barra de aceitação de NIP para exigir pelo menos duas implementações interoperáveis antes que um rascunho possa se graduar. Lado do cliente: Damus taggeou v1.7.2 e v1.8 mais uma v1.9 com tratamento completo de marcador NIP-10 em 9-10 de maio, trouxe autenticação NIP-98 em notificações push, e lançou suporte completo a marcador NIP-10. Amethyst tornou NIP-17 o modo padrão de DM em 14 de maio, construiu gerenciamento de relay outbox-model NIP-65, adicionou seleção de servidor NIP-96, e lançou derivação de chave NIP-06 BIP-32/BIP-39. Primal Android 0.99.2 em 10 de maio adicionou tagging de usuário e NWC de carteira externa, seguido por 0.99.4. Pablo Fernandez trouxe um cluster de optimistic-update NDK entre 24-31 de maio. Snort adicionou seleção de servidor NIP-96, e cashu-ts separou suas primitivas de criptografia em @cashu/crypto.

Maio de 2025

O mês em que NIP-77 (Negentropy Syncing) foi mesclado em 27 de maio, a especificação do fiatjaf e Doug Hoyte para o protocolo de fio que substitui filtros REQ de força bruta por computação de diferença de custo logarítmico. Este era o mesmo negentropy que strfry havia lançado dois anos antes como recurso do lado do relay, agora formalizado como um protocolo cliente-relay, e a entrada no README chegou no mesmo dia. Na semana anterior, NIP-23 long-form definiu como documentos HTML se associam a entidades Nostr através de uma tag <link> em 24 de maio, a primitiva de cópia web canônica. NIP-25 adicionou dicas de relay de alvo de reação em 22 de maio e removeu a recomendação emoji-para-like/dislike, tratando emojis como unidades semânticas distintas. NIP-52 foi simplificado em 14 de maio para focar nos kinds que os clientes estavam lançando em produção, o corte que tornou as extensões de calendário Formstr de um ano depois mais limpas de enxertar. Em 9 de maio, Follow Packs (kind 39089 listas de follow curadas) e Favorite Relays (uma nova lista substituível sob o NIP-51) entraram no README no mesmo dia. O arco do Protocolo Marmot ainda não havia começado: apenas o repositório whitenoise-rs existia (primeiro commit 9 de setembro de 2024), e maio de 2025 era sua fase de protótipo Svelte+Tauri, com o commit de 14 de maio removendo código específico do Tauri conforme o projeto pivotava para sua arquitetura atual. O core Rust dedicado MDK (12 de setembro de 2025), o repositório de especificação Marmot (19 de setembro de 2025), e a UI Flutter (2 de dezembro de 2025) todos vieram depois.

Maio de 2026

O mês coberto na Newsletter #21, #22, #23 e neste issue. A linha definidora é MLS-no-Nostr chegando a produção multi-cliente: MDK 0.8.0 lançou primitivas de leaf-index MIP-05 e key packages endereçáveis, seguido por PR #306 adicionando validação de mensagem efêmera NIP-40 entre iOS e Android através de uma superfície UniFFI compartilhada. White Noise v2026.5.22+25 lançou push no iOS através de uma Notification Service Extension que descriptografa ciphertext MLS dentro do processo de extensão para que o broker nunca veja plaintext, e dois novos clientes Marmot apareceram: Scramble (um cliente .NET/Avalonia para desktop e Android com slots KeyPackage multi-dispositivo) e Cordn (uma arquitetura MLS alternativa usando um coordenador por grupo sobre ContextVM). Angor migrou sua mensageria criptografada de NIP-04 para NIP-44 no PR #860, fechando o arco de descontinuação que abriu com a proposta NIP-44 de Paul Miller em maio de 2023. A equipe Formstr abriu a maior submissão coordenada de NIP na memória recente em 17 de maio, com PR #2350 para auto-remoção de participante, PR #2351 para eventos de calendário privados e recorrência (NIP-52E e NIP-52R), e PR #2352 para agendamento descentralizado de compromissos, todos com calendar.formstr.app já lançando a implementação de referência. Amethyst v1.11.0 renderizou eventos de calendário NIP-52 em sua própria categoria de linha do tempo, e o padrão de clientes controlados por agente que começou com AgentNoise na semana passada continuou com Vector v0.4.0 lançando um servidor MCP de 21 ferramentas e Shopstr abrindo sua superfície MCP como o primeiro marketplace-como-ferramenta-de-agente do Nostr.

Se você quiser discutir, mande uma DM para nós no Nostr.