Questa settimana è stata dominata dal lavoro sui signer, dai protocolli di scambio P2P e dalle release dei client di punta. Amethyst v1.12.0 include oltre 170 PR che aggiungono wallet Cashu NIP-60, nutzap NIP-61, feed di applicazioni software NIP-82, supporto ai podcast NIP-F4, verifica degli zap on-chain tramite CLINK, la migrazione KMP verso iOS nelle fasi 1 e 2 e un driver di autoripristino per Tor. Clave v1.0.0 (build 102) è stata inviata all’App Store, portando su iOS la firma in background risvegliata da push e la verifica delle firme in ingresso. Mostro Core v0.13.0 introduce Protocol v2, sostituendo la comunicazione degli ordini basata su relay con messaggi diretti gift wrap NIP-44, mentre Mostro v0.17.5 rende opzionale e configurabile il deposito antiabuso lato operatore. Signet v1.11.0 corregge un bypass della firma nei comandi amministrativi NIP-17 (DM privati gift wrap), che permetteva a chiunque disponesse di informazioni pubbliche di falsificare comandi di kill switch. Chama ha pubblicato sette release di escrow in sei giorni, trasformando la stanza di scambio da un muro di controlli a una conversazione specifica per ciascun ruolo. Sul versante signer, Amber v6.2.1, Clave (build 100, 101 e 102) e Nostur 1.29.0 implementano tutte il nuovo metodo logout NIP-46 integrato questa settimana (PR #2373). Zeus v13.1.0-rc1 e Amethyst introducono entrambi il supporto ai noffer CLINK, l’interfaccia Lightning comune proposta per le chiavi Nostr. I gruppi relay NIP-29 hanno ricevuto cinque proposte aperte riguardanti tag banner, codici invito, fissaggio dei messaggi, segnalazione dei gruppi tramite DM NIP-17 e controllo degli accessi basato sui ruoli.

Storie principali

Amethyst è il principale client Nostr Android di Vitor Pamplona. v1.12.0 raggruppa le 93 PR trattate come lavoro non ancora rilasciato nella Newsletter #25 (etichettatura degli hashtag NIP-32, schermata podcast NIP-F4, tracce musicali, signer effimeri, zap on-chain con filtro NIP-05) e nella Newsletter #26 (ulteriore lavoro su NIP-F4 e basi del watchdog Tor), oltre a una nuova tranche consistente questa settimana. Il nuovo lavoro si concentra sull’interfaccia Cashu/nutzap, su un driver CLINK per gli zap on-chain, su un insieme di meccanismi di autoripristino Tor e sulla migrazione KMP verso iOS.

Il supporto ai wallet Cashu NIP-60 e la visualizzazione dei nutzap NIP-61 arrivano nella PR #3075, insieme a una vista del saldo per mint (PR #3115) e a un’interfaccia unificata per le schede di pagamento (PR #3191), che riunisce indirizzi Lightning, zap on-chain, mint Cashu e NWC in un’unica schermata di pagamento del profilo (PR #3185). Un driver CLINK per la verifica degli zap on-chain viene distribuito nelle PR #3039, PR #3177 e PR #3182. CLINK è la Common Lightning Interface for Nostr Keys, la stessa interfaccia noffer che Zeus v13.1.0-rc1 pubblica questa settimana, e Amethyst aggiunge un percorso di verifica che collega una prova di pagamento on-chain a una chiave Nostr. NIP-82 aggiunge feed di applicazioni software nella PR #3210, mentre il lavoro NIP-F4 prosegue con controlli dei podcast, descrizioni degli episodi e gestione delle immagini. La release include inoltre schermate per le richieste di pagamento NWC, una cronologia wallet unificata e il recupero dei token Cashu.

Un gruppo di modifiche sull’affidabilità di Tor forma uno stack completo di autoripristino: la PR #3053 aggiorna Arti alla v2.3.0 con watchdog e test di integrazione, la PR #3223 impedisce le connessioni ai relay instradate via Tor finché Tor non è pronto, la PR #3224 limita il bootstrap di Arti con un timeout di 60 secondi, così una rete ostile non può bloccare il ciclo, e la PR #3231 esegue l’autoripristino quando Tor risulta Active ma tutti i circuiti sono inattivi. Il risultato è uno stack Tor che si riprende dai cambiamenti di rete e dai cicli sospensione-ripresa senza intervento manuale. Le fasi 1 e 2 della migrazione KMP verso iOS arrivano nelle PR #3047 e PR #3050, sbloccando la CI iOS per i moduli quartz e commons e ponendo le basi per una build iOS di Amethyst.

Mostro Core v0.13.0 elimina l’intermediario relay con Protocol v2

Mostro è un exchange P2P di Bitcoin regolato tramite Lightning che usa Nostr come order book e livello di comunicazione degli scambi. mostro-core v0.13.0, la libreria Rust che definisce il protocollo wire, sostituisce il modello di messaggistica instradato via relay con quello che il changelog chiama Protocol v2, un trasporto diretto NIP-44 basato su eventi kind 14. Le azioni specifiche dello scambio viaggiano ora come messaggi kind 14 avvolti secondo NIP-44 e legati alla chiave del singolo scambio generata dal partecipante alla creazione dell’ordine, senza far transitare di nuovo la conversazione attraverso eventi indirizzabili pubblici.

Nel modello precedente, l’intera superficie della conversazione di scambio veniva esposta a ogni relay che trasportava gli eventi. Il trasporto diretto kind 14 mantiene configurazione dell’ordine, procedura di contestazione e metadati di regolamento tra le due parti e il daemon Mostro, mentre i relay vedono soltanto envelope cifrati. Oltre al cambio di trasporto, v0.13.0 lega anche la prova d’identità v2 alla chiave dello scambio (registro dei commit), chiudendo una classe di rischi di replay contro il nuovo protocollo. Sul lato daemon, Mostro v0.17.5 rende opzionale e configurabile dall’operatore il deposito antiabuso: prima di iniziare determinati scambi, ciascuna parte può dover bloccare un piccolo deposito, restituito al completamento normale e confiscato in caso di stallo, mancata presentazione o comportamento molesto. Il deposito viene abilitato a livello dell’operatore del nodo, non imposto all’intera rete, così Mostro resta non-custodial e ogni operatore sceglie il compromesso tra attrito del marketplace e resistenza agli abusi.

Signet v1.11.0 corregge un bypass della firma nei comandi amministrativi NIP-17

Signet è un signer bunker remoto con una superficie di kill switch che permette a un amministratore di sospendere, riattivare o controllare il signer tramite Nostr senza accedere alla macchina host. v1.11.0 corregge una vulnerabilità in questa superficie: il percorso dei comandi amministrativi gift wrap NIP-17 controllava soltanto l’autore dichiarato del rumor interno non firmato, senza mai verificare il seal firmato. Poiché le chiavi di conversazione NIP-44 sono simmetriche, un attaccante in possesso di sole informazioni pubbliche (la pubkey del signer, l’npub dell’amministratore e un relay amministrativo) poteva falsificare dall’esterno un gift wrap ed eseguire qualsiasi comando di kill switch, compresi panic, resumeall o alive. La correzione chiama verifyEvent sul seal e lega l’autore del rumor alla firma del seal, perciò le falsificazioni non firmate vengono ora respinte all’ingresso. Gli operatori Signet dovrebbero aggiornare tempestivamente; specifica e percorso di codice corretto forniscono insieme a un attaccante un modello operativo completo della vulnerabilità precedente.

Da Chama v3.2.0 a v3.5.0, la stanza di scambio viene ridisegnata e il percorso del denaro rafforzato

Chama è un client di escrow P2P nativo Nostr che abbina ecash Fedimint alla condivisione del segreto di Shamir 2-su-3 per regolare scambi senza server. La Newsletter #26 ha trattato la serie dalla v2.0.0 alla v3.1.0, che ha superato la soglia dell’app standalone e aggiunto vetrine per venditore. Le sei release successive di questa settimana partono dalla v3.2.0 e arrivano alla v3.5.0 il 15 giugno, ridisegnando l’interfaccia della stanza di scambio attorno a una sola domanda per ruolo, «che cosa devo fare adesso?», e rendendo il percorso del denaro resistente ai guasti parziali. v3.2.0 assegna ad acquirente, venditore e arbitro prompt d’azione codificati per colore, così ogni ruolo vede la propria mossa successiva in ogni stato dello scambio. v3.3.0 restringe due regole di consenso nel motore di scambio e richiede un’adozione coordinata da parte dei client per evitare divergenze di stato. v3.4.0 introduce un percorso di ripristino per depositi ecash parzialmente completati e impedisce che una risposta duplicata avanzi due volte la macchina a stati. v3.4.1, v3.4.2 e v3.5.0 correggono regressioni nel rendering, nel routing e nel flusso di pagamento emerse durante la serie.

Clave 1.0 arriva sull’App Store con firma in background risvegliata da push

Clave è un signer remoto iOS NIP-46 che conserva la chiave privata Nostr dell’utente nel Portachiavi dell’iPhone. Le app richiedono firme attraverso un canale cifrato end-to-end e non ricevono mai la chiave. v1.0.0 build 102 è stata inviata all’App Store questa settimana, segnando il traguardo 1.0 dopo otto mesi di beta TestFlight. La release introduce la firma in background risvegliata da push: Clave può decifrare una richiesta, controllare i permessi, firmare e rispondere con l’app chiusa, eliminando il precedente requisito che iOS fosse in primo piano per mantenere reattivo il signer. La verifica delle firme in ingresso viene applicata con Schnorr BIP-340 sul formato canonico di serializzazione degli eventi NIP-01 (la specifica base che definisce come viene calcolato l’hash di ogni evento Nostr firmato), insieme a una protezione sulla freschezza contro i replay, così un’app malevola non può introdurre di nascosto un evento rifirmato nel canale di risposta.

La release porta anche il livello di cifratura NIP-44 aggiornato, con un modello di permessi delimitato per kind e tre livelli di sensibilità; corregge il caso limite della firma a bassa fiducia in cui una richiesta «chiedi ogni volta» restituiva un errore prima che l’utente potesse approvarla; e aggiunge l’accoppiamento multi-account, così un singolo pairing dell’app può operare con più identità. I pairing bunker mostrano ora la vera identità dell’app tramite l’estensione dei metadati di connessione NIP-46 proposta da Clave nella PR #2381. Il flusso di disconnessione pulita usa il nuovo metodo logout NIP-46 integrato nella PR #2373, così un’app abbinata può terminare correttamente la sessione senza un disaccoppiamento manuale. Livelli di fiducia per app (Full, Medium, Low) con override per kind di evento, un registro attività per ogni firma e un proxy push gestibile dall’utente completano la superficie; lo stack del proxy è distribuito con licenza MIT e il modello di interoperabilità per client è documentato nel repository.

Release

Amber v6.2.1 aggiunge il logout NIP-46 e riduce il consumo della batteria del signer

Amber è il principale signer Nostr per Android. v6.2.1 riduce il consumo della batteria dovuto alle riconnessioni ai relay e ai ping websocket, elimina i relay inattivi dal pool di subscription e smette di risvegliare il dispositivo quando aggiorna la notifica relay. La release aggiunge anche il supporto al metodo logout NIP-46, così i client possono terminare correttamente le sessioni del signer remoto (lo stesso metodo integrato nella specifica questa settimana con la PR #2373), e aggiunge il parsing dell’evento kind 39701 (segnalibro web pubblico), permettendo agli utenti di firmare gli eventi segnalibro direttamente da Amber. Le impostazioni sono state ricostruite con schede Material 3 raggruppate e icone distinte; è stato corretto un crash di navigazione nella schermata dei permessi delle applicazioni; e una perdita di connessioni al database per account è stata chiusa costruendo i database in modo atomico.

Nostur 1.29.0 introduce risposte anonime e logout dal signer remoto

Nostur è un client Nostr iOS di Fabian. 1.29.0-desktop aggiunge il supporto alle risposte alle ricevute zap e all’invio di risposte anonime. Sul lato signer, la release migliora il flusso di connessione al bunker remoto, invia un logout NIP-46 al signer remoto quando l’utente esce da un account e corregge uno spinner bloccato quando la connessione a un signer remoto fallisce. Corregge inoltre problemi di caricamento dei DM dovuti al conflitto tra relay DM e relay dell’app, elimina post duplicati quando si apre una risposta e si torna indietro e mostra un’anteprima dei media nelle righe delle notifiche.

Citrine v3.0.0 introduce Negentropy, AUTH NIP-42 e filtro dei relay onion

Citrine è un aggregatore di relay locali per Android. v3.0.0 è un incremento della versione principale che aggiunge il supporto a Negentropy NIP-77 per la sincronizzazione tramite riconciliazione di insiemi, il supporto a signer esterni e AUTH NIP-42 nell’aggregatore relay, e il rispetto delle mute list NIP-51 nei recuperi dell’aggregatore. L’aggregatore limita il recupero a tre relay per autore, con relay sorgente e indicizzatori configurabili; riusa follow, mute e metadati memorizzati nella cache dopo riavvii e cambi di rete; si mette in pausa sulle reti limitate o con restrizioni; e filtra gli URL dei relay onion quando il proxy in uscita è disabilitato. I repost che incorporano eventi protetti vengono rifiutati e, per impostazione predefinita, le mute list sono escluse dall’eliminazione basata sull’età.

FIPS v0.4.0-rc1 aggiunge un trasporto mixnet Nym e la scoperta LAN mDNS

FIPS è l’implementazione del protocollo di sincronizzazione mesh FIPS. v0.4.0-rc1 è compatibile a livello wire con v0.3.0, quindi mesh miste interoperano e non serve un aggiornamento coordinato. La release aggiunge due nuovi modi con cui i nodi possono trovarsi e raggiungersi: un trasporto in uscita sulla mixnet Nym, con demo in un singolo container ed esempio di mixnet-relay, e la scoperta opzionale mDNS / DNS-SD sulla rete locale. Una nuova query show_metrics, composta soltanto da contatori, abilita uno scraper Prometheus senza costi sul percorso critico, mentre il rekey di FMP e FSP è stato irrobustito per non interrompersi in caso di perdita di pacchetti in entrambe le direzioni.

Calendar by Formstr v1.6.1 e v1.6.2 aggiungono notifiche per evento

Calendar by Formstr è un client calendario NIP-52. v1.6.1 aggiunge preferenze di notifica per evento (PR #109), permettendo all’utente di attivare o disattivare i promemoria per ogni singolo evento del calendario. v1.6.2 corregge l’accesso con Amber (PR #185), così il nuovo handshake NIP-46 di Amber 6.2.x funziona end-to-end.

Bitchat v1.5.2 e v1.5.3 irrobustiscono il trasporto Nostr e BLE

Bitchat è un client di chat mesh Bluetooth e Nostr. v1.5.2 applica un rate limit alle notifiche dei peer iOS per prevenire flood (PR #972) e rafforza la convalida Nostr e i controlli degli announce BLE (PR #1012), così il percorso di ingest Nostr lato relay rifiuta ora i messaggi malformati prima che raggiungano il gestore mesh locale. v1.5.3 è un hotfix per un crash all’avvio causato da un dispatch_once ricorsivo tra NostrRelayManager e NetworkActivationService (PR #1343).

Keep v1.0.5 sposta la superficie delle policy del signer nel core Rust sottoposto ad audit

Keep è un signer Android che incorpora il core Rust keep. v1.0.5 fissa la dipendenza a keep v0.4.8 e include una correzione alla race condition di inizializzazione del bunker (PR #296), così l’handshake non perde più il primo evento sotto carico; popola la schermata Authorized Clients dal callback onConnect del bunker (PR #291); e consolida il kill switch in un’unica fonte di verità in keep-mobile (PR #284). Il core Rust upstream ha pubblicato v0.4.9 il 13 giugno, spostando nel core sottoposto ad audit la superficie delle policy del signer NIP-55 e NIP-46 (decisione sui permessi, limite di durata per kind sensibili, scadenza, gestione delle chiavi e stato del kill switch), invece di lasciarla duplicata nei wrapper di piattaforma.

ants è lo strumento di ricerca e lettura Nostr di dergigi. v0.4.5 aggiunge azioni alle schede degli articoli per i post long-form, tra cui link ai portali per articoli, condivisione naddr specifica dell’articolo, copia di nevent e accesso al JSON grezzo. L’insieme dei portali è stato aggiornato ripristinando Habla, sostituendo destinazioni non più attive e rimuovendo il portale imwald. La release ripristina anche il rendering delle note a piè di pagina degli articoli, preservando la navigazione tramite anchor all’interno dell’articolo, e attende una connessione relay prima di recuperare il profilo durante il ripristino dell’accesso, così l’avatar nell’intestazione viene risolto correttamente.

Morganite v0.0.3 introduce una cache Blossom locale per Android con Tor on demand

Morganite è una nuova cache Blossom locale per Android di greenart7c3, autore di Amber e Citrine. La cache agisce come mirror locale BUD-08 ed elimina i blob meno usati quando supera 1 GB. v0.0.3 avvia Tor on demand e lo arresta quando è inattivo per risparmiare batteria, disconnette il relay Nostr dopo la ricerca dell’autore per eliminare il consumo in background, corregge il consumo causato da uno stream logcat non filtrato e da client HTTP non rilasciati, e libera i client OkHttp sostituiti fuori dal thread principale. La release recupera inoltre i relay inbox dell’utente prima di interrogare l’elenco dei server Blossom, così la scoperta dei blob segue il modello outbox, e scarica il blob per le richieste HEAD quando non è presente nella cache, mantenendo il riscaldamento della cache legato alla domanda effettiva dei client.

Coracle 0.6.34 e 0.6.35 correggono l’accesso NIP-46, i feed obsoleti e l’attivazione delle risposte

Coracle è un client web Nostr di hodlbod. 0.6.34 corregge l’accesso NIP-46, uno stato obsoleto del feed nel quale la timeline home non si aggiornava dopo aver cambiato vista e un selettore delle risposte che, quando attivato, filtrava tutto. La release ricostruisce inoltre le viste feed ed elenco, corregge un problema con l’inset della safe area dei toast e migliora il caricamento delle immagini. 0.6.35 è un piccolo seguito che corregge i repost nascosti quando le risposte sono disabilitate, così il filtro dei repost non applica più eccessivamente quello delle risposte.

Zeus è un wallet Bitcoin e Lightning self-custodial con una superficie Nostr per wallet connect e pagamenti noffer. v13.1.0-rc1 aggiunge su iOS pagamenti Nostr Wallet Connect NIP-47 senza coda (in collaborazione con Primal), così una fattura NWC pagata non resta più in attesa in una coda in background; introduce il supporto ai pagamenti noffer CLINK, con Zeus Pay che genera un noffer CLINK per ogni account, così un mittente può pagare qualsiasi utente Zeus usando soltanto la sua chiave Nostr; e aggiunge su Zeus Pay un opt-out per gli zap Nostr, così il destinatario può disabilitare il percorso delle ricevute kind 9735 senza disabilitare NWC.

Alby Extension v3.14.3 migra gli stack crittografici noble/scure usati dal signer NIP-07

Alby Extension è l’estensione browser che fornisce firma NIP-07 e Nostr Wallet Connect insieme alla sua superficie Lightning. v3.14.3 migra gli stack @noble/curves, @noble/hashes, @noble/ciphers, @noble/secp256k1, @scure/bip32 e @scure/base alle versioni principali v2 e v3. Queste sono le librerie crittografiche sulle quali il percorso del signer NIP-07 fa affidamento per firmare gli eventi e per la cifratura NIP-44, quindi un cambio di versione principale tocca il formato wire prodotto dall’estensione per ogni richiesta di firma di un evento proveniente da un client web Nostr.

Mostro Mobile v1.2.8 e v1.2.9 supportano Protocol v2 e mostrano la policy del deposito

Mostro Mobile è il client mobile per Mostro. v1.2.8 introduce lato client il supporto a mostro-core v0.13.0 Protocol v2 (trattato nella storia principale qui sopra) e aggiunge 17 funzionalità complessive, tra cui il deposito antiabuso del maker dalla PR #608, la scoperta dei relay di bootstrap dalla PR #610, la persistenza dell’annullamento dell’ordine nella cronologia delle notifiche dalla PR #602 e i limiti sull’importo fiat nella schermata di creazione degli ordini dalla PR #605. v1.2.9 espone la policy del deposito antiabuso dall’evento info del nodo (PR #617), così l’utente può vedere le regole del deposito dell’istanza Mostro prima di aprire un ordine.

ZapBook dalle build 4 alla 27 introduce multi-account, pubblicazione delle chiavi Marmot e nuovi inviti ai circoli

ZapBook è un’app di lettura sociale nativa Nostr di codeswot per iOS e Android, organizzata attorno a circoli di lettura da 1 a 100 persone che condividono traguardi e si inviano zap in sats come incoraggiamento. Tra la build 4 dell'11 giugno e la build 27 del 15 giugno, il progetto ha pubblicato 17 build con tag e integrato 7 PR. Il supporto multi-account con cambio fluido di account è arrivato nella PR #25, così un utente può conservare nell’app più identità Nostr e migrare le sessioni tra loro. La pubblicazione iniziale dei key package Marmot (kind 443) viene ora attivata automaticamente al completamento dell’onboarding (PR #20), condizione preliminare per la messaggistica di gruppo su invito nei circoli di lettura. La gestione dei membri rimossi dai circoli elabora ora correttamente i nuovi inviti (PR #24), chiudendo una classe di bug per cui i membri riaggiunti non ricevevano nuovi inviti dopo la rimozione. La serie di release sposta inoltre l’inferenza degli embedding ONNX in un isolate in background (PR #19) per la ricerca semantica nel lettore e integra il servizio NWC con un APP_ID_SUFFIX per configurazioni specifiche dell’ambiente, così un singolo hub può servire più build di ZapBook.

Alby Hub v1.23.0 corregge la pubblicazione NIP-47 per le app eliminate e passa Bitrefill a NWC

Alby Hub è un hub Lightning e Nostr self-hosted. La superficie non Nostr di v1.23.0 è ampia (canali Just-in-Time, una pagina Cards per ricaricare carte di debito, un backend di pagamento Ark sperimentale e una home page di storie) e non rientra nell’ambito di Compass. Sul versante NIP-47, la release smette di riprovare a pubblicare le info NIP-47 per le app eliminate, così una connessione rimossa non continua a ripubblicare il proprio evento info kind 13194 (PR #2391), e rimuove la voce dell’app personalizzata Bitrefill in favore di una connessione NWC standard (PR #2420). L’opzione readonly per le app dell’app store (PR #2415) restringe gli ambiti dei permessi per le app NWC pubblicate tramite lo store interno all’hub.

Altre release

Release minori di questa settimana con contenuti rilevanti per Nostr ma sostanza limitata per ciascuna: Nostria dalla v3.1.48 alla v3.1.50, che prosegue il rollout dei Web Bookmarks con affidabilità delle notifiche e ottimizzazione del database dei thread di eventi nella v3.1.50; Deepmarks dalla v0.7.0 alla v0.7.5, che itera sul client di segnalibri sociali NIP-B0 (questa settimana il progetto ha anche aggiunto il link al proprio sito nella PR #96); Keep dalla v1.1.1 alla v1.1.4, con quattro correzioni alle build riproducibili F-Droid sopra la release signer v1.0.5 trattata sopra; NoorNote v0.11.1, v0.12.0, v0.13.0 e v0.13.1 sul client desktop per note; Boris v0.12.2 sul lettore Boris; Nostr Mail Client v0.13.0; Feeder 2.21.1; nak v0.19.13, un aggiornamento di manutenzione vuoto per la CLI Nostr; Hashtree dalla v0.2.68 alla v0.2.71, che aggiorna le cache mutable-root del gateway per il publisher di release indirizzate tramite hash tree; NYM v3.72.501 e v3.72.502, che aggiornano l’implementazione relay basata su Nostrify; swift-nostr-client 0.3.0, 0.4.0 e 0.5.0, tre release minori sostenute da 85 PR integrate sul client Nostr iOS; lawallet-nwc v0.11.0, con 18 PR integrate sul bridge LaWallet Nostr Wallet Connect; Astraea dalla v5.35.59 alla v5.35.62, che itera sul client Nostr Astraea; e i bot DM Nostr verificati NIP-05 BTC Recharge e giftcardshop, aggiunti alla directory dei progetti in una nuova categoria Shops.

Modifiche non ancora rilasciate

diVine integra 119 PR verso la prossima release del video breve

diVine è un client di video brevi in loop nativo Nostr che ripristina l’archivio Vine su un’infrastruttura Nostr. Questa settimana il progetto ha integrato 119 PR senza pubblicare una release con tag. Il lavoro sostanziale sulla superficie Nostr comprende un percorso REST-first per pubblicare video, così la mancanza dell’OK di un relay non viene più mostrata come un errore (PR #5221 e PR #5220); un nuovo filtraggio delle griglie curate e dei like quando cambia la blocklist generale (PR #5208); il recupero dell’elenco delle conversazioni DM dopo una regressione in seguito alla reinstallazione (PR #5202); il ripristino del badge Nostr sui profili (PR #5218); e riferimenti nostr: convertiti in link nelle citazioni dei commenti (PR #5225). Lo stack dell’editor video ha aggiunto unione o eliminazione di clip con selezione multipla, canvas con pinch-to-zoom e scrim letterbox che segue lo zoom, nonché trasformazioni di ritaglio, rotazione e ribaltamento delle clip.

Pollerama integra 15 PR nella finestra, con una rielaborazione del signer e un’ondata di funzionalità

Pollerama (repo formstr-hq/nostr-polls) è il client di sondaggi e feed nativo Nostr della famiglia Form*, fratello di Calendar by Form*, che questa settimana ha pubblicato v1.6.2. L’ultima release con tag su nostr-polls è v1.6.4 di marzo, quindi il lavoro nella finestra è in coda per il prossimo tag e non è ancora stato pubblicato, ma il flusso di merge è intenso: tra il 9 e il 16 giugno sono state integrate quindici pull request, con contributi di abh3po, geralt-debugs e SIDDHANTCOOKIE. Sul versante signer, il progetto ha sostituito la superficie di firma esistente nella PR #198 e aggiornato la sostituzione nella PR #201; inoltre, la PR #200 impedisce che gli aggiornamenti dei metadati kind 0 partano all’accesso, così un nuovo login non pubblica più un evento profilo non richiesto dall’utente. L’ondata di funzionalità comprende un editor del profilo con pubblicazione dalla vista profilo (PR #205), un flusso di repost migliorato (PR #209) e un percorso più semplice per la scoperta degli argomenti (PR #202). La prossima release con tag includerà tutto questo.

Lavoro su librerie e strumenti

NDK PR #375 e il lavoro integrato nei repository rust-nostr e nostr-tools sono rimasti tranquilli questa settimana, con una o due PR integrate ciascuno e nessuna release con tag. L’attività su ContextVM SDK (1 PR integrata), mesh-llm (37 PR integrate, 8 PR aperte), Zap Cooking (26 PR integrate) e Routstrd (2 PR integrate) è proseguita senza un tag di release nella finestra.

Aggiornamenti NIP e lavoro sulle specifiche di protocollo

Il lavoro di questa settimana sul protocollo si concentra in due aree: rafforzamento dei signer e governance dei gruppi NIP-29.

Integrato questa settimana:

  • NIP-46 (Nostr Connect). La PR #2373 aggiunge un metodo logout che consente a un client di terminare correttamente una sessione con un signer remoto. Amber, Clave e Nostur hanno tutti distribuito il supporto nella stessa settimana.
  • NIP-CC (Community Chat). La PR #2365 aggiorna NIP-CC per fare riferimento alla moderna specifica NIP-GC (Group Chat) per il meccanismo lato client, allineando la specifica delle stanze delle community con la primitiva canonica per la chat di gruppo.

Cluster NIP-29 aperto (governance dei gruppi basata su relay):

  • Tag banner. La PR #2383 aggiunge un tag banner all’evento dei metadati di gruppo kind 39000.
  • Suffisso del codice invito. La PR #2380 introduce un suffisso del codice invito nell’identificatore del gruppo, così un invito monouso può essere codificato nell’ID del gruppo stesso.
  • Fissaggio dei messaggi. La PR #2379 aggiunge un’azione di moderazione per aggiornare l’elenco dei messaggi fissati e un evento kind 39005 per trasmettere l’insieme fissato.
  • Segnalazione dei gruppi tramite DM NIP-17. La PR #2377 definisce un flusso di segnalazione nel quale i membri comunicano gli abusi nel gruppo al contatto amministrativo del relay tramite DM gift wrap NIP-17, tenendo il traffico di moderazione fuori dal flusso pubblico degli eventi del gruppo.
  • Controllo degli accessi basato sui ruoli. La PR #2376 aggiunge una superficie RBAC sopra l’attuale distinzione amministratore/membro.

Seguiti NIP-46 aperti:

  • Metadati del client nella richiesta di connessione. La PR #2381 consente al client che si connette di inviare nella richiesta i campi opzionali name, url e icon, così il signer può mostrare l’identità dell’applicazione nella schermata di pairing. Clave build 101 implementa la proposta.
  • Evitare timeout silenziosi. La PR #2375 restringe la specifica affinché un signer che necessita dell’input dell’utente mantenga aperta la richiesta fino alla decisione, correggendo la modalità di errore che Clave build 100 ha risolto lato implementazione.

Altro lavoro aperto:

  • NIP-100 Sovereign Agent Identity Network (SNIN). La PR #2378 propone un protocollo agent-to-agent per l’identità degli agenti autonomi e la scoperta delle loro capacità. La proposta è ampia e probabilmente sarà suddivisa in parti più piccole durante la revisione.

Specifica Blossom. La BUD-00 PR #108, integrata il 15 giugno, amplia la definizione BUD per includere convenzioni lato client e formati di dati costruiti sopra i blob Blossom che i server non implementano. La modifica porta BUD come BUD-10 (lo schema URI blossom:) e BUD-08 (le convenzioni per cache locali implementate questa settimana da Morganite) all’interno della numerazione canonica, mentre prima erano trattate come estensioni fuori banda.

Approfondimento NIP: NIP-77 (Negentropy)

NIP-77 definisce un protocollo di riconciliazione degli insiemi per i relay Nostr. Due parti (un client e un relay, oppure due relay in un bridge) possiedono ciascuna un insieme di eventi che corrisponde a un filtro e vogliono convergere verso l’unione senza ritrasmettere tutto. L’approccio ingenuo consiste nell’inviare tutti gli ID degli eventi e calcolare la differenza; per un filtro molto attivo, il costo cresce con la dimensione dell’insieme più grande, indipendentemente da quanto differiscano i due insiemi. NIP-77 riduce il costo rendendolo proporzionale alla differenza simmetrica.

La specifica si basa su due messaggi relay, NEG-OPEN e NEG-MSG. Un client apre una sessione di riconciliazione con ["NEG-OPEN", <subscription_id>, <filter>, <initial_message>], dove <initial_message> è un payload Negentropy codificato in esadecimale che descrive la visione dell’insieme del client. Le risposte arrivano come frame NEG-MSG e le due parti si scambiano messaggi finché non raggiungono un punto fisso. Ogni NEG-MSG restringe il disaccordo (suddividendo un intervallo in sottointervalli con le rispettive fingerprint) oppure termina una foglia (elencando gli ID di un intervallo piccolo, così il destinatario può calcolare direttamente la differenza). Quando una parte stabilisce che l’altra possiede eventi che le mancano, invia una normale REQ per quegli ID; quando possiede eventi che mancano all’altra, la specifica demanda il percorso di upload a una normale pubblicazione EVENT sull’altro lato.

La struttura dati sottostante è una variante sequenziata del Merkle tree. Ogni evento nell’insieme locale è indicizzato da (created_at, id) e raggruppato in intervalli; ciascun intervallo contiene una piccola fingerprint calcolata dagli ID che include. Quando una fingerprint coincide tra client e relay, l’intervallo è convergente e viene saltato. Quando differisce, la parte che risponde divide l’intervallo a metà (o in sottointervalli) e invia le fingerprint di ciascuno, ricorrendo nel disaccordo. Gli intervalli foglia (al di sotto di una piccola soglia di eventi) vengono inviati per esteso. La proprietà fondamentale è che confermare gli intervalli già convergenti costa quasi nulla, indipendentemente dal numero di eventi al loro interno.

L’inquadramento in ordine created_at è importante per due motivi. Primo, la paginazione Nostr esistente usa until e since rispetto allo stesso timestamp, quindi un reconciler può riprendere tra sessioni senza risincronizzare l’intero archivio: memorizza il limite superiore e avvia da lì la sincronizzazione successiva. Secondo, data una chiave ordinata, le divisioni degli intervalli sono deterministiche, quindi client e relay concordano sempre sul confine successivo senza bisogno di un messaggio di negoziazione separato. Il costo di una sincronizzazione è approssimativamente O(d log n), dove d è la dimensione della differenza simmetrica e n quella dell’insieme più grande: molto inferiore al costo O(n) di un invio ingenuo di ID e ai round trip O(n) richiesti da N REQ.

Vale la pena evidenziare tre compromessi implementativi. La dimensione della fingerprint (la specifica usa 32 byte per intervallo) bilancia probabilità di collisione e banda: fingerprint più piccole risparmiano byte ma aumentano il rischio di una corrispondenza falsa che faccia perdere eventi. La soglia delle foglie (quando smettere di dividere e inviare gli ID per esteso) bilancia round trip e banda per messaggio: soglie più basse comportano più round, soglie più alte messaggi foglia più grandi. Inoltre, il protocollo presume che entrambe le parti possano calcolare la stessa fingerprint sullo stesso intervallo; ciò richiede una serializzazione stabile delle coppie (created_at, id) condivisa dalle due implementazioni, motivo per cui la specifica è meticolosa sull’ordine dei byte nella costruzione della fingerprint.

Un relay che annuncia NIP-77 nel proprio supported_nips NIP-11 permette ai client di eseguire la riconciliazione al posto di, o insieme a, una normale sincronizzazione basata su REQ. Il client sceglie il protocollo in base alle necessità: una nuova subscription che vuole il traffico più recente usa REQ, perché non esiste uno stato precedente da riconciliare; un mirror di lunga durata che deve recuperare dopo un’interruzione usa NEG-OPEN, perché la differenza simmetrica è piccola rispetto all’archivio. I due percorsi si completano a vicenda in contesti di deployment differenti.

Esempio di scambio NEG-OPEN:

→ ["NEG-OPEN", "sync-1", {"kinds":[1],"authors":["abc..."]}, "<hex initial Negentropy message>"]
← ["NEG-MSG", "sync-1", "<hex relay response>"]
→ ["NEG-MSG", "sync-1", "<hex client refinement>"]
← ["NEG-MSG", "sync-1", "<hex leaf with IDs the relay has and client lacks>"]
→ ["REQ", "fetch-1", {"ids":[...]}]
← [...EVENT messages...]
← ["EOSE", "fetch-1"]
→ ["CLOSE", "sync-1"]

Questa settimana Citrine v3.0.0 introduce il supporto a NIP-77 nell’aggregatore relay, la prima volta in cui la superficie di relay locale Android può riconciliarsi con relay esterni invece di eseguire recuperi REQ in massa.

Approfondimento NIP: NIP-61 (Nutzaps)

NIP-61 definisce pagamenti ecash Cashu peer-to-peer consegnati come eventi Nostr. Un mittente pubblica un token Cashu bloccato sulla chiave pubblica derivata da Nostr del destinatario, che lo riscatta dalla mint quando preferisce. A differenza degli zap NIP-57, che richiedono che il destinatario sia raggiungibile tramite Lightning nel momento del pagamento, un nutzap è un token ecash autonomo che il destinatario può riscattare secondo i propri tempi.

La specifica combina tre kind di evento con la primitiva di lock P2PK di Cashu. Kind 10019 è la raccomandazione delle mint del destinatario: un evento sostituibile che elenca una o più mint dalle quali il destinatario accetta nutzap, insieme alla chiave pubblica Cashu usata per bloccare le proof a suo favore. Questa chiave è distinta dalla chiave d’identità Nostr del destinatario: è una chiave con ambito wallet derivata per ricevere nutzap, così la chiave d’identità non deve mai entrare in contatto con i segreti ecash. Prima di inviare, i mittenti leggono kind 10019, in modo che il token costruito sia riscattabile dal destinatario presso una mint di cui già si fida.

Kind 9321 è l’evento di pagamento. Contiene uno o più tag proof Cashu (ciascuno con una proof bloccata P2PK legata alla pubkey nutzap del destinatario indicata in kind 10019), un tag u con l’URL della mint, tag opzionali e e a che identificano una nota alla quale è stato inviato uno zap e un tag p per il destinatario. Il destinatario riceve kind 9321 attraverso la normale subscription Nostr, verifica che le proof siano bloccate sulla propria pubkey nutzap presso una mint elencata nel proprio kind 10019, le sblocca con la chiave privata corrispondente e le conserva nel wallet NIP-60 oppure le converte in Lightning. Kind 7375 registra le proof riscattate nella catena degli eventi wallet del destinatario, così un wallet che si risincronizza dai relay non conteggia due volte le proof nutzap provenienti dalla stessa fonte.

Il modello di fiducia è il prezzo esplicito del design. Le mint Cashu detengono il valore sottostante; una mint malevola o sequestrata può rifiutarsi di riscattarlo. NIP-61 eredita questo rischio di custodia da NIP-60 e non cerca di eliminarlo. In cambio, il design offre micropagamenti compatibili con destinatari offline e finalità istantanea: il token è il pagamento, il destinatario non deve eseguire un nodo Lightning né accettare HTLC in ingresso in tempo reale e un mittente che possiede proof presso la stessa mint può pagare senza un singolo passaggio di rete verso un custode. L’annuncio kind 10019 è il filtro del livello sociale: i mittenti che scelgono una mint fuori dall’insieme fidato del destinatario rischiano un token non riscattabile, mantenendo prevedibile la superficie di riscatto del destinatario.

Rispetto a NIP-57, anche il percorso di verifica è più semplice. Una ricevuta zap NIP-57 è un kind 9735 pubblicato dal servizio LNURL del destinatario e richiede che il verificatore recuperi l’endpoint LNURL e confermi che la chiave di firma della ricevuta corrisponda a quella dichiarata dall’endpoint. Un nutzap porta inline la prova crittografica del pagamento (le stesse proof bloccate P2PK), così qualunque verificatore con le chiavi pubbliche della mint può confermare la validità delle proof senza un round trip verso terze parti. Il compromesso è che verificare un nutzap richiede di comprendere i keyset della mint, mentre verificare NIP-57 richiede soltanto l’infrastruttura LNURL standard.

I due formati di zap coesistono come complementi. Gli zap NIP-57 restano la scelta giusta per i destinatari con routing Lightning operativo e per i mittenti che vogliono importi denominati in sats con semantica di regolamento Lightning. Gli zap NIP-61 diventano la scelta giusta per destinatari offline, flussi ricchi di micropagamenti nei quali le commissioni Lightning superano il valore trasferito e client rivolti a utenti senza infrastruttura Lightning.

Esempio di evento nutzap:

{
  "id": "a5f87fe2d4c8b9a0e3f1c4d5e6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f",
  "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
  "created_at": 1750162800,
  "kind": 9321,
  "tags": [
    ["proof", "{\"amount\":21,\"secret\":\"...\",\"C\":\"...\",\"id\":\"...\"}"],
    ["u", "https://mint.example.com"],
    ["e", "8b39f4e5d6c7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3"],
    ["p", "c5d8a4e3b2a1f0e9d8c7b6a5949382716050403020100ffeeddccbbaa99887766"]
  ],
  "content": "Great post!",
  "sig": "f1e2d3c4b5a6978869504132c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5"
}

Questa settimana Amethyst v1.12.0 introduce il rendering nativo dei nutzap NIP-61 insieme alla superficie wallet NIP-60 (PR #3075), rendendo Amethyst il primo client Android dominante a mostrare nella timeline i nutzap ricevuti e a offrire nel wallet viste del saldo per mint.