Amethyst v1.11.0 porta un’implementazione completa del calendario NIP-52 con promemoria, split di zap Bitcoin onchain e supporto alle risposte nei gruppi Marmot. White Noise v2026.5.22 rilascia le notifiche push iOS tramite una Notification Service Extension, insieme alla UX di block e a un pulsante per aggiungere membri. Vector v0.4.0 porta un rewrite da zero di vector-core, Tor one-click con bridge, remote signer NIP-46, sincronizzazione MLS di gruppo full-negentropy e un server MCP a 21 tool per agenti AI. Applesauce v6.1.0 introduce liste di lookup relay NIP-51 (kind 10086) e un set completo di factory per git-cast NIP-34. MDK aggiunge i messaggi a scomparsa NIP-40 su iOS e Android tramite una superficie UniFFI unificata, e Mostro v0.17.4 chiude il ciclo del bond anti-abuso con i payout di bond slashati di Fase 3 al vincitore. Notedeck mergia la riconciliazione completa negentropy NIP-77 per giftwrap e backfill dei thread, Cordn appare come messenger MLS mediato da coordinator che scambia una dipendenza di disponibilità a punto singolo per un ordinamento di epoch più stretto e un modello operativo più semplice, un’implementazione di riferimento NIP-B0 chiamata deepmarks rilascia un client di bookmark monetizzato dal curatore, e il team Formstr apre quattro proposte NIP calendario coordinate che coprono l’auto-rimozione dei partecipanti, gli eventi privati, la ricorrenza e la programmazione decentralizzata degli appuntamenti.

Storie principali

Amethyst v1.11.0: calendari, split di zap onchain e risposte Marmot

Amethyst, il client Nostr per Android manutenuto da Vitor Pamplona, ha rilasciato v1.11.0. PR #2994 aggiunge un’implementazione di eventi di calendario NIP-52 con una UI dedicata e un sistema di promemoria, così gli eventi di calendario sono ora resi nella propria categoria di timeline, separata dalla vista generica di kind-30023 long-form. PR #3018 estende gli zap Bitcoin onchain con il supporto agli split, distribuendo una singola transazione Bitcoin fra più destinatari secondo il tag zap-split esistente, così un pagamento onchain si comporta come uno split Lightning. PR #2974 aggiunge una schermata paginata di cronologia delle transazioni onchain che mostra ciascuno zap regolato con lo stato di conferma del blocco.

La messaggistica di gruppo guadagna parità con la chat uno-a-uno: PR #2995 aggiunge il supporto alle risposte per i messaggi di gruppo Marmot/MLS, così i thread all’interno di gruppi cifrati sono ora resi con la stessa UI di riferimento genitore delle note pubbliche. PR #2984 rafforza la validazione delle ricevute zap NIP-57 controllando che il provider LNURL corrisponda al lud16 dichiarato del destinatario, chiudendo una classe di falsificazione in cui un LNURL di terze parti poteva emettere una ricevuta per un pagamento mai avvenuto. PR #2968 accetta dimensioni floating-point nei tag imeta NIP-92, allineando Amethyst con i client che pubblicano valori di densità pixel frazionari da dispositivi come il display Retina dell’iPhone. La release collega anche i Payment Targets, un nuovo tip jar multi-rail su evento replaceable trattato nella sezione protocollo più sotto.

White Noise v2026.5.22: push iOS, UX di block e aggiunta membri

White Noise, il messenger di gruppo protocollo Marmot, ha rilasciato v2026.5.22 con le notifiche push iOS come funzionalità principale. PR #673 implementa una Notification Service Extension (NSE) iOS che decifra i messaggi MLS all’interno del processo dell’extension e li presenta come notifiche di sistema, così gli utenti iPhone non hanno più bisogno che l’app sia in foreground per ricevere messaggi. Il plumbing dei token push Android passa attraverso la stessa pipeline backend, con la NSE per-piattaforma che tiene il ciphertext fuori dal broker.

PR #676 aggiunge una UX completa di block e unblock con flussi di conferma e filtraggio della lista contatti. PR #679 aggiunge il pulsante “Aggiungi membri” richiesto da tempo alla schermata di info del gruppo, chiudendo un gap UX in cui gli admin del gruppo dovevano ricadere sui share link. PR #688 introduce una schermata di impostazioni notifiche iOS dedicata, e PR #687 collega la condivisione tramite long-press per media e messaggi.

MDK aggiunge i messaggi a scomparsa NIP-40 su tutte le piattaforme

Il Marmot Development Kit, il core Rust condiviso usato da White Noise iOS, White Noise Android e qualunque futuro client Marmot, ha mergiato PR #306 per esporre la validazione di messaggi a scomparsa e la gestione della scadenza NIP-40 tramite il bridge UniFFI. La PR è la seconda di una serie in tre parti. iOS e Android ora condividono un’unica implementazione Rust della logica di scadenza; le regole di timing vivono in un singolo percorso di codice auditato consumato da entrambe le piattaforme via UniFFI. PR #307 limita la lunghezza memorizzata delle ragioni di fallimento welcome e le sanifica prima della persistenza, un passaggio di hardening separato che complementa la gestione degli eventi welcome rilasciata la scorsa settimana.

I messaggi a scomparsa in MLS non sono solo una comodità UI. Il tag di scadenza è pubblicato con l’inviluppo del messaggio cifrato, così un destinatario che non apre mai il messaggio ha comunque il ciphertext sottostante che scade a livello relay insieme a qualunque copia in cache nel client ricevente. Con MDK che possiede il percorso di validazione, il comportamento resta consistente fra i client: qualunque implementazione Marmot conforme forza la stessa semantica di scadenza, così un client che rispetta la scadenza mentre un altro fa cache per sempre cessa di essere un rischio di portabilità.

