Nostr Compass #46

Questa settimana: Mostro aggiunge il ricollegamento firmato dell’identità. Amethyst porta i sondaggi privati nei gruppi Marmot e la sincronizzazione cifrata delle impostazioni tra dispositivi. swift-nostr introduce un controllo che si rifiuta di firmare gli event la cui chiave pubblica non corrisponde a quella del firmatario. Chiudiamo con Sei anni di ottobri su Nostr, 2021–2026.

Notizie principali

Mostro

Mostro, il daemon di scambio peer-to-peer coordinato tramite Nostr, ha rilasciato la 0.20.1. La versione aggiunge il ricollegamento firmato dell’identità, che il numero della scorsa settimana descriveva come non implementato, e distribuisce le esportazioni della reputazione finora disponibili solo nel codice sorgente. L’identità collegata firma un’autorizzazione monouso che indica il nodo e la nuova identità, valida al massimo per un’ora. Il daemon registra l’ID dell’event ed effettua il cambio con un compare-and-swap, quindi una firma non riuscita o una race persa non modificano nulla. Gli operatori dispongono inoltre di una RPC sottoposta ad audit, accessibile solo in loopback, che richiede un token di autenticazione e una motivazione. Il ricollegamento non revoca le attestazioni già emesse.

Le modifiche unite successivamente non sono confermate in una release. Un provider opzionale con peg fisso al dollaro USA aggiunge USDT, USDC e DOC al feed Nostr mostro-rates solo quando l’operatore lo abilita. I provider di rete e le quotazioni delle monete inoltrate tramite relay non lo attivano implicitamente. Una modifica successiva rinomina il provider e la sua chiave di configurazione in pegged, sostituendo la chiave stablecoins mai rilasciata. Quota inoltre BTC, LBTC e RBTC a un rapporto fisso di 1:1 in sats e pubblica i tassi come event di kind 30078. Queste ipotesi di peg configurate non garantiscono né il peg né il regolamento. I controlli del peg in tempo reale restano al di fuori di questo meccanismo. Per impostazione predefinita il provider è disattivato. Le valute accettate continuano a filtrare gli ordini; il lavoro su client, protocol-book e peg-guard è separato. I timelock delle cauzioni ora sono gestiti separatamente dall’escrow. La scadenza pubblicizzata degli ordini viene limitata, e la finestra di accettazione nell’order book si chiude prima che una cauzione possa scadere. Le cauzioni maker esistenti da 144 blocchi scadono con l’aggiornamento, e quegli ordini devono essere ricreati. Gli scambi in corso e la modalità Cashu non sono interessati, ma alcune configurazioni degli operatori si rifiutano di avviarsi finché il timelock della cauzione non viene regolato.

Estensione Nostr WoT

L’estensione Nostr WoT, un signer per browser con funzionalità di web-of-trust, ha rilasciato la 0.8.15 con un’opzione per generare la chiave di recupero da 256 bit di entropia ricavata dai dadi o dalle monete dell’utente stesso. I lanci di dadi vengono sottoposti a hash con SHA-256, mentre i lanci di moneta vengono usati come bit grezzi, in una scheda isolata che non mostra la frase di recupero. L’onboarding ora va in timeout quando i relay non sono raggiungibili. La versione 0.8.16 ha aggiunto autorizzazioni permanenti per l’autenticazione ai relay (NIP-42), così gli utenti possono approvare AUTH una sola volta per tutti i relay di un sito o per ogni sito connesso (implementazione dell’autenticazione ai relay). I rifiuti a livello di relay o di sito prevalgono su queste autorizzazioni, e le revoche vengono ricontrollate prima che le richieste in coda vengano risolte. Gli ambiti ampi sono sempre una scelta esplicita dell’utente e non si applicano mai a HTTP Auth (NIP-98). Il limite della coda resta a cinque, quindi le richieste in eccesso continuano a fallire e a essere ritentate. Con la versione 0.8.18 importazione e recupero confluiscono in un unico flusso che rileva i formati delle chiavi e mostra un’anteprima dell’identità, e il recupero compatibile con Nosskey mantiene la stessa identità, gli account esistenti e le passkey originali.

L’SDK separato per sviluppatori, nostr-wot-sdk, ha rilasciato la 3.0.1 con il supporto stabile a identity 1.1. Il recupero tramite passkey, anche attraverso Nosskey, mantiene la pubkey originale, e il codice di provider, recupero e firma ora condivide un’unica implementazione (sorgente di recupero e provider dell’SDK). I pacchetti forwarder deprecati funzionano ancora, ma gli integratori dovrebbero passare ai punti di ingresso mantenuti.

Amethyst

Amethyst, il client Nostr per Android e desktop, ha rilasciato la versione 1.20.0 con sondaggi privati e altre funzionalità per i gruppi cifrati Marmot. Tra queste figurano voti privati sostituibili, emoji personalizzate cifrate, eliminazione dei messaggi da parte degli amministratori e segnalazioni, oltre a media legati all’epoch corrente del gruppo. Dopo la revisione l’autore non ha ripetuto i controlli di interoperabilità tra client e non ha testato manualmente la modifica su Android. Restano le chiavi di cache per rami concorrenti che condividono lo stesso numero di epoch, e le chiavi dei media cifrati possono sopravvivere ai messaggi effimeri. La sincronizzazione delle impostazioni memorizza sei gruppi di impostazioni dell’app come dati NIP-78 cifrati. Chiavi, signer, wallet, notifiche, deck e indicatori di lettura restano su ciascun dispositivo. La prima modifica alle impostazioni pubblica tutti e sei i gruppi. Un account in sola lettura mantiene le impostazioni in locale, e il comportamento su due dispositivi di firma non è stato verificato.

Le notifiche di sistema su desktop seguono il filtro Notifiche e ignorano i gift wrap esterni usa e getta e i DM silenziati. I tag d non attendibili oltre i 255 byte non causano più errori. Le ricerche per kind interrogano solo i relay connessi e i relay di ricerca dell’account, fino a 200 event ciascuno. Le app usano la gestione JSON Kite di Quartz per frame, event, filtri e messaggi NIP-46 e NIP-55, anche se la firma tramite questi due protocolli non è stata verificata sui dispositivi. Una successiva suddivisione delle librerie sposta in librerie condivise le regole dei protocolli Marmot e cordn di cui avrebbero bisogno altri client.

Il codice unito dopo la 1.20.0, non ancora incluso in una release, esegue il percorso di ricezione Marmot dell’app sulla libreria condivisa. Ogni messaggio decifrato viene salvato in modo idempotente. All’ingresso viene registrata una baseline, così la prima modifica dei membri mostra la propria riga. Un messaggio di kind 445 che arriva prima del suo commit viene trattenuto e riprodotto in seguito, e il recupero da parte degli amministratori esegue il commit delle uscite in attesa. amy cordn migrate export disabilita i comandi di sessione della vecchia installazione fino a un’importazione o al nuovo comando di ripresa. L’autore ha eseguito test amy in loopback e test delle librerie su checkout locali. Non ha però provato manualmente il percorso di ricezione dell’app in esecuzione né eseguito la suite di interoperabilità Marmot. Un aggiornamento incompatibile al formato proposto NIP-5D per i napplet legge l’hash del manifest di un napplet come un singolo artefatto /index.html, sostituendo il vecchio aggregato di percorsi, quindi i bundle legacy vanno ripubblicati. I domini NAP obbligatori non disponibili falliscono in modalità chiusa (fail closed), mentre quelli facoltativi restano assenti. Le icone ricevono controlli su hash e decoder, lo storage è partizionato per kind del manifest, artefatto e snapshot, e i blob delle risorse usano base64 canonico. Non sono stati eseguiti test manuali sui dispositivi, test tra client né pubblicazioni su relay reali.

I rifiuti in un signer esterno ora vengono gestiti nelle coroutine che non avevano protezioni, quindi non mandano più in crash l’app. Ora vengono visualizzati ebook, riviste e numeri di PressStr (kind 33953, 34609 e 39731). I PDF si aprono nel lettore integrato nell’app, mentre gli EPUB vengono passati al gestore di sistema. Le schede mostrano tipo e dimensione del file, non scaricano mai un PDF di grandi dimensioni solo per mostrarne l’anteprima e recuperano i numeri solo dall’autore della rivista. Per questa modifica l’autore non ha riportato test su dispositivi Android. Quando le anteprime avanzate sono disattivate, fatture e LNURL appaiono come etichette compatte copiabili senza pulsante Paga, e le schede delle fatture ora mostrano l’ora di scadenza. amy gift wrap ora assegna al seal e al wrap orari casuali distinti, ciascuno fino a due giorni nel passato. --no-backdate disattiva questo comportamento. Il percorso dei DM normali riceve la sua correzione separatamente in Quartz. Su desktop, ogni scheda video gestisce la propria riproduzione, quindi schede con lo stesso URL non si sottraggono più il video a vicenda. L’autore ha testato questa modifica su macOS, ma non con cache fredda. Una proposta di correzione dei link su Windows apre i link tramite rundll32 usando il percorso completo e ripiega su AWT. La causa principale non è stata riprodotta, quindi si tratta di una correzione probabile e non confermata.

Myco aggiunge lo storage cifrato per i napplet e avvisi di aggiornamento firmati

Myco, un host Android per napplet Nostr, ha distribuito la 0.12.0 e la 0.12.1. I napplet possono ora memorizzare tramite il runtime dati NIP-44 auto-cifrati, ma le app con autorizzazioni di lettura su relay, outbox o mesh possono vedere il testo in chiaro, quindi i dati non sono isolati per singola app. Chi in precedenza ha effettuato l’accesso con Amber deve accedere di nuovo per concedere i nuovi permessi di cifratura e decifratura. Gli avvisi di aggiornamento sono firmati da un editore fissato (pinned) e raggiungono solo i dispositivi che eseguono già la 0.12. Online, Myco può consultare Zapstore ogni giorno oltre a Circle, mentre la modalità solo mesh interroga soltanto Circle, sostituendo la pausa iniziale. Una rail Blossom locale scelta esplicitamente mantiene i file sul dispositivo senza alcun server, fino a 64 MiB per app al giorno. Anche i caricamenti non riusciti verso un server predefinito approvato conservano una copia locale. Nessuno dei due percorsi rimuove i metadati EXIF. Le release aggiungono inoltre il supporto ad Android TV e un selettore di file NAPFS in cui è l’utente a scegliere i file.

Release con tag

Monostr

Monostr, un client social Nostr per Android, ha rilasciato la 0.26.0, la sua versione più recente. I video lunghi fino a due minuti ora vengono compressi sul dispositivo, e i metadati di posizione vengono rimossi. Discover, ricerca e onboarding offrono liste di follow curate. Thread e notifiche ora mostrano le risposte dal Fediverso inviate come commenti NIP-22.

Le funzionalità della 0.25.0 restano. Quando manca il post genitore di una risposta, l’app cerca nei relay hint della risposta e nei relay dell’autore del post genitore, il che comporta brevi connessioni a relay esterni alla lista dell’utente. Anche i relay e le sottoscrizioni ai messaggi in tempo reale si riconnettono ogni volta che il dispositivo cambia rete.

Sidecar

Sidecar, un’estensione per browser e signer Nostr, ha rilasciato la 1.16.3. Il compositore e lo strumento di evidenziazione ora pubblicano sui relay dell’account stesso e contano solo i relay che confermano la ricezione dell’event, quindi rimandano a quei relay. Una conferma indica che il relay ha accettato l’event, non che lo conserverà. Il compositore espanso non ripiega più sui relay predefiniti nelle Impostazioni. Ogni relay ha una propria scadenza di 12 secondi. Solo una pubblicazione che fallisce su tutti i relay viene ritentata, una volta, su socket nuovi. Anche i risultati dei sondaggi interrogano quattro relay pubblici alla ricerca delle schede di voto. Una modifica unita dopo il tag aggiunge un ulteriore relay per intercettare le schede depositate al di fuori dei relay abituali. In un sondaggio reale, questo ha portato il conteggio da 21 a 23 voti. Si tratta del risultato di un solo sondaggio e non dice nulla sulla completezza a livello di rete. Il conteggio continua a consentire una scheda per persona e ignora quelle espresse dopo la chiusura del sondaggio. La precedente 1.16.1 limita le autorizzazioni di firma permanenti all’account e al sito che le hanno approvate, e a un singolo record indirizzabile quando l’event ha un tag d. Le autorizzazioni non coprono mai la cifratura né la decifratura. Profilo e liste di follow, mute e relay restano esclusi da qualsiasi autorizzazione. Sono escluse anche le cancellazioni, le zap request, l’AUTH dei relay e il controllo del wallet. Un’estensione bloccata chiede comunque il PIN. Revocare un’autorizzazione o dimenticare un sito ne cancella le autorizzazioni e le finestre di approvazione.

Una pull request aperta separata farebbe valere come zap il pagamento di un’offerta CLINK. È in coda nella sezione Unreleased del changelog e non implementa Debits. Il pannello dell’offerta passerebbe una zap request firmata di kind 9734 con payer_data, così il servizio potrebbe pubblicare una ricevuta di kind 9735. Le ricevute andrebbero prima al relay dell’offerta e poi ai relay del destinatario, deduplicati e limitati a sei. I relay del pagatore non vengono usati. Se un’offerta risponde con il codice 3 e un’offerta successiva decodificabile, Sidecar la seguirebbe una sola volta con una nuova richiesta e una nuova firma. Non scriverebbe mai nel profilo del destinatario. Alla data di chiusura la modifica non era ancora stata unita.

Roadbeacon

Roadbeacon, un client per segnalare posizioni che in precedenza si chiamava Roadstr ed è distinto dall’app indipendente Roadstr, ha rilasciato la 0.4.0 con il nuovo nome come nuovo pacchetto con un nuovo formato di event. Segnalazioni e voti ora usano i kind condivisi e interoperabili 1315 e 1316. Le coordinate usano frame interi ricostruibili esattamente, e la versione web convalida le firme. Il pacchetto si installa accanto a quello vecchio senza migrare i dati. Gli event precedenti restano validi sui relay, ma il nuovo client non è in grado di leggerli.

Jumble

Jumble, un client web Nostr, ha rilasciato la v26.10.1. Tra le novità figurano un editor di articoli long-form, parole silenziate che si sincronizzano tra dispositivi, notifiche di sistema e lettori per contenuti di gruppo e Git. Le modifiche ai post in sospeso e al layout descritte in un numero recente arrivano con questo rilascio.

Un commit unito dopo il rilascio aggiunge un’impostazione opzionale per le risposte NIP-22. È disattivata per impostazione predefinita e viene salvata come preferenza locale. Se è attiva, le risposte alle note di testo kind 1 vengono inviate come commenti kind 1111. I thread kind 1111 esistenti mantengono la propria radice, e i commenti su altri kind o su contenuti esterni restano kind 1111. Con l’impostazione disattivata, le risposte conservano il comportamento legacy kind 1. L’app avverte che alcuni client potrebbero non mostrare questi commenti.

nostr-idb

nostr-idb, una libreria che memorizza in cache gli event Nostr nell’IndexedDB del browser, ha rilasciato la 5.1.1 con correzioni alle query. Le ricerche per ID esatto ora funzionano per gli event sostituibili e indirizzabili. Ogni vincolo di filtro e ogni limite per filtro ora vengono applicati, anche alle scritture in sospeso e alla cronologia delle sottoscrizioni. Sono stati corretti la potatura della cache e la gestione degli event con timestamp zero. La dimensione della cache in memoria, maxMemoryEvents, ha come valore predefinito maxEvents, e impostarla a zero la disattiva.

Manent

Manent, un taccuino cifrato che si sincronizza tramite Nostr, ha rilasciato la 3.0.0 con le note vocali. Le registrazioni si sincronizzano cifrate come le altre note. Le trascrizioni vengono generate offline con Whisper, dopo che l’app ha scaricato un modello. Il rilascio include anche il recupero dell’autenticazione ai relay, descritto in precedenza come lavoro sul sorgente, che ora arriva tramite la versione 0.10.1 di NDK, la libreria Nostr Development Kit.

NoorNote

NoorNote, un client Nostr per desktop e web, ha rilasciato la 1.9.2 con una ricerca full-text locale al dispositivo su note e messaggi diretti, insieme a una modalità solo cache. La versione 1.9.3 rende di nuovo leggibili menu a tendina, menu e toast dopo una regressione dell’effetto vetro trasparente nella 1.9.2. Questi rilasci includono anche il filtro per i timestamp futuri, che prima esisteva solo nel sorgente. I profili che non riescono a caricarsi ora restano nello stato di caricamento finché il mancato caricamento non viene confermato.

Earthly

Earthly, un client Nostr per creare mappe, ha rilasciato la 0.1.22 con correzioni a relay e pagamenti. L’autenticazione ai relay è ora legata all’account attivo. Le sottoscrizioni e i conteggi recuperati distinguono un conteggio non disponibile da uno zero reale e conservano i conteggi tra una revisione della mappa e l’altra. I totali degli zap provengono da ricevute di zap reali. Prima di spendere, l’app attende che la sincronizzazione del wallet sia completata. I pagamenti reali tramite Nostr Wallet Connect e tramite mint non sono ancora stati testati (integrazione del rilascio).

Chama

Chama, un client di trading con escrow basato su event Nostr, ha rilasciato la 6.4.31, che verifica i backup del seed prima del finanziamento. Prima che la chiave di trading on-chain di questo dispositivo entri nei termini firmati CREATE, JOIN o di deposito, un relay deve restituire il backup firmato del seed che il dispositivo ha aperto. Se il backup manca, è stato ritirato o è in conflitto, lo scambio si blocca. I nuovi tentativi reinviano esattamente il backup salvato, senza un nuovo seed. La rilettura dimostra che il backup era disponibile in quel momento, non che sia persistente. Gli annunci con più unità ora usano ordini per quantità. La versione 6.4.30 conteggia gli ordini della vetrina solo quando i termini firmati dall’acquirente corrispondono all’annuncio firmato. Protegge inoltre dagli event tardivi di estranei negli scambi il cui CREATE firmato è datato 1 dicembre 2026 o successivo, mentre gli scambi precedenti mantengono il vecchio comportamento di scadenza (convalida della scadenza degli scambi e della vetrina).

Una pull request aperta, non ancora unita alla data limite delle nostre fonti, consentirebbe un solo backup del seed del wallet per identità. All’avvio, la prima creazione verrebbe serializzata con una coda interna alla pagina e con Web Locks, e lo stato dei relay verrebbe poi riletto. Browser separati si affidano soltanto a quella rilettura. Un lock distribuito e la riparazione dei backup in conflitto già esistenti restano al di fuori di questa modifica. Non abbiamo testato alcun percorso che coinvolga denaro.

Linky

Linky, un wallet Cashu che si sincronizza tramite Nostr, ha aggiunto trasferimenti on-chain sperimentali, attivabili tramite un flag, nella versione 26.10.7 e nella build Android 26.10.8. Un operatore umano configurato completa le richieste di invio e di ricezione entro 24 ore in cambio di una commissione, quindi i trasferimenti non sono né atomici né trustless. La modifica di coordinamento usa messaggi personalizzati dell’app Nostr, la configurazione dell’operatore tramite NIP-78 e un nuovo ambito di sincronizzazione dei link. Questo ambito sincronizza gli invii di ecash in sospeso dell’operatore, in modo che i suoi altri dispositivi non possano pagare, rimborsare o regolare due volte lo stesso invio. Una ricezione si completa solo quando il wallet dell’utente riceve l’importo Cashu corrispondente. Operatore e utente si trovano solo sui relay consigliati, non tramite le liste di relay NIP-65 né tramite le liste di inbox dei DM. Perdere tutti i relay in comune può quindi interrompere il coordinamento.

LaWallet

LaWallet, un servizio di wallet e di account basato su Nostr Wallet Connect, ha rilasciato la versione 2.9.0 e la beta Android 1.2.0. Entrambe aggiungono il recupero verso un nuovo login Nostr con l’aiuto di una carta NFC (flusso di recupero nativo). Per il recupero servono un tocco della carta recente e verificato crittograficamente e un codice QR di recupero monouso, valido per 15 minuti. Gli asset vengono spostati in un’unica transazione, i ruoli non vengono trasferiti, le vecchie autorizzazioni OAuth vengono revocate e il vecchio login resta vuoto. Il recupero tramite carta è attivo per impostazione predefinita. I titolari dell’account possono disattivarlo nelle impostazioni di sicurezza e revocare i codici ancora validi. Un wallet irraggiungibile ora mostra un saldo pari a zero, il che non significa che sia vuoto. Nelle build dotate di un endpoint di segnalazione, la beta Android forza l’attivazione della segnalazione degli errori tramite Sentry, anche se in precedenza l’utente l’aveva disattivata. Le build locali e quelle F-Droid non hanno alcun endpoint.

