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

Questa settimana: Shopstr tiene i segreti del signer remoto e del wallet fuori dall’archivio del browser, Routstr SDK verifica la scoperta di provider proveniente dai relay, Postr debutta come piccolo compositore Android, Infans cifra il monitoraggio familiare e la sincronizzazione tra genitori, walls.rip trasporta chat cifrata con PGP su relay Nostr pubblici, e pakstr rende esplicita la pubblicazione su Zapstore. nostr-tools lega i rumor di gift wrap ai loro seal. Le release coprono l’isolamento delle subscription, gli stati di profilo e i marcatori di uscita per relay. Il lavoro di protocollo arriva al rilascio dei thread di commenti, alle bozze su tetto di commissione e ricerca pagamenti per wallet connect, alle richieste di display per napplet e a un’iscrizione sperimentale dallo stesso account. Il numero si chiude con Sei anni di agosto su Nostr.

Storie principali

Postr debutta come piccolo compositore Android

Postr è un compositore Android deliberatamente piccolo per note kind 1. La custodia della chiave privata resta in Amber, un signer Android NIP-55 (signer locale) e NIP-46. La versione 1.0.0 porta una outbox durevole che sopravvive alla perdita di connettività e alla morte del processo, bozze private per account e allegati Blossom con hash verificati e autorizzazione di upload delimitata.

Una pubblicazione riesce dopo che Postr rilegge l’evento firmato identico e ne verifica la firma. I tentativi ripetuti mantengono lo stesso id evento. La pubblicazione usa i relay di scrittura della lista NIP-65 (lista relay) dell’autore più relay di bootstrap cifrati, oppure una lista personalizzata per account. Un annuncio di repository NIP-34 (git su Nostr) firmato e un profilo di progetto kind 0 corrispondente sono pubblicati su relay.ngit.dev. Feed, analytics, pubblicità e archiviazione delle chiavi restano fuori dall’app.

Infans cifra il monitoraggio familiare e la sincronizzazione tra genitori su Nostr

I genitori possono tenere i dati di alimentazione, sonno e crescita sui propri telefoni e condividerli senza un fornitore di dati familiari. Infans è un tracker per neonati su Android che tratta un database Room locale come fonte di verità e pubblica eventi cifrati kind 30078 di NIP-78 (dati specifici dell’applicazione) per backup e sincronizzazione con il partner. Il suo repository etichetta la cifratura locale come NIP-44 (cifratura del payload), ma l’implementazione usa AES-256-GCM mentre NIP-44 v2 richiede ChaCha20 con HMAC-SHA256, quindi i payload in modalità locale non dovrebbero essere presentati come compatibili con NIP-44.

La sincronizzazione con il partner usa il d-tag baby-tracker-sync, mentre i backup personali usano baby-tracker-backup. Le note asincrone viaggiano dentro il payload del partner. Il percorso Amber NIP-55 documentato (signer locale) delega firma e cifratura al signer, ma il repository non fornisce alcun test di interoperabilità che dimostri che ogni percorso di backup e sincronizzazione produce testo cifrato NIP-44 v2. Il repository non presenta né una dichiarazione di dispositivo medico né una revisione di sicurezza esterna.

Il Ghost Chat di walls.rip porta la chat cifrata con PGP sui relay Nostr pubblici

walls.rip è un insieme di strumenti per comunicazione anonima la cui modalità Ghost Chat crea o importa un’identità OpenPGP nel browser. Il suo client open source cifra ogni messaggio con la chiave pubblica PGP del destinatario. La conversazione leggibile resta nell’archivio di sessione locale del dispositivo; l’applicazione non ha né account di chat né database centrale di messaggi.

Il trasporto è Nostr reale, ma è deliberatamente specifico dell’app. Ghost Chat pubblica testo cifrato in formato armored come eventi kind 1 verso cinque relay predefiniti ed etichetta ogni evento con un tag stanza stabile derivato dall’impronta PGP del destinatario. Questo dà agli sviluppatori un esempio concreto di uso dei relay come trasporto di messaggi resistente alla censura, e mostra anche perché la consegna decentralizzata da sola non protegge i metadati e non è interoperabile con i messaggi diretti NIP-17.

pakstr da 0.13.0 a 0.15.0 rende esplicita la pubblicazione su Zapstore

