Nostr Compass #28 | Nostr Compass

Bentornati su Nostr Compass, la vostra guida settimanale a Nostr.

Questa settimana: Sprout cambia nome in Buzz e inizia a pubblicare persona, team e record degli agent gestiti come event sui relay Nostr, mentre lo stato di lettura tra dispositivi e i marcatori di lettura per messaggio sostituiscono il vecchio modello della soglia dei badge. Napplets di sandwich.farm debutta come protocollo con un confine di fiducia per app Nostr componibili distribuite tramite Nostr e Blossom. Conduit, un monorepo di marketplace su Nostr con tre app (mercato per acquirenti, portale per commercianti e generatore di negozi, con directory NIP e specifiche proprie nel repository), integra 17 PR che irrobustiscono l’MVP del marketplace, passa al proprio relay pubblico per impostazione predefinita e aggiunge analytics rispettosi della privacy. BitBlik pubblica un protocollo di scambio P2P da BLIK a Lightning tramite DM Nostr cifrati, con un coordinatore che regola atomicamente fra valuta fiat e hold invoice Lightning. Amethyst fa seguito al lancio della scorsa settimana dedicato a wallet, podcast e allenamenti con Health Connect Workouts, Road Events, risposte comprimibili, monitoraggio dello stato della latenza relay con classificatore e una correzione per la notarizzazione macOS. Amber implementa l’estensione dei metadati client di NIP-46 proposta la scorsa settimana, mostrando icone e identità delle app native nelle schermate delle richieste del signer. Haven lancia la condivisione privata della posizione sul protocollo di messaggistica cifrata Marmot. CodeDeck consente di controllare dal telefono le sessioni Claude Code in esecuzione sul portatile tramite relay Nostr cifrati, poi riduce l’abbinamento a una sola scansione QR e aggiunge la selezione del modello per sessione. Grain pubblica una libreria client Nostr importabile in Go che usa il modello outbox. Mostro Core, Wisp insieme a Dark Wisp, Citrine, FIPS, Kubo (canali YouTube selezionati dai genitori e feed per bambini obbligatoriamente protetto dalla fiducia) e Pollerama (un punteggio web-of-trust, un motore relay on-device e una sezione «Persone che potresti conoscere») pubblicano patch successive. Il lavoro non ancora rilasciato comprende un coordinatore MLS nel browser di sandwich.farm, lo sprint di iterazione UX di nostter, la correzione NIP-46 tra progetti e la revisione del composer di Zap Cooking, il ciclo di escrow Cashu di Shopstr, divine.video e Nostur. Fra i nuovi progetti monitorati figurano Social Agents Prototype, PRana per il triage delle issue git-over-Nostr e routstr-chat. Sul fronte del protocollo, NIP-99 riceve una proposta di checkout ed escrow on-graph direttamente collegata al lavoro di Conduit, BitBlik e Shopstr sul commercio. Poiché questo è l’ultimo Compass di giugno, il numero si chiude con Sei anni di giugno su Nostr.

Storie principali

Da Amethyst v1.12.1 a v1.12.6 dopo il lancio della v1.12.0

Amethyst ha fatto seguire al lancio della v1.12.0 della scorsa settimana sei patch rapide fra mercoledì e venerdì. La v1.12.1 aggiunge Health Connect Workouts e un’azione Share-as-Image e rende deterministico il flag Active di Tor, così la callback di bootstrap non può entrare in race con il gate. La v1.12.2 aggiunge Road Events e risposte comprimibili, la v1.12.3 introduce il monitoraggio dello stato della latenza relay con classificatore e dashboard, oltre a una correzione per la notarizzazione macOS, mentre dalla v1.12.4 alla v1.12.6 arrivano passaggi di traduzione Crowdin e l’automazione dei crediti ai traduttori.

Sprout cambia nome in Buzz e pubblica persona, team e agent gestiti come event relay

Sprout, lo spazio di lavoro self-hostable di Block in cui persone e agent AI collaborano negli stessi canali e ogni messaggio, reazione, passaggio del workflow, approvazione di revisione ed event git viene scritto come event Nostr firmato, questa settimana è stato rinominato Buzz. GitHub ora reindirizza il vecchio slug block/sprout a block/buzz; repository, licenza e direzione del prodotto non sono cambiati. Tutti i riferimenti a Sprout nei numeri precedenti riguardano lo stesso progetto.

Insieme al cambio di nome, la settimana ha portato un lavoro sostanziale sul prodotto. Persona, team e record degli agent gestiti ora vengono pubblicati come event sui relay Nostr tramite la PR #1189, consentendo alla stessa identità agent di comparire in più spazi di lavoro e audit log senza duplicare lo stato. Un nuovo pannello desktop mostra sui profili le attestazioni del proprietario NIP-OA (PR #1198); la soglia dei badge non letti nei thread dei canali è stata sostituita da marcatori di lettura per messaggio, così i conteggi restano accurati fra dispositivi (PR #1178); e la posta in arrivo aggiunge attribuzione dell’autore e della fonte agli event promemoria (PR #1176).