Nel sorgente unito dopo il tag, il callback della carta può restituire OK prima del regolamento NWC quando il saldo copre il pagamento, quindi i sistemi point-of-sale devono confermare in autonomia la propria fattura. Un limite di pagamento fisso sostituisce il limite basato sul saldo. Una pull request aperta, non ancora unita alla data limite delle nostre fonti, consentirebbe l’accesso con passkey compatibili provenienti da altre app, tramite un provider configurato o tramite il recupero Nosskey. L’account verrebbe confermato prima di emettere una sessione temporanea con scadenza (#386). Un provider può firmare senza importare la chiave privata, e l’importazione è una scelta separata che richiede conferma. Gli screenshot della pull request mostrano risposte demo simulate e non dimostrano un accesso cross-origin reale.

Un altro merge, anch’esso non ancora confermato in un rilascio, impedisce al callback NWC e dell’indirizzo Lightning di sostituire il wallet remoto di un utente sulla sola base di un errore make_invoice. Un controllo di liveness e del saldo può invece mantenere il wallet e restituire un 503. Il servizio memorizza inoltre i saldi e lo stato dei fondi protetti, e aggiunge un’opzione Restore. Le sue soglie e la cronologia precedente, che non è nota, limitano ciò che può proteggere. Non garantisce quindi che tutti i fondi siano al sicuro. Non viene dichiarato alcun deployment né alcun account utente ripristinato.

KithMoot

KithMoot, un’app basata su Nostr per chat nelle stanze e chiamate, ora funziona senza i servizi pubblici del suo editore. Tra il 21 e il 23 ottobre l’editore ha dismesso i codici pubblici delle riunioni, il servizio TURN condiviso, il caricamento dei file e la lettura dei file archiviati. I link di invito sostituiscono i codici delle riunioni. Per i file pubblici viene usato Yakihonne come impostazione predefinita, con un avviso al primo invio, ma gli utenti possono scegliere un proprio server. Le chiamate tentano ancora per prima una connessione diretta. Hide IP, invece, richiede un server TURN funzionante e non ripiega mai sulla connessione diretta. Nella versione desktop 0.1.102 e in quella Android 0.6.106, lo STUN pubblico di Cloudflare sostituisce quello dell’editore, e gli utenti possono impostarne uno proprio. Le copie di backup servite sono state eliminate, mentre le copie cifrate offline restano. Desktop 0.1.109 e Android 0.6.121 bloccano la chat quando le credenziali del dispositivo scadono, ma conservano le bozze. Inoltre leggono il nome del profilo dell’utente stesso separatamente dalle ricerche opzionali nella directory. Il motore di chiamata ordinario non è passato all’anteprima sperimentale del realtime SDK, e il candidato per i gruppi MLS resta disattivato per impostazione predefinita.

Desktop 0.1.110 aggiunge visualizzatori di allegati in sandbox per immagini, audio, video e PDF, su desktop e sul web. Su desktop vengono eseguiti in un renderer Electron dedicato e non persistente, senza accesso a Node, senza archiviazione dell’applicazione e senza accesso alla rete esterna. Lo streaming ha limiti definiti. I visualizzatori vengono ripuliti quando vengono chiusi o quando un messaggio viene ritirato. L’esecuzione WebKit della pull request e un’ulteriore esecuzione sulla versione pacchettizzata con un SVG ostile si sono bloccate e non vengono dichiarate come verificate. Nulla di tutto ciò costituisce una certificazione di sicurezza. La build macOS è notarizzata, mentre quella Windows resta un’anteprima non firmata.

Un merge successivo, che non risulta incluso nella 0.1.110, rinnova le credenziali scadute del dispositivo in base all’ora effettiva dell’orologio dopo la sospensione e prima dell’invio, conservando la bozza mentre il signer risponde. Nasce dal caso di un tester le cui credenziali sono scadute durante la notte su un portatile in sospensione. Una richiesta al signer che non riceve mai risposta tiene comunque in sospeso il rinnovo. Su Android resta inoltre una lacuna separata, non ancora risolta, nel rinnovo. Una pull request aperta, non ancora unita alla data limite delle nostre fonti, metterebbe in pausa la funzione «Help other people connect». Secondo l’autore, l’app accetta una coppia peer-assist senza che questa trasporti i media. Ciò può impedire il ripiego su un forwarder o su TURN e lasciare una chiamata senza audio. Il valore predefinito della libreria resterebbe invariato.

Marmot TS

marmot-ts, una libreria TypeScript per il protocollo di messaggistica di gruppo cifrata Marmot, ha pubblicato la v0.8.0 e la v0.9.0, con modifiche incompatibili. Encrypted media V2 aggiunge il binding alla sorgente e decifra i media ritardati dopo un riavvio. I descrittori di upload Blossom, le destinazioni e il testo cifrato vengono convalidati prima della firma. Per i gruppi persistiti il backfill avviene a pagine, con nuovi tentativi in caso di commit incerti. Le app devono ora fornire store durevoli di ingest e di rewind, con adapter che rifiutano le letture non riuscite o scadute. I gruppi legacy V1 vanno ricreati, perché gli helper V1 restano disponibili solo per la cronologia.

Il sorgente unito in seguito aggiunge un AbortSignal opzionale ai watcher di key-package, inviti e cronologia. I relativi listener vengono ripuliti subito in caso di return, throw o dispose, anche se una lettura dallo storage è ancora in corso. Le modifiche che arrivano mentre un consumer è in pausa vengono trattenute e unite in un unico aggiornamento. La lettura sottostante dal backend prosegue anche dopo l’annullamento. Le query che falliscono producono ancora un reject, e la modifica non certifica l’interoperabilità a runtime.

Client di posta Nostr

nostr-mail-client, un client di posta basato su Nostr, ha rilasciato la v0.19.0. Introduce un unico flusso di accesso per bunker, nsec e ncryptsec, compresa l’approvazione dell’auth_url di un signer remoto. Il client ora segue le modifiche alle liste di relay DM, inbox, outbox e privati senza richiedere un nuovo login. Durante la sincronizzazione elimina le notifiche di posta duplicate, e sincronizza tra i dispositivi le firme email in forma cifrata. Gli allegati email che superano il limite di 25 MB vengono scartati con un avviso. Un indirizzo solo Nostr non può ricevere risposte inviate via email.

CLI di conformità di Napplet

napplet/web, l’insieme di pacchetti e strumenti web per i napplet (app web distribuite come event Nostr firmati), ora include il lavoro di verifica descritto nel numero scorso nel pacchetto versionato @napplet/conformance-cli 0.4.0. Prima di un’esecuzione headless, la CLI verifica l’ID dell’event del manifest, la firma e l’hash esatto dell’HTML grezzo. Segnala inoltre gli errori di binding del runtime, di namespace e di installazione separatamente dagli errori dei napplet. Il fallback incorporato copre solo RESOURCE e GAMEPAD, quindi gli host personalizzati devono passare esplicitamente gli input di sorgente e di snapshot.

Il comando deploy di Napplet ora prepara per impostazione predefinita le schede per Zapstore: cattura screenshot di ogni build selezionata e prepara un event kind 32267 Software Application. --no-screenshot e --no-zapstore disattivano questi passaggi. Preparare i metadati non significa pubblicare un rilascio, e la modifica non aggiunge alcun rilascio di pacchetto né alcun event di asset.

napplet-soy

napplet-soy, un workspace per creare e pubblicare napplet, ha taggato il suo strumento da riga di comando soyli come v0.31.2 e v0.31.3, che non costituiscono un deployment di Studio. Una volta confermata la consegna tramite Git, la pubblicazione contrassegna come unite le proposte di collaborazione Git (NIP-34) incluse, dopo aver verificato l’ascendenza esatta e il target insieme alla revisione corrente, e alla ripresa riutilizza gli stati prefirmati. Le revisioni più recenti delle proposte restano aperte. Inoltre, un tag che contiene un commit non viene considerato prova che il branch di destinazione lo abbia unito. Il codice sorgente alla base di questi tag aggiunge anche una vista iniziale del wallet Cashu (NIP-60) in un workspace Manage unificato e mantiene attive le napplet in esecuzione durante i cambi di scheda. Il precedente updater v0.31.1 tiene traccia dell’ID stabile del repository GitHub, così le installazioni conservano account e progetti nel passaggio a Soytec. Le installazioni con l’updater più vecchio devono eseguire l’installer una volta.

Il wallet Cashu NIP-60 riscatta i nutzap NIP-61 e, prima di eseguirli, salva gli output di mint preparati e gli aggiornamenti firmati per i relay, in modo che le richieste incerte possano essere recuperate senza ripetere un pagamento. I wallet restano isolati per account e le schede del browser non possono spendere contemporaneamente. Tuttavia i test hanno usato mint fittizi, e l’interoperabilità con denaro reale non è verificata. Le pagine dei contributi ora supportano zap diretti all’autore, che pagano l’autore firmatario della release o della proposta scelta.

Il tag soyli v0.31.4 riporta la cronologia dei contributi dell’autore e gli zap, oltre a modifiche alla prontezza NIP-5D, all’audio e ai test. Le chiamate di dominio non attendono più che la shell segnali di essere pronta. Un host condiviso coordina l’audio di proprietà delle napplet tramite NAPMEDIA senza allentare l’isolamento degli iframe. Nemmeno questo tag è un deployment di Studio. Dei controlli configurati, cinque sono stati superati e cinque sono stati saltati. La piena conformità resta non dimostrata, e le app riparate attendono di essere ripubblicate.

Pakstr

Pakstr, uno strumento da riga di comando che compila app Android e le pubblica su Nostr, ha taggato la v0.29.1. Prima della pubblicazione, legge il certificato del firmatario che un APK dichiara nel proprio blocco di firma v2 o v3 e ne confronta lo SHA-256 con il sidecar atteso e con la prova d’identità (revisione della pubblicazione). Gli APK non firmati, malformati o con più certificati vengono rifiutati. I sidecar obsoleti vengono rimossi alla ricompilazione, e una nsec di pubblicazione non valida provoca un errore prima della build. Il parser non verifica la firma dell’APK in sé, compito lasciato ad Android e ad apksigner: intercetta quindi build obsolete, non firmate o con il certificato sbagliato, ma non può dimostrare che una build non sia contraffatta. ZIP64, firmatari multipli e rotazione delle chiavi non sono supportati.

MDK

MDK, l’SDK e runtime per i gruppi cifrati Marmot, ha rilasciato la v0.14.0 stabile. Include l’handoff e l’archiviazione dei file multimediali, il recupero ordinato dei messaggi arrivati offline, la conservazione delle liste di follow e il rekeying della chiave SQLCipher raw. MLS e il formato wire restano invariati. La guida al rilascio 0.14.0 e la guida all’integrazione 0.14.0 richiedono che le app includano un insieme coerente di binding, libreria nativa e header, che MarmotKit 0.14.0 impacchetta per Apple e Android. Sulle piattaforme Apple il binario è un XCFramework statico raw. Le app lo abbinano quindi al binding Swift corrispondente e copiano la sua risorsa PrivacyInfo.xcprivacy nel prodotto wrapper a cui la assegnano. Superare i controlli sull’archivio della release non dimostra che un’esportazione per l’App Store andrà a buon fine. Database e archiviazione migrano in un’unica direzione, con il rekeying di ogni pagina eseguito una sola volta. I downgrade restano non supportati. I media dell’account e i dati di handoff andrebbero esclusi dai backup. L’agente WN resta in prerelease, e i crate non sono su crates.io. Permangono limiti noti: la cronologia che arriva con più di cinque epoch di ritardo diventa indecifrabile senza alcun avviso. I media persi in transito durante un avanzamento di epoch non sono stati corretti, e resta inoltre un problema di compatibilità nell’ordinamento del group context.

L’ascendenza del tag mostra che il tag stabile contiene anche cinque modifiche relative a sincronizzazione e media. I refresh delle sottoscrizioni di gruppo reimpacchettano solo le famiglie di batch REQ modificate. Una famiglia fallita mantiene le proprie route attive per la sincronizzazione successiva, mentre il commit parziale segnala comunque una sincronizzazione fallita. Gli invii e le modifiche ai gruppi continuano a entrare nella coda durevole quando un refresh pre-invio fallisce, anche se il completamento può restare CompletionUnknown. La REQ di un relay irraggiungibile resta in sospeso con lo stesso ID fino alla riconnessione, quindi una copertura degradata non equivale a una cronologia completa. L’approvazione della riparazione in fase di onboarding attende ogni sorgente di discovery e restituisce RetryableFailure quando una sorgente dichiarata va in timeout. La conservazione dei media per account, attivabile su richiesta, va da Keep forever fino a 30 giorni. Ripulisce i media in base all’ora di ricezione o all’ultimo nuovo download esplicito, non all’ultima visualizzazione, e non cancella la cronologia dei messaggi. Gli host devono gestire il nuovo valore FFI CleanedBySetting.

Dopo il tag, il codice sorgente unito ha proseguito il lavoro sul supporto multi-dispositivo e sulle notifiche push, lavoro che nessuna release include ancora. Le richieste di cronologia successive all’adesione persistono attraverso commit e riavvii, colmando un vuoto tra il Welcome e i messaggi live. Grazie al conteggio dei membri per account non compaiono più falsi avvisi su una persona quando un suo secondo dispositivo entra o esce. Inoltre la gestione dei Welcome ignora le consegne destinate a dispositivi fratelli senza far fallire l’adesione né consumare una chiave. Per le notifiche push, MDK diffonde via gossip record e tombstone firmati dal proprietario dopo i commit su un nuovo storage per il gossip push. Inoltre ricondivide i token dopo l’aggiunta di membri e notifica tutti i dispositivi di un destinatario, anche se i dispositivi del mittente stesso continuano a non ricevere alcuna notifica. Un padding casuale nuovo per ogni trigger impedisce alla deduplicazione di sopprimere i risvegli. La pubblicazione dei KeyPackage adotta le liste di relay dell’account stesso. Se una lista è incompleta o non contiene alcun relay utilizzabile, la pubblicazione fallisce e la lista memorizzata viene preservata. Gli stati tipizzati dei media con epoch obsoleta o in sospeso indicano alle app se caricare di nuovo oppure sincronizzare e reinviare. Infine, le modifiche allo stato dei trasferimenti arrivano immediatamente, con l’avanzamento in byte raggruppato.

Il codice sorgente più recente per gli account con più dispositivi rappresenta un passo verso una release successiva, non una 0.15 stabile. Tre nightly del 28 ottobre, etichettate come destinate solo ai test, sono fissate al commit b8d0a49, che precede merge successivi, quindi i loro asset non contengono tutto quel codice. MDK seleziona KeyPackage compatibili per ciascun dispositivo per un massimo di 20 dispositivi recenti per account, e la disconnessione ritira solo lo slot di pubblicazione di questo dispositivo. I pacchetti nuovi durano 30 giorni più un’ora e vengono rinnovati da sei a sette giorni dopo la pubblicazione. La discovery cerca ogni dispositivo, ma i guasti dei relay possono farne saltare alcuni. Invitare di nuovo può aiutare, senza alcuna garanzia di recupero automatico. Controlli autenticati delle capability per singola leaf sostituiscono la cache per account. I nuovi gruppi richiedono il componente account-devices 0x800d quando tutti i fondatori lo supportano, e i dispositivi aggiornati ora lo annunciano. Tali gruppi rifiutano i dispositivi più vecchi che ne sono privi, mentre i gruppi esistenti restano invariati. Quando il requisito è attivo, MDK rifiuta i dati di componente, le leaf non supportate, più di 20 leaf per account e i tentativi di eliminare il requisito, lasciando invariati i gruppi legacy e quelli senza il requisito. Separatamente, rifiuta i dati iniziali forniti dall’host per i componenti app il cui schema non prevede dati, prima che venga creato qualsiasi gruppo, Welcome o event.

Nei gruppi 0x800d il motore acquisisce l’autorità di aggiungere e rimuovere dispositivi del proprio account, con una classificazione dei commit che tiene conto dello stato del parent. Questa classificazione distingue i commit di self-update, di self-remove, dello stesso account e degli admin. Il privilegio dello stesso account richiede proposte by-value. Una gestione dei Welcome coerente accetta Welcome dello stesso account solo in quei gruppi e solo dopo i controlli sullo stato dei componenti e sulla firma. Gli altri gruppi richiedono ancora un admin attivo. Gli intenti di invio per aggiungere e rimuovere dispositivi del proprio account ottengono un turno equo nello scheduler, ma le API delle app non espongono ancora intenti di invio dello stesso account. La rimozione della leaf di un dispositivo ora determina la sua appartenenza locale, quindi la presenza di un dispositivo fratello non preserva più le azioni da membro di un dispositivo rimosso.

Il gossip push aggiunge annunci di kind 447 accodati in modo durevole, che trasportano prefissi di digest a 8 byte di record e tombstone. Vengono inviati all’adesione, quando un record cambia e con una cadenza di messaggi di sette giorni. I peer riparano i record mancanti firmati dal proprietario tramite risposte ordinate per priorità e scaglionate, con soppressione dei duplicati e un limite di 24 ore per leaf. Nel recupero, cut e cancel non generano più perdite nuove inesistenti, e dopo 24 tentativi senza progressi un obbligo viene parcheggiato dietro un avviso di cronologia incompleta. Il ledger di copertura funziona solo come registratore ombra. Una scansione suddivisa in intervalli di tempo riprende gli intervalli partendo dai più vecchi, ma non esiste ancora uno scheduler di produzione. I file di audit opzionali scadono 30 giorni dopo l’ultima scrittura, con una pulizia all’avvio e una ogni ora. L’eliminazione può avvenire con un giorno di ritardo. Il log di sicurezza separato sulle rivelazioni delle chiavi è escluso da questa scadenza.

Un crate di pairing utilizza X25519 effimero, un commitment, un confronto di sette emoji che l’utente verifica su entrambi gli schermi e conferme HMAC che si concludono con un ConfirmedLink. Il suo adattatore wire copre solo il trasporto ed è disattivato per impostazione predefinita in attesa di una specifica. L’interfaccia utente e i lavori successivi su Welcome e collegamento di gruppo non sono completati, e l’interoperabilità di questa implementazione resta non verificata. Il codice sorgente del device-roster 0x800e applica aggiornamenti diff a un gruppo nascosto con un solo account. Per annunciare 0x800e, però, serve un override della policy di test, quindi le build di produzione non possono ancora creare un gruppo di dispositivi né unirsi a uno.

Altre proposte di MDK restano aperte. Una smetterebbe di trattare un completamento NIP-67 come prova di copertura completa, perché la scansione non pianificata non offre alcuna garanzia di completezza. Altre aggiungerebbero il replay dei checkpoint, il rejoin automatico e l’attivazione di 0x800d nei gruppi esistenti. Da una nuova verifica dello stato, tre precedenti proposte di API native risultano ancora aperte. Il recupero degli allegati storici esaminerebbe gli slot di origine e verificherebbe digest autenticato e scadenza, prima di scrivere i byte verificati in un file privato con lease. La timeline resterebbe così priva di accessi alla rete. Una copia consegnata è uno snapshot che non può essere revocato. Gli handle di selezione delle chat estesi all’intero filtro coprirebbero ogni chat che corrisponde a un filtro, anche oltre la pagina caricata, escludendo però le chat arrivate in seguito. Infine, la selezione degli admin fondatori per la creazione di gruppi con wn-agent sceglierebbe gli admin fondatori invitati e rifiuterebbe i non membri prima del caricamento.

nosfry

nosfry, un relay Nostr scritto in Rust, ha rilasciato nosfry v0.2.0 per le sue edizioni nativa e Workers/SQL. Include funzionalità che nella v0.1 non erano state rilasciate: l’eliminazione NIP-09, la scadenza NIP-40, AUTH NIP-42 con gli event protetti NIP-70, COUNT NIP-45, la sincronizzazione Negentropy NIP-77, le richieste di vanish NIP-62 e l’API di amministrazione NIP-86. Aggiunge inoltre sottoscrizioni limitate con un budget in uscita e una policy di scrittura, e descrive permessage-deflate come attivo per impostazione predefinita. Le sue affermazioni su prestazioni e conformità non sono state riprodotte in modo indipendente. Il progetto non afferma di interoperare con ogni implementazione.

Il 25 ottobre, dopo il tag 0.3, sono state unite quattro modifiche di hardening, che non sono presenti in alcun binario rilasciato. I bucket di connessione e di rate del Worker aggregano gli indirizzi IPv6 per /64, mentre la blocklist IP di NIP-86 continua a confrontare indirizzi esatti (#78). Durante la raccolta, le scansioni NEG-OPEN addebitano il proprio consumo al budget globale di memoria per la sincronizzazione in blocchi da 1024 record (#73). I gruppi di event a pari merito con lo stesso timestamp mantengono un heap limitato dal limite della query (#72). Gli snapshot di moderazione NIP-86 si applicano alle letture dai dati memorizzati e alla consegna live così come sono stati acquisiti al momento della richiesta, quindi una richiesta aperta non recepisce istantaneamente i nuovi ban (#68).

Un ulteriore merge, anch’esso non rilasciato, limita il writer con un budget di 64 MiB in byte e smaltisce gli arretrati di pubblicazione in transazioni più grandi, ciascuna limitata dal lavoro svolto, mantenendo la sincronizzazione LMDB durevole. I dati di benchmark del progetto provengono dalle sue varianti di probe, non da nostre misurazioni.

nostream

nostream, un relay Nostr scritto in TypeScript, ha rilasciato nostream 3.7.0 e nostream 3.8.0. La versione 3.7.0 porta in una release le operazioni di amministrazione, i log di audit, i webhook firmati e le metriche che in precedenza avevamo segnalato come presenti solo nel codice sorgente. Aggiunge un ciclo di vita opzionale (opt-in) per le scritture a pagamento e corregge il parsing degli orari ISO e la scadenza per LNbits 1 e versioni successive. Il mirroring statico è stato rimosso: le relative impostazioni vengono ora ignorate con un avviso, a favore della sincronizzazione NIP-77. La pubblicazione dell’immagine container della 3.7.0 non è riuscita perché il suo tag Docker conteneva un @ non consentito, e la 3.8.0 corregge i tag e aggiunge la riesecuzione delle build di immagini fallite. Con la 3.8.0 arrivano inoltre nell’API e nella console di amministrazione liste di pubkey e di kind, oltre a controlli sugli IP e per il bypass del rate limit, con statistiche sui publisher più attivi, sugli IP e sulle attivazioni del rate limit; la versione corregge anche una collisione di chiavi Redis che si verificava cambiando strategia di rate limit o eseguendo un aggiornamento. Il solo codice sorgente non conferma che le immagini ora vengano pubblicate, e non si dichiara alcun sistema di fatturazione effettivamente in produzione.

Una riscrittura separata in Rust, sul branch rewrite/main, ha integrato in 740ef69 il suo primo nucleo di protocollo (wire core) in grado di rispondere a un client reale, e al commit 2b2287f il registro delle strategie implementa i 14 rami di strategia rimanenti. Questo prototipo, non predefinito, resta separato da main in TypeScript e dalle release stabili 3.x, e la revisione e i risultati della CI provengono dall’autore. La gestione di NIP-43 e NIP-56 resta disattivata per impostazione predefinita. Una richiesta di vanish può ancora perdere la corsa contro una pubblicazione concorrente, quindi il vanish non è una garanzia di privacy. Resta valida la richiesta dell’autore di una revisione manuale del codice di accesso e di identità.

swift-nostr

swift-nostr, un SDK Nostr per Swift, ha pubblicato la 0.9.0 il 27 ottobre. La release aggiunge chiavi, ID degli event, URL, timestamp, coordinate e ID di sottoscrizione tipizzati, EventTemplate che qualsiasi signer locale o remoto può firmare, errori tipizzati, sottoscrizioni gestite dal pool e l’instradamento RelayRoute tramite il pool, relay specifici o l’outbox NIP-65. Event.verify ora lancia un errore in caso di firma non valida, per cui il passaggio dalla 0.8 richiede modifiche al codice sorgente. La precedente 0.8.0 era una release di hardening: secondo le sue note, verifica gli event sostituibili, i mittenti dei gift wrap e le risposte NIP-46 e NWC, deduplica le risposte provenienti da più relay e aggiunge la cifratura NIP-44 gestita dal signer o a chiave condivisa, con controlli più rigorosi sugli zap come modifica incompatibile (breaking change). Si tratta di affermazioni dell’autore, non di un audit.

Le correzioni successive alla 0.8 di cui avevamo già parlato sono ora incluse nella 0.9.0. I signer rifiutano gli event la cui chiave pubblica è diversa dalla propria, e l’annullamento di una sottoscrizione non apre più un relay disconnesso per inviare CLOSE. La chiamata di invio di base lancia notConnected e la sottoscrizione stabilisce la connessione in modo esplicito, anche se i trasporti NWC e NIP-46 riconnettono ancora un relay caduto per una nuova richiesta. Le chiamate NWC e ai signer remoti ottengono errori tipizzati e annullamento immediato, sebbene una richiesta già inviata possa comunque essere eseguita. Gli stream NWC di notifiche e di challenge di autenticazione terminano quando i relay chiudono, le attese di connessione falliscono non appena tutti gli stream dei relay sono terminati e le query sui tag dei filtri vengono memorizzate una sola volta, con una sola chiave JSON per tag. Un WalletConnectRequest generico supporta metodi NIP-47 personalizzati a risposta singola con i consueti controlli su result_type ed errori, mentre multi_pay resta separato. Un RemoteSignerMethod estensibile richiama metodi NIP-46 oltre a quelli integrati e restituisce la stringa del risultato; in entrambi i casi il wallet o il signer deve supportare il metodo. EventTemplate con signer.sign consente ai signer NIP-46 remoti di usare helper, come le richieste di zap, che un tempo richiedevano un EventSigner locale, con modifiche correlate a diversi modelli di dati e ai builder NIP-29 e NIP-98. Questa modifica cambia l’API, non il formato di trasmissione (wire format).

Il codice integrato dopo il tag 0.9.0 non fa parte di quella release. Quando un chiamante annulla un invio, ora i relay funzionanti vengono mantenuti, e i tipi di apertura e di risultato dei DM sono più semplici, con l’autore del rumor vincolato al signer. FileAttachment unifica i metadati dei file cifrati. Un’unica coppia setSigner e removeSigner impedisce che un’impostazione remota obsoleta annulli il logout; removeSigner interrompe le risposte AUTH ma non revoca le richieste remote già inviate. Le impostazioni di riconnessione e di deduplicazione ricevono tipi di configurazione propri.

haps

haps, un installer per software firmato con chiavi Nostr, ha rilasciato haps v0.1.22. La versione si basa su haps v0.1.18, che eseguiva le build da sorgente su Linux e macOS in una home directory privata e in un checkout scrivibile, con l’accesso alla rete disattivato per impostazione predefinita. Le opzioni esplicite allow-build-network e allow-host-build possono modificare questo comportamento. Su Windows, le build da sorgente richiedono host-build. Le app installate restano fuori dalla sandbox. haps v0.1.19 ha introdotto un’unica conferma di audit e installazione che lega il sorgente e la ricetta di build fissati all’hash del payload compilato, così un binario del publisher corrispondente può essere installato secondo la policy di quella build revisionata. Riutilizzare una revisione attendibile non equivale a un ulteriore audit indipendente. Le installazioni da cataloghi firmati immutabili richiedono comunque un audit, e gli avvisi pubblicati necessitano di un consenso separato, con No come risposta predefinita. La versione 0.1.22 aggiunge ricerche con limiti e controlli del publisher sulla completezza del sorgente. Le ricerche ora condividono scadenze brevi, con il client che avvia le query dopo la connessione del primo relay, e le ricerche di snapshot restituiscono i risultati verificati trovati entro un unico budget di 3 secondi. Prima di modificare qualsiasi ref del sorgente, la pubblicazione si rifiuta di procedere se non trova un helper git incluso e qualificato, un helper installato separatamente che corrisponda al binario companion fissato, oppure un helper che dichiari complete-blob-dag-v1. Restano la copertura di base della revisione delle dipendenze, le protezioni su symlink e dimensioni e i tentativi ripetuti limitati, il che non costituisce un nuovo audit indipendente. Una sola installazione a freddo riuscita non dimostra che i timeout intermittenti nei trasferimenti siano risolti, e i bundle di helper fissati dipendono ancora dalla toolchain dell’host.

Swarm protegge la sua API di amministrazione con l’autenticazione NIP-98

Swarm, un server di pubblicazione e amministrazione collegato a Nostr, ha rilasciato la v0.2.0 con l’autenticazione HTTP NIP-98 per la sua API di amministrazione, affiancata al cookie della dashboard già esistente. Il server verifica la firma dell’event di kind 27235, una finestra temporale che va da cinque minuti nel passato a un minuto nel futuro, il metodo HTTP, il percorso e la query, la pubkey fissata dell’operatore e un hash opzionale del payload. Accettare un host inoltrato presuppone la presenza di un proxy attendibile a monte. L’endpoint /environment, in precedenza pubblico, ora richiede l’autenticazione di amministratore.

Un merge successivo, non confermato in una release, aggiunge il crossposting opzionale su X per le note di kind 1 dei membri del team collegati. Le note programmate e quelle in arrivo via WebSocket seguono lo stesso percorso. Le risposte con tag e vengono saltate, non viene recuperato nulla a ritroso e i duplicati vengono rimossi in base all’ID dell’event. Sul lato CMS si usa l’autenticazione NIP-98. La pubblicazione dipende da OAuth locale o da un servizio delegato attendibile, quindi non è né decentralizzata né trustless. La pubblicazione sul servizio X di produzione non è stata testata.

fips2go attiva i collegamenti diretti ai domini mesh verificati

fips2go, un client mesh per Android che individua peer e rivendicazioni di dominio tramite annunci Nostr, ha rilasciato le versioni dalla 0.9.6 alla 0.10.0. La versione 0.10 attiva per impostazione predefinita i collegamenti diretti verso i server di un massimo di due domini verificati più di recente, considerando solo i domini fissati tramite DNSSEC o più resolver. Questi collegamenti espongono a quei server l’indirizzo IP pubblico del telefono e i suoi orari di presenza online, e rivelano ai relay pubblici la scelta del server, ma gli utenti possono disattivarli. Un record TXT già fissato per un server e una porta precisi ora viene risolto senza una nuova rivendicazione Nostr, mentre server nuovi, porte spostate e record privi di porta restano ancora in attesa. Quando un cambio di rete richiede nuove route VPN ma la configurazione è invariata, l’app sostituisce solo il tunnel e mantiene nodo, collegamenti e sessioni. Le modifiche all’hotspot, le altre modifiche di configurazione e il fallback in caso di errore ricostruiscono ancora il nodo.

fips-pub-domains risponde alle ricerche con pin prima di recuperare le rivendicazioni

fips-pub-domains, che risolve i binding firmati con Nostr tra domini pubblici e indirizzi mesh, ha rilasciato la 0.2.9 e la 0.2.10. Un record TXT fissato per un server e una porta precisi può ora rispondere prima che termini il recupero in background della rivendicazione, secondo la stessa policy di pin, mentre un server o una porta nuovi attendono ancora una rivendicazione. All’avvio su desktop e dopo i cambi di rete, il resolver esegue il warm-up di un massimo di 16 server fissati, rivelando la propria presenza online a questi ultimi e ai nodi di routing. Durante il primo backoff di 20 secondi riprova ogni tre secondi e termina in anticipo non appena un server risponde.

Due modifiche integrate dopo questi tag non sono state rilasciate. La prima aggiunge un ruolo ServiceClaim fips-ca senza porta e con una propria catena DNSSEC e una propria attestazione, separato da fips-dns, senza introdurre una nuova PKI né modificare la policy di binding DNS. La seconda aggiunge i comandi CLI verify e zone, che leggono i file di pin senza scriverli. In questo codice, un’attestazione contiene solo il proprio witness precedente e le voci degli altri ruoli vengono verificate di nuovo. Un’opzione require-previous rifiuta i dati mancanti, ma non è in grado di distinguere un’interruzione del servizio da un record inesistente.

Codr

Codr v0.8.0, un bridge per controllare sessioni di programmazione su desktop tramite chat cifrate di White Noise, aggiunge un aggiornamento del worker che viene confermato nella chat e deve avvenire entro dieci minuti. L’aggiornamento recupera i record ngit da un maintainer fissato e byte Blossom verificati tramite checksum, senza fallback su GitHub. Rifiuta i cambi di connettore o di coorte di storage e, se l’avvio fallisce, ripristina il vecchio eseguibile. Finora l’aggiornamento è stato eseguito solo su fixture di test. File e contenuti multimediali ora raggiungono una sessione occupata senza interromperla, fino a 25 MiB e quattro allegati. La trascrizione opzionale con Gemini invia a Google i messaggi vocali decifrati ed è disattivata per impostazione predefinita. Le release dalla 0.4 alla 0.7 hanno portato il testo inviato dal telefono nelle sessioni occupate, aggiunto /cancel e i menu di progetto, agente e modello, e sono passate a MDK 0.14. La migrazione dalla 0.13 funziona in una sola direzione e richiede un backup e un’approvazione.

Una chat di controllo opzionale riservata al proprietario (control_chat=true, disattivata per impostazione predefinita) crea il proprio gruppo al successivo avvio del worker. /new avvia una sessione di progetto prima che venga collegata qualsiasi chat. Se l’esito della creazione è incerto, non viene ritentata automaticamente.

Una pull request aperta, non ancora integrata alla data limite delle nostre fonti, permetterebbe alla creazione del gruppo per una nuova sessione di programmazione di trattare come vuota una trascrizione non ancora scritta. Le trascrizioni non valide o ambigue verrebbero comunque rifiutate. Ciò ripristinerebbe gli inviti sul telefono per le nuove sessioni /new prima del primo prompt e non cambierebbe il modo in cui le sessioni vengono autorizzate.

nostr-media

nostr-media 0.17, un plugin WordPress per ospitare contenuti multimediali Nostr, rafforza il mirroring Blossom. Ora verifica l’autorizzazione firmata dell’hash di kind 24242 prima di recuperare un URL di mirror, rifiutando le richieste non autorizzate senza scaricare nulla. I recuperi usano l’API HTTP sicura di WordPress, che consente solo host HTTP(S) pubblici e convalida i redirect, con un limite di 20 secondi, tre redirect e 128 MiB; dei byte scaricati viene comunque calcolato e verificato l’hash. Gli header Authorization, X-SHA-256 e X-Content-Type vengono confrontati senza distinzione tra maiuscole e minuscole. La protezione contro la server-side request forgery è solida solo quanto l’API sicura di WordPress.

NosTube

NosTube, un sito di video basato su Nostr, ha rilasciato server 0.1.25 e desktop 0.2.51 per revocare la fiducia a un’autorità di certificazione compromessa. Il relay Rust del server non la considera più attendibile per le connessioni WebSocket o HTTPS, e le build delle immagini ora richiedono un bundle fisso di CA di sistema Debian. La release desktop applica la stessa mitigazione al proprio livello TLS e al sidecar almond. Queste affermazioni sulla sicurezza provengono dalle note di rilascio. Le note della successiva versione server 0.1.27 dicono di NON USARE (DO NOT USE) quell’immagine perché include una libbrotli1 obsoleta, e rimandano alla 0.1.28, di cui non abbiamo confermato il rilascio.

bitchat

bitchat, un messenger che funziona su mesh Bluetooth e Nostr, ha rilasciato la 1.8.0 con interventi sulle prestazioni delle chat di posizione Nostr (geochat) e timestamp limitati sui rumor dei DM. L’app ora riconosce i messaggi dell’utente stesso tramite l’ID del mittente, non tramite il nickname (correzione dell’identità del mittente). I gruppi privati fissano il proprio creatore, e l’ID del peer mesh resta escluso dai DM geohash. I dati sulle prestazioni sono del progetto stesso e non sono stati riprodotti da noi.

Una pull request aperta, non ancora unita alla data di chiusura delle nostre fonti, manterrebbe connessa la chat geografica durante i disservizi dei relay instradando il traffico sui cinque relay più vicini più cinque backup condivisi, con un limite di dieci connessioni per percorso (#1822). I messaggi verrebbero messi in coda prima del caricamento della directory dei relay, mentre sottoscrizioni e scritture in sospeso migrerebbero senza cambio di identità. La validazione è stata svolta dall’autore stesso, e la modifica complementare per Android è una pull request separata.

Un’altra pull request aperta, anch’essa non unita, aggiungerebbe video in diretta sulla mesh Bluetooth di iOS e macOS usando un formato LIVE_VIDEO_V1 personalizzato, non un trasporto Nostr. I frame pubblici sarebbero firmati e sottoposti a controllo di freschezza. I frame dei DM viaggerebbero all’interno della cifratura Noise; le registrazioni verrebbero inviate come messaggi. Secondo l’autore, uno stream da Android a iPhone è stato ricevuto. Restano non testati l’invio da un iPhone, le coppie iOS-iOS e il video in diretta nei DM.

ngit

ngit, lo strumento a riga di comando per la collaborazione Git su Nostr, ha rilasciato la v3.0.4. Le connessioni ai relay, così come HTTPS su Android, non si fidano più di un’autorità di certificazione compromessa. I prompt interattivi ora proteggono dall’input vuoto, e i comandi rispettano i filtri offline. Gli aggiornamenti del remote-tracking preservano i commit non ancora pubblicati. Inoltre, la diagnostica distingue una sorgente mancante da una query che non ha restituito risultati.

Hasheus

Lo strumento di verifica dei file prima chiamato verify ora si chiama Hasheus e ha rilasciato la 2.0.0. Controlla i file rispetto agli hash pubblicati su Nostr, e ora prende descrizioni e URL da verificatori fidati ed esegue l’hash dei file di grandi dimensioni a blocchi. Il banner di verifica compare solo sul file esatto pubblicato. Gestisce anche i profili malformati, deduplica i verificatori e segnala un errore in caso di relay mancante. Un checksum corrispondente conferma il file, non le affermazioni di chi lo pubblica su di esso.

Alby JS SDK

L’SDK JavaScript di Alby ha rilasciato la 9.0.0. I client NWC ora concedono a ogni richiesta pubblicata un’attesa fissa di 5 secondi per l’OK del relay e falliscono con Nip47PublishTimeoutError quando questo non arriva, mentre i timeout di risposta per metodo restano invariati. Una risposta che non si riesce a decifrare ora viene rigettata, e il testo di errore del relay viene conservato (gestione degli errori delle richieste). La modifica incompatibile rimuove i metodi multi_* deprecati, e il codice che usa Nip47SingleMethod dovrebbe passare a Nip47Method. Un OK del relay significa che il relay ha accettato la richiesta, non che un pagamento sia andato a buon fine.

Alby Hub

Alby Hub, un nodo Lightning self-hosted che serve wallet tramite Nostr Wallet Connect, ha rilasciato la 1.24.4. La patch rimuove la fiducia in un’autorità di certificazione compromessa dalle sue connessioni TLS native LDK e Go, da cui dipende il servizio wallet NWC dell’hub. Corregge inoltre l’avvio del plugin CLN per le hold invoice.

Orchard

Orchard, un catalogo software Flatpak, ha rilasciato la 0.3.0. La release collega l’interoperabilità delle release software con NIP-82 e la preparazione degli asset Flatpak per la pubblicazione tramite ngit o altri strumenti NIP-82. NIP-82 è una specifica proposta per cataloghi software che non è stata assegnata né accettata, quindi Orchard implementa una bozza che potrebbe ancora cambiare.

Bell

Bell, un aggregatore Android per le conversazioni Nostr, raccoglie risposte e citazioni di più account in un’unica lista cronologica. Le sue note di rilascio della 0.1.0 escludono like, zap, repost semplici e menzioni generiche, e gli account firmano tramite Amber oppure restano in sola lettura. Le release dalla 0.6.0 alla 0.9.0 hanno aggiunto regole di silenziamento per singolo account e una vista dei soli non letti con selezione multipla per segnare come letto. Secondo le relative note di rilascio, il ripristino conserva esattamente le risposte e le reazioni firmate, senza duplicati automatici. La 0.10.0 e la 0.10.1 consentono agli utenti di nascondere singoli post sul dispositivo, con annullamento e ripristino. Nascondere non elimina nulla dai relay, e le nuove risposte continuano a comparire. Le segnalazioni di spam riguardano sia il post sia il suo autore, vengono inviate pubblicamente da un account scelto esplicitamente e non funzionano come blocchi privati. Con la 0.11.0 arriva il repost, dopo che gli utenti hanno esaminato il post originale e l’account di invio. Un avatar dell’account permette di scegliere chi risponde, reagisce o fa repost. Poter pubblicare repost non significa che le notifiche di repost semplici ora vengano aggregate. I thread in cache possono restare incompleti, e l’ascolto in background, attivabile su scelta dell’utente, dipende dalle regole di Android su consumo energetico e rete, senza alcuna promessa di consegna sempre attiva o immediata.

SkateSpots

SkateSpots è una mappa comunitaria di spot e negozi di skate. La versione 1.7.4 ha aggiunto una chat della community cifrata end-to-end, in cui un bot della community approva automaticamente i nuovi dispositivi e anche gli admin possono approvarli. La 1.7.0 ha reso il relay della community la fonte autorevole per spot e negozi. La 1.7.3 ha corretto su Android i codici QR di invito per la chat privata della crew, introdotta in release precedenti. Le release 1.7.8, 1.7.10, 1.7.15, 1.7.19, 1.7.20, 1.7.21 e 1.7.22 estendono quella chat della crew. A differenza dell’approvazione tramite bot della chat della community, qui è un membro esistente della crew ad approvare i nuovi dispositivi tramite QR, membri e dispositivi possono essere rimossi, e la promozione di un fondatore ripubblica il tag admin. Reazioni, tombstone di eliminazione e ricevute di lettura viaggiano come controlli MLS cifrati. I tombstone non sono eliminazioni definitive sui relay, e le ricevute automatiche arrivano solo dai signer silenziosi. Un watcher in background usa la chiave del membro stesso, mai una chiave admin, e circa una volta al minuto trasforma le richieste di adesione in DM NIP-17 o in avvisi nella campanella. Per gli utenti di Amber, gli avvisi di adesione attendono che la campanella venga aperta, mentre i signer silenziosi possono precaricarli, così ad Amber non arrivano richieste in background. I conteggi dei non letti usano gli ID delle buste NIP-17 in sospeso senza decifrarle, escludono le copie inviate dall’utente stesso e non rivelano né confermano l’oggetto o il titolo della conversazione. La consegna in background istantanea o continua non è garantita. Le release dalla 1.7.19 alla 1.7.22 aggiungono anche una ricerca globale nel dataset che viene eseguita solo mentre la command palette è aperta, e memorizzano lo stato della mappa e dei livelli. Non abbiamo verificato in modo indipendente queste modifiche né con test su dispositivo né con un audit di sicurezza.

Emanator

Emanator, un client Nostr multi-account, con la 1.5.0 può ora avviare conversazioni private NIP-17, mentre le release precedenti si limitavano a rispondere ai thread esistenti. Gli utenti scelgono un account di invio abilitato alla messaggistica, poi cercano i contatti per nome o per NIP-05 oppure incollano un npub o un nprofile. Le conversazioni esistenti vengono riutilizzate, e se il destinatario non indica alcuna inbox per i DM l’app offre una consegna best-effort più un’opzione legacy. Con la 1.4.1. I nuovi tentativi mantengono gli event firmati già accettati. Solo i vecchi event che nessun relay ha accettato possono essere firmati di nuovo e ridatati.

Feather

Feather, un client Nostr per Android di cui abbiamo parlato l’ultima volta nel numero #45 durante la sua serie 0.9, è nel frattempo arrivato alla 1.8.4. Le note di rilascio della serie 1.x aggiungono la consultazione e la segnalazione native delle issue NIP-34 tramite i relay dichiarati da un repository. Le azioni firmate ora attendono in una outbox sul dispositivo che WorkManager consegna in background, inviando i post padre prima delle risposte. La 1.8.0 aggiunge i post di immagini di kind 20 con bozze salvate e consegna offline, e la 1.8.4 aggiunge il silenziamento opzionale dopo una segnalazione andata a buon fine. Dalla 1.7.0, la traduzione passa per l’app separata Offline Translator e i suoi pacchetti linguistici, senza fallback sul cloud.

OUTKAST

OUTKAST, un client Nostr per Android, aggiunge nella 2.2.1 la scoperta Network sul dispositivo, che mostra note di account non seguiti a cui le persone che segui hanno messo like o fatto repost nelle ultime 48 ore. Secondo le note di rilascio, il ranking conta reazioni, risposte e zap per numero (non per importo in sat), poi pondera il numero di amici e la novità, senza alcun server di ranking. Quando segui 40 o più account, una nota ha bisogno del sostegno di almeno due amici. I risultati si fermano a 100 note, senza pagine più vecchie. Le note di rilascio descrivono anche feed personalizzati basati su persone o liste scelte e un editor di foto che salva le modifiche come JPEG privi di metadati, mentre gli originali non modificati vengono caricati intatti.

CustID

CustID, un’app signer per Nostr, nella 0.2.2-beta richiede ora l’approvazione biometrica per le richieste ASK NIP-46 sulle identità protette da biometria, anche se un’autenticazione recente può soddisfare la richiesta. Le regole di approvazione e rifiuto memorizzate, comprese le approvazioni precedenti, ora si applicano in modo silenzioso sia su NIP-46 sia su NIP-55. Attivare l’approvazione automatica mostra prima un avviso di conferma, e annullarlo non cambia nulla. La beta aggiunge anche i client tag NIP-89 agli event che pubblica. Sono attivi per impostazione predefinita e mostrano ai lettori quale app ha pubblicato un event; un’impostazione nella sezione Privacy permette di disattivarli.

Nostr Vault

Nostr Vault, un client Nostr, aggiunge nella 3.0.0 connessioni FIPS opzionali tra dispositivi, abbinati tramite indirizzo o codice QR, così un Mac o un telefono di riserva a casa può fungere da vault. Il vault sincronizza note e cronologia, recupera le foto esistenti tramite la mesh e, una volta abilitata la mesh, si avvia insieme al relay dopo un riavvio. Per pubblicare media pubblici serve ancora un media server pubblico. La release corregge inoltre race condition tra account relative a follow e registrazione, attende che i relay di scrittura dell’utente confermino un post prima di segnalarne il successo, e mantiene i DM degli sconosciuti dietro Requests.

Holoboard

Holoboard, una bacheca in cui si paga per pubblicare post, rilascia Android 1.1.0 insieme a un percorso guidato Add to board sul sito web e sul backend che si conclude con il pagamento. Gli ospiti possono inviare testo e link oppure un post Nostr esistente. Le invoice preparate riprendono nello stesso profilo del browser sullo stesso dispositivo, e il QR della invoice resta disponibile senza account né wallet collegato. Da solo, l’APK aggiorna soltanto l’icona del launcher e la schermata di avvio, quindi le modifiche alla bacheca dipendono dal sito web e dal backend corrispondenti. Non è previsto l’accesso con email o password.

Hopp

Hopp, un’app per podcast con boost value-for-value, va oltre il lavoro su identità e pagamenti della serie 0.2.x trattato nel numero #45. La versione 0.3.0 aggiunge sincronizzazione e ripristino cifrati tra dispositivi tramite Nostr, senza alcun server Hopp, che coprono iscrizioni, avanzamento, preferiti, Up Next, abitudini di ascolto e impostazioni di download. Il ripristino mantiene la libreria esistente, e una vista di stato mostra i relay e lo stato delle operazioni in sospeso. Secondo le note, le quote dei boost con esito sconosciuto sono protette da tentativi ripetuti duplicati, e i budget ora tengono conto di Release Boosting e Boost2Unlock.

Nostrautica

Nostrautica, un’app di supporto per gli eventi, aggiunge nella 0.15.1 pacchetti offline per gli eventi che salvano persone, abbinamenti tra persone, talk, la pagina dell’evento, i post e le immagini del profilo, pensati per i luoghi con segnale debole. La chat ottiene i nomi nelle menzioni e le modifiche con eliminazioni, mentre gli invii in sospeso possono essere ritentati o scartati. La versione 0.16.0 passa a MarmotKit 0.14, una libreria per la messaggistica di gruppo Marmot, per il recupero offline con meno connessioni ai relay dei gruppi, e conserva i messaggi non letti durante la pulizia per la conservazione dei dati. La migrazione dello storage è a senso unico, per cui in seguito le versioni precedenti dell’app non sono più supportate. Le note dichiarano che l’interoperabilità con il messenger White Noise o con il web non cambia.

Staircase

Staircase, un’app di chat di gruppo Nostr di relay.tools, aggiunge nella 0.1.25 una modalità di notifica Frequent che controlla all’incirca ogni 5 o 10 minuti e poi si disconnette. In deep sleep è la pianificazione di Android a decidere i tempi, quindi la consegna in background non è né istantanea né garantita. Le modalità Periodic e Frequent eseguono un singolo controllo limitato quando la rete torna disponibile, al massimo ogni due minuti; la modalità Instant non cambia. Lo stato di adesione al gruppo smette di restare in attesa una volta che una richiesta viene gestita o scade, senza indicare quale dei due casi si sia verificato. I relay coordinatori personalizzati restano sotto il controllo dell’utente e non vengono sovrascritti da una lista pubblicata.

In sviluppo

Coracle

Coracle, un client web Nostr, ha integrato su master una correzione al routing. Cliccare su una voce di menu come Lists o Groups mentre quella stessa finestra modale è già in primo piano ora non ha alcun effetto. In precedenza ogni clic impilava un altro pannello identico. Escape li chiudeva uno alla volta. Le modali distinte e la normale navigazione tra le pagine funzionano come prima. Si tratta di codice sorgente integrato, non legato a una release.

nostter

nostter, un client web Nostr, ha integrato cinque correzioni al proprio flusso di zap. Una risposta pay_invoice di Nostr Wallet Connect ora conta come successo solo con il tipo di risultato corretto e una preimage valida, con il campo di errore nullo o omesso. Le risposte malformate vengono rifiutate. Il client rx-nostr dedicato viene sempre rilasciato, anche quando l’inizializzazione fallisce. Dieci secondi senza risposta dal wallet vengono trattati come un esito sconosciuto, non come un fallimento. Gli errori di invoice e di firma compaiono inline e conservano importo e commento per un nuovo tentativo, e i fallimenti delle invoice sono segnalati separatamente da quelli NWC. Il pulsante zap resta abilitato per zap ripetuti. Il suo segno arancione compare anche quando viene mostrata una invoice QR, il che non conferma che un pagamento manuale sia andato a buon fine. Riaprire la finestra di dialogo la reimposta solo quando è inattiva. Chiuderla dopo l’arrivo della invoice o della firma blocca un nuovo pagamento NWC, ma un pagamento già inviato prosegue.

Una pull request aperta mostrerebbe un avviso che invita a controllare la cronologia del wallet prima di pagare tramite il QR di riserva dopo un esito sconosciuto, e sopprimerebbe l’apertura automatica del wallet. Un timeout non significa che il wallet non abbia effettuato alcun addebito.

Pollerama

Pollerama, un client per sondaggi e feed, ha integrato una coda di richieste per singolo relay. La coda regola quante richieste vengono eseguite contemporaneamente, rallenta quando un relay applica limiti di frequenza, suddivide i filtri troppo grandi e normalizza gli URL dei relay. La vista dei pack Mine ora mantiene una sottoscrizione permanente, così anche le risposte lente dei relay vengono visualizzate. I problemi noti di richieste ripetute nell’app restano aperti, e i messaggi diretti non sono stati testati con questa modifica.

Grimoire

Grimoire, un client social Nostr, ha integrato correzioni alla sincronizzazione dei messaggi diretti. Il cursore della cronologia non avanza più su pagine di relay unite che risalgono solo in parte all’indietro, e una protezione di interruzione impedisce a un passaggio di decrittazione di ripopolare messaggi e indicatori di lettura dopo che il logout li ha cancellati. Un backfill interrotto si ferma prima di spostare il cursore o di segnare la cronologia come esaurita. Restano alcune lacune: un solo relay che risponde può ancora segnare la cronologia come esaurita mentre altri mancano, e un rifiuto permanente da parte di un signer fa ancora avanzare il cursore.

nostr-vpn

nostr-vpn, una VPN che usa chiavi Nostr per la scoperta dei peer, ha integrato una correzione per la riconnessione su mobile. Quando è già ora di eseguire una sonda di scoperta, il client ora riattiva i percorsi esauriti verso i peer noti. Lo fa solo se di recente non è stato ricevuto nulla e non esiste alcun percorso connesso o in sospeso, e al massimo una volta ogni 300 secondi. I percorsi sani e quelli in sospeso non vengono toccati, e il formato wire resta invariato. L’autore ha testato la correzione su una fixture nativa isolata, non su reti cellulari. Una seconda modifica integrata rimuove i segreti di adesione alla rete dai bundle di doctor, escludendo dall’output diagnostico il segreto di adesione dell’enrollment e lo stato grezzo del daemon. La chiave privata Nostr vi era già oscurata. I bundle condivisi prima di questa modifica restano esposti, quindi chi ne ha condiviso uno dovrebbe ruotare i segreti di adesione interessati.

Diverse modifiche correlate sono ancora proposte aperte e non sono state né integrate né rilasciate. Per i segreti memorizzati, una conserverebbe i segreti di adesione alla rete nell’archivio dei segreti della piattaforma tramite il percorso di migrazione esistente. Un’altra limiterebbe i segreti sidecar della macchina Windows a SYSTEM e Administrators, coprendo i file DPAPI che contengono le chiavi dei nodi Nostr. Tale restrizione si applica solo alla successiva scrittura di un file, e tra la creazione del file e l’ACL c’è un breve intervallo. I percorsi di configurazione personalizzati non sono coperti, e l’autore non ha effettuato test su una macchina Windows multiutente. Per l’appartenenza firmata, una proposta rifiuterebbe le approvazioni di adesione il cui snapshot del roster non corrisponde più al disco, così che l’amministratore ricarichi e riprovi preservando i dispositivi approvati in parallelo. Un’altra consentirebbe cinque minuti di sfasamento dell’orologio dell’amministratore e richiederebbe sempre un join signer configurato, anche quando l’elenco locale degli amministratori è vuoto, mantenendo il vincolo con il segreto della richiesta. Una terza risolverebbe i pareggi tra roster con timestamp uguale tramite l’hash dell’artefatto. I peer che vedono entrambi i roster sceglierebbero lo stesso unico roster; ciascun roster conserva i propri contenuti di appartenenza. Un’ultima proposta richiederebbe una conferma per le richieste di adesione tramite deep link e per i provider di uscita a pagamento. Su macOS e Linux i link di adesione attenderebbero un passaggio esplicito Add-device. macOS tratterrebbe inoltre i link dei provider a pagamento in attesa di conferma. Non è stata dimostrata l’esecuzione nativa su nessuna delle due piattaforme. Tutti i risultati dei test sono riportati dall’autore.

Buzz

Buzz, un relay comunitario con client desktop e mobile, ha integrato lavori su gruppi e agenti. Gli agenti possono autenticarsi in base alla NIP-FI del progetto, una specifica JWT che verifica il proprietario umano dichiarato dall’emittente; negare o disconnettere quel proprietario termina le sessioni dei suoi agenti, e l’appartenenza del proprietario alla community può ammettere un agente. Gli Huddle inoltre accettano record verificati di agenti gestiti provenienti dall’utente corrente o dal proprietario dell’Huddle, oltre al ruolo bot di attestazione del proprietario NIP-OA. Questo fallback è una politica di compatibilità e non si fida di record sconosciuti di terze parti. Non costituisce una prova di identità. Nessuna delle due specifiche è una NIP accettata.

I canali di annuncio aperti possono ammettere ospiti in sola lettura tramite join_role=guest, e i canali aperti non elencati sono nascosti alla scoperta da parte dei non membri ma leggibili da chiunque abbia l’ID del canale. Gli event di ammissione possono aggiungere fino a 100 membri, con possibile successo parziale. La correzione alle impostazioni dei canali, segnalata la settimana scorsa come proposta aperta, è ora integrata: le modifiche vengono confermate in un’unica transazione insieme alle relative richieste e notifiche. Un passaggio non riuscito da pubblico a privato viene annullato completamente, impedendo che i membri rimossi ricompaiano a causa di quel rollback. Su mobile, gli errori di configurazione delle notifiche push non bloccano più l’app, che riprova un numero limitato di volte e offre un ripristino manuale, con test basati su canali simulati e comportamento sui dispositivi APNs non verificato. I mute sincronizzati non causano più un avvio vuoto, ora verificati rispetto alle effettive sottoscrizioni push dei DM; questa correzione si basa su un solo log di iPhone. Nella mesh dei relay, i record dei peer non più attivi scadono dopo cinque minuti senza heartbeat, mentre le connessioni attive sono esenti.

I merge più recenti non sono confermati in una release. Le aggiunte di membri tramite kind 9000 ora vengono confermate insieme alle relative scritture del roster: una modifica non riuscita non salva né le une né le altre, e lo stesso event firmato può essere ritentato. I kind 9001, 9021 e 9022 mantengono la vecchia lacuna. La diagnostica in shadow mode di NIP-FI ora registra la chiave Nostr verificata e un motivo privato fisso per i casi che verrebbero negati, senza registrare token o claim. Ciò non modifica né l’ammissione né l’applicazione delle regole. La NIP-AP di Buzz, la sua specifica per agenti, un documento del progetto esterno alle NIP accettate, ora richiede un agentType definito dal client nelle impostazioni. Gli avvii con le impostazioni di un altro tipo vengono rifiutati, un campo mancante mantiene il suo significato legacy e il cambio di tipo può scartare le impostazioni annidate del tipo precedente. La selezione di agenti singoli fallisce in modo chiuso quando la policy di agenti gestiti kind 30177 più recente è malformata. I dati più vecchi restano esclusi. Gli agenti vengono etichettati con il nome gestito dal proprietario, mentre le immagini e gli autori dei messaggi usano ancora i profili.

Su mobile, creazione, elenco ed eliminazione degli agenti ospitati usano la prova del proprietario NIP-OA e le registrazioni kind 30177 con tentativi ripetuti durevoli sulla stessa identità, e conservano le istruzioni private in un archivio sicuro. Il relativo gate per l’hosting definito in fase di build è disattivato nelle build App Store e interne, quindi non si tratta di disponibilità pubblica. L’avvio a freddo da invito iOS ospitato conserva l’intento dell’invito, importa una chiave corrispondente e ripristina dal backup. Solo l’autore ha testato il percorso principale, e l’endpoint di fallback per l’appartenenza e la registrazione di un nuovo account restano irrisolti. Il ripristino della registrazione push attende con backoff esponenziale e poi sostituisce una richiesta salvata rifiutata con 401 con una nuova challenge limitata e una nuova chiave App Attest. Mantiene gli intenti dopo errori 400 o transitori e tratta normalmente un 404 ordinario. Questo ripristino non è stato verificato su dispositivi reali. I link ai messaggi verso canali pubblici a cui l’utente non si è unito recuperano i metadati kind 39000 e si aprono in sola lettura, mentre i controlli sui canali privati e sui DM restano invariati. Durante le riconnessioni i link vengono messi in coda, e una singola ricerca lenta può ritardare i link successivi fino a otto secondi.

Diverse pull request aperte non erano ancora state integrate alla data limite delle nostre fonti. Una capability buzz_v1, disattivata per impostazione predefinita, sostituirebbe lo stato di lettura lato client con API NIP-98 per barra laterale, stato di lettura e copertura, private per il chiamante. A queste si aggiungerebbero revisioni per persona e ping di invalidazione di kind 24300 inviati solo tramite relay. I relay privi di questa capability mantengono NIP-RS, mentre i database di grandi dimensioni devono prima costruire i propri indici in modo concorrente. I riepiloghi dei thread analizzerebbero solo le ultime 1.000 risposte, restituirebbero gli ultimi 10 autori e invierebbero aggiornamenti in tempo reale al massimo una volta al secondo per pod. Di conseguenza non elencherebbero tutti i partecipanti passati. Le risposte degli agent alle reazioni verrebbero inserite nel thread del messaggio a cui si è reagito, usando l’ultimo tag e valido di NIP-25 e ripiegando in alternativa sul vecchio ancoraggio. Gli agent basati su Hermes otterrebbero una shell MCP con ambito limitato all’agent per pubblicare in canali e DM. La shell si rifiuta di avviarsi senza il proprio bridge e oscura le credenziali. Installazione, riavvio e pubblicazione dal vivo, però, non sono stati verificati. Una correzione dell’adattatore ACP invierebbe i nomi di inizializzazione sia v1 sia v2, ripiegherebbe sulla v1 stabile e fisserebbe la versione major convalidata. Si tratta di una riparazione del trasporto degli agent, non di una modifica al protocollo Nostr. Su mobile, la funzione Lettura ad alta voce userebbe il motore di sintesi vocale del telefono, saltando codice, link e allegati. È il motore scelto dall’utente a determinare dove viene elaborato il parlato. Un generatore di carico per relay autonomo simulerebbe esseri umani e agent NIP-OA, facendo fallire le esecuzioni che superano i limiti prefissati di errori e latenza. Non modifica alcun codice dei relay e non dimostra la scalabilità in produzione.

Mosaico

Mosaico, un daemon che coordina agent in gruppi basati su relay (NIP-29), ha integrato la presenza basata su heartbeat. Ora un agent risulta presente in un canale solo finché pubblica un event di stato con un timestamp di scadenza (NIP-40) fissato 90 secondi avanti e rinnovato ogni 30 secondi. Un processo in esecuzione in locale non vale più, da solo, come presenza. L’appartenenza resta valida mentre l’agent è offline, così che possa riprendere. Un modello di lettura dei gruppi ricostruito viene generato una sola volta per ogni modifica del relay, con un cursore di arrivo canonico. In questo modo la chat non va più persa quando viene sostituita una sottoscrizione di gruppo ampia.

Tre merge successivi non risultano confermati in una release. Le sottoscrizioni sostitutive ora usano ID REQ nuovi e si aprono prima che venga chiusa quella vecchia. Un profilo dismesso viene pubblicato al di fuori del percorso critico per la latenza. Inoltre, un agent che lascia un canale ritira la propria presenza pur restando membro NIP-29. Le verifiche a supporto sono dell’autore, non misurazioni nostre. Il conteggio dei nuovi tentativi basato su claim preventivo è memorizzato in modo persistente nello schema 27 e sopravvive al replay del relay. Applica un backoff esponenziale da 30 secondi a un’ora su un unico timer seriale e rinuncia dopo 10 errori. Un event mancante non viene trattato come una cancellazione. Poiché la finestra conservata contiene 4.096 voci, la consegna di ogni event non è garantita. Gli snapshot relativi ai soli gruppi ora risvegliano i consumer dei gruppi, e nelle sostituzioni con timestamp uguali viene mantenuto l’ID di event più basso, come specificato da NIP-01. Le modifiche che riguardano solo il contenuto continuano a risvegliare il consumer generale. Un fallback circoscritto per un parent mancante può attendere la successiva modifica del gruppo o un timeout di 15 secondi.

Sonar

Sonar, un messenger che combina Nostr, la cifratura MLS e una rete mesh Bluetooth Low Energy, ha integrato una correzione all’avvio per le connessioni su rete cellulare. La PR attribuisce la lentezza del primo rendering al collegamento al relay push, che mantiene un lock sullo store. Su Android, l’avvio salta quel lock quando il nodo locale è già aperto, come accade quando la registrazione push lo ha aperto prima dell’avvio a freddo. Su iOS, l’app chiede alla notification service extension di interrompere la connessione e lo svuotamento, così da poter effettuare il rendering.

Shopstr

Shopstr, un marketplace Nostr, ha integrato il supporto all’eliminazione degli annunci che era stato proposto la settimana scorsa. Una richiesta di eliminazione di event (NIP-09) firmata dal venditore ora rimuove l’annuncio dalla cache e lo contrassegna con un tombstone. Così un articolo eliminato non può ricomparire né essere acquistato dalla cache, mentre le ripubblicazioni più recenti restano visibili. Alcune eliminazioni sfuggono ancora: una cancellazione che arriva prima del relativo annuncio viene ignorata, le richieste meno recenti prive di tag k non corrispondono alla query sul relay e le eliminazioni passate non vengono recuperate a posteriori. Inoltre, i relay possono conservare gli event eliminati. A parte questo, i messaggi gift-wrapped malformati non bloccano più le viste Orders e My Listings. In più, i venditori ora possono visualizzare i propri ordini, mentre agli altri utenti viene ancora restituito un 403.

Tre pull request aperte, non ancora integrate alla data limite delle nostre fonti, riguardano l’integrità degli ordini. #665 registrerebbe una sola volta i partecipanti di ciascun ordine tramite una registrazione NIP-98, ricavando l’acquirente dall’autenticazione e il venditore dall’annuncio firmato. Le scritture successive non potrebbero modificarli. Una registrazione non riuscita non bloccherebbe il checkout, e i nuovi ordini non risolti non verrebbero dedotti dai tag. Gli ordini legacy sono coperti solo fino a un limite ristretto, e una lacuna nel modo in cui lo stato viene memorizzato per ID ordine resta irrisolta. #666, che dipende da #665, applicherebbe i messaggi di stato dell’ordine gift-wrapped (NIP-59) solo se provengono dall’acquirente o dal venditore registrati per l’ordine, e non da un qualsiasi mittente autenticato. Gli ordini non risolti restano in sospeso, e la conferma post-pagamento dell’acquirente non vale come conferma del venditore. I messaggi contraffatti restano semplici messaggi di chat, senza modificare lo stato dell’ordine. #664 leggerebbe i metadati dei token con keyset Cashu v2 per la registrazione dell’escrow e per le decisioni, senza una ricerca del keyset in rete, e correggerebbe la somma delle proof. La decodifica del token in fase di creazione dell’ordine richiede ancora una correzione separata.

Conduit

Conduit, un marketplace Nostr con app abbinate per acquirenti e commercianti, ha integrato un unico record di account cifrato. Metadati del wallet, seed, identità nativa, indirizzo, preferenze e avanzamento della configurazione si trovano ora in un unico record di dati applicativi personalizzati arbitrari (NIP-78). Il record è cifrato con payload cifrati con versione (NIP-44) e verificato per firma, proprietario e identità derivata; entrambe le app lo trovano non appena il signer dà l’approvazione. Il passaggio non è retrocompatibile: i vecchi percorsi di backup e recupero vengono ignorati, e i backup legacy restano dove sono senza migrazione automatica. Altri merge aggiungono l’accesso con una nsec esistente, conservata nello storage locale del browser, e richiedono condizioni di spedizione firmate esatte quando si modificano famiglie di prodotti. Infine spostano il recupero del checkout su IndexedDB, con una rilettura prima di segnarlo come salvato.

Conduit è inoltre passato a NWC SDK 8.1.1, che porta con sé le relative correzioni per la convalida degli importi, i tentativi di connessione limitati, la gestione dei pool chiusi e le risposte in corso. La scelta del wallet, la cifratura e la policy di pagamento di Conduit restano invariate. Il deployment delle app non è ancora confermato. Due pull request in bozza non risultavano ancora integrate alla data limite delle nostre fonti. L’attivazione dei pagamenti salverebbe in modo persistente, rileggerebbe e consegnerebbe lo stato del pagamento entro una finestra di esecuzione fissa di due minuti, che i nuovi tentativi non azzerano. Ricevute Nostr, recupero privato dell’account e modifiche a scorte o evasione degli ordini richiederebbero ciascuno prove firmate distinte. Le ricevute conservate nelle 24 ore successive non ripristinano l’autorizzazione al pagamento. Restano inoltre in sospeso i controlli con fondi, su dispositivo e da parte dei maintainer. I prodotti riservati agli eventi contrassegnerebbero come nascosti gli annunci NIP-99 di kind 30402 tramite un’estensione conduit_event_only. Resterebbero esclusi dal catalogo e dal checkout normali e richiederebbero un’assegnazione esatta e autorizzata a una specifica occorrenza dell’evento. I dati firmati nascosti restano pubblici, e gli altri client supportano solo il flag hidden standard.

LNbits

LNbits, il server di wallet e account Lightning, ha integrato un’opzione per inviare le proprie notifiche Nostr come messaggi privati NIP-17. Gli amministratori possono scegliere tra i messaggi cifrati legacy NIP-04 e i messaggi diretti privati NIP-17, che sono l’impostazione predefinita per le nuove configurazioni. Con NIP-17, il server cerca l’elenco dei relay inbox per i DM del destinatario. Usa i relay NIP-05 come indicazioni per la scoperta e come destinazione quando non esiste alcun elenco. Se è stato pubblicato un elenco vuoto, l’invio fallisce. Ogni invio ha un limite di 30 secondi e richiede che almeno un relay inbox lo accetti. In nessun caso ripiega su NIP-04.

Zeus

Zeus, il wallet mobile per Bitcoin e Lightning, ha incluso la sua correzione per la contabilizzazione del budget di Nostr Wallet Connect quando l’aggiornamento successivo al pagamento non riesce nella prerelease v13.2.4-rc1. Nella stessa prerelease c’è anche la correzione precedente che fa sì che make_invoice di Nostr Wallet Connect restituisca la propria fattura. Prima della correzione, un errore di aggiornamento dopo un invio NIP-47 faceva saltare la contabilizzazione del budget e restituiva un errore per un pagamento che poteva essere andato a buon fine. Ora, se viene restituita una preimage, l’importo viene addebitato sul budget tramite il fallback esistente. In caso di timeout, invece, l’importo viene trattenuto come spesa in sospeso anche se il pagamento non compare nell’elenco. Potrebbero restare altre lacune, tra cui i pagamenti LND in corso. È seguita la v13.2.4-rc2, con soli aggiornamenti delle dipendenze.

Da allora, due correzioni più recenti sono state integrate nel codice sorgente e non risultano confermate in nessuna delle due release candidate. La correzione della scadenza predefinita fa sì che il decoder BOLT11 locale applichi la scadenza predefinita di 3600 secondi prevista dalla specifica quando una fattura non ha un campo di scadenza. Queste fatture venivano considerate senza scadenza, per cui il controllo che impedisce di pagare fatture scadute non si applicava. La convalida delle fatture NWC in NostrConnectUtils presentava la stessa lacuna. La correzione dei backup per singolo wallet reimposta il timestamp del backup Nostr dei mint per ciascun wallet ecash. Prima di questa correzione, un wallet recuperato dal seed nella stessa sessione di un altro wallet ecash poteva ereditarne il timestamp. Poteva quindi scartare come obsoleti i propri backup più vecchi sui relay e salvare un elenco di mint vuoto, il che disattivava il ripristino automatico. Un backup che termina dopo un cambio di wallet può ancora scrivere il proprio timestamp sotto il wallet sbagliato. I wallet già colpiti mantengono l’elenco vuoto salvato. Per questi wallet serve il ripristino manuale in Mint sync, oppure occorre aggiungere di nuovo i rispettivi URL dei mint. Il loro ecash resta presso il mint. Entrambe le pull request riportano che non sono stati effettuati test su dispositivo.

npub.cash

npub.cash riceve pagamenti Lightning per le identità Nostr e li converte in ecash Cashu. Ha integrato una modifica lato server che pubblica le ricevute di zap sui relay richiesti da chi paga. Il server analizzava già i relay indicati in una zap request, ma li ignorava al momento di pubblicare le ricevute dei pagamenti effettuati. Ora le ricevute vengono inviate a quei relay quando la richiesta ne indica almeno uno. Per le richieste con un elenco di relay mancante o vuoto si continuano invece a usare i relay predefiniti configurati.

eHagaki

eHagaki, un client web Nostr distribuito anche come Web Component incorporabile, ha rilasciato le versioni 1.31.0 e 1.31.1. La versione 1.31.0 aggiunge i repost (NIP-18), le reazioni (NIP-25) e la gestione dei media caricati. Definisce inoltre il routing outbox (NIP-65) prima che un event venga inviato a un signer esterno e può conservare la cronologia dei post e una cache in un relay Citrine locale. La sua migrazione di IndexedDB azzera la cronologia dei post visualizzata localmente, ma conserva le bozze e le richieste di eliminazione salvate. Quanto alla cronologia custodita dai relay, può essere recuperata di nuovo, mentre per i post presenti solo in locale serve un backup o un’esportazione prima dell’aggiornamento. La versione 1.31.1 sincronizza i server di upload NIP-96 tramite il kind 10096, accanto al kind 10063 di Blossom, e mantiene le impostazioni parziali dei relay ancora utilizzabili. Include anche le correzioni per l’elenco dei server di upload e per la sincronizzazione dei server multimediali. Il recupero dell’elenco dei server di upload tramite i relay di lettura dichiarati mantiene l’elenco più recente con firma valida nonostante i timeout di altri relay. Se non ne arriva nessuno, lascia invariate le impostazioni. La sincronizzazione dei server multimediali gestisce separatamente le preferenze Blossom e NIP-96 e non pubblica mai un elenco ridotto dopo una ricerca non riuscita.

Altre correzioni di affidabilità integrate non risultano ancora confermate in una release. Dopo un errore 401 o 403, gli utenti possono registrarsi presso i server NIP-96 yabu.me o nostrcheck.me dalla schermata dei media; la firma NIP-98 copre l’URL effettivo della POST e l’hash del corpo, un cambio di account o di destinazione annulla la richiesta, una protezione impedisce i doppi invii e le richieste dall’esito sconosciuto non vengono reinviate. eHagaki non fornisce mai una password, e i passaggi relativi a codici di invito o pagamenti rimandano al sito ufficiale del provider. Gli elenchi di file Blossom di grandi dimensioni vengono paginati 24 elementi alla volta a partire da uno snapshot locale limitato, rifiutando risposte oltre 8 MiB o 10.000 voci e scartando lo snapshot in caso di cambio di account, sessione o server; arrivare alla fine significa che lo snapshot è esaurito, non che il server non abbia altri file. Il ripristino del remote signer NIP-46 ricostruisce la connessione e, dopo 30 secondi, rifiuta esplicitamente le vecchie richieste in sospeso senza reinviarle. I caricamenti sul server Blossom di Primal codificano l’autorizzazione firmata esistente in Base64 standard con padding, mentre gli altri server mantengono Base64URL.

Anche due merge più recenti non sono confermati in una release. La pubblicazione ora condivide attese limitate e verificate sulle richieste ai relay e mantiene consegna e avanzamento legati alla sessione, sostituendo diversi timer separati. La prima conferma di ricezione valida da parte di un relay vale come successo, mentre la consegna ai relay rimanenti prosegue. L’indicatore di avanzamento non dichiara mai la consegna a tutti i relay, e cambiare account o disconnettersi interrompe la consegna in background. Su richiesta, la cronologia dei post può aggiornare risposte, reazioni ed eliminazioni correlate entro un limite di tre secondi. I risultati già ricevuti vengono conservati dopo un timeout parziale, e un’eliminazione che non arriva non viene considerata prova che non ne esista alcuna.

Formstr Drive

Formstr Drive, un’app di condivisione file cifrata basata su Nostr e Blossom, ha integrato il lavoro sul ripristino della DriveKey, che avevamo segnalato in precedenza come proposta aperta. Prima di scrivere un keyring combinato, l’app legge ogni relay raggiungibile, così le vecchie chiavi convergono man mano che diventano visibili. Una nuova chiave viene creata solo quando due dei quattro relay dell’app non restituiscono nulla e non esistono né cronologia né versione. Un relay di scrittura che non risponde può comunque nascondere per un po’ una vecchia chiave, e le build più vecchie non sono in grado di leggere il nuovo formato JSON.

Il progetto ha inoltre mantenuto separati, per ciascun account, file decifrati, condivisioni, cartelle e outbox. Cambiando account si bloccano le firme e le importazioni in sospeso dell’account precedente, anche se un blob già preparato può rimanere senza riferimenti. I nuovi account devono ora scegliere esplicitamente un server di upload, senza failover silenzioso, mentre le impostazioni predefinite automatiche precedenti vengono mantenute. Il server vede comunque la pubkey, i tempi di caricamento e i byte cifrati. Gli avvisi di duplicato ora richiedono byte attivi identici sullo stesso server e nella stessa cartella. I percorsi Android per la separazione degli account e per la conferma dei duplicati non sono testati, e non abbiamo verificato che nulla di tutto ciò sia presente in una release.

diVine

diVine, un client di brevi video per Nostr, ha integrato modifiche a messaggistica, account e challenge. Le sue prime release beta hanno solo note generiche, quindi nulla di ciò risulta stabilito nelle build distribuite. Gli snapshot dell’account cifrati campo per campo sincronizzano preferenze, decisioni sui badge e avvisi chiusi, ritentano localmente le modifiche in sospeso e bloccano pubblicazioni non sicure in caso di letture incomplete. Gli indicatori di lettura dei DM mantengono il protocollo esistente, le letture delle notifiche usano l’API del server e il comando «segna tutto come letto» richiede una connessione; permessi del sistema operativo, credenziali e consenso relativo all’età restano sul dispositivo.

Nei DM, il composer e il foglio di condivisione si chiudono non appena un messaggio è stato messo in coda in sicurezza; la consegna in background non viene eseguita mentre l’app è terminata, e la consegna conta solo dopo la conferma di ricezione del relay. I nuovi tentativi falliti vengono conteggiati in modo coerente rispetto al limite di tentativi. I messaggi NIP-04 legacy con struttura non valida vengono scartati e annotati in un ledger, anche se le bolle vuote già memorizzate restano e la compatibilità con signer esterni e altri dispositivi non è stabilita. Le anteprime sfocate opzionali per i video nei DM da mittenti fidati sono disattivate per impostazione predefinita e sempre sfocate con un avviso sui contenuti; il video viene comunque scaricato, quindi la sfocatura non offre alcuna privacy di rete. Nei gruppi, bloccare un membro nasconde solo i suoi messaggi; un avviso spiega che quella persona continua a ricevere i tuoi. L’uscita da una stanza resta salvata in modo persistente. La creazione di nuovi gruppi resta dietro un flag disattivato di default. Queste modifiche si applicano ai gruppi esistenti; la revisione trust-and-safety è in sospeso.

Sono state integrate due funzionalità in precedenza aperte. La cache dei video ricevuti nei DM conserva i file decifrati per account fino a 30 giorni o 300 MB; il caricamento automatico nelle chat fidate e dagli utenti seguiti rivela all’host dei media il momento della visualizzazione, mentre i video di sconosciuti richiedono un tocco. Una rimozione lato server non revoca immediatamente i byte in cache, che possono comunque essere eliminati dalla cache prima. La ricerca del proprietario di un nome utente consulta la directory NIP-05 del name server per le ricerche di handle Divine nella prima pagina e fissa solo un proprietario attivo; i nomi cercati compaiono nei log del server, e non si tratta di una validazione NIP-05 generale.

Le liste di persone passano alla disponibilità generale, basandosi sul lavoro combinato di scoperta e gestione. I link di supporto del profilo sono attivi per impostazione predefinita, e l’editor attende una lettura rigorosa del kind 0 grezzo da ogni relay, preservando i provider nascosti e le modifiche non salvate; la promozione negli store e il rollout del backend non sono ancora avvenuti. I tag di attribuzione del client seguono l’attuale preferenza NIP-89 nei nuovi tentativi e nelle modifiche dei metadati, rimuovendo un tag di un client estraneo prima della firma, mentre i post programmati già firmati non cambiano mai. I link brevi esterni autenticati, disattivati di default, firmano esattamente la POST NIP-98 e il corpo entro due secondi e ripiegano sugli URL canonici, che i DM e gli event Nostr mantengono sempre; la creazione tramite gateway è distribuita in stato disattivato, con ulteriori gate di rollout ancora da superare.

I creator possono consentire il riutilizzo di un video pubblico tramite un tag esplicito, opzione disattivata di default e bloccata al momento della pubblicazione in presenza di audio con licenza no-derivatives; si tratta di una convenzione lato client, non di DRM. Il lavoro sulle challenge, solo per test, comprende una base di protocollo firmata, la firma delle partecipazioni con verifiche di regole e consenso, un’archiviazione persistente per account e flussi nativi di revisione e ritiro in build di test speciali. La conferma di ricezione di un relay non equivale all’approvazione dell’organizzatore. La scoperta in produzione è disattivata. Restano da completare la consegna lato backend, i test di accettazione con account reali e una sequenza di rilascio coordinata tra client.

Anche i merge più recenti non sono confermati in una release. Quando la inbox DM kind 10050 di un destinatario non può essere letta, la coda di invii trattenuti NIP-17 ora riutilizza l’ID del gift wrap del destinatario già accettato da un relay, preservando l’identità di quel wrap tra un tentativo e l’altro. Se un nuovo tentativo trova la inbox, il client può ripubblicare sui relay annunciati. Se invece non emerge alcuna inbox, si attesta sulla copia accettata e si affida ai relay per conservarla. I messaggi possono comunque comparire come Failed. La consegna al destinatario o la sua lettura restano non dimostrate; i nuovi tentativi per reazioni ed eliminazioni restano esclusi da questa modifica. Il precaricamento delle notifiche pubbliche e l’aggiornamento del fuso orario usano una cache limitata delle miniature e un indice SQLite condiviso, escludendo DM e campagne. Richiedono una normale release nativa più una modifica coordinata al servizio, e l’esecuzione in background non è garantita. L’editor video guadagna cinque transizioni, per un totale di 20, renderizzate in modo nativo in anteprima e in esportazione. La modalità a movimento ridotto limita deliberatamente le miniature di anteprima. La spaziatura dei flash può ripiegare su una dissolvenza. Non abbiamo testato sul campo l’implementazione nativa.

Al momento del nostro cutoff delle fonti, quattro pull request aperte non erano ancora state integrate. Gli sticker social per i video, basati sul precedente lavoro sugli sticker informativi, scriverebbero piccoli tag sticker piatti con metadati di menzione (p), hashtag (t) e link (r). Il player sovrapporrebbe aree toccabili e avviserebbe prima di aprire link esterni. Gli altri client vedono solo gli sticker impressi nel video, a meno che non implementino i tag, che non sono un NIP accettato. Le menzioni nelle chat Concord protette da flag manterrebbero le identità all’interno di messaggi cifrati autenticati. Gli avvisi in-app arriverebbero solo da mittenti seguiti e non bloccati, nelle stanze che l’utente ha aperto, con un limite di 50 righe e stato di lettura salvato. Non attiverebbero notifiche push del sistema operativo né un rollout pubblico della chat, e i controlli su collisioni di identità, replay e blocchi sono coperti solo da test circoscritti. I tag dei rumor NIP-17 indicherebbero l’autore della reazione una sola volta con il kind effettivo, e le eliminazioni incapsulate rimuoverebbero i tag p fuorvianti. I gift wrap erano già indirizzati ai destinatari corretti, quindi questo non corregge una fuga di informazioni relativa ai destinatari. I rumor già in coda restano invariati, il comportamento negli altri client non è testato e rimane un compromesso sull’archiviazione nelle stanze. La prossima build nativa attiverebbe di default la condivisione tramite link brevi già esistente, mentre la versione web resta disattivata. I percorsi disattivati, senza login e di errore manterrebbero gli URL canonici completi. Distribuzione negli store, prontezza del servizio e verifiche sui dispositivi non sono dimostrate.

rust-nostr

rust-nostr, un insieme di librerie del protocollo Nostr in Rust, ha integrato una modifica incompatibile al modo in cui le sottoscrizioni vengono riemesse. SubscriptionData ora mostra lo stato EOSE corrente di ciascun relay. La riemissione accoda il CLOSE e la REQ con il filtro memorizzato in un unico passaggio atomico, anche in assenza di connessione, il che garantisce il modo in cui vengono accodati ma non che entrambi i frame raggiungano il relay. Il recupero da un vuoto nelle notifiche non fa più cadere silenziosamente una sottoscrizione né invia una richiesta duplicata. Messaggi EOSE o event in ritardo provenienti dalla REQ precedente possono comunque sovrapporsi a quella nuova, perché nel traffico di rete nulla li distingue. Si tratta di codice sorgente integrato, e non abbiamo confermato che sia presente in una release.

nostr-sdk-ffi

nostr-sdk-ffi, i binding che permettono ad altri linguaggi di usare l’SDK di rust-nostr, ha integrato l’accesso diretto alle conversation key NIP-44 v2, così gli host Concord non devono più includere un proprio codice ECDH e HKDF. È un sottile wrapper attorno alla derivazione esistente e non aggiunge nuova crittografia. L’autore ha riportato una build Python e un round trip che produce la stessa chiave da entrambi i lati, ma non ha aggiunto unit test dedicati. Si tratta solo di codice sorgente integrato.

NDK

NDK, un kit di sviluppo Nostr per Dart, ha pubblicato 0.11.0-dev.2, una prerelease con modifiche incompatibili. Non è una 0.11.0 stabile e non ha alcuna relazione con l’NDK JavaScript. La release aggiunge NIP-49: chiavi ncryptsec cifrate con password, con una UI di esempio. Secondo le note, la decifratura limita logN, rifiuta byte di sicurezza sconosciuti e azzera i buffer derivati; queste affermazioni si basano sulle note e sul codice sorgente integrato, e non abbiamo visto un audit indipendente né un’esecuzione dei test vector. Le richieste ora riportano un esito notSent che include l’errore di connessione o di invio, e le richieste verso relay irraggiungibili terminano non appena nessun relay o filtro rimanente può rispondere, senza attendere lo scadere di un timeout. I broadcast verificano la presenza di un signer prima di contrassegnare un event come in transito, gli ID delle zap request usano il created_at memorizzato, e i metadati NIP-11 dei relay vengono recuperati su richiesta tramite una cache condivisa, così non bloccano più ogni sincronizzazione.

La prerelease include anche modifiche che in precedenza erano presenti solo nel sorgente. Le liste NIP-65 che ripetono un URL di relay vengono ora unite correttamente, combinando i marcatori di lettura e scrittura e preservando l’insieme dei relay di scrittura dell’outbox; in una singola osservazione, l’autore ha rilevato 5 liste lette in modo errato su 932 profili. Un controllo preliminare facoltativo BUD-06 per gli upload chiede al server, usando l’autorizzazione dell’upload stesso, se accetterebbe un blob e riporta stato e motivo, come ora avviene anche per i rifiuti di upload reali. Un 404 significa che il supporto è sconosciuto, e superare il controllo non garantisce che l’upload vada a buon fine. Una modifica incompatibile ai timeout di riconciliazione NIP-77 divide il singolo timeout in timeout di apertura e di inattività con un errore tipizzato, escludendo il tempo trascorso in attesa dell’autenticazione. Non esiste una scadenza complessiva, quindi una sincronizzazione che continua a progredire può durare indefinitamente, e non abbiamo visto la modifica verificata su un relay reale.

Alcune pull request aperte propongono caching NIP-05 indicizzato per identificatore con caching negativo, un’API di cache che restituisce ID e timestamp per NIP-77, la gestione dello stato di prontezza dei WebSocket, i campi NIP-11 completi e il completamento quando una connessione viene rifiutata. Un’ulteriore proposta, ancora aperta secondo un controllo recente dello stato, permetterebbe di creare e recuperare account con passkey di piattaforma per browser e Flutter, seguendo una bozza di progetto per l’identità basata su passkey con modalità a chiave derivata e a chiave memorizzata, oltre a metadati legacy espliciti. Gli handle sconosciuti vengono rifiutati e mai trattati come un nuovo account, e il recupero deve essere verificato in modo indipendente prima che una registrazione memorizzata venga conservata. L’autore osserva che l’interoperabilità non è stata convalidata con tutti i provider di passkey.

Applesauce

Applesauce, un insieme di librerie TypeScript per Nostr, presenta nuove modifiche al sorgente accompagnate da changeset, e non affermiamo che esista una release corrispondente. Client di messaggistica autonomi e autenticazione esplicita ai relay aggiungono client NIP-04 e NIP-17 per un account fisso, che effettuano richieste di auth NIP-42 esplicite e ritentano gli invii firmati già preparati. Conversazioni wrapped e store di rumor con ambito definito espongono i rumor di kind 14 e i modelli dei thread senza avviare attività del signer o di rete. La decifratura è disattivata per impostazione predefinita, gli invii wrapped richiedono relay kind 10050 per ogni partecipante, mittente compreso, e l’accettazione da parte del relay non equivale alla ricezione da parte del peer. Il ripristino limitato della cache dei contenuti decifrati usa per impostazione predefinita una concorrenza di 8, che può riordinare gli event a meno che non venga impostata a 1. Spetta alle app definire l’ambito di queste cache in chiaro e cifrarle autonomamente. Seguono il trasporto NDR e un client coordinatore Cordn separato. NDR deve salvare in modo persistente il proprio stato di ratchet separato, e Submitted indica la consegna locale, non la ricezione da parte del peer. Cordn si occupa solo del trasporto, è accantonato nell’esempio e non implementa MLS. L’integrazione ContextVM di Kehto per singola finestra assegna a ogni finestra napplet un’identità ContextVM effimera, senza auth dell’account né pagamenti. Con depositi durevoli gestiti dall’app e recupero dei nutzap, i nuovi depositi e riscatti del wallet richiedono uno store di recupero fornito dall’applicazione che utilizza la libreria e il ripristino NUT-09 da parte del mint. Il journal conserva in modo persistente proof spendibili, segreti e fattori di blinding, quindi dovrebbe essere cifrato e circoscritto per account. La ripresa viene eseguita solo quando invocata esplicitamente, riutilizza gli ID firmati e mantiene il journal fino a un’accettazione positiva da parte del relay; l’annullamento, poi, non invalida la fattura. Snapshot della timeline raggruppati con stato del wallet sincrono accorpano gli aggiornamenti della timeline in finestre di 16 ms, mentre lo stato dei token del wallet resta sincrono. Lo scheduler delle richieste COUNT, proposto la settimana scorsa, è stato ora integrato. Parte da 8 sotto un limite di concorrenza e raddoppia fino al primo errore di rate limit o di trasporto; ogni errore dimezza il limite e aggiunge un periodo di cooldown. I timeout emergono come CountFailure senza abbassare il limite. La latenza orienta soltanto la scelta dei relay; il benchmark su tre relay resta insufficiente per affermazioni generali sulle prestazioni.

eventstore

eventstore, la libreria di fiatjaf che offre backend di archiviazione per gli event Nostr, ha integrato due correzioni alle query. Non è stata verificata alcuna release taggata che le contenga. Tutti i backend ora seguono la regola di NIP-01 per le liste di filtro vuote: una lista ids, authors, kinds o di tag vuota non corrisponde a nulla, mentre una lista di tag assente (nil) continua a non imporre alcuna restrizione. Una correzione al conteggio degli event in LMDB fa avanzare il cursore HyperLogLog dopo una corrispondenza, così i conteggi non si bloccano più all’infinito. Inoltre il conteggio non applica più controlli su author, kind o tag quando il filtro non ne prevede, cosa che in precedenza lo portava a restituire zero.

zsp

zsp, lo strumento a riga di comando di Zapstore per pubblicare app Android su Nostr, ha rilasciato la versione 2.0.0. Il README in corrispondenza di quel tag offre una procedura guidata in cui una persona dimostra di possedere il certificato di firma C1, oltre a un comando zsp skill che fornisce agli agenti le istruzioni di pubblicazione. Vieta di consegnare agli agenti il keystore, la sua password o qualsiasi chiave privata, così la prova resta nelle mani di un essere umano. La release inoltre rileva i keystore JKS e PKCS12 in base al contenuto, quindi gli store PKCS12 denominati .jks o .keystore vengono caricati sia nella procedura guidata sia nel percorso di pubblicazione. Non abbiamo testato la pubblicazione con questa versione.

nsite-gateway

nsite-gateway, che serve siti web statici pubblicati su Nostr, ha rilasciato la versione 3.6.6. La modifica al sorgente passa ad Applesauce 7 e ripristina la scadenza degli event. Le versioni precedenti sostituivano deliberatamente il gestore della scadenza con uno disattivato per aggirare un bug upstream relativo al clamping dei timer, perciò gli event scaduti dei siti potevano restare attivi a tempo indefinito nello store del gateway. Ora che la correzione upstream è disponibile, il gateway usa di nuovo il normale event store. In questo contesto la scadenza determina ciò che il gateway conserva e serve, e non elimina gli event dai relay o dalle cache di terze parti. Non abbiamo testato un gateway in esercizio.

44billion

44billion, un launcher di app Nostr, ha cambiato il modo in cui ricorda i permessi. Le autorizzazioni salvate sono ora legate ad app, nome del permesso, kind dell’event e ambito, e un’autorizzazione jolly con kind -1 non autorizza più kind specifici. Gli ambiti sono granulari solo per le coppie di kind e ambito registrate con etichette tradotte; quelli sconosciuti ricadono su un ambito vuoto che copre l’intero kind, e il registro parte vuoto. La versione 5 dello schema IndexedDB azzera intenzionalmente le autorizzazioni della versione 4 e rimuove all’avvio le autorizzazioni con ambito non supportate, mantenendo gli altri dati delle app. L’API personalizzata di cifratura personale include helper in stile NIP-44 v3 che non costituiscono uno standard accettato. Si tratta di una modifica al sorgente per cui non è stata individuata alcuna release o distribuzione.

Il sorgente più recente aggiunge impostazioni App Data Access che raggruppano per app le autorizzazioni ricordate e consentono agli utenti di revocare una singola autorizzazione o quelle di un’intera app senza ricaricare. La revoca riguarda solo le future richieste protette. I dati già memorizzati o copiati non vengono eliminati, e le operazioni già in corso potrebbero non essere interrotte. Una modifica alla cache degli asset Blossom considera completo un asset in cache solo dopo che lo SHA-256 dell’intero corpo risulta corretto e che è stato memorizzato un corrispondente marcatore di avvenuta convalida. I chunk provvisori provenienti da cache precedenti vengono riconvalidati, e lo streaming non segnala più un falso chunk finale. Ciò non significa che nessun byte venga esposto prima della convalida, e non c’è alcuna nuova release binaria.

Blossom Servers

La directory Blossom Servers ha aggiunto report sulle funzionalità forniti dalla comunità per ogni URL di server, ciascuno attribuito al relativo contributore. Le dichiarazioni manuali e le osservazioni effettuate dal browser sono tenute separate ed escono dai filtri rispettivamente dopo 90 giorni e dopo 24 ore. I controlli esaminano le risposte HTTP e i metodi dichiarati, insieme alle richieste di autenticazione e di pagamento. I controlli anonimi dal browser inviano una richiesta HEAD che propone i metadati di un PNG da 68 byte senza caricare nulla, quindi una risposta 200 non dimostra che un caricamento reale funzioni. Il caricamento delle discussioni ora ha un ambito definito, e l’attribuzione ai contributori sostituisce la precedente autorità implicita dell’operatore. Un report non prova chi gestisca un server e non dice nulla sull’uptime globale o sulla piena conformità ai BUD; i contributori, inoltre, possono essere in disaccordo o sbagliare. Non abbiamo verificato né una distribuzione né una release.

Il sorgente più recente aggiunge relay configurabili per l’app e per il lookup e legge account e outbox tramite NIP-65. Una lista di lookup pubblica kind 10086 già esistente ha la precedenza. Il salvataggio aggiorna la lista pubblica solo se ne esiste già una; in caso contrario resta locale. Il registro locale delle pubblicazioni si aggiorna solo dopo che almeno un relay ha confermato l’event, il che non significa che ogni relay lo abbia ricevuto. Nessuna release o distribuzione è confermata.

Ditto

Ditto, il client Nostr di Soapbox, ha corretto i metadati H.264 prodotti da encoder WebCodecs difettosi, così i video transcodificati possono essere riprodotti su iOS. Rileva i byte di intestazione NAL di SPS e PPS duplicati e i bit riservati errati nel record avcC, e li ripara prima che il muxer Mediabunny scriva i metadati MP4, lasciando invariati i record ben formati o non riconosciuti. La versione 2.45.1 è uscita, ma non abbiamo confermato che contenga la correzione né testato la riproduzione su un dispositivo iOS fisico. La modifica riguarda questo specifico difetto H.264, non tutti i codec o i video.

Signer desktop di Amber e correzione NIP-46 per Android

Amber, il signer Nostr per Android, ha integrato il 27 ottobre il sorgente di un signer NIP-46 desktop basato su Compose (Windows/macOS/Linux) che riproduce il modello di permessi per app e per kind di Android (commit). NIP-55 resta esclusivo di Android. Il codice desktop supporta più account e connessioni nostrconnect/bunker con relay e cronologia per singola app, oltre a Tor e alle notifiche nell’area di sistema. Le chiavi risiedono in un archivio PKCS12 cifrato, protetto da una passphrase Argon2id obbligatoria, con database cifrati per ciascun account. Non abbiamo verificato né il packaging desktop né il comportamento in esecuzione.

Una modifica separata, anch’essa integrata, riguarda l’app Android e non il signer desktop: aggiorna le sottoscrizioni ai relay NIP-46 e i filtri di connessione dopo il logout di un account. Di conseguenza, Amber smette di restare in ascolto per le chiavi di un account eliminato. La notifica con contenuto oscurato sulla schermata di blocco ora mostra anche la descrizione della richiesta. Questo rende la notifica più utile, ma non aggiunge privacy. Non è confermata alcuna nuova release stabile che includa l’una o l’altra modifica Android.

Intent dei napplet e dati delle app sincronizzati in noStrudel

Il client web noStrudel ha integrato diverse modifiche al sorgente, senza tag né distribuzione confermati. Gli intent tra napplet vengono risolti tramite il catalogo e le dichiarazioni del manifest z/i, e i payload accettati vengono consegnati dopo il caricamento del frame di destinazione insieme a un ID mittente attestato dal runtime; gli intent non supportati vengono rifiutati e i gestori con destinazione esplicita richiedono la conferma dell’utente (commit). I napplet installati e i gestori predefiniti si sincronizzano per account nei dati app kind 30078 cifrati con NIP-44, tramite un merge a tre vie (commit), mentre i monitor di relay NIP-66 selezionati si sincronizzano tramite dati app NIP-78 cifrati (commit). I messaggi NIP-17 idratano i gift wrap in cache e riconciliano trenta giorni di dati dai relay DM una volta per sessione, usando NIP-77 dove supportato, con la cronologia più vecchia disponibile su richiesta (commit).

Nostr Feedz archiviato

Nostr Feedz, che combinava RSS con i contenuti long-form e i video di Nostr, ora dichiara nel proprio README di essere archiviato e non più mantenuto (commit). L’avviso rimanda a Readstr di PrivKey, un fork che ne prosegue lo sviluppo. Si tratta di un cambiamento dello stato di manutenzione; non abbiamo verificato se GitHub contrassegni il repository come archiviato, né se account e dati vengano trasferiti.

Zap Cooking: liste protette, correzioni ai signer e registrazione con passkey

Zap Cooking, un client Nostr per la condivisione di ricette, ha integrato un ampio gruppo di modifiche al sorgente web; distribuzione e release non sono confermate. Le scritture delle liste salvate di kind 30001 ora eseguono prima una lettura e vengono serializzate per account, preservando i tag estranei e il contenuto cifrato a partire dalla base completa più recente, e vengono rifiutate quando la lista dei relay è sconosciuta o il quorum non è raggiunto (#869). Il quorum richiede almeno due risposte EOSE da relay in grado di gestire le liste, più la metà dei relay di scrittura idonei dell’utente, e una risposta vuota di nostr.wine non basta a dimostrare un’assenza (#878). Le collezioni personalizzate condividono lo stesso writer protetto, le operazioni in coda più vecchie vengono rieseguite con nuove protezioni (#885), e un EOSE aggregato vuoto, da solo, non fa più apparire vuota una lista (#872).

Un metodo di auth esplicito corregge un bug di minificazione in produzione che confondeva le classi dei signer, così la cifratura NIP-46 e NIP-07 usa il signer attivo e non una chiave locale obsoleta; il backup del wallet sui relay resta bloccato per NIP-46 (#896). Se il login parte da un salvataggio o da una reazione, l’azione viene ripresa. Uno zap in sospeso conserva importo e destinatario, ma richiede comunque di premere Send. Quando il signer rifiuta, viene mostrato un errore, senza alcuna nuova firma silenziosa con la chiave di uno sconosciuto (#867).

L’iscrizione crea l’identità in locale, con la sincronizzazione del vault cifrato tramite passkey attiva per impostazione predefinita; se la sincronizzazione è disattivata o il caricamento non riesce serve una chiave di backup, mentre Google Drive è utilizzabile solo per il ripristino (#893). La configurazione WebAuthn PRF con un’unica richiesta lascia il vault non confermato e la nsec in chiaro nel browser, finché una successiva decifratura riuscita del vault non conferma il vault e rimuove la chiave in chiaro (#907). Estendere quella richiesta all’iscrizione significa affidarsi a una registrazione non firmata, che non costituisce un’autenticazione: chiunque disponga di una challenge del server appena emessa può falsificare una registrazione che supera la verifica, e un attaccante che conosca l’ID della credenziale può sostituire una voce non confermata (TTL di 30 giorni) e negare la sincronizzazione all’utente reale (#911). Si tratta di compromessi documentati, non di garanzie di sicurezza.

I link alle note vengono codificati come NIP-19 nevent con un massimo di tre relay hint osservati, il che aiuta i client a trovare event poco replicati senza garantirne la disponibilità (#873). La sezione Replies del profilo include i commenti NIP-22 di kind 1111 con radice negli event (#877), e una correzione al parser delle coordinate mantiene nei pack e nei piani le ricette con d-tag costituiti da URL (#888). L’esperimento di paywall per le ricette premium è stato ritirato dopo che un audit condotto dall’autore del codice ha individuato un bypass basato sulla pubkey della query; i post legacy di kind 35000 restano leggibili come contenuto archiviato (#862).

Una proposta aperta, non ancora sottoposta a merge, riguarda le mute list (#921). Un recupero della mute list non disponibile resterebbe distinto da un recupero riuscito che restituisce una lista oppure nessuna lista. Con la modifica, un recupero non disponibile non verrebbe più memorizzato in cache come lista vuota per cinque minuti. Gli errori di parsing verrebbero ritentati, con un avviso quando non si riesce a decifrare i silenziamenti privati. All’apertura della campanella delle notifiche la lista verrebbe ricaricata. L’obiettivo è evitare che una mute list vuota, diventata obsoleta senza alcun segnale, lasci entrare nelle notifiche autori silenziati. La modifica non fa sì che ogni errore blocchi i contenuti, e non è stata distribuita.

Pagamenti zap via NWC in Lumilumi

Lumilumi, un client web Nostr, ha una pull request in bozza che permetterebbe di pagare le invoice degli zap tramite Nostr Wallet Connect (NIP-47) con un solo tocco (#1120). L’URI di connessione abilitato alla spesa viene conservato solo in locale ed è escluso dal backup in chiaro delle impostazioni di kind 30078. Le richieste usano NIP-44 quando il wallet dichiara nip44_v2 e, in caso contrario, ripiegano su NIP-04. L’autore l’ha verificata con un wallet simulato, senza alcun pagamento reale, e alla nostra data limite delle fonti la bozza non era stata sottoposta a merge.

Ricerca per identificatori in Wisp

Una pull request aperta per il client Nostr Wisp, non sottoposta a merge alla nostra data limite delle fonti, farebbe riconoscere alla ricerca identificatori NIP-19 e NIP-05 incollati, chiavi esadecimali e link web a entità, prima di ripiegare su una query testuale NIP-50 (#681). Le ricerche puntuali usano i relay hint e la cache locale. La ricerca trasmetterebbe i risultati in streaming mentre attende l’EOSE dai relay interrogati, fino a un limite di 15 secondi, così i relay lenti non vengono più scartati. L’autore riferisce di aver effettuato test solo su emulatore, non su un dispositivo fisico.

Supporto ad Android TV in Zapstore

Zapstore, l’app store basato su Nostr, ha una pull request v2 aperta per Android TV, non sottoposta a merge alla nostra data limite delle fonti (#407). Riconoscerebbe le ABI a 32 bit e supporterebbe il focus Leanback gestito con il solo telecomando, con una soluzione di ripiego quando la schermata del permesso di installazione non è disponibile. Le build a 32 bit prive di Arti mostrano esplicitamente una connessione solo Direct, mentre le build a 64 bit senza Arti falliscono in modalità chiusa. La build per TV usa un signer di debug locale, destinato ai test e non alla distribuzione, e l’unico test su TV dell’autore ha usato un relay compilato in locale perché il bundle pubblico non era disponibile.

Proposte di hardening e NIP-11 per strfry

strfry, il relay Nostr in C++, ha due proposte non sottoposte a merge alla nostra data limite delle fonti. #281 risponde ai rilievi da SF-01 a SF-13 dell’audit del relay limitando la profondità del JSON, i payload decompressi, le code e le etichette delle metriche, correggendo un crash causato da un filtro negentropy vuoto e applicando l’hashing agli indici per i tag lunghi. Passa al formato DB 4, quindi chi la adotta dovrebbe esportare e reimportare i dati. I test superati sono quelli dell’autore stesso. La bozza #278 dichiarerebbe solo le limitazioni NIP-11 effettivamente applicate, più fees e payments_url facoltativi, con payment_required impostato a false per impostazione predefinita e prezzi configurati che non implementano i pagamenti.

Pagamenti Bark in nostrcheck-server

nostrcheck-server, un server Nostr di hosting multimediale, ha una pull request in bozza che aggiunge un provider di pagamento barkd (Bark) (#62). Creerebbe invoice Lightning tramite la REST API di barkd e, facoltativamente, allegherebbe alle risposte 402 un URI BIP-321 X-Ark per singolo file, con la stessa invoice Lightning come ripiego. Un wallet sullo stesso server Ark paga tramite Ark, gli altri usano Lightning, e un pagamento saldato sblocca il file una sola volta. I test usano un barkd simulato, e la modifica dipende dalla pull request aperta BUD-07 #61. Alla nostra data limite delle fonti non era stata sottoposta a merge e non è una funzionalità disponibile su share.yabu.me.

Scritture a pagamento in nostr-relay di mattn

Una pull request in bozza per nostr-relay di mattn, non sottoposta a merge alla nostra data limite delle fonti, aggiungerebbe scritture a pagamento facoltative tramite un wallet Bark, disattivate per impostazione predefinita (#37). Le pubkey pagherebbero in anticipo le commissioni di scrittura tramite barkd, con un filtro facoltativo per kind, e chi scrive senza credito riceve una risposta restricted: con un URL per i pagamenti. Le ricariche userebbero Ark o Lightning tramite URI BIP-321 o NWC, con le commissioni elencate in NIP-11. I test usano un daemon simulato, e non è ancora deciso se la funzionalità debba stare nel codice principale (in-tree) o dietro un hook.

Protezione dal replay alla riconnessione in ContextVM

ContextVM, che trasporta MCP su Nostr, ha una pull request aperta per il suo SDK TypeScript che impedirebbe l’esecuzione duplicata dopo le riconnessioni ai relay (#113). Il transport del server conserverebbe gli ID degli event verificati fino alla propria chiusura, e una cache degli envelope separata e di dimensione limitata blocca i duplicati reincapsulati. La memoria cresce con gli event verificati univoci nel corso della vita del transport. Alla nostra data limite delle fonti la correzione non era stata sottoposta a merge e non è presente in alcun pacchetto rilasciato.

Riproduzione multimediale e approvazioni nella shell Kehto

Kehto, una shell web per le napplet Nostr, ha integrato la riproduzione NAP-MEDIA il 28 ottobre. Gli host Paja e playground ora condividono un player audio e video mediato da policy. Usa i codec del browser per sorgenti finite da URL e Blossom, e riproduce stream live HTTPS in MP3 o ADTS AAC dove MediaSource supporta il codec, avviando la riproduzione prima che la risposta termini. L’autorità della sessione resta vincolata all’endpoint, alla finestra di origine e all’ACL. Revoca o smantellamento ritirano gli URL Blob, interrompono la riproduzione e annullano gli stream. Il metodo ResourceService.openStream, riservato all’host, usa le autorizzazioni e la policy esistenti basate sull’origine dell’endpoint, e non aggiunge alcun messaggio di risorsa sul wire. La consegna terminale rimane. L’alias legacy sendCommand funziona ancora. A parte questo, le callback a due argomenti riconoscibili continuano a funzionare con un avviso. Le callback legacy unarie passano agli oggetti comando. Il resolver del browser rifiuta URL non HTTPS, credenziali e indirizzi IP privati letterali. Disabilita inoltre redirect e referrer. Non può ispezionare il DNS, quindi non garantisce la protezione dagli indirizzi privati al momento della risoluzione: i resolver di produzione richiedono controlli in fase di DNS, mentre il comportamento predefinito nel browser si affida a CORS e alla protezione delle reti private. HLS, DASH, Ogg live, sorgenti Nostr, code, persistenza e ripresa automatica al ritorno del focus restano non supportati. L’autore riferisce 155 test su Chromium e 112 secondi di riproduzione radio da un artefatto Funclet non modificato, che non abbiamo rieseguito. Si tratta di lavoro solo a livello di sorgente. Al pacchetto Napplet 0.32 pubblicato mancano alcuni tipi della bozza. NAP-MEDIA resta una bozza; la conformità in una versione rilasciata non è dichiarata.

Una seconda modifica integrata rende le approvazioni di firma e di pubblicazione specifiche per versione. Ogni approvazione è vincolata all’editore verificato, all’hash dell’artefatto e al signer attivo. Le approvazioni sono revocabili, e quelle solo per la firma e quelle solo per la pubblicazione sono distinte. Un permesso legacy non viene mai aggiornato silenziosamente. Il consenso per un URL di sviluppo mutabile vale solo per quel caricamento, e un cambio di endpoint o di account rifiuta le richieste in sospeso. NAP-LINK apre un link solo dopo un clic esplicito in una finestra modale dell’host, usando noopener. La modifica non dichiara test universali con sorgenti radio CVM esterne, e un merge nel sorgente non dimostra un rilascio su npm.

Pact

Pact, un protocollo Nostr per le relazioni tra agenti e il consenso degli operatori, ora autentica le risposte di Nostr Wallet Connect. Ogni risultato deve recare la firma del wallet e fare riferimento alla relativa richiesta, e Pact verifica il tipo di risultato e l’hash del pagamento insieme all’eventuale preimage restituita. Il riscatto ottiene scritture atomiche nel ledger e protezioni sul consumo e sui nuovi tentativi delle richieste, e vengono chiusi altri percorsi di falsificazione del consenso. Una modifica successiva che limita i pagamenti MCP li mantiene disattivati a meno che non sia impostato PACT_MCP_ALLOW_PAYMENTS=1 e confronta un limite predefinito di 1.000 sat sia con l’importo dichiarato sia con quello BOLT11. La finestra della inbox privata ora si ferma a 200 wrap e segnala il troncamento. I test dell’autore si basano su mock.

nostr.watch

nostr.watch, un monitor di relay Nostr, aggiunge un supporto esplicito al rilevamento e al trasporto FIPS, e le ricerche nell’overlay non ripiegano più sul DNS-over-HTTPS pubblico. Sono ancora gli host a fornire DNS e instradamento IPv6, poiché il monitor non include alcun daemon o proxy FIPS e non offre anonimato. Un controllo più rigoroso sulle npub accetta le npub solo all’interno di hostname .fips analizzati. Le verifiche automatiche NIP-11 e NIP-05 si spostano in un ServiceWorker di proprietà dell’app, eliminando il contesto della scheda proprietaria dal percorso di navigazione osservato guidato dalle estensioni; ciò è stato verificato in Firefox 155 standard con una fixture di estensione controllata. La suite di conformità contiene quindici controlli NIP-01 delimitati, con un livello di conversazione che supporta connessioni indipendenti. L’autore riferisce test superati ed esecuzioni su mesh isolate, non un audit su relay pubblici o sulla sicurezza del browser.

Bitcredit Core

Bitcredit Core, un protocollo peer-to-peer per crediti e cambiali che usa Nostr, ora verifica che almeno un relay di scrittura sia connesso prima che un’operazione su blocco salvi qualcosa in locale o ne attivi gli effetti. Anche il ripristino si reinizializza ora in modo pulito. La validazione delle catene candidate, segnalata come aperta la settimana scorsa, è stata nel frattempo integrata, quindi le catene vengono validate e preparate prima di essere salvate. Questi passaggi riducono la probabilità di uno stato locale incoerente. Un relay connesso non può garantire che i relay accettino l’event né che il regolamento si completi, e quel controllo da solo non rende durevole la persistenza locale.

Un merge più recente, non confermato in un rilascio, aggiunge un gestore delle transazioni al servizio di identità. Blocchi di identità, stato e conferma dell’email vengono ora sottoposti a commit in modo atomico prima che qualsiasi cosa si propaghi su Nostr, e nuovi test verificano che nulla venga inviato quando il commit non riesce. Ciò riguarda solo il servizio di identità. La persistenza di cambiali e aziende non dispone di questo commit atomico, e l’accettazione da parte dei relay e il regolamento restano non garantiti.

MLS-KMP e compatibilità con Marmot

MLS-KMP, la libreria MLS in Kotlin nell’ambito di marmot-kmp, aveva già corretto diversi comportamenti sul wire per allinearsi ad altre implementazioni MLS, quindi i membri sulla 1.2.0 e quelli su quel codice più recente non concordano nei casi elencati e i gruppi devono aggiornarsi insieme. Lo stato salvato è passato alla versione 10, che le release precedenti non possono ripristinare. Il job di compatibilità downstream con Marmot non è bloccante. I suoi test non sono stati eseguiti nell’ambiente in cui è stata scritta quella modifica; Marmot deve ancora adattarsi a authorizeProposal e a GREASE. Una precedente modifica alle app-components impone i componenti di cui Marmot ha bisogno per seguire MDK v0.14. Non abbiamo verificato l’adozione in Amethyst.

Codice sorgente integrato più di recente, non attribuito alla 1.3.0 rilasciata, ripara la compilazione del runner di interoperabilità notturno e riporta l’esito superato, fallito o saltato per ciascuno script. La nostra precedente nota secondo cui il runner live non era mai stato eseguito è quindi superata: gli autori riferiscono esecuzioni funzionanti, anche se l’ultima esecuzione era ancora in corso quando la modifica è stata aperta e non abbiamo riscontrato un risultato finale della CI. Il job OpenMLS resta non bloccante, salta 22 scenari non supportati o che vanno in panic e copre solo la ciphersuite 0x0001, quindi non certifica l’interoperabilità. Quella modifica corregge anche la ricerca della PSK di ReInit tramite l’ID di gruppo conservato, l’interim transcript dell’epoch zero, il segreto casuale del primo epoch e la gestione della PSK di resumption nei commit esterni. Per il transcript dell’epoch zero, il codice ora segue la sezione 11 della RFC 9420 per allinearsi a OpenMLS, quindi gli ingressi esterni nell’epoch 0 differiscono dalla 1.3.0 e dalle release precedenti, e i gruppi più vecchi salvati mantengono il vecchio hash fino al loro primo commit. Il motore originale derivava il segreto del primo epoch da zero; gli autori non hanno individuato alcun exploit perché i commit successivi includono un UpdatePath nuovo, e la correzione non dimostra che ogni problema di sicurezza sia risolto.

Obelisk Relay

Obelisk Relay ha integrato nel proprio branch predefinito una correzione per i gruppi NIP-29 privati. Gli amministratori globali del relay potevano già inviare REQ per i gruppi privati, ma il filtro di visibilità degli event rifiutava comunque gli event corrispondenti. Ora gli amministratori del relay possono leggere quegli event, e i controlli di accesso dei membri restano in vigore. I gruppi privati a livello di relay non sono cifrati end-to-end, e la modifica rende esplicita la visibilità dell’amministratore del server. La correzione è lavoro sul sorgente già integrato, destinato a sviluppatori e operatori.

Plume

Plume, il client desktop in Rust e Tauri, ha integrato una modifica che mantiene un’unica WebSocket persistente, con riconnessione automatica, per ogni relay. Feed, profilo, pubblicazione e messaggi diretti condividono tutti quella connessione. Su di essa vengono multiplexati sottoscrizioni e ID degli event. I tentativi di riconnessione applicano un backoff; le connessioni si chiudono quando si esce dall’app. Prima della modifica, ogni operazione apriva un nuovo socket che poi non veniva mai rilasciato. La modifica revisionata è lavoro sul sorgente già integrato; qui non sono stabilite misurazioni delle prestazioni. Non promette un ripristino senza perdite né una consegna garantita.

Hashtree

Il runtime TypeScript 0.5.22 di Hashtree consente ai provider del browser di conservare in IndexedDB fino a 256 annunci pubblici dei peer, firmati e aggiornati, suddivisi per identità e app. I provider possono ricaricarli prima della scoperta in rete. Le normali REQ tra peer possono riprodurre quella cache dove le regole di ammissione esistenti lo consentono, e la scoperta privata resta in un ambito del proprietario separato. A parte, una modifica all’adapter Rust già integrata annulla le letture dell’indice abbandonate, così i comandi non devono più attendere l’intero timeout di trasporto. La pull request riporta hashtree-nostr-pubsub 0.2.87 come pubblicato, e quel pacchetto ha un versionamento separato rispetto al runtime TypeScript. Alcuni commit del client Rust, presenti solo nel sorgente, aggiungono origini Blossom combinate legacy, di lettura e di scrittura per le letture e un singolo nuovo tentativo per i reset di connessione tipizzati nella fase di richiesta per ciascuna sorgente, senza memorizzare in cache risposte parziali. Una sola installazione a freddo su un Mac non dimostra che i timeout intermittenti dei trasferimenti siano stati risolti.

nostr-pubsub

nostr-pubsub TS 0.5.20 mantiene un archivio limitato di event firmati e aggiunge persistenza in IndexedDB, transazioni atomiche tra schede, scadenza e replay locale per le normali REQ Nostr. La stessa fonte descrive separatamente un’API opzionale nativa in Rust per un archivio su file, con snapshot atomici e un lease esclusivo per lo scrittore, distinta dal pacchetto TypeScript. Nell’implementazione dell’archivio durevole di event, i ricaricamenti ricontrollano le firme e i vincitori degli event sostituibili NIP-01, e rifiutano sia gli event effimeri sia i timestamp avanti di oltre cinque minuti rispetto all’ora corrente. Gli archivi non vengono mai aperti implicitamente, e sono i chiamanti a scegliere l’ambito degli annunci pubblici. FIPS ripristina gli annunci firmati di kind 37195 prima della scoperta in rete e continua a verificarne freschezza, schema e namespace. Le cache di scoperta anonime o private devono restare separate dal replay pubblico, e un router che recupera dati dalla rete non dovrebbe essere usato come fonte di replay. Poiché la conservazione è limitata, tutto ciò non offre un bootstrap offline a tempo indefinito.

FIPS-TS

Il runtime FIPS-TS 0.0.57 accetta un provider di scoperta durevole di proprietà dell’applicazione, che pubblica annunci firmati di kind 37195 e si sottoscrive a essi tramite l’interfaccia esistente. Con un provider iniettato, il trasporto non apre alcun client relay Nostr e accetta un elenco di relay vuoto, mentre allo spegnimento le sottoscrizioni in sospeso vengono svuotate. Il ciclo di vita del provider e lo storage ripristinato sono responsabilità del chiamante. I controlli su namespace, firma e scadenza restano in vigore. L’autorizzazione dei peer continua a essere obbligatoria. Gli annunci in cache non garantiscono il bootstrap offline, perché il nuovo routing autenticato e la segnalazione WebRTC richiedono comunque un carrier FIPS raggiungibile.

Flotilla

Flotilla ha integrato tre modifiche al sorgente. Condividi nella chat permette agli utenti di condividere note autonome e commenti NIP-22 in qualsiasi stanza o conversazione. Citare un messaggio in una conversazione non aggiunge più l’autore citato ai p-tag e non crea più una biforcazione dell’insieme dei membri. La ripresa dei caricamenti interrotti ripristina dalle bozze i caricamenti degli allegati e, mostrando un errore, consente agli utenti di rimediare ai caricamenti non riusciti. Se la compressione fallisce, si ricorre al file originale, che potrebbe conservare i propri metadati. L’attesa dei marcatori di lettura memorizzati trattiene le scritture dei marcatori di lettura della pagina finché non viene caricato lo stato di lettura memorizzato, così gli aggiornamenti di lettura iniziali non vanno persi all’avvio.

following.space

Una pull request aperta per following.space, non ancora integrata alla data limite delle nostre fonti, ripristinerebbe la creazione, la modifica e l’eliminazione dei follow pack, insieme alla possibilità di seguire i membri di un pack. Userebbe Applesauce per la scoperta dell’account e dei relay outbox, e condividerebbe i pack come indirizzi naddr. Supporta signer basati su estensione del browser, un segreto conservato solo in memoria e signer bunker. Né il codice né i test descritti dall’autore dimostrano un servizio distribuito o la compatibilità con ogni signer.

Routstr

Alla data limite delle nostre fonti, tre pull request di Routstr erano aperte e non integrate. Nel servizio principale, la scoperta dello stato di salute dei provider rifiuterebbe gli URL annunciati e i reindirizzamenti che si risolvono in indirizzi non globali, mantenendo la gestione del proxy onion. Gli autori descrivono un’esposizione a server-side request forgery (SSRF) e dei test, ma non si tratta di una correzione distribuita né di un exploit confermato. Nell’SDK, l’attribuzione del provider per un URL seguirebbe la chiave che ha firmato l’event di kind 38421. Una pubkey scritta nel suo contenuto resta non verificata. Tra gli 81 event che l’autore ha controllato sul relay predefinito, nessuno conteneva elenchi di provider basati sul contenuto, quindi non si afferma che URL noti siano stati sfruttati né che ogni provider sia ora sicuro. Il pinning automatico dei percorsi dei modelli passerebbe da costanti integrate a snapshot firmati contenuti in event indirizzabili attendibili di kind 38427. L’SDK conserverebbe l’ultimo snapshot valido e i watermark di rollback, e uno snapshot vuoto fungerebbe da kill switch. La modifica rompe l’API degli adapter personalizzati. Non è stato pubblicato alcun event di policy, e il rollout resta un passaggio a carico dell’operatore.

SatSigner

Una pull request aperta per SatSigner, non integrata alla data limite delle nostre fonti, rielabora il suo livello Nostr di relay, cache e sincronizzazione. Il mancato ritrovamento di un event (la risposta di fine degli event memorizzati inviata da un relay) verrebbe tenuto distinto dai timeout e dall’assenza totale di relay. I contenuti in cache non aggiornati verrebbero segnalati. Gli event verrebbero memorizzati prima che l’elaborazione faccia avanzare i cursori; gli ID dei rumor dei gift wrap verrebbero verificati. Rimuovere un’identità cancellerebbe le sue tabelle Nostr, ma una sincronizzazione di kind 0 può sovrascrivere una modifica locale al profilo. Un seguito impilato su di essa aggiungerebbe una diagnostica con dati oscurati, poster video da toccare per il caricamento nel feed Nostr con al massimo tre player, e il recupero degli aggiornamenti alla ripresa dell’app senza smantellare il pool di relay. Aggiunge inoltre test dei relay che iniettano guasti. Il nuovo modulo video nativo richiede una ricompilazione dell’app, e la validazione sui dispositivi è ancora in sospeso. Nessuna delle due modifiche è stata rilasciata o ha superato una verifica a runtime.

Bray

Bray 3.5.4 aggiunge l’autenticazione ai relay NIP-42 al proprio client e daemon bunker NIP-46. Ora è possibile usare relay privati che richiedono AUTH per leggere i messaggi indirizzati al bunker. Non è accertato che le modifiche successive al sorgente siano incluse in questo tag.

Nel sorgente integrato in seguito, il server MCP di Bray si avvia in sola lettura quando non è configurato alcun signer o quando BRAY_READ_ONLY è forzato, e prende questa decisione prima di aprire qualsiasi segreto. In questa modalità non viene caricato alcun wallet, firma, cifratura e decifratura vengono rifiutate, e sono disponibili soltanto 111 dei suoi 261 strumenti, ossia quelli di consultazione. La CLI e l’SDK richiedono comunque un signer, e un file di segreti configurato ma vuoto continua a essere un errore. Le nuove attestazioni usano ora un namespace di etichette di attestazione NIP-32, al posto di nip-va. La query esistente sul tipo #l trova sia le etichette vecchie sia quelle nuove, mentre signet-protocol mantiene la propria copia 2.5.5. Non si tratta di un’accettazione ufficiale come NIP, né significa che ogni libreria annidata sia migrata. Per nessuna delle due modifiche è dimostrata la presenza nella 3.5.4.

Estensione per browser Alby

Una pull request aperta per l’estensione per browser Alby Lightning, non integrata alla data limite delle nostre fonti, farebbe sì che il suo helper dei permessi rifiuti le voci bloccate memorizzate con un’unica lettura. Questo chiude una race condition in cui la rimozione di una voce di negazione poteva permettere a un handler Nostr di agire senza chiedere conferma. Il percorso equivalente delle voci bloccate per BTC e Liquid non è attualmente raggiungibile. Non si tratta di una correzione distribuita, e non è stato confermato alcun exploit.

Policy di scrittura del relay di MintRadar

Il sorgente di MintRadar aggiunge una policy di scrittura dell’operatore per il relay Nostr del progetto. Limita gli annunci pubblici di kind 38172 e le recensioni di kind 38000 a 16.384 caratteri di JSON serializzato per event e a 120 all’ora per ogni /64 IPv6, con i prefissi IPv6 compressi riportati in forma canonica. Alle sorgenti più intense si applica un tetto flessibile di 3.000 all’ora, mentre un limite assoluto di 6.000 all’ora conteggia solo gli event accettati su tutte le sorgenti. Le chiavi privilegiate non hanno limiti. Le nuove connessioni sono limitate a 120 al minuto, con un burst di 60. Si tratta di codice e configurazione dell’operatore, non della prova di un rollout in produzione né di una protezione completa dagli attacchi denial-of-service.

Nuovi progetti

bosstro

Bosstro è un nuovo client Android per chi risolve le dispute di Mostro. Il sorgente del suo MVP è pubblicato, con un front end Flutter basato sul core Rust di Mostro. I risolutori firmano con una chiave dedicata da risolutore, mai con la chiave del nodo, e il nodo concede a ciascuno un’autorità di sola lettura o di lettura e scrittura. I risolutori autorizzati possono prendere in carico le dispute, partecipare a chat cifrate tra acquirente e venditore che includono immagini e PDF, e pagare l’acquirente o rimborsare il venditore. Le chiavi risiedono in uno storage supportato da Android Keystore, ma le build di sviluppo per Linux e web non dispongono di queste protezioni. I checksum pubblicati non dimostrano chi sia l’editore.

cordn-kmp

cordn-kmp è una nuova implementazione Kotlin Multiplatform di Cordn, basata su Quartz e mls-kmp, per JVM, Android, iOS, macOS e Linux. Il suo CordnGroupManager headless crea gruppi, invia inviti, entra nei gruppi, invia messaggi e si mette in pari tramite un coordinatore MCP su Nostr, un modello diverso dalla consegna via relay di Marmot. I frontend forniscono la propria persistenza, e l’affermazione del README sull’interoperabilità con ts-mls proviene dall’autore.

Da allora il progetto ha pubblicato la 1.1.0, che si compila con la versione rilasciata di Quartz 2.4.0: il precedente requisito di un checkout locale di Quartz non rilasciato, dietro un flag di build, non si applica quindi più alle release taggate. La 1.2.0 rimuove il metodo pubblico CordnExposure.differsFromMarmot() e lascia ai frontend il confronto con un binding diverso. Nonostante il numero di versione minore, si tratta di una modifica incompatibile dell’API. Una proposta aveva chiamato questa versione 2.0.0, mentre la release effettiva usa 1.2.0.

emosphere

EmoSphere è una mappa degli stati d’animo su Nostr il cui sorgente è ora pubblico; il suo README descrive la versione 0.5.1. Ogni dispositivo genera la propria chiave e pubblica event firmati di kind 1074 che contengono un’emozione e un’intensità, una breve nota facoltativa e una posizione approssimativa che gli utenti possono disattivare. I post compaiono su una mappa del mondo con riproduzione temporale e un feed delle persone seguite. Questi segnali sono pubblici e pseudonimi, quindi i relay possono leggere umore e posizione e collegarli a una chiave nel tempo. Su Android le chiavi sono conservate in uno storage sicuro, mentre la versione web usa localStorage.

matrix-appservice-nostr

matrix-appservice-nostr è il sorgente prototipale di un application service Matrix abbinato a un relay Nostr. Dalle stanze Matrix, gli utenti Matrix possono creare o importare identità Nostr e pubblicare, seguire, rispondere, reagire e inviare DM, con handle NIP-05 sul dominio del bridge. Contenuti e media restano sul backend Matrix, e il relay ricostruisce gli event a partire dagli originali salvati. Le chiavi sono cifrate con AES-GCM tramite un segreto configurato oppure mantenute in remoto tramite NIP-46. Gli utenti devono fidarsi dell’operatore, e una redaction Matrix rimuove solo la copia del bridge.

Sette commit più recenti aggiungono identità Nostr ombra. Il bridge le crea automaticamente per gli utenti Matrix autorizzati che interagiscono verso l’esterno, con profili che rispecchiano quelli Matrix. Creando un profilo completo, l’account esistente viene aggiornato sul posto e mantiene la stessa chiave. Gli amministratori del bridge possono concedere a utenti o homeserver esterni un accesso completo o ombra, oppure un accesso passivo limitato alla stanza per risposte, reazioni e voti. Una concessione o un ban per un utente specifico prevale sulle regole dell’homeserver, che a loro volta prevalgono su quelle della stanza. Il permesso completo consente di creare un profilo, ma non ne pubblica uno automaticamente. La revoca dell’accesso conserva chiavi, cronologia e stanze, ma interrompe la pubblicazione verso l’esterno dove non è più consentita. Le identità importate non vengono mai sovrascritte con un profilo rispecchiato. I controlli dispongono di codice e test, ma non di verifiche di interoperabilità a runtime o di sicurezza, e resta necessario fidarsi della gestione delle chiavi da parte dell’operatore. Gli sticker vengono ora inviati come immagini.

nostr-scrutiny

Nostr Scrutiny pubblica sorgenti e schede informative datate 24 ottobre che mettono a confronto cinque client Nostr: Amethyst, Damus, Nostrich, Primal e Quill. Ogni scheda riporta le dichiarazioni sulla privacy del client negli app store e il codice pubblicato, oltre alle richieste di rete osservate alla prima visita da browser. Realizzato in semplice HTML statico, il sito dichiara di non effettuare tracciamento di prima parte. Le schede sono un inventario datato di fatti, non una certificazione di sicurezza né un audit crittografico. L’autore, in un conflitto di interessi dichiarato, sviluppa anche Quill.

v2

Solid Chat v2 è il sorgente, appena pubblicato, di un client che usa un’unica chiave did:nostr per scrivere nelle stanze dei pod Solid con l’autenticazione HTTP NIP-98 e per inviare DM NIP-17 in gift wrap. La firma avviene tramite NIP-07, NIP-46 o una nsec locale, con cifratura NIP-44 e wrap di kind 1059. Le stanze sono in chiaro e protette soltanto dall’ACL di ciascun pod. I media dei DM cifrati vengono caricati su Blossom, mentre le ricerche dei profili passano per una directory nostr.social. Una nsec locale risiede nel localStorage, quindi un signer esterno è più sicuro.

witchat

Witchat è il sorgente di un client bitchat non ufficiale per Windows e Linux. Comunica tramite una mesh Bluetooth di prossimità e, tra preferiti reciproci, ripiega sui gift wrap di Nostr. Si unisce inoltre ai canali geohash pubblici su Nostr, usando event di kind 20000 per i messaggi e di kind 20001 per la presenza. L’interoperabilità con i trasporti di bitchat è un’affermazione dell’autore, e i binari per Windows non sono firmati. I relay Nostr possono vedere gli indirizzi IP e i metadati dei canali; le trasmissioni di prossimità, al momento, viaggiano solo via Bluetooth.

wn-notify

wn-notify è una CLI Python non ufficiale, basata solo sulla libreria standard, che invia messaggi e file ai gruppi White Noise tramite un wn-agent locale attraverso il socket Unix marmot.agent-control.v2; è il connettore a custodire chiavi, stato MLS e relay. La CLI verifica la presenza di final_sent e degli ID dei messaggi. Se l’esito è sconosciuto, termina con un codice diverso da zero segnalandolo come sconosciuto e conserva la chiave di idempotenza per un nuovo tentativo manuale, dato che non ritenta mai da sola. Una conferma di ricezione attesta la pubblicazione sui relay, non che qualcuno abbia letto il messaggio. È stato testato soltanto wn-agent 0.13.0.

xmradar

XMRadar è un’estensione per browser che copia su Nostr post web e articoli di X. Ogni pubblicazione viene approvata tramite un signer NIP-07 esterno. La release 0.2.0 aggiunge le mance in Monero su X per gli autori che hanno un’identità Nostr.

L’implementazione pubblica una ricevuta di kind 9042 solo dopo che l’utente dichiara di aver inviato una mancia e conferma. La ricevuta rende pubbliche le npub di entrambi i partecipanti, l’importo e l’indirizzo. Non contiene alcun ID di transazione, chiave di transazione o prova di pagamento. Grazie a un piccolo importo casuale in piconero, il wallet del destinatario può abbinare il pagamento e pubblicare una conferma di kind 9044. Tale conferma è firmata dal destinatario e non costituisce una prova onchain indipendente. L’interfaccia distingue le mance confermate dal destinatario dalle dichiarazioni non confermate. Le mance inviate dall’utente stesso restano in sospeso per 30 minuti. Le dichiarazioni non confermate contano una sola volta per pagante, in base alla ricevuta più piccola verso l’indirizzo attuale; tali dichiarazioni possono essere falsificate. I totali sono calcolati per autore, non per post. La scoperta degli indirizzi tramite NIP-A3 e le prove X di NIP-39 è disattivata per impostazione predefinita. Quando è attiva, i relay e X possono vedere quali identità l’utente visualizza.

agent-inbox

agent-inbox è un nuovo strumento che permette agli agenti AI di raggiungersi a vicenda tramite handle brevi su Nostr. Un singolo file Python invia gift wrap NIP-17 standard con cifratura NIP-44 v2, può pubblicare su una bacheca pubblica e include fixture tratte dai vettori di test ufficiali. Gli handle sono suffissi troncati della chiave pubblica, non identità certificate. Il README avverte che la sua crittografia in puro Python non è a tempo costante, e noi non l’abbiamo sottoposta ad audit. Qualsiasi client NIP-17 può comunque inviare messaggi alla npub di un agente.

CarryChat

CarryChat è un nuovo messenger store-and-forward che sposta pacchetti di messaggi di dimensione limitata lungo qualunque percorso sia disponibile. Nostr è il suo trasporto via internet, mentre collegamenti locali come Bluetooth LE e il semplice scambio di file coprono i casi offline. Il sorgente include il trasporto Nostr insieme ai relativi test. Secondo il README si tratta di una prima release 0.2, e i test sul campo LoRa su hardware fisico non sono ancora completi. Non l’abbiamo testato su dispositivi.

Tredici commit più recenti, fino a 311f176, sostituiscono i segnaposto della roadmap con codice sorgente funzionante. Riguardano Wi-Fi Direct, un adattatore radio MeshCore, collegamenti Reticulum, schede contatto NFC e un trasporto audio, con codice Kotlin, Rust e di interfaccia utente. Via audio, il lato in ascolto verifica le firme delle schede contatto e accetta i normali frame dei messaggi, ma rifiuta i blocchi di file. NFC scambia solo schede contatto, non messaggi. Si tratta di sviluppo del sorgente successivo alla precedente release 0.2.0, non di un nuovo binario verificato. Il README afferma che MeshCore e LoRa, Reticulum, Wi-Fi Direct e NFC attendono ancora test sul campo o con due telefoni. Le modifiche non rivendicano compatibilità hardware, anonimato o sicurezza. L’audio ad alta frequenza dipende dall’hardware e non è inudibile ovunque. Accanto ai collegamenti locali, Nostr resta uno dei trasporti via relay su internet.

Cosign and Marble

Cosign è un nuovo protocollo, con relativa libreria, in beta che suddivide una chiave di firma Nostr in quote di soglia FROST. Il dispositivo di un utente può firmare insieme a un server, ma i server non possono firmare da soli. Una quota di backup cartacea supporta i flussi di recupero e di rinnovo delle quote descritti nel README, la cui sicurezza non è stata verificata. Marble, un client Android e browser, usa Cosign per i feed e la firma. La libreria FROST sottostante è stata sottoposta ad audit, ma il protocollo di Cosign in sé non ha avuto alcuna revisione indipendente.

Nel sorgente più recente, il client browser di Marble lega le note non inviate all’account con cui si è effettuato l’accesso. Prima di pubblicare, rileva quando un’altra scheda o una sessione remota ha terminato l’accesso, e una richiesta proveniente da un client disconnesso mostra Signed out. La ricerca istantanea interroga Ditto e i relay, non il web in generale. Quando si cercano i post di un singolo autore, controlla i post già caricati prima di interrogare i relay. Il probabile spam viene compresso dietro un avviso espandibile. Un’eccezione Not Spam vale solo in quel browser e solo per quell’autore. Queste funzioni di supporto alla ricerca non costituiscono prova di una revisione di sicurezza.

Cosign 0.12.7 consente che le unioni della lista dei membri provengano solo dai server, impedendo così che una quota di backup cartacea venga promossa a un altro ruolo. Dopo una sincronizzazione di epoch, i server non aggiornati vengono contrassegnati come in ritardo. I risultati parziali non validi vengono rifiutati; la riparazione automatica resta disattivata. Ora i parziali di decifratura includono prove di Chaum-Pedersen, che vengono verificate prima di combinare i parziali. I client più vecchi ignorano le prove, e la parte Android di Marble le riceverà con la sua prossima build. Queste descrizioni di sicurezza provengono dall’autore della release, e noi non abbiamo sottoposto ad audit la crittografia.

Il sorgente Android NIP-55 committato dopo il tag 0.12.7 corregge una race condition alla prima connessione, quando la concessione del server sta ancora arrivando tramite i relay. Le richieste della chiave pubblica ora ricevono risposta immediata. Firma e decifratura attendono fuori dal thread dell’interfaccia e ritentano una volta, solo quando una connessione appena autorizzata riceve una risposta di revoca. Il codice distingue inoltre un server irraggiungibile da uno che risponde con un rifiuto. Questa correzione successiva del sorgente non risulta né nel tag 0.12.7 né in un binario attuale di Marble.

Dream Nests

Dream Nests è una nuova directory in sola lettura di stanze audio Nostr dal vivo che riunisce le stanze Nests e gli event di attività live insieme alle relative chat. Per i lettori di schermo, la web app usa intestazioni e annunci in live region di tipo polite, mentre brevi earcon fungono da segnali sonori. Gli stream HLS pubblici vengono riprodotti in sola modalità ascolto. Le stanze Nests si aprono in Nests, mentre quelle di Corny Chat e HiveTalk si aprono sui rispettivi siti, quindi per parlare si resta in quelle app. Gli indicatori del microfono derivano dai metadati di presenza, non dal rilevamento dell’attività vocale. Non abbiamo testato l’accessibilità su dispositivi. Il repository documenta un URL pubblico del servizio attivo.

fips-pub-pki

fips-pub-pki è un nuovo sorgente per certificati Nostr firmati che consentono a un dominio di delegare a sotto-emittenti, con validazione offline del percorso. Le trust anchor provengono dal progetto complementare fips-pub-domains, che combina dichiarazioni DNSSEC con pin e testimoni. Il verificatore non interroga mai il DNS. La revoca si basa sulla scadenza e su marcatori espliciti, non sulla cancellazione di event dai relay. Secondo il README, i test mesh dal vivo con un dominio pubblico e un telefono non sono ancora completi. Poiché non è stato presentato alcun NIP né registrato alcun kind, si tratta di un esperimento, non di un sostituto di TLS.

Magnetar

Magnetar è un nuovo stack di ricerca per gli event torrent di NIP-35. Abbina un crawler e un backend di ricerca a un’app Android che mantiene una cache SQLite locale, costruisce la fiducia nei pubblicatori a partire dai follow e verifica l’attività degli swarm. La prima prerelease 0.1 include il codice del crawler e test sia per Android sia per il server. L’autore l’ha convalidato solo con test automatici e un emulatore, non su telefoni reali. La fiducia basata sui follow non può rendere un torrent legale o sicuro, e il backend non è un indice autorevole.

Magnitude Relay

Magnitude Relay è un nuovo relay Nostr in Rust di VectorPrivacy, ottimizzato per i DM in gift wrap di Vector e per il traffico Concord, con sincronizzazione NIP-77 e indicatori di digitazione. Secondo gli operatori, ha sostituito strfry su due endpoint Vector esistenti. Il suo repository include harness per test avversariali e benchmark, ma i dati di velocità pubblicati provengono da esecuzioni dell’autore stesso e non sono stati riprodotti in modo indipendente.

Da allora ha integrato un packaging Docker e Compose per gli operatori. Viene eseguito come utente non privilegiato con un volume dati, un bind solo locale e un healthcheck. Le osservazioni su produzione e importazione contenute nella pull request provengono dall’autore, e arm64 non è testato. Il packaging da solo non dimostra la conformità al protocollo.

Il sorgente più recente limita per impostazione predefinita le nuove connessioni per IP a un burst di 300, poi a 60 al minuto. Impostare il limite a 0 lo disattiva, e il loopback è esente. L’header con il vero IP inviato da un proxy è considerato attendibile solo se proviene da localhost, e le connessioni rifiutate ricevono HTTP 429 prima che si apra il WebSocket. Pubblicamente, i rifiuti del relay sono riportati solo in forma aggregata, mentre il dettaglio per IP è disponibile soltanto sul socket di amministrazione. La sincronizzazione massiva NIP-77 esclude gli event effimeri e quelli che scadono entro 600 secondi, mentre la consegna live trasporta comunque gli event di breve durata. Quando cambiano i collegamenti attendibili, il relay salta le verifiche ridondanti di visibilità dei gift wrap, ma i gift wrap vengono comunque sincronizzati. Si tratta di modifiche al sorgente prive di benchmark misurati in produzione.

nostr_doctor

nostr_doctor è una nuova libreria Dart, con una CLI e un front end Flutter, che verifica se i client riescono a scoprire i dati di un account. Parte dai metadati del profilo e dalle liste di relay NIP-65, per poi passare ai relay per i DM privati e alle bozze, oltre che ai server Blossom e alle impostazioni nutzap. Per verificare la reperibilità della lista dei relay, interroga la lista sostituibile. Abbiamo esaminato lo strumento diagnostico come sorgente, senza verificare una release dell’app. I suoi risultati riflettono soltanto i relay che interroga e non indicano la disponibilità globale.

nostr-indexer-relay

nostr-indexer-relay è un nuovo relay in Go che memorizza solo liste di relay NIP-65. Il suo crawler individua i relay indicati in quelle liste, ne verifica il supporto a NIP-77 e si sincronizza con altri indexer attivi tramite negentropy. Include una pagina pubblica di ricerca e un’interfaccia di amministrazione, e si descrive come in fase iniziale. È un indice mirato di liste di relay, non un archivio Nostr né un relay di contenuti generico.

nostr2gh

nostr2gh è un nuovo bridge che trasporta gli event NIP-34 di patch e pull request, insieme ai relativi aggiornamenti, da Nostr a GitHub tramite un relayer in whitelist. Un contributore esegue il push di un branch in una posizione da cui è possibile fare fetch e firma un event Nostr; a quel punto un amico con un account GitHub funzionante apre la PR al suo posto. Lo strumento aiuta i contributori che non hanno accesso a GitHub, ma non aggira automaticamente un ban e non autorizza l’esecuzione automatica di patch non attendibili.

Relay Radio

Relay Radio è una nuova web app in sola lettura che trasforma un feed Nostr dal vivo in suono tramite earcon e sintesi vocale del browser, con in più una live region di tipo polite opzionale per chi usa lettori di schermo. Chi ascolta sceglie una stazione globale curata oppure una costruita a partire dalle persone che segue, con note, risposte, repost, reazioni e zap. Non pubblica né paga mai al posto di chi ascolta. Il filtraggio dei contenuti è best effort, quindi non può garantire che tutto ciò che viene letto ad alta voce sia sicuro.

Hibiki

Hibiki è un napplet di feed autonomo per Torii, e il suo codice sorgente definisce la versione 0.2.1 il suo primo feed funzionante. Un nodo recupera post e media pubblici, mentre il ranking basato sui gusti dell’utente viene eseguito nel browser. Il feed gira in un iframe sandbox senza accesso diretto alla rete e considera la reputazione di spam firmata soltanto come un’indicazione consultiva. Non abbiamo verificato in modo indipendente il confine di privacy.

Il codice sorgente unito fino alla versione 0.2.6 aggiunge risposte inline e riassunti estrattivi delle notizie, e i like non riordinano più i post. Una release con tag resta non confermata. Il supporto all’anteprima nel player Watch aggiunge fotogrammi di anteprima. Gli zap arrivano insieme alle pagine profilo. Per ogni invoice il nodo controlla l’importo e l’hash della descrizione. Ogni pagamento richiede la conferma del proprietario; chi paga usa WebLN o un codice QR. Il nodo non detiene né fondi né chiavi. Le invoice degli indirizzi Primal non hanno l’hash della descrizione, quindi una modifica successiva le accetta quando l’importo corrisponde esattamente. Vengono contrassegnate con bound:false, e il proprietario riceve un avviso che il wallet potrebbe non confermare. Ciò indebolisce il legame tra invoice e richiesta di zap e non le rende conferme NIP-57 valide. Gli errori 5xx e i timeout del wallet vengono ritentati una volta e mostrano il motivo LNURL. L’autore non ha segnalato alcuno zap end-to-end riuscito con un wallet reale.

wax

wax è un nuovo signer in Common Lisp che deriva chiavi di ruolo da un seed BIP-39 e fa passare ogni richiesta attraverso un controllo di policy, negandola per impostazione predefinita a meno che una callback di approvazione o una allowlist non la consenta. Sequenze di envelope distinte per ciascun chiamante proteggono dai replay. I nomi dei suoi metodi ricordano NIP-46, ma il core non fornisce alcun trasporto di rete. Non abbiamo sottoposto il signer a un audit di sicurezza.

WhatZaps

WhatZaps è una nuova estensione per browser che paga i contatti WhatsApp tramite Lightning grazie al supporto WebLN dell’estensione Nostr WoT. Associa un contatto a un profilo Nostr, verifica il suo indirizzo di pagamento e chiede sempre una conferma esplicita prima di pagare. Il comando /zap non viene inviato come messaggio in chat, e il percorso tramite reazione o pulsante paga senza pubblicare nulla. Si tratta di pagamenti Lightning che usano Nostr per cercare le identità, non di ricevute di zap NIP-57 firmate. Non abbiamo testato la corrispondenza dei messaggi che esegue nel browser.

Sondaggi cifrati di Agora

Agora è un prototipo per browser di sondaggi di gruppo cifrati. Combina l’avallo da parte dei membri con ticket di voto ciechi e trasporta il traffico su relay Nostr e WebRTC. Il README presenta il design secondo il principio una persona reale, un voto, ma ciò dipende dalla fiducia nell’emittente dei ticket, che può fabbricarne, e dall’avallo come forma di fiducia sociale. Il design non offre alcuna resistenza alla coercizione. I relay possono vedere tempistiche e indirizzi IP; i risultati dipendono da quali event riceve un client. Il progetto non ha alcun legame con il più vecchio progetto di chat ghobs91/Agora.

Cinderous SDK

Cinderous SDK v0.83.0 è un nuovo prototipo in forma di sorgente che assegna a ogni dispositivo una propria chiave e sincronizza i documenti con una cronologia in stile Git su Nostr e WebRTC, ripiegando sui relay quando necessario. È il chiamante a scegliere e distribuire i relay, e l’SDK non include alcun relay pubblico predefinito. La cifratura usa uno schema sperimentale CinderEK con un Double Ratchet, che non è stato sottoposto ad alcun audit esterno. Lo scambio di chiavi ibrido non rende le firme secp256k1 resistenti ai computer quantistici, e il README descrive l’SDK come non pronto per la produzione.

evil-napplets

evil-napplets ha aggiunto i livelli dal 02 al 08 della sua scala di attacchi per testare gli host che eseguono napplet secondo il modello opaque-origin della bozza NIP-5D. I napplet malevoli sondano i confini delle capability e del bridge e riportano ciò che l’host ha consentito. La modalità dimostrativa è quella predefinita, mentre le modalità attive vanno abilitate esplicitamente. I test attivi devono essere eseguiti solo contro host che chi effettua i test è autorizzato a sondare. La suite è una fixture di red team, quindi il fatto che un host la superi non dimostra che sia sicuro. Si tratta di un progetto separato da evil-napps, che si rivolge a un’architettura di app diversa.

evil-napps

evil-napps è una nuova suite in forma di sorgente che sonda i confini di autorità nei launcher NAPP. Copre il bridge del launcher e il signer NIP-07 esposto alle app. Rientra nell’ambito anche lo storage SharedDB. I bundle NAPP abbinano metadati a un file index, un formato diverso dal singolo artefatto HTML usato dai napplet NIP-5D. Secondo il README, la suite funziona in modalità dimostrativa per impostazione predefinita ed esegue sonde attive solo su richiesta esplicita. I suoi test e il suo harness non certificano alcun launcher.

Feedstr

Feedstr è un nuovo lettore RSS in Rust che sincronizza feed, stato di lettura e preferiti su Nostr in forma cifrata. La sincronizzazione può essere disattivata per singoli feed. Supporta l’importazione e l’esportazione OPML e gestisce gli articoli long-form NIP-23. Il repository contiene alberi di sorgenti per core, Android, web e Flatpak. Il README afferma che il software è stato testato pochissimo e che non se ne consiglia l’uso, e che le istruzioni di installazione e d’uso arriveranno a breve.

Toolkit per ricevute di deposito NKIP

KYC-rip/nkip-0001 è un nuovo toolkit TypeScript, mantenuto da XBToshi, per le ricevute di deposito NKIP-0001. NKIP-0001 è un formato di ricevuta applicativo e non una NIP di Nostr accettata. Il toolkit gestisce ricevute di deposito firmate con Ed25519, commitment con salt, event witness di Nostr e il recupero del salt tramite cifratura NIP-44. La protezione che offre dipende dal fatto che l’applicazione non riveli l’indirizzo di deposito finché il witness non è stato osservato. L’SDK non blocca gli ordini e non garantisce i pagamenti in uscita. I dettagli si trovano nel README.

nostr-parse

nostr-parse è un nuovo parser Rust di VectorPrivacy per event Nostr firmati. Impone la struttura rigorosa dell’event a sette campi, richiede interi non negativi, limita i kind all’intervallo u16, controlla i campi esadecimali e convalida le stringhe con escape. Gli errori vengono segnalati con i relativi offset. I chiamanti possono produrre allocazioni compatte possedute oppure span presi in prestito che puntano all’input, e parse_unsigned accetta rumor NIP-59 non firmati. Il parsing non ricalcola l’ID dell’event né verifica la firma Schnorr, perciò i chiamanti devono comunque eseguire questi controlli autonomamente.

cl-deposits

cl-deposits è una nuova implementazione in Common Lisp di Bitcoin Deposits. In questo design un operatore gestisce su Nostr registri a catena di hash firmati e co-firmati da un quorum, garantiti da riserve Taproot. Il repository include il sorgente e una devnet con test di ispezione. Secondo il README e la ROADMAP, l’autore ha rieseguito le fixture di riferimento, ha fatto girare una devnet su signet e ha testato l’interoperabilità con deposits-rust in entrambe le direzioni. L’autore riferisce inoltre che il percorso di ricezione Lightning funziona, e indica InvoiceLock e Fulfill per i pagamenti come prossimi passi. Gli utenti dipendono dall’operatore, dal quorum di co-firma e dalle ipotesi sulle riserve.

Streets

Streets, un client web Nostr a colonne che mostra affiancati timeline, notifiche e ricerca, ha unito una modifica che salva l’emoji di reazione predefinita nel documento deck NIP-78 dell’account (kind 30078). Gli utenti non devono più sceglierla di nuovo dopo aver rieffettuato il login o su un altro dispositivo. In precedenza la scelta veniva memorizzata solo nel localStorage del dispositivo. Il documento deck è cifrato con NIP-44, per cui la sincronizzazione tra dispositivi richiede il login con un’estensione o un signer che supporti la cifratura. Con le altre modalità di login l’impostazione resta sul dispositivo. Se un account non ha una reazione salvata, viene usato il valore già presente sul dispositivo, così l’impostazione non torna al cuore. Un valore salvato non valido viene scartato senza eliminare il resto del deck. La modifica è nel sorgente, e le note di rilascio della 1.22.0 sono ancora una bozza.

Labradorite

Labradorite è un’app Android per controllare sessioni di agenti di programmazione su un computer Linux associato, e ha pubblicato le versioni 0.1.0 e 0.2.0. Il telefono è soltanto l’interfaccia di controllo. Sul computer, un daemon esegue l’agente e scambia messaggi Marmot MLS su normali relay Nostr, con un gruppo per sessione. Accetta solo npub presenti in una allowlist, vuota per impostazione predefinita (sorgente). La versione 0.1.0 avvia o riprende sessioni approvate, trasmette in streaming testo, chiamate agli strumenti e diff, e gestisce approvazioni e domande. Offre anche controlli Git e la navigazione dei file in sola lettura. La versione 0.2.0 mette in coda i messaggi successivi come turni separati, consente di annullarli dal telefono, conserva il lavoro in coda tra un riavvio del daemon e l’altro e riproduce la cronologia persa dopo la riconnessione. Si tratta di affermazioni di chi pubblica l’app, e non ne abbiamo sottoposto la sicurezza ad audit indipendente.

Nomisma

Nomisma è un registro Android di spese condivise in beta prototipale che associa due partecipanti tramite messaggi Nostr privati. Tiene traccia solo dei saldi e non trasferisce né salda denaro. La versione 0.1.3 ricollega automaticamente i dispositivi associati, ritenta le modifiche persistite con ritardi crescenti e aggiunge l’autenticazione ai relay NIP-42. Inoltre reinvia le operazioni mancanti. I due dispositivi confrontano un’impronta SHA-256 di voci, pagatori e ripartizioni solo quando i rispettivi vector clock per autore coincidono. Entrambi i dispositivi devono avere la 0.1.3 e impostazioni dei relay corrispondenti, perché il relay predefinito è cambiato. I checkpoint sono avvolti in gift wrap con una scadenza NIP-40 di 15 minuti, che chiede ai relay di eliminarli ma non ne garantisce la cancellazione. Le note riportano correzioni al caricamento delle librerie native, all’ordine degli argomenti Schnorr e alla derivazione delle chiavi NIP-44, e non ne abbiamo sottoposto la sicurezza ad audit indipendente. La firma dell’utente passa da Amber, ma sul dispositivo esistono anche chiavi effimere. Le note di distribuzione si contraddicono riguardo al certificato di firma dell’APK, quindi qui non ci siamo pronunciati sulla compatibilità degli aggiornamenti.

Onyx

Onyx è un prototipo di diario privato disponibile come sorgente, non come release qualificata. Conserva sul dispositivo file Markdown datati come fonte di verità e ne esegue il backup sui relay sotto forma di event cifrati di kind 30078. I d-tag con salt evitano di esporre direttamente le date delle voci. Il ripristino richiede la chiave di cifratura locale separata, che quindi gli utenti devono salvare, perché la sola npub non basta a ripristinare il diario. Una patch del 27 ottobre aggiunge un controllo che verifica l’integrità dei campi della richiesta prima della pubblicazione: kind, contenuto, pubkey, tag e timestamp dell’event restituito dal signer devono corrispondere alla richiesta. La patch rifiuta inoltre i download provenienti dall’autore sbagliato, mantiene le modifiche locali più recenti e sostituisce i dati in modo atomico durante il ripristino. Autori e timestamp degli event restano pubblici. Il testo in chiaro passato al comando di cifratura può risultare brevemente visibile tramite l’ispezione dei processi locali, e l’eliminazione di una voce non cancella le copie presenti sui relay.

Zzub

Zzub 0.0.41 è un client comunitario nato come fork di Buzz. Secondo le brevi note di chi lo pubblica, questa versione aggiunge le risposte RSVP del calendario con supporto ai fusi orari, gli zap sui profili, la visualizzazione dei badge NIP-58 e un pulsante huddle che consente di unirsi a una riunione in corso. I controlli degli agenti ottengono un’opzione di riavvio, la possibilità di modificare una lista esente dal budget e nuovi tipi di task card. L’avvio ora usa i canali in cache.

Lavori su protocollo e specifiche

NIP-CD definisce comandi invocati come testo semplice

La specifica NIP-CD, intitolata inizialmente Commands e ora Slash Commands, è stata unita al repository delle NIP il 21 ottobre (revisione della proposta). Un executor pubblicizza un comando in un event di kind 31992 che ne elenca trigger, titolo, descrizione, argomenti posizionali tipizzati e ambiti. Gli utenti lo invocano come testo semplice all’inizio del contenuto dell’event, eventualmente qualificato dalla npub dell’executor, quindi non servono tag specifici per i comandi né supporto da parte dei client. Un trigger senza qualificazione può corrispondere a più executor. I client possono offrire l’autocompletamento, ma non possono renderlo obbligatorio.

Marmot adotta più dispositivi per account

Marmot, un protocollo di messaggistica di gruppo cifrata per Nostr basato su MLS, ha integrato le sue regole per gli account multi-dispositivo (revisione della proposta) il 26 ottobre, in una forma rivista rispetto alla bozza precedente. In un Commit, chi invita può aggiungere al massimo 20 KeyPackage per un singolo account. Ogni dispositivo detiene esattamente uno slot di pubblicazione casuale valido per tutta la sua vita e non copia mai lo stato MLS né i KeyPackage privati. I pacchetti dovrebbero durare 30 giorni, con un rinnovo a 7 giorni. Chi invita invia a ciascun dispositivo idoneo un Welcome dedicato, e la rimozione di un account ne rimuove tutte le foglie.

Marmot consente ai membri di gestire le foglie del proprio account

Marmot ha adottato un componente di appartenenza per lo stesso account, marmot.group.account-devices.v1 (ID 0x800d), che non trasporta dati. Quando la negoziazione del gruppo richiede il componente, un membro può effettuare il commit di Add e Remove per il proprio account senza autorità di amministratore. Con questo componente il membro non può rimuovere la foglia stessa di chi esegue il commit né rimuovere altri account, e lo status di amministratore dell’account non cambia. I gruppi esistenti devono attivare il componente e rispettarne gli invarianti di supporto.

I trigger push di Marmot ottengono padding fresco

Con una modifica integrata il 26 ottobre, Marmot ora richiede padding fresco in ogni trigger push. Ogni trigger di kind 446 contiene almeno un blocco di padding CSPRNG fresco da 1.084 byte, il che lascia al massimo 31 token cifrati reali entro il limite di 32 blocchi. Senza padding fresco, byte di token identici consentirebbero alla deduplicazione basata sull’hash del contenuto di sopprimere notifiche successive legittime. I server calcolano l’hash di tutti i blocchi e non devono rifiutare un trigger strutturalmente valido per il fatto di non riuscire a rilevare il padding. Il padding nasconde il numero di token ai relay e agli osservatori, ma il server di notifica che decifra può comunque vederlo.

Marmot aggiunge la riparazione dei token push per i nuovi membri

Il 26 ottobre Marmot ha integrato la riparazione dei token push per i nuovi membri, e una modifica successiva ne ha chiarito la formulazione finale. Il proprietario del Commit che aggiunge un nuovo membro dovrebbe inviare gli snapshot dei token attivi di kind 448 e i tombstone di rimozione di kind 449. Grazie a un insieme facoltativo di fingerprint in un announce di kind 447, i peer possono inviare solo i record mancanti. Le tre foglie meglio classificate rispondono con timer scaglionati, sotto un limite di frequenza di 24 ore per ciascuna foglia che effettua l’announce. I record firmati inoltrati tramite relay e i tombstone di rimozione conservati riparano lo stato mancante dei token anche mentre i proprietari sono offline.

Proposta per chiavi Nostr custodite da passkey

Una proposta per chiavi Nostr custodite da passkey si basa su Nosskey, uno schema esistente per usare le passkey con le chiavi Nostr. Handle con tag separano un’identità derivata tramite PRF/HKDF da una chiave memorizzata, mentre i record relay cifrati di kind 31778 vincolano relying party, autore e credenziale. Metadati mancanti o sconosciuti non devono creare silenziosamente una nuova identità. L’autorizzazione dell’origine della relying party resta comunque valida, e per i dati Nosskey legacy serve un lettore di migrazione esplicito. Se non viene salvata separatamente, un’identità derivata va persa insieme alla sua passkey.

Proposta di delega DNS per gli identificatori NIP-05

Una proposta di delega DNS non ancora integrata per gli identificatori NIP-05 basati su DNS aggiunge un fallback che si applica solo quando la ricerca HTTPS originale restituisce 404 o 410. In quel caso i client leggono un record TXT _nip05 che punta a un provider HTTPS. Timeout, errori TLS o CORS, reindirizzamenti e chiavi non corrispondenti non attivano mai il fallback, e il DNS non memorizza alcuna chiave. DNSSEC è raccomandato ma facoltativo: con un DNS non firmato, quindi, il TLS del provider non può autenticare in modo indipendente l’autorizzazione del dominio originale. I client meno recenti non sono in grado di risolvere gli identificatori basati solo sulla delega.

Catalogo di applicazioni software proposto come NIP-82

Una proposta di catalogo di applicazioni software usa NIP-82 come numero proposto in quella pull request aperta e non integrata; il numero non è stato né assegnato né adottato. Riunisce kind per app (32267), release (30063), asset (3063), curatela (30267), prove di proprietà dei certificati (30509) e un elenco di relay del catalogo (10067). Gli asset identificano la propria piattaforma e il proprio runtime insieme a un hash del file. Per gli asset Android si aggiunge un hash del certificato di firma. Una firma di prova dimostra che chi pubblica controlla il certificato, ma i lettori devono comunque verificarne la scadenza e la revoca.

URI BIP 321 proposti come destinazioni di pagamento NIP-A3

Una proposta che aggiunge un tipo di pagamento bip321, non integrata, alle destinazioni di pagamento NIP-A3 consente a un event di kind 10133 di contenere un URI bitcoin: completo come istruzioni di pagamento statiche e riutilizzabili. Poiché la destinazione viene riutilizzata, la proposta non ammette un importo né un parametro di fattura BOLT11 monouso lightning. È chi paga a scegliere l’importo, mentre il wallet sceglie un metodo di pagamento che supporta, e il fallback sull’indirizzo Lightning viene mantenuto.

Proposta di zap pagati tramite destinazioni BIP 321

Una proposta di zap pagati tramite destinazioni BIP 321 prevede che il mittente paghi la destinazione bip321 NIP-A3 riutilizzabile di un destinatario tramite Ark (un protocollo Bitcoin offchain), Lightning o onchain, per poi pubblicare uno zap di kind 9740. Il detentore della chiave di ricevuta conferma il regolamento del pagamento con kind 9741. Entrambi i numeri di kind restano provvisori. Il riferimento di pagamento è cifrato con la cifratura versionata NIP-44 verso una chiave di ricevuta che il destinatario sceglie di attivare, e solo quella chiave può confermare il pagamento. Le terze parti non possono verificare i dettagli del pagamento, per cui la conferma dipende dalla fiducia nella firma del destinatario. La proposta non sostituisce gli zap Lightning NIP-57.

Pagamenti Ark proposti per Nostr Wallet Connect

Una proposta di estensione Ark non integrata per Nostr Wallet Connect, il protocollo NIP-47 che permette alle app di controllare un wallet remoto, aggiunge un’istruzione Ark al supporto esistente per pagamenti e ricezioni BIP 321, oltre a un record di pagamento Ark per lookup_payment, senza nuovi metodi. Un wallet usa l’istruzione solo quando supporta la versione dell’indirizzo e la rete e condivide lo stesso server Ark. In caso contrario prova un’altra istruzione dell’URI. Gli importi devono essere espressi in satoshi interi, senza arrotondamenti ai millisatoshi, e i record distinguono un pagamento cofirmato dal server dai fondi che il destinatario ha incassato e può spendere.

Header di pagamento Ark proposto per i server Blossom

Una proposta per un header di pagamento Ark in Blossom, il protocollo per archiviare blob multimediali su server HTTP, aggiunge X-Ark alle risposte HTTP 402 payment-required di BUD-07. L’header contiene un URI BIP 321 con un indirizzo Ark nuovo per ogni richiesta e l’importo. Facoltativamente, l’URI riporta anche lo stesso pagamento sotto forma di fattura Lightning. Come prova, dopo il regolamento del pagamento i client ripetono la richiesta con l’indirizzo Ark pagato. Chi ha usato il fallback la ripete invece con la preimage Lightning. Una richiesta HEAD non viene ripetuta con la prova, e i client procedono con la GET o la PUT.

Proposta di cashtag per le menzioni di asset nelle note

Una proposta di cashtag definisce la tokenizzazione facoltativa di $ seguito da due a sei lettere ASCII, escludendo codice, URL e riferimenti Nostr. Un singolo tag cashtag imposta la modalità di visualizzazione e può associare un ID di asset scelto dall’autore, dato che un ticker da solo non può identificare univocamente un asset. I lettori verificano che il simbolo corrisponda alla chain e all’indirizzo e segnalano le discrepanze senza rietichettarle. I tag facoltativi t nella forma $ticker consentono la ricerca standard sui relay.

Ritirata la specifica gamepad di Napplet

Il 27 ottobre il repository NAPs, dove vengono pubblicate le specifiche Napplet, ha integrato la rimozione della specifica gamepad. La modifica elimina NAP-GAMEPAD.md e annulla l’adozione precedente. Al momento non risulta adottato alcun NAP per il gamepad.

I tag di altezza di Cyberspace evitano collisioni con i tag di gruppo

Cyberspace, un protocollo spaziale basato su Nostr, ha integrato diverse sue specifiche, chiamate DECK. Si tratta di specifiche del progetto, non di NIP ufficiali. La specifica ora rinomina il tag di altezza su borse e chat da h a H. Il tag minuscolo entrava in conflitto con i tag di gruppo NIP-29 e faceva sì che gli event venissero rifiutati o archiviati in modo errato. I lettori ripiegano su un h legacy solo quando H manca. A cambiare è soltanto la specifica del progetto. Non emenda NIP-29 né dimostra che i client distribuiti siano interoperabili.

Audio nascosto in Cyberspace

DECK-0007 definisce l’audio nascosto come un file Blossom cifrato, referenziato da un rumor non firmato all’interno di una borsa o di un forziere firmati. Ciò significa che la persona che lo ha nascosto non viene identificata come autrice attraverso un post pubblico firmato separatamente e riproducibile. Ogni posizionamento usa una chiave e un testo cifrato nuovi, ma chiunque può comunque condividere la chiave. La specifica non afferma che la cifratura garantisca la privacy di chi lo trova né che le sue regole sugli URL blocchino ogni SSRF, e il supporto nei lettori è ancora in corso di sviluppo.

Modelli pubblici e animazione in Cyberspace

Gli oggetti possono ora fare riferimento a modelli SNO pubblici con animazioni bob e spin e ripiegano sul vecchio rendering quando un modello non è valido o non è disponibile. I modelli live possono cambiare o scomparire, e non si dichiara un’ampia adozione.

Specifiche di Cyberspace per oggetti, chat e commenti

I DECK facoltativi da 0004 a 0006 documentano il codice esistente per oggetti, forzieri, inserzioni, chat locale cifrata e commenti sigillati, con vettori di test sintetici. Diverse questioni restano aperte. Le firme di borse e forzieri differiscono, e i commenti sigillati espongono l’ID e il kind del genitore tramite tag pubblici. I detentori possono sovrascrivere le inserzioni. Nella chat ci sono lacune relative al replay e al vincolo di contesto, e i riferimenti ai forzieri non sono implementati. La documentazione non corregge alcun problema di sicurezza e non costituisce un deployment.

Proposta di event multi-autore

Un articolo long-form firmato, Multi-Author Nostr Events as a Soft Fork, propone event il cui hash dell’ID copre le pubkey di più autori, con ciascun autore che firma lo stesso ID. I client meno recenti vedrebbero un wrapper compatibile con secp256k1 contenente i dati nel nuovo formato e tag Q come suggerimenti di ricerca. I peer negozierebbero il nuovo formato per ogni connessione. L’articolo generalizza la precedente proposta post-quantistica dell’autore, che aggiungerebbe una chiave futura come ulteriore coautore. Si tratta di una proposta senza numero, non di una NIP accettata. Restano questioni aperte la sostituzione di naddr in coautorialità e il trasporto binario.

Le sottoscrizioni di sincronizzazione NIP-AR di Buzz inviano uno snapshot completo prima degli head live

Una pull request aperta di Buzz propone sottoscrizioni di sincronizzazione WebSocket NIP-AR (#8522). Il relay invierebbe un insieme coerente di artifact letto in REPEATABLE READ ed emetterebbe EOSE solo una volta completato tale insieme, per poi trasmettere in streaming gli head correnti live; la registrazione live su Redis avviene prima della lettura iniziale. Una disconnessione o un ritardo di Redis chiude la sottoscrizione con CLOSED e richiede una nuova sincronizzazione, e lo stesso vale per modifiche degli accessi, redaction o una coda piena. Le sottoscrizioni hanno un limite di 4.096 artifact; alla data limite delle nostre fonti la modifica non era integrata e non era disponibile in produzione.

Letture incrementali HTTP degli artifact NIP-AR in Buzz

Un’altra pull request aperta di Buzz aggiunge letture HTTP incrementali per gli artifact NIP-AR (#8523). I client paginano in base ai timestamp di modifica del database e a ID stabili con una sovrapposizione di 120 secondi, e ricevono la revisione corrente oppure una rimozione. Gli ID noti possono essere recuperati. I risultati seguono un modello di consistenza eventuale. La proposta non promette uno snapshot completo, e l’assenza di un artifact non significa né cancellazione né perdita di accesso. La sua revisione più recente richiede l’appartenenza o uno scope #h esplicito per i canali aperti non elencati, e una modifica dell’elenco azzera l’avanzamento incrementale. Il feature gate, BUZZ_ARTIFACT_INCREMENTAL_ENABLED, è disattivato e richiede che ogni writer e ogni migrazione (ora dalla 0074 alla 0076) siano già predisposti. Questo ritardo di 120 secondi è un’ipotesi operativa. Alla data limite delle nostre fonti la modifica restava aperta.

Bozza del testo NIP-AM per lettori delegati delle metriche

Una pull request di documentazione in bozza di Buzz specifica lettori delegati per le metriche NIP-AM senza modificare l’autorizzazione a runtime (#8582). L’event di kind 44200 cifrato dall’agente per il proprietario resta invariato, e l’agente emette una copia NIP-44 separata per ogni concessione attiva, vincolata all’esatto ID dell’event di concessione creato dal proprietario. Il kind di concessione proposto 30180 e i limiti per i lettori restano questioni aperte, così come la cronologia, la revoca e il collegamento pubblico. Una revoca firmata non può cancellare le copie che un destinatario possiede già, e alla data limite delle nostre fonti la bozza non era integrata.

DECK-0003 permette a un genitore di trasportare gli oggetti che posiziona

Una pull request aperta di Cyberspace propone DECK-0003 §1.10, una tabella radice di payload di oggetti SNO inline (#81). Una voce presente nella copia del genitore prevale senza alcun recupero dalla rete, anche quando non è valida. Ogni voce è circoscritta alla pubkey dell’autore, con dimensioni e profondità limitate oltre a limiti sui cicli. I lettori meno recenti recuperano gli oggetti mancanti e mostrano un segnaposto. La proposta descrive implementazioni tenute in sospeso in attesa di questa modifica, che alla data limite delle nostre fonti non era integrata.

DECK-0004 definisce porte vincolate all’altezza con chiavi di stanza derivate

Una pull request aperta di Cyberspace aggiunge a DECK-0004 i §3.6 e §3.7, dedicati a look e porte (#82). Le porte sono vincolate all’altezza, e la chiave della stanza è SHA-256(separatore di dominio ‖ chiave di posizione ‖ segreto della porta), con la borsa (bag) della stanza cifrata con tale chiave. Le stanze possono avere porte multiple o annidate, e l’impostazione di una nuova serratura ruota la chiave. Il testo non include vettori di test finché non esisterà una prima implementazione, e al momento del nostro cutoff delle fonti non era stato integrato.

Estensione di nostream per annunciare il peering nel NIP-11

Una pull request aperta di nostream estenderebbe il documento NIP-11 del relay con una sezione dedicata al peering (#999). La sezione annuncia i kind dei feed con limiti temporali e condizioni di regolamento, insieme a un endpoint di contatto e a una proof-of-work per il peering. Solo enabled: false disattiva la sezione, mentre condizioni vuote indicano un peering senza regolamento (settlement-free). Un’offerta annunciata non equivale a un peer accettato. La modifica non implementa alcun accordo tra peer né una federazione a pagamento. Al momento del nostro cutoff delle fonti non era stata integrata.

NIP-CD aggiunge elenchi opzionali di comandi installati

Un seguito di NIP-CD è stato integrato nel ramo predefinito dei NIP il 27 ottobre (merge), e la specifica ora si intitola Slash Commands. Definisce un elenco opzionale di kind 10992, conforme a NIP-51, nel quale un utente conserva tag di indirizzo che puntano a definizioni di comandi di kind 31992, ciascuna identificata dalla pubkey dell’esecutore e dal valore d, con un suggerimento di relay opzionale. Gli utenti possono mantenere l’elenco, e i client dovrebbero usarlo per l’autocompletamento e per i chip visualizzati. L’elenco è una preferenza di visualizzazione e di scoperta. Non autorizza gli esecutori, e l’invocazione in testo semplice continua a funzionare anche senza di esso, senza tag specifici per i comandi e senza che sia richiesto il supporto dei client. NIP-CD resta una bozza opzionale, e il merge non indica quali client abbiano adottato l’elenco.

Marmot restringe la sua regola di preparazione equa per i dispositivi dell’account

Marmot ha integrato il 28 ottobre una correzione alla propria regola di pianificazione per i gruppi che richiedono dispositivi dell’account. Dopo che un passaggio di convergenza limitato raggiunge lo stato Stable, un intent in coda autorizzato da un admin, oppure un intent consentito proveniente dallo stesso account, ottiene un tentativo di preparazione prima che il solo lavoro in ingresso in coda possa forzare un altro passaggio. SelfUpdate e Leave restano esclusi da questa garanzia di equità aggiuntiva, anche se qualsiasi membro può comunque eseguirne il commit. La modifica corregge una formulazione precedente che copriva ogni intent autorizzato, e i gruppi che non richiedono dispositivi dell’account mantengono la pianificazione precedente. Non c’è alcuna modifica al formato wire, e un tentativo di preparazione non garantisce un Commit valido, accettato o canonico.

Marmot propone un roster nascosto dei dispositivi per i gruppi dell’account

Una proposta aperta di Marmot, non integrata, aggiungerebbe un componente device-roster-v1 con ID 0x800e per un gruppo nascosto le cui foglie appartengono tutte a un unico account. Un gruppo porta il roster fin dalla creazione, oppure non lo porta mai. Il roster registra dispositivi, slot rifiutati, KeyPackage rifiutati e mappe delle foglie, ed è il primo componente a usare aggiornamenti differenziali espliciti e indipendenti dall’ordine, applicati al genitore candidato. Gli slot rimossi possono conservare le mappe delle foglie per i gruppi dai quali i loro slot fratelli non possono rimuoverli. Un dispositivo si fida di un gruppo di dispositivi solo se lo ha creato o se vi è entrato tramite un Welcome autenticato da un collegamento confermato, quindi il solo marcatore 0x800e non concede alcuna fiducia. L’Add fondativo indica esattamente il KeyPackage del collegamento confermato. Un dispositivo collegato rubato può modificare il roster finché non viene rimosso. Il limite di dispositivi si applica ai dispositivi. I record delle mappe delle foglie e quelli dei rifiuti hanno limiti di dimensione per singola voce, ma nessun limite al numero di record. I dati del roster non vengono mai copiati su altri account, e il gruppo resta nascosto da chat, conteggi, notifiche e destinazioni. Il testo della proposta afferma che MDK mantiene i byte del roster dietro un interruttore di test, senza alcuna nuova interfaccia ordinaria.

Marmot propone un riscontro più chiaro quando l’attivazione dei dispositivi dell’account fallisce

Un’altra proposta aperta di Marmot, non integrata, consentirebbe ai client di spiegare i fallimenti di attivazione dei dispositivi dell’account. Un client può segnalare che un gruppo non è in grado di attivare i dispositivi dell’account. Questo riscontro a livello di gruppo non può indicare i membri o i dispositivi che bloccano l’attivazione. Un membro che non è un admin attivo apprende soltanto di non avere lo stato di admin. Se una selezione di ramo va persa o un controllo di attivazione rigenerato fallisce, l’utente deve effettuare una nuova richiesta. Il client non ritenta mai automaticamente l’attivazione. Resta invariata la regola esistente secondo cui l’attivazione richiede una nuova richiesta dell’utente da un client autorizzato. Si tratta di una bozza di testo normativo, che non attesta comportamenti implementati o distribuiti.

Marmot propone la verifica tramite emoji per associare nuovi dispositivi

Una proposta aperta di Marmot, non integrata, descrive l’associazione di un nuovo dispositivo tramite uno scambio modellato su m.sas.v1 di Matrix, che usa X25519, HKDF e HMAC. L’utente confronta sette emoji etichettate su entrambi gli schermi, senza leggere né digitare alcun codice. Il possesso della chiave dell’account non autentica mai un dispositivo. Cinque rumor non firmati (Request, Answer, Reveal, Confirm e Cancel) vengono incapsulati (wrap) verso la pubkey dell’account e vincolano l’account, la sessione, il nuovo KeyPackageRef, lo slot del dispositivo esistente e chiavi nuove. Il dispositivo esistente conferma per primo e aggiunge esattamente il KeyPackageRef confermato. Il nuovo dispositivo conferma solo dopo aver verificato, e accetta un Welcome solo per l’ID di gruppo autenticato dallo scambio confermato. Sono proposti i kind da 452 a 456, con i kind da 457 a 489 riservati. Chi detiene la chiave dell’account può comunque falsificare un Cancel per causare un denial of service, anche dopo la conferma. Il limite orario sugli Answer non persiste tra un riavvio e l’altro. I relay possono vedere la raffica di wrap e l’indirizzo dell’account; alcuni casi di merge e di Welcome restano rinviati. Le implementazioni mantengono questi formati disattivati per impostazione predefinita, e due vettori known-answer forniti dagli autori non costituiscono un audit indipendente di sicurezza o di interoperabilità.

La proposta di napplet NIP-5D rende più rigorosi i campi media e sorgente

La proposta aperta di napplet NIP-5D era già stata descritta in precedenza. Le sue modifiche del 28 ottobre sono ora state integrate nel ramo della proposta, non nel ramo predefinito dei NIP, e rivedono i campi opzionali di media e di sorgente introdotti il 17 ottobre. I tag di screenshot e di anteprima ora riutilizzano i campi chiave-valore di NIP-92, con un solo valore x obbligatorio, SHA-256 in minuscolo, e i campi opzionali m, dim, size, alt e duration. I lettori devono verificare l’hash e decodificare il formato effettivo prima del rendering. Se è presente un campo m valido, anche il formato decodificato deve corrispondere a quel tipo MIME. Le voci con un x mancante, ripetuto o non valido vengono ignorate, i campi opzionali non validi vengono scartati senza eliminare gli altri media utilizzabili, e le anteprime multiple vengono ignorate. Un source-commit deve risolversi in un ID Git completo ed esatto, mentre gli archivi sorgente HTTPS richiedono una corrispondenza SHA-256 esatta a livello di byte. I campi sorgente duplicati o malformati vengono ignorati, e i dati sorgente inutilizzabili non devono bloccare la riproduzione HTML. Un commit o un archivio corrispondente non dimostra una build riproducibile, e non viene dichiarata alcuna conformità dei client.

Sei anni di ottobri su Nostr

Nell’arco di sei ottobri, le modifiche datate di Nostr si sono spostate verso l’esterno, dal framing dei messaggi alle applicazioni costruite su di esso. Nel 2021 la specifica di base ha stabilito che i messaggi dei client sono strutturati come array JSON di primo livello. Gli ottobri successivi hanno portato la ricerca nei client e le fatture Lightning, le prove di marcatura temporale e le richieste di lavoro, le varianti dei media e i wallet ecash, quindi la collaborazione sul codice e i metadati dei messaggi privati. Altre modifiche negli stessi mesi hanno reso identità e connessioni più facili da trasferire tra programmi, dallo stato visibile dei relay alle chiavi separate per il signer fino all’abbinamento dei wallet. Quest’ottobre lo stesso documento ha definito che cosa corrisponde a un elenco di filtri vuoto, così i relay che leggono lo stesso JSON dispongono ora di una regola condivisa su quali event esso seleziona.

Ottobre 2021: rendere il trasporto non ambiguo

Il 4 ottobre NIP-01, la specifica di base del protocollo, è stata rivista affinché i messaggi dei client fossero array JSON di primo livello. I prefissi informali EVENT, REQ e CLOSE sono diventati il primo elemento di ciascun array, ed è stato eliminato il requisito del percorso fisso /ws, per cui qualsiasi endpoint WebSocket andava bene. Questo ha chiarito una specifica che aveva già del codice alle spalle. I client scritti in modo indipendente hanno bisogno di un framing esatto prima che qualsiasi cosa più sofisticata possa interoperare.

Il 23 ottobre la direzione da relay a client ha acquisito messaggi EVENT e NOTICE espliciti. Un EVENT inviato dal relay porta l’identificatore di una sottoscrizione REQ esistente, così un client che gestisce più sottoscrizioni su una sola connessione può associare i risultati alle richieste, mentre NOTICE trasporta testo leggibile da una persona. Un vocabolario così ridotto si presta a essere implementato più volte, cosa adatta a relay gestiti separatamente.

Il testo di NIP-01 del 23 ottobre mostra anche che cosa copre una firma. L’ID di un event è il digest di un array JSON UTF-8 compatto che contiene uno zero iniziale, la chiave pubblica dell’autore, il timestamp, il kind, i tag e il contenuto, e l’autore firma quel digest con una firma Schnorr sulla curva secp256k1. L’involucro WebSocket e l’identificatore della sottoscrizione restano fuori da quei dati firmati. Da quel testo discende che lo stesso event firmato può arrivare su sottoscrizioni diverse, o su connessioni diverse, senza essere firmato di nuovo. Una REQ restituisce prima gli event memorizzati corrispondenti e poi resta attiva finché il client non invia CLOSE, chiude il socket o riutilizza l’ID della sottoscrizione per una nuova REQ. Ogni condizione all’interno di un singolo filtro deve essere soddisfatta, mentre più filtri in una stessa REQ corrispondono agli event che soddisfano almeno uno di essi. I nomi dei filtri in quella versione differiscono da quelli attuali. Il comportamento di NOTICE è stato lasciato non specificato, e nulla garantiva per quanto tempo i relay conservassero gli event né che una query li restituisse tutti. Cinque anni dopo, la stessa specifica sarebbe tornata sul significato dei filtri all’interno di REQ.

Ottobre 2022: un feed diventa utilizzabile su un telefono

L'8 ottobre Damus, un client Nostr per iOS, ha aggiunto la ricerca di hashtag, profili ed event. La modifica ha interessato la vista dei risultati di ricerca e il modello dei thread, consentendo a chi legge di passare direttamente a un’identità firmata o a uno specifico event, oltre a scorrere il testo in arrivo. Questa ricerca funzionava all’interno della navigazione del client stesso e non era una ricerca full-text lato relay.

Otto giorni dopo, Damus ha sostituito le semplici righe della configurazione dei relay con una vista che mostra lo stato di ciascuna connessione. Un pallino colorato legge il pool di relay del client. Il verde indica connesso e il giallo in connessione o in riconnessione, con il rosso per qualsiasi altro stato e il grigio prima della prima lettura. La vista si aggiorna quando compare e poi ogni due secondi. Lo swipe-to-delete, già esistente, è stato spostato nella nuova vista. Con i pallini visibili, un feed bloccato non doveva più essere interpretato come il silenzio di un autore, perché chi legge poteva vedere quale tra diverse connessioni indipendenti era attiva e quale stava riprovando. Un pallino verde indica un socket aperto. Non indica che un relay abbia accettato o conservato un event. Non indica nemmeno che una query abbia restituito tutto ciò che il relay contiene. Il commit documenta l’implementazione nel codice sorgente integrato. Questa modifica al codice sorgente non stabilisce alcuna data di rilascio sull’App Store.

Il 19 ottobre Damus ha aggiunto un parser per le fatture Lightning BOLT11 e dei widget per le fatture in post, chat e messaggi diretti. Nel widget compaiono la descrizione della fattura e l’importo in satoshi, e il suo pulsante Pay passa l’URI lightning:, tramite iOS, a un gestore installato. Il client social presenta il post firmato, mentre un wallet separato effettua il pagamento. Questi widget sono precedenti alla successiva convenzione delle ricevute zap, quindi sono visualizzazioni di fatture, non zap standardizzati.

Ottobre 2023: gli event portano prove e richieste di lavoro

L'11 ottobre le attestazioni OpenTimestamps di NIP-03, che ancorano a Bitcoin prove relative agli event, sono passate da un campo ots dell’event a un event separato di kind 1040. Quell’event indica l’originale con un tag e e contiene nel proprio contenuto il file OpenTimestamps completo in base64, con almeno un’attestazione Bitcoin. L’id dell’event referenziato è esso stesso il digest attestato dalla prova, così chi verifica apprende che l’event esisteva entro il momento attestato. Quel momento deriva da Bitcoin, non dal created_at indicato dall’autore. La prova data l’event e non afferma nulla sul suo contenuto.

Il 12 ottobre, indipendentemente dalla modifica sulle marcature temporali, la derivazione delle chiavi di NIP-06 ha ottenuto due vettori di test. Una frase mnemonica è una sequenza di parole che codifica un seed di recupero, e i vettori coprono una frase mnemonica da 12 parole e una da 24, ciascuna con le chiavi privata e pubblica attese in esadecimale e nelle codifiche nsec e npub. NIP-06 usava già BIP-39 per trasformare la frase mnemonica in un seed binario e il percorso BIP-32 m/44'/1237'/<account>'/0/0 per derivare una chiave, con l’account zero come scelta di base per una singola chiave. L’aggiunta di ottobre ha fornito risposte note, non un meccanismo di recupero dalla frase mnemonica né un nuovo algoritmo di derivazione. Un client può ora verificare che la propria derivazione e le proprie codifiche riproducano l’identità documentata. La corrispondenza con i vettori rende confrontabili le implementazioni. Non certifica però alcuna implementazione specifica, né dimostra che tutte le importazioni di wallet e client concordino. Proteggere un seed dal furto è una questione separata, che i vettori non affrontano.

Il 29 ottobre, NIP-90, lo standard delle data vending machine, è stato integrato nel repository dei NIP con kind di job fissi. Riservava i kind da 5000 a 5999 alle richieste di job e fissava il kind di ciascun risultato al kind della richiesta più 1000. Per il feedback si usava il kind 7000. Una richiesta può rimandare a testo, URL o job precedenti. Può anche indicare l’output atteso e proporre un’offerta di prezzo facoltativa. Il compito vive quindi in event firmati a cui qualsiasi fornitore può rispondere, al di fuori dell’API di un singolo vendor. Una bozza precedente aveva usato i kind 68001 e 68002.

Ottobre 2024: alternative per i media ed ecash portabile

Il 15 ottobre, gli event video di NIP-71 hanno adottato i tag imeta per le varianti video. Nei kind indirizzabili allora in vigore, 34235 e 34236, URL, dimensioni, tipo MIME, immagine di anteprima e fallback di ciascuna variante stavano insieme in un unico tag. Un client che sceglie una risoluzione deve sapere quale miniatura e quale fallback le appartengono, e dei metadati appiattiti non potevano dirlo. Quei numeri di kind sono storici: l’attuale NIP-71 usa i kind 21 e 22.

Dieci giorni dopo, i wallet Cashu di NIP-60 e i nutzap di NIP-61, entrambi introdotti in bozze precedenti, sono stati integrati insieme come specifiche. Si basano su Cashu, un protocollo ecash i cui token sono emessi dalle mint. NIP-60 conserva sui relay le proof cifrate del wallet, così applicazioni compatibili possono accedere allo stesso stato del wallet. Con NIP-61, l’event kind 10019 di un destinatario elenca mint fidate, relay e una chiave di blocco, mentre l’event kind 9321 di un mittente trasporta proof bloccate su quella chiave, che il destinatario può riscattare. Gli utenti continuano a dipendere dalle mint che emettono i token, e le applicazioni devono impedire che le stesse proof vengano riscattate due volte.

Il 29 ottobre, la firma remota di NIP-46, in cui un servizio separato custodisce la chiave che firma per conto dell’utente, è stata rivista in modo che una stringa di connessione bunker:// contenga la chiave pubblica del signer remoto. L’identità dell’utente si ottiene separatamente: il testo rivisto impone ai client di distinguere le due chiavi e di chiamare get_public_key dopo la connessione. Per la conversazione il client genera una propria coppia di chiavi e indirizza le sue richieste cifrate alla chiave del signer, mentre sign_event restituisce un event firmato con la chiave dell’utente. Le due chiavi possono coincidere, ma non devono farlo necessariamente. La chiave nella stringa di connessione identifica soltanto il servizio di firma. L’account dell’utente è la chiave pubblica restituita da get_public_key. Quattro giorni prima NIP-60 si era occupato dello stato condiviso del wallet; questa revisione affronta una questione distinta, l’identità del signer. Gli esempi presenti in quel commit usano ancora il trasporto cifrato che NIP-46 specificava all’epoca, e la modifica non rende trustless un signer remoto né dimostra chi detenga la chiave dell’utente.

Ottobre 2025: aggiornamenti alla collaborazione e metadati dei messaggi privati

L'8 ottobre, Nostr Wallet Connect di NIP-47 ha ottenuto i deep link per abbinare un’app a un wallet. Un wallet può registrare nostrnwc://connect o un nostrnwc+{app_name}://connect specifico dell’app, e l’app richiedente apre quel link passando la propria icona codificata come URI, il proprio nome e uno schema di callback. Una volta creata la connessione, il wallet apre la callback con un parametro value che contiene il codice di abbinamento, un URI nostr+walletconnect://. Tre anni dopo che Damus aveva passato le fatture a un wallet tramite iOS, l’abbinamento su un unico telefono non significava più per forza scansionare un codice QR mostrato sullo stesso schermo o copiare una lunga stringa da un’app all’altra. L’aggiunta riguarda soltanto questo passaggio di consegne. Non cambia alcun metodo di pagamento e da sola non paga nulla. Entrambe le app devono implementare i gestori, e il testo della specifica non prova che ogni wallet lo faccia. Né risolve le questioni dei budget di spesa, delle schermate di consenso o di quale app possa possedere in sicurezza uno schema di callback.

Il 16 ottobre, la collaborazione git di NIP-34 ha ottenuto gli event kind 1618 per le pull request e kind 1619 per gli aggiornamenti, accanto agli event di patch già esistenti. Una pull request indica la punta di un commit e le posizioni da cui clonare, e un aggiornamento sposta quella punta. Si raccomanda di mantenere le patch sotto i 60 kB, ricorrendo alle pull request per i contributi più grandi. Per questi ultimi il percorso raccomandato è così passato dai corpi delle patch trasportati dentro gli event a riferimenti firmati ai commit, mentre le modifiche più piccole possono ancora viaggiare come patch. Nostr veicola il coordinamento e i riferimenti firmati, e sono ancora i server Git a fornire gli oggetti commit a cui quei riferimenti puntano.

Il 27 ottobre, il gift wrap di NIP-59 ha ricevuto indicazioni per rendere casuali, in modo indipendente, i timestamp del seal e del gift wrap quando si aggiungono tag di scadenza. Il gift wrap racchiude un messaggio in questi due strati, e assegnare a ciascuno strato un proprio timestamp casuale riduce quanto strettamente si possano correlare le loro tempistiche. Qui l’attenzione si è spostata dalla cifratura dei contenuti alla limitazione di ciò che la correlazione dei metadati può rivelare. La cifratura nasconde il messaggio stesso, ma le tempistiche e gli altri metadati attorno alla busta restano osservabili, e sono le scelte implementative a decidere quanto facilmente possano essere collegati. Le indicazioni non aggiungono nuova cifratura e non rendono anonimi i partecipanti.

Ottobre 2026: significati condivisi delle query e servizi attivati dal testo

Il 5 ottobre, gli allegati multimediali di NIP-92 hanno esteso i tag imeta ai profili kind 0, consentendo a un profilo di descrivere i propri picture e banner con URL di fallback, un blurhash (una codifica compatta di un’anteprima sfocata), dimensioni, testo alternativo e altri metadati degli allegati. NIP-92 esisteva già prima di questa modifica; la novità è che i metadati raggruppati che NIP-71 aveva applicato alle varianti video nel 2024 arrivano ora alle immagini del profilo. L’associazione è esatta. Un tag si applica solo quando il suo URL coincide con l’URL della picture o del banner; i client dovrebbero (SHOULD) ignorare i tag che non corrispondono a nessuno dei due e dovrebbero (SHOULD) provare i fallback quando l’URL primario non funziona. Poiché un nuovo event kind 0 sostituisce il profilo precedente, chi pubblica dovrebbe (SHOULD) riportare i metadati di un’immagine rimasta invariata ed eliminare i tag delle immagini non più usate, così che testi alternativi o dimensioni obsoleti non finiscano per descrivere silenziosamente un’immagine diversa. Questa regola di aggiornamento conta quanto i nuovi campi. Un tag imeta non garantisce che un’immagine resti disponibile o si carichi più velocemente. Non offre nemmeno alcuna protezione della privacy, e i client non sono tenuti a visualizzare ogni campo.

Il 17 ottobre, NIP-01 è stato chiarito: una lista vuota in un filtro non corrisponde ad alcun event, il che è diverso dall’omettere l’attributo. Un intervento successivo ha rimosso l’incoerente formulazione «one or more» e ha raccomandato ai client di evitare l’invio di liste che non possono avere corrispondenze. Nell’ottobre 2021 questo documento aveva trovato un accordo sul framing JSON del messaggio REQ: il messaggio REQ è un array e ogni filtro è un oggetto JSON al suo interno. Quest’ottobre ha fissato la semantica dei filtri, stabilendo che cosa significhi una lista vuota all’interno di un filtro del genere, dato che relay capaci di analizzare lo stesso frame in modo identico potevano comunque restituire risultati diversi.

Il 21 ottobre, NIP-CD, allora intitolato Commands, è passato da proposta a bozza di specifica integrata; descrive gli slash command. I comandi sono definiti da event kind 31992, e un’invocazione è testo semplice che inizia dal primo carattere del contenuto di un event, quindi ai client non serve alcun supporto speciale per inviarla. Una proposta successiva, con un commit precedente su un branch separato, è stata integrata il 27 ottobre. Ha rinominato la specifica in Slash Commands e ha aggiunto liste facoltative kind 10992 dei comandi installati, che i client dovrebbero usare per l’autocompletamento e la visualizzazione. Le liste registrano una preferenza dell’utente e non autorizzano esecutori né condizionano l’invocazione in testo semplice. I job NIP-90 usano event strutturati di richiesta e di risultato, mentre un comando resta leggibile come testo ordinario.