Dopo il lavoro di packaging e Amber della 0.3.1 a luglio, pakstr è una CLI che trasforma una cartella di risorse web in un APK Android firmato e lo pubblica su Zapstore con una chiave Nostr. La 0.13.0 aggiunge il versionamento automatico delle release. Le successive 0.13.1 fino a 0.13.3 riparano la pubblicazione su Blossom: l’autorizzazione ora usa base64url, gli upload portano un Content-Digest, e l’evento applicazione di Zapstore è pubblicato prima dell’upload su Blossom.

La 0.14.0 valida il publisher Zapstore prima che una pubblicazione proceda. La 0.15.0 scrive i metadati della scheda su eventi applicazione kind 32267 e mette le note di rilascio nel content degli eventi release kind 30063, così che la scheda Zapstore di un’app pacchettizzata possa portare nome, riassunto e note senza un passaggio manuale separato.

Heterodyne specifica persona portabili e comunicazione sociale cifrata

Heterodyne è una famiglia di protocolli orientata alla specifica per persona portabili, comunicazione autenticata, controllo del proprio dispositivo e interazione sociale. Il suo README attuale compone quattro livelli esistenti: eventi Nostr firmati, Radicle (git peer-to-peer) come archiviazione durevole, Marmot (messaggistica di gruppo MLS su Nostr) per conversazioni cifrate dirette e di gruppo, e log di eventi di chiave KERI (Key Event Receipt Infrastructure) per la rotazione dell’identità. Una persona è descritta come un npub Nostr a radice fredda più un log KERI accettato; la firma ordinaria usa chiavi di epoca rotanti, mentre le identità dei nodi Radicle sono delegate con doppia prova.

La famiglia divide quel lavoro in quattro bozze 0.x versionate in modo indipendente. Core detiene identità, verifica dei log di eventi di chiave, byte canonici Nostr e il substrato di repository Radicle; Comms detiene le buste native Nostr, i livelli di privacy, la pubblicazione e le conversazioni Marmot; e Social detiene il following pubblico, le interazioni e le liste. Control, per l’iscrizione e i permessi del proprio dispositivo, è incompleto e non può essere rivendicato. Questi documenti restano bozze che possono rompersi prima della 1.0, e questo numero presenta la famiglia prima che sia arrivata qualsiasi release di client Heterodyne.

Release

Nostr Java v2.0.8: isolamento delle subscription e NIP-44 portabile

Una query gift wrap contro un relay con cinque eventi ne restituiva zero, due o sei a caso, perché Nostr Java, una libreria Java per dialogare con i relay e cifrare payload Nostr, consegnava ogni frame in ingresso a tutti i listener della connessione. La versione 2.0.8 indirizza EVENT, EOSE e CLOSED alla subscription che quei frame nominano, così il segnale di fine eventi memorizzati di una query non può più chiuderne un’altra. I frame con ambito di connessione come NOTICE, OK e AUTH raggiungono ancora tutti i listener.

NIP-44 (cifratura del payload) nella stessa release non richiede più un provider JCE registrato nel processo. La cifratura funzionava solo dopo aver generato una chiave in quella JVM, cosa che registrava BouncyCastle come effetto collaterale, e falliva su Android, dove aggiungere un provider chiamato “BC” non fa nulla. Entrambi i percorsi di cifratura ora usano il motore ChaCha20 leggero di BouncyCastle, e la generazione delle chiavi non altera più lo stato JCE globale del processo. Chi si affidava alla libreria per registrare il provider deve registrarlo da sé. La dipendenza di NIP-44 dal provider JCE è la issue che questo chiude.

NoorNote v1.3.6: stati di profilo e annunci

NoorNote è un client Nostr per desktop, web e Android. Una settimana dopo che la 1.3.4 ha aggiunto gli ingressi cifrati nelle community, la versione 1.3.6 mostra NIP-38 (stati utente) sotto il nome NIP-05 (verificato via dominio) di un profilo: gli eventi indirizzabili kind 30315, con scadenza opzionale, che portano uno stato generale o musicale su una riga. Un clic su quella riga imposta lo stato di chi guarda.

Gli annunci da NIP-99 (offerte di marketplace kind 30402) ora vengono resi in tutta l’app, quindi l’addon marketplace serve solo per comprare e vendere. Le note private di soprannome sui profili appaiono anche in arancione di avviso, con icona nota piena e anello arancione sull’avatar.

nostrord v2.9.0: stato di gruppo e media per relay

