Nostr Compass #32 | Nostr Compass

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

Questa settimana: IndieSats abbandona la custodia delle chiavi, la sua whitelist e la sua quota obbligatoria sui ricavi, rilanciandosi come relay aperto, player e livello di scoperta in cui gli artisti pubblicano con le proprie chiavi. Nostrord v2.3.0 introduce la moderazione dei gruppi, le mute list e i relay onion nella stessa settimana in cui vengono integrati cinque PR della specifica NIP-29. Zapstore 1.1.0 introduce una chiave del dispositivo portatile e cifrata, con backup tramite Amber, e aggiornamenti automatici in background su base opt-in. Il kind di lista per i set di follow preferiti viene integrato e nel giro di pochi giorni viene aperto un PR per rinumerarlo. E i progetti Iris rilasciano nostr-pubsub, il runtime per browser fips-ts e nostr-social-graph 2.0.0 nella stessa settimana.

I rilasci taggati portano Amber v6.3.0 con approvazioni raggruppate per la firma bunker, Armada v0.37.0 con un secondo client per gli spazi di lavoro Buzz, Divine Mobile 1.0.17 con consegna NIP-17 persistente e convalida TLS rigorosa, e nak v0.20.2 con comandi per i pull request NIP-34.

Sul fronte delle modifiche non ancora rilasciate, Snort registra la copertura della cache comprovata da EOSE, Shopstr chiude due falle nell’integrità dei pagamenti, Mostr collega le chat private ActivityPub ai DM Nostr, nostream integra lo stack di controllo degli accessi trattato dal Deep Dive di questa settimana, e Amethyst raggiunge 88 PR integrati con sondaggi NIP-88 completi su Desktop.

Il repository dei NIP integra cinque PR questa settimana, tra cui il cluster NIP-29 e i set di follow preferiti kind:10011, e apre dibattiti sulla semplificazione di NIP-47 e sulle asserzioni di fiducia sui relay. Il Deep Dive copre NIP-42 e NIP-43, la coppia per il controllo degli accessi ai relay.

Storie principali

IndieSats abbandona il suo ruolo di editore e si rilancia come infrastruttura musicale Nostr aperta

IndieSats è una piattaforma musicale basata su Nostr che fino a questa settimana agiva da editore: custodiva le chiavi degli artisti, gestiva una whitelist e tratteneva una quota obbligatoria del 2% sui ricavi. In un annuncio di svolta pubblicato il 20 luglio, il progetto ha abbandonato tutti e tre questi ruoli in una volta. La piattaforma rilanciata si compone di tre elementi di infrastruttura aperta: un relay aperto, un player e un livello di scoperta. Gli artisti ora pubblicano musica con i propri profili Nostr. La quota del 2% della piattaforma su ogni brano è facoltativa, ma viene selezionata per impostazione predefinita quando un artista pubblica; gli artisti possono deselezionarla per trattenere l’intero pagamento. La piattaforma rispetta inoltre le richieste di eliminazione kind:5 di NIP-09, così gli artisti possono rimuovere le proprie opere. Un aggiornamento v1.1.5 pubblicato il 21 luglio ha adeguato la pubblicazione dei brani al formato degli eventi previsto da Amethyst e dagli altri client musicali Nostr e ha reso esplicita la consegna ai relay. In uno spazio in cui si parla spesso di protocolli che sostituiscono le piattaforme, questo è un caso concreto di una piattaforma che si scompone volontariamente in elementi di protocollo.

Nostrord v2.3.0 porta la moderazione dei gruppi, le mute list e i relay onion