Mostro v0.17.4: la Fase 3 chiude il ciclo del bond slashato

Mostro, il protocollo di exchange Bitcoin peer-to-peer costruito su Nostr, ha rilasciato la Fase 3 del suo rollout di bond anti-abuso in v0.17.4. PR #738 porta il flusso di payout per i bond slashati, prendendo il collaterale confiscato al perdente e distribuendolo al vincitore della disputa. PR #743 aggiunge la Fase 3.5, un messaggio esplicito di conferma di payout al vincitore così che sappia che i sats slashati sono stati regolati, con l’evento di conferma che arriva sulla stessa sessione Nostr della risoluzione della disputa. La Fase 2, trattata la scorsa settimana, ha introdotto lo slashing come azione admin; la Fase 3 è la differenza fra minacciare una penalità e farla rispettare.

PR #746 consente al daemon di finalizzare dispute che non hanno una riga solver, un caso limite che precedentemente bloccava la risoluzione su dispute legacy. PR #748 tollera rate null nella risposta /exrates/BTC di Yadio così un breve outage di Yadio non rompe più il percorso di conversione fiat di Mostro. PR #745 documenta la spec per provider di prezzo multi-sorgente, il fondamento per rimuovere Yadio come single point of failure. Il client mobile Mostro ha collegato il corrispondente percorso di claim di Fase 3 in PR #596.

Applesauce v6.1.0: lookup relay e git cast NIP-34

Applesauce, il toolkit Nostr modulare che alimenta Coracle, noStrudel e lo stack di Pablo F7z, ha rilasciato v6.1.0 attraverso i suoi pacchetti. La release aggiunge il supporto nativo alle liste di lookup relay NIP-51: gli eventi di kind 10086 permettono a un utente di segnalare “chiedi a questi relay se vuoi trovarmi”, accanto alle liste outbox NIP-65 come primitiva di scoperta. Le applicazioni costruite su applesauce-core ottengono un observable reattivo User.lookupRelays$ e un loader corrispondente in applesauce-relay.

Le factory di git-cast NIP-34 arrivano in applesauce-factory, dando a ogni client basato su Applesauce un percorso di una riga per pubblicare annunci di repo (kind 30617), patch (kind 1617) e issue (kind 1621). Le proprietà reattive User.favoriteGitRepos$, User.gitAuthors$ e User.graspServers$ consentono alle applicazioni di elencare repo seguiti da un utente, manutentori di repo e server GRASP configurati direttamente dallo stesso oggetto User. La release corregge anche i metodi manuali del pool che scartavano silenziosamente i relay offline in PR #73.

Notedeck mergia il negentropy NIP-77 per giftwrap e backfill dei thread

Notedeck, il client desktop multi-colonna nativo di Damus, ha mergiato PR #1459 il 25 maggio per collegare la piena riconciliazione negentropy NIP-77 nel percorso outbox condiviso. La PR aggiunge frame client e relay NIP-77, sessioni negentropy locali del relay e un tracker di storia completa outbox che pilota la riconciliazione dei set locali e il fetch di eventi mancanti. I giftwrap di messaggi ottengono la riconciliazione negentropy così gli inviluppi di messaggi privati possono essere recuperati dai relay di lettura dell’account selezionato. Le viste dei thread non sono più limitate dal limite di risposte della sottoscrizione live. Dave PNS sostituisce la sua implementazione negentropy locale a Dave con il percorso outbox condiviso preservando il suo comportamento esistente di storia limitata.

Le sottoscrizioni live e negentropy usano ora filtri separati. Un flusso può mantenere una piccola richiesta live emettendo al contempo un filtro negentropy più ampio per riconciliare ciò che il relay ha già. La PR non abilita intenzionalmente la sync negentropy ampia per home o timeline di profilo, che cambierebbe le caratteristiche di costo a cold-start. La copertura di test è stata aggiunta per riconciliazione, consegna di giftwrap, backfill dei thread, ripristino di Dave PNS, cambio account, retargeting dei relay, retry di fetch e comportamento relay NIP-77.

Vector v0.4.0: rewrite di vector-core, Tor, NIP-46, MLS full-negentropy e una superficie di agente MCP

Vector, il messenger cross-platform focalizzato sulla privacy costruito su DM NIP-17 e gruppi Marmot, ha rilasciato v0.4.0. La novità è un rewrite dell’engine da zero: tutta la logica di Vector vive ora in un singolo crate disaccoppiato, vector-core, condiviso fra desktop, Android e qualunque futuro client, con oltre 440 test nel core stesso e la shell dell’applicazione ridotta di migliaia di righe. Il rewrite è la base per una CLI Vector, bot e SDK che pilotano lo stesso codice di protocollo della GUI.

L’integrazione Tor è rilasciata con routing del traffico one-click e supporto ai bridge per il bypass della censura. Il supporto multi-account arriva con uno switcher in-app. Il login con remote signer arriva tramite NIP-46 con pairing bunker via QR o URI incollato, così gli utenti possono accedere senza mai esporre il proprio nsec. Delete-for-everyone funziona sia nei DM NIP-17 sia nelle chat di gruppo Marmot, con Vector che mantiene la chiave di firma effimera come divergenza dalla spec deliberata che le note di release evidenziano esplicitamente: “una diversione dalle spec tradizionali NIP-17/Marmot per controlli di privacy utente potenziati”. La chiave effimera trattenuta dà ai client Vector una prova locale che un’eliminazione è stata sanzionata dal mittente originale, ma significa anche che qualunque altro client che tocca Vector vede una superficie di verificabilità dell’eliminazione diversa dai client NIP-17/Marmot baseline.