Lasciare un gruppo NIP-29 (gruppi gestiti dal relay) su un host prima sopprimeva lo stesso id di gruppo su ogni altro relay, perché nostrord, un client multipiattaforma per community ospitate su relay, indicizzava i suoi marcatori di uscita ed eliminazione per id nudo. I marcatori di uscita ed eliminazione delimitati per relay mantengono quelle soppressioni sull’host che le ha prodotte, così un gruppo che condivide un id fra due relay non viene più abbandonato né scartato in coppia. Un ingresso che il relay rifiuta perché si è già membri ora conta come successo e cancella il marcatore locale, che era stato uno stato assorbente: l’autoriparazione liberava uno slot mentre l’avvio a freddo ripristinava l’altro.

La versione 2.9.0 rende anche le immagini incorporate in markdown che altri client scrivono come ![alt](url), invece di mostrare la punteggiatura markdown attorno a una URL già rilevata. I messaggi diretti adottano NIP-17 (DM privati in gift wrap) e i rumor di file kind 15, così un allegato cifrato inviato da Jumble viene scaricato, decifrato e mostrato, e gli allegati in uscita sono cifrati prima dell’upload. Questo tag consegna ora il lavoro sulla chiave di cifratura NIP-4e trattato la settimana scorsa. La proposta resta non integrata, e nostrord dice che la sua implementazione segue il comportamento di Jumble in produzione dove quel comportamento differisce dalla bozza.

Modifiche non rilasciate

Shopstr tiene i segreti del signer remoto e del wallet fuori dall’archivio del browser

Shopstr è un marketplace web per annunci NIP-99. Dopo il lavoro sull’integrità dei pagamenti del mese scorso, smette di scrivere in localStorage i segreti serializzati del signer bunker. Un payload bunker NIP-46 (firma remota) aveva incluso la URL bunker:// attiva e la chiave privata di app generata, così qualsiasi script nell’origine Shopstr poteva riprendere la sessione di firma remota. I dati del bunker ora restano in memoria per la sessione corrente, i payload bunker residui vengono rimossi quando vengono trovati, e i tipi di signer diversi da bunker mantengono il loro comportamento di archiviazione precedente.

La modifica NWC corrispondente fa lo stesso per le credenziali NIP-47 (wallet connect). Shopstr aveva memorizzato l’intera stringa nostr+walletconnect://, incluso il segreto usato per le azioni sul wallet, come normale dato del browser, e la riusava al checkout. Le stringhe di connessione e i metadati del wallet ora restano in memoria, e le copie memorizzate più vecchie vengono cancellate quando i dati locali vengono letti. Gli script che già girano nell’origine Shopstr durante una sessione attiva possono ancora vedere quei valori in memoria.

Routstr verifica la scoperta di provider proveniente dai relay

Un singolo relay malevolo poteva prima decidere di quali provider di inferenza si fidava un client Routstr. Routstr SDK è la libreria TypeScript dietro Routstr, un marketplace che scopre provider di IA su Nostr e li paga con Cashu. La correzione della scoperta di questa settimana verifica ogni annuncio di provider, elenco di modelli e recensione consegnati dai relay (kind 38421, 38423 e 38425) prima che un consumatore li veda, così una recensione che nomina una pubkey fidata ma porta una firma non valida non entra più nel ranking.

I timestamp molto nel futuro vengono scartati prima della selezione della “recensione più recente”. Gli eventi oltre quindici minuti avanti rispetto all’orologio locale vengono rimossi sul percorso live e alla lettura dell’archivio persistente, il che impedisce a un created_at falsificato di superare recensioni firmate validamente attraverso i riavvii. Se le recensioni fidate non sono disponibili, il gate delle recensioni fallisce in chiusura ed esclude dal ranking di pagamento i provider senza recensione fino all’arrivo delle recensioni. Gli operatori possono ancora abilitare un provider a mano.

nostr-tools lega i rumor di gift wrap ai loro seal

Scartare un evento NIP-59 (gift wrap) prima decifrava il wrap, decifrava il seal e restituiva il rumor interno senza controllare da chi venisse il seal. nostr-tools è una libreria JavaScript di utilità del protocollo Nostr. La correzione di scarto di questa settimana richiede che il wrap sia kind 1059, che il seal sia kind 13 con firma valida, e che il pubkey del rumor sia uguale al pubkey del seal. Decifrare il seal prova già il controllo di seal.pubkey. Senza l’ultimo controllo, chiunque potrebbe sigillare un rumor che nomina qualcun altro come autore e far sì che un client attribuisca il messaggio a quella vittima.