Nostrord, il client di chat di gruppo per Android, iOS, web e desktop, ha rilasciato la v2.3.0 con azioni di moderazione dei gruppi collegate a tutte le interfacce (PR #192), inviti ai gruppi subordinati al consenso con rilevamento cross-relay (PR #195), mute list NIP-51 multipiattaforma (PR #188) e supporto per i relay Tor .onion. Il rilascio arriva nella stessa settimana in cui la specifica NIP-29 sottostante ha integrato cinque PR che coprono sottogruppi, fissaggio dei messaggi, banner e codici di invito (i dettagli sono nella sezione sul protocollo di questa settimana), quindi la chat di gruppo su Nostr ora dispone sia di una specifica più approfondita sia di un client che ne mette in pratica gran parte, accorciando il ciclo di feedback per chiunque altro sviluppi sui gruppi ospitati dai relay.

Zapstore 1.1.0 rende la chiave del dispositivo portatile e aggiunge gli aggiornamenti automatici in background

Zapstore è un app store nativo di Nostr in cui i rilasci sono firmati dalle chiavi degli sviluppatori e nessun operatore centrale ne garantisce l’affidabilità. La versione 1.1.0, il primo rilascio trattato qui dall’inizio di marzo, colma le due lacune principali rispetto agli app store convenzionali. Per gli aggiornamenti, i download in background su base opt-in ora avvengono tramite Wi-Fi e si installano silenziosamente o in modalità staged, così le app restano aggiornate senza passaggi manuali dallo store. La continuità dell’identità deriva da una chiave del dispositivo portatile e cifrata, di cui gli utenti possono eseguire il backup tramite Amber usando NIP-55, l’interfaccia per firmatari Android, così la migrazione a un altro telefono conserva l’identità del dispositivo. La versione 1.1.0 sposta inoltre il catalogo delle app sui relay come eventi kind:10067 firmati dal dispositivo, aggiunge dal menu aggiuntivo le segnalazioni verificate NIP-56, affinché gli utenti possano segnalare app problematiche in un formato utilizzabile da altri client, e verifica la prova C1 allegata a un rilascio prima di procedere con l’installazione, rafforzando il legame tra ciò che uno sviluppatore ha firmato e ciò che il dispositivo esegue.

Il kind di lista per i set di follow preferiti viene integrato e cambia subito casa

Una storia di coordinamento delle specifiche si è svolta nell’arco di una sola settimana. Il PR #2413 è stato integrato il 15 luglio, standardizzando sotto NIP-51 (liste) un kind di lista sostituibile per i set di follow preferiti: un kind dedicato ai set curati di account seguiti da un utente. Nel giro di pochi giorni è emerso che il kind:10011 assegnato era già in uso altrove, quindi un PR #2417 successivo è ora aperto per rinumerare la lista a kind:10021. Nulla è ancora stato rilasciato sulla base del kind integrato, quindi questo è il momento meno costoso per rinumerarlo; quando i client inizieranno a pubblicare eventi kind:10011, risolvere la collisione diventerà oneroso. Gli sviluppatori che realizzano funzionalità basate sulle liste dovrebbero seguire il PR di rinumerazione, non il testo integrato, finché la questione non sarà risolta.

Tre rilasci dall’orbita di Iris sono arrivati insieme, e si incastrano a vicenda. nostr-pubsub è una libreria publish/subscribe neutra rispetto al trasporto per eventi Nostr; i suoi primi rilasci tracciati, dalla v0.1.3 alla v0.5.2, offrono un carrier relay per browser costruito sul SimplePool di nostr-tools, la verifica degli eventi al confine del trasporto affinché le firme invalide non raggiungano mai i sottoscrittori, e query storiche limitate. fips-ts porta FIPS, il trasporto peer Noise-over-secp256k1 precedentemente disponibile come stack Rust, nel browser come runtime TypeScript: i rilasci dallo 0.0.24 allo 0.0.30 hanno aggiunto un carrier per datachannel WebRTC, il signaling basato su Nostr per la scoperta dei peer, una cache dei peer recenti e un adattatore IndexedDB per l’archiviazione nel browser, e il runtime è wire-compatible con l’implementazione Rust di riferimento. Il terzo pezzo, nostr-social-graph v2.0.0, è una major version della libreria social-graph: operazioni firmate sui roster per i grafi di identità Nostr, flussi di approvazione dei dispositivi avviati da un URI canonico a tre campi, e sfaccettature di identità del trasporto FIPS con vettori di test condivisi tra Rust e TypeScript. L’inquadramento connettivo è lo Iris Stack, il laboratorio di integrazione del progetto che lega queste librerie insieme a Blossom, Hashtree e la messaggistica cifrata. Nel complesso, una web app può ora scoprire peer tramite Nostr, aprire un canale FIPS cifrato verso di essi e mantenere un grafo sociale firmato, tutto in TypeScript.

Rilasci taggati

Amber v6.3.0 raggruppa le approvazioni di firma bunker e aggiunge il supporto per le Expert List

Amber è un firmatario remoto NIP-46 per Android. La v6.3.0 aggiunge l’approvazione raggruppata di richieste multiple, così gli utenti possono esaminare e approvare in una volta un gruppo di firme bunker. Il rilascio aggiunge anche il supporto per gli eventi Expert List (kind 12022) ed Expert Pack (kind 32022), una modalità privacy che nasconde i contenuti sensibili sullo schermo e una modifica che recupera la lista dei relay NIP-65 di un account prima dei metadati del profilo, così i flussi di firma partono dal set di relay effettivo dell’utente. Questo segue la linea v6.2.x trattata nel numero del 2026-07-08.

Seguito di Nostrord v2.2.0

Con la v2.3.0 in testa alla sezione News di questa settimana, lo spazio dei rilasci taggati annota solo ciò che la storia principale non copre: la v2.3.0 segue i controlli per i DM della v2.2.0 trattati nel #31, rendendo questo il secondo rilascio settimanale consecutivo del client.

Armada v0.37.0 apre gli spazi di lavoro Buzz da un secondo client

Armada, un client Nostr in stile Discord, ha rilasciato la v0.37.0 con il supporto per i relay Buzz come modalità avanzata per gli spazi di lavoro NIP-29, rilevata tramite i metadati NIP-11 del relay. Il client visualizza i post e i commenti dei forum Buzz come kind 45001 e 45003, incorpora modifiche ed eliminazioni nelle timeline dei flussi e aggiunge superfici per presenza, workflow, attività, huddle e canvas condivisi. Lo spazio di lavoro Projects legge direttamente dal relay gli annunci dei repository, le patch, i pull request, le issue e gli eventi di stato NIP-34 (commit dell’implementazione), offrendo agli spazi di lavoro Buzz un secondo client sia per le conversazioni sia per il lavoro sui repository.

Wisp v1.2.0 aggiunge un commutatore multi-account e thread di risposte comprimibili

Wisp è un client Nostr orientato alla privacy con supporto wallet integrato. La v1.2.0 aggiunge un commutatore multi-account per spostarsi tra i profili senza rifare il login, thread di risposte comprimibili per le conversazioni lunghe, la rimozione dei parametri di tracciamento dai link delle note prima che vengano aperti, e una vista dello storico delle transazioni del wallet. Il rilascio segue l’aggiornamento di Wisp trattato nel numero del 2026-07-08.

Divine Mobile 1.0.17 rafforza la sicurezza dei relay e la consegna dei DM

Divine Mobile, un client Nostr per video brevi, ha rilasciato la 1.0.17 con un editor stop-motion persistente e percorsi Nostr più rigorosi. I messaggi diretti ora attendono le risposte OK dei relay, vengono ritentati tramite una coda persistente e instradati attraverso le liste kind 10050 dei relay di posta in arrivo dei destinatari (PR #6046); l’abbinamento NIP-46 conserva le richieste auth_url come passaggi recuperabili del firmatario (PR #6151). Il PR #6278 elimina l’accettazione permissiva dei certificati dalle WebSocket dei relay in produzione e dalle richieste HTTP usate per upload NIP-96, LNURL e zap, ripristinando la convalida TLS della piattaforma al di fuori delle connessioni loopback di debug. Gli upload interrotti possono inoltre riprendere dall’ultimo offset confermato dal server, così una pubblicazione spostata in background non ricomincia più da zero.

ClipRelay v0.1.2 (nuovo progetto) sincronizza gli appunti tra dispositivi attraverso i relay Nostr

ClipRelay è un’app multipiattaforma appena lanciata (Android, macOS, Windows, Linux) che sincronizza gli appunti tra i propri dispositivi: copia su una macchina, incolla su un’altra. Tutto il traffico passa attraverso i relay Nostr come eventi cifrati NIP-44 indirizzati a se stessi, quindi non c’è nessun server da gestire e nessun account da creare; la chiave privata resta fuori dall’app. La v0.1.2 corregge un sottile fallimento di sincronizzazione per cui una macchina che si risvegliava dalla sospensione continuava a pubblicare ma smetteva silenziosamente di ricevere, e rafforza gli indicatori di stato dei relay che in precedenza segnalavano come sane sottoscrizioni morte. Questa è la prima apparizione di ClipRelay nella newsletter.

Sonar v0.1-alpha.11 prosegue la linea alpha

Sonar, la storia principale della scorsa settimana, ha taggato la v0.1-alpha.11 con lavoro sul motore di collegamento mesh in Rust, correzioni a BLE e alla mesh, e diagnostica dei relay; un seguito incrementale alla linea alpha trattata nel #31.

nak v0.20.2 aggiunge i flussi di lavoro per i pull request NIP-34

nak, lo strumento da riga di comando per Nostr, ha rilasciato la v0.20.2 con comandi per creare, recuperare e integrare pull request NIP-34, oltre che per recuperare singole patch; consente inoltre i push senza riscrivere l’annuncio del repository. L’intervallo di 11 commit del rilascio aggiunge anche la gestione dei gruppi genitore per NIP-29, interroga più relay outbox, rende configurabili i timeout di connessione ai relay e corregge la selezione del bunker quando è presente soltanto il valore predefinito di --sec.

I lanci minori della settimana

Quattro rilasci minori meritano una riga ciascuno: noscall v0.6.0, l’app per chiamate Nostr, ha migrato le notifiche push a UnifiedPush, mantenendo il signaling delle chiamate fuori dall’infrastruttura push di Google; nostr-vpn v4.1.3, una VPN mesh che usa Nostr per il signaling, ha uniformato la policy DNS di uscita tra le piattaforme e ora ripristina il routing e lo stato DNS originali al termine delle sessioni WireGuard o con uscita privata; StableKraft v1.3.0, l’aggregatore di musica e podcast Nostr più Lightning trattato ad aprile, ha aggiunto i controlli nativi Android dalla schermata di blocco e dalle cuffie, oltre a un wake lock limitato alla riproduzione affinché l’audio continui durante Doze; e la nuova app Zapstore Hakari esegue il backup di un registro del peso tramite eventi Nostr cifrati.

Amethyst completa il QA pre-rilascio della v1.13.0 su isolamento dei napplet e autorità Concord

Amethyst ha integrato 88 PR questa settimana in vista del rilascio della v1.13.0. Il PR #3650 è un passaggio di QA pre-rilascio che copre l’isolamento degli account dei napplet, correzioni all’autorità Concord e circa 30 altre correzioni. Il lavoro svolto verso la fine della finestra aggiunge su Desktop la visualizzazione, la creazione e il voto dei sondaggi NIP-88, il conteggio tramite i relay dichiarati e la ricerca dei kind 1068 (PR #3664); la ricerca NIP-50 ora ordina i risultati per rilevanza BM25, mentre i watcher di tag di grandi dimensioni usano un’unione limitata (PR #3663). Un intervento separato sul relay store seleziona gli indici delle query in base al costo misurato, aggiunge indici tag-autore-kind e serializza ogni evento live una sola volta per ciascun fanout (PR #3660), con riduzioni dichiarate nei benchmark da 149 a 4 millisecondi per un tipo di query e da 14,2 a 0,66 millisecondi per una comune query sulle stanze DM.

Modifiche non rilasciate

Snort riscrive la sincronizzazione delle query attorno alla copertura comprovata da EOSE

Snort, un client Nostr web, ha riscritto il percorso delle query e della sincronizzazione della cache nel commit 8a62770. Il client ora registra quali finestre di query hanno raggiunto EOSE, usa questi watermark per saltare gli intervalli della cache già coperti, centralizza la distribuzione degli eventi dietro un unico listener del pool di relay e invia i filtri di ricerca soltanto ai relay i cui documenti NIP-11 dichiarano il supporto per NIP-50. Le correzioni successive serializzano gli aggiornamenti concorrenti dei watermark e correggono i limiti inclusivi delle timeline, mentre il commit 9d1721b ripristina una sottoscrizione live al feed dei follow suddiviso in blocchi, così gli eventi che arrivano dopo il caricamento della pagina non restano bloccati fuori dalle finestre in cache.

Shopstr lega la convalida dei pagamenti alle ricevute firmate e ai prezzi lato server

Shopstr, un client per marketplace Nostr, ha chiuso due falle nell’integrità dei pagamenti. Il PR #552 fa sì che Zapsnag verifichi la firma, il firmatario, la richiesta di zap incorporata, i tag del destinatario e del prodotto, l’importo BOLT11 e il preimage facoltativo di ogni ricevuta kind 9735 rispetto all’hash di pagamento della fattura prima di considerarla un acquisto. Il PR #449 sposta la creazione dei preventivi Cashu dietro una route API di Shopstr che risolve l’inserzione e ne ricalcola il prezzo lato server, così un importo modificato nel browser non può determinare la fattura del mint.

Mostr collega le chat private ActivityPub ai DM Nostr

Mostr, un bridge da ActivityPub a Nostr, ora trasporta in entrambe le direzioni gli oggetti ChatMessage individuali di Pleroma e i DM Nostr cifrati (commit 36ee547). Le chat private ActivityPub diventano eventi kind 4 indirizzati al destinatario Nostr, mentre i messaggi kind 4 inviati agli utenti Fediverse collegati vengono decifrati e federati come oggetti ChatMessage. Il bridge limita questi eventi ai relay DM configurati, protetti da NIP-42, e si autentica con una chiave del relay separata. Questo percorso di interoperabilità usa la cifratura legacy NIP-04. Il gift wrapping NIP-17 resta escluso da questa implementazione.

nostream integra otto PR senza taggare un rilascio

nostream, l’implementazione di relay in TypeScript, ha integrato otto PR questa settimana senza taggare un rilascio. La coppia principale è PR #702 e PR #676, che insieme forniscono agli operatori di relay uno stack funzionante di controllo degli accessi basato su autenticazione e appartenenza; il NIP Deep Dive di questa settimana illustra esattamente quell’handshake. Il PR #694 corregge i filtri generici per tag #e, #p, #g e simili, che potevano restituire una copia di un evento per ogni riga di tag corrispondente, riducendo il traffico di protocollo duplicato all’interno di una sottoscrizione.

FIPS v0.4.1 rafforza il livello di trasporto di Iris

jmcorgan/fips ha rilasciato la v0.4.1, un rilascio di manutenzione che limita lo stato antipoison, corregge la convergenza e la gestione dell’MTU e riduce l’uso della CPU. Il runtime TypeScript per browser fips-ts del gruppo di progetti Iris è wire-compatible con questo trasporto Rust, quindi le correzioni apportate qui si propagano direttamente all’interoperabilità nel browser.

Lavoro sul protocollo e aggiornamenti dei NIP

Modifiche recenti al repository dei NIP:

Integrati:

NIP-29 (Relay-based Groups): Sottogruppi (PR #2319, integrato il 2026-07-16): NIP-29 definisce gruppi ospitati su relay dove l’appartenenza, i ruoli e la cronologia della chat vivono su un singolo relay come eventi indirizzabili della serie kind:39000, con le azioni di moderazione trasportate da eventi amministrativi della serie kind:9000. Questo PR consente a un gruppo di dichiararsi sottogruppo aggiungendo un tag parent ai propri metadati, che punta all’identificatore d di un altro gruppo sullo stesso relay. I sottogruppi sono gruppi ordinari sotto ogni altro aspetto: l’appartenenza non si propaga a cascata (unirsi a un genitore non concede l’appartenenza a nessun figlio), i ruoli di amministrazione non si ereditano (la lista degli admin kind:39001 di ciascun sottogruppo è autorevole per il proprio ambito), e ogni sottogruppo mantiene i propri eventi indipendenti sui membri kind:9000/kind:9001. I relay che supportano la gerarchia la pubblicizzano nel loro documento informativo NIP-11 sotto un oggetto nip29 con "subgroups": true, così i client possono scoprire la capacità prima di tentare di creare comunità annidate.
NIP-29: Fissaggio dei messaggi (PR #2379, integrato il 2026-07-15; PR #2416, integrato il 2026-07-17): Gli amministratori dei gruppi ora possono fissare messaggi all’interno di un gruppo basato su relay. Il meccanismo aggiunge un nuovo evento di moderazione, kind:9010 update-pin-list, che trasporta l’intera lista ordinata dei messaggi fissati come tag e riferiti agli id di eventi ordinari, e un nuovo evento facoltativo a livello di gruppo, kind:39005 group pinned events, che il relay rigenera per rispecchiare la lista dei messaggi fissati accettata più di recente. Ogni kind:9010 sostituisce l’intera lista, quindi una sola nuova lista esprime il fissaggio, la rimozione, il riordino o l’azzeramento dei messaggi fissati. Il PR successivo #2416 estende il formato affinché la lista accetti anche i tag a, consentendo agli amministratori di fissare eventi indirizzabili (post in formato lungo, pagine wiki e altri contenuti sostituibili parametrizzati) insieme ai normali messaggi di chat. I relay possono limitare il numero di elementi fissati e il testo integrato della specifica consiglia di visualizzarli nell’ordine in cui compaiono i tag.
NIP-29: Tag banner e suffisso con codice di invito (PR #2383, integrato il 2026-07-16; PR #2380, integrato il 2026-07-16): Due aggiunte per la visualizzazione e l’onboarding ai metadati dei gruppi. Il PR #2383 aggiunge un tag opzionale banner all’evento di metadati del gruppo kind:39000, unendosi ai campi esistenti name, picture e about affinché i client possano rendere un’immagine di intestazione per la pagina di un gruppo. Il PR #2380 definisce un suffisso con codice di invito per i link di condivisione dei gruppi: un codice di invito può essere aggiunto all’identificatore naddr del gruppo come naddr1...?invite=<code>. Poiché il set di caratteri bech32 non include ?, la porzione prima del suffisso resta un naddr valido di per sé, così i client che non comprendono l’estensione possono comunque risolvere il gruppo. I client che la comprendono precompilano il tag code sulla richiesta di adesione kind:9021, che si abbina all’evento di moderazione esistente kind:9009 create-invite per semplificare l’ammissione ai gruppi chiusi.
NIP-51 (Liste): Set di follow preferiti, kind:10011 (PR #2413, integrato il 2026-07-15): NIP-51 definisce i kind di lista standard, divisi tra liste sostituibili della serie kind:10000 (una per utente) e set indirizzabili della serie kind:30000 (molti per utente, indicizzati dal tag d). Questo PR aggiunge kind:10011, favorite follow sets, una lista sostituibile standard i cui tag a puntano a set di follow kind:30000. Specchio del kind:10012 (relay feeds), che contiene tag a che fanno riferimento a set di relay kind:30002, il nuovo kind consente a un utente di aggiungere ai segnalibri set di follow con nome, come liste curate di collezioni di pubkey pubblicate da sé o da altri, e di far sì che i client li presentino per seguirli con un tocco o cambiare feed. Si noti che questo numero di kind è già conteso: si veda il PR di rinumerazione aperto più sotto.
NIP-46 (Nostr Connect): Indicazioni sui timeout silenziosi (PR #2375, integrato il 2026-07-15): NIP-46 è il protocollo di firma remota in cui un client invia richieste cifrate in stile JSON-RPC a un firmatario (bunker) tramite relay e attende una risposta cifrata. La modifica integrata consiste in una frase sul comportamento del protocollo: alle richieste effettuate con metodi sconosciuti o non supportati DEVE essere inviato un errore in risposta. In precedenza un firmatario che riceveva un metodo non implementato poteva non rispondere mai, lasciando il client in attesa fino allo scadere del proprio timeout senza alcun modo di distinguere “metodo non supportato” da “firmatario offline”. La risposta di errore obbligatoria consente ai client di interrompere subito l’operazione e mostrare un errore significativo prima del timeout locale.

PR aperti e discussioni:

Rinumerazione di kind:10011 a kind:10021 (PR #2417): Sposta la lista dei set di follow preferiti appena integrata da kind:10011 a kind:10021, perché 10011 è già in uso altrove. Il PR di rinumerazione è stato aperto nel giro di pochi giorni dall’integrazione originale, quindi i client che implementano i set di follow preferiti dovrebbero seguire questo PR e puntare al numero finale, non a 10011.
NIP-47 (Nostr Wallet Connect): Semplificazione del nucleo (PR #2419): Propone di restringere NIP-47, il protocollo wallet-connect che consente alle app di richiedere pagamenti Lightning da un wallet remoto tramite Nostr, in una specifica di nucleo più piccola. Le funzionalità opzionali e più specializzate uscirebbero da 47.md per entrare in un repository dedicato alle estensioni, nostr-wallet-connect/nwc, dove le specifiche delle estensioni possono evolvere indipendentemente dal nucleo. L’obiettivo dichiarato è mantenere il nucleo piccolo, stabile e facile da implementare, seguendo la direzione concordata nelle precedenti chiamate NWC di separare un livello minimale di wallet-connect da comportamenti opzionali più ricchi. Dato quanto ampiamente NIP-47 è distribuito tra wallet e app, chiunque parli NWC dovrebbe seguire la discussione sulla ristrutturazione.
Trusted Relay Assertions (bozza, nessun numero assegnato) (PR #2418): Propone uno standard per pubblicare valutazioni di fiducia sui relay Nostr, posizionato come il livello “ciò che concludiamo” accanto a NIP-11 (ciò che un relay dichiara di sé) e NIP-66 (ciò che i monitor hanno misurato). I fornitori di asserzioni calcolerebbero punteggi di fiducia da metriche osservate, reputazione dell’operatore e segnalazioni degli utenti; i client interrogherebbero queste asserzioni quando scelgono a quali relay connettersi. La bozza introduce kind:30385 (Trusted Relay Assertion indirizzabile, che trasporta tag di punteggio, affidabilità, qualità, accessibilità, operatore, policy e giurisdizione), kind:10385 (Trusted Provider List sostituibile, i fornitori di asserzioni scelti dall’utente), e riusa le etichette NIP-32 per le segnalazioni su relay e operatori. Nessun numero di NIP è stato ancora assegnato; questa è una bozza in fase iniziale.
Operatore AND per i filtri (“NIP-91”, proposto, numero non ancora presente nel repository) (PR #2252): In NIP-01, i filtri sui tag supportano soltanto OR: un filtro "#t": ["meme", "cat"] corrisponde agli eventi con uno dei due tag. Questa proposta aggiunge un modificatore & per i tag indicizzabili, così "&t": ["meme", "cat"] restituisce soltanto gli eventi che contengono entrambi i tag. I relay eseguono l’intersezione lato server e restituiscono un risultato più ristretto. Le regole di compatibilità danno la precedenza ad AND rispetto a OR, ignorano in OR i valori AND sui relay che supportano l’estensione e impongono ai client di includere i tag OR standard # per i relay che non la supportano; i client intersecano localmente questi risultati più ampi. Questo PR riapre una proposta precedente ed elenca implementazioni per i relay, tra cui un’immagine Docker di nostr-rs-relay, netstr e un relay worker di Snort. NIP-91 compare soltanto nel branch del PR e resta assente dall’indice dei NIP nel README del repository, quindi il numero è provvisorio.
Nostr web applets (“NIP-5D”, proposto, numero non ancora nel repository) (PR #2303): Definisce un protocollo postMessage per applicazioni web in sandbox (“napplet”) eseguite in iframe o webview per comunicare con un’applicazione ospitante (“shell”). La specifica è deliberatamente un nucleo sottile: specifica l’involucro dei messaggi, le regole di sandbox (gli iframe dei napplet DEVONO usare sandbox="allow-scripts" senza allow-same-origin, e le shell NON DEVONO esporre window.nostr NIP-07 all’interno dell’iframe), l’identificazione del mittente tramite il riferimento alla finestra MessageEvent.source non falsificabile, non event.origin, e la negoziazione delle capacità basata su manifest. I messaggi di protocollo effettivi per la firma, l’accesso ai relay, l’archiviazione e la comunicazione tra napplet sono delegati alle specifiche di estensione NAP (Nostr Applet Protocol), ciascuna proprietaria di un dominio di capacità, con la firma e la cifratura sempre mediate dalla shell affinché le chiavi non entrino mai nella sandbox. La proposta dipende dalla specifica del manifest dei napplet NIP-5A ed è tempestiva questa settimana: il lavoro pre-rilascio della v1.13.0 di Amethyst include l’isolamento degli account dei napplet, rendendo l’hosting lato client dei napplet un’area di implementazione attiva. Come per “NIP-91” sopra, il numero 5D è provvisorio.

NIP Deep Dive: NIP-42 e NIP-43

Gestire un relay non aperto a tutti un tempo significava inventare tutto da soli. Un operatore di relay a pagamento o solo su invito doveva mantenere una whitelist fuori banda, di solito un file di testo di pubkey raccolti tramite DM, senza alcun modo standard per dire a un client connesso “dimostra chi sei” e senza alcun modo standard per un utente di chiedere l’ammissione o sapere se fosse un membro. Ogni relay che voleva letture o scritture con accesso limitato costruiva il proprio meccanismo privato, e i client non potevano interoperare con nessuno di essi. NIP-42 standardizza la metà del problema relativa alla prova di identità, e NIP-43 standardizza la metà relativa all’appartenenza. Questa settimana nostream, il relay TypeScript, ha integrato la coppia da capo a fondo: il PR #702 limita le letture dei kind cifrati ai destinatari autenticati, e il PR #676 aggiunge le strategie per gli eventi di richiesta di adesione e uscita, entrambi integrati il 20 luglio.

NIP-42: Autenticazione dei client verso i relay

NIP-42 risponde a una domanda: chi si trova su questa connessione? Un relay che vuole limitare le letture o le scritture invia un messaggio AUTH contenente una stringa di sfida, al momento della connessione o quando una richiesta richiede l’autenticazione. Un client risponde con un proprio messaggio AUTH contenente un evento effimero firmato, kind 22242, e il relay risponde con un messaggio OK come se l’evento di autenticazione fosse una normale scrittura. L’autenticazione resta valida per la durata della connessione. Una sequenza di messaggi AUTH può autenticare più pubkey sulla stessa connessione.

L’evento di autenticazione firmato è un oggetto compatto: un pubkey, un created_at, kind 22242, un tag relay, un tag challenge, un content vuoto e una sig sull’id dell’evento. Poiché kind 22242 è effimero — i relay non devono mai memorizzarlo né ritrasmetterlo — non esiste alcun esempio pubblicato da incorporare; la panoramica dei campi qui sotto copre ciò che contiene.

Il pubkey è l’identità di cui si dimostra il possesso, poiché il relay verifica la sig sull’id dell’evento rispetto a quella chiave. Il kind 22242 rientra nell’intervallo effimero: l’evento è una credenziale a livello di connessione e i relay non devono mai archiviarlo né trasmetterlo ad altri client. Un tag relay lega la firma all’URL di un relay, così un evento di autenticazione intercettato non può essere riutilizzato contro un relay diverso, mentre il tag challenge lo lega alla specifica stringa di sfida emessa su questa connessione e blocca i riutilizzi successivi. Il suo created_at deve essere vicino all’ora corrente, entro una finestra di circa dieci minuti, così un evento di autenticazione obsoleto scade da solo. Il campo content vuoto conferma che non viene pubblicato nulla.

La specifica definisce anche due prefissi leggibili dalle macchine che rendono visibile ai client la limitazione degli accessi. Un relay che rifiuta una sottoscrizione perché il client non si è ancora autenticato risponde con un messaggio CLOSED che inizia con auth-required:, e una scrittura rifiutata ottiene un OK con lo stesso prefisso. Un client che si è autenticato ma non ha comunque il permesso per l’azione ottiene invece restricted:. È su questa distinzione che il PR #702 di nostream costruisce: le letture dei kind cifrati possono ora essere chiuse con auth-required: finché il pubkey richiedente non dimostra di essere il destinatario.

NIP-43: Metadati e richieste di accesso ai relay

NIP-43 risponde alla domanda successiva: ora che il relay sa chi sei, cosa ti è permesso fare? Dove NIP-42 è un handshake su una connessione attiva, NIP-43 è un insieme di eventi pubblicati che descrivono lo stato di appartenenza e consentono agli utenti di chiedere di cambiarlo. Sul lato relay, un evento kind 13534, firmato dal pubkey nel campo self del documento NIP-11 del relay, elenca un tag member per pubkey, con argomenti di ruolo opzionali che puntano a definizioni di ruolo pubblicate come kind 33534. Il kind 8000 annuncia l’aggiunta di un membro e il kind 8001 annuncia una rimozione, entrambi firmati dalla stessa chiave del relay con un tag p per il membro interessato. Sul lato utente, il kind 28934 è una richiesta di adesione che trasporta un codice di invito in un tag claim, il kind 28935 è un evento effimero con codice di invito che il relay genera al volo quando un utente richiede un claim, e il kind 28936 è una richiesta di uscita.

Una richiesta di adesione è un oggetto altrettanto piccolo, e nessun relay pubblico implementa ancora NIP-43, quindi non c’è alcun evento kind 28934 reale da incorporare; la panoramica dei campi qui sotto copre ciò che contiene.

Il pubkey è l’utente che chiede l’ammissione e il kind 28934 identifica l’evento come richiesta di adesione. Il suo tag - è il marcatore di evento protetto di NIP-70, che indica ai relay di accettare l’evento soltanto dal suo autore. Un tag claim contiene il codice di invito ottenuto fuori banda e created_at deve corrispondere all’ora corrente, con uno scarto di pochi minuti, così una vecchia richiesta non può essere riutilizzata. I relay rispondono al claim con un messaggio OK, riutilizzano il prefisso restricted: di NIP-42 per errori come un codice scaduto o non valido, aggiornano la lista kind 13534 e possono pubblicare un evento kind 8000 di aggiunta del membro. L’appartenenza non deriva deliberatamente da un singolo evento: la specifica considera la lista firmata dal relay come uno degli elementi disponibili e un client che deve stabilire se qualcuno è attualmente membro dovrebbe consultare sia il kind 13534 del relay sia gli eventi del membro. I client devono inviare richieste di adesione, invito o uscita soltanto ai relay che dichiarano questo NIP nella sezione supported_nips del proprio documento NIP-11, mentre il PR #676 di nostream fornisce il meccanismo lato relay che trasforma questi kind di richiesta in effettive modifiche dell’appartenenza.

Storia

NIP-42 è di gran lunga il più vecchio dei due. È entrato nel repository dei NIP il 2 gennaio 2023, nel commit c80be21c, in cui fiatjaf ha semplificato drasticamente un precedente NIP per l’autenticazione ai relay redatto da semisol, riducendo uno schema di sfida più complesso al singolo evento effimero firmato che la specifica usa ancora oggi. NIP-43 è arrivato molto più tardi, il 30 ottobre 2025, quando è stato integrato il PR #1079 di hodlbod, che ha aggiunto metadati e richieste di accesso ai relay costruiti direttamente sul prefisso restricted: di NIP-42. Il divario di due anni e mezzo riflette quanto a lungo gli operatori di relay a pagamento e privati abbiano usato whitelist ad hoc prima che il livello di appartenenza ottenesse uno standard.

Implementazioni

Sul lato relay, nostream ora include entrambe le metà dopo le integrazioni di questa settimana. strfry implementa NIP-42, validando gli eventi di autenticazione kind 22242 nel suo ingester ed emettendo sfide dalla sua configurazione. nostr-rs-relay gestisce l’handshake AUTH nel suo livello di connessione con test che coprono la sfida e la finestra temporale. khatru, il framework per relay in Go, traccia il pubkey autenticato per connessione affinché le policy possano limitare letture e scritture su di esso. Sul lato client, Amethyst firma risposte kind 22242 alle sfide dei relay, inclusa l’autenticazione per flusso per le sue comunità cifrate Concord. I due NIP dividono il controllo degli accessi lungo una linea pulita: NIP-42 è prova di identità, limitata a una connessione, una sfida e pochi minuti di validità, e non dice nulla sulla policy. NIP-43 è policy, espressa come eventi ordinari di relay: chi è un membro, chi è stato aggiunto o rimosso, e come un utente richiede quelle transizioni. La lacuna che gli implementatori dovrebbero tenere a mente è che nulla standardizza ancora permessi più granulari oltre ai metadati di ruolo opzionali di NIP-43, quindi qualsiasi relay che faccia più di una divisione binaria membro/non-membro sta progettando quel livello da solo.

Per questa settimana è tutto. State costruendo qualcosa o avete notizie da condividere? Contattateci tramite DM NIP-17 o trovateci su Nostr.