La sincronizzazione dei gruppi MLS è ora completamente riconciliata su negentropy NIP-77, la stessa direzione che Notedeck ha preso per giftwrap e thread questa settimana. L’uploader Blossom fa failover su più server, impara le capability di ciascun server e sincronizza la lista dei server fra i dispositivi. I pacchetti di emoji custom sono creabili dall’utente, condivisibili e cross-compatibili con altri client Nostr. La memoria SQLite è scesa da circa 308MB a 5MB. Il pannello emoji si apre dalla cache su disco e gli shortcode stile Discord (:smile:) più il ranking di frequenza Unicode mostrano il glifo giusto per primo.

L’aggiunta più originale è vector-agent, un server MCP (Model Context Protocol) che espone 21 tool così gli agenti AI possono pilotare Vector: inviare DM, gestire gruppi, caricare file, modificare profili. Questo è il secondo progetto Nostr questa settimana (insieme a Shopstr) a rilasciare una superficie MCP, e la prima applicazione di classe messenger a farlo. Combinato con AgentNoise (trattato la scorsa settimana), il pattern di client Nostr controllati da agenti si muove da esperimenti isolati a una direzione di piattaforma deliberata.

Cordn appare come messenger MLS mediato da coordinator

Cordn (client web a cordn.net, repo a Cordn-msg/cordn e Cordn-msg/cordn-web) è un nuovo messenger MLS che prende una direzione architetturale diversa da Marmot. Dove Marmot è completamente basato su relay senza un coordinator privilegiato (ogni membro del gruppo scrive direttamente ai relay e qualunque relay conforme può trasportare il traffico), Cordn introduce un ruolo di coordinator per-gruppo implementato come un servizio ContextVM. Il coordinator ordina i commit MLS e gestisce la distribuzione dei welcome.

L’argomento di Cordn, dichiarato sulla sua pagina /why, è che MLS come deployato nei messenger di produzione “non è coordination-free” e che “la disseminazione pubblica debolmente ordinata” rende la convergenza dello stato di gruppo “molto più difficile” senza un punto di coordinamento forte. Un design mediato da coordinator fornisce avanzamento predicibile delle epoch e una risoluzione più semplice dei commit concorrenti. I partecipanti si connettono al coordinator usando chiavi effimere, così il coordinator apprende l’ID del gruppo e il timing del traffico di commit ma non quali pubkey a lungo termine sono membri. Qualunque parte che interroghi i relay per un gruppo Marmot può già vedere la stessa superficie: attività del gruppo per ID di gruppo, con il timing inferibile dall’arrivo degli eventi. Cordn riconosce anche che “la fiducia di disponibilità resta” con il self-hosting: un coordinator self-hosted evita la preoccupazione di centralizzazione a livello operatore ma introduce un single point of failure per la vivacità del gruppo. Marmot evita quel single point lasciando l’ordinamento a MLS stesso (le epoch e i messaggi Commit gestiscono l’ordinamento all’interno del protocollo) e distribuendo eventi Welcome via gift wrap NIP-59, al costo della disciplina lato admin: gli admin devono aspettare l’acknowledgement del relay di un Commit prima di inviare il Welcome corrispondente, e i client devono riconciliare commit concorrenti quando la consegna del relay va in gara con una transizione di stato.

Il contrasto merita di essere approfondito da qualunque team che scelga uno stack di messaggistica privata. Marmot scambia una certa complessità implementativa per un deployment agnostico ai relay senza attori privilegiati nel percorso. Cordn scambia una dipendenza di disponibilità a punto singolo per un ordinamento più stretto e un modello operativo più semplice. Entrambi i progetti si basano su MLS e usano Nostr come livello di identità e trasporto. Il disaccordo è su dove viva il costo del coordinamento. I repo cordn-msg mostrano una cadenza di commit stabile con il servizio coordinator implementato su ContextVM e il livello MLS costruito su ts-mls.

deepmarks: bookmark NIP-B0 con pubblicazione monetizzata dai curatori

deepmarks-public è un client di riferimento per la spec di bookmark proposta NIP-B0 (kind 39701), con un’architettura a tre riquadri (curatore, indicizzatore, viewer) e un sistema di tier finanziato da zap NIP-57 diretti al curatore. Il client implementa NIP-B0, NIP-07, NIP-46, NIP-57, NIP-44, NIP-98, NIP-65 e Blossom BUD-01 e BUD-04 per lo storage file. Un tier lifetime da 21.000 sat converte lettori paganti in destinatari ricorrenti di zap per il curatore. Il curatore pubblica gli eventi bookmark, l’indicizzatore li arricchisce con metadati leggibili dalla macchina e il viewer rende il feed; ciascun ruolo è un servizio deployabile separato.

Rilasci

Amber v6.1.0 GA: backup cifrato per-account

Amber è passato da v6.1.0-pre3 alla GA v6.1.0 questa settimana. PR #444 rilascia il backup e ripristino cifrati per il database dei permessi dell’applicazione, e PR #446 divide il backup per account, così gli utenti con più identità Nostr possono fare backup e ripristino di ogni set di grant di app indipendentemente. Il lavoro sulla firma PSBT trattato la scorsa settimana è nel taglio GA.

Citrine: sottoscrizioni per-relay e prevenzione di leak di URL onion