NIP-17 (DM privati in gift wrap) usa lo stesso percorso di scarto, quindi il legame si applica ai DM privati. Lo scarto in batch ora salta un wrap che non passa quei controlli invece di lanciare un’eccezione, perché i gift wrap non sono richiesti e un solo evento ostile scarterebbe altrimenti il resto di una query al relay.

Haven aggiunge amministrazione firmata del relay e un browser locale di note

Haven è un relay Nostr self-hosted e un server di media Blossom. La sua console di amministrazione appena integrata espone chiamate di gestione NIP-86 su ogni endpoint del relay, con ogni richiesta autenticata da un evento NIP-98 del proprietario configurato. Gli operatori possono gestire ban, liste di permessi, regole sui kind, nomi del relay e media memorizzati senza dare al relay una chiave di firma. Un browser di note in sola lettura mantiene opachi i kind cifrati e carica i media remoti solo dopo un clic, evitando una richiesta automatica che rivelerebbe l’indirizzo IP dell’operatore a un host esterno.

La stessa modifica di Haven aggiunge grafici di traffico persistenti e corregge un guasto con LMDB predefinito in cui contare gli eventi memorizzati poteva ciclare all’infinito, saturare un core della CPU e bloccare le chiamate di statistiche successive. Haven ora usa il contatore del backend dove termina e una scansione limitata degli eventi altrimenti. Il progetto ha aggiunto i suoi primi 23 test su paginazione degli eventi, eliminazione, persistenza delle metriche, controlli sul proprietario e firme di richiesta legate alla URL.

Amethyst sposta l’autorizzazione Blossom fuori dai thread di caricamento immagini

Amethyst, un client Nostr per Android, non aspetta più l’autorizzazione di lettura Blossom sui thread del dispatcher OkHttp. L’interceptor ora avvia la firma fuori dal thread di rete, mentre il fetcher di immagini attende una firma condivisa per host e ritenta la richiesta del blob protetto. Una raffica di immagini soggette a controllo non occupa quindi più ogni slot di connessione per host mentre un signer risponde.

La stessa patch di Amethyst allinea la codifica del token a BUD-11: Base64url senza padding, ambito server e nessun tag x specifico del blob, permettendo a un token di coprire più blob sullo stesso host. Nuovi test di concorrenza esercitano cache, scadenza, ritentativi firmati e sedici chiamanti simultanei che condividono una firma.

Aggiornamenti NIP e lavoro di specifica del protocollo

NIP

Snort e Ditto ora usano NIP-22 (thread di commenti) per le normali risposte testuali, convergendo su kind 1111 mantenendo percorsi di compatibilità; questo non stabilisce un kind di risposta unico per tutto il protocollo. Dopo che l’emendamento di giugno ha rimosso il divieto di usare NIP-22 sulle note kind 1, un’aggiunta integrata a NIP-30 (emoji personalizzate) elenca kind 1111 fra gli eventi che possono portare tag emoji, con uno shortcode in content risolto da quel tag. Snort, un client Nostr web, ora scrive ogni risposta come kind 1111, carica quei commenti tramite tag di ambito radice E/A in maiuscolo, e accetta ancora un percorso NIP-10 (tag di risposta kind 1) opzionale per le note più vecchie. Ditto, server Mastodon e relay Nostr combinati, pubblica ogni risposta come commento NIP-22, kind 1111 per il testo e kind 1244 per la voce, continuando a rendere le risposte kind 1 esistenti. I client che capiscono solo NIP-10 non vedranno la nuova forma. I post di primo livello restano kind 1.

Una richiesta pay_invoice di NIP-47 (Nostr Wallet Connect) attualmente non ha un modo standard perché il client specifichi un tetto alla commissione di routing. Una proposta aperta sul tetto di commissione aggiunge un parametro opzionale max_fee, in millisatoshi, a pay_invoice. I wallet che rispettano il budget NON DEVONO inviare un pagamento il cui costo di routing superi amount + max_fee e DEVONO restituire FEE_LIMIT_EXCEEDED, definito come nessun addebito e nessun pagamento tentato. Le implementazioni che lo supportano DEVONO includere fees_paid nella risposta perché il client possa riconciliare. Le implementazioni senza supporto al limite di commissione ignorano il parametro sconosciuto, e i client dovrebbero trattare un campo fees_paid mancante come segnale che il tetto potrebbe non essere stato applicato. La modifica non aggiunge kind di evento e resta una proposta fino all’integrazione.