I canali temporanei ora scadono per impostazione predefinita dopo 7 giorni (PR #1182); gli override dei relay per agent rispettano il relay configurato prima di ripiegare su quello predefinito dello spazio di lavoro (PR #1131); e la build Windows ora include una toolchain Git for Windows completa per lo strumento shell (PR #1145).

Napplets: app Nostr componibili con un confine di fiducia definito

Questa settimana Sandwich.farm ha annunciato napplet.run, un protocollo per applet Nostr componibili, o napplet: piccoli programmi che svolgono una sola funzione, vengono eseguiti in ambienti sandbox e sono risolti tramite Nostr e Blossom usando la stessa forma di event degli nsite. Il progetto è distribuito su tre repository: napplet/web, che contiene i pacchetti web e questa settimana ha pubblicato in un lancio coordinato 51 tag di versione per i sottopacchetti (@napplet/core, @napplet/sdk, @napplet/nap, @napplet/shim, @napplet/conformance); napplet/naps, il filone di specifiche NAP con 15 PR integrate; e kehto/web, il runtime web con 41 PR integrate e un playground su kehto.github.io/web/playground. La PR di specifica corrispondente è NIP-5D #2303, aperta da dskvr (sandwich.farm).

La premessa architetturale è un confine di fiducia definito a livello di protocollo. Una shell media le operazioni pericolose (firma, accesso alle chiavi, scritture sui relay), un runtime gestisce l’implementazione e l’UX di livello superiore, mentre i napplet restano portabili, usa e getta e più difficili da catturare per un singolo host. I napplet possono comunicare fra loro attraverso la stessa shell e, per progetto, non esiste lock-in del runtime. L’autore mette i napplet in dialogo con NMP (di Pablof7z) e Tiles (di Soapbox), presentandoli come interpretazioni parallele dello stesso problema, e osserva che il supporto NIP-5A e NIP-5D di Amethyst v1.12.6 offre ai napplet almeno un client già distribuito al lancio. È incluso anche un filo storico: il precedente napp.run di sandwich.farm, un prototipo di app nativa NIP-07, e il browser dryft, fork di Thorium, hanno entrambi contribuito al progetto attuale prima di essere accantonati.

Conduit irrobustisce l’MVP del marketplace e passa al relay pubblico per impostazione predefinita

Conduit è il monorepo con tre app del marketplace su conduit.market, ossia Market per gli acquirenti, Merchant Portal e Store Builder, sotto l’organizzazione Conduit-BTC. Comprende directory nips/ e specs/ proprie che definiscono primitive commerciali Nostr specifiche di Conduit, con l’estensione khatru Scope-2 Conduit-BTC/conduit-relay in esecuzione sotto il sistema. Entrambi i repository sono stati aperti all’inizio dell’anno; questa settimana il progetto ha integrato 17 PR per irrobustire l’MVP del marketplace.

Le PR distribuite si concentrano sulla correttezza del marketplace: stati di sicurezza delle inserzioni (PR #110) e rafforzamento lato commerciante dei prezzi dei prodotti e delle zone di spedizione (PR #115). Sul lato relay, la PR #102 corregge il rilevamento delle capacità commerciali, la PR #112 ignora gli hint di relay insicuri forniti da terzi e la PR #128 imposta il dominio del relay pubblico di Conduit come predefinito per i nuovi client. Analytics rispettosi della privacy arrivano nelle PR #109 e #129, mentre un aggiornamento di dompurify chiude un advisory OSV (PR #116). Il lavoro si colloca in una più ampia ondata commerciale NIP-99 di questa settimana: la PR #2323 propone per i mercati NIP-99 un livello di checkout on-graph che copre flusso dell’ordine, escrow e controversie; la storica Gamma Markets Market Spec, che estende NIP-99 per l’e-commerce completo, diventa il livello di specifica su cui costruiscono Conduit e altri; e Shopstr ha distribuito nello stesso periodo un ciclo di escrow Cashu.

BitBlik lancia su Nostr un protocollo di scambio P2P da BLIK a Lightning

BitBlik è stato aperto questa settimana come protocollo peer-to-peer di scambio BLIK ↔ Lightning costruito su Nostr. BLIK è il sistema di pagamento istantaneo emesso dalle banche polacche; il coordinatore BitBlik regola atomicamente fra fiat BLIK, pagata dai taker, e hold invoice Lightning, finanziate dai maker, mentre il ciclo della transazione avviene su Nostr. L’app Flutter, la CLI e il coordinatore condividono un pacchetto core; il progetto viene distribuito dal monorepo GitHub bit-blik/bitblik, dalla build web www.bitblik.app e dall’app Zapstore app.bitblik.

Il protocollo usa messaggi diretti Nostr cifrati (NIP-44) per l’RPC client-coordinatore. Le offerte sono pubblicate come event sostituibili parametrizzati di kind 38383, le richieste RPC sul kind 25195, le risposte RPC sul kind 25196 e gli aggiornamenti di stato sul kind 25197. Il coordinatore trattiene una hold invoice Lightning mentre un taker invia un codice BLIK, rilascia la preimage quando il trasferimento BLIK è confermato e instrada il regolamento dell’invoice al maker.

Release con tag

Amber v6.2.2 implementa i metadati client NIP-46

Amber, il principale signer remoto Android NIP-46 mantenuto da greenart7c3, ha pubblicato la v6.2.2 nella stessa settimana in cui è stata integrata la PR di specifica corrispondente. La release mostra le icone delle app native e i nuovi campi dei metadati client nelle schermate delle richieste e nell’elenco delle app, conserva i metadati client a ogni connessione e acquisisce icona e nome dell’app nativa al momento della connessione e dell’accettazione. La modifica è direttamente collegata alla PR NIP-46 #2381 di DocNR, che aggiunge metadati client opzionali alla richiesta di connessione, così i signer possono mostrare un nome e un’icona significativi per chi fa la richiesta. Amber v6.2.2 aggiunge inoltre il supporto all’event kind 30618 e separa relay predefiniti e relay della connessione nella schermata Active relays.

La release restringe la superficie di sicurezza del signer. I corpi decifrati di richieste e risposte NIP-46 non finiscono più nei log, mentre i payload di cifratura e decifratura sono memorizzati come ciphertext e decifrati su richiesta. Tutto l’output logcat è subordinato a BuildConfig.DEBUG, i chiamanti browser (con pacchetto nullo) sono costretti a chiedere sempre conferma e le copie negli appunti di nsec, ncryptsec e parole seed vengono contrassegnate come sensibili e cancellate dopo un intervallo. Sono aggiunte esclusioni esplicite di backup ed estrazione dati come difesa in profondità. La release corregge anche un crash dovuto allo scrolling annidato in Active relays, un crash per chiavi duplicate di LazyColumn causato da una race nella deduplicazione delle richieste bunker e una race EOSE nel controllo degli aggiornamenti.

Haven è stato aperto questa settimana come app Android e iOS privata e resistente alla censura per la condivisione della posizione, eseguita su Nostr tramite il protocollo Marmot. Il repository ha pubblicato cinque release, dalla v0.1.0 alla v0.1.4, nell’arco di quattro giorni: le prime release di un nuovo progetto. Haven è sviluppato in Dart e Flutter e distribuito tramite Zapstore come app firmata dallo sviluppatore. Marmot, il livello di messaggistica end-to-end cifrata basato su MLS per Nostr, fornisce lo stato di gruppo e la distribuzione del ciphertext; Haven estende questo schema dalla messaggistica alla condivisione della posizione, con lo stato cifrato di ciascun gruppo che trasporta gli aggiornamenti della posizione che il gruppo ha acconsentito a condividere.

CodeDeck: coding agentico remoto tramite Nostr

CodeDeck è stato aperto questa settimana come interfaccia per coding agentico multisessione su Android e desktop, costruita con Tauri v2, React 19 e un backend Rust, che permette di controllare dal telefono sessioni Claude Code in esecuzione su un portatile tramite relay Nostr cifrati. Il progetto ha pubblicato v2026.06.17, v2026.6.18 e v2026.6.20 nello stesso intervallo di quattro giorni. Il modello di trasporto usa Nostr come piano di controllo cifrato: un telefono con CodeDeck pubblica comandi come event cifrati a cui si iscrive il bridge accanto al portatile, e il portatile pubblica l’output della sessione sugli stessi relay.

La v2026.06.17 incorpora la mesh FIPS di nostr-vpn come servizio VPN Android dell’app, così un portatile può compilare, installare, avviare e controllare da qualsiasi luogo le build di sviluppo di un’app su un telefono fisico di test, con CodeDeck come unico software installato sul telefono. La v2026.6.18 unifica abbinamento e invito alla mesh in una singola scansione QR, mentre la v2026.6.20 aggiunge la selezione del modello per sessione, così ogni sessione parte con il modello scelto.

Grain v0.8.0-rc1 pubblica un motore client Nostr completo

Grain, il relay Go mantenuto da 0ceanSlim, ha taggato v0.8.0-rc1 ed è ora sia un relay Nostr sia la libreria client Go importabile su cui esso stesso è costruito. Mentre la serie v0.7.x si concentrava sulla gestione del relay da browser, la linea v0.8 distribuisce client/core, un motore client Nostr autonomo e puro Go basato sul modello outbox, senza dipendenze cgo o HTTP. Il motore gestisce un pool di relay condiviso, risolve gli elenchi relay di ogni utente e instrada letture e pubblicazioni secondo il modello gossip / outbox: si leggono le note di un utente dai suoi relay outbox e una risposta pubblicata raggiunge i relay inbox dell’autore della nota parent. Il frontend web di Grain è ora il consumer di riferimento della libreria, quindi l’interfaccia è sia un’app utilizzabile sia un esempio completo per progetti Go downstream.

La release introduce cifratura NIP-44 nativa (v2 e v3), AUTH relay NIP-42, elenchi relay NIP-65, NIP-17, NIP-51 e NIP-37, tag client NIP-89 e supporto media Blossom più NIP-96. Le app Go downstream che prima dovevano reimplementare l’instradamento relay ora possono semplicemente fare import del motore.

Mostro Core v0.13.1 fa seguito a Protocol v2

Mostro Core ha pubblicato v0.13.1 come seguito al rollout di Protocol v2 della scorsa settimana, introducendo una variante di errore PriceTooStale per il contratto del price feed del protocollo. Sul lato daemon, questa settimana la PR #752 fa sì che gli ID ordine non validi vengano mostrati ai client come errore CantDo(NotFound) invece di essere ignorati senza risposta; la PR #785 fa seguire alla versione interna del protocollo il trasporto attivo; la PR #778 introduce la fase 3 del provider El Toque per i cambi fiat CUP e MLC; e la PR #782 rinomina il tag informativo NIP-33 da protocol_versions a protocol_version per allinearlo alla specifica.

Wisp v1.1.2 e la variante Dark Wisp

Wisp, il client Android Kotlin e Jetpack Compose di barrydeen, ha pubblicato v1.1.2, che mantiene distinti i passaggi di wallet verso se stessi nell’ordine deterministico delle transazioni (PR #586), crea in modo lazy i player video inline per resistere alle note ricche di media (PR #592), corregge una ConcurrentModificationException nell’insieme event-relay (PR #595) e risolve un problema di misurazione intrinseca del contenuto delle bolle di chat per evitare un crash di SubcomposeLayout (PR #596). La release introduce anche un filtro feed incrementale con valutazione dello spam fuori dal lock. Questa settimana il team Wisp ha inoltre pubblicato su Zapstore Dark Wisp v1.1.0, una variante multivaluta che aggiunge obiettivi zap ZEC, DASH, BCH e LTC più una modalità anonima.

Citrine v3.0.1

Citrine, il relay Nostr locale Android di greenart7c3, ha pubblicato v3.0.1 con una sola correzione: la rimozione della registrazione di un receiver Pokey non registrato non provoca più un crash del relay.

FIPS v0.4.0-rc2

FIPS, il Free Internetworking Peering System, ha taggato v0.4.0-rc2 come release candidate di convalida del packaging basata sul formato wire v0.3.x. La linea v0.4.0 aggiunge un trasporto mixnet Nym e discovery LAN mDNS opzionale per la raggiungibilità dei peer, rivede il piano dati per ottenere più throughput su singolo nodo e meno CPU per pacchetto, sposta la superficie operativa di lettura fuori dall’hot path del piano dati affinché l’osservabilità resti reattiva sotto carico, distribuisce una TUI fipstop rielaborata e irrobustisce il rekey FMP e FSP affinché non interrompa il traffico in caso di perdita di pacchetti. Questa è una release candidate; la versione stabile v0.4.0 era prevista provvisoriamente per il 21 giugno 2026.

Kubo v2026.06.12 e v2026.06.20 bloccano il feed per bambini protetto dalla fiducia e aggiungono YouTube selezionato dai genitori

Kubo, l’alternativa Nostr-native a YouTube Kids di JeroenOnNostr costruita sul Trust Extended Permissions Protocol (TEPP), ha pubblicato due release questa settimana. La v2026.06.12, con versionamento a calendario e versionCode derivato YYYYMMDD, rende obbligatorio il feed per bambini protetto dalla fiducia: ogni post, profilo, reazione e repost che il bambino può vedere o con cui può interagire passa ora attraverso TEPP, limitato alle persone ammesse dal genitore. Le nuove installazioni iniziano con il gate di fiducia attivo e la cerchia del bambino inizializzata durante l’onboarding, così il feed è sicuro dal primo avvio. La release introduce anche chat di gruppo gestita per i genitori, instrada gli event di fiducia verso il set di relay privati della famiglia e fallisce in modo chiuso, senza mostrare nulla invece di far trapelare contenuti non verificati, se i dati di fiducia non possono essere caricati.

La v2026.06.20 aggiunge canali YouTube selezionati dai genitori: i genitori possono cercare un canale e aggiungerlo al feed dei bambini, affinché questi vedano soltanto video da canali approvati, con una corsia HTTP veloce e un’interfaccia ottimistica che sostituiscono il percorso di aggiunta da circa 10 secondi. La release rimuove anche l’opzione per disattivare Trust Extended Permissions, poiché il progetto è costruito attorno alla fiducia obbligatoria e l’interruttore è ora sempre attivo; aggiunge una pagina Support dedicata; corregge le @mention nella chat di gruppo affinché il tag mostri il nome cliccabile @name invece di un nostr:npub1… grezzo; aggiunge il completamento automatico delle mention; e corregge la pubblicazione della fiducia affinché dipenda dallo stato di enforcement reale invece che da un flag specchio. Entrambe le release sono monitorate tramite Zapstore come app Android com.kubo.app firmata dallo sviluppatore.

Da Pollerama v1.9.0 a v1.9.4: punteggio web-of-trust, motore relay on-device e sezione «Persone che potresti conoscere»

Pollerama di abh3po, il client della famiglia Form* per sondaggi e feed Nostr su pollerama.fun, ha pubblicato cinque release su Zapstore questa settimana. La v1.9.0 introduce un nuovo motore relay on-device: un relay locale integrato memorizza ora tutto ciò che l’utente ha visto e risponde prima di tutto dalla cache locale, così feed, profili e thread si caricano immediatamente, anche offline, e restano sincronizzati con la rete in background. Tutto il traffico relay, in lettura e scrittura, passa attraverso questo motore fuori dal thread principale; note, profili, reazioni e zap già caricati provengono direttamente dall’archivio locale invece di essere recuperati di nuovo.

La v1.9.2 corregge le viste Home e Notes, e qualsiasi vista Following/Network, che talvolta non mostravano nulla all’avvio o alla ripresa, memorizzando la lista dei follow indipendentemente dal motore di sincronizzazione; rende affidabile il caricamento delle note condivise nei DM recuperando la nota indicata dagli hint relay anche quando l’utente non segue l’autore; e aggiunge un pannello Network nelle impostazioni che mostra connessioni relay, dimensione della cache e stato di sincronizzazione, con controlli per riconnettere o cancellare la cache locale. La v1.9.3 corregge un crash all’avvio e una regressione nel caricamento del feed Home.

La v1.9.4 introduce un punteggio di fiducia web-of-trust sui profili, cioè quante delle persone seguite seguono anche quella persona, mostrato come chip di rete, e una sezione «Persone che potresti conoscere», con suggerimenti di follow ricavati dal web-of-trust e ordinati per numero di follow in comune. Le impostazioni Network mostrano ora dimensione del web-of-trust e ora dell’ultimo calcolo, con un pulsante per ricalcolarlo su richiesta. Punteggi di fiducia e raccomandazioni vengono calcolati in background dal worker web-of-trust, così non bloccano l’app.

Release minori con tag

nogringo/nostr-mail-client v0.13.1 ripristina il login tramite app signer NIP-55 per Amber, Aegis e Primal e smette di chiedere ripetutamente alle app signer di firmare i contatti. Cameri/nostream v3.0.0 rimuove unsafe-inline dal generatore della web app e implementa nonce per gli script. LaWallet NWC v1.0.0 pubblica la prima 1.0 del progetto con attivazione tramite scheda con link QR condivisibile, riconoscimento Remote Wallet e provisioning automatico dell’indirizzo Lightning. Da Formstr Nostr Calendar v2.0.0 a v2.0.2 aggiungono una PWA, correggono gli event sostituibili offline (PR #194) e associano i metodi del signer affinché l’invio di moduli privati funzioni (PR #199). Completano la settimana release minori di Spl0itable/NYM, codeswot/ZapBook, 77elements/noornote, mattn/nostr-relay, mattn/algia, mouse484/astraea, dergigi/boris, fiatjaf/nak, Spl0itable/nosflare e nostrord/nostrord.

Modifiche non ancora rilasciate

Cordn Ad-hoc CVM: un coordinatore MLS nel browser

Cordn Ad-hoc, la nuova web app di sandwich.farm, viene aperta pubblicamente questa settimana come coordinatore MLS eseguito in una scheda del browser per gruppi Cordn ad hoc. Lo schema è insolito: una scheda del browser esegue il processo coordinatore Nostr ContextVM, pubblica la propria pubkey, riceve richieste MCP tramite relay Nostr e memorizza nel browser pacchetti di chiavi MLS, welcome, richieste di join e messaggi di gruppo, senza backend. L’app impedisce l’esecuzione simultanea di più coordinatori con la stessa pubkey ed espone un log di debug per l’operatore con event Nostr grezzi, richieste decodificate e heartbeat delle istanze.

SnowCait/nostter pubblica 19 PR di iterazione UX

nostter, il client web Nostr di SnowCait, ha integrato 19 PR questa settimana senza pubblicare una release. La sostituzione di nostrapp.link con app-manager.nostter.app (PR #2234) e l’aggiunta di deck.nostter.app all’allowlist frame-ancestors (PR #2233) consolidano la superficie del progetto sotto il dominio nostter.app. Gli event sostituibili delle persone seguite vengono memorizzati in IndexedDB (PR #2231) e lo stato seen-on dei relay torna reattivo con opzioni separate seen-on e via (PR #2230).

Zap Cooking corregge un bug NIP-46 tra progetti e rivede il composer

Zap Cooking, il client Nostr per la condivisione di ricette, ha integrato 16 PR questa settimana. La modifica dall’impatto più ampio è la PR #452: i signer remoti Primal marcavano gli event con la pubkey del signer stesso, interrompendo upload, zap e autenticazione per qualsiasi client instradato attraverso Primal. Zap Cooking ha individuato e corretto il percorso; la correzione è locale al client, ma il bug esiste in tutto lo spazio NIP-46. Il composer viene ricostruito nella PR #458 con conto alla rovescia, interfaccia unificata per risposte e commenti e schede Write/Preview. Tre correzioni SSR (PR #460, PR #461, PR #462) e la PR #454 stabilizzano le route di profili e ricette. L’esperienza Explore riceve righe con trascinamento per scorrere, un cursore avatar con link al profilo e una correzione delle schede sticky per le community (PR #456).

Shopstr pubblica un ciclo di escrow Cashu e strumenti per le vetrine

Shopstr, il marketplace NIP-99, ha integrato una serie di PR sostanziali questa settimana. La PR #512 implementa per il marketplace un ciclo di escrow Cashu P2PK end-to-end, collegandosi alla più ampia ondata commerciale della stessa settimana attraverso la PR NIP-99 #2323, proposta per un livello checkout on-graph, e il lancio di Conduit. Nella PR #543 arrivano strumenti di lettura per elencare aziende, ottenere dettagli aziendali, recuperare una vetrina e ottenere la reputazione del venditore. La PR #229 aggiunge il supporto all’incollaggio di URL per immagini di profilo e negozio, mentre la PR #359 aggiorna il recupero delle statistiche del marketplace includendo un timestamp.

Lavoro su divine.video mobile e desktop

divine.video, il client di rabble per video brevi in loop con gli archivi Vine ripristinati, questa settimana ha integrato PR concentrate su riproduzione e montaggio: i video indirizzabili vengono deduplicati nel feed (PR #5465), i filtri locali dei tag Nostr ora richiedono corrispondenze esatte per evitare risultati spurii (PR #5463), l’editor video recupera senza crash le bozze con livelli di sticker (PR #5474) e il badge Messages conta le chat non lette di persone seguite a cui non è ancora stata data risposta (PR #5473).

Nostur pubblica supporto ai metadati client NIP-46 e correzioni al refresh dei DM

Nostur, il client iOS di Fabian, ha integrato quattro PR nel repository canonico dopo la release 1.29.0 della scorsa settimana. La PR #74 aggiunge metadati client alle richieste di connessione bunker NIP-46, la stessa forma proposta da DocNR e pubblicata da Amber v6.2.2 questa settimana. Le PR #75 e #76 correggono i percorsi di refresh dei DM e ripristino in primo piano dopo il ritorno in foreground di un iPhone, mentre la PR #78 aggiunge la scansione QR alla configurazione NWC personalizzata.

Nuovi progetti monitorati e scoperti

Social Agents Prototype è uno strumento AI sperimentale costruito su Nostr che esplora la comunicazione decentralizzata fra agent. Gli agent trasmettono domande atomiche attraverso la rete, rispondono soltanto quelli pertinenti e ogni messaggio inviato o ricevuto passa da un gate di approvazione umana prima del transito. L’autore è Sruly Rosenblat. Il progetto occupa lo stesso spazio di collaborazione fra agent di Buzz e NIP-100 SNIN di questa settimana, ma assume una forma diversa: Social Agents Prototype modella gli agent come partecipanti che trasmettono e ascoltano, i cui messaggi devono essere tutti approvati da una persona. Questa settimana sono visibili più approcci paralleli allo stesso problema.

PRana: una lista di lavoro per issue NIP-34

PRana di DocNR è una lista di lavoro di issue NIP-34 aperte correttamente fra repository git-over-Nostr con adesione volontaria. Lo strumento si colloca un livello sopra lo stack git-over-Nostr: consuma gli event issue NIP-34 dei repository partecipanti e li presenta come coda di triage. Il lancio arriva nella stessa settimana in cui la PR NIP-34 #2384 propone di rimuovere il tag maintainers per risolvere problemi di scadenza, modifica che incide direttamente sul modo in cui strumenti come PRana risolvono l’autorità sulle issue fra repository.

routstr-chat: accesso a LLM locali tramite il protocollo Routstr su Nostr

routstr-chat del team Routstr è un’interfaccia di chat interamente locale che usa il protocollo Routstr per accedere a qualsiasi modello LLM tramite Nostr. Il protocollo Routstr instrada le richieste di inferenza attraverso annunci dei provider pubblicati su Nostr (kind 38421) e regola i pagamenti con Cashu, come descritto nella Newsletter #20. Il client chat è la superficie rivolta all’utente sopra il protocollo; il daemon di instradamento Routstrd gestisce discovery e pagamento, mentre l’app chat fornisce l’interfaccia della conversazione.

Lavoro sul protocollo

Aggiornamenti NIP

L’attività NIP della settimana è stata insolitamente intensa: due integrazioni e un’ondata di proposte aperte sostanziali.

I metadati client NIP-46 arrivano in Amber e Nostur

La PR NIP-46 #2381, proposta da Clave la scorsa settimana, dispone ora di implementazioni distribuite su entrambi i lati. Amber v6.2.2 legge il nuovo campo opzionale optional_client_metadata nelle richieste di connessione bunker e mostra icone e metadati delle app native nelle schermate delle richieste e nell’elenco delle app. La PR Nostur #74 aggiunge il campo sul lato client. Insieme, i tre progetti chiudono la lacuna d’identità nell’abbinamento bunker: un abbinamento bunker:// ora trasporta gli stessi name, url e image che un’app poteva già annunciare tramite nostrconnect://.

NIP-86 signevent e un event complementare per i ruoli relay

La PR #2389 di staab ha integrato un’operazione signevent in NIP-86, l’API di gestione relay, consentendo agli amministratori dei relay di gestire event NIP-43 per conto del relay. La proposta complementare ancora aperta, PR #2390 di staab, definisce un event per i ruoli relay, così i relay possono dichiarare le definizioni dei ruoli e gli amministratori possono assegnare o revocare quei ruoli ai membri. Le due PR sono progettate per comporsi: NIP-86 fornisce agli amministratori le operazioni, l’event dei ruoli fornisce il modello di autorizzazione.

NIP-99: livello di checkout on-graph per i marketplace

La PR #2323 di Colabonate è il collegamento centrale più forte della settimana. La proposta è formulata come richiesta di feedback sul progetto e individua due lacune nello stack NIP-99 e Gamma Market Spec: un flusso di checkout che vive on-graph, con stato successivo al buy-now, creazione dell’ordine, pagamento e conferma della consegna come event Nostr pubblici e indirizzabili leggibili da qualsiasi client; ed escrow più risoluzione delle controversie per il sottoinsieme di transazioni in cui i segnali web-of-trust da soli non bastano, come articoli di valore elevato, controparti alla prima transazione, marketplace anonimi e consegna fisica. La proposta chiude i silos fra client nei marketplace allo stesso modo in cui NIP-99 ha chiuso quelli delle inserzioni. Arriva nella stessa settimana del lancio di Conduit, che distribuisce directory nips/ e specs/ proprie, della PR Shopstr #512, con un ciclo di escrow Cashu end-to-end, di BitBlik, P2P BLIK ↔ Lightning con primitive di escrow proprie, e dell’ingresso nel monitoraggio attivo del repository autonomo Gamma Markets Market Spec.

NIP-34: rimuovere il tag maintainers per risolvere i problemi di scadenza

La PR #2384 di dhalsim rimuove il tag maintainers dagli annunci dei repository NIP-34, affrontando la issue #2382. Il tag maintainers non aveva una semantica di scadenza definita, rendendo difficile per gli strumenti downstream stabilire quando l’assegnazione di un maintainer fosse ancora autorevole. La modifica ha un raggio d’azione ampio: riguarda le patch flotilla-budabit, l’unico repository NIP-34 monitorato con attività sostanziale sulle patch questa settimana, la configurazione di distribuzione NIP-34 su otto repository del team Iris, il mirror NIP-34 di BitBlik, il nuovo mirror NIP-34 di Amber e lo strumento PRana di DocNR per le liste di lavoro delle issue. Fra i revisori incrociati della PR figurano DanConwayDev (ngit), vitorpamplona (Amethyst), TheAwiteb e chebizarro.

Stati dei gruppi NIP-29 (lavoro in corso)

La PR #2372 di dtonon propone una struttura per gli stati dei gruppi di NIP-29, condivisa come lavoro in corso per raccogliere feedback. Prosegue l’evoluzione di NIP-29 descritta nel numero #27, ora attraverso una nuova impostazione.

NIP-79 Stories e NIP-76 Reels Feed, entrambe di anaskmh

Questa settimana sono arrivate due specifiche dello stesso autore per media in formato breve. La PR #2386 propone NIP-79 Stories: slide a schermo intero effimere con foto, video e testo, che scadono dopo 24 ore, con kind 19 per le singole slide, kind 34237 come event indirizzabile contenente tag e ordinati per sequenziare storie composte da più slide e una ricevuta seen-by opzionale e rispettosa della privacy sul kind 15750. La PR #2385 propone NIP-76 per un Reels Feed di video brevi. Entrambe sono specifiche parallele rispetto a ciò che client video esistenti come divine.video stanno distribuendo, non implementazioni di esso.

kind 1111 come risposta alle note kind 1

La PR #2358 di zhoreeq rimuove la riga del corpus NIP che in precedenza sconsigliava l’uso di risposte commento kind 1111 (NIP-22) su note kind 1 (issue #2250). La modifica è piccola nel diff ma ampia negli effetti: qualsiasi client che voglia usare la struttura dei commenti in thread di NIP-22 sulle normali note kind 1 della timeline ha ora un supporto esplicito per farlo.

Sei anni di giugno su Nostr

La storia del repository nel mese di giugno segue Nostr dall’infanzia del protocollo a un substrato componibile per applicazioni. Nel 2021 il lavoro entrava ancora tutto in un solo repository del protocollo. Nel 2022 il processo di standardizzazione e i primi client seri sono diventati progetti separati. L’ondata pubblica del 2023 ha reso urgenti relay, pagamenti e identità più ricche; il 2024 ha sostituito le prime scorciatoie per firma e messaggistica; il 2025 ha portato quei contratti in gruppi privati, collaborazione git, media e commercio; e il 2026 ha lanciato prodotti che usano Nostr come uno dei livelli di spazi di lavoro per agent, exchange e strumenti per sviluppatori. La progressione va dal dimostrare che gli event firmati possono viaggiare attraverso i relay al rendere questo fatto un dettaglio di implementazione.

Giugno 2021: l’infanzia del protocollo

Nostr aveva circa sette mesi. Il post originale sul protocollo di fiatjaf e il repository fiatjaf/nostr contenevano ancora quasi tutto il progetto pubblico. Una manciata di sviluppatori poteva revisionare ogni modifica e l’implementazione di riferimento era uno script Python. Non esisteva ancora un ecosistema di client; esisteva l’affermazione che gli utenti potessero firmare event e scegliere relay senza che una piattaforma assegnasse loro l’identità.

Non esisteva un repository NIP dedicato, quindi proposte ed esempi di implementazione condividevano ancora la storia principale del protocollo. In questa fase, tale portata ridotta era un punto di forza: un nuovo implementatore poteva comprendere il protocollo da un capo all’altro. Il costo era che ogni nuovo comportamento dipendeva ancora dallo stesso piccolo gruppo, un limite che la separazione dei repository e l’ondata di client del 2022 avrebbero iniziato a rimuovere.

Giugno 2022: nasce il repository NIP

A metà 2022 Nostr aveva abbastanza proponenti da giustificare il repository separato nostr-protocol/nips, creato a maggio. Circa venti specifiche coprivano ormai il formato base degli event, le liste follow, i DM cifrati, i metadati relay e gli identificatori bech32. Spostare i documenti fuori dal repository del codice originale ha cambiato la governance del progetto: i client potevano evolvere in modo indipendente, mentre il comportamento wire condiviso riceveva proposte e revisioni esplicite.

I primi client web pubblici, fra cui Astral e Anigma, erano attivi in forme iniziali e il repository Damus di William Casarin si avvicinava alla distribuzione su TestFlight. La base utenti era ancora piccola e composta soprattutto da sviluppatori, ma il sistema disponeva ormai di due superfici moltiplicatrici: più persone potevano costruire applicazioni senza mantenere la specifica e più persone potevano migliorare la specifica senza possedere il client originale.

Giugno 2023: l’ondata di adozione dopo Damus

A giugno 2023, l’ondata pubblica successiva al lancio di Damus nell’App Store aveva cambiato il problema ingegneristico. Primal e Iris costruivano per persone che non avevano seguito le prime chat sul protocollo, mentre strfry offriva un relay ad alte prestazioni agli operatori che affrontavano più traffico. La rete non aveva più bisogno soltanto di un maggior numero di implementazioni; servivano client e relay capaci di restare reattivi con la crescita di utenti, follow e cronologie degli event.

Il lavoro sul protocollo si è quindi concentrato su instradamento e trasferimento di valore. Le liste relay NIP-65 hanno dato al modello outbox emergente una fonte di verità portabile, mentre gli zap NIP-57 hanno collegato event e identità alle ricevute Lightning. Il cambio di fase era pratico: identità e pubblicazione avevano attirato gli utenti, ma erano l’instradamento selettivo dei relay e l’interoperabilità dei wallet a permettere alla rete più ampia di comportarsi come qualcosa di diverso da un unico feed pubblico sovraccarico.

Giugno 2024: signer, gift wrap e aggiornamento della messaggistica

A giugno 2024 la firma aveva iniziato a uscire dai singoli client. La specifica NIP-46, nsecBunker e Amber offrivano alle applicazioni web e Android modi per richiedere firme senza importare la chiave segreta dell’utente. Ciò rovesciava un’ipotesi iniziale: portabilità non significava più copiare una nsec in ogni client, ma consentire a signer specializzati di imporre un confine attorno a essa.

La messaggistica cambiava per la stessa ragione. NIP-17 combinava la cifratura NIP-44 con il gift wrapping NIP-59 per ridurre i metadati esposti da NIP-04, mentre NIP-89 permetteva ai client di raccomandare gestori per i tipi di event che non renderizzavano. Le discussioni su MLS-over-Nostr sono iniziate in questo contesto. Privacy e discovery delle applicazioni stavano diventando contratti fra client, preparando il terreno a gruppi privati e applicazioni più ricche specifiche per tipo di event, invece di un solo client che tentasse di contenere ogni funzionalità.

Giugno 2025: Marmot, maturità di git-over-Nostr e la lunga coda dei client

A giugno 2025, MLS-over-Nostr disponeva della specifica Marmot formale e di White Noise come implementazione pubblica. Gli event git NIP-34, ngit e GitWorkshop erano inoltre maturati fino a formare un flusso di revisione del codice utilizzabile. Questi progetti condividevano una stessa fase progettuale: usavano i relay per il coordinamento, spostando però stato sensibile dei gruppi o oggetti dei repository in livelli specializzati invece di trattare un client di note testuali come applicazione completa.

Commercio e media hanno seguito lo stesso schema. I wallet NIP-60 e i nutzap NIP-61 hanno portato lo stato Cashu in event portabili; Wavlake, Divine e le implementazioni di marketplace NIP-99 hanno usato kind dedicati per musica, video e inserzioni. Nostr stava diventando meno visibilmente «un social network», perché le applicazioni mantenevano il substrato di identità e relay introducendo archiviazione, pagamenti, moderazione e presentazione specifici del dominio.

Giugno 2026: un mese ricco di lanci

Giugno 2026 ha portato lanci che trattavano Nostr come un componente all’interno di prodotti più ampi. Buzz ha aperto uno schema self-hosted di spazio di lavoro come relay per persone e agent; Napplets ha definito un confine di fiducia per app componibili su Nostr e Blossom; e Conduit ha affiancato alle applicazioni del marketplace i propri documenti di protocollo. Questi progetti non chiedevano più se gli event firmati potessero supportare la collaborazione. Decidevano quale lavoro spettasse agli event, quale ai blob o allo stato locale e quali permessi dovesse mantenere un host.

BitBlik ha usato Nostr in uno scambio peer-to-peer fra fiat e Lightning, CodeDeck ha trasportato sessioni di coding tramite relay cifrati e Haven ha applicato Marmot fuori da un messenger convenzionale. La distanza dal repository prototipo del 2021 non consiste soltanto in un maggior numero di progetti. È un cambiamento di astrazione: i team potevano partire da identità portabile, discovery dei relay, cifratura e pagamenti come componenti esistenti, per poi concentrare il lavoro di progettazione sul confine specifico dell’applicazione costruito sopra di essi.