Citrine, il personal relay on-device che viene rilasciato con Amethyst, ha rilasciato due correzioni in questo ciclo. PR #157 passa da una singola sottoscrizione globale a sottoscrizioni per-relay taggate, così due relay sorgente che condividono un filtro kinds: [1] non collidono più sul lato aggregatore. PR #162 filtra gli URL di relay onion quando il proxy Tor in uscita è disabilitato, impedendo che gli indirizzi onion trapelino nel percorso di routing clearnet.

Angor v0.2.27 e v0.2.28: affidabilità dei relay e riconnessione Boltz

Angor ha rilasciato v0.2.27 e v0.2.28. PR #874 corregge un bug di deduplicazione dei relay in cui solo un relay era connesso alla volta, una regressione che degradava silenziosamente l’affidabilità per i progetti con più endpoint relay. PR #876 aggiunge logica di riconnessione WebSocket per il monitoraggio degli swap sottomarini Boltz, così una breve disconnessione non lascia più uno swap in uno stato sconosciuto.

Nostrord v1.1.0: zap NIP-57 e distinzione dei ruoli NIP-29

Nostrord ha rilasciato v1.1.0 con supporto agli zap Lightning NIP-57 per messaggi e profili (PR #98) e una distinzione corretta nel feed di attività fra cambi di ruolo NIP-29 e aggiunte di membri (PR #92), che prima si rendevano in modo identico e oscuravano chi era stato promosso rispetto a chi era stato invitato.

ぬるぬる v1.5.x: keystore MLS SQLCipher e catch-up delle epoch

ぬるぬる (nurunuru, di tami1A84), un client Nostr in lingua giapponese che implementa la messaggistica di gruppo MLS (kind 443) insieme a NIP-44, ricerca avanzata NIP-50, NIP-55 e NIP-70, ha rilasciato cinque release questa settimana. PR #184 introduce la cifratura SQLCipher per il keystore MLS nel layer rust-engine. PR #187 e PR #188 estendono SQLCipher rispettivamente ad Android e iOS, con un passaggio di purga legacy-plaintext e guardie CI. PR #189 e PR #191 aggiungono il catch-up delle epoch peer MLS con una replay cache e un banner di recovery su entrambe le piattaforme, così un client che resta indietro sui commit di gruppo può recuperare senza perdere la conversazione. ぬるぬる è un client Marmot costruito su mdk-core, mdk-sqlite-storage e mdk-storage-traits da marmot-protocol/mdk, così il lavoro su SQLCipher e catch-up delle epoch atterra dentro lo stesso runtime MDK che White Noise usa.

Bitcredit Core v0.5.10: correzione della propagazione di blocchi con radice Nostr

Bitcredit Core ha rilasciato v0.5.10 con una correzione per un campo Nostr-node-id mancante durante la propagazione dei blocchi, che rompeva i flussi di creazione azienda che includevano l’upload dell’identità. Bitcredit è un protocollo di e-bill che usa identità Nostr come radice di fiducia per gli eventi di propagazione di aziende e bill.

Modifiche non rilasciate

Jumble ha aperto PR #797 per il login Google tramite il threshold signer Pomegranate, consentendo a un utente di dividere la propria chiave Nostr fra più parti così nessun singolo signer detiene l’intero segreto. Questo è un passo significativo oltre i flussi bunker o import di nsec: un utente può recuperare il proprio account anche se una parte signer è compromessa, senza che quella parte detenga mai la chiave privata completa.

Shopstr ha aperto PR #492 inizializzando un server MCP (Model Context Protocol), con PR #494 che costruisce l’infrastruttura di supporto (fetch dei relay, parser, validazione, errori, deduplicazione, audit logging) e PR #472 che aggiunge una allowlist di relay per il gestore di relay MCP. Ciò rende Shopstr il primo marketplace Nostr a esporre se stesso come server MCP, così gli agenti AI possono navigare e agire su annunci NIP-99 come uno strumento strutturato.

Keydex, il vault di secret-sharing Shamir, ha aperto una migrazione sostanziale in PR #226 spostando i kind custom 1337-1345 nella gamma 713-721, insieme a PR #239 che aggiunge AEAD sopra le share Shamir e PR #234 che migra all’aritmetica GF256. La migrazione della gamma di kind allinea Keydex con il modo in cui il repo NIPs alloca i kind custom, allontanandosi da una gamma auto-reclamata.

Mill (nostr-mill) è una nuova UI di signer Nostr drop-in di OceanSlim (manutentore del relay Go grain), rilasciata come Web Component a singolo script-tag su npm e jsDelivr. Un tag <script> dà a un’app web tutti e sei i punti di ingresso comuni del signer dietro una UI unificata: estensione browser NIP-07, bunker NIP-46 (URL incollato o pairing QR con relay specificabili dall’utente, insolito fra le integrazioni bunker in-pagina), Amber NIP-55 via Android intent, nsec cifrato memorizzato in sessionStorage via AES-256-GCM con PBKDF2, npub read-only e generazione di keypair nel browser. Il componente è personalizzabile tramite 29 proprietà CSS custom collegate allo Shadow DOM ed espone una piccola API tracciata SemVer (MILL.open, eventi mill:connected / mill:disconnected, esportazioni di tema con nome). La motivazione del manutentore è che i flussi di login bunker sono stati re-implementati un’app web alla volta attraverso Nostr. Consolidare su un componente condiviso consente ai client di convergere su come la UX del signer dovrebbe comportarsi, e trasforma flussi opzionali (come il login con chiave delegata tramite threshold signer, che rispecchia il login Google basato su Pomegranate di Wisp trattato sopra) in una superficie riutilizzabile che qualunque app può inserire. Mill è a npm v1.5.0, single-maintainer, stadio alpha, con grain come primo integratore pianificato.

moStard, un fork Monero-first di noStrudel di roguehashrate, ha raggiunto v1.0.1 questa settimana con un set di funzionalità ridotto e un’identità a tema Monero stratificata sullo stesso stack Applesauce + worker-relay. Il lavoro di questa settimana ha portato il rendering per gli eventi software-application di kind 32267 di Zapstore (embed card nella timeline che mostrano nome dell’app, icona, screenshot, piattaforma, licenza e un link di lancio a zapstore.dev/apps/<d-tag>), sondaggi via kind 20 e kind 21, tipping basato su NIP-A3 Payment Targets con QR code per metodo, rendering markdown nelle note, supporto del picker GIF per tastiere GIF esterne e correzioni al pairing del signer Amber. L’inquadratura Monero si estende al flusso di tip: le voci payto NIP-A3 per indirizzi monero ottengono pulsanti di prima classe nella stessa UI insieme a lightning e bitcoin. Il client è single-maintainer e in fase alpha, ma il lavoro del 27 maggio mostra un builder che tira NIP-A3 dagli annunci di spec di protocollo di questa settimana direttamente in un fork rilasciato entro pochi giorni.

Aggiornamenti NIP e lavoro di spec di protocollo

Stack NIP calendario: quattro proposte dal team Formstr

Ix2 (@geralt-debugs) ha aperto quattro PR NIP coordinate il 17 maggio, tutte riferendosi all’implementazione calendar.formstr.app già rilasciata sotto lo stesso autore. PR #2350 propone il kind 84 come un evento generalizzato di “auto-rimozione partecipante”: un partecipante taggato su qualunque evento può pubblicare un kind 84 che fa riferimento all’originale via tag e, a e k per segnalare opt-out. I relay devono validare che il firmatario del kind 84 appaia in un tag p dell’evento di riferimento prima di onorare la rimozione, e un’eliminazione di kind 5 ha sempre precedenza. La PR generalizza un pattern che era precedentemente descritto solo dentro il contesto calendario NIP-52, così il kind 84 diventa il modo standard per i non-autori di ritirarsi da qualunque evento partecipante.

PR #2351 è il fondamento dello stack calendario: NIP-52E per eventi di calendario privati (kind 32678 basato sul tempo, 32681 evento giornaliero, 32123 lista calendario privata, 31926 lista busy, 1052 gift wrap, 52 rumor) e NIP-52R per eventi ricorrenti. Al centro architetturale c’è il pattern view-key: una keypair generata casualmente cifra il contenuto dell’evento con NIP-44, e la metà segreta (codificata bech32 come nsec) è gift-wrapped a ciascun partecipante. Il firmatario detiene solo il tag d pubblico; tutto il resto vive nel content cifrato. Disaccoppiare la cifratura del contenuto dall’identità in questo modo significa che modificare un evento non richiede di re-chiavare i destinatari. NIP-52R definisce due tag opzionali sui kind esistenti 31923 e 31922 per dichiarare la ricorrenza usando valori RFC 5545 RRULE nudi, con l’indice di giorno D che diventa opzionale quando RRULE è presente. La forward secrecy è esplicitamente assente: una view key trapelata rivela tutte le versioni passate e future dell’evento sotto lo stesso tag d.

PR #2352 costruisce su NIP-52E con una spec di programmazione appuntamenti decentralizzata che la descrizione della PR chiama “un’alternativa drop-in a Calendly/Cal.com senza intermediario centrale”. Il kind 31927 pubblicizza una pagina di scheduling con finestre di disponibilità cifrate; il kind 32680 è un record di recovery self-encrypted lato host per la view key; i kind 1057 e 1058 sono la richiesta e la risposta di booking gift-wrapped. Il meccanismo intelligente: il booker genera sia il tag d sia la view key per il futuro evento privato prima di inviare la richiesta, così il booker può aggiungere l’appuntamento al proprio calendario immediatamente con la chiave corretta, e l’host non deve mai fare round-trip di una chiave. Le risposte di booking portano un tag status non cifrato sul wrap esterno così i relay possono filtrare senza decifrare.

Un’implementazione di riferimento è già live a calendar.formstr.app e come app Calendar Android su Zapstore. PR #2351 chiude PR #2027 a suo favore, consolidando una proposta precedente di calendario privato che era aperta dall’inizio dell’anno.

Payment Targets e Silent Payments

Due proposte NIP in più hanno circolato questa settimana in documenti kind:30023 long-form.

Una proposta Payment Targets (NIP-A3 / payto) definisce un evento replaceable di kind 10133 che porta uno o più tag ["payto", "<type>", "<authority>"] che mappano a URI payto: RFC 8905. I tipi supportati includono bitcoin, lightning, ethereum, monero, nano, cashme, revolut e venmo. L’intento è standardizzare un tip jar multi-rail che complementi (non sostituisca) gli zap NIP-57 basati su lud16. Amethyst v1.11.0 è il primo implementatore; le PR mergiate #2953 e #3009 rilasciano la superficie di sottoscrizione e osservazione, e PR #3011 collega la UI per PaymentTargetsEvent.

Due proposte Silent Payments concorrenti sono arrivate da autori diversi. La prima variante deriva le chiavi scan e spend di silent-payment BIP-352 da nsec tramite tweak additivi pubblici, così qualunque mittente può costruire un indirizzo sp1q... da un npub senza setup. L’avvertimento dell’autore è esplicito nella spec: “bscan e bspend DEVONO essere trattate esattamente con la stessa cura di nsec”, perché la chiave di scan rivela l’nsec. Una seconda variante prende l’approccio inverso, aggiungendo un campo sp_address ai metadati profilo di kind 0 contenente un indirizzo silent-payment BIP-352 standard le cui chiavi sono tenute indipendenti dall’identità Nostr. La variante due è strutturalmente più sicura. Entrambe le proposte hanno attratto un thread di review ponderato; erskingardner (lead di Marmot) ha postato un commento dettagliato sul gist trbouma che traccia la proposta. La sua preoccupazione centrale è che la variante 1 deriva la chiave privata di scan da nsec più un tweak calcolabile pubblicamente, il che significa che chiunque detenga la chiave scan (incluso un servizio di scansione di terze parti a cui l’utente deve delegare in pratica) può recuperare il nsec completo sottraendo quel tweak. La stessa chiave che consente a un servizio remoto di scansionare i pagamenti in arrivo per te consente anche a quel servizio di rubare la tua identità e qualunque fondo derivato da essa.

Sul lato NIP-34 git-over-Nostr, hzrd149 ha pubblicato 2 patch a schemata. gitworkshop.dev stesso ha attirato due segnalazioni di issue: una che segnala che le sessioni di login vengono perse al refresh della pagina quando si usa un remote signer NIP-46, l’altra che chiede uno styling di link distinto nelle anteprime README.

Sei anni di May di Nostr

L’ultima newsletter di maggio 2026 fa un passo indietro dai rilasci della settimana per attraversare il mese di maggio nella storia di Nostr. Ogni anno ha avuto un baricentro diverso: il 2021 è stato un singolo commit, il 2022 la formazione del repo NIPs stesso, il 2023 l’esplosione delle spec di protocollo, il 2024 il ciclo di consolidamento, il 2025 quando il negentropy è stato mergiato e Notedeck di Damus è passato a Beta, e il 2026 è il mese trattato in questo e nei tre numeri precedenti.

Maggio 2021

Nostr aveva sei mesi. L’unico codice Nostr viveva in fiatjaf/nostr e l’intero mese ha prodotto esattamente un commit, ma quel commit è diventato una delle parti più usate del protocollo. Il 22 maggio, fiatjaf ha ridefinito NIP-02 come il NIP della lista contatti. Il messaggio di commit recita: “repurpose NIP-02 and add NIP authorship”, e il credito esplicito va alla PR #16 di arcbtc (Ben Arc di LNbits), aperta il 9 febbraio e chiusa il giorno prima che fiatjaf incorporasse l’idea in NIP-02. Il pitch di arcbtc era piccolo: un kind per “inviare la lista dei follower ai relay” che sarebbe stato “utile per ripristinare account e raccomandare chiavi pubbliche da seguire”. fiatjaf lo ha generalizzato in un singolo evento kind:3 i cui tag servono tre scopi contemporaneamente. Sono una lista di follow (il grafo sociale), uno store di petname (nickname locali per gli amici) e una sorgente di raccomandazione di relay (quali relay usa un follow). Lo stesso evento, replaceable per autore, è diventato la risposta canonica a “chi segue questa persona”, “come li chiama” e “dove legge”. Ogni client costruito nei successivi cinque anni legge kind:3. La convenzione aggiunta nello stesso commit, che ogni NIP nomini il proprio autore, è la ragione per cui ogni spec ha ora una firma.

Maggio 2022

Il mese in cui il repo NIPs è diventato un progetto di comunità. Il 1° maggio, fiatjaf ha migrato le spec da fiatjaf/nostr in un repo dedicato nostr-protocol/nips e il 2 maggio ha aggiunto i criteri formali di accettazione. Due giorni dopo, Robert C. Martin (Uncle Bob) ha aperto la PR #1, la prima pull request esterna, proponendo convenzioni di threading per i tag e e p. La PR era originariamente numerata NIP-13, poi rinominata NIP-10 per fare spazio a proof-of-work. Tre dei primi sei NIP sono di Uncle Bob: NIP-10 (threading marker), NIP-14 (il tag Subject) e il commit del 21 maggio che ha fissato kind:1 come il kind canonico di short text-note. Il 5 maggio, William Casarin ha fatto i suoi primi commit NIP: NIP-13 Proof of Work e l’evento kind:2 recommend-relay. Il giorno dopo, fiatjaf ha pubblicato NIP-07 window.nostr, venti righe di markdown che hanno definito l’interfaccia signer browser-extension ancora usata oggi. L’avvertimento CORS di NIP-05 di David A. Harding e il filter.limit di NIP-01 sono arrivati la stessa settimana. nostr-tools ha rilasciato la sua prima build ESM importabile in browser l'8 maggio. Semisol ha redatto NIP-15 (End Of Stored Events) e NIP-16 (event kind ranges) a fine mese, i documenti che ancora governano la semantica di sync dei relay e la classificazione regular-vs-replaceable-vs-ephemeral.

Maggio 2023

L’esplosione di spec di protocollo. Sessantaquattro PR NIP sono state aperte quel mese, con diverse delle proposte che hanno definito la superficie di Nostr per i due anni successivi che sono tutte arrivate in 31 giorni, e il più grande annuncio di finanziamento che Nostr avesse mai ricevuto è arrivato il 4 maggio con il grant OpenSats da 10 milioni di dollari da parte di #startsmall di Jack Dorsey, il denaro che ha finanziato ogni ondata di grant Nostr da allora. NIP-47 (Nostr Wallet Connect) è stato mergiato il 2 maggio, portando la spec di wallet-connect di Alby nel protocollo principale. Due giorni dopo Vitor Pamplona ha proposto NIP-53 Live Activities con room di kind:30311 e messaggi di chat di kind:1311, il fondamento di ogni superficie di livestream Nostr seguita. Pablo Fernandez ha aperto NIP-84 Highlights il 5 maggio e NIP-89 Recommended Application Handlers il 14 maggio. v0l (Kieran Babich, autore di Snort) ha proposto NIP-98 HTTP Auth l'8 maggio, la primitiva di autenticazione da cui NIP-96 e Blossom hanno entrambi in seguito dipeso. Jonathan Staab ha proposto NIP-32 Labels il 15 maggio, e NIP-30 Custom Emoji è stato mergiato lo stesso giorno. Arthur Franca ha proposto NIP-96 HTTP File Storage Integration il 21 maggio. Due giorni dopo, Vitor ha aggiunto gli zap split a NIP-57 e verbiricha ha aggiunto le bozze long-form kind:30024 a NIP-23, la spec che è diventata il fondamento dei moderni workflow di scrittura long-form Nostr in Habla, YakiHonne e Highlighter. fiatjaf ha proposto NIP-29 Simple Groups il 28 maggio, la prima spec di gruppo gestita dal relay che copre gli eventi di moderazione da kind:9000 a kind:9020. Il mese si è chiuso con Paul Miller che apriva la conversazione NIP-44 il 31 maggio, un design di DM cifrato basato su XChaCha20 destinato a sostituire NIP-04. Il lato client si è mosso altrettanto rapidamente: Damus ha rilasciato NWC, zap pool e Pending Zap fra il 10 e il 15 maggio; Snort ha lanciato zap pool e media a paywall L402; Amethyst ha rilasciato circa trenta release versionate nel corso del mese, da v0.40.1 il 1° maggio fino alla gamma v0.55.x a fine mese, con zap split in v0.45.0 ed etichette NIP-32 in v0.46.0; il repo Primal Android è stato creato il 16 maggio; rust-nostr v0.22.0 ha aggiunto NIP-47 e NIP-58. Il 1° maggio, strfry ha rilasciato la sua integrazione negentropy, la prima implementazione relay del protocollo di riconciliazione dei set di Doug Hoyte che sarebbe più tardi diventato NIP-77. Il mese si è chiuso con Forbes che pubblicava un profilo long-form di fiatjaf il 30 maggio, uno dei primi approfondimenti della stampa mainstream sul fondatore anonimo di Nostr.

Maggio 2024

Il ciclo di consolidamento. Meno proposte appariscenti, più cose in rilascio. NIP-54 Decentralized Wikis è stato mergiato il 2 maggio con articoli kind:30818 e tag d normalizzati per case. Tre giorni dopo, NIP-56 è stato esteso così le abuse report potessero segnalare minacce digitali (malware, phishing) accanto alle categorie solo contenuto. Il 6 maggio, le reazioni NIP-25 sono state semplificate per smettere di includere l’intero thread di risposta come tag e. Arthur Franca ha proposto NIP-22 Comment il 12 maggio, introducendo kind:1111 così le risposte a eventi non-kind:1 (articoli, file, prodotti) ottenessero un modo strutturato per fare thread. Il 19 maggio, fiatjaf ha ristrutturato NIP-46 per abbandonare completamente NIP-04 e passare tutto il traffico bunker alla cifratura NIP-44, la mossa di deprecazione che ha plasmato ogni implementazione bunker da allora. Il 20 maggio, NIP-71 Video Events è stato mergiato con kind:21 e kind:22, e NIP-10 ha aggiunto l’argomento pubkey opzionale sui tag e così i client possono risolvere gli autori dei thread senza prima recuperare l’evento di riferimento. NIP-35 Torrents di Kieran Walsh è stato mergiato il 22 maggio, e il 24 maggio il README dei NIP ha per la prima volta fatto riferimento a CIP-01 come una proposta fuori-repo, segnalando l’inizio del pattern “NIP come uno di diversi luoghi di proposta”. Il 25 maggio, una PR di pulizia ha rimosso il tag aes-256-gcm da NIP-71 prima che le implementazioni a valle lo congelassero. NIP-96 ha aggiunto list files e ha eliminato il requisito di transform il 27 maggio. Il 28 maggio, Jonathan Staab ha proposto di alzare l’asticella di accettazione dei NIP per richiedere almeno due implementazioni interoperanti prima che una bozza possa laurearsi. Lato client: Damus ha taggato v1.7.2 e v1.8 più una v1.9 con piena gestione dei marker NIP-10 il 9-10 maggio, ha portato l’autenticazione NIP-98 sulle notifiche push e ha rilasciato il pieno supporto ai marker NIP-10. Amethyst ha reso NIP-17 la modalità DM di default il 14 maggio, ha costruito la gestione dei relay outbox-model NIP-65, ha aggiunto la selezione dei server NIP-96 e ha rilasciato la derivazione di chiavi BIP-32/BIP-39 NIP-06. Primal Android 0.99.2 il 10 maggio ha aggiunto tagging utenti e NWC per wallet esterni, seguita da 0.99.4. Pablo Fernandez ha portato un cluster di optimistic-update NDK dal 24 al 31 maggio. Snort ha aggiunto la selezione dei server NIP-96, e cashu-ts ha separato le sue primitive crypto in @cashu/crypto.

Maggio 2025

Il mese in cui NIP-77 (Negentropy Syncing) è stato mergiato il 27 maggio, la spec di fiatjaf e Doug Hoyte per il wire protocol che sostituisce i filtri REQ brute-force con un calcolo di differenza a costo logaritmico. Questo era lo stesso negentropy che strfry aveva rilasciato due anni prima come funzionalità lato relay, ora formalizzato come protocollo client-relay, e la voce del README è arrivata lo stesso giorno. La settimana prima, NIP-23 long-form ha definito come i documenti HTML si associano a entità Nostr tramite un tag <link> il 24 maggio, la primitiva canonical-web-copy. NIP-25 ha aggiunto gli hint di relay per il target della reazione il 22 maggio e ha abbandonato la raccomandazione emoji-to-like/dislike, trattando le emoji come unità semantiche distinte. NIP-52 è stato semplificato il 14 maggio per focalizzarsi sui kind che i client stavano rilasciando in produzione, la sfoltita che ha reso le estensioni calendario di Formstr di un anno dopo più pulite da innestare. Il 9 maggio, Follow Pack (liste di follow curate di kind 39089) e Favorite Relay (una nuova lista replaceable sotto NIP-51) sono entrati nel README lo stesso giorno. L’arco del Protocollo Marmot non era ancora cominciato: esisteva solo il repo whitenoise-rs (primo commit 9 settembre 2024), e maggio 2025 era la sua fase di prototipo Svelte+Tauri, con il commit del 14 maggio che rimuoveva codice specifico di Tauri mentre il progetto pivotava alla sua architettura attuale. Il core Rust dedicato MDK (12 settembre 2025), il repo spec di Marmot (19 settembre 2025) e la UI Flutter (2 dicembre 2025) sono tutti arrivati dopo nell’anno. Sul lato client, Notedeck v0.4.0 di Damus è stato rilasciato il 5 maggio come prima Beta, laureandosi da Alpha con full-text search, l’assistente AI Dave, zap su NWC, GIF, tagging utenti e mute list. Due giorni dopo, Flotilla 1.0.0 di hodlbod ha attraversato il confine del lancio pubblico come client di group-chat basato su NIP-29, insieme a Coracle 0.6.12, la prima di sei release Coracle che si sono estese fino a 0.6.17 il 14 maggio. Amber v3.4.0 il 12 maggio si è spostato dalle API Autofill e ClipboardManager Android deprecate ed è migrato dalle encrypted shared preferences a DataStore. Primal Android 2.2.20 il 20 maggio ha aggiunto il flusso Redeem Code per Primal Premium e una galleria immagini ridisegnata. nak v0.14.0 il 21 maggio ha tagliato una minor della CLI canonica nella stessa settimana delle release di Coracle, Flotilla e Notedeck. OpenSats ha ricevuto la sua più grande donazione non-Bitcoin-treasury a oggi quando la Reynolds Foundation ha dato 2 milioni di dollari il 22 maggio.

Maggio 2026

Il mese trattato in Newsletter #21, #22, #23 e in questo numero. Il filo definitorio è MLS-on-Nostr che raggiunge produzione multi-client: MDK 0.8.0 ha rilasciato le primitive di leaf-index MIP-05 e i key package indirizzabili, seguito da PR #306 che aggiunge la validazione di messaggi a scomparsa NIP-40 su iOS e Android tramite una superficie UniFFI condivisa. White Noise v2026.5.22+25 ha rilasciato la push iOS tramite una Notification Service Extension che decifra il ciphertext MLS dentro il processo dell’extension così il broker non vede mai plaintext, e sono apparsi due nuovi client Marmot: Scramble (un client desktop e Android .NET/Avalonia con slot KeyPackage multi-dispositivo) e Cordn (un’architettura MLS alternativa che usa un coordinator per-gruppo su ContextVM). Angor ha migrato la sua messaggistica cifrata da NIP-04 a NIP-44 in PR #860, chiudendo l’arco di deprecazione aperto con la proposta NIP-44 di Paul Miller nel maggio 2023. Il team Formstr ha aperto la più grande submission NIP coordinata a memoria recente il 17 maggio, con PR #2350 per l’auto-rimozione dei partecipanti, PR #2351 per eventi di calendario privati e ricorrenza (NIP-52E e NIP-52R) e PR #2352 per la programmazione decentralizzata di appuntamenti, tutti con calendar.formstr.app che già rilascia l’implementazione di riferimento. Amethyst v1.11.0 ha reso i calendari NIP-52 come una categoria di timeline nativa e ha esteso gli zap Bitcoin onchain a distribuzioni split. Un anno dopo che NIP-77 è stato mergiato nel maggio 2025, tre implementazioni indipendenti hanno rilasciato l’adozione negentropy nella stessa finestra: Notedeck PR #1459 l’ha collegata al client desktop di Damus per giftwrap e backfill dei thread, Vector v0.4.0 ha usato la sync MLS full-negentropy come parte del suo rewrite da zero di vector-core insieme al Tor one-click e a una superficie di agente MCP a 21 tool, e Citrine v3.0.0-pre1 l’ha aggiunta al relay Android-nativo insieme a Tor integrato e aggregazione multi-relay. Mostro v0.17.4 ha chiuso il ciclo del bond anti-abuso con i payout di bond slashati di Fase 3 in PR #738, facendo rispettare ciò che il protocollo prima solo minacciava. Tre anni da “sostituiamo NIP-04” a “sostituiamo NIP-44 con lo stato di gruppo MLS completo”.

Se vuoi discutere, mandaci un DM su Nostr.