Una proposta aperta su etichette di lingua in NIP-32 standardizzerebbe ["l", "<BCP-47>", "lang"] per la lingua del testo dichiarata dall’autore. Poiché il tag l di una sola lettera è già indicizzabile dai relay, i client potrebbero chiedere un feed in giapponese con {"#l":["ja"]} senza aggiornare il relay né ricorrere a un rilevamento di lingua poco affidabile dopo il download. La bozza migra anche gli esempi di lingua nei report di relay NIP-66, nei metadati immagine NIP-68 e nelle tracce audio NIP-71 nello stesso namespace. Le etichette restano affermazioni non verificate dell’autore, e la modifica non è integrata.

Nostr Wallet Connect

Dopo un timeout, una riconnessione o una notifica mancata, un client wallet connect ha bisogno di un modo per chiedere un singolo record di pagamento senza sapere quale protocollo di pagamento Bitcoin l’ha creato. Una bozza aperta sulla ricerca dei pagamenti nel repository di estensioni NWC definisce l’opzionale NWC-09 lookup_payment accanto al nucleo NIP-47. La richiesta usa esattamente un selettore: un transaction_id stabile con ambito wallet, i campi payment_hash e/o invoice compatibili con BOLT11 già usati da lookup_invoice, oppure un payment_type più un oggetto lookup tipizzato definito da un’altra estensione. Un risultato riuscito restituisce una busta comune (transaction_id, type, state, payment_type, amount in msat, timestamp, fees_paid e metadata opzionali, e un oggetto details discriminato) e DEVE risolversi in esattamente un record visibile a quella connessione. Il wallet NON DEVE rivelare se esiste un record inaccessibile, e un selettore che corrisponde a più record visibili restituisce MULTIPLE_MATCHES. Gli stati sono pending, accepted, settled, failed, expired e canceled. La stessa proposta aggiunge dettagli di offerta e pagamento BOLT12 in NWC-12 che riusano quella busta. Entrambi i documenti sono ancora bozze.

NAP

Una bozza aperta NAP-DISPLAY permetterebbe a un napplet di chiedere al proprio host i display a pixel che ha il permesso di usare. Si appoggia alla proposta di web applet NIP-5D, non integrata e trattata separatamente, che la Newsletter #17 ha presentato e che resta fuori dall’insieme dei NIP integrati. La bozza definisce display.list, che restituirebbe identificatori stabili opachi con larghezza e altezza logiche e un tipo scelto a runtime (lcd, eink, led-matrix o other), e display.push, che invierebbe un batch non vuoto di pixel sRGB da tre byte indirizzati per coordinate. La scoperta a runtime mapperebbe l’RGB logico su profondità di colore nativa, orientamento e refresh e PUÒ ruotare, riordinare, quantizzare, applicare dithering o unire gli aggiornamenti. La policy della shell controllerebbe quali display un napplet può elencare o scrivere e PUÒ rifiutare, limitare la frequenza o porre un tetto ai batch. Prima di applicare qualsiasi pixel, il runtime validerebbe l’intero batch, così un push fallito non cambierebbe nulla sul dispositivo. Il successo significherebbe che il batch è stato accettato, non che il refresh dell’hardware sia finito.

Marmot

Un esperimento aperto di Marmot sostituirebbe la bozza External Commit ritirata per l’iscrizione dallo stesso account con una forma di Commit delimitata. Marmot, il protocollo di messaggistica di gruppo MLS su Nostr, assegna in quella bozza il componente senza dati 0x800d (marmot.same-account-membership.v1) come marcatore di comportamento negoziato. Finché è richiesto, una foglia corrente può redigere esattamente un Add inline dello stesso account oppure da uno a quattro Remove inline di fratelli, ciascuno con un UpdatePath normale e priorità di convergenza ordinaria, e ogni Commit DEVE lasciare al più cinque foglie correnti per account. L’accoppiamento usa un QR effimero mostrato dallo sponsor (marmot-pairing-v1:) il cui segreto alimenta HKDF-SHA256 e ChaCha20-Poly1305 su un canale indipendente dal vettore. Prove kind 453 solo locali legano la sessione alla chiave di account condivisa e non vengono mai inviate ai relay. Dopo un Welcome corrispondente, il primo payload applicativo di chi entra è una conferma kind 452 non resa, legata ai digest di Welcome e GroupInfo, così che un Welcome identico byte per byte possa essere recuperato senza consumare di nuovo il KeyPackage. Lo sponsor accoppiato è la radice di fiducia di chi entra per quel ramo e non prova finalità globale. Un documento complementare sulla sincronizzazione degli account resta esplorativo e non interoperabile. L’esperimento non fa parte del profilo base adottato.

Sei anni di agosto su Nostr

Gli agosti seguono un solo problema di interoperabilità: come un client nomina un obiettivo e vi allega un riscontro. Il repository originale del protocollo non ha registrato commit ad agosto 2021, quindi il nucleo degli eventi firmati è rimasto fermo. NIP-25 (reazioni) ha poi lasciato la casella dei soli kind 1 nel 2022. I record sostituibili regolari hanno guadagnato coordinate naddr e a con identificatore vuoto nel 2023; nel 2024 la classe sostituibile parametrizzata separata è stata rinominata eventi indirizzabili senza cambiare il formato di trasmissione. Le reazioni si sono spostate su media esterni nel 2025. Il kind 1111 di NIP-22 (thread di commenti) ha raggiunto client in produzione nel 2026. La progressione va da un documento di protocollo fermo a un vocabolario condiviso di risposte e reazioni che funziona su note, record sostituibili e oggetti fuori dalla rete.

Agosto 2021

La finestra di commit di agosto 2021 nel repository originale del protocollo è vuota. L’ultima modifica prima di quel mese inattivo fu la bozza NIP-05 del 18 giugno, che aggiunse identificatori di dominio DNS come puntatore leggibile da un umano verso una chiave pubblica. NIP-05 (identificatori di dominio) è passato più tardi a un file JSON well-known, ma a metà 2021 era ancora una ricerca TXT DNS. Agosto non ha esteso quel lavoro sugli identificatori né aggiunto un nuovo kind di evento o messaggio di relay.

La stessa finestra vuota compare negli strumenti che già esistevano accanto alla specifica. noscl, un client a riga di comando creato a gennaio 2021, non ha registrato commit ad agosto; nemmeno go-nostr o nostr-tools. L’attività di protocollo è ripresa solo a fine anno, quando il repository ha assegnato NIP-09 (richieste di eliminazione degli eventi) e ha sostituito lo schema DNS con un file JSON well-known di identificatori. Agosto 2021 è la fase inattiva fra la bozza di identificatori di giugno e il lavoro su eliminazione e JSON well-known di dicembre, mentre il modello di eventi firmati e relay reggeva così come era scritto.

Agosto 2022

Il 19 agosto, una modifica a NIP-25 ha esteso gli obiettivi delle reazioni kind 7 dalle note testuali kind 1 ad altre note. L’evento kind 7 e la convenzione +/- erano già nella bozza. Quella modifica di interoperabilità ha permesso a un like, un dislike o un’emoji di attaccarsi a un profilo, a una lista di follow o a qualsiasi kind di evento successivo che riusasse gli stessi tag e e p.

L’attuale specifica NIP-25 mantiene quella generalizzazione: una reazione indica reazioni dell’utente ad altri eventi, e un obiettivo indirizzabile riceve anche un tag a con coordinate kind:pubkey:d-tag. Amethyst, un client Android, implementa quel contratto nel suo builder di reazioni. Il builder accetta qualsiasi evento, scrive tag e, p e k, e aggiunge un tag a quando l’obiettivo è un evento indirizzabile. Questo ha generalizzato gli obiettivi delle reazioni oltre il kind 1; modifiche di agosto successive hanno aggiunto coordinate stabili e tag di contesto per i commenti.

Anche il software di relay stava traducendo regole sui tag in comportamento di archiviazione. Il 17 agosto, nostr-rs-relay ha smesso di trattare ogni valore di tag dall’aspetto esadecimale come chiave di indice binaria. Ha limitato quell’ottimizzazione ai tag di una sola lettera e ai valori esadecimali minuscoli, preservando i normali tag testuali invece di decodificarli in una forma che i filtri non potevano far corrispondere. Quel mese ha così unito due lati dell’interoperabilità: le specifiche hanno ampliato ciò che un’interazione poteva prendere come obiettivo, mentre un relay correggeva come quei tag obiettivo venivano indicizzati e recuperati.

Agosto 2023

Il 24 agosto, NIP-19 (identificatori bech32) ha definito come codificare un evento sostituibile non parametrizzato come naddr. Il campo identificatore, il tag d, è diventato una stringa vuota per i kind che si sostituiscono per sola pubkey e kind, come metadati e liste di contatti. Cinque giorni dopo, NIP-01 (il protocollo base di eventi e relay) ha aggiunto il formato a-tag corrispondente: kind:pubkey: con due punti finali e senza identificatore. I client potevano ora puntare a un record sostituibile senza attendere un id di evento specifico che la sostituzione successiva avrebbe invalidato.

L’attuale testo di NIP-19 dice ancora a chi implementa di usare una stringa vuota per quegli eventi sostituibili. nostr-tools, la libreria JavaScript di identificatori, codifica quel campo tramite naddrEncode, così chi la chiama può passare un identificatore vuoto e produrre una coordinata condivisibile. Il lavoro di agosto 2023 ha reso lo stato sostituibile qualcosa che un commento, una reazione o un link di condivisione potevano nominare dopo che l’evento sottostante era stato sostituito. L’agosto successivo ha standardizzato la terminologia della classe sostituibile parametrizzata collegata, mentre tag di commento successivi hanno riusato la grammatica delle coordinate come A e a.

I payload privati stavano diventando portabili nello stesso periodo. Il 24 agosto, rust-nostr ha aggiunto funzioni di cifratura e decifratura NIP-44 ai suoi binding JavaScript, esponendo lo schema versionato di chiave di conversazione alle applicazioni web accanto ai chiamanti Rust nativi. Il 22 agosto, Amethyst ha separato la cifratura NIP-44 dal formato dell’evento di messaggistica, riflettendo la separazione di protocollo fra come il contenuto è cifrato e come un’applicazione lo trasporta. Le coordinate stabili hanno reso gli oggetti pubblici più facili da referenziare; le API di cifratura riusabili hanno reso il contenuto privato più facile da spostare fra implementazioni senza legarlo a un kind di messaggio.

Lo stesso mese ha portato anche finanziamenti per lavoro adiacente su isolamento delle chiavi, interfacce e formazione. Un ciclo di sovvenzioni OpenSats del 17 agosto ha assegnato le sue sovvenzioni del Nostr Fund ad Amber, al design condiviso dell’interfaccia Nostr e alla formazione sui casi d’uso di Nostr. La sovvenzione di Amber si concentrava sul mantenere le chiavi di firma in un’applicazione Android dedicata tramite NIP-46, mentre le sovvenzioni su design e formazione affrontavano l’onboarding e schemi applicativi riusabili. Il sistema Nostr più ampio avanzava attraverso commit di specifica, isolamento delle chiavi, lavoro sull’interfaccia e formazione degli sviluppatori finanziata come infrastruttura condivisa.

Agosto 2024

Il 20 agosto, le specifiche hanno rinominato “evento sostituibile parametrizzato” in “evento indirizzabile” in NIP-01 e in altri sedici documenti, inclusi articoli long-form, attività live, liste, calendari e annunci. Il formato di trasmissione non è cambiato. kind:pubkey:d-tag è rimasta la coordinata. Ciò che è cambiato è che ogni specifica che già usava quelle coordinate ora usava la stessa parola per indicarle.

Quel vocabolario è quello che le implementazioni attuali rilasciano. NIP-01 memorizza gli eventi indirizzabili come il record più recente per kind, pubkey e tag d. NIP-19 chiama un naddr “a nostr addressable event coordinate”. Il percorso di reazione di Amethyst, citato sopra, tipizza l’obiettivo come AddressableEvent prima di scrivere il tag a. L’estensione delle coordinate del 2023 e il cambio di terminologia del 2024 usano entrambi la grammatica di coordinate kind:pubkey:d-tag, mentre NIP-01 continua a distinguere gli eventi sostituibili regolari dagli eventi indirizzabili. Un commento successivo può quindi recuperare una discussione indirizzabile tramite A maiuscolo senza curarsi di quale id di evento occupi quell’indirizzo al momento.

I protocolli di archiviazione applicavano la stessa preferenza per identificatori espliciti. Il 27 agosto, il BUD-04 di Blossom ha permesso a un evento di autorizzazione di portare più tag x di hash di blob, così un client poteva autorizzare un batch delimitato di upload, mirror o eliminazioni senza pretendere che gli hash descrivessero un solo oggetto. Quattro giorni dopo, il progetto ha chiarito il suo descrittore di blob e aggiunto un esempio. Gli eventi Nostr coordinavano operazioni su media indirizzati per contenuto mentre i byte restavano su server di media, separando l’autorizzazione firmata dal trasporto di archiviazione.

Il 29 agosto, la firma remota è diventata più tollerante verso insiemi di relay imperfetti. go-nostr ha modificato il suo client NIP-46 perché un relay difettoso non potesse bloccare una richiesta inviata tramite altri relay configurati: le connessioni ai relay e i tentativi di pubblicazione girano in modo indipendente, e la chiamata procede appena una qualsiasi connessione riesce. Il 19 agosto, OpenSats ha anche annunciato un sostegno di lungo periodo al creatore di Amethyst, Vitor Pamplona, incluso lavoro sui messaggi privati NIP-17, sulle librerie multipiattaforma e sul modello outbox. Vocabolario del protocollo, trasporto resiliente, lavoro sulla privacy e finanziamento continuativo della manutenzione convergevano sullo stesso obiettivo: client capaci di continuare a funzionare fra dispositivi e condizioni di relay disomogenee.

Agosto 2025

Il 22 agosto, NIP-25 ha guadagnato le reazioni a contenuto esterno. Una reazione a qualcosa che non è un evento Nostr nativo deve essere kind 17 e deve portare i tag k e i di NIP-73 (identificatori di contenuto esterno), sostituendo il vecchio tag r per i siti web. Gli esempi nel testo integrato sono una URL web (k=web) e un episodio di podcast identificato da GUID del programma e GUID dell’elemento, con URL Fountain come suggerimenti. Le reazioni avevano lasciato il kind 1 nel 2022. Ora lasciavano l’insieme degli eventi Nostr.

Fountain 1.3, pubblicato il 15 agosto 2025, ha rilasciato quei like prima dell’integrazione della specifica e ha detto che si basano su Nostr perché altre app di podcast possano leggerli. L’attuale documento NIP-25 usa ancora l’esempio di GUID di podcast di Fountain. Ad agosto 2025 una coordinata di reazione poteva nominare un episodio di podcast o una pagina web con la stessa grammatica di identificatori che un commento usa poi per una radice esterna.

Agosto 2026

Questo agosto ha portato i thread di commenti nei client che scrivono risposte ordinarie. L’emendamento di giugno, integrato più tardi, ha rimosso la riga che diceva ai client di non usare i commenti NIP-22 sulle note brevi. NIP-30 (emoji personalizzate) ha poi aggiunto kind 1111 accanto a note, reazioni e stati utente, così un commento può portare gli stessi tag emoji che quegli altri kind già usavano. Il lavoro di specifica è il permesso. Il lavoro dei client è il rilascio.

Snort, un client web, ora pubblica commenti NIP-22 per obiettivi kind 1 per impostazione predefinita, sottoscrive i thread tramite tag radice E/A in maiuscolo, e accetta kind 1111 nelle notifiche. Ditto, un client web di community, pubblica ogni risposta come commento NIP-22, kind 1111 per il testo e 1244 per la voce, incluse le risposte alle note kind 1, continuando a leggere le risposte NIP-10 (concatenamento di note). Lo spostamento di sei anni si vede in quelle impostazioni predefinite: il 2022 ha generalizzato la reazione, il 2023 e il 2024 hanno nominato la coordinata, il 2025 ha puntato le reazioni fuori dalla rete, e il 2026 ha fatto del commento l’evento di risposta condiviso su quegli stessi obiettivi.

L’infrastruttura per i gruppi privati definiva il ripristino come requisito di interoperabilità. Il contratto di durabilità e riavvio del 13 agosto di Marmot specifica quale stato locale MLS e di pubblicazione deve sopravvivere a un riavvio, e richiede ai client di riconciliare lo stato persistito prima di proseguire le operazioni di gruppo. Questo estende la progressione di agosto oltre il nominare un obiettivo: un client maturo deve anche preservare abbastanza stato crittografico e di consegna per riprendere in sicurezza dopo un’interruzione. Le forme di evento condivise servono solo quando le implementazioni riescono a recuperare lo stato necessario per usarle.

Inviate un DM NIP-17 per condividere un progetto o una notizia attraverso il progetto Nostr Compass.