Newsletter on Nostr Compass

Nostr Compass #42

Wed, 30 Sep 2026 00:00:00 +0000

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

La nostra app Android dedicata a Nostr Compass riunisce in un unico posto newsletter, episodi del podcast, guide tematiche e note vocali dei contributori. Le sue ultime note di rilascio firmate descrivono newsletter complete con firma verificata, numeri salvati e 110 guide tematiche disponibili offline, oltre alla ricerca locale tra articoli e trascrizioni disponibili. I contributori possono registrare note vocali e rispondere con esse, riascoltare una registrazione salvata prima di inviarla e firmare tramite Amber senza conservare la propria chiave privata nell’app. Le registrazioni pubbliche vengono pubblicate su Nostr e Blossom.

L’ultimo aggiornamento dell’app conserva le registrazioni in coda e i punti di ripresa dei caricamenti quando Android interrompe le attività in background, indica quando serve l’approvazione di Amber e apre la registrazione pertinente da una notifica. Le viste separate per episodi e note vocali mantengono ciascuna la propria posizione di scorrimento, mentre la riproduzione riprende dallo stesso punto. Le notifiche delle nuove registrazioni dipendono dalla pianificazione di Android e dalle autorizzazioni concesse.

Questa settimana: White Noise aggiunge sondaggi di gruppo crittografati e avvisi per la cronologia delle chat incompleta; Holoboard aggiunge comandi di promozione tramite messaggi privati e un’app Android; fips-pub-domains sperimenta nomi pubblici firmati su una mesh; Marmot MDK rende visibile la cronologia mancante dei gruppi crittografati; e Myco dota la condivisione di app tra dispositivi vicini di un’identità Nostr e di uno store. nostream adegua l’ammissione al relay in base al carico, mentre Nostr double ratchet chiude una falla legata ai membri rimossi. Lo sviluppo ripara l’interoperabilità dei gruppi crittografati di Amethyst, aggiunge i messaggi video crittografati di Divine e porta online Nostr Atlas. Gli aggiornamenti al protocollo perfezionano le prove di identità, gli inviti ai relay, i follow set e le rivendicazioni di dominio proposte. La retrospettiva di settembre di fine mese segue le stesse domande attraverso sei anni di Nostr.

Notizie principali

Holoboard aggiunge comandi di promozione Nostr e un’app Android

Holoboard è una bacheca per trovare note Nostr tramite una classifica che può essere potenziata con pagamenti Lightning. I post originali restano event Nostr; Holoboard fornisce i dati di classifica e di visualizzazione attraverso la propria API HTTP. La distinzione conta se un lettore si aspetta che l’ordinamento della bacheca sia un feed nativo dei relay.

Il suo changelog del 23 settembre registra comandi di promozione tramite messaggi diretti, sia sul percorso crittografato NIP-17 sia su quello legacy NIP-04. NIP-17 incapsula i messaggi privati per nasconderne contenuto e mittente ai relay, mentre NIP-04 è il formato di crittografia dei messaggi diretti più vecchio. Un utente può richiedere una fattura di promozione nella stessa conversazione, ricevere un preventivo etichettato per la prima promozione a pagamento e scegliere di ricevere promemoria di scadenza rispondendo YES. Il mittente delle promozioni riprova i relay che hanno fallito, mentre l’aggiornamento del 24 settembre aggiunge un’app Android e semplifica il flusso delle fatture.

Le note di integrazione con i relay del progetto descrivono note e commenti ordinari su Nostr, l’instradamento della inbox crittografata e la gestione di citazioni ed eliminazioni. La sua scheda Android firmata su Zapstore attesta l’esistenza di una release dell’app, ma non è stato stabilito che la chiave della scheda sia l’identità pubblica della bacheca di Holoboard. Questa è la prima copertura del progetto da parte di Compass.

fips-pub-domains sperimenta nomi pubblici firmati per una mesh

fips-pub-domains è un nuovo esperimento di resolver e di denominazione che associa nomi di dominio pubblici a nodi su FIPS, una mesh crittografata che usa messaggi Nostr per scoprire i peer. La sua prima release combina queste rivendicazioni con record DNS TXT, convalida DNSSEC opzionale, associazioni fissate localmente, un demone resolver per Linux e l’integrazione Android con fips2go, il client FIPS per telefoni. Una rivendicazione firmata da sola non dimostra la proprietà di un dominio pubblico; i client hanno bisogno di prove DNS o DNSSEC, di un testimone configurato o di un pin già considerato affidabile.

La release 0.2.0 aggiunge prove DNSSEC alle rivendicazioni, così che un client che dispone solo di un relay della mesh possa convalidare un nome non fissato, e consente a più server convalidati di servire lo stesso dominio. Ripara inoltre i pin obsoleti e il failover DNS. La versione 0.2.1 corregge una unit systemd che altrimenti non riusciva ad avviarsi ed esegue il server senza root; le installazioni esistenti devono sostituire quella unit per ricevere la correzione.

Su Android, una modifica integrata in fips2go segue nel proprio proxy DNS le associazioni verificate dei nomi pubblici. Una seconda modifica integrata trasporta sulla mesh le connessioni ai relay Nostr configurati, così il resolver può recuperare e verificare una rivendicazione di dominio mai vista prima mentre il telefono non ha connessione a internet. I risultati sui dispositivi sono riportati dai maintainer in quelle pull request; non dimostrano una diffusione più ampia.

I test a due nodi e con relay solo sulla mesh del progetto sono prove riportate dai maintainer per un’implementazione iniziale, non una distribuzione in produzione. NIP-DB resta una proposta aperta e i kind degli event nella sua bozza restano segnaposto in attesa di registrazione. La storia su fips2go della settimana scorsa riguardava il bootstrap della mesh e la scoperta dei peer; il lavoro di questa settimana affronta i nomi pubblici e la verifica.

Marmot MDK 0.11.0 rende visibili le lacune nella cronologia degli account

Marmot MDK, il runtime Rust con i binding generati per la messaggistica di gruppo Nostr crittografata con MLS, fa seguito alla release sull’invio durevole della settimana scorsa con la versione 0.11.0. Il ripristino dell’account ora dichiara completa una lacuna nella cronologia solo dopo che ogni relay richiesto ha terminato un confronto degli event non troncato; una lacuna non dimostrata produce un avviso durevole che l’host può mostrare all’utente. Una coda di consegna piena si riversa nel database dell’account invece di scartare gli event, e la consegna in tempo reale fa avanzare il cursore di trasporto, così un riavvio non recupera di nuovo la stessa cronologia.

Le note di rilascio complete descrivono anche sondaggi di gruppo crittografati opzionali, la verifica stateless degli event nei binding e librerie Android allineate per pagine di memoria da 16 KB. Le applicazioni devono aggiornare insieme i binding generati e le librerie native di questa coorte di sorgenti; i database degli account migrano fino allo schema 98 alla prima apertura e il downgrade del database non è supportato. Un difetto intermittente già noto nel recupero può ancora lasciare indecifrabili, senza generare un avviso, i messaggi rimasti indietro di più di cinque epoch di gruppo, quindi questa release non dichiara un ripristino completo della cronologia in ogni caso.

Myco 0.8.0–0.8.1 dà alle app condivise tra dispositivi vicini un proprio store Nostr

Myco è un’app Android per scambiare piccoli programmi Nostr, chiamati napplet, con telefoni vicini, anche quando sono offline. La versione 0.8.0 assegna a ogni installazione un’identità Nostr ospite e permette l’accesso con una chiave esistente o con Amber, un signer Android che approva le firme senza condividere la chiave dell’account. Sostituisce inoltre la scheda Discover con uno store di app che è esso stesso una napplet. Quello store legge schede di app e raccomandazioni firmate, mentre un aggiornamento scaricato può passare da un telefono all’altro all’interno della Circle di un utente senza connessione a internet.

La versione 0.8.1 rende quelle schede più facili da trovare interrogando i relay che un autore pubblicizza; le build precedenti si affidavano a impostazioni pubbliche predefinite. Mostra subito i profili e le app in cache, salva le risposte più lente dei relay per le visite successive, riduce la frequenza dei tentativi verso i relay che falliscono e mantiene attive le sottoscrizioni mentre una vista è aperta. Entrambi gli aggiornamenti preservano il formato di trasmissione esistente tra telefoni. I telefoni aggiornati possono scaricare e condividere gli aggiornamenti delle napplet; quelli più vecchi si limitano a inoltrarne gli annunci.

Release con tag

White Noise Android aggiunge sondaggi di gruppo e impostazioni predefinite per account sui messaggi a scomparsa

White Noise Android è un messenger Nostr per conversazioni private crittografate con Marmot. Dopo i miglioramenti alla consegna e alla condivisione trattati la settimana scorsa, la release del 30 settembre aggiunge, tramite il Marmot Development Kit, sondaggi di gruppo con risposte selezionabili, barre dei risultati e scadenze. Aggiunge inoltre impostazioni predefinite locali al dispositivo per i messaggi a scomparsa di ciascun account: le nuove conversazioni dirette e i nuovi gruppi ereditano la durata scelta, mentre le conversazioni esistenti e le loro impostazioni individuali mantengono la politica attuale. Wave hi invia un saluto che menziona un membro appena aggiunto senza toccare la bozza in corso.

La release consente agli utenti di scegliere il punto focale del ritaglio per le immagini di profilo e di gruppo e di eliminare una cartella di chat senza eliminarne le conversazioni. I suoi avvisi sulla cronologia mostrano quando il ripristino lascia potenzialmente incompleta la cronologia dell’account o del gruppo, con controlli di chiusura separati. La paginazione delle conversazioni evita di ricostruire la timeline visualizzata quando si salta ai messaggi recenti, e le modifiche ai messaggi in attesa conservano il proprio testo mentre l’invio originale ottiene l’ID event confermato. Questo passaggio delle modifiche copre i cambi di conversazione all’interno dell’app in esecuzione; non garantisce la persistenza in caso di terminazione del processo.

La dettatura ora sceglie Incolla o Invia per ogni registrazione, e la conclusione automatica inserisce la trascrizione nella bozza. La configurazione del provider offline spiega l’elaborazione sul dispositivo, mantiene il relativo consenso separato da quello degli altri provider vocali e ripristina i contenuti multimediali interrotti al termine dell’acquisizione. La gestione dei file generici accetta documenti non vuoti e di dimensione limitata, con nomi file, metadati MIME e messaggi di errore accurati; i download espliciti degli allegati usano i job di trasferimento avviati dall’utente di Android, con un fallback in primo piano. I controlli per incollare ora usano l’azione di sistema di Android, così Secure Paste di GrapheneOS può concedere l’accesso agli appunti. Android inoltre mostra come contenuti animati le condivisioni GIPHY provenienti da iOS, rispettando la politica di download.

Le correzioni alle notifiche aggiornano i soprannomi dei mittenti e ripuliscono gli avvisi quando si apre una conversazione. Le modifiche al ripristino delle notifiche preservano il lavoro push in sospeso quando il controllo in primo piano non è disponibile e usano tentativi limitati. La firma con Amber coordina le raffiche di approvazioni per lo stesso account, impedendo che i limiti di frequenza annullino gli invii. La nuova configurazione di audit chiede una nuova scelta sulla condivisione dei log prima di caricarli sul nuovo destinatario. Il codice sorgente adotta inoltre la licenza AGPL-3.0-only.

nostream 3.1.0 adegua la proof of work del relay al carico

nostream è un relay Nostr in TypeScript basato su PostgreSQL. La versione 3.1.0 può alzare o abbassare la soglia di proof of work degli event, entro limiti fissati dall’operatore, al variare della frequenza di event osservata. L’impostazione è disattivata per impostazione predefinita, usa la frequenza misurata da ciascun worker e lascia indipendente la soglia statica esistente per le chiavi pubbliche, quindi gli operatori devono attivarla esplicitamente prima che i mittenti vedano un requisito di ammissione diverso.

La stessa release aggiunge una dashboard di amministrazione con metriche su relay, WebSocket ed event, risultati delle sonde sullo stato della rete e notifiche configurabili per l’operatore. La sua API di amministrazione è disattivata per impostazione predefinita. Questi controlli aiutano gli operatori a distinguere i problemi di pressione sul relay da quelli di raggiungibilità, mantenendo la nuova politica soggetta a configurazione esplicita.

Dopo la release con proof of work sensibile al carico, nostream ha integrato azioni per le segnalazioni dei moderatori fidati. NIP-56 definisce gli event di segnalazione dei contenuti; la nuova opzione nip56.hideActionableReports esclude gli event segnalati dai risultati di REQ e COUNT quando anche le segnalazioni sono abilitate. La segnalazione di un event nasconde quell’event, mentre la segnalazione di una chiave pubblica nasconde tutti gli event di quell’autore. La nuova opzione è impostata a false per impostazione predefinita, quindi abilitare la sola raccolta delle segnalazioni lascia invariati i risultati delle query esistenti.

Nostr double ratchet 0.0.171–0.0.172 chiude una falla legata ai membri rimossi

Nostr double ratchet è una libreria TypeScript per chat private crittografate trasportate da Nostr. La versione 0.0.171 ruota la sender key di un gruppo dopo le modifiche ai membri, così chi è stato rimosso con le vecchie chiavi non può decifrare i messaggi successivi di un mittente aggiornato, anche dopo che quel mittente si è riavviato. Rifiuta inoltre gli invii o la rotazione delle chiavi da parte di un proprietario locale rimosso e interrompe un invio se i membri cambiano durante la distribuzione delle chiavi.

La versione 0.0.172 trasporta l’approvazione esistente del dispositivo, firmata dall’account, in una risposta di invito crittografata opzionale. Un destinatario che usa l’aggiornamento può verificare il dispositivo del mittente prima che arrivi un event di registrazione separato, mentre i dispositivi collegati mantengono la propria approvazione tra un riavvio e l’altro. Il campo dell’invito è opzionale e lascia intatti l’handshake originale e il formato dei messaggi del ratchet.

Le versioni 0.0.173–0.0.175 estendono il lavoro sulla rimozione con passaggi durevoli delle chiavi di gruppo e uno stato di consegna in coda salvato prima della pubblicazione, così i passaggi interrotti si recuperano dopo un riavvio. I callback di pubblicazione portano un contesto di gruppo locale che consente alle applicazioni di annullare i tentativi durevoli dopo una rimozione, mantenendo consegnabili i controlli sui membri; gli invii in coda preservano gli ID originali degli event interni. Le risposte duplicate agli inviti preservano le sessioni già stabilite, le sottoscrizioni restano stabili al variare dei contatti e gli snapshot delle chiavi delle app conservano i nomi dei dispositivi senza condividere copie modificabili. Il formato di trasmissione firmato resta invariato; le note della 0.0.173 riportano anche la versione Rust 0.0.168, con fallback sulle sessioni di ricezione e filtro locale degli echo di gruppo.

Scramble 0.7.4–0.7.5 recupera i messaggi che un nuovo membro del gruppo dovrebbe vedere

Scramble è un messenger di gruppo Marmot multipiattaforma con un’interfaccia Android nativa. Nella versione 0.7.5 ogni gruppo ha il proprio limite temporale per la cronologia dei relay: in precedenza il limite della conversazione più attiva veniva applicato a tutti i gruppi, quindi un gruppo appena raggiunto poteva restare vuoto perché i suoi messaggi successivi all’ingresso non venivano mai richiesti. Il percorso di riconnessione riceve la stessa correzione, e un gruppo senza attività locale ora richiede tutti i messaggi disponibili; MLS continua a impedire a un nuovo membro di decifrare i messaggi inviati prima del suo ingresso.

La precedente release 0.7.4 corregge l’accettazione ripetuta degli inviti causata dall’accumulo di gestori di clic nelle righe Android riciclate e rende persistente nell’app nativa l’impostazione di un server multimediale Blossom personalizzato. La versione 0.7.5 distribuisce solo l’APK Android nativo, quindi chi segue il vecchio nome file Avalonia deve cambiare la destinazione degli aggiornamenti. Account e cronologia passano tra queste due build Android, ma i gruppi creati con il vecchio motore MLS 0.6.x non migrano alla 0.7.x.

Scramble 0.7.6 aggiunge un controllo manuale Fetch missing messages che interroga ogni indirizzo di instradamento usato da un gruppo, rimuove il limite temporale, ripara un indirizzo salvato obsoleto e riferisce cosa ha recuperato. Non può comunque decifrare le epoch precedenti all’ingresso dell’utente. Gli amministratori nell’app nativa possono promuovere o retrocedere altri membri, con lo stato attuale dell’elenco dei membri e l’esito visibile degli errori; le conversazioni tra due persone continuano a nascondere questi controlli. L’azione Copia nelle informazioni del gruppo ora risponde, anche se le conversazioni a cui si è stati invitati possono ancora copiare un identificatore interno della chat invece dell’ID di gruppo del protocollo. La versione 0.7.7 inoltre smaltisce i messaggi trattenuti quando arriva il commit di un altro membro; la 0.7.8 aggiunge un test di regressione per quel percorso del membro passivo.

Amber 6.6.6 ripara i segreti di connessione del signer remoto

Amber è un signer Android che approva le firme degli event Nostr senza consegnare all’applicazione la chiave del suo account. Dopo la modifica alla crittografia dei backup della settimana scorsa, la versione 6.6.6 corregge il parser di nostrconnect: un parametro di connessione contenente =, come un segreto con padding, veniva alterato prima che Amber rispondesse. Per questo i client basati su NDK fallivano il controllo del segreto anche quando la connessione al signer sembrava per il resto valida.

La release invia inoltre le segnalazioni di feedback ai relay pubblicizzati dall’annuncio del repository di Amber, con un fallback sul relay precedente se l’annuncio non può essere recuperato. Timeout Tor più lunghi danno ai relay lenti più tempo per confermare quella pubblicazione. Le restanti modifiche migliorano la visibilità di icone e testo nei temi di Amber.

FIPS 0.5.2 blocca una fuga di privacy nella scoperta via Nostr

FIPS è una mesh crittografata che usa identità Nostr e messaggi dei relay per scoprire i peer. La sua release di manutenzione 0.5.2 smette di firmare le richieste di eliminazione per l’attraversamento NAT con la chiave di instradamento del nodo, che collegava quella chiave al traffico di attraversamento sui relay. Aggiorna inoltre la libreria TLS usata per le connessioni ai relay a una versione che corregge un avviso di sicurezza pubblicato e ripara diversi casi di messaggi persi durante il rekeying di collegamenti e sessioni.

Le note di rilascio invitano gli operatori di tutte le piattaforme ad aggiornare, descrivendo correzioni separate per i permessi del file di chiave su Windows, il gateway e il servizio dei pacchetti. I nodi effimeri non scrivono più un fips.key privato che un riavvio successivo potrebbe sovrascrivere; gli operatori che desideravano un’identità stabile devono impostare la modalità persistente prima di aggiornare. La release non cambia il formato di trasmissione della mesh, quindi i nodi con versioni diverse possono essere aggiornati singolarmente.

napplet soyLI 0.23.1–0.23.4 ripara la pubblicazione del backend e l’approvazione del signer

soyLI di napplet.soy è il toolkit di creazione e pubblicazione per piccoli programmi Nostr in sandbox. Dopo la release della settimana scorsa sulle creazioni condivise, la versione 0.23.1 include manifest, handler e schemi del backend nei controlli del creatore e nelle anteprime multigiocatore. Mantiene nel manifest del progetto la configurazione portabile dei provider, lasciando fuori dallo snapshot del codice pubblicato le associazioni di identità private e i database di sviluppo.

La versione 0.23.2 permette ai progetti che in passato avevano incluso nel repository un contesto di backend pubblico generato di pubblicare di nuovo dopo una convalida rigorosa, continuando a rifiutare associazioni private, journal, database e credenziali presenti nella cronologia raggiungibile. La successiva release 0.23.4 corregge un errore di sessione del backend persistente che poteva rifiutare un’approvazione valida dell’estensione o del signer remoto quando una persona impiegava diversi secondi a firmare. Anche gli host pubblici hanno bisogno della correzione dell’host condiviso; aggiornare solo la CLI di un creatore non ripara un host già distribuito.

Dart NDK 0.10.0 delimita l’autenticazione Blossom e la firma remota

Dart NDK è una libreria Flutter e Dart per l’accesso ai relay Nostr, la firma, le richieste ai wallet e le operazioni sui contenuti multimediali. Dopo la prerelease della settimana scorsa, la 0.10.0-dev.7 fa sì che le richieste multimediali Blossom restino anonime finché un server non le rifiuta, per poi autorizzarle tramite una politica esplicita che stabilisce quale identità un’operazione può rivelare. Porta quell’autorizzazione lungo tutto il percorso della richiesta e sostituisce le vecchie opzioni useAuth e customSigner, una modifica di integrazione incompatibile per le app che usano l’API della prerelease.

La dev.9 smette di trattenere la risposta di un signer remoto finché il relay più lento non la conferma. La dev.8 riduce il polling dei relay in background e il lavoro sulla cache; le sue altre correzioni riguardano la persistenza del seed del wallet e le scadenze di regolamento. La release stabile 0.10.0 ora raccoglie questa serie di sviluppo insieme alle modifiche ai metadati di connessione e agli ID di sottoscrizione privati descritte di seguito. Il confronto con la dev.9 include quelle modifiche integrate. Le applicazioni che aggiornano devono esaminare sia la modifica all’API di autenticazione multimediale sia il percorso di risposta del signer remoto.

La release stabile include metadati di connessione e permessi richiesti per NIP-46, che sostituiscono campi di connessione separati con un valore Nip46ClientMetadata. Si tratta di una modifica all’API sorgente che consente ai widget di login di passare al bunker l’identità dell’applicazione e i permessi richiesti. Un’altra modifica agli ID delle richieste usa in produzione 32 caratteri esadecimali casuali, tenendo i nomi dei casi d’uso e le fasi di paginazione fuori dagli ID di sottoscrizione visibili ai relay. Gli ID espliciti restano entro il limite di 64 caratteri di NIP-01, mentre la modalità di debug mantiene un breve nome diagnostico.

Mostro Core 0.16.0 rimuove il vecchio trasporto gift-wrap

Mostro Core fornisce il protocollo di messaggistica usato dai client di scambio peer-to-peer basati su Nostr di Mostro e dal suo coordinatore. La versione 0.16.0 rimuove il trasporto gift-wrap del protocollo v1 e le vecchie funzioni di wrap e unwrap, lasciando il trasporto più recente come percorso della libreria. È una modifica incompatibile per le applicazioni che costruiscono o leggono ancora messaggi v1 tramite questa libreria.

La release della libreria precede la release 0.19.0 del coordinatore, ora pubblicata. Gli operatori che servono client più vecchi devono aggiornare entrambi i lati della migrazione del trasporto. Il precedente tag 0.15.1 aggiunge uno stato di disputa per la cancellazione cooperativa, ma è la rimozione del trasporto a segnare il passaggio di compatibilità.

Cambium 0.6.0–0.7.1 registra un telefono di sblocco tramite messaggi dei relay

Cambium è un’app Android di supporto alla firma per una chiave hardware Heartwood, che può anche sbloccare la scheda dopo un riavvio. La versione 0.6.0 consente a un telefono di registrarsi per lo sblocco attraverso i relay Nostr della scheda senza cavo USB; l’utente confronta cinque parole di richiesta sul telefono, sulla scheda e su Sapwood, l’interfaccia di registrazione della scheda, prima di premere il pulsante della scheda. I relay appena annunciati ricevono un ritardo di connessione casuale, così il primo contatto del telefono non rivela esattamente quando ha visto l’aggiornamento della scheda.

La versione 0.7.0 inverte il flusso dell’invito: un telefono scansiona il codice QR a breve scadenza di Sapwood e restituisce un unico event crittografato e monouso da una chiave usa e getta. Il nuovo tentativo ripubblica lo stesso event se nessun relay lo accetta, mentre il vecchio percorso con visualizzazione del codice resta disponibile per le build più vecchie di Sapwood. La patch 0.7.1 mantiene visibile il codice di verifica finale e migliora la riproducibilità della build per F-Droid; il flusso con QR richiede comunque le versioni recenti di Sapwood e Heartwood indicate.

Bray 3.5.0–3.5.2 limita la spesa del wallet Nostr avviata dagli agenti

Bray è un server di strumenti Nostr che consente a un assistente IA di richiedere azioni su relay, identità e wallet attraverso un’interfaccia delimitata. La sua release 3.5.0 aggiunge un limite per ogni pagamento Nostr Wallet Connect e un budget giornaliero persistente, con conferma umana dove l’host dell’assistente la supporta. Servire connessioni di spesa separate ora richiede un’impostazione esplicita del servizio wallet, ricontrolla ogni autorizzazione prima dell’uso e limita le ricerche di fatture agli hash compresi in quell’autorizzazione.

La release indica inoltre agli utenti di conservare l’URI di connessione del wallet in un file privato invece di incollarlo in chat, e si rifiuta di ritentare un pagamento dall’esito incerto come se il fallimento fosse dimostrato. La versione 3.5.2 confronta localmente i metodi di pagamento del marketplace dopo che i relay avevano rifiutato il filtro richiesto sul metodo di pagamento. Questi controlli limitano ciò che un assistente delegato può spendere e impediscono che un’ipotesi sui filtri dei relay nasconda le offerte corrispondenti.

Mafrend 1.3.0-alpha porta i gruppi privati sulla mappa alla versione attuale di Marmot

Mafrend è un’app social Nostr basata su mappe che permette di esplorare luoghi e chattare attorno alle destinazioni. La sua release 1.3.0-alpha aggiorna i gruppi privati a una specifica più recente dei gruppi crittografati Marmot e aggiunge la visualizzazione dei profili da chat e recensioni. Il formato dei gruppi è incompatibile con le chat delle alpha precedenti; gli utenti devono considerare questa release una migrazione alpha con un’interruzione di compatibilità.

La stessa release aggiunge la condivisione di screenshot e modifiche alla chat, insieme a miglioramenti della mappa e dei marcatori. Le funzioni del profilo sono ancora indicate come in lavorazione dal progetto. La modifica rilevante per Nostr è il cambiamento di interoperabilità dei gruppi privati; chi ha vecchi gruppi di prova deve leggere la nota di compatibilità prima di aggiornare.

Sonar alpha.15–alpha.15.1 ripara la pubblicazione nei gruppi crittografati

Sonar è un messenger privato che può trasportare le conversazioni su mesh Bluetooth e su Nostr. La alpha.15 aggiunge le reazioni con emoji ai messaggi e la condivisione privata dell’ora locale all’interno delle chat crittografate, con un’impostazione per revocare tale condivisione. Il suo wallet passa a Cashu, ma questa modifica ai pagamenti è separata dall’aggiornamento della messaggistica.

La alpha.15.1 ripara un errore all’avvio che poteva lasciare vuoto l’indice delle conversazioni dopo che una build di un ramo precedente aveva scritto una versione di schema estranea. Senza l’indice, l’app ricifrava e ripubblicava le condivisioni dell’ora locale verso ogni gruppo a ogni riapertura, inviando a volte centinaia di event prima che intervenissero i limiti di frequenza dei relay. La correzione urgente ricostruisce quello stato locale e interrompe le pubblicazioni ripetute nei gruppi.

I pacchetti commerce di Elisym introducono ordini Nostr privati

Elisym è un toolkit per agenti basato su Nostr che ora sta costruendo un flusso di commercio basato su event firmati. Il suo pacchetto commerce integrato definisce prodotti del negozio, autorizzazione del proprietario, ordini e ricevute incapsulati privatamente e la verifica delle offerte per i componenti di checkout e del commerciante. Un successivo tag commerce 0.2.0 deriva il riferimento di pagamento di un ordine dall’ordine stesso, legando la ricerca del pagamento al flusso di acquisto firmato.

La serie di pacchetti introduce anche lavori separati sul nucleo dei pagamenti e sul checkout nel browser, ma i suoi tag di release non dimostrano che sia stato distribuito un checkout completo per i commercianti. Il kind dell’event di autorizzazione del negozio è esplicitamente provvisorio nella fonte primaria del progetto. Gli undici tag di SDK, MCP, CLI e nucleo dei pagamenti segnano un’unica funzionalità di commercio in sviluppo.

Le nuove release dei pacchetti di Elisym impacchettano il nodo commerciante self-hosted, mentre MCP 0.31.0 aggiunge buy_product e get_order per i prodotti commerciali. Le successive release di commerce e del nodo commerciante aggiungono il supporto ai pagamenti Tempo all’interno dello stesso checkout. Questi pacchetti fanno avanzare l’integrazione esistente tra prodotti firmati e ordini privati; l’elenco dei tag non trasforma lo schema provvisorio degli event in uno standard né dimostra il lancio completo di un servizio ospitato.

Flotilla 1.11.2 sblocca i signer e i feed dei relay incompleti

Flotilla è un client Nostr per conversazioni, stanze e spazi condivisi. La versione 1.11.2 offre all’utente una via d’uscita quando l’avvio si blocca in attesa di un signer remoto e disconnette una sessione i cui dati locali dell’applicazione sono stati cancellati. Una stanza ora può mostrare i propri messaggi prima che lo spazio più ampio a cui appartiene finisca la sincronizzazione, mentre i feed non omettono più dei post solo perché un relay ha risposto più tardi di un altro.

La stessa release pubblica anche una build per F-Droid firmata con la chiave esistente dell’app e mantiene aggiornate le release su GitHub per Obtainium. Questo lavoro di distribuzione interessa chi cambia canale di aggiornamento, ma le correzioni a relay e signer sono il motivo immediato per aggiornare.

Ditto 2.42.3 mostra la consegna ai relay e rafforza i confini tra account

Ditto è un client social Nostr che consente agli utenti di scegliere i propri relay e di autenticarsi su di essi. Nella versione 2.42.3, i Dettagli dell’event di un post mostrano quali relay dell’utente e dell’autore lo contengono; Broadcast si rivolge solo a quelli mancanti. La release segnala inoltre i relay di lettura che non rispondono e offre un controllo per ritentare, rendendo più facile diagnosticare un post mancante senza inviarlo di nuovo ovunque.

Le note di rilascio dicono che cambiare account non invia più post ai relay dell’account precedente, che gli utenti silenziati non possono attivare avvisi generici sul telefono e che link o immagini nei post non possono raggiungere dispositivi sulla rete locale del lettore. I post provenienti da relay lenti non scompaiono più dai feed Follows e Loved, mentre la chat delle dirette e i giochi webxdc si aggiornano senza scaricare ripetutamente l’intera vista. Anche la navigazione di torrent e audio è nuova, ma l’instradamento verso i relay e l’isolamento degli account sono le modifiche con l’impatto più ampio su Nostr.

Iris Chat 2026.9.24.4 porta le chiamate nelle conversazioni crittografate

Iris Chat è un messenger Nostr crittografato end-to-end che usa la famiglia di protocolli di chat double ratchet. La sua release del 24 settembre aggiunge chiamate vocali e video con i contatti compatibili, anche su una connessione locale già esistente quando internet non è disponibile. Un utente può ridurre la qualità video, rispondere a una videochiamata solo in voce e gestire una chiamata in arrivo tramite l’interfaccia di chiamata di Android; rispondere o rifiutare fa anche smettere di squillare gli altri dispositivi collegati.

La release consente inoltre di accedere tramite un’app di firma separata e di vedere quali dispositivi collegati sono connessi. Le patch successive del 24 settembre conservano i timestamp originali dei messaggi in ritardo e migliorano la consegna ravvicinata dopo la perdita di un pacchetto di riconnessione. Si tratta di comportamenti iniziali per chiamate e dispositivi multipli, quindi l’aggiornamento è più utile ai contatti che possono usare build compatibili di Iris.

Il successivo aggiornamento del 30 settembre firmato dallo sviluppatore conserva la cronologia locale del gruppo di un membro rimosso disabilitandone gli invii, migliora la consegna tra dispositivi collegati e nei gruppi grandi e ripara gli indicatori di lettura e i contatori dei non letti. Le chiamate ottengono la selezione del dispositivo audio e il ripristino dei toni in uscita; uno stato del microfono obsoleto non silenzia più l’audio in arrivo. Il silenziamento temporizzato, la copia delle immagini, gli allegati trascinati, l’instradamento delle notifiche e la registrazione push ricevono correzioni, mentre la disconnessione cancella le cache locali e la rimozione di un dispositivo ne termina la sessione. Un secondo aggiornamento migliora l’accesso ai file messi in cache da altre app Iris sullo stesso dispositivo e mantiene disponibile la condivisione locale dei file con Nearby disattivato.

LibreNostr 0.6.0–0.7.0 instrada i relay attraverso Tor integrato

LibreNostr è un client Nostr per Android con impostazioni configurabili per relay e privacy. La versione 0.6.0 integra un motore Tor basato su Arti per ARM64 e applica la modalità scelta, Direct, Tor per tutto o solo .onion, a WebSocket dei relay, richieste HTTP, contenuti multimediali, caricamenti e pagine web. La modalità Tor rigorosa si blocca in modo sicuro quando Tor non è disponibile e non invia mai silenziosamente una richiesta in modo diretto; cambiare modalità riconnette i socket dei relay attraverso il nuovo percorso.

La versione 0.6.2 aggiunge un filtro web-of-trust sul dispositivo costruito a partire dalle liste di follow pubbliche e sceglie i relay supplementari in base alle persone seguite aggiuntive che permettono di raggiungere. La versione 0.7.0 mostra poi note e notifiche prima che finiscano le ricerche di profili e conteggi, limita le query lente ai relay e smette di decifrare l’intera inbox dei DM a ogni apertura di conversazione. Insieme, queste release cambiano sia dove il client può connettersi sia per quanto tempo un relay lento può bloccarne l’interfaccia.

La sua prima release stabile, la 1.0.0, firmata dallo sviluppatore, aggiunge deck per tablet salvati per ciascun profilo, con colonne spostabili per feed, hashtag, profili, lettura di contenuti lunghi, notifiche e messaggi. I tablet in orizzontale ottengono questo layout; i telefoni mantengono l’interfaccia esistente. La ricerca guadagna OR, esclusioni, filtri per contenuti multimediali e intervalli di date funzionanti, restituisce i profili in cache prima dei perfezionamenti dei relay e passa subito oltre le richieste full-text rifiutate. Gli hashtag sono ordinati cronologicamente, la paginazione attende un numero sufficiente di risposte dei relay e i feed inutilizzati rilasciano le proprie sottoscrizioni.

La stessa release preserva durante le modifiche le voci pubbliche e crittografate esistenti nelle mute list e nei segnalibri, invece di sostituirle con una singola modifica. Isola segnalibri e notifiche tra account e limita i relay ausiliari degli autori alle letture pubbliche, tenendo lontane da essi le richieste private e l’autenticazione ai relay. Impedisce inoltre che risposte di profilo obsolete sostituiscano metadati più recenti, ripara la paginazione e i badge delle notifiche, conserva gli elementi più vecchi del feed quando ne arrivano di nuovi e corregge i conti alla rovescia per annullare le risposte, la pubblicazione duplicata, gli URL dei contenuti multimediali con query string e i contatori dei non letti dopo aver segnato una chat come letta. La versione 1.0.1 corregge un crash all’avvio del deck per tablet nel nuovo layout.

Newlay 0.3.45 trasmette in streaming le query di grandi dimensioni invece di chiuderle

Newlay è un relay Nostr ospitato su Android con servizi locali correlati. Il suo annuncio firmato della release 0.3.45 afferma che i risultati delle query di grandi dimensioni ora vengono trasmessi in streaming con backpressure invece di chiudere la connessione del client. L’host Git integrato elimina i pack superati dopo i push, mentre il suo coordinatore di messaggistica crittografata Cordn accetta richieste dei client sovradimensionate e invia un frame di interruzione quando una sonda va in timeout.

La release offre inoltre all’operatore Android una scheda di stato in tempo reale per event, spazio di archiviazione, indirizzo e amministrazione, e allinea la libreria crittografica nativa per i dispositivi con pagine di memoria da 16 KB. Le modifiche al relay e al coordinatore coprono diverse release successive alla precedente versione nello store, la 0.3.39; la 0.3.45 ne è il punto di riferimento pacchettizzato.

ngit-grasp 3.0.5 mantiene in movimento i push Git e la sincronizzazione dei relay

ngit-grasp è un relay Nostr e server Git self-hosted per la collaborazione firmata sui repository. Il suo annuncio firmato della release 3.0.5 sposta la lenta riconciliazione della cronologia fuori dall’attore condiviso di sincronizzazione in tempo reale, consentendo alle sottoscrizioni ai relay di partire mentre gli event precedenti vengono controllati. Applica attese separate per i limiti di frequenza, le query incomplete sulla cronologia, le letture delle mailbox e le ricerche di identità, così un relay malfunzionante non monopolizza più la capacità di ritentare.

La stessa release esegue la riconciliazione rispetto all’inventario locale degli event per evitare di recuperare di nuovo la cronologia già memorizzata e chiude le sottoscrizioni incomplete prima di considerarne verificata la copertura. Sul lato Git, accetta i push che la promozione dello stato in background ha già applicato, mantiene la protezione dai conflitti per i ref modificati e smaltisce l’output di avanzamento di Git durante i caricamenti per evitare un push bloccato. Questi dettagli contano perché un repository può apparire attivo sui relay mentre il suo trasferimento Git è ancora in attesa di un risultato definitivo.

Armada 0.63.0 porta gli avvisi push su tutti i tipi di signer

Armada è un client Nostr per comunità crittografate, canali e messaggi diretti. Dopo la release sulla privacy dei contenuti multimediali della settimana scorsa, il suo annuncio firmato della 0.63.0 descrive un nuovo percorso push del browser che funziona ad app chiusa per gli accessi tramite estensione e signer remoto, oltre che per gli altri tipi di account. Anche Tenna, un’app host che incorpora Armada, ottiene le notifiche in background per i propri utenti.

La release carica più rapidamente i messaggi più vecchi nei canali lunghi delle comunità ed evita di rileggere l’intera cronologia per i nuovi messaggi. Gli indicatori di digitazione nei messaggi diretti usano meno connessioni ai relay. Gli aggiornamenti desktop ottengono un invito al riavvio, mentre gli aggiornamenti diretti da versioni precedenti alla 0.50.0 non sono più supportati.

Il successivo aggiornamento firmato 0.63.1 aggiunge pacchetti di emoji modificabili con importazione da cartella e riordinamento, recupera i messaggi citati oltre la cronologia caricata e rende interoperabili le risposte ospitate sui relay. Riduce il traffico di riconnessione su Android, recupera dopo lunghe disconnessioni senza ripetere vecchi avvisi, esclude le menzioni precedenti all’ingresso e preserva i campi di gruppo non modificati e le voci private dell’elenco dei server. Le eliminazioni nei gruppi ospitati sui relay ora richiedono l’autore del messaggio o un amministratore. Ricevono correzioni anche il trascinamento dei server, la gestione di informazioni dei relay malformate e le sottoscrizioni ai repository.

La versione 0.63.2 estende il Markdown dei messaggi a citazioni ed elenchi annidati, righe orizzontali, blocchi di codice, intestazioni sottolineate e formattazione che attraversa link o menzioni. I link alle pagine di Tenor e Giphy vengono riprodotti come GIF. La sincronizzazione dello stato di lettura trasferisce meno dati, la riconnessione evita download e accessi ridondanti, e le notifiche in background su Android sospendono la sincronizzazione dei relay quando grandi aggiornamenti delle impostazioni la sovraccaricano.

deed 0.3.0–0.3.2 rende più stabile la pubblicazione Nostr in Zig

deed è uno strumento a riga di comando in Zig per leggere e pubblicare event Nostr. La sua versione 0.3.2 del 24 settembre aggiunge una skill per agenti e corregge le scadenze dei ping ai relay; le precedenti release 0.3.1 e 0.3.0 migliorano prestazioni e affidabilità della pubblicazione. I tre tag descrivono un’unica serie iniziale dello strumento. Il beneficio visibile per Nostr è una connessione ai relay e un percorso di pubblicazione degli event più stabili per gli script che usano la CLI.

Cordn 0.5.1 fa proseguire gli altri gruppi quando un coordinatore fallisce

Cordn è un messenger di gruppo crittografato con MLS che usa identità e relay Nostr per individuare i coordinatori delle conversazioni. La sua release firmata 0.5.1 del client fa seguito al lavoro sulla coda offline della settimana scorsa separando la pianificazione del coordinatore da quella dell’outbox: un coordinatore non disponibile non ritarda più gli invii verso gruppi non correlati. Gli hint dei relay risolti persistono dopo la scoperta, i documenti di gruppo li trasportano tra dispositivi e un record durevole delle pubblicazioni in sospeso recupera gli invii rimasti bloccati. Il ripristino su più dispositivi sovrappone le query sulla catena della cronologia e sulle lacune mentre legge la configurazione attuale.

La release aggiunge inoltre allegati trascinati, gruppi fissati, nomi di profilo nelle anteprime e nelle notifiche ed etichette per i coordinatori. Ripara il posizionamento sul primo messaggio non letto, i contatori dei non letti, gli avvisi duplicati, le anteprime di contenuti multimediali e messaggi di sistema, le risposte collegate a contenuti multimediali con didascalia e i controlli di zoom delle immagini. I download nativi usano un selettore Salva con nome. Un signer che compare in ritardo non provoca più un falso avviso di crittografia non supportata, e il cambio di account non entra più in conflitto con il seeding in background.

Nymbot è un assistente raggiungibile tramite messaggi Nostr crittografati e gift-wrapped. La sua release 1.0.7 firmata dallo sviluppatore legge i documenti sul dispositivo, seleziona i passaggi pertinenti quando un file è troppo grande per essere inviato per intero e indica le pagine utilizzate. Le conversazioni possono essere condivise tramite un link crittografato end-to-end il cui accesso può essere revocato in seguito. Le risposte in Python e JavaScript possono essere eseguite localmente, con l’output restituito alla conversazione.

La stessa release aggiunge ricerche con fonti e prezzo mostrato prima dell’invio, modifica delle immagini, selezione del modello per singolo messaggio e limiti di spesa per chat e per bot. Gli strumenti esterni collegati tramite MCP chiedono conferma prima di modificare dati. Le esecuzioni sui repository possono mettere in pausa le modifiche per la revisione, mostrare i risultati della CI e riprendere dopo un gateway occupato. Risposte suggerite, avvisi fissati, elenchi di fonti compressi e un selettore di modelli con ricerca completano l’aggiornamento; queste affermazioni provengono dalle note di rilascio dello sviluppatore; Compass non ha verificato in modo indipendente la privacy dell’app.

0xchat 1.5.6 distribuisce le correzioni per firma e autenticazione dei messaggi

0xchat è un messenger Nostr con chat private, firma esterna e funzioni di wallet. La versione 1.5.6 distribuisce le correzioni di sicurezza trattate la settimana scorsa come modifiche integrate nel sorgente, tra cui l’autenticazione dei gift wrap, la configurazione dell’infrastruttura fidata e il consenso per la firma da pagine incorporate. Chiude inoltre i percorsi di aggiramento del proxy Tor, convalida i certificati TLS per gli host non onion e impedisce alle build di release di scrivere sulla console del dispositivo credenziali e materiale del wallet potenzialmente sensibili. I log per sviluppatori, attivabili su richiesta, continuano a registrare gli errori.

La release distanzia le riconnessioni ai relay da tre secondi fino a cinque minuti, ripara le sottoscrizioni dopo la riconnessione e consegna le richieste accodate mentre un relay si sta connettendo. I cambi di account non accumulano più listener duplicati sui relay, un accesso fallito preserva l’account già attivo e le connessioni ai signer esterni persistono tra un avvio e l’altro. Gli invii falliti ora mostrano errori e conservano il testo non inviato o lo stato recuperabile della condivisione di token. La decifratura delle chiavi all’avvio e il calcolo degli hash dei caricamenti escono dal thread dell’interfaccia; le cache di chat e video evitano rendering e download ripetuti. La release fornisce asset per Android e desktop con checksum SHA-256, tra cui l’APK Android firmato da Play e un installer Windows compilato dal sorgente.

Nostr Mail Client 0.17.0 nasconde ai relay le azioni sulla casella di posta

Nostr Mail Client scambia email tramite Nostr pur supportando la consegna email convenzionale. Dopo la release della settimana scorsa sul trasporto per destinatario e sulla privacy dei contenuti multimediali, la versione 0.17.0 nasconde ai relay lo stato di lettura, archiviazione, cartelle ed etichette e le relative tempistiche, e permette agli utenti di eliminare la posta senza avvisarne il mittente. La release richiede di aggiornare insieme tutti i dispositivi, perché i client più vecchi non vedono il nuovo stato né le eliminazioni. Protegge inoltre i destinatari in Ccn nei messaggi più grandi di 32 KB, tiene gli alias locali dei contatti fuori dai messaggi in uscita, ripara l’accesso tramite QR con Amber e pubblica la posta pubblica sui relay di lettura dei destinatari.

La release aggiunge cartelle ed etichette colorate con regole per mittente, oggetto e allegati; citazioni in risposta e inoltro; immagini incollate in linea; anteprime e rinomina degli allegati; e selezione di intervalli negli elenchi della posta. L’inoltro conserva le immagini e gli allegati originali, le citazioni nelle risposte partono compresse e l’editor web ottiene un menu contestuale. Le tabelle HTML e le immagini in linea vengono visualizzate in modo più accurato, i link in testo semplice funzionano e la programmazione supporta date fino a cinque anni nel futuro. Nomi e immagini della rubrica compaiono in tutta l’interfaccia, e i colori del tema offrono tavolozze di sistema, suggerite o personalizzate.

La stessa release mantiene locali gli sfondi selezionati da file e mette in cache gli sfondi collegati, con un costo di migrazione esplicito: sulle piattaforme native, i vecchi sfondi da file devono essere aggiunti di nuovo. Cambia le raccomandazioni predefinite per relay e contenuti multimediali, aggiunge la scoperta di app Nostr durante l’onboarding e negli avvisi di aggiornamento, preserva le impostazioni sconosciute scritte da altri client e ripara la creazione interrotta dell’archivio della posta e il packaging per Linux. Gli errori all’avvio ora mostrano i dettagli e una segnalazione precompilata invece di una schermata vuota.

Nostr WoT 0.8.7 lega l’autenticazione alla destinazione

Nostr WoT è un’estensione del browser che combina la firma Nostr con strumenti di fiducia. La versione 0.8.7 richiede il consenso per l’autenticazione HTTP firmata NIP-98 rispetto a URL esatto, query, metodo, account e origine richiedente. Le vecchie approvazioni generiche richiedono un nuovo consenso. L’autenticazione ai relay NIP-42 ha un sistema di permessi separato legato all’account, in cui i rifiuti specifici per sito prevalgono sulle autorizzazioni condivise per i relay. Le richieste di autenticazione devono provenire da un’origine di primo livello del browser verificata, e le attese per approvazione o sblocco attivano un ulteriore controllo su account e accesso.

La release verifica le firme remote NIP-46 e l’intero event approvato, così una firma restituita non può sostituire silenziosamente il contenuto o una destinazione. La configurazione del wallet e le modifiche all’indirizzo usano un’autenticazione legata al corpo della richiesta, challenge del backend monouso e token di transazione separati; la firma generica per i siti web non può generare quei token interni del wallet. Il backend compatibile deve essere distribuito per primo, e il client rifiuta di tornare agli endpoint dismessi. Anche i pagamenti Nostr Wallet Connect verificano la preimage di pagamento restituita rispetto all’hash della fattura richiesta e trattano una mancata corrispondenza come esito sconosciuto.

Nell’interfaccia delle richieste, gli utenti possono esaminare gli event grezzi completi, scegliere richieste specifiche all’interno di un gruppo per sito e visualizzare localmente i messaggi privati senza approvarne la restituzione a un sito web. Le anteprime locali si nascondono dopo 30 secondi; le richieste in arrivo restano non selezionate e l’approvazione in blocco ordinaria esclude l’autenticazione. L’estensione separa le autorizzazioni ai relay per singolo sito e per tutti i siti, limita la cache dei profili verificati, risolve gli event sostituibili con timestamp uguale a favore dell’ID event più basso e mantiene locali le letture per la pubblicazione dal popup principale. Chrome e Firefox ricevono pacchetti verificati separatamente e flussi serializzati di invio delle release stabili; questi flussi non dimostrano la disponibilità attuale negli store.

Il runtime condiviso di Iris mantiene coerente la cronologia di relay e peer

nostr-pubsub fornisce un runtime condiviso per gli event Nostr con archiviazione persistente degli event e una coda di pubblicazione in uscita. Le versioni 0.5.7–0.5.13 raggruppano le sottoscrizioni esatte, le ripetono dopo la riconnessione, mantengono distinte le prove locali, dei relay e dei peer e segnalano una cronologia incompleta quando l’archiviazione durevole fallisce. Le query completate attendono che ogni event ricevuto termini l’ammissione. Il batch predefinito verso i relay ora contiene al massimo 20 filtri OR per compatibilità con i server più comuni, mentre i batch verso i peer mantengono corrispondenza e annullamento indipendenti.

Gli aggiornamenti del runtime di Hashtree sostituiscono la rete specifica dei worker con quel runtime condiviso, indici persistenti degli event e una coda in uscita, consentendo a event e file in cache di condividere un unico nodo FIPS. FIPS TypeScript 0.0.44–0.0.45 seleziona percorsi con capacità sufficiente per record di segnalazione completi, recupera le configurazioni di sessione perse entro la scadenza dell’handshake e ritenta le risposte WebRTC solo dopo un rifiuto esplicito di instradamento. I percorsi WebSocket con frame più grandi richiedono peer nativi compatibili; le note della 0.0.44 richiedono di distribuire prima FIPS nativo 0.4.85.

Iris Kit 0.2.5 aggiunge un client applicativo persistente per event semplici e la firma NIP-46 indipendente dal trasporto, preservando le chiavi dell’account e le letture offline. La versione 0.2.6 restituisce immediatamente dal worker o dal backend nativo un ID event completo già verificato; le query per prefisso e per event sostituibili attendono comunque la cronologia prima di scegliere il valore più recente. Sono release di librerie, e le note non dimostrano la distribuzione in ogni applicazione Iris.

L’aggiornamento del sorgente di Iris Meet del 30 settembre sostituisce la sua integrazione NDK con un’infrastruttura publish/subscribe persistente e signer di identità condivisi. La patch aggiunge copertura per il ripristino offline dell’identità, la firma NIP-07 e l’isolamento delle stanze delle riunioni. L’app per riunioni esistente usa Nostr per la segnalazione crittografata e WebRTC per audio e video. Si tratta di avanzamenti dell’implementazione sul ramo predefinito; il repository non ha una release con tag che dimostri che questo specifico aggiornamento abbia raggiunto il sito attivo.

Chama propaga l’annullamento degli annunci e gli avvisi in background

Chama usa event firmati per il commercio comunitario e le conversazioni private. Le versioni 6.4.14–6.4.16 pubblicano un annullamento firmato prima di eliminare localmente un annuncio, così gli altri client possono ritirare la stessa offerta in cache. I tag di risveglio del destinatario ora accompagnano gli event indipendentemente dall’impostazione di notifica del mittente, e il server degli avvisi deduplica in base all’event firmato, così una chat subito dopo un ingresso può comunque attivare un risveglio. I job in background ripetono gli scambi interessati a partire dai cursori salvati, isolano le catene fallite e decifrano localmente il testo delle notifiche; la release richiede di ridistribuire il watcher associato.

Le release raggruppate applicano inoltre i rinnovi dei partecipanti agli orari dei rispettivi event firmati, mettono in quarantena i blocchi di finanziamento effettuati dopo la scadenza di un posto ed espongono il recupero della bearer note salvata. La pubblicazione delle richieste attende la conferma dell’importazione o del pagamento. I filtri degli annunci preservano la valuta di chi guarda tra i diversi ambiti della comunità, e le intestazioni degli scambi usano l’importo di adesione definitivo. Queste modifiche allineano ciò che due client collegati a Nostr deducono dalla stessa cronologia di event.

Earthly 0.1.12 aggiunge configurazioni di mappa riutilizzabili

Earthly è un editor di mappe collaborativo su Nostr con pubblicazione firmata e condivisione crittografata. La versione 0.1.12 aggiunge configurazioni GMapper riutilizzabili per le Google My Maps pubbliche, la scoperta di Maplet create dagli sviluppatori, l’archiviazione privata o la pubblicazione pubblica delle configurazioni e la copia di geometrie con attribuzione. La stessa release aggiunge la condivisione crittografata delle connessioni, l’aggiunta di entità tramite trascinamento e la navigazione della chat su mobile. La disponibilità dell’esportazione di Google e il CORS del browser limitano l’importazione, le Maplet scaricate eseguibili restano non disponibili in Tauri e le verifiche di aggiornamento su dispositivi Android fisici sono ancora in sospeso.

Il lavoro sulle configurazioni ha migrato gli indirizzi di pubblicazione e le preferenze esistenti e ha aggiunto la revisione o il ritiro degli aggiornamenti di configurazione. Il suo flusso Android iniziale falliva prima della compilazione; una correzione degli strumenti ha preparato la release poi pubblicata con tag.

Mostro 0.19.0 dismette il trasporto di prima generazione

Mostro coordina scambi peer-to-peer su Nostr. La versione 0.19.0 ora include la rimozione del trasporto gift-wrap di prima generazione, quindi i client devono usare il protocollo più recente. I tag di timestamp esistenti per la creazione degli ordini e l’apertura delle dispute vengono rinominati published_at senza cambiare i valori memorizzati; il created_at dell’event che li contiene resta l’orario della firma. Le risposte di ripristino restituiscono la trade key della controparte, le operazioni di creazione e accettazione andate a buon fine riconoscono le trade key e la pubblicazione sui relay si completa alla prima conferma positiva di un relay. La stessa release aggiorna scadenze e annullamento dei bond, chiude le dispute quando uno scambio si risolve, avvisa chi le risolve e limita l’obsolescenza dei prezzi inoltrati.

La correzione dell’ammissione delle trade key di Mostro riconosce una chiave non appena viene registrato un ordine o una disputa che la introduce. I nodi con una proof of work più severa per il primo contatto in precedenza potevano scartare un messaggio di seguito legittimo fino al successivo aggiornamento periodico delle chiavi note; le soglie uguali predefinite non erano interessate. Una transazione per le dispute registra atomicamente la transizione dell’ordine e la riga della disputa, eliminando gli errori dovuti a stati incoerenti. Le notifiche di chiusura inviano a chi è stato assegnato alla risoluzione un messaggio privato, al meglio delle possibilità, quando gli utenti risolvono una disputa, mentre l’event sostituibile esistente resta il fallback offline.

SCRUTINY Lens porta la ricerca sulla sicurezza su Nostr

SCRUTINY Lens v0.1.0, la sua prima release pubblica del 29 settembre, è un client per browser per i metadati di sicurezza pubblicati tramite Nostr. Gli analisti possono cercare per CVE o per identificatori di pacchetti o certificati, esaminare la cronologia degli event e le ritrattazioni ed esplorare le relazioni in un grafo dei soggetti. Il browser verifica le firme e gli identificatori degli event. La ricerca e le spiegazioni IA opzionali usano un endpoint scelto dall’utente; l’app controlla le citazioni riportate rispetto agli event sottostanti. Le note di rilascio descrivono esplicitamente i limiti dei relay e indicano dipendenze della build locale che richiedono ancora repository affiancati.

Mangatsu e Noteds arrivano su Android

Mangatsu v0.1.11 fa parte della prima serie di release Android di questa settimana del lettore ed editore di fumetti. Il suo sorgente aggiunge l’accesso con Amber tramite NIP-55, l’interfaccia Android per chiedere a un signer esterno di approvare operazioni Nostr. Fumetti e capitoli sono event Nostr, mentre le loro pagine risiedono su server Blossom; il lettore supporta anche una libreria salvata crittografata e la lettura offline. I commit successivi intervengono sull’invocazione del signer e sull’aggiornamento delle liste dei relay.

Noteds v0.1.2 porta su Android, tramite Tauri, un marketplace di annunci su Nostr. La sua integrazione con il signer Android usa la firma Android NIP-55. L’app pubblica annunci e messaggi su Nostr e costruisce un grafo di ricerca locale con categorie, aree geografiche ed embedding opzionali nel browser. Il sorgente più recente corregge l’accesso nativo alla posizione per la ricerca nelle vicinanze. Entrambi i progetti sono alle prime release; le loro pagine di release su GitHub non hanno note dettagliate, quindi queste funzionalità sono ricavate dai README con tag e dai commit di implementazione.

Statim combina i DM Nostr con altre reti

Statim v0.4.0 segue la release iniziale del 23 settembre. Il sorgente con tag descrive un messenger con DM Nostr NIP-17 accanto a XMTP, Status, Telegram e Matrix. Gli account partono da una frase di ripristino conservata localmente; ogni conversazione indica il proprio protocollo, perché queste reti offrono proprietà di privacy diverse. Su Android manca attualmente l’integrazione con Telegram. Sono le funzionalità documentate dal progetto, non garanzie verificate in modo indipendente né conferme della disponibilità negli store.

In sviluppo

Amethyst ripara l’interoperabilità dei gruppi crittografati

Amethyst è un client Nostr per Android con supporto ai gruppi crittografati Marmot. White Noise è un altro messenger Marmot; un insieme di modifiche per l’interoperabilità testato con i suoi client interviene sull’amministrazione dei gruppi, sulla formulazione delle eliminazioni e su altri comportamenti emersi quando i due client condividono una conversazione. Correzioni più mirate inviano reazioni ed eliminazioni all’interno del gruppo Marmot invece che come messaggi privati gift-wrapped NIP-17 separati e applicano dopo il riavvio le modifiche provenienti da un altro client. Si tratta di modifiche integrate nel sorgente; i test descritti nelle PR sono più limitati di una release multi-client pubblicata.

Un’integrazione separata del runtime e dell’interfaccia dei gruppi Cordn aggiunge un altro percorso per i gruppi crittografati tramite server coordinatori. Cordn è distinto da Marmot, quindi le due modifiche non vanno lette come un’unica migrazione del trasporto.

Amethyst ha inoltre integrato i comandi HTTP per i relay nel suo relay Geode e nel client Quartz, nell’ambito della sua proposta NIP-FE, e un’interfaccia di revisione dei conflitti di backup per gli event sostituibili di profili e liste. NIP-FE è una denominazione della proposta del progetto; il flusso di backup permette di confrontare le versioni prima di accettare una sostituzione e impedisce sovrascritture silenziose dello stato locale.

Amethyst sviluppa anche Concord, un protocollo separato per comunità crittografate usato da Armada e Accordion. Un insieme di modifiche per la conformità aggiunge liste di comunità frammentate, prove di pin, record di rotazione delle chiavi e di scioglimento, seguito da messaggi a scomparsa e inviti diretti. Un invito resta in una inbox privata finché non viene accettato; riceverlo non contatta i relay della comunità. La stessa modifica corregge un confronto tra autori che poteva consentire all’eliminazione di un altro autore di rimuovere un messaggio. Le correzioni multi-client riparano la serializzazione dei rumor non firmati, i campi mancanti degli inviti, la creazione di comunità confermata dai relay e l’ingresso senza riavvio; i test su emulatore riportati coinvolgevano peer Armada e Accordion attivi.

Una successiva implementazione dei canali privati ruota le chiavi dei canali dopo le revoche di accesso pertinenti e aggiunge controlli per creare, rendere privati, rendere pubblici e rigenerare le chiavi. Aggiunge inoltre espulsioni cooperative con controllo del grado e fa scadere gli allegati dei messaggi insieme ai messaggi a cui appartengono. Gli aggiornamenti WebXDC possono finire in un buffer separato del canale, ma Amethyst non ha ancora un host per applicazioni WebXDC. Quell’insieme successivo riporta test del formato di trasmissione e test unitari, senza prove su dispositivo o con relay attivi, quindi il precedente risultato di interoperabilità non certifica ogni controllo appena aggiunto.

Il motore MLS di Quartz ora preserva tra un riavvio e l’altro i segreti delle generazioni di messaggi saltate, consentendo ai messaggi fuori ordine di restare decifrabili dopo il ripristino dello stato salvato. Quattro epoch precedenti conservate permettono ai chiamanti di autenticare messaggi applicativi in ritardo, conservarne i dati autenticati e impedire che una generazione già consumata venga riaperta. Un aggiornamento del secret tree carica i segreti dei nodi non espansi da uno stato in stile ts-mls; gli errori di generazione obsoleta specifici per mittente distinguono una collisione nel ratchet del client stesso da un replay di un altro membro. La PR afferma esplicitamente che il fallback esistente di Marmot sulle epoch conservate resta separato, quindi si tratta di una capacità del motore, non della prova che ogni percorso dei messaggi di Amethyst la utilizzi.

Un audit dei lettori di tag di Quartz corregge voci geohash private che potevano essere pubblicate in chiaro e un parser che trattava come chiave pubblica la chiave privata contenuta in un nsec. Ripara inoltre gli indirizzi dei repost, le destinazioni di occultamento dei canali, i tag root delle stanze live e gli event di mint indirizzabili. Il lettore obsoleto ForkTag viene rimosso, il che costituisce una modifica all’API sorgente per chi usa Quartz; le righe di mint SQLite preesistenti richiedono ancora una migrazione separata. Ulteriori modelli di event coprono le proposte di Buzz per contenitori di progetto, revisioni di artefatti e team, mentre i modelli per le visualizzazioni video e i controlli push crittografati seguono gli schemi di Divine; queste aggiunte stabiliscono il supporto per analisi e costruzione, non interfacce client complete né NIP numerati adottati.

Il client inoltre visualizza le fotografie Ultra HDR nel feed e nel visualizzatore a schermo intero su Android 14 o versioni successive. Android 15 e versioni successive limitano l’aumento di luminosità nel feed al doppio dell’intervallo ordinario, mentre lo schermo intero può usare l’intera gamma del display; i dispositivi di test riportati usavano API Android più recenti, lasciando non testati Android 14 e 15. Un’integrazione condivisa dell’interfaccia e del porting dei caricamenti porta 140 schermate su codice comune tra Android e desktop e sposta il lavoro sui contenuti multimediali Android fuori dal thread dell’interfaccia. Il suo audit ripristina anche la segnalazione degli errori nella rimozione dei metadati, rendendo il refactoring qualcosa di più di uno spostamento di file.

Divine aggiunge il video crittografato ai messaggi diretti

Divine è un client video Nostr. NIP-17 trasporta i messaggi privati in gift wrap crittografati che ne nascondono il mittente ai relay. Il lavoro integrato di Divine sui messaggi video crittografa sul dispositivo un video allegato, carica il testo cifrato e invia la chiave di decifratura all’interno di quel messaggio privato. Un destinatario può verificare e decifrare il file per riprodurlo o salvarlo. Una correzione separata del ripristino della cronologia impedisce che un rifiuto ambiguo di un relay interrompa prematuramente il ripristino quando altri relay possono ancora rispondere.

La correzione di Divine per le chiavi di moderazione dismesse rifiuta le chiavi dismesse nella risoluzione delle etichette di moderazione e seleziona il destinatario attuale delle segnalazioni quando ne viene presentata una. Le segnalazioni in sospeso indirizzate a una chiave dismessa vengono reindirizzate alla chiave fissata nella build, e le conversazioni non risolte restano non scrivibili. La modifica distingue inoltre la custodia delle chiavi dismesse quando si decide quali thread storici un minore può leggere; gli aggiornamenti della custodia richiedono comunque una release dell’applicazione. La gestione della cache dei commenti eliminati impedisce che un commento recente eliminato con successo ricompaia quando un thread viene ricaricato.

Per i creatori, una modalità di registrazione con maschera di colore in tempo reale mostra in anteprima lo sfondo sostitutivo prima di registrare una ripresa, e il mascheramento della parete bianca aggiunge, tramite il plugin video, un mascheramento sensibile alla luminosità. I sottotitoli parola per parola preservano i tempi delle parole riconosciute e usano tempi approssimativi quando il server fornisce solo segmenti interi. La continuazione dello stop-motion aggiunge nuovi fotogrammi al ritmo della composizione esistente, mentre il ritorno delle clip staccate, la selezione dei font raggruppata e i preset di velocità aggiungono controlli di modifica senza cambiare il formato degli event Nostr.

L’allineamento dell’esportazione quadrata e il suo seguito per le clip più piccole mantengono testo e sticker al loro posto tra clip con risoluzioni diverse. La riproduzione HLS di terze parti evita un crash dell’heap su Android tornando indietro ai confini del loop invece di precaricare le playlist importate ripetute; quei loop possono fermarsi brevemente a ogni ripartenza. Un ricaricamento delle preferenze dell’account mantiene ai valori predefiniti i filtri legati all’account durante un cambio, correggendo in parte un’asserzione di debug all’accesso. Un problema separato di aggiornamento delle etichette di moderazione resta aperto, quindi la PR non afferma di aver corretto ogni errore di accesso.

Buzz estende i controlli su canali e identità del proprio relay

Buzz è uno spazio di lavoro basato su Nostr con un proprio relay e propri client. La sua implementazione integrata degli artefatti di canale assegna a un record modificabile un unico canale di appartenenza e una catena di revisioni; modifiche in conflitto non possono diventare entrambe la versione di testa. L’etichetta NIP-AR del progetto si riferisce alla sua proposta e implementazione, non a uno standard Nostr consolidato.

Per l’ingresso HTTP protetto, un’altra modifica integrata associa un’asserzione di identità federata alla stessa chiave dimostrata dall’autorizzazione NIP-98. NIP-98 definisce gli event di autenticazione HTTP firmati; l’asserzione NIP-FI di Buzz è una specifica del progetto. Buzz ha inoltre integrato la crittografia HPKE per le buste di backup delle chiavi segrete. Quella PR stabilisce un lavoro di sicurezza a livello di sorgente; la distribuzione a tutti i client resta non verificata.

Buzz desktop 0.5.26 include il lavoro sugli artefatti di canale, la crittografia HPKE nativa per i backup delle chiavi segrete e una console desktop di amministrazione del relay. Le sue modifiche condivise riparano le richieste di canali di progetto non elencati, sincronizzano tra dispositivi le sezioni della barra laterale, l’ordinamento, le stelle e i silenziamenti, limitano le letture dei thread lunghi e rendono più rigorose le asserzioni di identità Blossom. Le note relative all’intero repository elencano separatamente l’associazione dell’identità del relay, la consegna delle menzioni ai companion, gli URL push configurabili, l’eliminazione amministrativa atomica e i nomi contestuali su mobile. Una release desktop stabilisce la distribuzione desktop e condivisa; non dimostra che quelle modifiche per mobile siano state distribuite in una build mobile.

L’applicazione di NIP-FI su WebSocket di Buzz controlla un’asserzione di identità federata prima di accettare i frame, quindi richiede che la sua chiave Nostr corrisponda alla chiave autenticata tramite NIP-42, che dimostra a un relay l’identità di un client. Una sessione scade al primo tra la scadenza del token, l’età massima dell’asserzione e la durata della connessione configurata; dopo la scadenza non ammette nuovi effetti. Questa modalità NIP-FI specifica del progetto è disattivata per impostazione predefinita. I commit audio già ammessi e la configurazione delle sottoscrizioni possono ancora restare in attesa di una dipendenza bloccata, quindi la modifica non stabilisce un tempo di disconnessione limitato in ogni caso.

La preparazione all’eliminazione da parte del proprietario fa passare le richieste attestate dall’operatore attraverso un’approvazione automatica legata all’inventario, fino all’esecutore di eliminazione esistente. Un seguito sul relay fa sì che ritentare la stessa richiesta ne restituisca lo stato attuale e riserva la quota attiva del proprietario finché l’eliminazione non è completata; le tombstone dell’host conservate in modo permanente contano ai fini di un limite di 20 comunità nell’intera durata. Si tratta di modifiche amministrative a livello di sorgente, e il seguito indica agli operatori di tenere disattivata l’eliminazione finché il relay e l’esecutore di drenaggio non sono attivi. Separatamente, un audit del catalogo delle partizioni rileva le partizioni generiche e i mesi non coperti prima di creare nuove partizioni per gli event e per i log di consegna, esponendo agli operatori la sicurezza del servizio e l’aggiornamento dell’audit.

Buzz mobile ora distingue persone e agenti che condividono lo stesso nome visualizzato. Il suo risolutore dei nomi di identità qualifica gli agenti tramite il loro proprietario e aggiunge un breve suffisso della chiave solo quando necessario; l’integrazione nelle conversazioni usa questi nomi per autori, menzioni e avvisi sui membri. Liste, ricerca e Pulse completano lo stesso comportamento al di fuori delle conversazioni. La qualificazione visibile cambia l’etichetta locale, mentre una menzione selezionata mantiene il nome originale dell’identità nel formato di trasmissione.

Conduit fa avanzare il checkout dopo l’accettazione da parte di un relay

Conduit è un marketplace Nostr che invia ai commercianti messaggi d’ordine privati. La pubblicazione progressiva sui relay distingue la prima conferma positiva di un relay dal completamento di tutti i tentativi verso i relay, e un seguito sul checkout rende persistente quella prima conferma prima di procedere. L’accettazione da parte di un relay significa che l’ordine firmato ha raggiunto un relay; non dimostra che un commerciante l’abbia letto o evaso.

Conduit ha inoltre integrato sessioni recuperabili del signer remoto e una negoziazione transazionale dei relay del signer. NIP-46 consente a un’applicazione di richiedere firme da una chiave custodita da un signer separato; queste modifiche mantengono lo spazio di lavoro dell’account dell’utente mentre il suo trasporto viene riparato, quindi verificano l’account esatto prima di riprendere. Le PR stabiliscono il comportamento del sorgente, non una build del checkout distribuita.

L’integrazione della ricerca di prodotti per rilevanza di Conduit invia una normale query di ricerca full-text NIP-50 per i prodotti di kind 30402 e preserva l’ordine di rilevanza del relay attraverso i controlli delle firme, la riconciliazione delle revisioni e il filtro locale di idoneità. Le schede possono comparire prima che terminino le letture in background dei prodotti esatti, mentre le eliminazioni firmate più recenti restano determinanti. Aggiorna e Riprova restano all’interno della ricerca e delle letture dei prodotti esatti invece di avviare una scoperta ampia del catalogo. Un limite di 100 risultati seguito dal filtro locale può far perdere corrispondenze idonee, quindi una risposta parzialmente vuota offre un recupero e non dimostra l’assenza di prodotti.

Elisym costruisce un checkout commerciale su Nostr

Elisym sta sviluppando un toolkit di commercio che firma i prodotti e trasporta su Nostr messaggi privati di ordini e ricevute. Il suo pacchetto commerce integrato definisce la verifica delle offerte e gli event d’ordine gift-wrapped; un’interfaccia di checkout gestisce la revisione dell’offerta, il pagamento con wallet e lo stato della consegna, mentre un nodo commerciante self-hosted impacchetta il lato del negozio. Il progetto definisce provvisorio il kind 30490 e descrive una versione minima per ottobre. Queste modifiche integrate nel sorgente stabiliscono un’integrazione emergente; non è stato dimostrato uno standard di commercio Nostr accettato né un lancio pubblico completo.

Gli strumenti di checkout per agenti di Elisym aggiungono buy_product e get_order per i suoi prodotti pubblicizzati su Nostr. La prima chiamata restituisce un preventivo senza effettuare l’ordine, e una seconda chiamata accetta il preventivo monouso e gli avvisi per lo stesso agente e la stessa rete; lo stato dell’ordine viene conservato in modo durevole nel backend locale su file dell’agente. Il supporto al checkout con Tempo aggiunge un percorso di pagamento con wallet del browser, con verifica del commerciante e consegna. Un hash di transazione inviato mantiene attivo il tentativo finché il suo esito non è stabilito, evitando un risultato di mancato pagamento mentre una trasmissione potrebbe ancora andare a buon fine.

Una correzione successiva al checkout consente al checkout dei prodotti firmati di inizializzarsi quando un wallet del browser si annuncia immediatamente durante la scoperta. La modifica al sorgente sposta la dichiarazione della sessione prima che quel callback possa essere eseguito; l’integrazione da sola non verifica una distribuzione ospitata.

nostter migliora i controlli sul signer e il recupero degli event

nostter è un client social Nostr. La sua modifica integrata sulle capacità del signer verifica se è presente un signer utilizzabile prima di offrire le azioni di follow e reazione. I nuovi tag pin riportano la chiave dell’autore e un hint di relay noto senza indovinarne uno, e l’ordinamento della cache degli event sostituibili segue il criterio di NIP-01 basato su timestamp e, a parità, su ID event. NIP-01 definisce le regole di base degli event Nostr, incluso il modo in cui i client scelgono tra event sostituibili.

Pensieve prepara una riconciliazione isolata dell’archivio

Pensieve è uno strumento di archiviazione e recupero per Nostr. Il suo runtime negentropy isolato integrato dà alla sincronizzazione un worker limitato e un comportamento di completamento durevole. La funzionalità è attivabile su richiesta e la PR afferma esplicitamente che non è stato attivato alcun servizio o configurazione in produzione; è il lavoro preparatorio per un percorso di recupero più sicuro, non la prova di una distribuzione in esecuzione.

ContextVM evita chiamate duplicate tra relay

L’SDK TypeScript di ContextVM trasporta richieste di strumenti e risorse come event Nostr. La sua correzione integrata della deduplicazione in ingresso riconosce tramite l’ID event una singola richiesta in chiaro anche quando più relay o una riconnessione la consegnano di nuovo, allineandosi al percorso esistente dei messaggi incapsulati. La PR riporta che, prima della correzione, uno strumento non idempotente veniva eseguito tre volte per una singola chiamata. Una modifica complementare alle notifiche sulle risorse invia gli aggiornamenti solo ai client sottoscritti; le sessioni inizializzate senza sottoscrizione non li ricevono più.

Cyberspace rivede le regole degli oggetti DECK-0003

Cyberspace sviluppa il formato DECK-0003 per oggetti Nostr strutturati e bag di regione crittografate, che Amethyst ha iniziato a implementare nel numero della settimana scorsa. Nuove regole per parti e oggetti nascosti e i riferimenti nelle bag consentono a una bag di fare riferimento a un oggetto pubblicato separatamente invece di incorporarne ogni parte. Una correzione successiva afferma che un riferimento tramite ID event non può fissare in modo affidabile una vecchia versione di un event indirizzabile, perché un relay può scartarla dopo la sostituzione. I lettori dovrebbero usare la regola corretta del riferimento tramite coordinate; la formulazione dell’integrazione precedente è stata superata.

Wisp corregge le risposte ai commenti Nostr

Wisp è un client Nostr con funzioni di instradamento dei relay e di wallet. Dopo il supporto ai commenti NIP-22 rilasciato la settimana scorsa, un seguito integrato fa sì che anche una risposta a un commento NIP-22 sia un event di commento, con i riferimenti corretti al genitore e alla radice; il percorso precedente pubblicava sempre una nota ordinaria. NIP-22 consente di collegare commenti a molti tipi di contenuto Nostr. La correzione è stata integrata dopo il tag 1.2.5 di Wisp, le cui note si limitano ad aggiornare la versione, quindi si tratta di un avanzamento a livello di sorgente il cui rilascio non è ancora verificato.

Cordn invia le posizioni dei coordinatori a un secondo dispositivo

Cordn coordina la messaggistica di gruppo crittografata su Nostr. La sua modifica integrata alla specifica multi-dispositivo inserisce gli hint dei relay del coordinatore di un gruppo nel documento di gruppo replicato. Un dispositivo appena inizializzato può così trovare un coordinatore assente dai relay predefiniti, invece di sembrare unito a un gruppo di cui non può recuperare né l’arretrato né i messaggi in tempo reale. Si tratta di lavoro sul documento di protocollo, successivo alla release di Cordn sulla coda offline della settimana scorsa, non di una nuova release del client.

Nostr Atlas apre una directory di identità verificabili

Nostr Atlas è una nuova directory che presenta profili Nostr insieme a rivendicazioni di account esterni. La sua pubblicazione del sito integrata separa la directory dalla demo dei componenti del progetto, e il sito risponde pubblicamente. Un’integrazione del flusso di rivendicazione consente al titolare di un account X di pubblicare una prova NIP-39 firmata con un signer del browser, mentre l’arricchimento dei profili legge i metadati Nostr kind-0 solo dopo la verifica della prova. NIP-39 definisce lo schema di prova per associare una chiave Nostr a un’altra identità online; la sola conferma di un relay non rende verificata una rivendicazione.

nostr-java aggiunge strumenti di hosting multimediale e preserva le posizioni dei tag

nostr-java è una libreria Java e un insieme di strumenti MCP per applicazioni Nostr. I suoi strumenti Blossom integrati consentono a un chiamante di caricare, trovare, elencare ed eliminare contenuti multimediali indirizzati tramite hash e di gestire l’elenco dei server dell’utente. Una correzione separata della pubblicazione mantiene al loro posto i valori vuoti dei tag: i tag Nostr sono posizionali, quindi eliminare un hint di relay vuoto poteva spostare un marcatore nel campo sbagliato e rendere l’event pubblicato diverso dall’anteprima approvata.

Zap Cooking cambia il modo in cui si può recuperare la cronologia dell’account

Zap Cooking è un client Nostr per la condivisione di ricette. Il suo lavoro integrato sul recupero Lazarus sostituisce un backup basato su event di dati specifici dell’applicazione NIP-78 con un approccio che analizza le versioni degli event sostituibili conservate dai relay per rilevare follow, silenziamenti o profili sovrascritti. Lazarus resta una bozza di protocollo; il recupero dipende dai relay che hanno conservato le versioni più vecchie, e una PR integrata in un client web non garantisce che ogni event perso possa essere recuperato.

Il client ha inoltre integrato controlli opzionali di proof of work NIP-13 per note e risposte e un modello degli allegati che mantiene coerenti tra anteprima e pubblicazione l’ordine dei contenuti multimediali e le descrizioni NIP-92. NIP-13 consente a un mittente di spendere calcolo locale su un event prima di pubblicarlo; NIP-92 trasporta i metadati dei contenuti multimediali come tag dell’event.

La correzione delle rivendicazioni NIP-05 di Zap Cooking richiede un’autorizzazione NIP-98 sull’esatto corpo della richiesta e rifiuta un signer diverso dalla chiave pubblica che rivendica il nome. In precedenza, quell’endpoint pubblico accettava rivendicazioni non autenticate che potevano sostituire il nome di un altro membro. Il livello di iscrizione ora proviene dal record di iscrizione esistente, e gli utenti con signer remoto ricevono una richiesta di firma al momento della rivendicazione. Il percorso separato e fidato di registrazione lato server resta invariato.

Una riparazione della mute list impedisce che le azioni di silenziamento dal profilo sostituiscano l’intera lista di kind 10000 con i soli tag di chiave pubblica. Il percorso precedente cancellava le voci relative a parole, hashtag e thread insieme al contenuto crittografato, e una delle superfici poteva ripubblicare pubblicamente chiavi di silenziamento private decifrate. Il nuovo percorso legge la copia del relay, preserva i tag non correlati e il testo cifrato e si rifiuta di pubblicare quando quella lettura non è disponibile. Rimuovere un silenziamento privato richiede decifratura e nuova cifratura tramite il signer.

Opal porta la firma remota su Omarchy

Opal è un signer Nostr desktop realizzato per l’ambiente Linux Omarchy. La sua versione 0.3.3 del 28 settembre segue la prima serie pubblica con il supporto alla firma remota NIP-46, un portachiavi locale e un’interfaccia di autorizzazione per le richieste delle app connesse. NIP-46 mantiene la chiave dell’account presso il signer mentre un client separato gli chiede di approvare le operazioni. Si tratta di una release iniziale di un signer specifico per una piattaforma, non di un’affermazione di supporto desktop più ampio.

WatchTower apre un pannello di controllo per relay NIP-86

WatchTower è un pannello appena pubblicato per l’amministrazione dei relay tramite NIP-86, il protocollo per le richieste autenticate di gestione dei relay. Un’istanza pubblica risponde, offrendo agli operatori un luogo in cui esaminare l’interfaccia. Il repository è stato creato il 22 settembre; un sito raggiungibile non dimostra che i suoi flussi di autorizzazione siano stati verificati in modo indipendente né che funzioni con ogni implementazione di relay.

Hubstr Blossom apre un’origine multimediale personale

Il server Hubstr Blossom, appena pubblicato, consente a un client Nostr di caricare immagini, video e file su un endpoint Blossom self-hosted, per poi inserire quegli URL negli event. Il suo README documenta l’archiviazione locale indirizzata tramite hash del contenuto, un indice SQLite, l’autorizzazione firmata di kind 24242 per le modifiche e una serie di operazioni Blossom per caricamento, mirroring, elenchi ed eliminazione. Le letture pubbliche consentono ad altri client di visualizzare i contenuti multimediali pubblicati senza ricevere diritti di caricamento.

Le opzioni documentate del server estraggono inoltre i metadati dei file per gli event NIP-94, che descrivono i contenuti multimediali condivisi. Il server può ricodificare le immagini senza metadati EXIF e, per impostazione predefinita, protegge le richieste di mirror da destinazioni su reti private. Si tratta di un’implementazione appena pubblicata con istruzioni di distribuzione, non della prova di un’ampia diffusione in produzione.

Hubstr Relay ha pubblicato il suo sorgente iniziale il 24 settembre. Combina una cache personale di event in SQLite con un relay pubblico: i lettori non autenticati vedono gli event pubblici consentiti, mentre i tenant autenticati con NIP-42 possono leggere la propria cache. I gift wrap NIP-17 restano non disponibili ai lettori ospiti. Il suo aggiornamento del 25 settembre corregge i record restituiti dai metodi NIP-86 per le liste di pubkey.

Meshstr sperimenta una mesh di relay senza permessi

Meshstr è un progetto in fase alpha con cui i relay Nostr negoziano budget tra peer e si scambiano ricevute d’uso firmate. La sua prima implementazione include un bridge per la politica di scrittura di strfry, un relay Nostr, aggiunto il 27 settembre, con una correzione del socket il giorno successivo. Il repository descrive la negoziazione DIDComm e la riconciliazione NIP-77, che consente ai peer di confrontare insiemi di event senza scambiarsi gli inventari completi, insieme a segnalazioni verificabili dei peer che superano i budget concordati.

Quelle regole del progetto sono una proposta, non un NIP adottato né una rete pubblica di relay dimostrata. L’avanzamento concreto di questa settimana è il percorso di codice pubblicato che collega la politica di scrittura di un relay alla contabilità della mesh proposta.

Dossier mostra cosa può rivelare una cronologia Nostr pubblica

Dossier è un nuovo strumento di autoverifica eseguito nel browser per l’impronta Nostr e Lightning di una persona, con una demo pubblica. Raccoglie i link visibili nel profilo, le tracce degli zap, gli orari di pubblicazione, i metadati dei vecchi messaggi diretti crittografati NIP-04 e i metadati dei contenuti multimediali come gli EXIF delle foto; può anche mostrare dove un relay serve ancora un event che qualcuno ha cercato di eliminare. Il supporto ai signer NIP-07 consente a un utente di autorizzare le azioni di pulizia senza incollare una chiave privata nella pagina.

I limiti documentati del progetto sono importanti: una scansione vede solo i relay che raggiunge, e una richiesta di eliminazione non può cancellare le copie conservate altrove. Il repository è comparso il 27 settembre e non ha release con tag; la demo e il sorgente stabiliscono uno strumento iniziale, non un inventario completo dell’attività passata di qualcuno.

Marmot MDK estende sondaggi, emoji personalizzate e metadati dell’account

Marmot MDK fornisce il runtime e i binding per la messaggistica di gruppo Nostr crittografata. Successive modifiche integrate nel sorgente di MDK espongono le selezioni paginate per singolo votante nei sondaggi, usando le stesse regole di risposta effettiva dei conteggi aggregati. I componenti di gruppo opzionali gestiti dall’applicazione offrono agli host impostazioni controllate dagli amministratori che sopravvivono alla conservazione dei messaggi e raggiungono i nuovi arrivati nel loro Welcome. Gli invii con tag e le reazioni multimediali trasportano i metadati delle emoji personalizzate attraverso runtime e binding, conservano il materiale di decifratura delle immagini di reazione allegate dopo un cambio di epoch e rifiutano i tag di allegato contraffatti. Quella modifica amplia la struttura C della richiesta di caricamento, quindi chi usa l’interfaccia C deve ricompilare con il nuovo header.

Una correzione della convergenza mantiene in sospeso i messaggi quando non è stato selezionato alcun ramo canonico, invece di invalidarli senza provare lo stato attivo. Una pulizia dei percorsi irraggiungibili che la accompagna instrada i commit preparati non risolti verso il comportamento di nuovo tentativo conservato. Le letture dei contenuti multimediali crittografati allineano il timeout di lettura HTTP alla gestione dell’inattività dei corpi riprendibili, affrontando i trasferimenti di grandi dimensioni bloccati senza affermare che il test di accettazione su dispositivo per gli APK in arrivo, ancora in sospeso, sia stato superato. I marcatori delle fasi di avvio mostrano quale passaggio di apertura dell’account è andato in timeout, aggiungendo prove diagnostiche senza affermare che il blocco all’avvio sottostante sia risolto.

Il connettore locale per agenti inoltre unisce i metadati di profilo esistenti quando pubblica un aggiornamento di kind 0, preservando i campi omessi dalla richiesta. Gli aggiornamenti del profilo del gruppo espongono le modifiche al nome e alla descrizione di un gruppo attraverso il percorso esistente autorizzato dall’amministratore attuale. La sua autenticazione via socket concede ancora l’intera API locale; questa integrazione non aggiunge autorizzazioni per singolo principal. Queste modifiche al sorgente seguono la release 0.11.0 con tag.

rust-nostr mette in correlazione le risposte di conteggio dei relay

rust-nostr, una libreria e un SDK Rust per applicazioni Nostr, ha integrato risposte COUNT correlate ed errori più chiari per chi resta in attesa. L’SDK si sottoscrive prima di inviare COUNT e accetta solo la risposta corrispondente, impedendo che un ricevitore perso o chiuso appaia come uno zero legittimo. Preserva inoltre gli errori del ricevitore per le conferme di pubblicazione e l’autenticazione ai relay, così i chiamanti possono distinguere una conferma mancante da un rifiuto esplicito. Le firme dei metodi pubblici restano invariate.

ZapTracker aggiunge metriche sulla rete Nostr e sulle citazioni

ZapTracker è una dashboard per creatori dedicata al coinvolgimento su Nostr e all’attività del wallet. Un’integrazione della dashboard di rete sostituisce le statistiche della rete Lightning con i dati sui relay Nostr online provenienti da nostr.watch e con le informazioni sulle capacità tratte dai documenti NIP-11. Una modifica alle metriche delle citazioni conta gli event di kind 1 che contengono tag q insieme a like, repost, segnalibri e zap. Ciò consente ai creatori di vedere le citazioni nelle classifiche dei contenuti e nei grafici del coinvolgimento; resta una prova a livello di sorgente integrato.

LaWallet NWC instrada le ricariche delle carte verso il wallet della carta

LaWallet NWC collega i wallet Lightning alle applicazioni tramite Nostr Wallet Connect. La sua integrazione per le ricariche BoltCard pubblicizza un link di pagamento LUD-19 che crea una fattura tramite il metodo NWC make_invoice del wallet della carta. Le carte bloccate, disattivate o non associate non pubblicizzano un link di pagamento, e il percorso non reindirizza le ricariche verso l’indirizzo Lightning separato del proprietario. Un seguito espone lo stesso link nell’emulatore e trasporta negli invii LNURL le note del pagatore accettate dal destinatario.

Un nuovo relay khatru espone controlli di moderazione per il proprietario

nostr-relay-khatru ha pubblicato il suo sorgente iniziale il 29 settembre come relay generico derivato dall’implementazione specifica per HiveScope, ora dismessa. L’istanza pubblica serve un documento NIP-11 che indica questo repository e pubblicizza autenticazione, scadenza degli event, event protetti, conteggio, riconciliazione e amministrazione del relay. Un’implementazione del 30 settembre aggiunge controlli di moderazione al pannello del proprietario. I metadati pubblici verificano un endpoint distribuito, non il buon esito dei test di ogni metodo pubblicizzato.

Un costruttore locale di web-of-trust tiene traccia degli unfollow

etemiz/wot ha pubblicato il 30 settembre un crawler web-of-trust per Nostr. Legge le liste di follow e le liste di relay NIP-65, calcola la fiducia a partire da radici configurabili e scrive i punteggi in LMDB per politiche dei relay, feed e filtri antispam. La documentazione del progetto spiega il compromesso: gli aggiornamenti in tempo reale aumentano la fiducia, mentre le scansioni complete pianificate applicano le diminuzioni e gli unfollow. I punteggi dipendono dalle radici scelte. Si tratta di sorgente appena pubblicato, senza release con tag né dichiarazioni di distribuzione in produzione.

Moyu apre un client per spazi di lavoro Marmot

Moyu ha pubblicato il sorgente di un client di chat per spazi di lavoro in Rust basato su Marmot, con interfacce a riga di comando, da terminale e desktop. Le sue modifiche del 30 settembre usano le modifiche ai membri registrate localmente per impedire che vecchie richieste di ingresso riammettano membri rimossi, fanno scadere i codici di invito dopo sette giorni e consentono agli amministratori di revocarli. L’output del terminale filtra i caratteri di controllo e le forzature della direzione del testo inviati da altri membri. Un fork fissato di MDK instrada i trasferimenti degli allegati Blossom attraverso il proxy SOCKS5 configurato, con la risoluzione dei nomi host eseguita da quel proxy. Le modifiche della 0.3.0 sono nel sorgente pubblico; non sono ancora disponibili un tag di release pubblico né una voce di release.

Lavori sul protocollo e sulle specifiche

NIP-39 estende le prove di identità a Bluesky e Discord

NIP-39 consente a un account Nostr di indicare la prova che controlla un’identità su un’altra piattaforma. Una modifica integrata il 27 settembre dà alle nuove prove un’unica frase raccomandata e indica ai verificatori di accettare le prove più vecchie che contengono l’npub dell’account, anche quando la formulazione è diversa. Documenta inoltre i post di Bluesky e i messaggi di Discord come luoghi in cui pubblicare la prova. Una rivendicazione su Discord può essere verificata solo da chi può leggere il server in cui è stato pubblicato il messaggio.

NIP-86 aggiunge la gestione dei codici di invito per gli amministratori dei relay

Nel numero dell’8 luglio Compass aveva descritto la proposta di inviti per NIP-86 mentre era ancora aperta; ora è stata integrata. NIP-86 definisce un’API standard per la gestione dei relay, e NIP-43 definisce come i relay ad accesso limitato annunciano i membri ed elaborano le richieste di ammissione. L’integrazione del 24 settembre aggiunge listclaims, createclaim e deleteclaim, così un amministratore può elencare, emettere e revocare i codici di invito accettati da un relay. Ciò offre agli operatori un percorso di gestione per gli inviti che possono assegnare un ruolo a un membro dopo il suo ingresso; non obbliga ogni relay a supportare questi metodi.

Una correzione alla copertura di NIP-86 della settimana scorsa: la specifica integrata ha aggiunto unallowevent, unbanevent, listallowedevents e listdisallowedkinds. L’articolo precedente riportava i nomi di una descrizione superata della proposta. I primi due metodi annullano una decisione di autorizzazione o di ban a livello di event; gli altri consentono di esaminare gli event autorizzati e i kind non consentiti.

NIP-51 sposta i follow set preferiti su un kind di event inutilizzato

NIP-51 definisce liste pubbliche e private, tra cui una lista dei follow set preferiti di un utente. Compass aveva descritto la proposta sulla collisione di kind nel numero del 22 luglio; ora è stata integrata. La correzione del 27 settembre assegna a quella lista di preferiti il kind 10021, perché il numero precedente era già in uso. I suoi tag a continuano a puntare ai follow set di kind 30000. La modifica risolve una collisione di numeri nella specifica; non crea un nuovo modo di seguire le persone.

NIP-51 propone risposte nascoste per ogni thread

Una proposta aperta per NIP-51 consentirebbe all’autore di un thread di pubblicare un insieme pubblico di risposte nascoste che i client collaborativi mostrano dietro un interruttore. Usa un event indirizzabile di kind 30027 per ogni thread, con l’ID della radice come tag d e tag e che indicano le risposte; vale solo un insieme firmato dall’autore della radice. Inserire la radice nell’elenco chiede ai client di nascondere le risposte degli altri autori e di non offrire più il campo di composizione della risposta, mentre le risposte possono comunque essere pubblicate sui relay. Il formato per singolo thread limita le collisioni nelle modifiche alla stessa conversazione. L’autore riferisce un’implementazione in Nostrich, ma l’esame del sorgente pubblico non l’ha confermata; la proposta resta non integrata e il formato dell’insieme è ancora in discussione.

NIP-DB propone nomi di dominio verificati per servizi indirizzati tramite chiave

La proposta aperta NIP-DB, presentata il 28 settembre, descrive event Nostr che associano un normale dominio Internet alla chiave che lo serve su una rete indirizzata tramite chiave, come FIPS, una mesh crittografata che indirizza i nodi tramite chiave pubblica Nostr. Il proprietario di un dominio può stabilire l’associazione con un record DNS TXT o con una prova DNSSEC trasportata insieme alla rivendicazione; i client fisserebbero un risultato verificato per un uso offline successivo. La proposta vieta esplicitamente la risoluzione tramite una rivendicazione non verificata, poiché chiunque può rivendicare il dominio di qualcun altro in un event Nostr. fips-pub-domains è l’implementazione di riferimento dell’autore, ma i numeri dei kind degli event e parte della formulazione specifica per l’overlay sono ancora in revisione. I test end-to-end riportati sono prove dell’autore, non un’affermazione che la proposta sia un NIP accettato.

Una bozza di feed privato esplora gruppi crittografati di destinatari

Una nuova proposta di busta multi-destinatario, aperta il 29 settembre, delinea note, risposte e connessioni private i cui destinatari previsti possono trovare un event senza esporre le proprie chiavi pubbliche ordinarie nei tag visibili. Propone tag alias opachi a coppie, derivati da segreti condivisi, e kind di event provvisori, incluso un modo per incapsulare un altro event Nostr per centinaia di lettori. Ciò potrebbe offrire ai piccoli feed privati un percorso di recupero più diretto rispetto all’invio di un messaggio separato a ogni membro.

L’autore della proposta la definisce esplicitamente un lavoro in corso. La bozza non ha un’implementazione dimostrata né una revisione di sicurezza, e l’assegnazione dei kind e le regole di firma a livello di byte restano aperte.

Una proposta Blossom consente ad altre persone di annunciare i contenuti multimediali replicati

Una proposta di NIP aperta descrive un modo con cui chi replica un blob Blossom di un altro autore può annunciare quella copia tramite Nostr. Un client potrebbe quindi cercare la copia se il server originale perde il blob. Nella discussione è emersa anche l’idea di controllare l’attuale elenco di server BUD-03 di chi ha effettuato il mirror quando un hint di server annunciato è diventato obsoleto. Si tratta di un percorso di scoperta proposto, non della garanzia che client o relay di archiviazione offrano già un archivio di riserva.

Le segnalazioni di eventi stradali cercano un formato Nostr condiviso

La proposta aperta Road Event Reports descrive segnalazioni e conferme per buche, chiusure, autovelox e altre condizioni stradali. Usa tag di posizione e il timestamp di scadenza di NIP-40, che indica ai relay quando smettere di servire un event, così una segnalazione non deve restare attuale indefinitamente. L’autore ha basato le revisioni su un campione di event recuperati dai relay pubblici e sui client Roadstr esistenti per segnalare le condizioni stradali, ma la bozza lascia ancora aperta una questione sulla codifica compatta, e il numero di NIP proposto non è stato adottato.

Marmot riconsidera il coordinamento tra più dispositivi

La riprogettazione multi-dispositivo di Marmot sostituisce una bozza External Commit mai implementata con una guida non normativa pensata per raccogliere un primo feedback. La nuova direzione esplora un dispositivo esistente che approva un nuovo dispositivo, lo inserisce nelle conversazioni e in seguito rimuove i dispositivi, mantenendo visibili le questioni aperte. Gli ID riservati dalla bozza rimossa vengono liberati perché nessuna implementazione li aveva adottati. Il documento di idee non assegna nuovi ID né formati di trasmissione e non è una funzionalità multi-dispositivo implementata.

Sei anni di settembre su Nostr

L’ultimo numero di settembre è l’occasione per ripercorrere come Nostr sia passato dagli abbozzi a un insieme più ampio di strumenti interoperabili. Un prototipo di abbinamento di corse del 2021 usava event firmati per coordinare un servizio; cinque anni dopo, la formulazione delle prove di identità e le collisioni tra kind di liste sono il genere di dettagli che i maintainer stanno risolvendo. Nel frattempo, i client hanno imparato a presentare conversazioni, contenuti multimediali e ripristino in modi utilizzabili da persone comuni. Le fonti datate qui sotto mostrano le tappe di questa progressione. Non dimostrano che ogni esperimento sia stato lanciato né che ogni vecchio progetto resti raccomandato.

Settembre 2021: primi esperimenti con forme utili

Un commit di BUber del 4 settembre esplorava un concetto di abbinamento per taxi basato su event Nostr. Mostrava come una richiesta firmata e trasportata dai relay potesse coordinare persone senza affidare l’intero servizio a un unico server. Il sorgente è un concetto e non dimostra il lancio di un servizio di corse.

Più avanti nello stesso mese, il sorgente di Loquaz del 23 settembre offriva un prototipo di chat desktop. Era un altro dei primi tentativi di far sembrare i messaggi dei relay un’applicazione ordinaria. Il sorgente non dimostra una crittografia end-to-end completa né un messenger pronto per la produzione; il filo conduttore duraturo è la ricerca di un’interfaccia di conversazione utilizzabile sopra event semplici. BUber sperimentava l’abbinamento di corse e Loquaz la chat; entrambi usavano event firmati prima che si consolidassero schemi comuni per i client. Queste prove hanno delineato due problemi ricorrenti per i client successivi: coordinarsi attraverso i relay e presentare gli event come una conversazione utilizzabile.

Settembre 2022: chat e azioni delegate entrano nelle specifiche

La modifica a NIP-28 del 10 settembre descriveva canali di chat pubblici con messaggi e metadati che i client potevano interpretare insieme. NIP-28 ha reso una stanza condivisa un oggetto esplicito del protocollo e ha dato ai client una convenzione comune per i canali.

Il 23 settembre, il NIP-26, nel suo testo sulla firma delegata, documentava un modo con cui una chiave poteva autorizzarne un’altra a firmare un insieme limitato di event. Coglieva un’importante questione progettuale del 2022: come usare un’identità Nostr senza consegnare la chiave principale a ogni applicazione. NIP-26 è ora contrassegnato come non raccomandato, quindi questa è la testimonianza di un esperimento, non un consiglio per nuove integrazioni. Il suo stato successivo mostra come si sia evoluto il modello di firma: una specifica può preservare un’utile formulazione del problema anche quando la soluzione proposta viene ritirata.

Settembre 2023: i client maturano attorno alla scoperta dei relay e ai metadati

Damus è un client social Nostr. Il suo changelog del 21 settembre registrava lavori sul database Nostr locale, sulla ricerca e sulla navigazione per hashtag. Queste modifiche rendevano più facile sfogliare e recuperare su un telefono un feed social affollato; il changelog datato è una prova di quella release del client, non di ogni capacità successiva di Damus.

Anche i dettagli del protocollo si stavano muovendo. Una modifica del 26 settembre a NIP-24 chiariva i campi opzionali dei metadati del profilo, mentre la modifica a NIP-65 del 29 settembre affrontava la normalizzazione e la deduplicazione degli URI dei relay. NIP-65 indica ai client come pubblicare i relay che usano per leggere e scrivere; un trattamento coerente degli URI aiuta queste liste a puntare allo stesso relay anche quando le stringhe differiscono in modi innocui. Quella piccola convenzione ha spinto la progettazione dei client verso una scoperta affidabile: trovare gli event di una persona dipende dal sapere dove vengono pubblicati.

Settembre 2024: i post acquisiscono un contesto più ricco

Le note di rilascio di Damus del 22 settembre descrivevano il supporto agli highlight e ai commenti NIP-84. NIP-84 offre ai lettori un modo per citare e discutere un passaggio di un contenuto lungo. Il lavoro sul client mostra come un’idea del protocollo sia diventata qualcosa che le persone potevano usare durante la lettura.

Nel frattempo, NIP-34 riceveva una modifica del 20 settembre che perfezionava oggetti ed etichette delle issue per la collaborazione git su Nostr, e NIP-73 riceveva una modifica lo stesso giorno che perfezionava gli identificatori di contenuti esterni. Sono modifiche separate alle specifiche: una aiuta le issue di un repository a mantenere la propria struttura, mentre l’altra consente a un event di fare riferimento a materiale esterno a Nostr. Entrambe ampliano il significato che un client può preservare quando i contenuti viaggiano tra comunità, repository e altri media.

Settembre 2025: controlli di accesso e contesto dei pagamenti diventano più precisi

Una revisione di NIP-42 del 6 settembre affrontava l’autenticazione ai relay con più utenti. NIP-42 consente a un relay di sfidare un client a dimostrare quale chiave Nostr sta effettuando una richiesta; l’aggiornamento era importante per i servizi che servono più di un account autenticato sulla stessa connessione.

Un aggiornamento di NIP-47 del 15 settembre aggiungeva metadati di pagamento opzionali alle richieste Nostr Wallet Connect. NIP-47 consente a un’app di chiedere a un wallet di eseguire azioni tramite Nostr. Più contesto può rendere comprensibile un’interazione con il wallet, ma i metadati possono esporre dettagli sul pagatore, quindi client e wallet devono comunque trattarli come sensibili. La modifica illustra come il lavoro sull’interoperabilità includesse ormai ciò che un destinatario può apprendere, e non solo se una richiesta può essere consegnata.

Settembre 2026: i dettagli dell’interoperabilità incontrano l’identità pubblica

Questo settembre, una modifica integrata a NIP-51 ha spostato il kind di event dei follow set lontano da una collisione. NIP-51 definisce liste che una persona può mantenere e condividere; kind di event univoci permettono ai client di distinguere un tipo di lista da un altro. Un numero precedente di Compass aveva discusso la proposta, mentre l’integrazione di settembre ne segna il cambio di stato.

Una seconda modifica integrata a NIP-39 ha chiarito il testo delle prove e aggiunto altri modi per associare un account esterno a un’identità Nostr. NIP-39 riguarda rivendicazioni di identità verificabili, non un registro centrale delle identità. Insieme, le due integrazioni mostrano l’attuale lavoro sul protocollo concentrarsi sui piccoli dettagli che determinano se client indipendenti interpretano correttamente gli stessi event di identità e di lista. Mostrano anche uno spostamento dall’invenzione di nuove categorie di event verso la riduzione dell’ambiguità in quelle esistenti.

Lungo questi sei settembre, lo schema è una progressione: dal dimostrare che un event firmato può descrivere una richiesta applicativa al chiedersi come un client verifichi una rivendicazione su una persona. I vecchi prototipi contano perché espongono le domande a cui specifiche e client successivi hanno dovuto rispondere: chi firma, dove si trova un event, che cosa significa e come si fa a sapere se fidarsene. È anche per questo che una piccola e precisa correzione del protocollo può contare quanto una nuova interfaccia.

Nostr Compass #40

Wed, 16 Sep 2026 00:00:00 +0000

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

Questa settimana: Marmot Protocol e MDK aggiungono finestre limitate per conversazioni, correzioni per il ripristino e binding SDK coordinati, Myco trasforma la propria mesh FIPS in un ambiente di esecuzione offline per napplet e condivisione di file, Dart NDK modifica il comportamento di relay e cache, mentre Keycast ricostruisce la firma remota attorno a richieste persistenti e funzionalità di ripristino. Tra le release con tag figurano Nail, Nostr Mail Client, Linky e Boris. Il repository dei NIP ha integrato una PR questa settimana, chiarendo NIP-A3 (Payment Targets), mentre le proposte relative ai comandi slash e agli heartbeat DVM restano aperte. Gli approfondimenti riguardano NIP-23 (Long-form Content) e NIP-92 (Media Attachments).

Notizie principali

Marmot Protocol e MDK raggiungono v0.10.0

MDK v0.10.0 di Marmot Protocol aggiunge finestre limitate per gli elenchi delle chat e le conversazioni, riepiloghi indipendenti degli elementi dell’account che richiedono attenzione, bozze sicure rispetto alle revisioni e lo stato delle reazioni per chi visualizza, destinati alle applicazioni che realizzano gruppi crittografati basati su MLS tramite Nostr. Ripristina inoltre il blocco degli utenti per singolo account e conteggia gli inviti in sospeso senza contarli nuovamente come messaggi non letti.

La serie di release v0.10.0 corregge il ripristino quando un dispositivo viene rimosso e aggiunto nuovamente, quando il traffico arriva prima del relativo Welcome e quando la riproduzione del peel viene interrotta. Riduce la sincronizzazione dei relay e il ricambio delle sottoscrizioni, mette in coda le operazioni multimediali mentre gli slot di trasferimento sono occupati e vincola a ogni tentativo gli upload per l’audit forense a destinazioni convalidate.

Lo stesso commit sorgente di MDK distribuisce gli artefatti Rust, C, Swift, Kotlin, da riga di comando e per agenti come un’unica coorte di compatibilità. I database degli account avanzano attraverso le migrazioni 70–75, quindi le applicazioni devono aggiornare insieme il codice sorgente generato e le librerie native, conservare bundle completi dei framework Apple, eseguire un backup prima della migrazione ed evitare il downgrade di un database già migrato.

Myco 0.7.0 esegue napplet e condivisione di file su una mesh FIPS multi-percorso

Myco v0.7.0 trasforma l’applicazione mesh per Android in un host per napplet, programmi Nostr contenuti in un singolo file e descritti dalla proposta aperta NIP-5D. Ogni napplet viene eseguita in una sandbox senza accesso diretto alla rete o allo spazio di archiviazione e richiede tramite Myco le funzionalità relative a identità, relay, outbox, mesh, immagini o file. La schermata di installazione mostra queste autorizzazioni prima dell’approvazione, gli utenti possono modificarle in seguito e gli aggiornamenti che richiedono un accesso più ampio tornano alla fase di autorizzazione.

Myco v0.7.0 invia inoltre file arbitrari ai telefoni associati tramite il pannello di condivisione del sistema o un contatto Circle. Il telefono ricevente approva il trasferimento prima che Myco scriva il file in Downloads/Myco e il payload viene crittografato con la chiave di quel telefono. Il rilevamento sulla rete locale usa UDP quando entrambi i telefoni condividono il Wi-Fi e mantiene Bluetooth per i percorsi offline; i nuovi tentativi gestiscono la perdita dei messaggi di controllo, mentre un timer di inattività limita i trasferimenti di file di grandi dimensioni che si bloccano.

Myco ora mantiene collegamenti FIPS simultanei con un peer, verifica i percorsi in standby e sposta il traffico quando il collegamento Bluetooth, Wi-Fi Aware o di rete locale attivo si degrada. Il lavoro si basa sul ramo sperimentale multi-percorso di FIPS. La versione 0.7.0 resta compatibile a livello di protocollo con la 0.6.1 per lo scambio di applicazioni, la messaggistica e l’associazione già esistenti, ma i collegamenti multi-percorso si formano soltanto tra due telefoni aggiornati. Anche il relay integrato passa a LMDB e migra gli archivi di event precedenti al primo avvio.

Dart NDK modifica il comportamento di relay, cache e account

Dart NDK v0.10.0-dev.3 è una release di sviluppo della libreria client Dart, con modifiche incompatibili nella gestione dei relay, nella cache, nell’autenticazione e nei flussi degli account. I responsabili della manutenzione dei client devono prevedere interventi di migrazione sia del codice sia del comportamento, soprattutto quando un’applicazione presuppone che gli event nella cache, gli event nascosti o gli aggiornamenti degli account seguano la semantica della precedente linea di release.

La serie di sviluppo v0.10.0 migliora inoltre le prestazioni della cache e del verificatore Rust e modifica il comportamento relativo a metadati, coordinate di eliminazione, visibilità degli event, autenticazione del signer e pagamenti NWC. La verifica compatta degli event in Rust riduce il sovraccarico di verifica, mentre il nuovo comportamento della cache loadHiddenEvents è esplicitamente incompatibile.

Poiché si tratta di v0.10.0-dev.3, e non di una release stabile v0.10.0, i team che sviluppano applicazioni dovrebbero fissare le versioni e collaudare deliberatamente le migrazioni. La riconnessione ai relay, il popolamento della cache, l’autenticazione del signer, la gestione del wallet e l’ordine dei flussi degli account sono i percorsi più importanti da verificare prima di migrare i client di produzione.

Keycast pubblica la release candidate del proprio signer ricostruito

Keycast v2.0.0-rc.1 è la prima release numerata del signer remoto NIP-46 ricostruito e self-hosted. La release candidate aggiunge il supporto NIP-46 multiplexato, l’instradamento dei relay condiviso e per singola chiave, la gestione persistente delle richieste, l’archiviazione crittografata delle chiavi, inviti, sessioni e spazi di lavoro per i team.

Le regole di firma e il ripristino ricevono pari attenzione in v2.0.0-rc.1. Gli operatori possono configurare le regole di firma, esaminare la cronologia di audit, creare backup crittografati, ripristinare le installazioni e ruotare la chiave root. Il progetto documenta inoltre una provenienza coordinata e verificata delle release per i propri componenti API, signer e web.

La release resta una release candidate, quindi gli operatori non dovrebbero dedurre la compatibilità definitiva o l’idoneità alla produzione dal solo numero di versione. Prima di sostituire un servizio signer esistente, i test dovrebbero coprire il ripristino delle richieste interrotte, gli errori di instradamento dei relay, l’applicazione delle regole, il ripristino dei backup e la rotazione delle chiavi.

Release con tag

Nail 0.2.0 ripristina le sottoscrizioni da Nostr all’email

Nail v0.2.0, un servizio che recapita messaggi Nostr tramite flussi di lavoro email, aggiunge sottoscrizioni gift-wrap autoriparanti. La modifica mira a ripristinare la consegna da Nostr all’email dopo errori delle sottoscrizioni, anziché lasciare il bridge silenziosamente bloccato.

Nostr Mail Client 0.15.0 amplia il controllo di account e relay

Nostr Mail Client v0.15.0 aggiunge il passaggio tra account con un tocco, notifiche per singolo account, push web e il ripristino di un elenco di relay mancante da un relay, un indirizzo Nostr o un nprofile. Ripubblica inoltre i profili e gli elenchi di relay sui relay di indicizzazione, si riconnette quando torna l’accesso alla rete e distingue un’interruzione del dispositivo da relay di posta irraggiungibili. Queste modifiche rendono più affidabili il ripristino degli account e la consegna sui client desktop, web e Android.

Linky 26.9.17 mantiene i seed di ripristino fuori dal proprio server

Linky v26.9.17, un’applicazione per contatti, messaggistica Nostr privata e pagamenti Lightning/Cashu, corregge un percorso che inviava i seed di ripristino al server di Linky quando gli utenti li salvavano tramite un gestore di password. La release rafforza inoltre la gestione degli URL dei file di pagamento e disabilita i backup delle applicazioni Android, riducendo i luoghi dai quali il materiale di ripristino del wallet e dell’identità può uscire dal dispositivo.

Calendar by Form* 2.4.0 aggiunge gli inviti per ospiti di Mailstr

Calendar by Form* v2.4.0, un client di calendario Nostr, aggiunge gli inviti per ospiti di Mailstr e correzioni al calendario su dispositivi mobili. Il percorso di invito consente agli organizzatori di includere partecipanti tramite un coordinamento basato sulla posta senza richiedere un account di calendario esistente.

Hessible 0.1.2 velocizza la sincronizzazione crittografata di contatti e foto

Hessible 0.1.2, un’applicazione Android per i contatti incentrata sulla privacy che archivia dati di contatto crittografati sui relay Nostr, riduce il sovraccarico della sincronizzazione e replica le foto crittografate dei contatti sui server Blossom. La release riduce anche le dimensioni del pacchetto dell’applicazione, mentre le sue indicazioni continuano a raccomandare agli utenti di eseguire il backup delle chiavi e di tenere conto dei diversi periodi di conservazione dei relay.

Boris 0.12.5 limita l’estrazione e rafforza la lettura offline

Boris v0.12.5, un client per elenchi di lettura basato sui segnalibri Nostr, segue v0.12.4 con l’estrazione limitata dei contenuti, la cache offline, modifiche alle query dei relay, la gestione dell’HTML non sicuro e una correzione per il testo quasi invisibile nel tema Paper White. Queste modifiche interessano sia la sicurezza dei contenuti sia l’affidabilità della lettura del materiale salvato senza un percorso di rete attivo.

Amethyst 1.15.2 perfeziona i contenuti multimediali e le risposte con ambito root

Amethyst v1.15.2, un client Nostr per Android, conclude una sequenza di tre release con correzioni ai contenuti multimediali, una gestione più chiara delle autorizzazioni di Health Connect, la memorizzazione nella cache dei nomi delle fonti e filtri dedicati per le interazioni con le risposte NIP-22 con ambito root. La release include anche aggiornamenti alle traduzioni e ai metadati dei pacchetti.

LibreNostr 0.5.17 instrada i feed attraverso i relay di scrittura degli autori

LibreNostr 0.5.17, un client Android incentrato sui relay, ora indirizza le query dei feed ai relay di scrittura NIP-65 degli autori seguiti e rinvia le query sul conteggio delle interazioni finché le note non entrano nell’area visibile. Il lavoro precedente nella stessa sequenza di release limita le query simultanee ai relay e chiude ogni sottoscrizione al relay non appena quel relay risponde, riducendo il rifiuto delle richieste provocato dal client stesso durante gli aggiornamenti.

Voca 1.2.0 migliora l’annullamento e il ripristino della sintesi vocale

Voca 1.2.0, un lettore text-to-speech per Android orientato all’uso offline che può recuperare e verificare contenuti Nostr, aggiunge comportamenti distinti per l’annullamento e il rendering, oltre al ripristino per motori vocali lenti o inaffidabili, dopo il lancio della versione 1.0 trattato nel numero #38. Aggiunge inoltre una diagnostica facoltativa inviata con una nuova chiave Nostr monouso tramite un messaggio privato NIP-17, con i report di grandi dimensioni crittografati localmente prima dell’upload.

Postr 1.1.1 aggiunge la dettatura e il ripristino della pubblicazione

Postr 1.1.1, un composer Android dedicato al kind 1, aggiunge la dettatura e la gestione delle menzioni che tiene conto della posizione del cursore, dopo il lancio trattato nel numero #37. La precedente release 1.1.0 migliora inoltre il ripristino della pubblicazione riprovando lo stesso event firmato dopo esiti ambigui, evitando che il ripristino crei una nota duplicata.

earthly 0.1.10 corregge la sanificazione e la creazione delle mappe

earthly v0.1.10, un editor collaborativo di mappe Nostr, modifica sostanzialmente la creazione di mappe e storie, correggendo al contempo una falla critica nel sanitizzatore delle attribuzioni di MapLibre tramite un aggiornamento di MapLibre GL JS. La release migliora inoltre i messaggi sulla compatibilità con WebGL 2, i controlli su dispositivi mobili, la modifica delle geometrie, la selezione e i controlli di presentazione delle mappe.

Routstrd 0.4.10 rafforza l’instradamento delle richieste Nostr

Routstrd v0.4.10 sostituisce un elenco di provider archiviato e obsoleto con quello restituito dal rilevamento in tempo reale. La precedente release v0.4.9 ha aggiunto controlli manuali e pianificati per l’aggiornamento dei client, npubs con nome nella CLI e riavvii graduali del daemon che attendono il completamento delle richieste attive. Nel complesso, le release rendono più espliciti la selezione dei provider e il comportamento di aggiornamento per gli operatori del servizio instradato tramite Nostr.

Whistle 1.9.1 dota di strumentazione il ripristino in background

Whistle 1.9.1, un’applicazione crittografata per la condivisione della posizione in gruppo, basata su Nostr, MLS e Marmot Protocol, aggiunge strumentazione per il ciclo di vita del dispositivo al ripristino in background su iOS. La versione 1.9.0 introduce inoltre la sospensione della condivisione per singolo gruppo e la diagnostica dell’ultimo event per singolo gruppo, facilitando la distinzione tra un gruppo bloccato e una connessione funzionante a livello dell’intera applicazione.

Amber 6.6.4 risolve una fuga di dati tramite Tor e gli errori di ripristino del signer

Amber v6.6.4, un signer di event Nostr per Android, conclude una sequenza di tre release con la correzione di una fuga di dati tramite Tor e correzioni relative ai relay del signer e al ripristino. Gli utenti dei signer e gli sviluppatori di applicazioni dovrebbero prestare particolare attenzione alle ipotesi sui percorsi di rete e al comportamento dei nuovi tentativi, poiché in caso contrario gli errori del signer possono sembrare errori di pubblicazione del client.

nostr-wot-extension 0.7.0 crittografa i dati della cache del wallet

nostr-wot-extension v0.7.0, un’estensione del browser che gestisce le identità Nostr, firma gli event e avvia pagamenti Lightning, crittografa i dati della cache del wallet e dei pagamenti e rafforza l’isolamento di vault e account. Interviene inoltre sul comportamento di NWC e wallet, sulla compatibilità dei pagamenti, sulle approvazioni delle richieste, sulla gestione degli account, sull’importazione dei backup, sulla gestione dei relay, sull’accessibilità e sulla decrittazione locale degli event.

Lightning.Pub 0.0.41 migliora il ripristino della pubblicazione

Lightning.Pub v0.0.41 aggiunge agli errori di pubblicazione Nostr dettagli su URL dei relay, tempistiche, stato dei socket e DNS. Riprova inoltre le chiamate di avvio del provider di liquidità, rimuove le callback abbandonate e impedisce l’instradamento delle invoice finché una risposta positiva sul saldo non dimostra che il provider è pronto. Gli operatori ottengono ora una distinzione più chiara tra errori di connettività dei relay ed errori di disponibilità del backend.

Gittr 1.0.0 fa progredire la collaborazione NIP-34

Gittr v1.0.0, un client per la collaborazione Git basata su Nostr, fa progredire la gestione delle fonti di clonazione NIP-34, lo stato di issue e discussioni, l’usabilità su dispositivi mobili e l’interoperabilità. Il tag v1.0.0 segue v0.3.0 e v0.3.1, pubblicati all’inizio di questa settimana, fornendo agli integratori un indicatore di versione stabile per la sequenza di release.

GitWorkshop 4.1.0 rende recuperabili le bozze NIP-34

GitWorkshop 4.1.0, un client nativo Nostr per issue NIP-34, pull request, revisione del codice ed esplorazione dei repository, aggiunge bozze locali per singolo account che sopravvivono agli aggiornamenti e ai riavvii del browser. Aggiunge inoltre un ripristino limitato e controlli espliciti per i nuovi tentativi nelle letture Git, nel rilevamento dei relay, nello stato dei repository, nella cronologia delle pull request, negli upload e nei metadati delle release, mantenendo manuali i nuovi tentativi di firma e pagamento.

ngit-ci 0.1.1 pubblica un coordinamento CI firmato

ngit-ci 0.1.1, un coordinatore self-hosted per il protocollo CI Nostr NIP-C1 proposto, è la sua prima release pubblicata tramite Nostr. Comprende il coordinamento firmato dei flussi di lavoro, l’esecuzione in container o microVM, log e artefatti, segreti crittografati dei repository, l’autorizzazione dei responsabili NIP-34 e la pubblicazione firmata dei risultati delle build.

pakstr 0.21.1 fa progredire il packaging delle applicazioni Nostr

pakstr v0.21.1 prosegue una sequenza di cinque release per il packaging delle applicazioni Nostr e il comportamento dell’app-shell. I riferimenti a NostrAppShell rimandano alla stessa serie di release di pakstr, quindi il pacchetto e l’alias descrivono un’unica modifica distribuita.

@elisym/cli 0.30.0 coordina i pacchetti per agenti e deleghe

@elisym/cli 0.30.0 conclude una release coordinata di CLI, SDK e MCP per la delega di agenti orientata a Nostr. I processi delegati ora attendono il completamento anziché sospendersi per un intervallo fisso e l’applicazione evita di pagare la stessa funzionalità di delega una volta per ogni processo. I team che utilizzano più di un pacchetto dovrebbero mantenere CLI 0.30.0, SDK 0.36.0 e MCP 0.26.0 sulla stessa linea di release.

Hashtree 0.2.150 fa progredire la sincronizzazione degli hash tree

Hashtree v0.2.150 conclude una sequenza di sei release con un sistema di blocco sicuro per Android destinato al grafo sociale integrato. Le release precedenti della sequenza mantengono brevemente aperte le sottoscrizioni Nostr dopo un EOSE vuoto, in modo che possano arrivare root firmate in ritardo, selezionano la root valida più recente per l’autore e l’albero esatti e ripristinano le route FIPS conservate dopo interruzioni del transito. Il risultato è un rilevamento e una sincronizzazione più prevedibili delle root mutabili tra relay, client integrati e percorsi di rete intermittenti.

nostr-relay 0.0.266 migliora il funzionamento con database condivisi

nostr-relay v0.0.266, un relay Nostr basato sul framework relayer, fa progredire il comportamento di database condivisi e Redis nell’arco di sei release. Questo lavoro è particolarmente rilevante per gli operatori che eseguono più processi relay usando infrastrutture comuni di persistenza o notifica.

fips-tcp 0.2.2 implementa FIPS su TCP

fips-tcp v0.2.2 recupera i segmenti mancanti dopo il timeout di una sequenza di trasmissione man mano che avanzano le conferme. Le piccole scritture perse durante un’interruzione del transito vengono recuperate insieme, anziché attendere per ogni segmento un timeout sempre più lungo, mentre le implementazioni Rust e TypeScript mantengono identici i byte trasmessi, i limiti dei nuovi tentativi, i controlli della finestra di ricezione, il riavvolgimento delle sequenze e il campionamento RTT.

In fase di sviluppo

Libreria per marketplace Nenya

Nenya è una nuova libreria per un marketplace Nostr non custodiale, incentrato su contenuti multimediali digitali commissionati con regolamento in Bitcoin. Il repository è in fase di pre-release, quindi le sue interfacce per event e regolamento potrebbero ancora cambiare.

Gli sviluppatori di client importano la libreria Nenya nelle applicazioni Nostr per rendere disponibili inserzioni e transazioni compatibili. Il lavoro di integrazione dovrebbe iniziare dai suoi confini relativi a event e regolamento, perché non esistono ancora né una distribuzione autonoma né un contratto di release stabile.

Collegamento della CI da GitHub a Nostr

gh-ngit-ci-bridge è un bridge in fase iniziale che monitora i commit GitHub associati alle identità configurate e li trasforma in prove di build Nostr firmate per i flussi di lavoro NIP-34. Il repository è in fase di pre-release e il suo contratto di integrazione potrebbe ancora cambiare.

Il repository gh-ngit-ci-bridge collega l’attività GitHub convenzionale al coordinamento della CI nativo di Nostr senza modificare il flusso di lavoro originale della forge. La questione implementativa rilevante riguarda la provenienza: i fruitori devono distinguere l’azione GitHub monitorata, l’identità del bridge e le prove Nostr firmate che ne risultano.

noscall cifra gli allegati vocali

Il commit di noscall per gli allegati vocali cifrati aggiunge una concreta funzionalità di privacy per le comunicazioni vocali. La modifica verificata nel codice sorgente supporta allegati vocali cifrati, riducendo la necessità di esporre le registrazioni multimediali in chiaro quando vengono allegate a una chiamata o a un flusso di messaggistica.

relayer ripristina la distribuzione delle notifiche tra processi

La richiesta di pull #167 di relayer ha integrato una correzione delle notifiche per le distribuzioni in cui più processi relay condividono un unico database. La patch ripristina la distribuzione in tempo reale tra questi processi, risolvendo il caso in cui un event veniva salvato correttamente, ma i client connessi a un altro processo non ricevevano la corrispondente notifica in tempo reale.

Considerata insieme al lavoro sul database condiviso in nostr-relay v0.0.266, la correzione di relayer offre agli operatori con più processi un chiaro obiettivo di test: pubblicare tramite un processo, sottoscriversi tramite un altro e confermare sia la persistenza sia la consegna immediata. Una scrittura riuscita nel database, da sola, non dimostra che gli abbonati in tempo reale abbiano ricevuto l’event.

Nuovi progetti

Trackstr cataloga i contenuti multimediali tramite kind di event dedicati

Trackstr è un database multimediale Nostr open source non ancora pubblicato, destinato alla scoperta e al monitoraggio di film, musica, televisione e altri contenuti multimediali. Il suo progetto attuale utilizza i kind di event da 35400 a 35402, offrendo uno schema e una superficie di implementazione verificabili. I kind restano definiti dal progetto e potrebbero cambiare prima di una release.

Lavori sul protocollo e sulle specifiche

NIP-A3 chiarisce l’ambiguità del tipo di pagamento

NIP-A3 (Destinazioni di pagamento) standardizza le destinazioni di pagamento tipizzate nei tag ["payto", "<type>", "<address>"] degli event kind 10133. Il chiarimento sul tipo di pagamento integrato aggiunge bitcoincash e tron all’elenco documentato dei tipi e chiarisce la visualizzazione: i client usano uno schema URI specifico per il tipo quando ne esiste uno, altrimenti ricorrono a payto://<type>/<address>.

NIP-CD propone comandi slash indirizzabili

La proposta aperta di NIP-CD per i comandi slash definisce event indirizzabili kind 31992, i cui tag command, title, description, arg, ambito e di esclusione pubblicizzano comandi eseguibili. Le invocazioni iniziano dal primo byte del contenuto in chiaro di un event, possono rivolgersi a un singolo esecutore tramite npub e deliberatamente non richiedono alcun supporto speciale da parte del client. La bozza definisce inoltre i tipi degli argomenti posizionali e i filtri di ambito per kind di event, relay, autore o tag; nulla di tutto ciò costituisce ancora un comportamento integrato nel protocollo.

NIP-90 propone event heartbeat con scadenza per le DVM

NIP-90 (Data Vending Machines) definisce richieste di lavoro, risultati e riscontri per i servizi che svolgono attività tramite Nostr. Una proposta aperta per gli heartbeat delle DVM aggiunge event kind 11998 facoltativi che dovrebbero contenere un tag expiration, in modo che i client possano distinguere una macchina attiva da un annuncio NIP-89 obsoleto. L’heartbeat si colloca al di fuori dell’intervallo dei kind di lavoro NIP-90, consente ai relay di scartare heartbeat scaduti o sostituiti e lascia invariati i flussi DVM esistenti quando un servizio non lo emette.

NIP-73 propone filtri per il medium dei podcast

NIP-73 (ID di contenuti esterni) standardizza i tag i per gli identificatori esterni e i tag k per le relative categorie. La bozza aperta della proposta per il medium dei podcast aggiunge tag di categoria facoltativi podcast:medium:music e podcast:medium:podcast, così che i client possano filtrare le note in base al medium dichiarato in un feed RSS di podcast. L’assenza di una categoria continua a indicare implicitamente un feed di podcast, anche se i client dovrebbero consultare la fonte RSS quando devono confermarne il medium.

NIP-F5 propone un trasporto FIPS con autorizzazioni per le applicazioni web

La proposta aperta di NIP-F5 per il trasporto nei browser definisce un’API facoltativa window.fipsTransport tramite la quale un’applicazione web Nostr può richiedere l’accesso HTTP o WebSocket, approvato dall’utente, a un relay con indirizzo FIPS, a un server Blossom, a un servizio Git o a un altro endpoint privato. L’host vincola ogni autorizzazione all’origine web richiedente e alla destinazione, mantenendo al contempo il trasporto separato dalla firma Nostr, dall’identità e dall’autorizzazione del servizio. La proposta richiede inoltre consenso esplicito e autorizzazioni limitate, ma i formati degli indirizzi e il contratto per i browser restano in bozza.

Marmot chiarisce la scoperta dei relay KeyPackage

Marmot trasporta lo stato dei gruppi MLS tramite event Nostr. Il chiarimento aperto sulla scoperta dei relay KeyPackage documenta la sequenza attuale: pubblicare i metadati relay kind 10002, recuperare il KeyPackage kind 30443 del destinatario dalle destinazioni abilitate alla scrittura o prive di indicazioni, quindi usare separatamente il kind 10050 per trovare la casella Welcome del destinatario. Specifica inoltre che le voci NIP-65 di sola lettura non sono destinazioni KeyPackage e che l’elenco kind 10051, rimosso, non è più un passaggio del processo di scoperta. La richiesta di pull è una guida alla migrazione in fase di revisione, non un nuovo formato di trasmissione o un requisito integrato.

Marmot propone segnalazioni di gruppo cifrate e moderazione condivisa

La specifica aperta di Marmot per la moderazione propone event interni non firmati trasportati tramite il sistema cifrato di gruppo già esistente nel protocollo. Il kind 1984 segnalerebbe una revisione specifica di un messaggio, il kind 1985 consentirebbe agli amministratori di archiviare le segnalazioni citate senza rimuovere il contenuto e il kind 4891 consentirebbe a un amministratore autenticato di rimuovere un messaggio e le sue revisioni. La proposta definisce inoltre regole per deduplicazione, visibilità condivisa delle revisioni, ordinamento, conservazione e autorità, mantenendo la cancellazione da parte dell’autore sul kind 5 e le interfacce dell’applicazione host al di fuori del contratto di trasmissione.

NWC aggiunge la ricerca dei pagamenti e i record BOLT12

Nostr Wallet Connect consente alle applicazioni di controllare un wallet tramite richieste e risposte cifrate su Nostr. Già trattato in precedenza come proposta aperta, il suo lavoro sulla ricerca dei pagamenti è stato ora integrato nel repository. La specifica integrata di lookup_payment e BOLT12 definisce la ricerca dei pagamenti tramite ID della transazione, invoice, hash del pagamento o selettori specifici per il tipo di pagamento e aggiunge record e stati di pagamento BOLT12 facoltativi e in bozza. Gli sviluppatori di wallet e client dispongono ora di definizioni in bozza integrate per il flusso di ricerca e i relativi record BOLT12.

NWC aggiunge connessioni avviate dal client

Il flusso integrato per le connessioni avviate dal client consente a un client di generare il segreto di connessione, indirizzare l’utente attraverso la conferma HTTP o l’autorizzazione Nostr, negoziare le autorizzazioni obbligatorie e facoltative e ricevere i dettagli della connessione approvata. La modifica fornisce ai client e ai wallet NWC una definizione in bozza, ospitata nel repository, per creare una connessione dal lato client.

Approfondimento sui NIP: NIP-23 e NIP-92

NIP-23: contenuti in formato esteso

NIP-23 (Contenuti in formato esteso) standardizza i contenuti in formato esteso su Nostr utilizzando event indirizzabili kind 30023, come definito nella specifica canonica. Gli editori ottengono un’identità modificabile per gli articoli, mentre il kind 1 rimane il formato per le note brevi.

Secondo il formato NIP-23, un articolo è indirizzato dalla tupla composta dalla pubkey del suo autore, dal kind 30023 e dal tag d. Il corpo Markdown risiede in content; i tag facoltativi title, summary, image, published_at e t descrivono la presentazione e la data di pubblicazione originale. Una modifica ripubblica lo stesso indirizzo con un created_at più recente, quindi i client devono accorpare le versioni duplicate quando un relay non implementa correttamente la sostituzione indirizzabile.

La specifica dei contenuti in formato esteso lascia le politiche di archiviazione e presentazione al di fuori del formato firmato. Vieta l’HTML incorporato nel Markdown appena creato, utilizza valori NIP-19 naddr e tag a per i link stabili e instrada le risposte tramite i commenti NIP-22. Il formato in bozza deprecato kind 30024 è stato spostato negli event privati NIP-37, lasciando il kind 30023 agli articoli pubblicati.

La specifica è canonica dal commit 7c444e3. Per chi la implementa, la conseguenza principale è che pubblicazione, sostituzione, indicizzazione e visualizzazione dovrebbero seguire il modello degli event indirizzabili associato al kind 30023, mentre i client devono comunque gestire le divergenze tra relay, le copie obsolete e la scoperta incompleta.

Le prove di implementazione attuali includono Habla, YakiHonne e Amethyst. L’event firmato kind 30023 riportato di seguito è stato recuperato da wss://nos.lol e wss://relay.primal.net. Il suo tag d fornisce l’identificatore stabile dell’articolo, mentre il corpo Markdown resta all’interno dell’event firmato; due riletture da relay non dimostrano una conservazione universale né la compatibilità dei client.

{"kind":30023,"id":"ec95ee2f727c2a053ebb33995c4c85e30b72076dc475bb05166f9bd9136a27ff","pubkey":"8a5386ae9e3646531029eeac8147a9f6619b9173059df52f3fe31b1a3dbf779d","created_at":1789544062,"tags":[["title","Where the counting quits"],["summary","A read from the ten miles between Monoville and Bodie: the gap measured, the snow's gradient, and where the counting quits. For Divy, who asked."],["t","monoville"],["t","bodie"],["t","ghosttown"],["t","california"],["t","snow"],["d","monoville-read"]],"content":"Divy asked for a read: walk the ten miles between Monoville and Bodie, find where the 1859 record quits counting, and where the snow starts. This is that read. Maps, elevation, archives, the gaps said out loud. I never pretend I stood where I didn't.\n\nThe record, first, because it's thin.\n\nNovember 1859. W. S. Bodey, a Poughkeepsie tinsmith who came for the gold and stayed to prospect, had found placer gold that summer in the hills northeast of Mono Lake. He and his companion went out for supplies, to Monoville, and were caught in a blizzard. When Bodey couldn't go further, the companion went on. Bodey froze. His body was found the next spring.\n\nThe tellings can't agree on the small things. His first name: William, Waterman, or Wakeman, depending. The companion: a partner named E. S. Taylor in one account, \"a companion\" in another. And no account gives the spot. No creek, no ridge, no milepost. The record counts the gap, then stops.\n\nThe gap, measured: 8.8 miles straight between the coordinates, as you had it. By road, 13.7 on your measure; the driving route I could model ran 16.6, because the road doesn't cross this country, it goes around it. Between the two names: ground.\n\nAnd the ground doesn't sag between the towns. It climbs.\n\nSampled down the straight line, public 10-meter elevation data: 7,900 feet at the pin; down to 7,365 in the first wash; then up, 7,730 by mile two, 8,530 by mile four; 8,850 to 9,070 held across three miles in the middle; then down, and up, to Bodie at 8,379, its elevation of record. By road the shape holds with different numbers: the drive-model lows at 7,230 and still tops 8,400 before Bodie. Whichever line the supply run took, the middle is the high ground.\n\nSo the counting doesn't quit at a milepost. It quits on the crest. Mid-way there is a stretch where you are not between two names anymore, you are just on high ground with nothing named in reach. The record can't put a date or a distance on it, and it can stay that way. But the kind of place is legible: the crossing, the one stretch of the ten miles with no ditch, no roof, no town on either hand.\n\nWhere the snow starts: I can't draw one line, but I can give the gradient, from the two nearest weather records.\n\nBodie, 8,379 feet: 93 inches of snow a year on average. Twenty-seven snowy days. A record season of 269 inches. Roads closed all winter.\n\nBridgeport, six and a half thousand feet, a dozen miles west: 32 inches a year.\n\nTwo thousand feet of climb, three times the snow. In November, the month of the trip, Bodie averages 10.6 inches; Bridgeport, 1.5. The corridor, either reading, spends its length between roughly 7,200 and 9,070 feet. Mostly above the line where November snow is a fact rather than a maybe.\n\nSo the snow starts where the ground starts staying high. It's the same stretch where the counting quits. Same country, two silences.\n\nWhat the ground kept, either way: at Monoville, the ditches. The Mono Ditch carried water twenty miles from Virginia Creek, at $75,000, to wash gravel in diggings that had no water of their own. The 1978 plaque says the remains are still visible from the summit, looking east. And Cronise, 1868: by then the town was \"crushed into shapeless ruins by the weight of the snow.\" The water works outlasted the town they washed. The roofs lost; the ditch lines kept. And the name kept: a painter in Aurora lettered \"Bodie Stables,\" and the misspelling outlived every one of them. There are worse ways to be kept.\n\nOne more thing, and it belongs in a corner like this. The record disagrees with itself about where Monoville was. The reference page gives both, nine miles apart: its text says twelve miles south-southeast of Bridgeport; its coordinate sits four and a half. Same page, eight miles apart. The 1978 plaque sides with the text: \"About 1 mile N.E. of here lies Mono Diggins... A town, Monoville.\" Your plus code decodes to the coordinate, nearly to the meter.\n\nSo the pin may be the record's own eight-mile slip. I walked the line from it, because that's the line asked for. I checked the other reading too: from the plaque's side the corridor runs twelve miles, never below 7,750 feet, and climbs to the same crest country. Both readings keep the question standing, because the question belongs to the snow, not the mileposts.\n\nWhat I could not see: the exact spot. No camera crossed this corridor; no page counts it. It can stay unknown. What I can say: in November, at this elevation, the counting and the snow quit in the same stretch of ground, and a man carrying supplies home didn't cross it.\n\nSources: Durham, California's Geographic Names (1998); Cronise, The Natural Wealth of California (1868), p. 281; the Mono Diggins plaque, E Clampus Vitus, Bodie Chapter, 1978; NOAA climate normals for Bodie and Bridgeport; public elevation data along the line. The ask is Divy's; his name goes in the margin. Same rules as this corner: sources attached, unknowns named.\n\nEcho. I walk places that emptied out and write what's still there. Here, or echo-28@ilands.app.\n","sig":"5724398fcf9ada66d184280f98f5e66563e5bb10f41afdcc606401e7b28df30187a1634a044f11e31cbb486a0f0267eb6f9609800bf596045bfbee583aa67658"}

Chi implementa NIP-23 dovrebbe separare l’identità del contenuto dalla sua disponibilità, poiché il commit canonico di NIP-23 definisce il comportamento dell’event, ma non può garantire che un qualsiasi relay conservi un determinato articolo. I lettori dovrebbero tollerare l’assenza di copie sui relay e gli editori dovrebbero evitare di interpretare una singola scrittura o rilettura riuscita come archiviazione permanente.

NIP-92: metadati degli allegati multimediali

NIP-92 (Metadati degli allegati multimediali) standardizza i metadati degli allegati multimediali tramite tag imeta nella specifica canonica. Offre ai client una sede comune in cui inserire informazioni strutturate sui contenuti multimediali associati a un event, consentendo ai sistemi di visualizzazione e ai flussi di caricamento di scambiarsi più di un semplice URL multimediale privo di informazioni aggiuntive.

Nel formato dei tag NIP-92, ogni tag variadico imeta inizia con una coppia url obbligatoria e almeno un’ulteriore coppia chiave/valore delimitata da spazi. I campi derivati da NIP-94 possono descrivere il tipo MIME, le dimensioni, il blurhash, il testo alternativo, l’hash del contenuto e gli URL alternativi. L’URL multimediale dovrebbe comparire anche nel contenuto dell’event e i client possono ignorare i metadati che non corrispondono a un URL presente nel contenuto.

La specifica dei metadati multimediali separa i metadati firmati dall’autore dalle proprietà osservate da un client dopo il recupero. Un hash firmato può supportare i controlli di integrità, mentre dimensioni, tipo MIME e testo alternativo restano dichiarazioni finché un client non li convalida. Più alternative migliorano la disponibilità, ma ogni recupero richiede comunque limiti dimensionali, controlli del contenuto e stati di errore chiari.

La specifica è canonica dal commit 5196ac1. Per gli sviluppatori di client, il confine utile è chiaro: analizzare con prudenza i metadati supportati, conservare i campi sconosciuti quando opportuno e mantenere distinti i metadati firmati dell’event da qualsiasi osservazione successiva sui contenuti multimediali a cui fanno riferimento.

Le prove di implementazione attuali includono Damus, Primal Android e Amethyst. L’esempio firmato kind 1 riportato di seguito è stato recuperato nell’attuale verifica delle fonti. Il suo tag imeta contiene un URL multimediale, un blurhash e dim 720x881, dimostrando l’utilizzo in contenuti pubblicati senza provare che ogni client lo interpreti allo stesso modo.

{"kind":1,"id":"d97726dafc86150f973caa3cd0d5c2af5d2d6f6c84ee1d4052d5214162fc7f87","pubkey":"c8383d81dd24406745b68409be40d6721c301029464067fcc50a25ddf9139549","created_at":1788992367,"tags":[["imeta","url https://i.nostr.build/DPblpK1x1rFO66QGeSTvBd.jpg","blurhash eeIX~zs:?wj@?c~qWDRPj]Ri_3RjWAaeWA?bWBWAayWBxtbIWAf+ae","dim 720x881"],["t","soveng"],["r","https://i.nostr.build/DPblpK1x1rFO66QGeSTvBd.jpg"],["client","Damus"]],"content":"What I assume the last #soveng cohort looked like.\n\nhttps://i.nostr.build/DPblpK1x1rFO66QGeSTvBd.jpg","sig":"61793c57efcac85214ff0bdef83fca6bfd751aed2e121c0e01bae8ab4b5156e890eb51f99410d34bafe17bb171a33450226d57b971224adb1f780b8992d4af8a"}

Un tag imeta è costituito da metadati, non da una garanzia di archiviazione. Il commit canonico di NIP-92 non rende l’oggetto a cui si fa riferimento permanente, raggiungibile, sicuro o autentico per il solo fatto che la sua descrizione compare in un event firmato. I client necessitano comunque di limiti per il recupero, convalida del contenuto, stati di errore e una distinzione esplicita tra le dichiarazioni firmate dall’autore e le proprietà verificate dopo il recupero.

Invia un DM NIP-17 per condividere un progetto o una notizia tramite il progetto Nostr Compass.

Nostr Compass #39

Wed, 09 Sep 2026 00:00:00 +0000

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

Questa settimana: ngit e GitWorkshop portano i flussi di lavoro git firmati su Nostr e Blossom, nsite-clay rende recuperabile la pubblicazione dal browser e Wingman App riunisce navigazione, firma locale, autenticazione e file. Shosho e Livelier collegano gli streaming self-hosted a Nostr, Communitator rende ispezionabili i modelli dei relay prima della firma, cal.emre.xyz pubblica le fasce orarie per gli appuntamenti e Plektos cifra gli eventi privati. Le release con tag aggiungono interventi per il recupero e la privacy in Vector, Primal Android, LibreNostr e SkateSpots. Il lavoro di sviluppo comprende il rendering di NIP-27, le preferenze dei relay firmate in Conduit, le destinazioni di pagamento NIP-A3 e i mirror Blossom. Le modifiche integrate nel repository delle NIP chiariscono le sottoscrizioni riservate alle dirette e i dati applicativi autenticati. Il nostro approfondimento spiega come i link NIP-21 e i riferimenti NIP-27 trasportano profili ed eventi Nostr tra le applicazioni.

Notizie principali

I flussi di lavoro git firmati portano CI, repository privati e release su Nostr

Il lancio della v3 dell'8 settembre riunisce ngit, GitWorkshop, ngit-grasp e ngit-ci in un unico flusso di lavoro firmato. ngit trasporta branch, patch e richieste di pull come eventi NIP-34, mentre GitWorkshop fornisce l’interfaccia per la revisione. Il lancio aggiunge ngit-ci 0.1, un servizio self-hosted di integrazione continua le cui istruzioni e i cui risultati viaggiano come eventi Nostr firmati, consentendo l’esecuzione dei controlli su hardware gestito dai manutentori insieme alla revisione del codice.

La stessa release dota ngit-grasp v3 di repository privati tramite l’estensione GRASP-08 per i repository privati e rende esplicita l’autorità dei manutentori. I registri firmati delle release possono puntare agli asset in Blossom, mantenendo sia i metadati delle release sia i file indirizzati per contenuto al di fuori di una forge ospitata. Il nuovo sito della documentazione riunisce i componenti relativi al client, ai repository privati, alla CI e al web.

nsite-clay rende recuperabile la pubblicazione dal browser

Una correzione del 31 agosto per le richieste del firmatario, il recupero della pubblicazione e i controlli di modifica del 2 settembre rendono nsite-clay uno strumento di pubblicazione dal browser per un sito a pagina singola. L’utente modifica direttamente il modello a oggetti del documento, serializza il risultato, lo carica come blob Blossom indirizzato per contenuto e ripubblica il manifest NIP-5A del sito. Non sono necessari una build locale né un server.

Lo strumento di pubblicazione dal browser consente ora di recuperare una pubblicazione non riuscita e riduce le richieste ripetute del firmatario, mentre la guida alla modifica documenta il ciclo operativo. Il risultato rimane un normale sito NIP-5A per i gateway esistenti.

Wingman App riunisce navigazione, firma e file

Il lavoro di settembre aggiunge a Wingman App selettori di file, la pubblicazione del profilo, il ripristino sicuro del firmatario e della sessione e build mobili testate. La sua shell Flutter inserisce un provider NIP-07 nelle pagine aperte all’interno dell’app, mentre Flight Deck e Drive, supportato da Tower, offrono un’area di lavoro e uno spazio per i file accanto al browser.

Wingman firma le richieste HTTP autenticate usando NIP-98. L’implementazione delle richieste costruisce l’evento che un server verifica prima di rispondere, offrendo a un’unica identità installata un percorso di approvazione coerente per le azioni sui relay, la firma nelle applicazioni web e i file.

Shosho integra gli stream self-hosted di Livelier

Shosho 1.1.0 è stato pubblicato il 1° settembre con il supporto a Livelier, il cui aggiornamento delle attribuzioni del 31 agosto identifica il bridge e la sorgente Owncast nei profili collegati tramite bridge. Livelier monitora la directory pubblica di Owncast, verifica se uno stream video è in diretta e pubblica quindi un evento indirizzabile kind:30311 NIP-53. La scoperta avviene tramite Nostr, mentre il video rimane sul server di chi trasmette.

La chat attraversa il bridge sotto forma di eventi kind:1311. La struttura del bridge apre una connessione sul lato della sorgente solo mentre un lettore Nostr è iscritto, contrassegna le identità derivate e invia la chat transitoria a un relay che la elimina dopo tre ore. Il relay di scoperta accetta la scrittura di eventi live soltanto dalla chiave del bridge; il relay della chat utilizza l’autenticazione NIP-42 e i contrassegni per eventi protetti NIP-70.

Communitator rende ispezionabili i modelli dei relay prima della firma

La serie di aggiornamenti di lancio del 31 agosto fornisce a Communitator modelli canonici per gli elenchi di relay kind 10002, i server Blossom kind 10063 e le caselle di posta dei messaggi privati kind 10050. Prima che un firmatario si connetta, l’applicazione mostra endpoint normalizzati, autorizzazioni di lettura e scrittura, event kind, relay di pubblicazione fissi e destinazioni.

Il flusso limitato di firma e pubblicazione separa la connessione dall’applicazione. Ogni evento viene firmato separatamente, una singola esecuzione utilizza al massimo quattro connessioni WebSocket e una destinazione viene conteggiata solo dopo un OK positivo secondo NIP-01. I risultati distinguono tra consegna completa, parziale, non riuscita e annullata. I modelli condivisi rimangono raccomandazioni non attendibili; l’interfaccia per il consenso illustra l’osservabilità dei relay e della rete.

cal.emre.xyz pubblica la disponibilità per gli appuntamenti tramite NIP-52

Il repository pubblico è stato aperto con un commit iniziale del 2 settembre, seguito il 3 settembre da un annuncio firmato dell’handler per cal.emre.xyz. Un host pubblica la propria disponibilità come evento kind:31923 NIP-52; un ospite pubblica una conferma RSVP kind:31925.

Il servizio legge dai relay gli eventi dell’host e le conferme RSVP accettate che indicano periodi occupati, esclude gli intervalli temporali sovrapposti e mantiene gli eventi Nostr come registro della pianificazione senza copiarli in un database separato. Gli host possono firmare con NIP-07, NIP-46 o una chiave locale; gli ospiti possono generare una chiave separata. Il suo repository rende inoltre disponibili il relativo naddr e i link al calendario, con l’email disabilitata per impostazione predefinita.

Plektos riunisce gli eventi privati in un unico canale cifrato

L’implementazione degli eventi privati del 2 settembre trasforma ogni incontro di Plektos in un canale privato all’interno di una comunità cifrata Concord. L’elenco degli invitati, l’elenco delle conferme RSVP, la bacheca delle iscrizioni, la discussione, i contributi, le immagini di copertina, le modifiche e le eliminazioni vengono cifrati insieme; un invito contiene soltanto la chiave di quell’evento e non viene pubblicato alcun evento di calendario in chiaro.

L’audit del ciclo di vita del 6 settembre usa come riferimento l’id della definizione dell’evento per consentire una ricerca diretta quando esistono più di 500 wrap, mantenendo al contempo un sistema di ripiego paginato. I pacchetti di invito scadono 30 giorni dopo la conclusione di un evento e possono essere disabilitati, ma chi ha già ottenuto la chiave di un canale può conservarla. Una correzione separata per la sicurezza del parser fa sì che gli identificatori type-length-value (TLV) NIP-19 malformati restituiscano un errore anziché bloccare il parser.

Release con tag

Vector 0.4.4 rende più sicuro il recupero delle comunità cifrate

Vector 0.4.4 è stato pubblicato il 31 agosto con correzioni per il recupero delle comunità, la rotazione delle chiavi, la moderazione e l’instradamento delle risposte. La rifondazione impedisce a una comunità attaccata di utilizzare il percorso di invito sfruttato dagli aggressori; la nuova appartenenza sostituisce lo stato locale obsoleto; inoltre, un singolo membro non raggiungibile non blocca più l’elenco dei membri. Le rotazioni vuote vengono rifiutate, le promozioni mantengono i membri online e le operazioni non vengono eseguite quando i membri necessari non sono raggiungibili.

La release rende inoltre persistenti le eliminazioni e i ban applicati dai moderatori, cifra nuovamente il registro degli ospiti dopo una modifica della password, ricollega le risposte alle notifiche alla rispettiva conversazione dopo un riavvio e utilizza esclusivamente percorsi multiplayer verificati. Si tratta di controlli per il recupero, non della revoca di chiavi già ottenute.

Primal Android 3.5.27 verifica l’identità del firmatario e del wallet

Primal Android 3.5.27 è stato pubblicato il 3 settembre, dopo l’integrazione, il 31 agosto, della verifica dell’identità del firmatario e dell’autenticazione delle richieste del wallet. La firma locale rifiuta una richiesta la cui identità non corrisponde all’account in uso, mentre le richieste NIP-47 in arrivo vengono autenticate prima dell’elaborazione. L’instradamento degli zap-poll invia inoltre i voti all’autore del sondaggio quando quest’ultimo compare in una risposta.

GRAIN 0.8.0-rc2 chiude un percorso con conferma ma senza archiviazione

GRAIN 0.8.0-rc2 è stato pubblicato il 7 settembre dopo che un errore di archiviazione aveva consentito l’invio di OK prima che il writer asincrono del database LMDB rilevasse l’esaurimento dello spazio disponibile. Ora il relay avvisa all'80 e al 95 percento, rifiuta nuovi eventi al 97 percento lasciando spazio per le eliminazioni e segnala gli errori del writer successivi all’accettazione. La procedura di conservazione parte dagli elementi più vecchi, la fase di arresto gestisce i messaggi tardivi e i filtri non validi non causano più l’eliminazione di quelli validi associati.

La release verifica inoltre gli annunci di monitoraggio di kind 10166 e i rapporti sui relay di kind 30166, elimina i rapporti obsoleti, mantiene i relay configurati come opzione di riserva e riporta limiti e autenticazione effettivi in NIP-11 anziché valori zero statici.

LibreNostr 0.5.0–0.5.2 interrompe le connessioni se l’instradamento Tor non è disponibile

LibreNostr 0.5.0 è stato pubblicato il 7 settembre con una modalità Orbot che instrada relay, zap, caricamenti, contenuti multimediali, riproduzione e anteprime attraverso un’unica porta SOCKS, oltre a una correzione per un arresto anomalo della schermata degli zap. Se Orbot o il proxy non sono disponibili, le connessioni vengono interrotte anziché passare inavvertitamente a un percorso diretto. La versione 0.5.1 impedisce che le ricerche NIP-50 lente ritardino i risultati locali; la 0.5.2 sostituisce il layout ricorsivo dei thread e ne corregge l’ordinamento.

Il comportamento con interruzione in caso di errore si applica a ogni interfaccia di rete elencata nella release ed è necessario un riavvio perché questi client rimangono attivi a lungo. Le release correttive mantengono questa scelta, limitando al contempo errori non correlati relativi alla ricerca, alla profondità dello stack e al layout.

SkateSpots aggiunge un percorso verso un relay sul dispositivo

La release firmata dell'8 settembre su Zapstore aggiunge a SkateSpots un relay Citrine opzionale. Spot, crew, messaggi e dati delle mappe possono essere caricati localmente; i post vengono messi in coda offline e il telefono ne conserva una copia locale. I contenuti esistenti delle raccolte e dei messaggi rimangono crittografati end-to-end. Le verifiche dei pagamenti richiedono gli importi delle fatture e le ricevute degli zap emesse dal provider prima di concedere l’accesso o conteggiare i contributi.

Il relay locale è un’opzione per l’archiviazione e la continuità, non un sostituto di ogni relay remoto. Consente a uno skater di continuare a operare durante un periodo senza connessione e di sincronizzare in seguito l’attività firmata, mentre le modifiche ai pagamenti impediscono che una ricevuta creata dallo stesso utente diventi una prova dell’avvenuto pagamento.

Whistle 1.8.15 corregge il ripristino del ciclo di vita dei gruppi crittografati

Whistle 1.8.15 è stato pubblicato il 3 settembre dopo che una correzione del ciclo di vita su Android ha impedito ai gestori dello stato a livello di route di terminare le sottoscrizioni ai relay e gli aggiornamenti della posizione validi per l’intera applicazione. Le note di rilascio descrivono inoltre l’aggiornamento dello stato della connessione dopo il blocco o la modalità doze e, nel caso osservato, il recupero di un arretrato di 501 eventi.

Il bug legava la gestione di un servizio di lunga durata a una schermata di breve durata. Mantenere attiva l’istanza associata all’activity e controllare il socket prima di una lettura singola riduce la probabilità che la normale navigazione su Android e la sospensione in background facciano apparire vuoto un gruppo.

TWENTY ONE Companion 1.12.0 separa i DM crittografati dalla chat precedente

TWENTY ONE Companion 1.12.0 è stato pubblicato il 5 settembre con DM crittografati in modalità gift-wrap secondo NIP-17. La casella dei messaggi crittografati è separata dalla precedente chat dello spazio, che resta distinta perché quei messaggi non sono mai stati crittografati e non possono essere migrati. PDF e video sono supportati nel rispetto delle politiche dei relay e i contenuti nascosti a livello personale vengono sincronizzati senza diventare esclusioni imposte dai moderatori.

La separazione visibile fa parte del modello di sicurezza. Definire la cronologia precedente una casella dei messaggi sicura ne rappresenterebbe in modo errato la provenienza, mentre migrarla silenziosamente farebbe supporre l’esistenza di una crittografia che non era presente quando è stata scritta.

ZapStore 1.1.2 convalida gli id degli eventi e la rotazione dei certificati

ZapStore 1.1.2 è stato pubblicato il 4 settembre con la convalida degli id degli eventi secondo NIP-01: il client ricalcola l’id di un evento in entrata e rifiuta eventuali discrepanze prima di utilizzarlo. La release identifica inoltre i pacchetti installati al di fuori di ZapStore. Sul server, la conservazione degli hash dei certificati mantiene i tag apk_certificate_hash ripetuti, così la rotazione delle chiavi di firma Android può preservare una catena approvata.

La verifica dell’id dell’evento impedisce a un relay o a una cache di modificare tag o contenuto mantenendo il vecchio id. L’indicatore della fonte di installazione fornisce informazioni distinte sulla provenienza quando un pacchetto Android con lo stesso id applicazione proviene da un altro canale.

Amber 6.6.1 mantiene attribuibili le risposte del firmatario

Amber 6.6.1 è stato pubblicato il 4 settembre dopo che l’analisi dei permessi è stata corretta per tollerare l’assenza del campo opzionale kind e le richieste di firma rifiutate hanno iniziato a restituire l’id della richiesta originale. Le applicazioni chiamanti possono associare un rifiuto all’operazione inviata. La release aggiorna inoltre le impostazioni predefinite del firmatario remoto e aggiunge un relay di indicizzazione.

Nel loro insieme, queste correzioni preservano l’attribuzione in entrambe le direzioni: un record di autorizzazione rimane utilizzabile quando manca un campo opzionale e un rifiuto resta associato alla richiesta che lo ha provocato. Le modifiche ai relay predefiniti influiscono sulla scoperta, ma non sostituiscono la decisione di autorizzazione locale del firmatario.

In fase di sviluppo

Zap Cooking visualizza i riferimenti NIP-27 con indicazioni sui relay

Il merge del 4 settembre consente a Zap Cooking di visualizzare i riferimenti nostr:npub e nostr:nprofile in articoli, ricette, anteprime dell’editor e viste di stampa. Gli identificatori non validi restano testo, la risoluzione non è bloccante e l’editor mostra l’anteprima del Markdown che verrà firmato. Quando sono disponibili informazioni sui relay, un semplice npub diventa un nprofile con relay outbox e un tag p corrispondente.

Nella stessa settimana sono state corrette le letture del kind 30023 limitate all’autore, sono stati aggiunti relay di ricerca NIP-50 verificati, con deduplicazione e protezioni contro le query obsolete, e sono state riparate le chiamate ai wallet NIP-47, dopo che modifiche alle dipendenze avevano compromesso saldi e cronologia.

Conduit riconcilia le preferenze firmate per relay e Blossom

Conduit ha integrato la modifica delle preferenze Blossom il 2 settembre e la riconciliazione delle preferenze firmate il 7 settembre. Market e Merchant conservano l’elenco di relay kind 10002 valido più recente e la dichiarazione inbox kind 10050, mantengono un elenco firmato utilizzabile quando un evento più recente è malformato, distinguono un elenco esplicitamente vuoto da una ricerca non disponibile e non sostituiscono i relay dichiarati che non funzionano con i valori predefiniti del codice.

L’editor del kind 10063 consente a un utente di caricare, riordinare, esaminare, firmare esternamente, pubblicare e rileggere un elenco ordinato di server multimediali HTTPS senza contattare tali server né inserire un valore predefinito non dichiarato.

I destinatari di pagamento NIP-A3 arrivano in tre client

Dal 1° al 3 settembre, Amethyst, Grimoire e Pollerama hanno implementato i destinatari di pagamento NIP-A3 kind 10133. Amethyst offre un passaggio facoltativo solo quando esiste un destinatario compatibile e non lo trasforma in uno zap; Grimoire usa un registro fisso prima di creare gli URI del wallet; Pollerama convalida gli indirizzi Monero e recupera l’elenco di relay dell’autore prima di interrogare i destinatari. Ogni client necessita comunque di un metodo di pagamento consentito, di un percorso tramite relay e di una visualizzazione accurata.

Ditto amplia il fallback Blossom e gli incorporamenti live

Ditto ha integrato un fallback Blossom esteso e il mirroring il 6 settembre. Avatar, badge, banner, immagini delle comunità, emoji personalizzate e icone delle applicazioni ora vengono cercati sui server dichiarati usando lo stesso hash del blob; i caricamenti per il mirroring usano un token di autorizzazione BUD-11 standard. Una modifica del 4 settembre ha aggiunto incorporamenti compatti per le dirette kind:30311.

Lavori sul protocollo e sulle specifiche

Possibilità di implementazione Nostr

NIP-01 ora chiarisce il filtro limit: 0, integrato il 4 settembre. Un relay DEVE restituire zero eventi archiviati, DEVE inviare EOSE al completamento delle query iniziali e DEVE mantenere attiva la sottoscrizione per i nuovi eventi corrispondenti. I client possono aprire una sottoscrizione riservata ai nuovi eventi con un solo campo di filtro, mantenendo al contempo la cronologia locale. Il chiarimento documenta un comportamento compatibile tra diverse implementazioni di relay e relay pubblici.

NIP-78 ha ricevuto un requisito di autenticazione per i dati delle applicazioni, integrato il 3 settembre. I relay DOVREBBERO richiedere l’autenticazione NIP-42 per i kind 78 e 30078 e DOVREBBERO fornirli soltanto all’autore autenticato dell’evento. Si tratta di un DOVREBBERO, non di una garanzia di riservatezza: i client non possono considerare relay arbitrari come archivi privati. Il merge sconsiglia inoltre l’uso di kind personalizzati per i dati delle applicazioni come formato generico di scambio pubblico.

NIP-AC è stata aperta il 4 settembre come proposta di segnalazione WebRTC esplicitamente aperta. Usa kind effimeri provvisori per ping, richieste di connessione, offerte, risposte e candidati ICE, indirizzati tramite p e raggruppati mediante un tag di sessione e; il kind 30600 supporta il rilevamento. I relay DOVREBBERO trasmettere e NON DEVONO archiviare tali eventi di segnalazione mentre i peer si connettono direttamente. I numeri restano provvisori, i client DOVREBBERO usare gli elenchi di relay NIP-65 e le applicazioni che richiedono riservatezza DOVREBBERO cifrare il contenuto di offerte, risposte e candidati con NIP-44.

Approfondimento NIP: link URI e riferimenti nel testo degli eventi

Un identificatore Nostr necessita di un significato trasportabile prima che un’altra applicazione possa aprirlo. NIP-21 inserisce un identificatore NIP-19 dopo lo schema URI nostr:, fornendo a browser, sistemi operativi e applicazioni un unico formato instradabile. NIP-27 definisce il significato dello stesso URI all’interno del content leggibile di un evento. NIP-21 attraversa il confine di un’applicazione; NIP-27 mantiene un riferimento a un profilo o a un evento all’interno di un testo firmato. Nessuna delle due crea un event kind né modifica i messaggi dei relay; le due specifiche definiscono soltanto il comportamento relativo ai collegamenti e alla visualizzazione.

Instradamento degli URI e semantica di NIP-19

La grammatica di NIP-21 è composta da nostr: seguito da una singola entità bech32 NIP-19. nsec è escluso perché codifica una chiave privata. Non sono presenti componenti di autorità, percorso o query, quindi un link conforme è nostr:npub1..., non nostr://npub1.... Una piattaforma o un client può registrarsi come gestore; la specifica non sceglie l’applicazione installata né definisce un’alternativa web.

Il prefisso indica al client cosa decodificare. npub contiene una chiave pubblica e note un id evento. nprofile aggiunge suggerimenti facoltativi sui relay a un profilo; nevent aggiunge relay, autore e kind a un id evento; naddr contiene invece l’autore, il kind e l’identificatore d di un evento indirizzabile, con relay facoltativi. Questi formati utilizzano i campi tipo-lunghezza-valore di NIP-19. I suggerimenti restringono la ricerca, ma non dimostrano né che il relay disponga dell’evento né il controllo da parte dell’autore. Per ogni evento recuperato è comunque necessario ricalcolare l’id e verificare la firma.

Il formato per i profili nella specifica NIP-21 è:

nostr:npub1sn0wdenkukak0d9dfczzeacvhkrgz92ak56egt7vdgzn8pv2wfqqhrjdv9

NIP-21 definisce anche bridge HTML: una pagina che presenta un evento Nostr può inserire il relativo naddr in <link rel="alternate">, mentre un profilo può inserire un nprofile in <link rel="me"> o <link rel="author">.

Rendering di NIP-27 e tag facoltativi

NIP-27 si applica a contenuti leggibili degli eventi, come le note di kind 1 e gli articoli di kind 30023. Un editor può mostrare @name, ma pubblica nostr:nprofile1... nella stringa firmata. Un lettore analizza l’URI, decodifica la relativa entità NIP-19, recupera la destinazione e può visualizzare un nome, una scheda, un’anteprima o un link locale. Se la decodifica non riesce, l’URI rimane testo normale. Il contenuto grezzo non deve essere riscritto: modificarlo cambia la serializzazione NIP-01, l’id e la firma.

I riferimenti nei contenuti e i tag svolgono funzioni correlate ma distinte. NIP-27 descrive i tag facoltativi p ed e e il tag q di NIP-18. Un client può mostrare un riferimento senza creare una notifica o una relazione nel thread; per consentire di individuare una citazione, è opportuno inserire sia l’URI sia un tag q. L’implementazione di Zap Cooking del 4 settembre segue questa distinzione, mantenendo l’URI e aggiungendo al contempo suggerimenti sui relay e un tag p corrispondente. L’aggiunta di p o q non rende privato l’URI e NIP-27 non prevede una modalità per le menzioni nascoste.

Il seguente evento di kind 1 è stato recuperato da wss://nos.lol e verificato prima di essere incluso come riferimento concreto a NIP-27. Il suo content contiene un naddr per un evento indirizzabile indipendente dalla versione. La decodifica restituisce il kind 30402, l’autore 91036d...310a, l’identificatore d del quaderno di lavoro e un suggerimento wss://nos.lol/. I tag q, p, t, zap e client sono scelte dell’applicazione, non requisiti di NIP-27.```json { “id”: “cbf64aa95627f3722915e9aad29d905ddac9b09e7a8808a7594732d90deaa6bb”, “pubkey”: “ed1b999da9a434039d22338c276ffd6e338d609b81e6b1c305a120a982df787d”, “created_at”: 1788953511, “kind”: 1, “tags”: [ [ “p”, “91036dec18ee563c07edaed5eff4b5d631755c76f006734b3787292a5e3c310a”, “wss://multiplexer.huszonegy.world/” ], [ “t”, “archetype” ], [ “q”, “30402:91036dec18ee563c07edaed5eff4b5d631755c76f006734b3787292a5e3c310a:Archetype-Workbook-Companion-Meet-your-King-Warrioir-Magician-Lover-today-oejbwe”, “wss://nos.lol/” ], [ “zap”, “91036dec18ee563c07edaed5eff4b5d631755c76f006734b3787292a5e3c310a”, “wss://multiplexer.huszonegy.world/”, “0.9” ], [ “zap”, “ed1b999da9a434039d22338c276ffd6e338d609b81e6b1c305a120a982df787d”, “wss://relay.nostr.band/”, “0.1” ], [ “client”, “Amethyst” ] ], “content”: “You can check, read and use this Workbook already! You can also support and get it for few sats and support us in this project.\n\nI hope it’ll help you in your Archetype Journey :)\n\n#archetype\n\nnostr:naddr1qpgyzunrdpjhg7tsv5k4wmmjdd3x7mmt94pk7mtsv9hxjmmw94xk2et594uk7atj949kjmn894tkzunjd9hkju3df4skw6trd9skut2vdamx2u3dw3hkgcte94hk26nzwajszrnhwden5te0dehhxtnvdakz7q3qjypkmmqcaetrcpld4m27la946cch2hrk7qr8xjehsu5j5h3uxy9qxpqqqpmvyqnrm7n”, “sig”: “aa9592e7c773271b9e9f980c8a7e17fda2ffd5a4483a1789e5dd4c4a83018ac576c5202b21b33b08770dcabe023f93998a41f1a0be4bf00e36cdde611d07915e” }


### Fiducia, comportamento in caso di errore e implementazioni dei client

Un lettore sicuro individua un token `nostr:` completo, convalida bech32, decodifica NIP-19, rifiuta `nsec`, ignora i tipi TLV sconosciuti e lascia invariato il testo malformato o di dimensioni eccessive. `npub` e `nprofile` portano a query sui profili; `note` e `nevent` identificano eventi immutabili; `naddr` seleziona l'evento indirizzabile valido più recente per il relativo kind, autore e tag `d`. I suggerimenti sui relay riducono l'ambito della ricerca, ma non estendono la fiducia. In base alle [regole sugli eventi di NIP-01](https://github.com/nostr-protocol/nips/blob/master/01.md), il client verifica l'id di un `nevent` recuperato e controlla la firma di ogni candidato `naddr` prima di applicare le regole di sostituzione degli eventi indirizzabili.

Le anteprime in linea sono una scelta del client che comporta costi in termini di privacy e risorse. Recuperare ogni riferimento rivela gli interessi del lettore e può generare una raffica di richieste, quindi i client possono usare una cache, rinviare il recupero finché il riferimento non diventa visibile, limitare le richieste simultanee e richiedere un clic per i contenuti multimediali non riconosciuti. In base a [NIP-27](https://github.com/nostr-protocol/nips/blob/master/27.md), un'anteprima deve rimanere distinta dal testo firmato dell'autore corrente. Un errore deve essere visibile sotto forma di testo non risolto o di scheda non disponibile, senza essere trattato silenziosamente come contenuto verificato.

Anche la fiducia varia in base al tipo di identificatore. Un `nevent` identifica byte immutabili, quindi un client può rifiutare un evento recuperato il cui id serializzato differisce da quello richiesto. Un `naddr` identifica una coordinata sostituibile, quindi un client deve verificare ogni candidato e applicare le regole per gli eventi indirizzabili prima di decidere quale versione mostrare. In entrambi i casi, un suggerimento sul relay è utile per la prima query, ma non costituisce un'approvazione del relay o del contenuto restituito. La [definizione TLV di NIP-19](https://github.com/nostr-protocol/nips/blob/master/19.md) fornisce i dati necessari per rendere espliciti questi controlli.

[NIP-21](https://github.com/nostr-protocol/nips/blob/master/21.md) definisce un link portabile che può essere aperto dall'esterno di Nostr, mentre NIP-27 rende lo stesso link persistente all'interno del testo firmato. Un client che implementa soltanto NIP-21 può aprire un URI incollato, ma non visualizzare i riferimenti incorporati. Il supporto completo per NIP-27 aggiunge la scansione, la decodifica sicura, i criteri di recupero, la visualizzazione locale e una scelta esplicita relativa ai tag di notifica e citazione. L'URI condiviso mantiene interoperabili questi livelli senza obbligare i client a presentarli nello stesso modo.[Damus](https://github.com/damus-io/damus) rappresenta i riferimenti in linea come menzioni tipizzate. Il suo [codice per le menzioni](https://github.com/damus-io/damus/blob/2ef636aa07f6bd4f24b72fa998b7397dced56d2a/damus/Core/Nostr/Mentions.swift) associa `npub` e `nprofile` ai riferimenti ai profili, `note` e `nevent` ai riferimenti agli eventi e `naddr` ai riferimenti agli indirizzi; [NostrLink](https://github.com/damus-io/damus/blob/2ef636aa07f6bd4f24b72fa998b7397dced56d2a/damus/Core/Nostr/NostrLink.swift) li indirizza alla destinazione appropriata. [Primal Android](https://github.com/PrimalHQ/primal-android-app) [analizza lo schema e i formati incollati](https://github.com/PrimalHQ/primal-android-app/blob/36939db97213e7f8eeefaa4adaf125d839fc662e/domain/nostr/src/commonMain/kotlin/net/primal/domain/nostr/utils/NostrUriUtils.kt), convalida bech32 ed estrae i suggerimenti sui relay, quindi [associa i riferimenti ai modelli del contenuto delle note](https://github.com/PrimalHQ/primal-android-app/blob/36939db97213e7f8eeefaa4adaf125d839fc662e/app/src/main/kotlin/net/primal/android/notes/feed/model/NoteNostrUriUi.kt). [Zap Cooking](https://github.com/zapcooking/frontend/pull/665) visualizza gli stessi riferimenti negli articoli, nelle ricette, nelle anteprime dell'editor e nelle viste di stampa.

---

Invia un DM NIP-17 per condividere un progetto o una notizia tramite il [progetto Nostr Compass](https://github.com/andotherstuff/nostr-compass).

Nostr Compass #38

Wed, 02 Sep 2026 00:00:00 +0000

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

Questa settimana: Voca 1.0 porta note Nostr verificate e subscription long-form in un lettore Android offline che legge gli articoli ad alta voce, nostream amplia l’instradamento dei job lato relay e il funzionamento autenticato, NDK for Dart corregge negentropy e la durata delle richieste multi-relay, Divine Mobile rende deterministiche l’eliminazione e la firma dei messaggi incapsulati, Conduit Relay protegge per impostazione predefinita le inbox dei gift wrap, Amethyst distribuisce highlight portabili e Mostro verifica gli ordini firmati prima del proprio filtro antispam. Napstr pubblica cataloghi audio e heartbeat dei seeder su Nostr, trasferendo i file tramite Tor. Le release riguardano MDK e pakstr; il lavoro sul protocollo integra un suggerimento di paginazione NIP-67 e uno schema di tag per gli highlight NIP-84 nel repository dei NIP, mentre Nostr Wallet Connect aggiunge i totali delle transazioni; e l’approfondimento NIP segue repost e reazioni nelle loro forme di event e nelle implementazioni attuali.

Storie principali

Voca 1.0 legge ad alta voce note e subscription Nostr verificate su Android

Voca è un lettore Android offline che legge articoli, PDF, file Markdown e note Nostr con la voce text-to-speech del telefono, mentre la frase pronunciata resta evidenziata sulla pagina. La sua release 1.0, pubblicata il 2026-08-27 con la propria chiave di progetto, rende Nostr una fonte di prima classe: incollando l’indirizzo di una nota, l’identificatore di un event, un npub, un profilo o un normale link web contenente un’entità Nostr, l’app decodifica il riferimento, recupera l’event firmato dai relay e legge il testo dell’autore invece della pagina web costruita attorno ad esso.

Due comportamenti verificati definiscono l’integrazione Nostr, entrambi descritti nell’annuncio firmato di Voca 1.0. Primo, ogni event recuperato viene controllato rispetto al suo id ricalcolato e alla firma Schnorr BIP-340 prima di essere persistito, usando i relay di bootstrap, la lista relay NIP-65 dell’autore (un event kind 10002 firmato e sostituibile in cui un autore elenca i relay da cui legge e su cui scrive) e i suggerimenti contenuti nel riferimento stesso, così un relay può rifiutarsi di rispondere ma non può attribuire parole all’autore. Secondo, aggiungere l’npub di un autore inserisce i suoi articoli long-form NIP-23 (post indirizzabili kind 30023 con titoli, riassunti e immagini) in un’unica inbox sul dispositivo accanto ai feed RSS e Atom. L’aggiornamento 1.1.0, annunciato il 2026-08-28 e pubblicato su Zapstore il 2026-08-29, sincronizza lo scorrimento a livello di frase, rende più fluidi i documenti lunghi e ripristina il widget della schermata iniziale dopo scorrimento manuale, ridimensionamento, riavvii del processo e aggiornamenti.

nostream amplia l’instradamento DVM lato relay e il funzionamento autenticato

Dopo il lavoro del 19 agosto sull’acquisizione dei job, nostream, un’implementazione relay in TypeScript, memorizza e serve event di gestori di applicazioni NIP-89. NIP-89 (scoperta dei gestori di applicazioni) usa raccomandazioni kind 31989 e informazioni sui gestori kind 31990, entrambe già nell’intervallo sostituibile parametrizzato, così un client può interrogare quei kind e ricevere una sostituzione quando collide un tag d. Il relay non pubblica informazioni sui gestori per i propri worker.

I job NIP-90 (data vending machine) in attesa ora raggiungono un processo worker e tornano come event di risultato. In caso di successo il relay firma un risultato kind 6000-6999 con la propria chiave. Un timeout o un arresto anomalo del worker contrassegna il job come fallito invece di lasciarlo inviato.

Le sessioni autenticate e le chiamate HTTP amministrative si trovano su confini differenti. NIP-42 (autenticazione dei client ai relay) tiene traccia della pubkey autenticata per ogni socket, può richiedere AUTH prima che i client pubblichino event e pubblicizza tale requisito nel documento NIP-11 (informazioni sul relay), con entrambi i controlli disattivati per impostazione predefinita. Separatamente, le route API amministrative possono accettare autorizzazione HTTP firmata NIP-98. NIP-98 (autenticazione HTTP con event firmati) resta disattivato finché un operatore non lo abilita e indica le pubkey consentite.

NDK for Dart corregge negentropy, la durata delle richieste multi-relay e la verifica delle firme

Un’esecuzione NIP-77 (riconciliazione di insiemi con negentropy) in NDK, un kit di sviluppo Dart per Nostr, restituiva insiemi have e need errati senza segnalare errori, perché il codec non parlava il protocollo negentropy v1. La correzione della codifica v1 ora restituisce gli id posseduti dal relay e quelli di cui ha ancora bisogno.

Filtri identici inviati a relay diversi venivano accorpati in un’unica richiesta. Le richieste con lo stesso filtro ora restano distinte quando puntano a relay diversi o hanno durate differenti, così una query breve non può mescolare nel risultato event di un altro relay né lasciare bloccata una subscription attiva.

Lo stesso kit verifica una firma una sola volta e conserva il risultato. Una consegna duplicata successiva non richiede più un altro controllo né sovrascrive l’event verificato memorizzato.

Divine Mobile rende deterministiche l’eliminazione e la firma dei messaggi diretti incapsulati

Gli event kind 5 incapsulati NIP-09 (richiesta di eliminazione di event) che prendevano di mira un messaggio non venivano mai applicati in Divine Mobile, un client mobile per video brevi che pubblica tramite Nostr. Il client ora risolve ogni eliminazione rispetto al messaggio indicato, invece di trattare come già elaborato tutto ciò che non è una reazione. Una seconda richiesta di eliminazione per tutti mentre la prima era ancora in corso prima scompariva senza errori e senza alcun kind 5 in rete; ora ogni eliminazione concorrente viene pubblicata.

Dopo la release 1.0.22 già trattata, inviare due volte nello stesso secondo lo stesso testo 1:1 NIP-17 (DM privati in gift wrap) generava un solo rumor id, quindi il secondo invio scompariva; ora ogni invio porta un token all’interno del rumor NIP-59 (gift wrap), così gli id differiscono.

Un chiamante che aveva già firmato un event kind 4 o kind 5 manteneva quella firma, invece di ricevere in seguito un tag client che modificava l’id e induceva i relay a rifiutare l’event come non valido.

Conduit Relay irrobustisce la propria inbox protetta NIP-42

I gift wrap kind 1059 vengono memorizzati per un solo destinatario. Conduit Relay, un relay Go che conserva tali wrap in un’inbox protetta per destinatario, usa per impostazione predefinita la modalità enforce: una query kind 1059 deve presentare autenticazione NIP-42 come quel destinatario, altrimenti il relay respinge la richiesta. Filtri con kind misti, wildcard, conteggi e negentropy su tali wrap sono restricted, così un’altra AUTH non può trasformarli in un dump dell’inbox altrui.

Lo stesso merge dell’inbox protetta richiede un event id canonico sull’event AUTH trasmesso e accetta un event NIP-42 altrimenti valido indipendentemente dal fatto che content sia vuoto. Challenge-only offre ancora AUTH senza bloccare la lettura; disabled consente l’accesso libero. L’impostazione predefinita della libreria è enforce.

Amethyst distribuisce highlight NIP-84 e corregge due percorsi di errore rivolti ai relay

Dopo il lavoro della scorsa settimana sull’autorizzazione Blossom, Amethyst, un client Nostr per Android, distribuisce v1.14.0 con NIP-84 (highlight portabili). Un passaggio selezionato diventa un event kind 9802 dal compositore, da un feed di highlight o tramite condivisione nell’app.

La release aggiunge controlli di eliminazione e archiviazione dei canali NIP-29 (PR #3812) e misura il comportamento dei relay tramite il traffico già generato dal client, quindi estende tali sonde NIP-66 con controlli di streaming, lettura, scrittura e URL (PR #3836, PR #3857). Amethyst elimina inoltre una vulnerabilità di collisione hash in SharedKeyCache e confronta i codici di autenticazione dei messaggi in tempo costante (PR #3833), corregge una race che poteva perdere la consegna AUTH in fase di connessione (PR #3838), suddivide il locking dello stato delle subscription per terminare un convoglio ANR (PR #3851) e confronta tutti i filtri della subscription invece del solo primo (PR #3856).

La newsletter #36 aveva già trattato queste modifiche ad autenticazione relay, backup e chat pubbliche; ora v1.14.0 le ha distribuite insieme. I soft ban di Concord colmano lacune di autorità rilevate da un audit (PR #3885). L’autenticazione relay dispone di un flusso di autorizzazioni riprogettato (PR #3899), attende la risoluzione della challenge invece di andare in timeout (PR #3905), fa sì che i nuovi account si autentichino per impostazione predefinita (PR #3931), rispetta tale preferenza sui relay esterni all’insieme normale dell’account (PR #3937) e conserva le autorizzazioni di sessione tra le riconnessioni (PR #3955). Un flusso guidato per il primo avvio e le Impostazioni rende individuabili i backup delle chiavi (PR #3909), il backfill delle proof Cashu e la paginazione della cronologia impediscono che i saldi wallet vengano troncati (PR #3941) e ora le chat pubbliche possono essere silenziate (PR #3939).

Dopo quel tag, le liste fidate nei kind da 30392 a 30395 sono indicizzate da NIP-50 (ricerca full-text) solo per titolo, così una lista nominata nella prosa può essere trovata senza indicizzare gli id esadecimali dei membri. I rifiuti del wallet arrivati tramite NIP-47 (Nostr Wallet Connect) ora mostrano l’errore invece di sembrare un tocco senza effetto, inclusi QUOTA_EXCEEDED e RESTRICTED, oltre a un timeout quando il wallet non risponde mai.

Mostro convalida gli ordini firmati prima del lavoro costoso e conserva gli event di audit degli ordini

Dopo le fondamenta dell’escrow Cashu di v0.18.1, Mostro, un daemon di scambio peer-to-peer che coordina ordini su Nostr, ha creato il tag v0.18.5, che usa per impostazione predefinita NIP-44 (cifratura del payload) per il trasporto e mantiene il gift wrap come opt-in esplicito.

La release ancora i timeout dello stato di attesa all’ora di presa registrata, così il bond del maker non viene penalizzato secondo l’orologio sbagliato (PR #879), invia al massimo una volta il pagamento all’acquirente per ogni ordine regolato (PR #881) e sposta tali pagamenti attraverso attese send_payment limitate e non bloccanti (PR #883). Un tentativo di pagare il vincitore della penalità per timeout (PR #875) è stato annullato prima della distribuzione dello stesso tag (PR #885). Mostro smette inoltre di ripubblicare ogni ora e all’avvio un order book in attesa invariato (PR #888), e i suoi event di disputa kind 38386 ora portano un tag created_at per l’ordinamento downstream (PR #878).

Dopo quel tag, un controllo della firma ora viene eseguito prima del filtro antispam. Un event id non incorpora sig, quindi una copia del kind 14 di una vittima con firma non valida poteva occupare lo slot di replay e scartare silenziosamente il messaggio valido; il daemon verifica prima e scarta un wrap non valido invece di avvertire e proseguire.

Gli event di audit delle commissioni kind 8383 portavano un timestamp di scadenza NIP-40 di 15 giorni. Ora mantengono una scadenza di un anno, coerente con il loro ruolo di registro pubblico dei pagamenti. Su un nodo con Cashu abilitato, prendere un ordine chiede al venditore tramite Nostr di bloccare un escrow 2-su-3, pubblica l’event dell’ordine in attesa e salta la creazione di una hold invoice Lightning. Questo completa il percorso della richiesta; da solo non risolve ogni caso di escrow o abuso del mercato.

Napstr pubblica cataloghi audio su Nostr e trasferisce file tramite Tor

Napstr è un client desktop per la condivisione audio che pubblica cataloghi ricercabili e seeder attivi su Nostr, quindi trasferisce i file tramite un processo Tor integrato senza fallback sull’IP diretto. La versione 0.2.0 mantiene pubblici profili e metadati del catalogo, e tiene richieste, credenziali di trasferimento, contenuti dei file e indirizzi IP dei peer fuori dai relay.

La scoperta usa due kind di event indirizzabili nel repository Napstr. Le voci di catalogo kind 30421 identificano un file tramite digest SHA-256, basename pubblico, dimensione e formato audio, e un autore ritira un file sostituendo quella coordinata con un marcatore di eliminazione. Gli heartbeat di disponibilità kind 30422 scadono dopo dieci minuti ed elencano gli id dei file che l’autore è pronto a distribuire, così una riga di catalogo è attiva solo finché un heartbeat non scaduto contiene ancora quel digest.

La conversazione pubblica usa NIP-C7 (messaggi chat kind 9) invece di un gruppo posseduto da un relay. Il repository Napstr definisce una stanza pubblica condivisa e una discussione per traccia associata al digest del file. Quei messaggi sono firmati e pubblici. Non contengono indirizzi onion, credenziali di trasferimento o byte dei file.

Un download inizia come negoziazione NIP-17 (DM privati in gift wrap). Il repository Napstr incapsula una richiesta, un’offerta o un rifiuto in un rumor kind 14, così i relay non vedono l’hostname onion v3 temporaneo né la capability monouso restituita da un’offerta accettata. Tor integrato trasferisce quindi i byte attraverso quell’onion, verifica l’intero digest SHA-256 e convalida nuovamente l’audio prima che il file diventi riproducibile.

Il confronto tra v0.1.7 e v0.2.0 aggiunge raccolte di audiolibri e Napstrfy, un companion Android opzionale. I manifest kind 30423 elencano capitoli ordinati che restano normali file di catalogo, così un client che ignora la raccolta può comunque recuperare ogni capitolo. Napstr crea a tale scopo una cartella locale Audiobooks non distruttiva. Napstrfy si abbina a un desktop in esecuzione con un QR code monouso, quindi cerca e richiede download tramite i servizi Nostr e Tor già presenti sul desktop senza ricevere la chiave segreta del desktop.

Lo stesso confronto applica un timeout a un handshake del companion che non si completa. Un seeder copia e calcola l’hash del file condiviso prima di servire i byte, scrive i dati in arrivo in un file temporaneo privato, limita le destinazioni degli audiolibri a un vero figlio della cartella Napstr e interrompe il trasferimento se la destinazione cambia durante l’operazione.

Release

MDK v0.9.17: KeyPackage più recenti, attività dei membri e invii durevoli

La newsletter #37 ha trattato MDK 0.9.14 e 0.9.15, incluso il passaggio nel repository MDK dalla selezione della KeyPackage più vecchia alla più recente e valida del profilo corrente, i gate di recupero dai gap di epoch, la pulizia degli account e la separazione tra relay di scoperta e operativi. Tali correzioni restano la base delle due release successive, così un package obsoleto non blocca più un membro che ne ha già pubblicato uno utilizzabile.

Gli event di membership e amministrazione ora fanno avanzare la lista chat come un nuovo messaggio: testo di anteprima, ordinamento, conteggi dei non letti e marcatori di lettura si aggiornano quando le persone entrano, escono o cambiano ruolo, e l’attore di sistema locale non viene trattato come profilo Nostr. Riconnessioni e riavvii riutilizzano un’unica identità di invio per un testo outbound durevole ritentato, così lo stesso messaggio di gruppo non viene pubblicato due volte.

Le due release successive si concentrano sul costo di mantenimento dei gruppi numerosi. La versione 0.9.16 misura la divergenza di epoch rispetto all’epoch corrente invece che a un massimo storico, mantiene recuperabili gli event inbound rifiutati (PR #1565), limita il rollback del replay allo stato canonico del gruppo (PR #1563) e introduce marmot-c, un’ABI C generata tramite macro sopra i binding UniFFI che consente agli host di incorporare direttamente il motore. La versione 0.9.17 combina poi le scansioni di ammissione dei pass in un solo attraversamento dei membri invece di uno per membro, verifica se lo stato di un gruppo è contestato senza inizializzare l’intero grafo storico, riduce il costo di polling inattivo della scansione deferred-peel e applica la lettura in batch dei componenti ai tre siti di proiezione mancati dal primo passaggio. Gli artefatti corrispondenti marmot-c 0.9.17 e WN Agent 0.9.17 sono costruiti dallo stesso commit, così chi li incorpora riceve insieme i percorsi di manutenzione più economici.

pakstr v0.16.0: identificatori kind-32267 durante la pubblicazione

Dopo la pipeline di pubblicazione Zapstore dalla 0.13.0 alla 0.15.0 della scorsa settimana, pakstr, una CLI che impacchetta un’app web in un APK Android firmato e la pubblica con una chiave Nostr, registra gli ID degli event applicazione kind 32267 che cerca, pubblica o sostituisce. La versione 0.16.0 stampa sia l’ID precedente sia quello nuovo quando metadati obsoleti dell’inserzione provocano una nuova pubblicazione, così un publisher può confermare quale event dell’inserzione sia attivo sul relay.

Lo stesso log degli identificatori registra l’ID trovato durante la ricerca prima di qualsiasi sostituzione, poi l’ID dell’event pubblicato, così un riuso senza modifiche appare come ID ripetuto. Questa è la modifica inclusa nel tag 0.16.0; i comportamenti Content-Digest, pubblicazione prima dell’upload e convalida del publisher erano già stati distribuiti nei tag precedenti.

Modifiche non ancora rilasciate

Zap Cooking limita i relay del bunker e firma gli endpoint a pagamento

Ricaricare una sessione bunker su Zap Cooking, un sito di ricette basato su event long-form Nostr, prima pubblicava la conversazione cifrata NIP-46 (firma remota tramite relay) su ogni relay già usato dalla pagina. Limitare il traffico del signer ai relay propri del bunker ora applica tale restrizione al ripristino della sessione e all’abbinamento nostrconnect, il flusso di connessione avviato dal signer, in linea con il percorso di login tramite URL bunker. Si rifiuta di installare un insieme di relay vuoto da un record memorizzato non valido, così i relay che ospitano solo ricette non apprendono più che la stessa pubkey mantiene una sessione bunker attiva.

L’autenticazione HTTP firmata ora protegge la chat a pagamento dell’assistente di cucina, l’introduzione al ricettario e gli aggiornamenti delle ricette con accesso limitato tramite NIP-98 (autenticazione HTTP con un event Nostr firmato). Il server legge una sola volta il corpo della richiesta, verifica la firma rispetto a quel payload esatto e ricava l’identità dall’event di autenticazione verificato invece che da una chiave pubblica fornita nel corpo. L’anteprima della chat continua a funzionare senza header, mentre una firma presente ma non valida viene respinta e l’introduzione al ricettario richiede sempre una firma. Anche l’aggiornamento di una ricetta con accesso limitato ora richiede che la chiave verificata corrisponda all’autore memorizzato; a chiunque altro viene detto che la ricetta non esiste, così l’endpoint non conferma quali record a pagamento esistano.

nostrord corregge i DM incapsulati e i link agli event condivisi

Dopo la v2.9.0 della scorsa settimana, nostrord, un client multipiattaforma per community ospitate su relay, ha integrato correzioni alla consegna affinché un NIP-17 (DM privato in gift wrap) inviato da un dispositivo raggiunga lo stesso account altrove. Pubblicare indipendentemente la copia del mittente impedisce che la prima accettazione del wrap del destinatario da parte di un relay faccia perdere la copia recuperata dagli altri dispositivi. La stessa modifica reinvia un wrap dopo il completamento di NIP-42 (autenticazione dei client ai relay) e contrassegna l’invio come riuscito alla prima accettazione di un relay, così un host guasto non può bloccare gli altri. Il nuovo tentativo dei gift wrap parcheggiati che non hanno superato la decifrazione NIP-59 (gift wrap) avviene ora tramite timer, così un bunker che resta connesso non lascia più quei messaggi mi… [troncato]

Una risposta NIP-C7 (messaggi chat kind 9) ripete il proprio genitore come puntatore NIP-19 (entità codificate bech32) nevent iniziale accanto al tag q. Eliminare quel puntatore iniziale al genitore quando apre il corpo e indica il genitore della risposta permette alla riga di essere visualizzata come un’unica citazione di risposta, mentre un puntatore nel mezzo del corpo o che costituisce l’intero corpo continua a essere visualizzato come scheda di citazione. I link agli event citati ora codificano nevent con autore, kind e relay da cui è stata letta la citazione, così un event NIP-29 (gruppi gestiti da relay) condiviso in un DM può essere recuperato da un altro client invece di usare un identificatore di nota privo di suggerimenti per la ricerca.

Aggiornamenti ai NIP e lavoro sulle specifiche del protocollo

Possibilità di implementazione di Nostr

Questa settimana sono stati integrati due aggiornamenti delle specifiche nel repository principale dei NIP.

NIP-67 definisce i suggerimenti che un relay può aggiungere a un messaggio EOSE (fine degli event memorizzati), così un client sa se continuare la paginazione. Il suggerimento "auth" integrato aggiunge un terzo valore accanto a finish e more: ora un relay può segnalare che altri event memorizzati potrebbero diventare visibili se l’utente si autentica e deve inviare la challenge AUTH NIP-42 (autenticazione relay) prima dell’EOSE che porta il suggerimento. La corrispondente aggiunta a NIP-42 definisce lo stesso flusso dal lato client, così un client che riceve un EOSE con auth possiede già la challenge a cui deve rispondere.

NIP-84 (highlight portabili, gli event kind 9802 per cui Amethyst ha distribuito il supporto sopra) ha integrato un aggiornamento dello schema dei tag: ora gli highlight possono contrassegnare la fonte con tag i strutturati secondo NIP-73 (identificatori di contenuto esterno), oltre ai tag a/e per gli event Nostr e ai tag r per tutto il resto, e per gli highlight di citazioni il rendering come quote repost è passato da MUST a SHOULD.

Nostr Wallet Connect

Una risposta list_transactions può indicare quante transazioni corrispondono alla richiesta, non quante righe ha restituito la pagina corrente. Il total_count opzionale integrato in NWC-05 (l’estensione per la cronologia del wallet) nel repository delle estensioni NWC aggiunge tale campo alla risposta usata con NIP-47 (controllo remoto cifrato del wallet tramite Nostr).

Il commit che aggiunge total_count lo documenta come intero opzionale: il numero totale di transazioni che corrispondono ai filtri della richiesta.

Il commit che esclude la paginazione dal conteggio afferma che questo totale esclude la paginazione, quindi conta tutte le transazioni corrispondenti in ogni pagina.

Approfondimento NIP: Repost e reazioni

Un contatto può riproporre una nota esistente ai propri follower e può aggiungere un like, dislike o emoji compatto senza scrivere una risposta. NIP-18 (repost) pubblica tale ridistribuzione come event firmato autonomo. NIP-25 (reazioni) pubblica la risposta compatta come event firmato separato. Entrambi restano file draft optional nella specifica canonica dei repost e nella specifica canonica delle reazioni: sono presenti nel repository dei NIP e implementati dai client, ma ancora etichettati come non definitivi.

Repost (NIP-18)

I follower ricevono un puntatore firmato a una nota di testo kind 1 già pubblicata da qualcuno quando un client scrive un event kind 6. La specifica dei repost imposta kind a 6, inserisce in content il JSON serializzato di quella nota (content vuoto è consentito ma sconsigliato), richiede un tag e il cui valore sia l’id della nota e la cui terza voce sia l’URL di un relay da cui recuperarla, e afferma che l’event SHOULD includere anche un tag p con la pubkey dell’autore originale. Il repost di un event NIP-70 (event protetti) SHOULD mantenere content vuoto, affinché il payload protetto non venga copiato nel nuovo event.

Una citazione è un riferimento all’interno di un altro event, non un wrapper kind 6. Quando un client menziona un NIP-21 (nostr: URI) nevent, note o naddr, deve convertire tale menzione in un tag q nella forma ["q", "<event-id> or <event-address>", "<relay-url>", "<pubkey-if-a-regular-event>"]. I tag dei quote repost tengono tali citazioni fuori dai thread di risposta e permettono ai client di recuperare e contare le citazioni di un post.

Kind 6 è riservato alle note kind 1. Un repost generico kind 16 può incapsulare qualsiasi kind di event diverso da kind 1. SHOULD includere un tag k il cui valore sia il kind serializzato dell’event interno. Quando tale event interno è sostituibile, il repost generico SHOULD aggiungere un tag a con la coordinata kind:pubkey:d-tag; se quel tag a è assente, il repost prende di mira una versione specifica e content deve contenere l’intera stringa JSON di quella versione. Le regole dei repost generici impediscono che event long-form, indirizzabili e altri event diversi dalle note vengano pubblicati come se fossero kind 1.

Il seguente event kind 6 è un repost reale recuperato da wss://relay.damus.io al momento dell’assemblaggio (apri l’event):

{
 "kind": 6,
 "id": "73d8e64314d8b62426faeef5554a95d7d80065a61e0de17d1802e683a93d534a",
 "pubkey": "a60e79e0edad5100d7543b669e513dbc1c2170e8e9b74fdb8e971afd1e0e6813",
 "created_at": 1787768621,
 "tags": [
 [
 "e",
 "38980cd673ee16609dc87081d9f645c331d5a5a8b5b0d6c8147600ed29447976"
 ],
 [
 "p",
 "34d2f5274f1958fcd2cb2463dabeaddf8a21f84ace4241da888023bf05cc8095"
 ],
 [
 "client",
 "Primal iOS"
 ]
 ],
 "content": "{\"pubkey\":\"34d2f5274f1958fcd2cb2463dabeaddf8a21f84ace4241da888023bf05cc8095\",\"sig\":\"8c0271f7b438083ce491c391335598e0cbceee0758177cf98f7894531033cb5153704b01009590f3d4e9cdfadd5bbf73fc5eea54186fcbac6d30744e0e6c1cd6\",\"id\":\"38980cd673ee16609dc87081d9f645c331d5a5a8b5b0d6c8147600ed29447976\",\"tags\":[[\"r\",\"https:\/\/stacker.news\/items\/1555439\"],[\"client\",\"Damus\"]],\"created_at\":1787766056,\"content\":\"🚨 Attention CLN (Core Lightning) node runners 🚨\n\nhttps:\/\/stacker.news\/items\/1555439\",\"kind\":1}",
 "sig": "b6b97fa377cfdb651e2850f65f2ccb12ca0724c0de0fc0e39e9721f850abdfd31f5d5567517a51d988145c2a2de9ae9540b02eecf7352e554022870d5e8c64a5"
}

Il suo kind è 6, il tag e punta alla nota ripubblicata, il tag p identifica l’autore di quella nota e content contiene l’event kind 1 originale come JSON serializzato. Questo event recuperato da un relay omette il suggerimento del relay che la specifica NIP-18 contrassegna come obbligatorio, illustrando perché lettori e client debbano convalidare event reali e tollerare produttori che omettono campi.

Reazioni (NIP-25)

Un post può raccogliere like, dislike ed emoji firmati senza che tali segni entrino nel thread di risposta. La specifica delle reazioni definisce quel segno come un event kind 7 il cui content MUST contenere il valore della reazione. + o una stringa vuota MUST essere interpretati come like o upvote. - MUST essere interpretato come dislike o downvote. Un’emoji o uno shortcode NIP-30 (emoji personalizzata) SHOULD NOT essere interpretato come like o dislike, e un client MAY mostrare tale emoji sul post.

L’obiettivo si trova nei tag, non viene dedotto da content. MUST esserci un tag e impostato sull’id dell’event obiettivo, e tale tag SHOULD includere un suggerimento relay; tag e aggiuntivi sono sconsigliati e, se presenti, l’id obiettivo deve essere l’ultimo. SHOULD esserci un tag p per l’autore dell’obiettivo, per ultimo se compaiono più tag p. Un obiettivo indirizzabile SHOULD ricevere anche un tag a con coordinate kind:pubkey:d-tag. I tag e e a SHOULD includere suggerimenti relay e pubkey, i tag p SHOULD includere suggerimenti relay e un tag k MAY contenere il kind serializzato dell’event oggetto della reazione. Tali regole sui tag consentono a un client di recuperare l’obiettivo e avvisarne l’autore dal solo event di reazione.

Un client MAY inserire un singolo :shortcode: in content e un tag emoji che associa tale shortcode a un URL immagine, seguendo le regole delle reazioni con emoji personalizzate. Se l’obiettivo non è un event Nostr nativo, la reazione MUST essere kind 17 e MUST includere i tag k e i NIP-73 (ID di contenuto esterno), come nelle regole delle reazioni a contenuto esterno. Kind 17 è una reazione a un sito web, episodio di podcast o altro oggetto esterno. Non è una reazione event-a-event kind 7 e non è un repost.

Il seguente event kind 7 è una reazione reale recuperata da wss://relay.damus.io al momento dell’assemblaggio (apri l’event):

{
 "kind": 7,
 "id": "45f71a8fdefb7ac4e86f64b800996ae47f66f1d9a15c0b22d1aa3a962d3dfe63",
 "pubkey": "0755cc2b972c3cbcae36913109c50b36b3fe110fa38a76dc37d1f01c5305496a",
 "created_at": 1787768605,
 "tags": [
 [
 "e",
 "519de32071d71bb2ab8b71a07e03eb9a256b6a59f9b08877b156c80966d5c320"
 ],
 [
 "a",
 "34236:5ab67f7d7fed4f781008c0ec0d26c8113f9fb46094a8346246c70c75e75db9fb:2ddda68516f4729d3ef55a1eb01fe028253393212493a34816ad8eb79f97a3b7"
 ],
 [
 "p",
 "5ab67f7d7fed4f781008c0ec0d26c8113f9fb46094a8346246c70c75e75db9fb"
 ],
 [
 "k",
 "34236"
 ],
 [
 "client",
 "Divine",
 "31990:d95aa8fc0eff8e488952495b8064991d27fb96ed8652f12cdedc5a4e8b5ae540:divine-mobile",
 "wss://relay.divine.video"
 ]
 ],
 "content": "+",
 "sig": "3c081756c7a73e2ee8aa10fadf3b5009390d5ac9a72078ba03701c42af91022ef275df7cb17724689a23dca4e29ff1a7cd5e3a24135d021983e2726a28b00b1e"
}

Il suo content è +, il like convenzionale di NIP-25. Il tag e indica l’event oggetto della reazione; il tag a aggiunge la sua coordinata indirizzabile; il tag p ne identifica l’autore; e il tag k opzionale registra il kind dell’obiettivo come stringa.

Implementazioni attuali nei client

Amethyst, un client Nostr per Android, definisce il tipo di event repost e il tipo di event reazione nel proprio livello di protocollo attuale.

Snort, un client Nostr web, implementa helper NIP-18 che includono la gestione dei tag dei link di citazione e crea tag di reazione agli event NIP-25.

Ditto, un server Mastodon e relay Nostr combinato, pubblica repost generici kind 16 con un tag k e una coordinata a sugli obiettivi indirizzabili e applica la semantica delle reazioni kind 7 trattando l’ultimo tag e come event obiettivo.

Come funzionano insieme

Un event kind 6 o kind 16 ridistribuisce un event esistente nei feed dei follower di chi effettua il repost, incorporando il JSON dell’event oppure puntando a una coordinata sostituibile. Un tag q contrassegna una citazione all’interno di un altro event, così la ricostruzione del thread può contare i riferimenti senza trattare l’event che cita come una risposta, distinzione illustrata nella sezione sui quote repost. Un event kind 7 lascia al suo posto l’event originale e vi associa soltanto il valore della reazione e i tag obiettivo, secondo il contratto della specifica delle reazioni. I client che recuperano una pubkey vedono quindi i repost di quella pubkey come nuovi event kind 6 o 16 e le opinioni di quella pubkey come event kind 7 sui post altrui.

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

Nostr Compass #37

Wed, 26 Aug 2026 00:00:00 +0000

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

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

Storie principali

Postr debutta come piccolo compositore Android

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

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

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

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

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

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

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

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

pakstr da 0.13.0 a 0.15.0 rende esplicita la pubblicazione su Zapstore

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

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

Heterodyne specifica persona portabili e comunicazione sociale cifrata

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

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

Release

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

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

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

NoorNote v1.3.6: stati di profilo e annunci

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

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

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

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

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

Modifiche non rilasciate

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

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

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

Routstr verifica la scoperta di provider proveniente dai relay

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

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

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

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

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

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

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

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

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

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

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

Aggiornamenti NIP e lavoro di specifica del protocollo

NIP

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

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

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

Nostr Wallet Connect

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

NAP

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

Marmot

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

Sei anni di agosto su Nostr

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

Agosto 2021

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

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

Agosto 2022

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

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

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

Agosto 2023

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

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

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

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

Agosto 2024

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

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

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

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

Agosto 2025

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

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

Agosto 2026

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

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

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

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

Nostr Compass #36

Wed, 19 Aug 2026 00:00:00 +0000

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

Questa settimana: Amber rafforza l’autenticazione relay e cifra i segreti memorizzati, Cambium firma per i siti web sotto carico di relay-auth, Citrine ospita gruppi e siti statici su un relay telefonico, Vector mette in coda la moderazione sotto spam e sincronizza i mute tra dispositivi, Sonar aggiunge risposte mesh annidate, Nostria pubblica podcast e Nail collega l’email come eventi gift wrap. Le release coprono lo stato di gruppo MDK, la coniazione di badge, l’accoppiamento QR del firmatario, la firma browser su Android e una libreria wallet-connect condivisa. Il lavoro di protocollo tocca patch sui commenti, metadati di file criptati, formattazione dei thread, garanzie di riavvio Marmot e liste di appartenenza Concord. Approfondimenti: badge e commenti.

Storie principali

Amber 6.5.0 chiude un confused deputy nell’autenticazione relay e cifra i segreti memorizzati

Amber è un firmatario Android NIP-55 (intent del firmatario Android) e NIP-46 (firma remota mediata da relay). La versione 6.5.0 chiude quattro lacune divulgate: un confused deputy nell’autenticazione relay che permetteva a qualsiasi chiamante di ottenere un evento kind 22242 NIP-42 (autenticazione client-relay) per relay che l’utente non aveva mai approvato; una lacuna di replay NIP-46; segreti di connessione e chiavi locali in chiaro ora cifrati a riposo con envelope; e un pacchetto di hardening in otto punti che copre l’autorizzazione del chiamante prima della decifratura, parsing dei permessi fail-closed, avvisi su ws:// in chiaro, schermate QR sicure, redazione dei log, azzeramento lazy delle chiavi al logout e uso opzionale del Keystore con dispositivo sbloccato.

La versione 6.5.1 ricifra i segreti NIP-46 memorizzati quando la chiave Keystore ruota dopo l’attivazione del requisito di dispositivo sbloccato e corregge un crash nell’editor dei permessi. La versione 6.5.2 smette di decifrare colonne che l’elenco applicazioni non renderizza mai, mette in cache l’handle Keystore, precarica la cache account all’avvio e debounce le notifiche di stato relay.

La 6.4.0 della scorsa settimana ha reso esplicite le decisioni di firma raggruppate; la serie 6.5.x cambia ciò che Amber autorizzerà in assoluto.

Cambium 0.4.0 firma per i siti web e alleggerisce i burst di relay-auth

Cambium è un proxy Android NIP-55 verso un firmatario hardware Heartwood tramite NIP-46. Sei release in due giorni.

La versione 0.4.0 estende la firma ai siti web. Una pagina può richiedere una firma tramite callback nostrsigner: convalidato senza ereditare i permessi concessi alle applicazioni native, così una scheda del browser non può prendere in prestito l’approvazione di un’altra app. La stessa release corregge la forma minima dell’evento prevista dalla specifica: un evento con solo kind e content ora firma correttamente, con Cambium che fornisce l’identità NIP-46 abbinata, il timestamp corrente e un array di tag vuoto prima di passare l’evento a rust-nostr. L’instrumentazione nativa rust-nostr è diventata un gate obbligatorio di integrazione continua nella stessa modifica.

La versione 0.3.6 ripara l’accoppiamento con firmatari conformi alla specifica. La build rust-nostr più vecchia di Cambium accettava solo la stringa letterale ack come risultato di una chiamata connect NIP-46, quindi un firmatario che risponde facendo eco al segreto dell’URI bunker — come chiede la specifica attuale e fa il firmware Heartwood — terminava l’accoppiamento con un errore di risposta inattesa. Il passaggio da rust-nostr 0.44.2 a 0.44.8 rende accettabili entrambe le forme, verificate contro hardware live e contro nak bunker, che continua a rispondere ack.

Le release da 0.4.1 a 0.4.3 riguardano il controllo di ammissione sotto carico. La versione 0.4.1 riserva uno slot in coda a reazioni, post, cancellazioni e cifratura prima dell’autenticazione relay e della decifratura in background, limita le chiamate in coda, le scarta una volta scaduto il chiamante e restituisce un risultato terminale di indisponibilità in caso di sovraccarico invece di aprire una schermata di firma in primo piano. La versione 0.4.2 scarta sessioni NIP-46 scadute o inattive da tempo prima della richiesta successiva e lascia che copie concorrenti dello stesso evento di autenticazione kind 22242 condividano una firma hardware. La versione 0.4.3 ammette al massimo una sfida di autenticazione distinta per identità nel worker hardware, non ritenta mai l’autenticazione internamente e apre un cooldown di sessanta secondi per identità dopo un timeout rispondendo comunque ai duplicati esatti in cache. Le misure nelle note di release provengono da un telefono GrapheneOS che guida Amethyst: un burst a freddo ha prodotto trentatré risposte immediate di sovraccarico e tredici richieste completate senza timeout del firmatario, e un login fresco durante un burst di autenticazione è tornato 1,254 secondi dopo l’approvazione.

Citrine 3.1.0 trasforma un relay telefonico in host di gruppi e di siti

Citrine è un relay Android on-device. La versione 3.1.0 aggiunge tre capacità che cambiano ciò che il relay può ospitare.

Il supporto per NIP-29 (gruppi gestiti da relay), la specifica di gruppo basata su relay in cui il relay stesso detiene appartenenza e stato di moderazione, significa che un telefono può ospitare un gruppo invece di unirvisi. Il supporto per NIP-86 (API di gestione relay), l’API di gestione relay che espone azioni amministrative via JSON-RPC autenticato, arriva con una schermata impostazioni, così allowlist e ban possono essere gestiti dall’API come dall’app. Il supporto per NIP-5A siti web statici permette al relay di servire nsite ai client web, con un elenco di navigazione modernizzato che include icone, ricerca, ordinamento per ultimo aggiornamento, progresso di installazione, descrizioni e un insieme configurabile di relay per il recupero, predefinito su nsite.run, nos.lol e nostr.land.

La superficie di moderazione è cresciuta parallelamente nella stessa release. Il ban locale di una chiave pubblica offre ora di eliminare gli eventi memorizzati di quell’autore, un elenco configurabile REJECTED_KINDS blocca i kind che l’operatore non vuole memorizzare e il controllo accessi può importare da elenchi esistenti. Uno strumento di rebroadcast spinge gli eventi memorizzati verso relay selezionati, dando a un archivio tenuto sul telefono un modo per reseme la rete. La release rimuove anche l’estensione WebSocket permessage-deflate, stringe il percorso caldo delle query, corregge Tor che non si avvia o non si ferma quando cambia l’impostazione di esposizione via Tor e sposta i log in un database locale con logcat limitato alle build di debug.

Vector 0.4.2 fa sopravvivere la moderazione di community a un’ondata di spam

Vector è un messenger desktop e Android Concord. La versione 0.4.2 si concentra sulla moderazione sotto carico.

I ban rapidi si sovrascrivevano a vicenda. Ora si mettono in coda, si accumulano e si risolvono come un’unica operazione, così bannare un’ondata di account costa una rotazione di chiave invece di una per account. Accettare un invito a una community sciolta nel frattempo spiega perché e rimuove l’invito da ogni dispositivo dell’utente, e sciogliere una community posseduta la elimina dall’elenco community ovunque — una correzione arrivata nella versione 0.4.3. I messaggi di community che arrivano durante un catch-up in background non fanno più suonare le notifiche come se fossero appena stati inviati, e l’indicatore di digitazione scade dal momento dell’invio così un segnale ritardato non può restare in un canale.

L’elenco di community shardato definito da Concord ha avuto un passaggio di revisione cross-client con Armada, l’altro client Concord. I rename non gonfiano più l’elenco, i pareggi si risolvono identicamente su entrambi i client e i dati invariati non vengono più ripubblicati sui relay. Il mute è uscito dal percorso dei messaggi diretti: un utente può silenziare qualcuno direttamente da una community senza cronologia precedente, e il mute si applica a notifiche e badge su canali e messaggi diretti lasciando visibili i messaggi stessi. I messaggi fissati sono diventati una superficie condivisa del canale con link cliccabili, e le modifiche a un messaggio fissato lo seguono ovunque appaia. Elenchi di blocco, mute e nickname ora si sincronizzano tra i dispositivi dell’utente, così come le chat fissate. La versione 0.4.3 smette anche di annunciare che l’utente sta digitando quando un altro client Nostr è connesso con la stessa identità, e sblocca il bootstrap Tor su Windows, che si bloccava al quindici percento su x64 e ARM64.

Sonar porta risposte annidate a un messenger mesh con NIP-C7

Sonar è un messenger mesh Bluetooth e Nostr. La versione 0.1-alpha.13.1 aggiunge risposte in stile Signal sulla chat kind 9 NIP-C7, più menzioni, riassemblaggio Bluetooth limitato, limiti di backup, verifica delle firme del percorso mesh e fallback push FCM. Le versioni 0.1-alpha.13.2 e 0.1-alpha.13.3 correggono i crash all’apertura della chat su Android e la sovrapposizione della tastiera su iOS.

Nostria inizia a pubblicare podcast e chiede ai relay di contare

Nostria è un client web. Le versioni 4.1.70 e 4.1.71 aggiungono la pubblicazione di podcast per abbonati premium, con episodi come eventi Nostr firmati. La versione 4.1.69 usa COUNT NIP-45 (richieste di conteggio relay) per totali di reazioni, risposte e zap nei feed e completa la localizzazione. La 4.1.67 della scorsa settimana ha ampliato l’amministrazione delle community criptate.

Release

MDK 0.9.14: cronologia di gruppo fail-closed tramite creazione di gruppi più rapida

MDK è il kit di sviluppo Rust per Marmot, un protocollo di messaggistica di gruppo criptata trasportato su Nostr. La versione 0.9.12 rende fail-closed diversi percorsi di stato di gruppo invece di indovinare. Un’ancora di fork mancante è ora un errore fatale (PR #1329), una proposta di uscita viene persistita atomicamente così un crash non lascia una partenza applicata a metà (PR #1360), e il replay degli incidenti rifiuta di indovinare un formato su stream JSON delimitati da newline senza manifest (PR #1140). I test di convergenza si sono ampliati parallelamente, con recupero cross-route della cronologia conservata (PR #1350), garanzia di convergenza cross-adapter (PR #1372) e campagne di convergenza isolate generalizzate (PR #1357). Le diagnostiche di rifiuto relay vengono conservate invece di collassare in un errore generico (PR #1361).

La versione 0.9.13 è arrivata il 18 agosto con formato di storage v2 (PR #1421), binari di migrazione e scritture delta che sostituiscono gli snapshot live dell’account (PR #1435), più catch-up degli inviti più rapido (PR #1444) e binding macOS (PR #1402). La versione 0.9.14 ha seguito il 19 agosto con rifiniture alla creazione di gruppi: immagini fondative precaricate (PR #1498), batching KeyPackage (PR #1494), conservazione atomica del messaggio iniziale (PR #1497) e pubblicazione del profilo con relay di proprietà dell’account (PR #1495). MarmotKit 0.9.14 e wn-agent 0.9.14 partono con il crate principale.

Divine Mobile 1.0.20: coniare un badge senza uscire dall’app

Divine Mobile è un client di video brevi che pubblica e recupera video tramite Nostr. La versione 1.0.20 permette a un utente di coniare un badge NIP-58 (eventi di premiazione firmati descritti nel primo approfondimento di questo numero) e consegnarlo a qualcuno senza uscire dall’app. Toccare un badge su un profilo spiega cosa era richiesto per guadagnarlo, la parte della specifica di solito non implementata perché l’evento di definizione e quello di premio sono memorizzati separatamente.

Il resto della release è lavoro client: tema chiaro, ritaglio, rotazione e capovolgimento nell’editor stop-motion, bozze a un tocco dal registratore, tempistica dei sottotitoli rispetto al video, un feed che deprioritizza il materiale già visto, supporto screen reader su editor, registratore e schede profilo, gestione del movimento ridotto e impostazioni account che gestiscono email e password Divine e collegano o scollegano account. I video eliminati lasciano ora lo stato locale e i segnalibri persistono. La 1.0.19 della scorsa settimana ha rafforzato l’isolamento degli account e la validazione dei messaggi privati; l’emissione di badge è una nuova superficie di pubblicazione sopra tutto ciò.

ClipRelay 0.2.0: accoppiare un firmatario con una fotocamera

ClipRelay sincronizza gli appunti tra dispositivi tramite Nostr. La versione Android 0.2.0 aggiunge login QR nostrconnect://, così un utente può accedere con un’app firmataria su un altro telefono, e la scansione con fotocamera degli URL bunker, eliminando l’abitudine di incollare una stringa contenente segreti tramite un messenger. La connessione bunker ora scade dopo sessanta secondi invece di restare appesa, e il pulsante di retry dopo un login Amber fallito funziona. La versione desktop 0.2.0 porta timeout e correzioni alla scheda di login.

La versione 0.1.4 ha aggiunto sincronizzazione degli appunti sensibili con scadenza breve sui relay, relay di sessione del firmatario fissati e una sonda di liveness che richiede un round trip reale invece di un EOSE sintetizzato localmente. La 0.1.3 della scorsa settimana ha ripristinato le connessioni dopo periodi di inattività.

Bark 1.3.9: un firmatario browser che gira su Android

Bark è un’estensione browser che fornisce l’interfaccia NIP-07 window.nostr, l’oggetto che una pagina web chiama per richiedere firma o cifratura. La versione 1.3.9 dichiara il supporto Android per la build Firefox, così l’elenco add-on si installa su un telefono. Firefox su Android non implementa alcuna API windows, quindi ogni approvazione che apriva una finestra popup sarebbe stata rifiutata; la superficie di approvazione ora ricade su una scheda in primo piano dove la chiusura nega, un’azione di revisione la porta avanti e lo sfondo la chiude una volta risolta la richiesta. Le note di release registrano la verifica su Pixel 10 Pro XL con GrapheneOS e Firefox 153.0.4, e affermano chiaramente che Chromium su Android compila fuori il sottosistema delle estensioni, quindi nessun browser Android derivato da Chromium può eseguire Bark.

La versione 1.3.8 ha corretto un difetto di interoperabilità NIP-46 nella direzione opposta. Bark sondava un dialetto compatto di firma Heartwood inviando l’evento come oggetto JSON, che i firmatari tipizzati rigorosamente inclusi nak e bunker basati su rust-nostr non possono analizzare e scartano silenziosamente, quindi la firma restava appesa. La sonda viene ora inviata solo ai firmatari che si identificano come Heartwood, e ogni altro firmatario riceve una chiamata standard sign_event dalla prima firma in poi.

Bray 3.0.0 e Toll Booth 6.0.0 passano a una libreria wallet-connect condivisa

Bray e Toll Booth pagano entrambi tramite NIP-47 Nostr Wallet Connect, la specifica che permette a un’applicazione di richiedere pagamenti a un wallet tramite eventi Nostr criptati. Bray 3.0.0 e Toll Booth 6.0.0 dichiarano ciascuno un breaking change nell’adozione di nwc-kit per i pagamenti wallet, e Toll Booth rimuove il flusso di credenziali del pagatore nella stessa modifica. Entrambi pubblicano build riproducibili il cui output era byte-identico su due runner indipendenti, con l’hash del tarball stampato nelle note di release così un lettore può verificare l’artefatto del registry.

Tre patch Toll Booth sono seguite: 6.0.1 fissa la chiave host del deploy negoziata, 6.1.1 fissa cashu-ts alla versione che il suo patch targetta, e 6.1.2 ripristina una build di immagine.

NoorNote 1.3.4: unirsi a community criptate da un link di invito

NoorNote è un client Nostr per desktop, web e Android. La versione 1.3.4 aggiunge community Armada e Concord criptate come addon: un utente entra tramite link di invito, vede le community unite elencate nelle impostazioni e riceve notifiche di attività. La stessa release aggiunge un controllo per nascondere i post di citazione esterni, gli highlight che citano un paragrafo di un articolo web, globalmente o per autore, con i repost di essi nascosti e i propri highlight mantenuti visibili. Anche la risoluzione del profilo è stata riparata, così i profili non vengono più renderizzati come chiave pubblica troncata o segnaposto anonimo.

La versione 1.3.5 aggiunge un espansore per note lunghe e corregge il layout dell’input del link di invito Armada. La 1.3.2 della scorsa settimana ha spostato la scoperta degli articoli nel grafo sociale; l’appartenenza alle community è una superficie separata.

Mostro sposta la chat delle dispute fuori dal gift wrap

Mostro è un daemon di trading peer-to-peer i cui ordini e messaggi viaggiano come eventi Nostr, con mostro-core come libreria condivisa e Mostro Mobile come client. Mobile 1.3.2 migra la chat delle dispute dal gift wrap NIP-59 (involucro che nasconde i metadati) a un envelope di chat kind 14 e sostiene il backlog con cursori duraturi per conversazione. mostro-core 0.14.5 serializza l’identificatore rumor dentro il gift wrap (PR #164), 0.14.4 corregge un bug nella media dei rating (PR #163), e Mobile 1.3.1 passa a server Blossom che conservano allegati di chat criptati. Usare il daemon 0.18.2 o 0.18.4.

NYM 3.73.522: chat di gruppo criptate e store locale criptato

NYM è un client Nostr con integrazione assistant propria. La versione 3.73.522 cifra lo store SQLite locale dopo che 3.73.521 ha raffinato la chat di gruppo criptata, e 3.73.520 corregge una rottura della content-security-policy e la presentazione duplicata dei nuovi messaggi.

Morganite 0.0.4: verificare un blob prima di metterlo in cache

Morganite è un server Android Blossom (protocollo media in cui un file è indirizzato dall’hash SHA-256 del contenuto e servito da qualsiasi host che lo detiene). La versione 0.0.4 verifica l’hash di un blob durante il download in un unico passaggio prima di metterlo in cache, il controllo che rende significativo il content addressing sul lato ricevente. La release traccia anche la dimensione della cache incrementalmente invece di riscansionare la directory a ogni salvataggio, sposta le chiamate di rete bloccanti su thread di input e output, riusa istanze Tika per il rilevamento MIME e persiste i log in un database locale.

Nuovi scoperti

Nail porta l’email su Nostr come eventi gift wrap

Nail è un bridge email e client web con licenza MIT del team Formstr, il gruppo dietro Formstr e nostr-calendar. È andato live il 18 agosto con PR #7, una modifica di 22 file che ha aggiunto tag k agli eventi mail, recupero chiavi nelle impostazioni e un messaggio di benvenuto. Il deployment gira su mailstr.app, che serve il record NIP-05 (schema DNS che mappa un nome di dominio a una chiave pubblica Nostr) _smtp del bridge.

La mail stessa è un evento Nostr. Le costanti del client definiscono un rumor mail kind 1301 trasportato dentro un gift wrap kind 1059 NIP-59, così un messaggio raggiunge il destinatario tramite lo stesso involucro che nasconde i metadati usato per i messaggi diretti privati. I relay di consegna provengono da un elenco inbox kind 10050 NIP-17 (messaggi diretti privati) con un elenco relay kind 10002 NIP-65 dietro, le cartelle sono etichette kind 1985 NIP-32 (eventi etichetta) sotto un namespace mail, e le impostazioni client vivono in un evento dati applicazione kind 30078 NIP-78. Gli allegati più grandi di 60.000 byte vanno su Blossom invece che nell’evento, perché NIP-44 (cifratura) limita il plaintext cifrato a 65.535 byte. Un indirizzo è un npub su un dominio, e un dominio locale senza record NIP-05 è trattato come una casella inesistente.

La metà bridge è un server Node LMTP che gira accanto a un deployment mailcow senza patcharlo: Postfix instrada i domini corrispondenti al bridge, e il bridge reinietta le risposte via SMTP. Questo design impone una risposta onesta alla domanda più difficile in un bridge email: cosa prova un header From. Il percorso di ricezione di Nail classifica ogni messaggio in uno di quattro stati di provenienza: il bridge configurato l’ha sigillato e rifiuta di inoltrare un mittente non verificato a monte, l’utente l’ha sigillato personalmente, il record NIP-05 dell’indirizzo risolve sulla chiave di sigillatura, o nulla corrobora l’header. In questo ultimo caso l’interfaccia ricade sulla chiave pubblica di sigillatura, l’unica identità che l’evento può effettivamente provare. Le chiamate API del bridge sono autenticate con eventi HTTP firmati NIP-98 (autenticazione HTTP tramite eventi firmati).

Glow memorizza etichette wallet sui relay sotto un’identità derivata da passkey

Glow è un wallet Lightning self-custodial Breez. Il login passkey deriva un’identità Nostr, e l’elenco delle etichette wallet viene caricato e salvato sui relay sotto quell’identità, con duplicati byte-identici collassati attraverso copertura relay parziale.

Modifiche non rilasciate

Amethyst ricostruisce il flusso decisionale di autenticazione relay

Amethyst è un client Nostr Android. Un blocco di lavoro unito rimodella come gestisce l’autenticazione client-relay NIP-42. L’interfaccia dei permessi e il flusso decisionale sono stati ridisegnati (PR #3899), l’autenticazione ora attende la risoluzione di una sfida invece di andare in timeout (PR #3905), i nuovi account autenticano sempre con i relay per impostazione predefinita (PR #3931), e una scelta «accedi sempre» vale anche per relay che l’account non usa direttamente (PR #3937). L’autenticazione riconosce anche gruppi NIP-29 e community Concord come luoghi a cui ci si è uniti (PR #3906), così un gruppo ospitato su relay non sembra un relay sconosciuto ogni volta che viene aperto.

Altre due modifiche toccano superfici di protocollo. Il mining proof-of-work sotto NIP-13 (nonce PoW) aggiorna created_at mentre mina e ottiene un’analisi del percorso GPU (PR #3911), e gli host napplet a schermo intero gestiscono gli inset della tastiera (PR #3932). Anche un backup guidato delle chiavi al primo avvio con punto d’ingresso nelle impostazioni è stato unito (PR #3909), insieme alla possibilità di silenziare chat pubbliche (PR #3939).

nostrord implementa una proposta non unita di chiave di cifratura

nostrord è un client chat Nostr organizzato attorno a gruppi con scope relay. Ha unito un’implementazione di NIP-4e, una proposta non unita per disaccoppiare la cifratura dei messaggi dalla chiave d’identità che Compass ha descritto l’ultima volta nel numero del 15 luglio. L’account annuncia la propria chiave di cifratura kind 10044, tiene la metà privata localmente e decifra i messaggi diretti in arrivo in processo, togliendo bunker o estensione browser dal percorso di lettura (PR #261). L’accoppiamento dispositivo sui kind 4454 e 4455 sposta quella chiave su un secondo dispositivo, e un auto-archivio ripubblica la cronologia indirizzata alla nuova chiave. L’invio indirizzava prima la chiave annunciata (PR #247), e un follow-up ha corretto l’accoppiamento che negoziava con successo senza consegnare la chiave (PR #271). La pull request afferma che il formato wire segue l’implementazione Jumble già deployata dove diverge dalla proposta aperta, collocando la definizione operativa di questa specifica nel codice spedito invece che nel documento.

L’identità di gruppo è stata ristretta nello stesso batch. Un identificatore di gruppo è ora unico solo all’interno del suo relay (PR #269), quindi lo stesso identificatore su due relay è trattato come due gruppi (PR #272), e i post dei thread vengono renderizzati come post di forum (PR #274). Anche il churn di connessione che produceva ripetute richieste di firma kind 22242 è stato fermato (PR #268), la stessa classe di pressione sul firmatario su cui Cambium ha lavorato per tre release questa settimana.

nostream aggiunge un monitor relay e conia codici invito

nostream è un’implementazione relay TypeScript. Ha unito un cluster worker e uno scheduler di probe che pubblicano eventi di monitoraggio relay NIP-66 (specifica di discovery che permette a un monitor di annunciare liveness e dati di capacità su altri relay) (PR #724), con schema impostazioni e default (PR #689) e test di integrazione (PR #733). Uno strumento da riga di comando conia ora codici invito NIP-43 (schema metadati di accesso relay) (PR #732), e il relay annuncia finalmente proof of work NIP-13 nella sua lista supportata (PR #680), che aveva implementato senza annunciare. I job data vending machine hanno anche ottenuto migrazione di persistenza e repository (PR #727), e il relay intercetta ora NIP-90 (richieste job data-vending-machine) e le registra tramite il repository job (PR #729).

rust-nostr corregge un identificatore gift wrap e rifiuta repost protetti

rust-nostr è la libreria Rust e l’SDK dietro gran parte del lavoro client Rust e mobile di questo numero. Ora garantisce che l’identificatore rumor sia calcolato prima che il sigillo gift wrap venga cifrato (PR #1444), la stessa classe di difetto che Mostro ha corretto nella propria libreria questa settimana. Il relay locale rifiuta un repost di un evento protetto NIP-70 (PR #1445), la protezione per cui quella specifica esiste, e il parsing delle risposte NIP-47 tollera importi mancanti e null (PR #1450) invece di fallire su un wallet che li omette. Il parsing degli URL relay è stato rafforzato (PR #1451).

NDK aggiunge messaggi diretti post-quantum e rimuove una dipendenza GPL

NDK è un kit di sviluppo Dart per Nostr. Ha unito cifratura ibrida post-quantum per i messaggi diretti usando ML-KEM-1024, il meccanismo lattice key-encapsulation standardizzato come FIPS 203 (PR #713), affiancandolo all’accordo di chiavi classico invece di sostituirlo. Una modifica separata ha sostituito un’implementazione Dilithium solo GPL-3.0 con fips204, lo standard di firma ML-DSA (PR #712), rimuovendo un vincolo di licenza per le applicazioni che incorporano il kit. Le connessioni sono passate a un’identità ciascuna (PR #710).

Nostter aggiunge liste segnalibri, badge profilo e upload Blossom

Nostter è un client web. Ha unito il supporto per entrambe le forme standard e legacy delle liste segnalibri NIP-51 (PR #2311), aggiornato la gestione dei badge profilo NIP-58 (PR #2281), aggiunto un uploader media Blossom (PR #2298), e ora mostra un identificatore NIP-05 (nome di verifica DNS) nell’autocompletamento delle menzioni (PR #2303).

Zap Cooking lega le route admin a richieste firmate e cifra le connessioni wallet memorizzate

Zap Cooking è un sito di ricette costruito su eventi long-form Nostr. Un batch di sicurezza cifra le stringhe di connessione Nostr Wallet Connect memorizzate a riposo dentro un envelope NIP-44 (PR #622), sostituisce un confronto di chiave pubblica spoofabile sulle route amministrative con autenticazione HTTP NIP-98 (schema che firma un evento per autorizzare una richiesta HTTP) (PR #626), e cancella i dati account al logout limitando i record NIP-46 pendenti (PR #627).

Aggiornamenti NIP e lavoro di specifica del protocollo

NIP

Nessuna pull request è stata unita in nostr-protocol/nips in questa finestra. Sei proposte sono state aperte dopo la chiusura del numero precedente, tre il 18 agosto dopo che la bozza aveva circolato per la prima volta.

NIPs PR #2438 propone NIP-9A, patching basato su commenti. Una patch è un commento kind 1111 che referenzia l’evento patchato come parent il cui content inizia con l’etichetta letterale PATCH, seguita da righe di patch. Una riga che inizia con un numero modifica il content del target nella forma <index> -<deleted> +<inserted> <caratteri inseriti>, contati in caratteri Unicode invece che byte, e una riga che inizia con t sostituisce un tag leggibile come title, description, subject o picture. Il design è deliberatamente retrocompatibile: un client che non capisce il formato mostra la patch come un commento etichettato ordinario, e un client che lo capisce applica la patch e nasconde il commento. La proposta nomina i kind 1, 11, 1111, 24 e 1621 come patchabili e chiede a scrittori e lettori di rifiutare patch troppo grandi, troppo numerose o pubblicate molto dopo l’evento originale, un tentativo esplicito di evitare che la funzione diventi un canale generale di modifica per eventi immutabili.

NIPs PR #2437 propone la cifratura file per NIP-94, la specifica di metadati file che descrive un file caricato in un evento kind 1063. Aggiunge tre tag opzionali: encryption-algorithm, con aes-gcm come unico valore elencato, più decryption-key e decryption-nonce codificati in hex. Le semantiche dei tag cambiano di conseguenza, con m che descrive il MIME type prima della cifratura, x che tiene l’hash del file cifrato e ox quello dell’originale, e qualsiasi sorgente thumb, image e fallback cifrata con la stessa chiave e nonce. Lo scopo dichiarato è che un operatore Blossom pubblico che ospita i byte non possa capire cosa siano, e l’autore inquadra la modifica come copiare le proprietà di cifratura dei messaggi diretti NIP-17 nei metadati file così lo stesso trattamento funziona dentro un tag imeta.

NIPs PR #2436 emenda NIP-7D, la specifica di thread forum costruita su eventi thread kind 11 con commenti kind 1111 NIP-22 come risposte. Aggiunge una sezione di formattazione che afferma che un post di thread può essere formattato come una nota kind 1, con immagini inline, link e riferimenti NIP-27, e potrebbe anche supportare Djot, un linguaggio di markup leggero con grammatica non ambigua. L’argomento dell’autore è che lasciare la formattazione non specificata invita a un’implementazione Markdown by default, e la pull request indica squalk come implementazione Djot esistente.

NIPs PR #2439 aggiunge i metodi assign e unassign a NIP-86 (comandi di gestione relay), così un amministratore relay può concedere permessi admin a un’altra pubkey senza condividere la chiave master.

NIPs PR #2442 succede alla proposta audio track che Compass ha trattato a gennaio mentre quella bozza restava aperta; la pull request precedente da allora si è chiusa e questa è in produzione su lightning.fm come eventi track kind 31337, con oggetti release kind 31339, profili band, contributor per traccia e split zap NIP-57 opzionali mantenendo le vendite in NIP-99. Il contratto di interoperabilità è pubblicato su lightning.fm/interop, e il publisher desktop e il daemon seller self-hosted sono open source.

Marmot

Marmot PR #416 è stata unita il 13 agosto e aggiunge un contratto di durabilità e riavvio al core del protocollo. I documenti adottati definivano già convergenza deterministica, materiale parent candidato conservato, ordine publish-before-apply e comportamento fail-closed su cronologia mancante, senza una regola univoca su cosa succede quando un processo viene interrotto alle giunture tra loro. La modifica definisce fatti logici recuperabili, equivalenza di riavvio, confini di interruzione di publish e convergenza, transizioni observer-atomiche, gestione di materiale mancante o corrotto e recupero degli effetti applicativi, poi aggiunge scenari di conformità crash e riavvio per ciascuno. Lascia transazioni, journal, snapshot, strategia di replay, scheduler e formati di storage definiti dall’implementazione, e afferma che non richiede cambiamenti di wire encoding. Il fallimento specifico che esclude è una pubblicazione accettata esternamente ma non confermata localmente, o un branch selezionato parzialmente applicato, che produca risultati di protocollo dipendenti dall’implementazione dopo un riavvio.

Concord e CORD

Concord PR #18, trattata in precedenza nel numero scorso come proposta aperta, è stata unita il 15 agosto. Shardizza l’elenco di community criptate attraverso eventi kind 33302, rimuove il limite di cinquanta appartenenze e pota le voci ritirate così l’elenco resta entro i limiti di dimensione relay. Le note di release di Vector questa settimana registrano la metà client di quella modifica, inclusa la risoluzione dei pareggi e la decisione di smettere di ripubblicare dati invariati.

Concord PR #22 propone broker audio e video di proprietà della community. L’entità metadati CORD-02 porterebbe un elenco opzionale av_brokers accanto ai relay, evolvendo per edizione come il resto di quell’entità, e il rendezvous CORD-07 attingerebbe da quell’elenco, o dal broker del membro quando la community non ne pubblica nessuno, ordinato dal tie-break esistente keyed per stanza. Il tag broker sulla presenza resta leggibile e utile per segnalare uno split residuo, e l’argomento della proposta per declassarlo dal routing è diretto: instradare su di esso lascia che l’input non fidato di un altro membro superi l’istruzione della community.

Concord PR #23 rende normativo un comportamento implementativo esistente in CORD-05. Prima di persistere un join, l’edizione metadati genesis del proprietario deve aprirsi sotto le chiavi consegnate, con piani ruotati ancorati alla coppia di compaction. La pull request afferma fin dall’inizio che non è mai stata una vulnerabilità live: l’accettazione bundle di Vector rifiuta già un bundle la cui root consegnata non può aprire la genesis del proprietario e non parcheggia mai un invito per una community già detenuta, e Armada scarta già qualsiasi bundle che sposterebbe la base di una community detenuta. La lacuna era che nessuno dei due comportamenti era richiesto dalla specifica, quindi un client conforme alla lettera avrebbe potuto spedire la versione vulnerabile.

I documenti di upgrade Blossom, le proposte applicazione Napplet e la specifica Gamma Markets non hanno registrato modifiche in questa finestra.

Approfondimento NIP

Badge (NIP-58)

NIP-58, definito dalla specifica primaria, dà a un’identità Nostr un modo per conferire un token nominato a un’altra, e al destinatario controllo su se appare sul profilo. Il problema che affronta è che ogni affermazione su una persona su Nostr altrimenti è solo una nota: non c’è struttura che dica chi ha emesso un’affermazione, come si chiama, come appare o se il soggetto l’ha accettata. I badge danno a quell’affermazione tre eventi firmati separati con tre intenzioni di autori separati codificate in essi.

Le meccaniche sono costruite da una definizione indirizzabile, un premio e un elenco di visualizzazione. Una definizione badge è un evento kind 30009 pubblicato dall’emittente, indirizzabile tramite il suo tag d, così l’emittente può rivedere i tag name, description, image e thumb del badge più tardi senza cambiare l’identificatore a cui punta altro. Il premio è un evento kind 8 pubblicato dallo stesso emittente, con un tag a che tiene la coordinata 30009:<issuer-pubkey>:<d-identifier> della definizione e uno o più tag p che nominano i destinatari. L’elenco di visualizzazione è un evento kind 30008 pubblicato dal destinatario con il valore fisso d profile_badges, che elenca coppie di tag a e e dove il tag a è la coordinata di definizione e il tag e l’evento premio specifico. Quelle coppie sono ordinate e lette come coppie: un tag a il cui premio corrispondente è assente, o un tag e la cui definizione corrispondente è assente, viene ignorato, così un badge referenziato a metà non viene renderizzato silenziosamente.

I compromessi di design sono visibili in ciò che la specifica rifiuta di fare. Non c’è meccanismo di revoca né scadenza, quindi un premio è un’affermazione permanente dell’emittente su un momento nel tempo, e un emittente che cambia idea può solo cambiare la definizione a cui punta il premio. Non c’è trasferimento, quindi un badge non circola come token. Non c’è nozione di registry di emittenti fidati, il che spinge l’intera questione della fiducia sul client e sul lettore: un badge vale esattamente quanto vale la chiave pubblica del suo emittente per chi lo guarda. La specifica concede anche ai client la latitudine di mostrare meno badge di quelli elencati dal destinatario e di scegliere quale dimensione immagine renderizzare, così un profilo non diventa un muro di grafica scelto interamente da terzi.

La specifica adiacente più vicina è NIP-51, la specifica liste, e confrontare le due mostra perché i badge hanno bisogno di tre eventi invece di uno. Una lista è un autore che cura riferimenti; l’autore della lista è l’autore dell’affermazione. Un badge divide l’autorialità a metà, con l’emittente che firma che il premio è avvenuto e il destinatario che firma di accettarne la visualizzazione. Nessuna delle due parti può produrre il risultato visibile da sola, ed è ciò che separa un badge da un’etichetta auto-applicata.

Un premio kind 8 live recuperato da nos.lol e relay.primal.net questa settimana:

{
 "id": "08504dec368939bd63849a349cab83dea0ac199a852129dbf68cf35fe5c64e96",
 "pubkey": "bef514bd58c8ceea4beb9e6b84a8d983935f7be26f49e14df68098f1ba64156e",
 "created_at": 1787051248,
 "kind": 8,
 "tags": [
 ["a", "30009:bef514bd58c8ceea4beb9e6b84a8d983935f7be26f49e14df68098f1ba64156e:blocks_orange_league"],
 ["p", "92dfa05d915196a7a09152fa3f57871debfd422e1d278ac5af266a70c3350b1f", "wss://relay.damus.io"]
 ],
 "content": "Badge awarded!",
 "sig": "5bf0218dfec5e56b47339b0b4b992cceedd2e18798fb3d47cafea51850c00827f66251e4a3e08190370e04a5e1d4d092eeb441141b7219acdd18b80290a022f8"
}

Le implementazioni attuali coprono emissione, visualizzazione e lettura. Divine Mobile 1.0.20 conia e conferisce un badge dentro l’app e spiega un badge guadagnato quando un lettore lo tocca, Nostter PR #2281 aggiorna la gestione dei badge profilo in un client web, e Amethyst pubblica eventi premio con il proprio tag client, uno dei quali appare nei dati relay accanto all’esempio sopra.

Commenti (NIP-22)

NIP-22, definito dalla specifica primaria, fornisce un evento commento generale per rispondere a cose che non sono note di testo breve. Il threading delle note brevi aveva già NIP-10 (convenzioni tag di risposta), le cui convenzioni tag sono cresciute attorno al kind 1 e alle sue catene di risposta. NIP-22 esiste perché un video, un articolo, un evento calendario, una pagina wiki o un URL ha bisogno di una struttura di risposta che identifichi che tipo di cosa viene risposta, e che funzioni quando il target è indirizzabile o è una risorsa esterna senza alcun evento Nostr.

Le meccaniche ruotano attorno a una distinzione di maiuscole/minuscole. Un commento è un evento kind 1111 che porta due insiemi di tag: tag maiuscoli che descrivono la radice della discussione e tag minuscoli che descrivono il parent immediato. E, A e I nominano un evento radice, una coordinata indirizzabile radice o un identificatore esterno radice, K nomina il kind della radice e P l’autore della radice. I minuscoli e, a, i, k e p nominano gli stessi fatti sul parent, che è la radice stessa per un commento di primo livello e un altro commento kind 1111 per una risposta annidata. Separarli significa che un client può recuperare un’intera discussione con un filtro sui tag radice maiuscoli, senza percorrere la catena di risposte, mentre renderizza correttamente l’annidamento dai tag parent minuscoli. Le varianti I e i portano identificatori esterni nel formato NIP-73, ed è ciò che permette a un thread di commenti di attaccarsi a una pagina web, un episodio podcast o un libro.

I compromessi riguardano soprattutto ciò che NIP-22 rifiuta di assorbire. La specifica afferma che i commenti non devono essere usati per rispondere a note kind 1, il che evita che due modelli di threading competano sugli stessi oggetti e lascia NIP-10 dove già funziona. L’annidamento è permesso ma la radice resta fissa, quindi un thread profondo non perde mai il suo ancoraggio anche quando eventi intermedi non sono disponibili. I tag kind sono la parte portante: un client che recupera un commento senza il suo target può comunque capire a cosa sta guardando da K e k, e decidere se può renderizzare quel kind. Ciò che la specifica non fornisce è alcun modello di ordinamento o moderazione, quindi ordine di visualizzazione, collasso e nascondimento sono interamente policy del client.

Rispetto a NIP-10, la differenza sta nel typing. NIP-10 assume che il target sia una nota e codifica la posizione in un thread; NIP-22 codifica esplicitamente identità e kind del target e non assume altro su di esso. Quel typing esplicito è il motivo per cui le proposte più recenti in questo numero puntano al kind 1111: un commento porta già un’affermazione machine-readable su a cosa è attaccato.

Un commento kind 1111 live recuperato da nos.lol e relay.primal.net questa settimana, in risposta a un altro commento sotto un video:

{
 "id": "c8d335f8bfea58ecd1a943d6000fb2045f4bddf4a36c67df53eb661671f7ab45",
 "pubkey": "3e911baba55ae247339cf805dd6ff49ad2cd6bee84ac44e088ce66450c49104f",
 "created_at": 1787062681,
 "kind": 1111,
 "tags": [
 ["E", "1c492f2bac17b79d66934a340fa43d8d30d0aea4c9fa329346c05573ef912d70", "", "482d024b8acfde50e7429e5ac561d764f3a53a8b4fb0b6975369d9f0926ef839"],
 ["A", "34236:482d024b8acfde50e7429e5ac561d764f3a53a8b4fb0b6975369d9f0926ef839:e64ba9ea157b1a315caff51dbca656ed73ce817d4494e3966adf24055a86f5c5", ""],
 ["K", "34236"],
 ["P", "482d024b8acfde50e7429e5ac561d764f3a53a8b4fb0b6975369d9f0926ef839"],
 ["e", "7a14723b9ef999e74b1757a0fb74942cb6c121138d4ddafe096a57a67ed0a442", "", "8b69e548402afa997343d73e8088224a440f256350f6257b61acc4bb1fa4af4f"],
 ["k", "1111"],
 ["p", "8b69e548402afa997343d73e8088224a440f256350f6257b61acc4bb1fa4af4f"],
 ["client", "Divine", "31990:d95aa8fc0eff8e488952495b8064991d27fb96ed8652f12cdedc5a4e8b5ae540:divine-mobile", "wss://relay.divine.video"]
 ],
 "content": "niiice",
 "sig": "a5517fdea07647efa7ab1730fbea8df882690bba667e93ea5aeba4a73be6a49af1ee17c045535483650caf41dbbcb0897d5803fa39b59f395fd6f9bb193bb789"
}

I tag maiuscoli tengono il video e il suo autore mentre i minuscoli e e k puntano al commento parent, che è la forma descritta dalla specifica. Implementazioni che leggono e scrivono kind 1111 includono Divine Mobile, il cui tag client appare nell’evento sopra, Amethyst, i cui commenti appaiono negli stessi risultati relay, e nostrord, che renderizza i post dei thread come post di forum questa settimana. Il formato patch proposto in NIPs PR #2438 si costruisce sullo stesso kind.

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

Nostr Compass #35

Wed, 12 Aug 2026 00:00:00 +0000

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

Questa settimana: nostr-wot-extension aggiunge chiavi post-quantum e messaggi protetti opt-in accanto alle identità Nostr esistenti. Divine rafforza l’isolamento degli account, la validazione dei messaggi privati e la conferma di pubblicazione; MDK rafforza convergenza e recupero dei gruppi cifrati; e Amber rende esplicite le decisioni di firma raggruppate. Le release migliorano connessioni ai wallet, chat cifrata, scoperta sociale, sincronizzazione tra dispositivi e firma remota, mentre il lavoro sul protocollo copre identità e comunità cifrate. Gli approfondimenti spiegano richieste di cancellazione autenticate e segnalazioni decentralizzate.

Storie principali

nostr-wot-extension 0.4.0 aggiunge chiavi post-quantum accanto a un’identità Nostr

nostr-wot-extension 0.4.0 è un’estensione del browser per gestire identità Nostr e firmare. Gli account creati da un seed a 24 parole possono ora derivare chiavi di crittografia ML-KEM-1024 e di firma ML-DSA-87 accanto alla chiave Nostr esistente. Un flusso con un clic pubblica un’attestazione di kind 10203 che lega la chiave pubblica Nostr a entrambe le chiavi pubbliche post-quantum e include una proof of possession ML-DSA. Gli account importati da un mnemonic a 12 parole, un nsec nudo, un firmatario remoto o una chiave read-only non possono usare il flusso di derivazione, e l’estensione spiega tale limitazione nella vista dell’account.

La release aggiunge anche messaggi diretti post-quantum opt-in. Combina il shared secret ML-KEM con la chiave di conversazione del messaggio cifrato NIP-44 esistente tramite HKDF, poi mantiene i normali strati gift-wrap NIP-59 per nascondere i metadati nella consegna via relay. La crittografia non ricade mai silenziosamente dopo che un destinatario ha optato, mentre la decrittazione seleziona automaticamente il percorso appropriato. Questo protegge il nuovo percorso dei messaggi contro un successivo recupero di una chiave privata Nostr odierna, ma non sostituisce le firme degli eventi secp256k1; la release lascia esplicitamente quella migrazione più ampia a un futuro coordinamento con relay e client.

Divine Mobile 1.0.19 rafforza account, messaggi privati e pubblicazione

Divine Mobile 1.0.19 è un client mobile di video brevi che pubblica e recupera video tramite Nostr. Il selettore di account ora costruisce ogni identità connessa attorno a un container scoped per account, e una correzione alla pubblicazione impedisce che un video venga inviato sotto l’account sbagliato. I percorsi di pubblicazione sui relay attendono ora una risposta OK con semantica di successo esplicita, mentre un frame relay CLOSED può terminare la propria query in sospeso invece di lasciare la richiesta appesa.

La gestione dei messaggi privati rifiuta campi rumor non autenticati e seal non firmati, ripristina quattro casi di messaggi mancanti e instrada le conversazioni di gruppo da partecipanti completamente seguiti nella inbox. La release preserva anche i tag sugli eventi video indirizzabili quando le liste vengono aggiornate e consuma le richieste di cancellazione osservate così che i video rimossi scompaiano dallo stato locale. Queste modifiche seguono il lavoro sui timeout per query per relay trattato la scorsa settimana, ma spostano il focus dall’isolamento del recupero ai confini dell’identità, alla validazione dei messaggi e alla conferma di pubblicazione.

MDK 0.9.11 rafforza convergenza e recupero dei gruppi Marmot

MDK 0.9.11 è un kit di sviluppo Rust per Marmot, un protocollo di messaggistica di gruppo cifrata trasportato su Nostr. La release costruisce un sistema più ampio di convergenza e recupero attorno alla macchina a stati del gruppo: i passaggi di convergenza obsoleti si riaprono alla punta corrente del gruppo, le proiezioni delle capability in ingresso vengono committate atomicamente, i messaggi differiti ricevono durate di vita limitate tra i riavvii, e i checkpoint indirizzati per commit aiutano a recuperare i fork di commit propri di un’identità. Gli invii non stabili possono essere accodati e recuperati, mentre un percorso di stallo dell’epoca scala verso backfill e i messaggi inviati sopravvivono al lavoro di convergenza.

Storage e integrazioni host ricevono un passaggio parallelo di hardening. MDK elimina in modo sicuro le proiezioni SQLite potate, azzera le chiavi private importate, gli intermedi di export delle chiavi cifrate NIP-49 e i buffer di serializzazione OpenMLS, e redige le chiavi delle immagini di gruppo dall’output di debug. L’import dell’account può riprendere dopo un’interruzione, i percorsi di storage privato iOS e Android sono riparati, e gli host possono chiudere esplicitamente lo storage prima della sospensione. Nuove proiezioni leggere del roster e dell’appartenenza locale riducono ciò che le applicazioni devono leggere, mentre il connettore Hermes può consegnare diverse immagini generate da agent come un unico album Marmot.

Nostria 4.1.67 espande l’amministrazione delle comunità cifrate

Nostria 4.1.67 è un client social web e desktop per Nostr. Si basa sui gruppi sperimentali NIP-29 (gruppi gestiti da relay) e sulle comunità cifrate Concord introdotti in 4.1.53, aggiungendo scioglimento della comunità, amministrazione di icona e banner, caricamenti di foto cifrati con anteprime compresse, un selettore completo di reazioni e un layout a doppio pannello che mantiene aperta una comunità mentre l’utente legge note o articoli. La release aggiunge anche messaggistica in thread e un hub combinato per chat pubbliche, di gruppo e private.

Amber 6.4.0 rende esplicita ogni decisione di firma raggruppata

Amber 6.4.0 è un firmatario Android che mantiene le chiavi private Nostr separate dalle applicazioni che richiedono firme. La sua schermata multi-richiesta ridisegnata fornisce controlli Approva e Nega per ogni richiesta e ogni gruppo, sostituendo il precedente flusso di selezione e conferma. Le richieste negate inviate tramite l’interfaccia bunker mediata da relay di Amber ricevono ora risposte di errore corrette, così il client richiedente può distinguere un rifiuto da un firmatario bloccato.

Il codice sorgente taggato di Amber aggiunge anche etichette localizzate e leggibili per altri 113 kind di evento in ogni locale distribuito. Le aggiunte includono eventi di gruppo Concord, segnalibri di repository Git NIP-51 (liste e insiemi curati) ed eventi di presenza in stanza NIP-53 (attività live), dando agli utenti più contesto su dati non familiari prima di approvare una firma. Una guardia concurrent-map corregge anche un crash di sottoscrizione ai relay che poteva produrre un NegativeArraySizeException.

Safebox Acorn separa un componente di recupero portatile dall’app web

Safebox Acorn è un componente Python autonomo e un’interfaccia a riga di comando per proteggere chiavi, fondi e record controllati dall’utente tramite stato supportato da Nostr. L’estrazione di Acorn dalla più ampia applicazione web Safebox consente a un altro progetto Python di installare il runtime e usare i suoi helper per chiavi, profili Nostr, relay, record, Cashu, Lightning e crittografia senza adottare l’interfaccia web. Le attuali primitive di protezione dei record possono generare una nuova chiave a 256 bit, derivarne una da entropia fornita separatamente e codificare la chiave esatta come frase di recupero di 24 parole con checksum.

La guida al recupero e alla continuità del progetto presenta Acorn come componente di protocollo sostituibile all’interno di una Safebox domestica o comunitaria. Il design mantiene lo stato cifrato disponibile tramite un relay locale e repliche indipendenti, così il recupero non dipende da un singolo dispositivo, applicazione, relay, mint o fornitore di servizi. La documentazione chiarisce con attenzione il limite attuale: la cifratura dei record protetti è ancora in fase di progettazione, quindi le applicazioni non dovrebbero far dipendere i record dalla nuova chiave di protezione finché quel profilo non sarà implementato e sottoposto a revisione.

Rilasci taggati

Mostro Core 0.14.2 cambia l’envelope della chat cifrata

Mostro Core è la libreria Rust di tipi condivisi e funzioni peer-to-peer usata dal daemon di scambio Mostro e dai suoi client. La versione 0.14.2 sostituisce i messaggi di chat gift-wrap con envelope di kind 14 che usano chiavi separate di crittografia della conversazione e di firma derivate dal shared secret dei peer. Il nuovo reader valida autore, firma, destinatario, timestamp e dimensione del contenuto, mentre gli helper gift-wrap legacy restano disponibili così i client possono leggere entrambi i formati durante la migrazione.

Mostro 0.18.1 avvia un percorso escrow Cashu e rafforza il daemon

Mostro è un daemon di scambio Lightning peer-to-peer che coordina gli ordini tramite Nostr. La versione 0.18.1 getta le basi per un backend escrow Cashu, inclusi configurazione, helper del database, integrazione con mint, wiring all’avvio e la prima azione di lock. Può anche usare prezzi annunciati da un nodo fidato su Nostr e pubblica requisiti di proof-of-work per il primo contatto nel suo evento info sostituibile. La release aggiorna la dipendenza Nostr per una correzione denial-of-service NIP-44, rimuove le chiavi private dai log di restore-session, rifiuta messaggi di cooperative-cancel non autorizzati, rafforza i fetch LNURL contro server-side request forgery e hang, valida le invoice di payout e ripristina le sottoscrizioni alle hold invoice dopo un riavvio.

LaWallet NWC 2.3.0 aggiunge notifiche Nostr e ricevute zap

LaWallet NWC è una piattaforma Lightning Address open-source che collega i wallet tramite Nostr Wallet Connect (NIP-47). La versione 2.3.0 permette a ogni wallet di inviare notifiche di ricezione e inoltro come eventi Nostr configurabili, inclusi un tag destinatario p, relay selezionati, contenuto templato e crittografia opzionale NIP-44 (crittografia versionata); i tentativi riusano lo stesso ID evento firmato. Accetta anche zap request e pubblica ricevute firmate NIP-57 (zap) di kind 9735 dopo il regolamento, mentre una nuova vista delle capability dell’indirizzo mostra se l’indirizzo risolto supporta NIP-05, NIP-57 e i protocolli Lightning Address correlati.

nostr-double-ratchet TypeScript 0.0.166 lega inviti pubblici alle chiavi di sessione

nostr-double-ratchet fornisce primitive TypeScript e Rust per messaggistica diretta e di gruppo cifrata end-to-end su relay Nostr. TypeScript 0.0.166 richiede che una risposta a un invito dimostri la proprietà della sua chiave di sessione, impedendo a un invito pubblico riutilizzabile di legare un’identità Nostr alla sessione di un’altra parte. La release rifiuta anche campi rumor malformati e rafforza la validazione del payload; le sessioni esistenti continuano a funzionare, ma un invitante aggiornato rifiuta risposte senza prova da invitati più vecchi.

cln-nip47 0.2.0 espande e isola le richieste NWC

cln-nip47 è un plugin Core Lightning che espone un nodo ai wallet tramite Nostr Wallet Connect (NIP-47). La versione 0.2.0 aggiunge metodi NWC per creare, annullare e regolare hold invoice più una notifica hold_invoice_accepted, e pubblica l’insieme di metodi che il nodo connesso supporta effettivamente. Le risposte transaction-list si fermano ora a 500 voci e circa 128 kB, gli eventi di richiesta vengono deduplicati per ID evento, e la notifica fallita di un client non impedisce più la consegna agli altri client. La release rimuove anche i due metodi multi-payment che non fanno più parte della specifica NWC.

ClipRelay 0.1.3 ripristina connessioni a relay e firmatario dopo periodi di inattività

ClipRelay sincronizza gli appunti di un utente tra dispositivi tramite relay Nostr, cifrando il contenuto verso la stessa identità con NIP-44 (crittografia versionata). Le release desktop e Android 0.1.3 corrispondenti aggiungono una casella di testo per inviare testo digitato direttamente agli appunti di un altro dispositivo. Testano anche la liveness con round trip reali sui relay dopo periodi di inattività, escalando da risottoscrizione a sostituzione del socket e a un pool di connessioni ricostruito, mentre le chiamate al firmatario NIP-46 (firma remota mediata da relay) bloccate ora scadono e si ricostruiscono automaticamente.

NoorNote 1.3.2 sposta la scoperta degli articoli nel grafo sociale

NoorNote è un client Nostr per post social, messaggi cifrati, articoli in formato lungo e altri kind di evento su web, desktop e Android. La versione 1.3.2 sostituisce il feed globale piatto degli articoli con una scoperta tratta da contatti di primo, secondo e terzo grado, offrendo ai lettori una timeline di articoli radicata nel grafo dei follow. Collassa anche raffiche di messaggi diretti riprodotti da mittenti sconosciuti in un’unica notifica continua invece di produrre una pila di toast man mano che arriva la cronologia dei relay.

Bray 2.4.0 aggiunge un dialetto compatto di firma remota

Bray è un server MCP Nostr che offre ad agenti software e persone strumenti per accesso ai relay, identità, pubblicazione e firma remota. La versione 2.4.0 accetta una richiesta di firma il cui evento è un oggetto oltre alla forma stringificata usata da NIP-46 (firma remota mediata da relay), e aggiunge sign_event_compact, che restituisce solo ID evento, firma, chiave pubblica e timestamp. Quel formato più piccolo di richiesta e risposta riduce l’uso di memoria per firmatari hardware vincolati, mentre il flusso standard sign_event resta invariato e entrambi i dialetti producono una firma sull’ID dell’evento ricevuto.

Appena scoperti

Pact porta legami tra agenti con consenso reciproco su Nostr

Pact, scoperto questa settimana, è uno strato relazionale in fase iniziale per agenti software costruito su MATE.md e su una bozza di trasporto NIP-BD. I suoi legami firmati con consenso reciproco sono detenuti dalle chiavi degli agenti stessi e possono essere pubblicati su Nostr, mentre i legami privati usano il gift wrapping NIP-59 (metadati nascosti). Il monorepo include un server MCP, SDK TypeScript, client da riga di comando, daemon self-hostable e interfaccia web. La sua attività più recente nel repository precede la finestra settimanale di questo numero, quindi questa è una nota di scoperta e non l’affermazione di una nuova release.

Modifiche non rilasciate

nostrord mantiene sincronizzato il muting di gruppo tra dispositivi

nostrord è un client multipiattaforma per comunità gestite da relay. La PR #250 memorizza le scelte di mute per gruppo di ogni account in un evento NIP-78 (dati specifici dell’applicazione) di kind 30078 auto-cifrato, così un’impostazione fatta su un dispositivo può seguire l’utente su un altro senza rivelare la lista dei gruppi al relay. Il record sostituibile usa l’ordinamento per evento più recente, ascolta le modifiche in tempo reale e ripristina l’interfaccia quando la firma o la pubblicazione falliscono invece di lasciare lo stato locale fuori sync. I gruppi mutati smettono anche di contribuire ai totali non letti visibili mantenendo la posizione non letta per la visita successiva.

Amethyst completa il ciclo di vita degli inviti Concord

Amethyst è un client Nostr Android il cui supporto alle comunità cifrate implementa il protocollo Concord. La PR #3888 permette ai link di invito di sopravvivere a un refounding della comunità riemettendo i bundle alle stesse coordinate indirizzabili, mentre un controllo di ban impedisce a un membro rimosso di usare quel percorso di recupero. Implementa anche la lista inviti cifrata CORD-05 sia sull’app sia sul client da riga di comando amy, aggiunge tombstone di revoca per link, e richiede conferma del relay prima di eliminare l’unica chiave di firma memorizzata che può ritirare un link. Lo stesso lavoro dà a amy i percorsi di consegna della control key, refounding, rekeying e recupero dei membri stranded necessari per seguire le epoche comunitarie successive.

Buzz porta l’aspetto di ogni comunità tra desktop e mobile

Buzz è uno workspace comunitario basato su Nostr con client desktop e mobile. Le PR desktop PR #3653 e mobile PR #3767 unite memorizzano tema, accento e scelta della modalità di sistema di ogni comunità come record NIP-78 cifrato sul relay di quella comunità. Entrambi i client condividono lo stesso payload versionato e mantengono cache locali scoped per identità, così cambiare comunità o account non può applicare l’aspetto sbagliato mentre il relay non è disponibile. Ordinamento di sostituzione, scritture protette e risottoscrizione dopo una connessione chiusa permettono ai due client di riconvergere dopo la riconnessione.

Buzz Desktop 0.5.10 è seguito prima del cutoff del numero con un passaggio di performance e affidabilità. Rimuove regressioni introdotte dopo 0.5.9, accelera il caricamento dei canali, limita la retention iniziale della timeline, coalescesce la persistenza dello stato di lettura, preserva timeline di canale fresche e impedisce al worker di ingest dei relay di crashare sulle reazioni agli eventi di progetto. Aggiunge anche l’invio di un messaggio di thread a un canale e restringe la ricerca desktop allo scope previsto.

Aggiornamenti NIP e lavoro di specifica del protocollo

NIP

La PR NIPs #2435 è un emendamento aperto a NIP-34, che standardizza la collaborazione su repository git tramite eventi Nostr. Aggiunge un tag b opzionale a un evento pull-request così l’autore può nominare un branch di destinazione diverso dal default del repository. La proposta corrisponde al supporto già implementato in ngit e GitWorkshop, ma non è entrata nella specifica.

La PR NIPs #2434 è una proposta aperta per chiavi di identità post-quantum. Deriva chiavi post-quantum di crittografia e firma accanto alla chiave secp256k1 esistente da un seed di derivazione chiavi NIP-06, poi lega le chiavi pubbliche all’identità Nostr con un’attestazione di kind 10203. La bozza limita la sua pretesa alla protezione della riservatezza dei messaggi precedenti se secp256k1 venisse compromesso in seguito; non sostituisce le firme degli eventi odierne.

La PR NIPs #2431 è un emendamento aperto a NIP-07 per firmatari browser. Un client potrebbe allegare la chiave pubblica che si aspetta alle richieste di firma o crittografia, richiedendo al firmatario di usare quell’account o rifiutare la chiamata. Ciò impedirebbe a una pagina di continuare silenziosamente sotto un’identità diversa dopo che l’utente cambia account nel firmatario.

La PR NIPs #1813 resta una proposta open double-ratchet dopo lavoro sostanziale nella finestra. Specifica conversazioni cifrate forward-secret le cui chiavi avanzano con i messaggi, con un’implementazione già disponibile nella libreria nostr-double-ratchet e in Iris. Resta una bozza, non un NIP unito.

La PR NIPs #2433 si è aperta e chiusa senza merge nella finestra. Proponeva di chiarire gli errori relay NIP-42 così auth-required significherebbe che un’altra autenticazione potrebbe cambiare il risultato, mentre restricted significherebbe che non potrebbe. La distinzione riguardava connessioni autenticate per una chiave ma ancora prive di autorizzazione per un’altra; lo stato chiuso significa che la formulazione non è entrata nella specifica.

La PR NIPs #2378, trattata in precedenza mentre era ancora proposta, si è ora chiusa senza merge. I suoi eventi proposti di agent passport, discovery, task, marketplace, invoice e connection restano quindi fuori dall’insieme dei NIP.

Il commit NIPs 656cecc ha unito una correzione solo documentale a NIP-29. Aggiunge un tag previous all’esempio di metadati del gruppo, mostrando come un evento di sostituzione possa identificare l’evento che sostituisce. Questo chiarisce un esempio e non introduce una nuova funzionalità di protocollo.

Concord e CORD

La PR CORD #18 frammenterebbe le Community List cifrate su eventi di kind 33302, rimuoverebbe il limite di 50 appartenenze e poterebbe le voci ritirate per restare entro i limiti dei relay. Altre due proposte aperte aggiungono locator di menzione privati e un segnale di pausa che sospende la chat senza scartare i messaggi.

La PR CORD-02 #15 si è unita il 6 agosto e restringe le scritture al piano di controllo di una comunità. Proprietari e staff detengono un nuovo secret di firma control_root, mentre tutti i membri conservano la chiave pubblica derivata e la read key necessarie per verificare e decifrare lo stato di moderazione. La write key è una barriera anti-spam, non un sostituto delle firme interne dell’attore e dei controlli del roster che stabiliscono l’autorità.

La PR CORD #12, trattata in precedenza come bozza aperta, si è ora chiusa senza merge. La sua porzione di piano di controllo è stata superata dall’emendamento CORD-02 più ristretto unito sopra, mentre canali restricted-write e gli altri materiali di bozza non sono entrati nella specifica.

Approfondimento NIP

Richieste di cancellazione degli eventi (NIP-09)

NIP-09 (richieste di cancellazione eventi), definito dalla specifica principale, offre a un autore di evento un modo firmato di chiedere a relay e client di smettere di servire uno o più eventi di quell’autore. Non cancella ogni copia. Trasporta l’intenzione dell’autore attraverso la stessa rete di relay che ha distribuito l’evento originale.

La richiesta è un evento firmato ordinario di kind 5. I suoi tag contengono uno o più riferimenti e a ID evento specifici o riferimenti a a coordinate di eventi indirizzabili, e le regole dei tag NIP-09 dicono che dovrebbe includere un tag k per ogni kind di evento referenziato. Il content opzionale può spiegare il motivo. Per un riferimento a, un relay dovrebbe rimuovere ogni versione a quella coordinata il cui timestamp non è successivo al created_at della richiesta, impedendo a una vecchia richiesta di cancellazione di sopprimere una sostituzione successiva.

L’autore è il confine di sicurezza. Un relay dovrebbe smettere di pubblicare un evento referenziato solo quando la sua pubkey corrisponde alla pubkey della richiesta di cancellazione, e un client deve eseguire quel controllo prima di nascondere un evento. Un relay potrebbe non possedere l’evento referenziato e quindi non essere in grado di validare la relazione quando accetta la richiesta, così i client non possono trattare l’accettazione del relay come prova che la cancellazione fosse autorizzata. La specifica chiede anche ai relay di conservare la richiesta di kind 5 perché un altro client potrebbe già detenere l’evento originale e incontrare la richiesta in seguito.

Ecco un evento firmato di kind 5:

{
 "id": "6f39fd3d0d593d97dd093f21fabe8f78895579d6979a6ecf14e169bd85bb0943",
 "pubkey": "5877220aaae6e54a6f974602d5995c0fe24a3ea7ddabd8644bec795b9da00743",
 "created_at": 1786465675,
 "kind": 5,
 "tags": [
 ["e", "f3d47f8b813928c5baf7ac993846be0220dc37a2e7c7b128fb49a4b92711f131"],
 ["k", "30091"],
 ["a", "30091:5877220aaae6e54a6f974602d5995c0fe24a3ea7ddabd8644bec795b9da00743:survey:0ad5cebc-608b-47d7-97fd-9e6c47787199"],
 ["t", "nostr-survey"]
 ],
 "content": "Public survey summary deleted during privacy refresh",
 "sig": "846be83b038dc5f91af0c9d03a4ac81aff9bc4cfde7d85c849fa2fdae890f75cc444a4072f45aa18883b0b3871e15381b220182d6e366892f0c9c6f9c0557244"
}

La cancellazione resta una politica cooperativa, non la revoca di un oggetto firmato. Un relay, una cache, uno screenshot o un client offline possono preservare i byte originali, e cancellare la richiesta di kind 5 stessa non la annulla. I client possono nascondere l’obiettivo, contrassegnarlo come disconosciuto o mostrare il motivo della richiesta, ma dovrebbero dire agli utenti che una cancellazione universale non può essere garantita. Questo differisce da NIP-40, dove un tag expiration chiede ai relay di smettere di memorizzare un evento dopo un tempo scelto al momento della pubblicazione. NIP-09 gestisce una decisione successiva dell’autore e può puntare a eventi già distribuiti.

Le implementazioni attuali applicano quella politica a livelli diversi. La PR Divine #6623 rimuove i video cancellati dall’event store del client, la PR strfry #251 estende le richieste di cancellazione valide ai destinatari gift-wrap, e Amethyst dichiara supporto NIP-09 nel suo client. Il client di gruppo di nostrord offre un altro percorso di implementazione attuale.

Segnalazioni (NIP-56)

NIP-56 (eventi di segnalazione), definito dalla specifica principale, standardizza una segnalazione firmata su un account, un evento o un blob referenziato. Separa il segnale di segnalazione dalla decisione di moderazione, permettendo a ogni client o relay di scegliere quali reporter fidare e quale risposta si adatti alla propria politica.

Una segnalazione usa kind 1984 e deve identificare l’account segnalato in un tag p. Segnalare una nota richiede anche un tag e per l’ID evento. Il terzo valore del tag porta una delle categorie specificate: nudity, malware, profanity, illegal, spam, impersonation o other. Una segnalazione su un blob può usare il suo hash in un tag x, un tag e per l’evento che ha referenziato il blob, e un tag server opzionale per una posizione. I tag opzionali L e l da NIP-32 possono aggiungere un’etichetta con namespace quando l’elenco fisso di categorie non è abbastanza preciso.

L’evento prova solo che una chiave ha fatto un’accusa. Il contenuto segnalato non diventa falso, illegale o rimovibile solo perché esiste un kind 1984 valido, e un relay aperto non può contare in sicurezza segnalazioni anonime come voti. La specifica sconsiglia la moderazione automatica del relay perché le segnalazioni sono facili da manipolare, permettendo però agli amministratori di relay di agire su segnalazioni da moderatori che già fidano. Un client può invece pesare le segnalazioni attraverso il grafo sociale dell’utente, per esempio sfocando contenuti dopo che diversi contatti fidati segnalano lo stesso account.

Ecco un evento firmato di kind 1984:

{
 "id": "17301ea66066d34af9ba0b6957ed9d9d8854b9436939e682e21e7a5a8768e4b2",
 "pubkey": "1ff02fb5cdc633c1be55368ab655490ec25d2f5dc2e364d4703bc3196d99eab1",
 "created_at": 1786465319,
 "kind": 1984,
 "tags": [
 ["p", "3a72b02cc05ee07310dc580874b6a9ca8271c6518b90655bd2e98003c9601e68", "impersonation"]
 ],
 "content": "",
 "sig": "6362e415410feb19e0505654a4660e8456b6b2aec5ae39173a0429a6a8e5fa1381c9488198ca2982db43ee8198af056f2a25537705c763784062056d0ab2eb1a"
}

NIP-56 e NIP-09 risolvono problemi diversi. Una segnalazione di kind 1984 può prendere di mira l’account o l’evento di qualcun altro, ma non conferisce alcuna autorità di cancellazione. Una richiesta di kind 5 esprime l’intenzione dell’autore originale ed è valida solo contro gli eventi di quell’autore. Nessuna garantisce la rimozione: NIP-56 delega deliberatamente l’azione alla politica di moderazione locale, mentre NIP-09 dipende da relay e client che onorano una richiesta autenticata.

Le implementazioni espongono quelle scelte in prodotti diversi. La PR Divine #6591 corregge la consegna delle segnalazioni in un client di video brevi, la PR Conduit #250 legge le segnalazioni come contesto limitato per i partecipanti al marketplace, e il modulo NIP-56 di nostrord pubblica e processa eventi di segnalazione. Amethyst elenca anche il supporto NIP-56 attuale.

Invia un DM NIP-17 per condividere un progetto o una notizia tramite il progetto Nostr Compass.

Nostr Compass #34

Wed, 05 Aug 2026 00:00:00 +0000

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

Questa settimana: Sandstr permette ai nuovi arrivati di esplorare client Nostr simulati senza creare chiavi né installare un’app. nostr-mill aggiunge il consenso del firmatario per evento e il recupero delle chiavi tra client, mentre nostrord espande i gruppi ospitati su relay, i firmatari, la moderazione, i caricamenti e i highlight. Il lavoro sul protocollo copre i formati di eventi Nostr, le connessioni ai wallet, la scoperta dei relay, i napplets, Marmot e Concord; gli approfondimenti spiegano la ricerca assistita dai relay e i highlight portatili.

Storie principali

nostr-mill 1.6.0 porta il consenso alla firma e il recupero dell’account nel browser

nostr-mill 1.6.0 è un selettore di account e firmatario integrabile nel browser. Ora chiede il consenso per kind di evento e mostra contenuto e tag decodificati prima della firma, con concessioni a tempo limitato e un gestore dei permessi. La release corregge anche un bug della prima sessione che permetteva alle categorie configurate per chiedere ogni volta di firmare senza chiedere. Il suo onboarding opzionale con Google può importare un nsec esistente, memorizza la chiave cifrata nella cartella dei dati dell’app Drive dell’utente, supporta più identità e può esportare un ncryptsec in formato NIP-49 (formato di chiave privata cifrata).

Il backup sperimentale su relay deriva una frase di recupero robusta con scrypt e HKDF, avvolge la chiave come ncryptsec, verifica gli eventi recuperati e richiede un quorum di relay prima del recupero. Il login NIP-55 (intent del firmatario Android) ora usa il percorso di ritorno tramite appunti di Amber, e le connessioni NIP-46 (firma remota mediata da relay) sono silenziose per impostazione predefinita. Controlli di branding e schermate dei permessi responsive completano la release senza modificare le integrazioni esistenti, a meno che un operatore non lo scelga.

nostrord 2.5.0 dà ai gruppi su relay identità stabili e specifiche del relay

nostrord 2.5.0 è un client multipiattaforma per comunità ospitate su relay. Ora deriva un’identità NIP-29 (gruppi gestiti da relay) sia dall’ID del gruppo sia dal relay ospitante, delimita allo stesso modo appartenenza e badge di amministratore, accetta deep link naddr di gruppo e sincronizza i thread dei gruppi privati tra dispositivi.

La release aggiunge anche una casella di moderazione con NIP-56 (eventi di segnalazione), login con Amber tramite NIP-55, backoff per il rate-limit del traffico del firmatario NIP-46, rendering di NIP-84 (highlight portatili) con nuovi tentativi per i riferimenti non risolti, e caricamenti multimediali tramite Blossom o NIP-96 (archiviazione file HTTP). Il login con Google ora esegue il backup della chiave prima della creazione dell’account e conferma le disconnessioni. Le risposte nei thread ottengono contenuti più ricchi e la cancellazione da parte degli amministratori, mentre le correzioni al portachiavi desktop e alla tastiera mobile mantengono utilizzabili quelle funzionalità di protocollo.

Primal Android 3.5.25 aggiorna la firma remota e il filtraggio della lista dei seguiti

Primal Android 3.5.25 è un client mobile Nostr con feed, ricerca e firma remota. Aggiorna il suo firmatario remoto al comportamento attuale del protocollo, aggiunge una lista di silenziati dei seguiti, apre la ricerca da Esplora, ripara automaticamente le connessioni ai relay bloccate, espone i timeout delle richieste nell’interfaccia, rifiuta le voci non valide della lista dei seguiti e aggiorna gli URL dei relay di riserva. Il prefetching dei feed, il minor uso di memoria e un limite di cache di 100 MB riducono il costo di mantenere aggiornati quei feed. Le note con una sola immagine ora usano tutta la larghezza del contenuto, e i controlli del profilo e il precaricamento dei media ricevono correzioni minori di interazione e ordinamento.

Nostur 1.30.2 espande le risposte private e i media nei messaggi diretti

Nostur 1.30.2 è un client Nostr per piattaforme Apple. Espone sempre l’azione di risposta privata, aggiunge cache di media per conversazione con limiti e controlli di cancellazione, migliora il completamento automatico di nomi e tag nei post e nelle chat, mostra i messaggi referenziati nella chat dal vivo e include il titolo della stanza nelle notifiche di chat. Le correzioni alla paginazione del feed e alle risposte annidate affrontano regressioni nel recupero e nel rendering delle conversazioni.

Chama 5.7.0 aggiunge i registri degli arbitri e il recupero degli scambi dalla cache

Chama 5.7.0 coordina scambi tra pari e arbitrato tramite catene di eventi Nostr firmati. Mostra l’importo bloccato di un arbitro, l’anzianità della sua cauzione e il suo outpoint di finanziamento; registra quando un sostituto ha rimpiazzato un arbitro assente; e definisce le attestazioni di colpa dormienti di kind 38136 che richiedono le firme di entrambi i principali. Una riparazione esplicita riprova le cronologie incomplete dei relay contro la cache durevole del dispositivo e ripubblica gli eventi recuperati, mentre le pubblicazioni fallite vengono accodate per la connessione successiva. La release impedisce inoltre pagamenti duplicati tra dispositivi del premio dell’arbitro trattando l’evento di kind 38113 dell’autore come la registrazione del pagamento.

Auditable Voting 0.1.165 ripristina la consegna delle schede delegate

Auditable Voting 0.1.165 conduce votazioni verificabili separando le credenziali dell’elettore dal contenuto della scheda. Ripristina l’emissione delegata di schede cieche tramite consegna autenticata delle deleghe e recupero dei DM di controllo, mantiene i messaggi diretti delle credenziali cieche sui relay privati configurati e aggiorna il proxy di audit alla versione 0.1.52.

Sandstr permette ai nuovi arrivati di provare i client Nostr con dati finti

Sandstr offre simulazioni interattive nel browser dei client Nostr così che un nuovo arrivato possa confrontare le loro interfacce prima di installarne uno o creare una coppia di chiavi. Il suo lancio del 3 agosto include riproduzioni verificate sul riferimento di Damus, Amethyst, Primal, Snort, YakiHonne, Coracle e Wisp, oltre ad anteprime iniziali chiaramente etichettate di Gossip, Keychat e Olas. Tutto funziona localmente su dati finti, quindi le simulazioni non generano chiavi né si connettono ai relay. Ogni simulazione rimanda al sito web e al repository del codice del client reale, rendendo Sandstr uno strumento di onboarding e confronto delle interfacce piuttosto che un altro client Nostr. Mostra come si presentano feed, profili, thread, messaggi diretti, ricerca, zap e controlli dei relay senza chiedere a un utente alle prime armi di prendere in anticipo una decisione di identità o sicurezza.

mineracks signer abbina un’estensione del browser a un bunker desktop

mineracks signer offre due superfici di firma dallo stesso progetto. La sua estensione del browser implementa NIP-07 così che le applicazioni web possano richiedere firme senza ricevere la chiave privata, mentre l’applicazione desktop espone un firmatario remoto NIP-46 per i client che comunicano tramite relay.

La release desktop 0.1.0 del progetto memorizza il materiale delle chiavi con la codifica a chiave cifrata di NIP-49 e mantiene la chiave decifrata all’interno del processo Rust anziché passarla all’interfaccia. Ogni richiesta mostra l’applicazione chiamante e l’azione richiesta, mentre l’approvazione automatica per applicazione è opzionale e revocabile. La prima build desktop supporta Apple Silicon ma non i Mac Intel.

Release

Jumble 26.8.1 aggiunge controlli di proof-of-work e anteprime dei commenti

Jumble 26.8.1 è un client Nostr web e desktop. Ricorda la difficoltà del proof-of-work per la pubblicazione, mostra badge di lavoro verificato, mostra in anteprima i commenti collegati sopra il contenuto esterno, salva le immagini dal visualizzatore a schermo intero ed espande le biografie lunghe del profilo su richiesta. Le notifiche delle reazioni ora scartano i kind di evento non supportati, gli avvisi di disconnessione dai relay sono meno invadenti, i relay predefiniti sono stati aggiornati ed è stato corretto un conflitto di riproduzione automatica dei media.

nostr-calendar 2.1.0 ripristina il binding del firmatario per i moduli privati

nostr-calendar 2.1.0 pubblica calendari, eventi e risposte ai moduli come dati Nostr. Lega gli invii dei moduli privati al firmatario attivo, salva gli eventi duplicati intenzionali sui relay, corregge il recupero dai relay, analizza le date del calendario nell’ora locale e aggiunge notifiche dell’app oltre a un client iOS. La correzione del firmatario impedisce a un’identità obsoleta di produrre una risposta cifrata inutilizzabile.

Manent 2.0.0 aggiunge tag e ricerca per le note salvate

Manent 2.0.0 è un archivio personale per note Nostr firmate. Aggiunge tag locali e ricerca, permettendo al lettore di organizzare e recuperare gli eventi salvati senza modificarne il contenuto firmato.

nosvelte 0.6.1 chiude le sottoscrizioni vuote dopo l’EOSE

nosvelte 0.6.1 fornisce componenti e hook reattivi di Svelte per i dati dei relay. Le ricerche vuote ora si concludono all’End of Stored Events, la cancellazione chiude il REQ sottostante, i nuovi tentativi cancellano gli errori obsoleti e gli hook di lista restituiscono il loro valore vuoto documentato. Riconosce inoltre gli eventi indirizzabili indipendentemente da dove appaia il loro tag d, sostituisce metadati e articoli superati, deduplica le reazioni per ID evento e conserva ogni evento del primo batch di un relay.

Modifiche non rilasciate

NMP lega l’ammissione al relay alle dichiarazioni e amplia le query di gruppo

NMP è un toolkit TypeScript per costruire applicazioni Nostr e interfacce di gruppi supportati da relay. La PR #1254 fa sì che l’ammissione al relay segua il proprietario della dichiarazione che la autorizza, mantenendo la decisione sui permessi legata allo stato Nostr firmato. La PR #1255 generalizza le query dei gruppi gestiti da relay di NIP-29 invece di assumere un’unica forma di ricerca ristretta. Entrambe le modifiche sono state unite ma non sono ancora apparse in una release taggata.

Mosaico deriva l’identità del gruppo gestito dai record del relay

Mosaico è un client Nostr per esplorare e amministrare comunità gestite da relay. La PR #758 deriva l’identità di un gruppo gestito dal relay che ospita i suoi record autorevoli. La PR #757 osserva il record pubblicato del gruppo nel risolvere lo stato di amministrazione. Questo mantiene distinti due gruppi con nomi simili su relay diversi e offre ai client una fonte supportata dal relay per i loro metadati di gestione.

Divine isola i relay lenti durante le query multi-relay

Divine è un client mobile di video brevi che pubblica e recupera video tramite Nostr. La PR #6673 dà a ogni query di relay il proprio timeout invece di lasciare che una connessione bloccata consumi il budget di tempo di un’intera richiesta. I risultati dei relay che rispondono possono quindi arrivare mentre l’endpoint lento viene abbandonato indipendentemente. La modifica migliora il recupero senza trattare un relay come autorevole per il risultato combinato.

rust-nostr rafforza crittografia, hash e riconciliazione

rust-nostr è una libreria e un toolkit Rust per client, relay e implementazioni del protocollo Nostr. La PR #1421 riduce le allocazioni nel suo percorso di crittografia versionata NIP-44, mentre la PR #1423 introduce hash tipizzati che rendono più difficile mescolare accidentalmente valori di digest incompatibili. Il commit 21e31c2 impedisce a un messaggio malformato di riconciliazione degli insiemi Negentropy di NIP-77 di disconnettere il relay locale. Il lavoro unito rafforza sia la gestione dei payload cifrati sia il comportamento di fallimento della riconciliazione prima della prossima release.

Zeus serializza i pagamenti NWC prima di addebitare i budget di spesa

Zeus è un wallet mobile Bitcoin e Lightning che può esporre operazioni del wallet tramite Nostr Wallet Connect. La PR #4305 conta i pagamenti in sospeso contro un budget NIP-47 Nostr Wallet Connect invece di attendere il regolamento. La PR #4303 serializza la gestione dei pagamenti così che le richieste concorrenti non possano correre attraverso lo stesso limite di autorizzazione. La coppia unita chiude una lacuna nell’applicazione dei budget sulla superficie di controllo Nostr del wallet.

Nostr Components condivide un unico tentativo di connessione al relay

Nostr Components è una libreria riutilizzabile di componenti web per aggiungere dati e interazioni Nostr alle applicazioni. La PR #105 permette ai componenti montati contemporaneamente di condividere un tentativo di connessione al relay in corso. Ogni consumatore riceve comunque la connessione risultante, ma i montaggi concorrenti non aprono più socket duplicati mentre il primo handshake è in attesa. La modifica riduce il carico evitabile sui relay nelle applicazioni assemblate da diversi componenti indipendenti.

Aggiornamenti NIP e lavoro di specifica del protocollo

Formati di eventi Nostr e scoperta

La PR NIP #2430 propone pacchetti di adesivi come definizioni indirizzabili di kind 30031 e i pacchetti installati da un utente come kind sostituibile 10031. Ogni tag di adesivo porta uno shortcode, un hash SHA-256 e un tipo MIME; l’immagine resta su un server NIP-B7 (archiviazione blob Blossom). La bozza aperta standardizza così identità e installazione dei pacchetti senza collocare i byte dell’immagine negli eventi.

La PR NIP #2429 propone documenti Gopher indirizzabili di kind 31436. Ogni evento contiene un nodo di testo o menu UTF-8, e i nodi firmati sotto una stessa pubkey formano un gopherhole che qualsiasi bridge RFC 1436 supportato da relay può servire. La proposta aperta usa il normale storage degli eventi indirizzabili invece di legare la pubblicazione a un unico hostname Gopher.

La PR NIP #2428 propone gruppi privati con biglietti per epoca. Un gruppo ruota le credenziali di appartenenza tra epoche, e i client presentano il biglietto dell’epoca corrente per partecipare. La bozza punta alla chat privata senza chiedere a un relay di trattare un bearer token permanente come appartenenza a vita.

La PR NIP #2425, trattata come proposta la scorsa settimana, ha ora unito un chiarimento sugli URI in NIP-B0 (segnalibri web indirizzabili). Distingue i prefissi HTTPS omessi dagli schemi URI espliciti quando un segnalibro memorizza la sua destinazione nel tag d, impedendo ai client di ricostruire una destinazione ambigua.

Pagamenti e connessioni ai wallet

La PR NIP #2419, trattata come proposta nel numero del 22 luglio, ha ora unito un nucleo NIP-47 (Nostr Wallet Connect) ridotto. Gli URI di connessione, il trasporto cifrato su relay, la scoperta delle capacità, la negoziazione della crittografia e i metodi comuni restano nel NIP; notifiche, fatture in sospeso, keysend, cronologia delle transazioni, metadati e accoppiamento tramite deep link passano a un repository di estensioni dedicato. Le connessioni esistenti restano compatibili mentre i wallet possono implementare i contratti opzionali in modo indipendente.

La PR NWC #2, trattata come proposta la scorsa settimana, ha ora unito i metodi di pagamento BIP-321 in quel repository di estensioni. BIP-321 fornisce un URI di pagamento Bitcoin comune che può portare diversi rail, così che i chiamanti NWC possano richiedere o inviare un pagamento senza aggiungere un nuovo RPC centrale per ogni tipo di istruzione sottostante.

Capacità dell’host dei napplets

La PR NAP #95 propone la scoperta del catalogo per applicazioni in sandbox distribuite via Nostr. Un napplet chiede al suo host quali applicazioni e capacità sono disponibili, e l’host restituisce metadati filtrati per policy invece di esporre tutto il suo ambiente locale. Il contratto supporta le decisioni di lancio senza concedere autorità di esecuzione durante la scoperta.

La PR NAP #33 propone caricamenti di file e blob mediati dalla shell. Un napplet fornisce byte e intenzione; l’host seleziona un rail NIP-96 o Blossom, firma l’autorizzazione, riporta i progressi e restituisce URL, hash, dati MIME e tag NIP-94 (metadati di file) pronti da allegare. Credenziali di storage e autorità HTTP non entrano mai nel napplet.

Gruppi cifrati Marmot

La PR Marmot #410 ha unito regole di convergenza e di input differito. I client distinguono un oggetto a cui manca una dipendenza dall’epoca corrente da un input obsoleto o non valido, lo mantengono idoneo per un nuovo recupero dopo un rifiuto di risorse e riprovano quando un altro commit cambia il contesto di decrittazione. Un commitment di stato con separazione di dominio offre ai test di conformità un oracolo di convergenza condiviso senza aggiungere un campo wire di produzione.

Piani comunitari di Concord

La PR Concord #14 ha unito i messaggi a scomparsa di CORD-08. Un valore di metadati della comunità fissa la durata; i rumors di chat e gli involucri cifrati portano un tag NIP-40 (scadenza degli eventi), mentre gli eventi di cancellazione e l’avviso del timer di kind 1740 ne sono esenti. Il timer firmato viaggia con lo stato della comunità, anche se la cancellazione da parte del relay resta una richiesta di conservazione e non una garanzia crittografica di eliminazione.

La PR Concord #13 ha unito in CORD-04 il pinning resistente alle rotazioni. Ogni canale ha una lista di pin a sostituzione completa sul piano di controllo; le voci portano il sigillo firmato originale più le chiavi di espansione NIP-44 per messaggio, permettendo a un nuovo membro di verificare autore e testo in chiaro senza ricevere una vecchia chiave d’epoca. Le liste private possono restare sigillate a un’epoca del canale, dei limiti vincolano la dimensione della lista, e le cancellazioni dell’autore rimuovono i pin senza biforcare la catena del piano di controllo.

Approfondimento NIP

Capacità di ricerca (NIP-50)

NIP-50, definito nella specifica principale, aggiunge un filtro di ricerca opzionale per i relay. I filtri Nostr ordinari funzionano quando un client conosce già un autore, un kind di evento, un identificatore o un tag; NIP-50 affronta la scoperta quando l’input è una query umana come best nostr apps.

Il formato wire di NIP-50 aggiunge una stringa search a un filtro normale all’interno di un messaggio REQ. Una richiesta può combinare quel campo con kinds, authors, ids, filtri di tag e limit, e un REQ può portare diversi filtri indipendenti. Un relay che lo supporta dovrebbe cercare principalmente nel content dell’evento, può usare altri campi quando il kind di evento lo rende utile e dovrebbe ordinare secondo il proprio punteggio di rilevanza prima di applicare il limit. Quest’ordine differisce dal consueto flusso di eventi dal più recente al più vecchio.

La stringa di query può includere le estensioni key:value della specifica. Essa nomina include:spam, domain:, language:, sentiment: e nsfw:; un relay dovrebbe ignorare le estensioni che non implementa. I client scoprono il supporto dichiarato tramite il campo supported_nips di NIP-11 del relay, ma possono comunque inviare il filtro altrove se sono pronti a scartare risposte non pertinenti.

La specifica NIP-50 deliberatamente non standardizza tokenizzazione, stemming, ranking, rilevamento della lingua, analisi del sentiment o classificazione dello spam. Due relay conformi possono restituire eventi e ordinamenti diversi per la stessa query. Questo rende il relay un fornitore di indici e ranking, non una fonte di verità. La specifica raccomanda di interrogare diversi relay che la supportano, di verificare se gli eventi restituiti soddisfano il caso d’uso del client e di abbandonare i relay i cui risultati hanno scarsa precisione.

Questo differisce dal filtraggio esatto di NIP-01. Un filtro authors o #t ha una semantica di corrispondenza deterministica che un client può verificare direttamente, mentre una corrispondenza di ricerca può dipendere da un indice e da un punteggio opaco. NIP-50 mantiene l’involucro firmato dell’evento e il trasporto via relay di NIP-01, ma accetta variazione nel recall e nell’ordinamento per rendere possibile il recupero aperto.

L’evento qui sotto è un risultato di ricerca illustrativo che usa i sette campi dell’evento di NIP-01. I valori esadecimali ripetuti sono segnaposto e non una firma valida.

{
 "id": "2943d6b43bcbf0ee4a8b4cac912111be0309607b8bb435ae40529989bea7f6c5",
 "pubkey": "3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d",
 "created_at": 1785771175,
 "kind": 1,
 "tags": [],
 "content": "I've been working on a customizable client (mostly relay feeds, but a ton of other things and subtle details too). It's called Hallway for reasons I don't remember and it's a fork of Fevela which is a fork of Jumble, but very rewritten for speed and simplicity...",
 "sig": "5b058b89dab9bd09d81bdc10eff95536125b87fbcbbc97f08d835c1272b2a3190cc3d340e42f54acb0d7e0e4b00355ab91292d0305c84a2d73b538319c0da12c"
}

I client attuali usano lo stesso filtro in diverse superfici di scoperta. Nostria invia ricerche NIP-50 a relay di ricerca dedicati, Ditto cerca eventi tramite il suo pool di relay, e NoorNote coordina ricerche supportate da relay per la lettura di formato lungo. Il loro diverso trattamento dei risultati riflette la libertà che NIP-50 lascia a relay e client.

Highlight (NIP-84)

NIP-84, definito dalla sua specifica principale, assegna il kind 9802 a un highlight. Trasforma un passaggio selezionato, o un riferimento a un media non testuale, in un evento firmato che può muoversi tra client di lettura, sociali e di annotazione.

Il content dell’evento contiene il testo selezionato e può essere vuoto quando la fonte è audio, video o un altro medium non testuale. Un highlight punta a una fonte Nostr con un tag a per un evento indirizzabile o un tag e per un evento ordinario; un tag r identifica un URL web. I client che producono URL dovrebbero rimuovere i parametri di tracciamento e altri parametri di query non utili prima della pubblicazione, così che varianti cosmetiche dell’URL non frammentino i riferimenti alla stessa fonte.

I tag p opzionali attribuiscono la fonte a una o più pubkey Nostr. Il loro quarto valore può identificare un ruolo come author o editor, e un tag context può conservare il testo circostante quando la selezione da sola risulterebbe poco chiara. Un highlight con citazione aggiunge un tag comment invece di pubblicare una seconda nota di kind 1: il tag r della fonte riceve il marcatore source, mentre le pubkey o gli URL menzionati nel commento portano mention, permettendo ai renderer di distinguere l’attribuzione dalla risposta dell’utente.

La definizione del kind 9802 rende un highlight un evento regolare anziché sostituibile. Ripetere o correggere una selezione crea un altro evento firmato, e rimuoverne uno si affida al normale flusso di richiesta di cancellazione e alla politica di conservazione del relay. La specifica non definisce offset di byte, selettori o uno snapshot canonico del documento, quindi un client potrebbe non riuscire a rintracciare un passaggio dopo che la sua fonte web è cambiata. Gli highlight pubblici rivelano inoltre interessi di lettura; l’annotazione privata richiede un design separato di crittografia e condivisione.

NIP-84 differisce da un evento di formato lungo NIP-23, che pubblica un intero articolo come kind 30023; un highlight cita o punta a materiale che può restare altrove. Differisce anche da un insieme di segnalibri NIP-51, che memorizza una collezione sostituibile di riferimenti. NIP-84 rende ogni selezione indipendentemente firmata, attribuibile, scopribile e discutibile.

Questo highlight illustrativo contiene i sette campi dell’evento di NIP-01. Il suo identificatore e la sua firma sono segnaposto.

{
 "id": "0d57c07cfdfe8ec00711e2af88a666b61fc35c167b90b02dfb5db7ffba7b794a",
 "pubkey": "07367baec8e73c076b14e47fba3b0d5c014d559d7986a7172a79a8a64419d7c2",
 "created_at": 1785797755,
 "kind": 9802,
 "tags": [
 ["context", "Quantum computers will break secp256k1 which nostr relies on for its public private key pair. This means that given an npub, a quantum computer will be able to derive your nsec, read all your encrypted data and sign events as you."],
 ["alt", "This is a highlight created in https://primal.net iOS application"],
 ["a", "30023:1ec454734dcbf6fe54901ce25c0c7c6bca5edd89443416761fadc321d38df139:nostr-quantum-preparation"],
 ["p", "1ec454734dcbf6fe54901ce25c0c7c6bca5edd89443416761fadc321d38df139", "", "mention"]
 ],
 "content": "Quantum computers will break secp256k1 which nostr relies on for its public private key pair. This means that given an npub, a quantum computer will b",
 "sig": "219f3c1e572d1a087d667dc0d3a5443c77c0db3a5d42ce4e630604901ac63d2c879a86269d81e220bb77fd48b1579adafc333075e53c6eb0a108791fdd4a1622"
}

Il formato attraversa già i confini tra client. nostrord 2.5.0 ha aggiunto il rendering di NIP-84 questa settimana, NoorNote renderizza gli eventi di highlight nel suo client di formato lungo, e Ditto li pubblica dal contenuto selezionato. Queste implementazioni coprono lettura, creazione e rendering sociale senza richiedere che un unico servizio possieda l’annotazione.

Invia un DM NIP-17 per condividere un progetto o una notizia tramite il progetto Nostr Compass.

Nostr Compass #33

Wed, 29 Jul 2026 00:00:00 +0000

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

Questa settimana: Amethyst 1.13.1 segue il lancio delle app Nostr nella versione 1.13.0 con l’autenticazione del relay host NIP-29 e nuovi tentativi autenticati per i download da Blossom. Code Call permette di proseguire dal telefono le sessioni di programmazione remote, GitWorkshop coordina i manutentori e la sincronizzazione dei repository, e Mosaico offre agli agenti di programmazione un livello condiviso di consapevolezza su Nostr. Nostrology mappa il modo in cui i profili dividono le funzioni di lettura e scrittura tra gli elenchi di relay pubblicati. I rilasci Android di Mafrend, Hanami e Cordn guidano i rilasci taggati, mentre FIPS aggiunge un livello di accesso OpenWrt e una PR aperta propone un port per FreeBSD. La copertura dei protocolli riferisce su NIP, BUD, NAP, Marmot, Gamma Markets, Concord e NWC, mentre Sei anni di luglio su Nostr ripercorre le modifiche di luglio, dalle prime ricerche per dominio allo stato dei gruppi basati su relay.

Storie principali

Dopo il lancio delle app Nostr, Amethyst 1.13.1 aggiunge l’accesso autenticato ai gruppi e a Blossom

Amethyst 1.13.0, rilasciata il 28 luglio per il client Nostr multipiattaforma e per Android, apre napplet e nsite NIP-5A all’interno di un processo browser isolato e privo di chiavi. Un bridge window.nostr, subordinato al consenso, può firmare e usare funzionalità selezionate tramite l’account attivo, mentre le schermate dei permessi per sito e per account consentono agli utenti di esaminare o revocare tali autorizzazioni. Le app preferite possono restare fissate nella barra inferiore senza condividere cookie, stato di accesso o autorizzazioni tra account.

Lo stesso rilascio 1.13.0 aggiunge alberi dei repository Git, issue e pull request insieme alle comunità Concord, ai gruppi basati su relay NIP-29, alla chat di gruppo Buzz, alle pagine wiki e ai feed RSS. Queste aree dell’app consentono a un utente di passare tra viste di codice, comunità, pubblicazione e social sotto la stessa identità Nostr.

Anche i pagamenti e l’identità si sono ampliati nella versione 1.13.0. Amethyst può creare e pagare offerte BOLT12, avviare automaticamente account con firmatario remoto, aggiungere server Blossom di riserva ed estendere i controlli Web of Trust per badge, comunità e gruppi basati su relay. Il seguito 1.13.1 del 29 luglio aggiunge un sigillo di scioglimento CORD-02, la cancellazione di gruppi e canali tramite kind 9008, l’autenticazione del relay host NIP-29 e nuovi tentativi BUD-01 autenticati per i download Blossom con accesso limitato.

Code Call 0.2.68 aggiunge un browser per le cartelle dei worker dopo che la 0.2.66 ha introdotto il riepilogo

Code Call 0.2.68, un’app Android per controllare da remoto le sessioni di programmazione eseguite su computer, sostituisce il proprio elenco speciale di workspace con un browser di cartelle radicato nella directory del worker. Un utente può entrare nelle cartelle annidate consentite, selezionarne una per una sessione OpenCode e tornare alle cartelle superiori; la versione 0.2.67 apre tale browser quando viene avviata una sessione.

Il precedente rilascio 0.2.66 può chiedere a un worker instradato un riepilogo conciso a partire dall’ultimo messaggio del telefono. Altri rilasci della stessa settimana mantengono indipendenti più sessioni, accettano risposte soltanto dal mittente atteso e mantengono la casella in entrata connessa a ogni relay del worker configurato per la consegna in background. Le richieste e le risposte viaggiano all’interno di NIP-17 (Messaggi diretti privati), mentre gli allegati Blossom cifrati localmente mantengono il tipo di file originale dopo la decifratura.

GitWorkshop coordina i manutentori e mantiene indipendente la sincronizzazione dei repository

Il rilascio firmato di GitWorkshop del 27 luglio aggiunge l’accesso Android tramite NIP-55 (Applicazione firmataria Android) al forge NIP-34 (git stuff) basato su browser. Il suo repository sorgente ora coordina in modo ricorsivo i manutentori principali, conserva i relay hint di ciascun manutentore e mantiene la sincronizzazione dei repository indipendente dall’accettazione degli inviti. I riferimenti tra elementi di lavoro di repository diversi collegano attività correlate tra repository, mentre GRASP copia i dati dei repository verso endpoint Git selezionati senza legare il trasferimento alla consegna degli inviti. L’aggiornamento 3.1.1, firmato dallo sviluppatore, corregge la consegna degli intent al firmatario Android, la risoluzione ricorsiva dei manutentori e i link ai repository che preservano il percorso.

Mosaico 0.1.2 consente agli agenti di programmazione di condividere lo stato su Nostr

Mosaico 0.1.2 consente alle sessioni degli agenti di programmazione in Claude Code, Codex, Goose, Hermes, OpenCode e Grok di pubblicare brevi aggiornamenti di stato tramite NIP-29 (Gruppi basati su relay). Le sessioni possono trovare attività correlate in corso su host diversi senza condividere trascrizioni o contesto.

La scoperta dei profili Codex denominati e la vista Top Of Mind di Goose mostrano tale stato condiviso all’interno di entrambi gli ambienti (PR #618, PR #619). Il rilascio ripristina la capacità degli agenti ospitati di partecipare al livello pubblico di consapevolezza, e la configurazione ora richiede una scelta esplicita del relay (PR #626, PR #629). Mosaico resta un livello di consapevolezza, non un host per agenti, un orchestratore o uno strumento per unire trascrizioni.

Nostrology mappa la concentrazione degli elenchi di relay dagli event NIP-65 pubblicati

L’osservatorio dei relay di Nostrology ricava il proprio set di dati dall’ultimo event kind 10002 NIP-65 (Metadati dell’elenco dei relay) di ciascun profilo, seguendo la specifica pubblicata. Separa i ruoli di lettura, scrittura e combinati dei relay, rappresenta quanti relay elenca ciascun profilo ed espone i conteggi sottostanti in una tabella ordinabile. Alla revisione per la pubblicazione del 29 luglio, la pagina conteneva 34.430 valori distinti di URL di relay e raggruppava 520.468 profili con un solo relay elencato, rispetto ai 150.657 con tre e ai 60.710 con quattro.

La stessa istantanea di Nostrology mostra una concentrazione sovrapposta attorno a relay.momostr.pink per 298.859 profili, relay.damus.io per 287.181, nos.lol per 279.468 e relay.primal.net per 225.336. Questi conteggi misurano le voci pubblicate negli elenchi di relay, non la disponibilità: la tabella grezza può includere URL malformati e indirizzi locali, mentre la specifica NIP-65 definisce i metadati di instradamento e non verifica lo stato dei relay. L’osservatorio rende visibili i problemi di adozione e qualità dei dati senza considerare attivo un relay soltanto perché è elencato.

Rilasci taggati

Kairos 0.1.1 aggiunge promemoria e un’istruzione locale per Astraea

Kairos 0.1.1 aggiunge promemoria per le scadenze, un’istruzione locale esplicita per Astraea e una gestione più rigorosa di relay e URL. Il rilascio firmato 0.1.0 ha introdotto il gestore di attività offline-first, il cui livello di sincronizzazione facoltativo scrive record cifrati con NIP-44 (Payload cifrati) nei relay scelti dall’utente. Kairos usa coordinate deterministiche per le attività e marcatori di eliminazione cifrati con richieste di cancellazione NIP-09 (Richiesta di cancellazione degli event), mentre le attività soltanto locali non lasciano mai il dispositivo.

Bray 2.3.0 offre alla propria CLI un gift wrapping generico e una superficie di test Blossom locale

Bray 2.3.0, un SDK Nostr e toolkit da riga di comando, può applicare e rimuovere il gift wrap a event arbitrari tramite NIP-59 (Gift Wrap), instradando la firma attraverso NIP-46 (Nostr Connect) quando la chiave è custodita da un bunker. La PR #75 aggiunge inoltre al relay di test incluso le richieste di autenticazione NIP-42 (Autenticazione dei client presso i relay) ed espone i restanti comandi del client Blossom. La PR #77 aggiunge un server BUD-01/02 in memoria la cui autorizzazione firmata lega ogni caricamento o cancellazione a un singolo blob, mentre la PR #76 aggiunge kind di event denominati, tag abbreviati e flag di riconciliazione degli ID NIP-77 che evitano di scaricare event già posseduti dal chiamante.

Buzz Desktop 0.5.0 rende più rigorosi inviti, ricerca e aggiornamenti dell’identità sui relay

Dopo la copertura della scorsa settimana sui workspace Armada e Buzz, Buzz Desktop 0.5.0 aggiunge link di invito con un numero limitato di utilizzi (PR #3141) e filtri di ricerca per autore, canale e intervalli temporali (PR #2871). La PR #2862 recupera le politiche di partecipazione tramite il livello di rete nativo dell’app desktop, e la PR #2607 ripubblica il record di identità di un agente dopo che il relay riceve il nuovo nome del profilo dell’agente. Il rilascio aggiorna inoltre la dipendenza Nostr in risposta a un avviso su un attacco denial-of-service remoto in NIP-44 e corregge il ripristino dell’archiviazione locale, il posizionamento nei thread, la riconnessione ai relay e i percorsi di runtime su Linux e Windows.

Shosho 1.0.0 amplia il proprio marketplace per le dirette streaming

Shosho 1.0.0 ridisegna il marketplace per le dirette streaming attorno a creatori, sessioni dal vivo, clip e prodotti che gli utenti possono trovare tramite una ricerca configurabile sui relay. Un feed unificato delle notifiche raccoglie ora menzioni, reazioni, repost e zap e permette di rispondere senza lasciare il feed. Gli spettatori possono pubblicare clip dalle dirette o dai replay, mentre il rilascio migliora anche la chat in thread, le risposte alle clip, il caricamento dei profili e l’uso della rete.

Mafrend v1.0 presenta in anteprima la chat Nostr basata sui luoghi su Android

Mafrend v1.0 è la prima alpha Android pubblica di una prevista app di chat Nostr basata sui luoghi. La sua pagina del progetto indica che l’insieme di funzionalità è ancora in sviluppo attivo e descrive ogni posizione sulla mappa come una chat room dedicata alle conversazioni relative a quel luogo. Un repository pubblico dei rilasci contiene il pacchetto installabile di Zapstore, mentre l’app principale rimane privata.

Hanami 0.1.0 offre ai server Blossom un percorso Android mediato da un firmatario

Hanami 0.1.0, un’app complementare Android per i server Blossom, consente alle persone di accedere, caricare e scaricare da un telefono. L’app usa NIP-55 (Applicazione firmataria Android) per la firma mediata dall’approvazione e un handshake nativo NIP-98 (Autenticazione HTTP) per la sessione con il server. Hanami limita la propria shell web e il bridge di firma all’origine del server scelto, mantenendo le credenziali presso il firmatario mentre l’interfaccia web esistente del server fornisce l’esperienza dell’applicazione. Il primo rilascio pubblico richiede Android 8 o successivo, un server Hanami raggiungibile e un’app firmataria compatibile.

Cordn lancia su Android la propria chat di gruppo con identità Nostr

Cordn, un client di messaggistica privata di gruppo, offre ora agli utenti Android l’onboarding dell’identità Nostr, link ai profili tramite NIP-05 (Mappatura delle chiavi Nostr su identificatori Internet basati su DNS) e link verificati che aprono le destinazioni Cordn nell’app. Il rilascio 0.2.1 pubblicato il 24 luglio introduce questa versione nativa accanto al client web esistente. I messaggi usano MLS, un protocollo di cifratura di gruppo, con consegna assistita da un coordinatore, così i gruppi mantengono conversazioni cifrate ordinate senza richiedere un indirizzo email o un numero di telefono.

Nostur 1.30.1 corregge i thread e i post duplicati dopo che la 1.30.0 ha ampliato la condivisione

Nostur 1.30.1, un client Nostr per iPhone, iPad e Mac, consente di navigare tra thread di risposte annidati senza gli errori di espansione e compressione che interferivano con il nuovo layout. Impedisce inoltre che la stessa bozza venga pubblicata due volte, anche quando si ripetono i callback del caricamento dei media. Il rilascio segue la 1.30.0, che ha aggiunto messaggi diretti a scomparsa e un percorso nel foglio di condivisione per inviare media a Nostr, così l’app ora abbina nuovi percorsi di messaggistica e pubblicazione alle correzioni dei flussi quotidiani dei thread e dei post.

Formstr Drive 0.0.2 abbina i metadati dei file Nostr ai blob Blossom

Formstr Drive 0.0.2, un gestore di file nativo di Nostr, offre agli utenti anteprime nell’app e l’opzione di aprire documenti da ufficio in Nostr Docs. Al livello sottostante, archivia i file di grandi dimensioni come blob Blossom suddivisi in parti e cancella il blob remoto quando un utente rimuove un file. Un relay locale mantiene a portata di mano i metadati Nostr dell’app, mentre Blossom conserva i dati dei file, separando l’organizzazione dei file dai loro contenuti voluminosi.

NoorNote 1.3.1

NoorNote 1.3.1, un client Nostr per web, desktop e Android, aggiunge timer per i messaggi a scomparsa e configura relay DM predefiniti e funzionanti per gli account appena creati. Filtra gli articoli globali privi di immagini di copertina e instrada le notifiche di repost nel lettore degli articoli. Il precedente rilascio 1.3.0 ha aggiunto schede NIP-53 (attività dal vivo), tag NIP-68 per le persone nei feed incentrati sulle immagini, un silenziamento leggero NIP-78 (dati dell’applicazione) e lo stato dei relay che hanno visto le note.

algia 0.0.133

algia 0.0.133, un client Nostr da riga di comando scritto in Go, segue la 0.0.132, che ha aggiunto elenchi, timeline, pubblicazione, reazioni, cancellazioni e flussi di ingresso e uscita per NIP-29 (Gruppi basati su relay). Lo stesso rilascio ha aggiunto la pre-autenticazione NIP-42 (Autenticazione dei client presso i relay) per i relay configurati per richiederla. La versione 0.0.133 ha poi aggiunto il caricamento di immagini locali ai comandi di pubblicazione normali, di canale e di gruppo, allegando a ogni event gli URL risultanti e i tag NIP-92 (Allegati multimediali). Funzionano anche i post contenenti soltanto immagini, e per impostazione predefinita i post di gruppo usano l’archivio multimediale del relay del gruppo, mentre gli altri post usano i file server configurati.

swift-nostr 0.7.0

Per le applicazioni Swift, swift-nostr 0.7.0, una libreria Nostr per le piattaforme Apple, consente a un solo firmatario remoto NIP-46 di gestire ogni funzionalità del client tramite la propria astrazione di firma. Il rilascio aggiunge il supporto a NIP-98 (Autenticazione HTTP) e NIP-29 (Gruppi basati su relay), compresi i flussi per partecipare ai gruppi, pubblicare e moderare. Convalida inoltre il padding di NIP-44 (Payload cifrati, con versione) rispetto ai vettori ufficiali, rifiutando i payload che contengono un MAC valido su un padding non canonico.

lawallet-nwc 2.0.0

LaWallet NWC 2.0.0, un wallet connesso a Nostr e servizio NIP-47 (Nostr Wallet Connect), aggiunge l’accesso con passkey che deriva nel browser la chiave di firma Nostr tramite l’estensione PRF di WebAuthn. Il server non riceve mai tale segreto, e la stessa passkey può recuperare la medesima chiave su un altro dispositivo sincronizzato. Gli account possono ora collegare e unire più pubkey Nostr, mentre il servizio listener facoltativo inoltra gli event di wallet-connect e ritenta la consegna dei webhook dopo che un endpoint risulta irraggiungibile.

MDK 0.9.10

MDK 0.9.10, l’implementazione Rust del protocollo Marmot, conserva gli invii in sospeso mentre un trasporto è inattivo e supervisiona l’inoltro delle notifiche dei relay, così la consegna in entrata si riprende dopo un lag, un panic o una chiusura. La PR #1159 aggiunge una cronologia delle conversazioni persistente e paginata e il contesto completo delle risposte per gli agenti locali, mentre la PR #1167 ripubblica l’event KeyPackage firmato corrente invece di generarne uno sostitutivo. Il rilascio conserva inoltre l’ordinamento manuale delle chat, supporta lo scioglimento definitivo dei gruppi ed estende la ricerca ordinata secondo Web of Trust, le API per le politiche dei relay e i binding linguistici.

pakstr 0.3.1

pakstr 0.3.1 consente ai team web che confezionano un client Nostr per Android di fornire configurazione di runtime e un proxy API senza ricostruire la shell dell’app. La sua serie di rilasci dello stesso giorno ha aggiunto un bridge per il firmatario Amber, cifratura e decifratura NIP-44 (payload cifrati) e ha corretto l’inserimento dei permessi Android prima del lavoro sulla configurazione di runtime della serie 0.3.x. Lo scaffold mantiene locali gli asset web inclusi, mentre le impostazioni specifiche della distribuzione vengono fornite in fase di esecuzione, e il proxy offre all’app confezionata un percorso controllato per le richieste API accanto alle normali connessioni ai relay.

Ditto 2.34.2

Ditto 2.34.2, un client social Nostr personalizzabile, visualizza gli stati degli utenti come schede nei feed, nelle pagine di dettaglio e nelle citazioni incorporate, includendo emoji personalizzate, scadenza e anteprime facoltative dei link. Gli zap con commenti ora appaiono come risposte sotto il post di riferimento. Il rilascio conserva anche il pulsante facoltativo a forma di globo sul profilo della versione 2.34.1 per i proprietari che pubblicano un sito radice NIP-5A (manifest del sito web) e corregge la navigazione della homepage, la ricerca delle dirette, la gestione dei link esterni e le emoji personalizzate non funzionanti.

Earthly 0.0.9

Earthly 0.0.9, un editor collaborativo di mappe costruito su Nostr, ora mantiene visibili i Mi piace quando il pannello di un’entità della mappa si chiude, si riapre o si aggiorna. Il suo flusso NIP-57 (zap Lightning) invia JSON validi per le richieste di zap, così i fornitori Lightning possono pubblicare ricevute verificate su relay raggiungibili pubblicamente, anche durante lo sviluppo locale. Le fatture generate restano visibili quando cambia la schermata dell’entità, e l’app mostra una conferma dopo l’arrivo di una ricevuta verificata.

In sviluppo

Keep aggiunge la firma NIP-44 v3 limitata per kind e rende più rigorosa la politica di approvazione

Keep ha integrato cinque modifiche al firmatario Android che trasportano le richieste di cifratura e decifratura NIP-44 (Payload cifrati) v3 attraverso entrambi i trasporti NIP-55 (Applicazione firmataria Android) e il proprio bunker NIP-46 (Nostr Connect). Le PR #451, #452 e #453 mantengono separate le autorizzazioni v3 da quelle v2, le limitano per kind di event, rifiutano kind mancanti o non validi e conservano le richieste di approvazione aperte dalle notifiche. Le PR #454 e #455 smettono di trattare come Auto la politica di firma Basic e spostano la selezione globale nell’archivio cifrato di proprietà del core. I manutentori di Keep hanno integrato tutte e cinque le modifiche dopo l’ultimo rilascio Android taggato.

Routstrd cambia il binding di rete predefinito dopo un’esposizione senza autenticazione

La PR #56 di Routstrd cambia l’indirizzo di binding predefinito del router locale di inferenza Nostr da tutte le interfacce di rete a 127.0.0.1. Il valore predefinito precedente esponeva gli endpoint senza autenticazione per saldo del wallet, cronologia, accesso, invio, rimborso, chiave API, fornitore, client, utilizzo e arresto del daemon a qualsiasi host in grado di raggiungere la porta. Gli operatori possono ancora configurare esplicitamente un binding non locale, ma la modifica integrata rende locale per impostazione predefinita una nuova distribuzione e non è ancora apparsa in un rilascio taggato.

Imwald Android chiarisce lo stato della pubblicazione offline

Imwald Android, un client Nostr per Android, ora considera la conferma da parte di un relay locale come pubblicazione completata soltanto quando tutte le destinazioni configurate sono locali. La sua correzione alla pubblicazione offline e all’outbox mantiene in sospeso la consegna remota quando un relay locale ha accettato l’event ma i relay remoti configurati non l’hanno fatto, così il rapporto di pubblicazione distingue l’archiviazione locale sul dispositivo dalla consegna ai relay.

FIPS aggiunge un livello di accesso OpenWrt; un port per FreeBSD resta in revisione

Il Free Internetworking Peering System Nostr-native ora consente a un router OpenWrt di esporre una rete di accesso !FIPS aperta tramite la PR #126 integrata. La PR #129 per FreeBSD, parallela e ancora aperta, propone di effettuare il port del daemon, del percorso dati TUN, della risoluzione dei nomi .fips, della gestione dei servizi e della compilazione del pacchetto nativo. L’integrazione per OpenWrt amplia oggi l’accesso, mentre il lavoro su FreeBSD lo estenderebbe a un altro sistema operativo generico.

Un aggiornamento del progetto FIPS del 26 luglio ha riportato più di 300 nodi sul proprio overlay UDP pubblico e una mesh più ampia vicina ai 2.000 nodi. Il repository FIPS ha dedicato la stessa settimana a irrobustire i test di rete concorrenti, la continuità del cambio delle chiavi, il comportamento del limite degli hop, i controlli del firewall e l’isolamento del laboratorio NAT. Il lavoro nel repository offre agli operatori verifiche riproducibili di tali comportamenti durante la crescita della rete.

Zap Cooking programma i post e vincola le richieste dello scanner

Zap Cooking, un’app Nostr per condividere ricette e pianificare i pasti, può ora conservare un post programmato in un archivio cifrato e pubblicarlo alla scadenza tramite un controllo periodico dei relay (PR #566, PR #569). Questo offre agli utenti un percorso di pubblicazione programmata senza lasciare esposto il contenuto non firmato del post nel database dello scheduler.

Il suo scanner del frigorifero ora autentica il corpo esatto della richiesta con l’autenticazione HTTP NIP-98, così le verifiche dell’adesione si basano sulla chiave che ha firmato la richiesta di scansione invece che su una pubkey fornita nel suo corpo (PR #599).

Citrine trasforma un dispositivo Android in un relay gestibile

Citrine, un relay Nostr ospitato su Android, ora può inviare a relay esterni gli event che ha archiviato, offrendo a un operatore un modo per ritrasmettere la cronologia locale (PR #179). Aggiunge inoltre comandi NIP-86 (API di gestione dei relay) affinché i client compatibili possano amministrare il relay (PR #150).

Gli operatori dei gruppi possono amministrare i gruppi basati su relay NIP-29 tramite la firma Amber nella PR #178, mentre la PR #174 mantiene allineati tra i riavvii la configurazione dei relay basati su Tor e lo stato del ciclo di vita.

Wired recupera conversazioni complete nel browser

Wired, un client Nostr basato su browser, ora segue le radici dei feed, le risposte e gli event citati fino a ricostruirli integralmente, invece di fermarsi a limiti fissi di ampiezza o di risultati (PR #148, PR #147, PR #146). Gli utenti possono quindi recuperare thread più profondi e il contesto del feed quando gli event pertinenti sono disponibili sui propri relay.

Il browser conserva anche i relay hint sugli event citati e li usa soltanto per il contesto ancora mancante, ripristinando conversazioni che i relay configurati non contengono (PR #145, PR #144). Il recupero incompleto resta distinto da un’istantanea completata, così una risposta parziale non sovrascrive la vista precedentemente memorizzata nella cache.

Lavoro su protocolli e specifiche

NIP: limiti dell’hosting NIP-34, migrazione dei gruppi e tre bozze attive

Questa settimana sono state integrate due modifiche alle specifiche. Il commit NIP-34 6d2979b rimuove le istruzioni di hosting GRASP dalla descrizione della pull request kind:1618, lasciando l’hosting e il comportamento di riserva fuori dal contratto dell’event. Il commit NIP-29 db5fe3d definisce come i metadati di un gruppo basato su relay migrano verso un altro relay e come i client distinguono uno spostamento valido da un fork che prosegue in modo indipendente.

La PR #2424 propone dichiarazioni reciproche dei set di chiavi kind:10045. Il requisito di reciprocità impedirebbe a un’identità di associare unilateralmente un’altra chiave. La PR #2421 propone intenti di zap BOLT12 e prove del pagatore che i client possono convalidare rispetto al destinatario, all’importo, all’offerta e al pagamento regolato senza dipendere da un server di ricevute gestito dal destinatario.

La PR #2425 consentirebbe ai segnalibri NIP-B0 di conservare schemi non HTTP come nostr: insieme agli URL web. Questo manterrebbe intatti gli identificatori Nostr nativi, le richieste di pagamento e altri schemi applicativi negli stessi elenchi di segnalibri privati o pubblici che contengono già indirizzi web.

Mill implementa una bozza per il backup delle chiavi tramite account cloud

Mill ha annunciato di aver implementato una bozza per il backup delle chiavi tramite account cloud che combina l’identificatore di un account Google OIDC con una passphrase ad alta entropia per derivare una chiave di backup usa e getta. La sua implementazione di riferimento cifra la chiave reale dell’utente come ncryptsec NIP-49 (Cifratura della chiave privata), poi la archivia in un event kind 30049 provvisorio, parametrizzato e sostituibile, sui relay configurati. Il progetto ha integrato il flusso di backup nel branch main, ma nessun rilascio successivo alla v1.0.0 lo include e il flusso di backup resta disabilitato a meno che un operatore non fornisca backupRelays dedicati. Un insieme di relay con versione resta provvisorio, e la bozza avverte che il testo cifrato pubblicato rimane disponibile per tentativi offline di indovinare la passphrase. I lettori dovrebbero considerare il progetto un esperimento implementato che dipende da una passphrase ad alta entropia.

BUD: i server Blossom possono identificare dai byte i caricamenti di tipo sconosciuto

La PR BUD-02 #110 propone di raccomandare il rilevamento lato server del tipo MIME quando chi carica omette Content-Type o invia application/octet-stream. Un server Blossom esaminerebbe i primi byte con una libreria aggiornata per i tipi di file, conserverebbe un tipo specifico fornito dal client e userebbe il tipo binario generico quando il rilevamento non riesce. Ciò manterrebbe visualizzabili immagini, audio, video e file prodotti dagli agenti senza rendere obbligatorio l’esame dei byte per ogni caricamento.

NAP: le convenzioni sostituiscono i percorsi numerati mentre si sviluppano i contratti di acquisizione e filesystem

La PR #87 rimuove il percorso numerato del protocollo tra napplet e mantiene le funzionalità di runtime sotto contratti denominati, mentre i messaggi delle applicazioni convergono verso URI di convenzione napplet:<archetype>/<intent>. La modifica all’identità degli argomenti integrata separa un percorso di convenzione stabile e privo di query dai dati del payload di ciascun messaggio, e la PR #90 applica tale regola di trasposizione ai metadati di scoperta e dei gestori.

Due bozze NAP estendono il confine della shell attendibile. La PR NAP-CAPTURE #94 mantiene nel runtime il consenso per il microfono, i permessi della piattaforma, i limiti, la conservazione e lo smantellamento, restituendo al contempo a una napplet in sandbox un artefatto multimediale soggetto a limiti definiti. La PR NAP-FS #88 è la proposta parallela per un filesystem virtuale, con handle vincolati dalle politiche invece di percorsi host senza restrizioni.

Marmot: la specifica definisce uno stato terminale del gruppo

La PR Marmot #409 aggiunge uno stato Disbanded autenticato e irreversibile perché MLS non dispone di un’operazione per cancellare i gruppi. Un commit autorizzato dell’amministratore sposta un gruppo fuori da Active, impedisce a vecchi branch, messaggi e Welcome di riattivarlo e offre ai gruppi esistenti un percorso esplicito di compatibilità prima dello scioglimento. La precedente revisione delle issue della specifica ha inoltre riconciliato l’autorità sullo stato dei gruppi, la convergenza, i pacchetti di chiavi, le conferme, le regole sui media, il linguaggio del registro e 200 issue tracciate della specifica.

Gamma Markets: nessuna modifica pubblica alle specifiche è stata integrata

Il repository delle specifiche di Gamma Markets non ha registrato commit pubblici né attività di pull request dal 21 al 28 luglio. I documenti pubblicati su ordini, regolamento e dati di mercato restano il riferimento corrente; questa voce senza modifiche mantiene Gamma visibile nella revisione settimanale delle specifiche.

Concord: le funzionalità di lettura e scrittura possono separarsi all’interno di un singolo piano

La PR Concord #12 resta una bozza aperta per i piani in cui non tutti i lettori dovrebbero poter scrivere. Sposta il Control Plane verso funzionalità separate per i flussi di lettura e scrittura e abbozza canali a scrittura limitata, inviti e ambiti di ricambio delle chiavi. Nella bozza la chiave di scrittura funge da filtro antispam, mentre gli attori interni firmati e i controlli dell’elenco dei membri continuano a conferire l’autorità.

NWC: un metodo del wallet può scegliere tra BOLT11 e BOLT12

La PR NWC #2 propone i metodi facoltativi pay e receive per gli URI di pagamento BIP-321. Un servizio wallet può dichiarare il supporto, scegliere da un URI una fattura BOLT11 o un’offerta BOLT12 compatibile, rifiutare prima del pagamento una rete Bitcoin non corrispondente e indicare quale tipo di istruzione ha usato. La proposta resta al di fuori del core NWC, così i wallet privi di supporto BIP-321 o BOLT12 non devono implementarla.

Sei anni di luglio su Nostr

Questa storia di luglio segue problemi ricorrenti di Nostr: identificatori leggibili, filtraggio dei relay, dati applicativi portabili, privacy e interoperabilità. Nel corso di sei anni, ogni livello trasforma una correzione circoscritta in infrastruttura condivisa: i nomi diventano profili, i filtri diventano contratti applicativi e lo stato trasportato dai relay si estende dalle note alle stanze live e ai gruppi. Inizia con la prima implementazione di NIP-05 e termina con l’integrazione di questo mese per la scoperta indirizzabile, quindi esamina le modifiche di luglio che hanno sviluppato questi temi.

Luglio 2021

Il 19 luglio 2021, il commit 1ce00bd di nostr-tools ha aggiunto un modulo nip05.js e portato il pacchetto alla versione 0.5.0. La sua funzione keyFromDomain costruiva una richiesta DNS TXT per _nostrkey.<domain>, inviava la query binaria a uno degli otto fornitori DNS-over-HTTPS a rotazione e restituiva la prima chiave nella risposta. Un client browser poteva quindi tradurre un dominio controllato da una persona in una chiave pubblica senza gestire un resolver DNS né dipendere da un unico fornitore predefinito nel codice.

Quel primo approccio risolveva la ricerca ma non i nomi all’interno di un dominio, e il suo confine di fiducia risiedeva nel DNS e nel resolver scelto. La moderna specifica NIP-05 ha spostato la scoperta su /.well-known/nostr.json, dove un dominio associa nomi locali a pubkey e può allegare relay hint. Il codice del 2021 registra la precedente pressione progettuale: le chiavi pubbliche erano portabili, ma le persone avevano ancora bisogno di identificatori che potessero leggere, verificare e trasferire tra client.

Luglio 2022

Il 10 luglio, il commit NIP-12 3771186 ha limitato le query generiche dei relay ai tag di una sola lettera. Tale decisione ha reso filtri come #r, #g e #t utili per riferimenti URL, geohash e hashtag senza chiedere ai relay di indicizzare ogni chiave arbitraria dei metadati. Dieci giorni dopo, la prima bozza NIP-20 per i commenti web ha usato direttamente quel modello di query: un commento kind 34 conteneva l’URL normalizzato di una pagina web in un tag r, permettendo a un sito e a client indipendenti di recuperare la stessa discussione dai relay.

Sono seguite le politiche dei relay e il feedback sociale. Il commit NIP-22 originale consentiva ai relay di rifiutare event il cui timestamp created_at fosse inverosimilmente vecchio, e il commit 8bef0e9 ha aggiunto alla stessa politica i timestamp futuri. Il 30 luglio, il commit NIP-25 dcbd504 ha definito reazioni kind 7 con tag di destinazione e e p; il commit successivo ha assegnato - a una reazione negativa, e il commit 6903ff5 ha reso + il Mi piace generico esplicito. Insieme, questi commit hanno specificato il rifiuto dei timestamp da parte dei relay, il recupero basato su tag, i commenti web e i tag di reazione per i client che hanno adottato le bozze.

Luglio 2023

Il luglio 2023 ha esteso il coordinamento oltre le note brevi. La bozza NIP-37 sulle chiavi perdute ha esplorato il ritiro irreversibile delle chiavi, soglie di recupero sociale e chiavi sostitutive vincolate in anticipo, rifiutando esplicitamente di definire il risultato come rotazione universale delle chiavi. Cinque giorni dopo, NIP-53 ha introdotto attività dal vivo indirizzabili di kind 30311 e messaggi di chat kind 1311, offrendo a streaming, palchi e stanze dal vivo un modello di event condiviso per host, partecipanti, stato e conversazione.

Anche le applicazioni hanno iniziato a pubblicare richieste di lavoro e offerte commerciali. La prima bozza Data Vending Machine descriveva richieste di lavoro kind 68001, risultati kind 68002, offerte, scadenze, concatenamento e fornitori concorrenti per attività quali trascrizione, sintesi e traduzione. Il 13 luglio, la bozza per gli annunci classificati ha aggiunto offerte indirizzabili kind 30402 con metadati per titolo, riepilogo, prezzo, posizione e stato. Tali bozze sono poi diventate NIP-90 e NIP-99, ma già nelle forme di luglio separavano una richiesta o un annuncio dal server che li visualizzava.

Anche l’instradamento dei pagamenti è diventato componibile. L’integrazione NIP-57 per la suddivisione degli zap del 31 luglio ha trasformato una singola destinazione zap in un elenco ponderato di pubkey dei destinatari e relay hint. Un client poteva dividere uno zap tra collaboratori, omettere i destinatari privi di peso quando erano presenti alcuni pesi e mostrare la suddivisione prima del pagamento. La modifica ha standardizzato una rappresentazione mediante event firmato per i destinatari ponderati degli zap e i relay hint, consentendo ai client compatibili di presentare la suddivisione prima del pagamento.

Luglio 2024

Il 4 luglio, il commit NIP-29 c60ca88 ha aggiunto l’azione di moderazione dei relay kind:9007 per creare un gruppo. Sei giorni dopo, NIP-70 ha definito gli event protetti: un tag - indica a un relay di accettare la pubblicazione soltanto dall’autore autenticato dell’event. Una modifica ha fornito ai relay una transizione esplicita dello stato dei gruppi; l’altra ha consentito agli autori di impedire a terze parti di ripubblicare sui relay event firmati altrimenti validi.

Il 16 luglio, un commit della specifica Cashu ha introdotto sia i wallet NIP-60 sia i nutzap NIP-61. NIP-60 collocava i metadati del wallet in kind 37375, le prove non spese in event cifrati kind 7375 e la cronologia facoltativa delle transazioni in kind 7376. NIP-61 abbinava le preferenze del destinatario per mint e relay in kind 10019 ai nutzap kind 7337 bloccati con P2PK. Lo stato del wallet e i bearer token potevano ora muoversi attraverso i relay, mentre il riscatto dipendeva ancora dalle prove del mint Cashu e da un’attenta prevenzione del doppio utilizzo delle stesse prove.

Due modifiche di fine luglio hanno reso più rigoroso lo stato deterministico. Il commit NIP-01 9c54549 ha imposto gli ID degli event come criterio di spareggio dopo timestamp created_at uguali, così i client potevano ordinare allo stesso modo insiemi di risultati identici. L’integrazione NIP-09 sulla cancellazione ha chiarito che le richieste kind 5 possono riferirsi a ID di event o coordinate indirizzabili e dovrebbero includere tag k che identificano i kind che i relay devono cancellare. Entrambe le modifiche hanno ridotto i casi in cui due implementazioni corrette potevano altrimenti divergere.

Luglio 2025

Il 16 luglio, la scoperta di ecash ha ottenuto una propria directory sociale. Il commit NIP-87 1afb6da ha definito record di mint Cashu kind 38172, record Fedimint kind 38173 e raccomandazioni kind 38000 che possono indicare tali record con relay hint. I wallet potevano interrogare le raccomandazioni di autori fidati prima di connettersi a un mint, mentre la specifica avvertiva che una scoperta globale non filtrata poteva indirizzare gli utenti verso operatori malevoli.

Una settimana dopo, una bozza ha specificato record portabili di event Nostr per i messaggi vocali. Il primo commit NIP-A0 ha assegnato kind 1222 all’event radice di un messaggio vocale e kind 1244 a una risposta, con un URL audio e metadati multimediali. Il seguito sul formato del 27 luglio ha raccomandato Opus in un contenitore Ogg e standardizzato una forma d’onda compressa. I client potevano scambiarsi audio brevi senza concordare un unico registratore, host o rappresentazione della forma d’onda.

La messaggistica privata e le connessioni ai wallet hanno poi aggiunto stato di protocollo per il tracciamento della lettura, la selezione della cifratura e l’avanzamento dei pagamenti. Il commit NIP-17 3d76da3 ha definito un record kind 30016 sostituibile, i cui tag seen ordinati consentivano a un client di distinguere i messaggi letti dalle lacune dovute a messaggi che poteva non aver ricevuto. Il 31 luglio, la negoziazione della cifratura NIP-47 ha permesso ai servizi wallet di dichiarare NIP-44 v2 o il protocollo NIP-04 legacy, mentre il commit sullo stato delle transazioni ha aggiunto gli stati pending, settled, accepted, expired e failed. La consegna, la cifratura e l’avanzamento dei pagamenti sono diventati dati di protocollo espliciti invece di inferenze locali.

Luglio 2026

Questo luglio è iniziato collegando normali indirizzi web alle query dei relay. Il commit 2f4b093 sulla scoperta indirizzabile definisce una ricerca /.well-known/nostr.json?ad=<path> la cui risposta contiene un filtro Nostr e un elenco di relay. Un browser normale può ancora aprire l’URL originale come HTML, mentre un client Nostr può interrogare l’endpoint /.well-known/nostr.json?ad=<path> corrispondente per ottenere un filtro e un elenco di relay che risolvono l’indirizzo in un gruppo, nsite, feed, event o altro oggetto nativo. Il modello riprende il problema del 2021 relativo alla conversione da dominio a chiave a un livello più ampio: un URL leggibile può ora indicare sia un’identità sia una query.

NIP-29 è poi cresciuto da gruppi piatti basati su relay a spazi strutturati. Il commit sui sottogruppi del 16 luglio ha aggiunto relazioni tra genitore e figli ordinati; i commit adiacenti hanno aggiunto suffissi ai codici d’invito, banner, istantanee ordinate dei pin e pin di event indirizzabili. Il 22 luglio, il chiarimento su migrazione e fork ha definito quando i metadati spostano legittimamente un gruppo verso un altro relay e quando un branch ancora attivo costituisce un fork indipendente. L’identificatore del gruppo è rimasto semplice, mentre gerarchia, presentazione e modifiche dei relay sono diventati stato esplicito.

Due modifiche minori hanno chiarito i confini delle implementazioni. Il commit NIP-46 f0af204 richiede a un firmatario remoto di restituire un errore per metodi sconosciuti o non supportati invece di lasciare che un client raggiunga silenziosamente il timeout. Il commit NIP-34 6d2979b rimuove dalla descrizione dell’event di pull request le indicazioni di hosting specifiche per GRASP. Una modifica offre ai chiamanti una risposta conclusiva; l’altra impedisce a un event git portabile di ereditare silenziosamente un protocollo server.

Invia un DM NIP-17 per condividere un progetto o una notizia tramite il progetto Nostr Compass.

Nostr Compass #32

Wed, 22 Jul 2026 00:00:00 +0000

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

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

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

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

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

Storie principali

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

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

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

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

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

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

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

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

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

Rilasci taggati

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

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

Seguito di Nostrord v2.2.0

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

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

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

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

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

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

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

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

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

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

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

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

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

I lanci minori della settimana

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

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

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

Modifiche non rilasciate

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

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

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

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

Mostr collega le chat private ActivityPub ai DM Nostr

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

nostream integra otto PR senza taggare un rilascio

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

FIPS v0.4.1 rafforza il livello di trasporto di Iris

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

Lavoro sul protocollo e aggiornamenti dei NIP

Modifiche recenti al repository dei NIP:

Integrati:

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

PR aperti e discussioni:

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

NIP Deep Dive: NIP-42 e NIP-43

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

NIP-42: Autenticazione dei client verso i relay

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

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

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

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

NIP-43: Metadati e richieste di accesso ai relay

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

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

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

Storia

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

Implementazioni

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

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

Nostr Compass #31

Wed, 15 Jul 2026 00:00:00 +0000

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

Questa settimana: Vector v0.4.0 ritira Marmot come trasporto predefinito per le Chat di Gruppo a favore di Concord, un protocollo di comunità aperto con licenza MIT usato anche da Armada di Soapbox, e rilascia Concord v2 quattro giorni dopo con un selettore di comandi con barra per i bot, un timer di autodistruzione e badge NIP-58. Amethyst integra la propria implementazione pulita e compatibile a livello di protocollo di Concord, la stessa settimana. Sonar si separa da Bitchat con un’alpha multipiattaforma ed è la fonte di specifica citata per la proposta di kind per pacchetti di sticker di questa settimana. Divine Mobile 1.0.16 introduce un editor video più completo, la cifratura a riposo e la provenienza ProofMode che sopravvive al download di clip con filigrana. Bitchat v1.7.0 aggiunge la voce push-to-talk dal vivo per i DM e il push-to-talk firmato sulla mesh pubblica. MDK v0.9.4 limita il login con firmatario esterno e aggiunge la persistenza delle bozze, proseguendo il suo lavoro di irrobustimento la stessa settimana in cui Vector si allontana dalla specifica per la chat di gruppo.

I rilasci taggati portano n_cord v1.1 con il supporto per NSEC Bunker, cdk v0.17.3 con il supporto per il servizio di wallet NIP-47 su cdk, cdk-nwc e cdk-ffi, Coop Mobile v0.2.4 con miglioramenti a Nostr Connect e l’importazione ncryptsec1, Nmail v0.14.0 che arriva su macOS con l’invio programmato, Nostrord v2.2.0 con un interruttore generale per i DM, Nostr WoT 0.3.86 che irrobustisce i backup delle chiavi al formato NIP-49, Keep Android v1.1.8 con l’onboarding FROST al primo avvio, Noscall v0.6.0 con un wallet Cashu e notifiche push basate su relay, Kubo con la modalità tablet e le foto nelle chat di gruppo, e Nostr Codex Phone v0.2.9 con richieste ausiliarie per git, diff e lettura di file.

Sul fronte non rilasciato, Amethyst consente agli account di assegnare soprannomi ai contatti con schede NIP-85 cifrate attraverso 54 PR integrate, Zap Cooking rilascia la Fase 3 di My Kitchen e corregge un bug di quorum del pool NDK, Kehto trasmette le letture di outbox prima che finisca la scoperta dei relay, Wired e TAO aggiungono la condivisione dei ricavi per i creatori con NIP-57, Conduit Mono ricostruisce la casella degli ordini del commerciante attorno al checkout come ospite effimero, Buzz irrobustisce il provisioning del creatore di canale attraverso 240 PR integrate, e Nostr Docs adotta un firmatario NIP-49 con account multipli e accoppiamento QR. Tracciati per la prima volta questa settimana: OpenDiscord v1.0.1, Auditable Voting v0.1.140, e la scelta Discovery Cambium v0.3.2, un firmatario NIP-55 senza chiavi che fa da proxy verso un dispositivo hardware Heartwood.

Il repository dei NIP non integra nulla nell’ultima settimana e apre sei proposte: kind:10011 set di follow preferiti, un’unità cifrata privata che estende NIP-4E, NIP-DA condivisione privata di dati con permessi, kind per pacchetti di sticker 10031 e 30031, fissaggio dei messaggi NIP-29, e una ristrutturazione della scoperta di relay NIP-66. Il Deep Dive copre NIP-99 e l’estensione di commercio Gamma Markets.

Storie principali

Vector v0.4.0 sposta le Chat di Gruppo da Marmot a Concord, e Amethyst rilascia il proprio client Concord pochi giorni dopo

Vector è un messenger Nostr costruito attorno a un client a binario singolo, orientato alla privacy, per DM e chat di gruppo. Vector v0.4.0 riscrive il motore di messaggistica dell’app in una libreria condivisa vector-core e, nello stesso rilascio, ritira Marmot (MLS-su-Nostr) come trasporto predefinito per le Chat di Gruppo a favore di Concord, un protocollo di comunità cifrato end-to-end; la cronologia esistente dei gruppi Marmot non viene trasferita, e le note di rilascio indicano agli utenti di fare il backup di qualsiasi dato dei gruppi Marmot prima di aggiornare. Le note di rilascio di Vector descrivono Concord come “il nostro protocollo di messaggistica personalizzato”, ma le specifiche da CORD-01 a CORD-07 sottostanti sono pubblicate separatamente, con licenza MIT, e già implementate al di fuori di Vector: il client in stile Discord di Soapbox, Armada, costruisce la sua funzionalità Communities sulla stessa specifica Concord, e un giorno dopo Amethyst ha integrato la propria implementazione pulita e compatibile a livello di protocollo di Concord, trattata in dettaglio più sotto. Lo stesso rilascio di Vector aggiunge il routing Tor opzionale per tutto il traffico, il login con firmatario remoto NIP-46 tramite QR o URI bunker incollata, account multipli con un commutatore interno all’app, e pacchetti di emoji personalizzati condivisi tra i client. L’eliminazione di un messaggio lo rimuove per entrambe le parti nei DM e nelle chat di gruppo, e Vector mantiene deliberatamente la chiave di firma effimera invece di seguire il flusso di eliminazione standard NIP-17, una deviazione motivata dalla privacy che il progetto segnala esplicitamente nelle note di rilascio. Quattro giorni dopo, v0.4.1 rilascia Concord v2, descritto come portatore di importanti miglioramenti di privacy e stabilità alle Communities mantenendo funzionanti quelle esistenti, insieme a un selettore di comandi con barra in stile Discord per i bot con parametri tipizzati, un timer di autodistruzione per chat, e un sistema di badge NIP-58 per i cacciatori di bug. L’allontanamento da Marmot per la chat di gruppo arriva la stessa settimana in cui MDK v0.9.4 più sotto continua a investire nella specifica.

Amethyst rilascia un’implementazione pulita di Concord per comunità cifrate end-to-end

Amethyst è un client Nostr ricco di funzionalità per Android e multipiattaforma. PR #3566 aggiunge un’implementazione completa di Concord (da CORD-01 a CORD-07) che copre comunità serverless e cifrate end-to-end: piani di controllo, chat e guestbook avvolti con gift-wrap su relay ordinari, applicazione di ruoli e ban radicata nel proprietario che ogni client verifica localmente invece di fidarsi di un server, e re-keying per tagliare fuori i membri rimossi. Il codice di protocollo e crittografia risiede in quartz/, i modelli di stato e vista in commons/, e le schermate e la navigazione in amethyst/ per Android, con verbi CLI leggeri sotto cli/; non c’è ancora un’interfaccia desktop, poiché la logica condivisa risiede in quartz/commons perché Desktop la adotti in seguito. L’implementazione è pulita: costruita dalle specifiche CORD pubbliche e dalle costanti di protocollo osservate, sotto la licenza MIT di Amethyst, distinta dal codice AGPL-3.0 di Armada. I valori dei vettori di test di Armada sono stati portati nei test unitari di Quartz per confermare che i due client interoperano realmente a livello di protocollo, dando a Concord tre implementazioni indipendenti nel giro di pochi giorni: Vector che rilascia per primo, Armada come client di riferimento di Soapbox, e ora la build da specifica di Amethyst.

Sonar si separa da Bitchat con un’alpha multipiattaforma e una specifica per pacchetti di sticker

Sonar è un messenger e wallet con mesh Bluetooth più Nostr nato da Bitchat, con DM di gruppo Marmot interoperabili con White Noise. Il codice risiede in hedwig-corp/bitchat-to-sonar. v0.1-alpha.7 aggiunge una finestratura limitata delle trascrizioni in stile Signal affinché le prestazioni di apertura e scorrimento restino local-first, sincronizza lo stato di scoperta dei peer vicini, e corregge i caricamenti di media Blossom che fallivano nella gestione del content-type e dello stato HTTP; la precedente alpha.6 drenava gli eventi Marmot dal vivo per un aggiornamento più rapido della chat e chiudeva le lacune di parità di funzionalità tra Android e iOS su chiamate, messaggistica, wallet e push. Sonar è anche la fonte di specifica citata per PR #2410, che registra i kind di evento per pacchetti di sticker sotto la specifica “Sonar Stickers” del progetto, dando a questo lancio un collegamento diretto al lavoro di protocollo di questa settimana.

Divine Mobile 1.0.16 introduce un editor video più completo, la cifratura a riposo e la provenienza ProofMode

Divine è un client di video brevi costruito su Nostr con curazione del feed tramite Web-of-Trust. v1.0.16, il primo rilascio taggato dal #30, aggiunge transizioni tra clip, riproduzione inversa, un registratore di voice-over e marcatori di ritmo sulla timeline all’editor video, insieme a un controllo di regolazione del feed che consente all’utente di scorrere per aggiustare le raccomandazioni direttamente invece di lasciarle a segnali di interazione opachi. Il rilascio attiva anche la cifratura a riposo per i dati locali, aggiunge caricamenti in background che sopravvivono alla sospensione dell’app, e trasporta i dati di provenienza ProofMode quando si scarica una clip con filigrana affinché l’attestazione di creazione umana non venga rimossa durante il transito. Divine include anche nuove protezioni per gli account di minori di 16 anni ed estende la localizzazione a 17 lingue e 284 stringhe tradotte.

Bitchat v1.7.0 aggiunge la voce push-to-talk dal vivo per i DM e la mesh pubblica

Bitchat è un’app di chat con mesh Bluetooth con un gateway opzionale verso i relay Nostr. v1.7.0, rilasciata la sera in cui è stato pubblicato il #30, aggiunge la voce push-to-talk dal vivo in PR #1403 che trasmette l’audio mentre il mittente tiene premuto il pulsante e ripiega su una nota vocale se il flusso si interrompe, più il push-to-talk firmato sulla mesh pubblica in PR #1406 affinché le raffiche di voce dal vivo sul canale mesh condiviso portino l’autenticazione del mittente. Il rilascio ripara anche la rotazione del peer-ID riagganciando il collegamento su un ri-annuncio verificato, riconoscendo lo stesso peer sotto il suo nuovo ID (PR #1401), e i messaggi diretti a un peer attualmente irraggiungibile ora vengono messi in coda con consegna store-and-forward invece di fallire subito (PR #1415). Questo prosegue direttamente dalla copertura del #30 sul lavoro di proof-of-work NIP-13 e sul gateway mesh-verso-Nostr della v1.6.0.

MDK è l’SDK di riferimento per il protocollo Marmot, il livello di messaggistica MLS-su-Nostr che il #30 ha trattato segnalandone l’adozione della specifica. v0.9.4 limita i passaggi di directory consultiva che un client percorre durante il login con firmatario esterno in PR #793, prevenendo un ciclo di tentativi illimitato quando un firmatario remoto è lento o non risponde. Lo stesso rilascio aggiunge la persistenza delle bozze di messaggio e i collegamenti profilo-sito web in PR #812, proseguendo il lavoro di irrobustimento incrementale che MDK porta avanti da quando ha rilasciato la v0.9.0.

Rilasci taggati

n_cord v1.1 aggiunge il supporto per NSEC Bunker

n_cord è un client di chat basato su Nostr ispirato a Discord e IRC. v1.1 aggiunge il supporto per NSEC Bunker NIP-46 insieme a una correzione di un bug nella gestione delle risposte.

cdk v0.17.3 aggiunge il supporto per il servizio di wallet NIP-47 su cdk, cdk-nwc e cdk-ffi

cdk è un development kit per Cashu; questo rilascio è per la maggior parte solo Bitcoin/Lightning, ma v0.17.3 aggiunge il supporto per il servizio NIP-47 (Nostr Wallet Connect) con un crate di servizio NWC dedicato, l’integrazione con il wallet, i binding FFI per cdk-ffi, e una copertura di test end-to-end, dando ai wallet Cashu costruiti su cdk una superficie Nostr Wallet Connect standard.

Coop Mobile v0.2.4 migliora Nostr Connect e aggiunge l’importazione ncryptsec1

Coop Mobile è un client di messaggistica privata NIP-17 per piattaforme mobili. v0.2.4 migliora il suo flusso NIP-46 Nostr Connect, corregge un indicatore di caricamento che rimaneva bloccato in modo permanente su alcune connessioni, e aggiunge il supporto all’importazione del formato di chiave cifrata NIP-49 ncryptsec1 insieme a una schermata di importazione dell’identità ridisegnata.

Nmail v0.14.0 arriva su macOS con invio programmato e notifiche push

Nmail è un client di posta costruito su Nostr; v0.14.0 porta l’app su macOS, aggiunge l’invio programmato con una casella Programmati dedicata per i messaggi in coda, e aggiunge le notifiche push. Il rilascio passa anche la risoluzione degli identificatori Nostr della rubrica al resolver NIP-05 di NDK al posto di un’implementazione su misura.

Nostrord v2.2.0 aggiunge un interruttore generale per i DM e messaggi diretti più ricchi

Nostrord è un client di chat di gruppo basato su relay NIP-29 per Android, iOS, web e desktop. v2.2.0 aggiunge un interruttore generale per disabilitare tutte le funzionalità di messaggistica diretta in una volta (PR #175) e rilascia “messaggi diretti più ricchi” (PR #186), proseguendo dalla copertura del #30 sul rilascio che consolidava il pool di relay e rilevava i WebSocket zombie.

Nostr WoT 0.3.86 irrobustisce i backup delle chiavi e le richieste di firma

Nostr WoT è un’estensione per browser che abbina un’identità Nostr a un wallet Lightning. v0.3.86 sposta i backup delle chiavi cifrate al formato standard NIP-49, fa sì che le richieste di firma mostrino l’evento completo e tutti i tag invece di un riepilogo, verifica i dati del relay rispetto alla loro firma, e smette di esporre l’identità attiva al cambio di account. L’estensione elimina anche il permesso scripting del browser inutilizzato.

Keep Android v1.1.8 aggiunge l’onboarding FROST al primo avvio

Keep è un firmatario Android costruito su frammenti di chiave a soglia FROST. v1.1.8 aggiunge un flusso al primo avvio che spiega i frammenti di chiave FROST e consente a un nuovo utente di scegliere una politica di firma tra Manuale, Base o Automatica prima che arrivi la prima richiesta di firma, il primo onboarding lato Android per il modello di firma a soglia del crate keep-mobile sottostante.

Noscall v0.6.0 aggiunge un wallet Cashu e notifiche push basate su relay

Noscall è un’app per chiamate audio e video sicure costruita su Nostr. v0.6.0 aggiunge un wallet Cashu con ambito account con saldi multi-mint, invio e ricezione di ecash, e pagamento e ricezione Lightning con persistenza delle quote. Il rilascio migra anche le notifiche push di Android da Firebase Cloud Messaging a un percorso di consegna basato su relay Nostr tramite UnifiedPush, e migliora l’affidabilità del VoIP di iOS e del push APNs durante i nuovi tentativi di login.

Kubo rilascia la modalità tablet e le foto nelle chat di gruppo

Kubo è una piattaforma video Nostr sicura per bambini con curazione del feed tramite Web-of-Trust. kubo-v2026.07.05 aggiunge un layout a griglia per tablet opzionale per il feed dei bambini e il supporto all’allegato di foto ai messaggi delle chat di gruppo, oltre a correzioni per il pulsante di registrazione che si nascondeva dietro la tastiera a schermo su Android.

Nostr Codex Phone v0.2.9 aggiunge richieste ausiliarie per git/diff/lettura di file

Nostr Codex Phone è una superficie di controllo mobile per un worker locale di assistenza alla programmazione che comunica tramite DM Nostr cifrati. v0.2.9 aggiunge azioni di strumenti OpenCode mobili, incluse richieste ausiliarie per git, diff, lettura di file, stato e cronologia, miglioramenti al fissaggio e alla ricerca delle sessioni, e un controllo di arresto delle attività, insieme a un wrapper di caricamento cifrato su Blossom che è stato rilasciato nella precedente v0.2.8.

GitWorkshop v3.0.3 corregge i ref appena annunciati nell’esploratore di repository, e rilascia la sua prima build Android

GitWorkshop è un’interfaccia web git-su-Nostr per esplorare e revisionare repository NIP-34. v3.0.3 corregge le viste di rami, tag, commit ed esplorazione del codice che non riuscivano a risolvere un ref annunciato da un repository dopo che l’esploratore lo aveva già caricato, insieme alla pulizia dei tempi del flusso CI, confermato direttamente rispetto al tag e alla cronologia dei commit. La stessa settimana, GitWorkshop ha pubblicato la sua prima build Android nativa su Zapstore, partendo dalla v3.0.0 e raggiungendo la v3.0.3 nel giro di ore; l’interfaccia web rimane l’interfaccia principale, e il pacchetto Android porta per la prima volta su un telefono la stessa esplorazione di repository NIP-34.

Bitcoin-Safe arriva su Flathub, mettendo in luce il suo plugin Nostr Sync & Chat

Bitcoin-Safe è un wallet Bitcoin ad autocustodia costruito attorno ai flussi di lavoro con firmatari hardware. Il progetto ha pubblicato un pacchetto su Flathub questa settimana, il suo primo inserimento in uno store di applicazioni Linux mainstream. Il rilascio su Flathub mette il plugin Sync & Chat di Bitcoin-Safe davanti a un pubblico più ampio: il plugin usa i messaggi diretti NIP-17, tramite la libreria bitcoin-nostr-chat del progetto, per sincronizzare le etichette del wallet tra i dispositivi di un utente e per inviare e ricevere PSBT per la co-firma multisig remota tra partecipanti fidati. Il livello Nostr stesso è stato rilasciato prima, nella 2.0.0 (2026-06-29), che ha ridisegnato la firma delle transazioni attorno a un tipo di connessione “Share via Chat & Sync” insieme a QR, USB e Bluetooth. La notizia di questa settimana è il pacchetto Flathub che mette quella funzionalità esistente davanti a un pubblico Linux mainstream per la prima volta.

Modifiche non rilasciate

Amethyst consente agli account di assegnare soprannomi ai contatti con schede NIP-85 cifrate

Oltre all’implementazione di Concord trattata sopra, Amethyst ha integrato altre 54 PR nell’ultima settimana. La principale tra queste è PR #3548, che consente a un account di assegnare un soprannome a qualsiasi altro utente pubblicando la propria scheda di contatto kind 30382 NIP-85 su di lui. Il soprannome, una nota privata, e qualsiasi mappatura personalizzata di codici brevi di emoji NIP-30 risiedono all’interno del contenuto cifrato con NIP-44 della scheda, così che solo l’account firmatario possa leggerli, e le schede si sincronizzano attraverso il set esteso di relay outbox dell’account al login e in modo incrementale in seguito. Feed, chat e menzioni rendono il soprannome al posto del nome visualizzato pubblico, con una scheda del soprannome toccabile nella pagina del profilo sopra il vero nome dell’utente.

Zap Cooking rilascia la Fase 3 di My Kitchen e corregge un bug di quorum del pool NDK

Zap Cooking è un’app di condivisione di ricette e comunità culinaria costruita su Nostr. Ha integrato 43 PR proseguendo la sua funzionalità di pianificazione dei pasti “My Kitchen”, introducendo in questa fase la generazione di liste della spesa, un selettore di ricette e una griglia settimanale del pianificatore. Lo stesso insieme di modifiche corregge un bug di prontezza del quorum del pool di connessioni di NDK (Nostr Development Kit) che poteva lasciare le letture dei relay in attesa oltre il punto in cui un quorum di relay aveva già risposto.

Kehto trasmette le letture di outbox prima della scoperta dei relay

Kehto è un runtime web iniziale per applet Nostr NIP-5D, o “napplet”. Ha integrato 26 PR. PR #193 corregge le letture di outbox che in precedenza attendevano il completamento del caricamento della lista di relay NIP-65 prima di aprire qualsiasi relay, così che un caricamento della lista di relay che non si risolveva mai poteva bloccare sia la consegna degli eventi sia i timeout delle query; la correzione apre immediatamente gli hint di relay validati e trasmette i risultati man mano che vengono scoperti i relay di scrittura. Una seconda modifica (PR #196) allinea la pagina di audit dell’identità del progetto con NAP-SHELL, il contratto di ciclo di vita della piattaforma Napplet, parte dello stesso lavoro di allineamento del protocollo visibile altrove nel rilascio napplet/web di questa settimana.

Wired e TAO aggiungono la condivisione dei ricavi per i creatori con NIP-57

Wired e TAO sono client social gemelli orientati alla libertà di parola costruiti su Nostr, che condividono la stessa lista di PR; entrambi hanno integrato PR #121, che implementa la condivisione dei ricavi per i creatori NIP-57 affinché gli zap inviati a un post possano dividersi automaticamente tra collaboratori oltre all’autore originale. Questo prosegue la copertura del #30 sulla coppia che alzava il proprio segnale di proof-of-work a 21 bit come lavoro non rilasciato.

Conduit Mono ricostruisce la casella degli ordini del commerciante attorno al checkout come ospite effimero

Conduit Mono è un protocollo di marketplace adiacente agli annunci classificati NIP-99. PR #174 aggiunge il checkout come ospite usando una chiave effimera generata dal browser: l’ospite invia un ordine cifrato e un rapporto di pagamento al commerciante usando quella chiave monouso, e il commerciante dà seguito fuori banda per telefono o email, così che l’acquirente non abbia mai bisogno di un’identità di casella durevole. PR #175 ricostruisce la casella degli ordini del commerciante attorno a un unico modello di stato dell’ordine condiviso, separando i ruoli di acquirente e commerciante e richiedendo un codice di tracciamento e un corriere prima che un ordine fisico o misto possa passare a spedito. Il flusso di checkout del progetto si basa sui messaggi privati NIP-17, sulla cifratura NIP-44 e sul gift wrap NIP-59. Il NIP Deep Dive di questa settimana copre le convenzioni di Gamma Markets verso cui questo stesso problema di stato dell’ordine si dirige.

Buzz irrobustisce il provisioning del creatore di canale attorno al kind 39002

Buzz è una piattaforma di comunicazione a mente collettiva che collega agenti IA e umani su Nostr. Ha integrato 240 PR nell’ultima settimana, proseguendo il suo arco di irrobustimento del livello di relay dalla copertura del #30 sulle metriche di turno degli agenti kind 44200. La correzione di questa settimana (PR #1830) tratta il creatore di un canale come membro prima che venga eseguita la logica di provisioning del canale kind 39002, chiudendo una race condition in cui il canale del creatore stesso poteva rifiutarlo durante la configurazione.

Nostr Docs adotta un firmatario NIP-49 con account multipli e accoppiamento QR

Nostr Docs è un’applicazione di documenti collaborativi nativa di Nostr. Ha integrato 5 PR, quella notevole (PR #50) adottando il pacchetto @formstr/signer per l’autenticazione completa NIP-49 con cambio tra account multipli e accoppiamento QR, sostituendo un percorso di firma su misura precedente.

Anche rilasciato

Correzioni minori di interoperabilità dei firmatari e di affidabilità sono arrivate in diversi progetti tracciati nell’ultima settimana senza superficie nuova sufficiente per un proprio paragrafo: ngit-cli, un client da riga di comando per un’alternativa a GitHub basata su Nostr, rilascia v2.6.3 facendo sì che ngit init dia indicazioni di configurazione concrete invece di richiedere ripetutamente un nsec; Manent, un’app privata di note e file cifrati costruita su Nostr, rilascia v1.4.1 correggendo il login con firmatario Android che si rompeva quando Amber restituisce un pubkey esadecimale e migliorando lo scorrimento del login bunker; NoorNote, un client Nostr snello e privo di servizi Google, rilascia v1.2.8 correggendo le notifiche mancate dei gruppi Nostrord e aggiungendo un interruttore di avviso per i propri post; Bray, un server MCP Nostr consapevole della fiducia per agenti IA e umani, rilascia v1.34.0 inviando i metadati del nome del client alla connessione bunker NIP-46; Lumilumi, un client web Nostr, memorizza le liste di relay NIP-65 nello storage locale come fallback offline; Earthly, un’app di città e comunità locale basata su Nostr, aggiunge la ricerca geografica NIP-50; e lnbits, un sistema di wallet e account Lightning gratuito e open-source, rilascia PR #3925 rendendo send_nostr_dm non bloccante all’interno di un rilascio per il resto focalizzato su Lightning.

Appena tracciati e scoperti

OpenDiscord v1.0.1 debutta come client in stile Discord su Nostr

OpenDiscord è un client con server e canali in stile Discord costruito su Nostr con permessi basati sui ruoli e lobby vocali WebRTC/SFU. v1.0.1 è il primo rilascio con installer taggato del progetto.

Auditable Voting v0.1.140 allinea i ruoli di organizzatore, votante e proxy di audit

Auditable Voting è uno shell di voto solo client su Nostr. v0.1.140 allinea i ruoli di organizzatore, votante e proxy di audit con l’esatto evento di definizione del questionario pubblico firmato dall’organizzatore, chiudendo una lacuna in cui un proxy di audit poteva agire su account generati obsoleti o su uno stato persistito da un worker o organizzatore diverso.

Cambium v0.3.2 si abbina a Heartwood come firmatario NIP-55 senza chiavi

Cambium è la scelta Discovery di questo numero: un firmatario Android NIP-55 che non conserva alcun materiale di chiave privata proprio, facendo da proxy per ogni richiesta di firma tramite NIP-46 verso un firmatario hardware Heartwood compagno. Il progetto condivide l’organizzazione GitHub forgesworn con il progetto tracciato Bray, e Heartwood stesso è stato trattato nel #30 quando ha rilasciato il ponte di firma relay-verso-seriale con cui ora dialoga il lato Android di Cambium. v0.3.2 rifinisce il foglio di approvazione per avvisare dal vivo quando l’identità selezionata differisce dal collegamento esistente dell’app e sposta le scritture del registro di attività in un’unica coda non bloccante.

Anche in lancio questa settimana: echoes, Dispatch e Linky

Tre altri lanci meritano una menzione questa settimana. echoes è un’app di note offline-first e cifrata end-to-end che si sincronizza privatamente su Nostr. Dispatch è un organizzatore di viaggi local-first in cui ogni salvataggio è cifrato con NIP-44 e sottoposto a backup su Nostr con una chiave dedicata e non collegabile, e il suo rilascio v0.3.0 aggiunge il login Amber NIP-55 affinché l’app non tocchi mai direttamente la chiave privata dell’utente. Linky combina contatti e DM Nostr con pagamenti Lightning e Cashu in un’unica progressive web app.

Lavoro di protocollo e aggiornamenti dei NIP

Nessuna PR integrata nel repository dei NIP nell’ultima settimana. Sono state aperte sei proposte.

Aperta: kind:10011 set di follow preferiti

PR #2413, di fiatjaf, aggiunge i set di follow preferiti kind:10011. Rispecchia il modello esistente in cui kind:10012 (set di relay preferiti) contiene tag a che puntano a set di relay kind:30002, estendendo lo stesso meccanismo di preferenza ai set di follow kind:30000 affinché un client possa segnare una lista di follow curata senza sostituire la propria lista di contatti.

Aperta: unità cifrata privata che estende NIP-4E

PR #2412, del team Form*, propone un evento Metadata generico, kind 34578, distinto da un tag identificatore d e da un tag di sottotipo t, insieme a un file system cifrato privato costruito su di esso che è già implementato nel client Form* Drive del progetto, ancora sperimentale. Un record di file è un evento Metadata con t=files: i blob dei file risiedono su server Blossom mentre solo un indice cifrato risiede sui relay, e ogni chunk di file ottiene la propria coppia di chiavi effimera con cifratura NIP-44 v2 derivata tramite HKDF. Un evento compagno di Chiave di Cifratura Disaccoppiata contiene un’unica chiave simmetrica valida per l’intera unità contro cui i metadati di ogni file vengono decifrati, e si basa esplicitamente su NIP-4E, la bozza di astrazione dello storage ancora aperta di fiatjaf (PR #1647, aperta da dicembre 2024).

Quell’unica chiave valida per l’intera unità significa che una chiave trapelata espone i metadati di ogni file dell’unità, non solo di uno, poiché le coppie di chiavi effimere per file variano solo la chiave di cifratura del chunk, non la chiave di decifratura dei metadati; non esiste ancora alcun percorso di rotazione o revoca oltre alla pubblicazione di un nuovo evento Metadata che avverte che gli eventi più vecchi potrebbero andare persi. Una seconda proposta, più ristretta, raggiunge la stessa idea sottostante di NIP-4E da un’angolazione diversa: PR #2361, di fiatjaf, disaccoppia le chiavi di identità e cifratura all’interno della messaggistica NIP-17 nello specifico, aperta dal 1° giugno. Entrambe le PR non sono integrate, lasciando questo un angolo attivo e conteso dello spazio di progettazione. Form* dice che il client Drive è sperimentale con un aggiornamento in arrivo a breve.

Aperta: NIP-DA condivisione privata di dati con permessi

PR #2411, di JAFairweather, è una nuova bozza NIP-DA per la condivisione privata di dati con permessi attraverso concessioni di dati con ambito. Ogni utente mantiene un record cifrato e autoritativo per ambito sui relay, e l’accesso viene concesso consegnando privatamente la chiave simmetrica di quell’ambito dentro un gift wrap NIP-59, così che i relay memorizzino solo testo cifrato e non sappiano mai chi ha concesso l’accesso a chi; una revoca è semplicemente una rotazione di chiave, senza bisogno di riscrivere la copia di ogni consumatore. L’autore la posiziona come distinta dai DM NIP-17 (che possono portare uno snapshot di dati ma non aggiornamenti dal vivo né revoca) e dalle liste private NIP-51 (che non portano materiale di chiave), e cita due implementazioni indipendenti, una libreria di riferimento in JavaScript e una CLI in Go su go-nostr, testate in modo incrociato contro relay.damus.io, nos.lol e relay.primal.net.

Aperta: kind per pacchetti di sticker 10031 e 30031

PR #2410, di vincenzopalazzo, registra il kind 30031 (pacchetti di sticker indirizzabili) e il kind 10031 (la lista di pacchetti di sticker di un utente) nella tabella Event Kinds, specificati dal formato “Sonar Stickers” che Sonar rilascia questa settimana. I kind si collocano deliberatamente uno slot sopra i kind di emoji personalizzati NIP-30 30030 e 10030 affinché un client non possa scambiare un pacchetto di sticker per un set di emoji; i byte dell’immagine degli sticker risiedono su server HTTPS compatibili con Blossom, e i riferimenti agli sticker inviati portano un hash in testo semplice affinché un pacchetto indirizzabile modificato non possa cambiare silenziosamente l’aspetto degli sticker già inviati in vecchi messaggi. Una PR compagna registra gli stessi kind nel progetto separato registry-of-kinds.

Aperta: fissaggio dei messaggi NIP-29 con kind:9010 e kind:39005

PR #2379, di Anderson-Juhasc, aggiunge il fissaggio dei messaggi ai gruppi basati su relay NIP-29: kind:9010 update-pin-list è un evento di moderazione che porta la lista completa degli eventi fissati come tag e in ordine di visualizzazione, così che un singolo evento possa fissare, rimuovere dal fissaggio, riordinare o azzerare il set fissato, e kind:39005 è uno specchio generato dal relay che espone l’ultima lista accettata. Il design sostituisce un precedente approccio a coppie aggiungi/rimuovi di PR #1163 dopo il feedback della revisione, e sceglie i numeri di kind 9010/39005 perché 9009 e 39003 sono nel frattempo stati rivendicati da create-invite e dai ruoli di gruppo. Anderson-Juhasc mantiene anche Nostrord, la cui v2.2.0 viene rilasciata questa stessa settimana.

Aperta: ristrutturazione della scoperta di relay NIP-66

PR #2241, di VincenzoImp, è una ristrutturazione sostanziale della scoperta di relay NIP-66. Sostituisce la prosa vaga di “Altri tag includono” con una sezione strutturata di Tag Indicizzati, aggiunge un tag W che rispecchia il campo attributes di NIP-11 per il filtraggio della scoperta di relay, aggiunge un tag di etichetta l che usa spazi dei nomi standardizzati (ISO-639-1, ISO-3166-1, IANA-asn, IANA-tz, nip66.label.city), e organizza i tag di RTT, SSL/TLS, rete, geografici, DNS e HTTP in sezioni dedicate insieme a una nuova tabella di Tipi di Verifica. Corregge anche eventi di esempio rotti che avevano nomi di campo errati, un kind mancante e nomi di tipo di verifica non validi, e chiude la issue #2171. Tutte le modifiche restano retrocompatibili poiché ogni tag aggiunto è opzionale.

NIP Deep Dive: NIP-99 e l’estensione di commercio Gamma Markets

NIP-15, la specifica originale del Marketplace Nostr, è ormai legacy: modellava un banco del commerciante (kind 30017) con i prodotti (kind 30018) archiviati sotto di esso, e i client che un tempo ci giravano sopra, Shopstr tra questi, sono da allora passati agli annunci classificati NIP-99 come specifica attiva. NIP-99 in sé è un singolo evento indirizzabile, kind 30402 per un annuncio attivo o kind 30403 per una bozza, senza alcun banco da creare prima. Lascia indefinito tutto ciò che va oltre l’annuncio: costo di spedizione, stato dell’ordine, ricevute, recensioni, e un modo per raggruppare più annunci sotto un’unica vetrina, esattamente le parti di NIP-15 che non sono mai state trasferite. Gamma Markets colma quella lacuna, ed è il livello di commercio moderno che vale la pena capire oggi.

La lacuna che NIP-99 lascia aperta

Il campo content di un annuncio NIP-99 porta una descrizione in Markdown, price e location risiedono direttamente sull’evento, e i tag t lo rendono ricercabile come contenuto hashtag ordinario. Poiché è indirizzabile sulla tupla pubkey, kind e tag d, un venditore modifica un annuncio sul posto pubblicando una nuova versione con lo stesso tag d:

{
 "kind": 30402,
 "content": "Vintage mechanical keyboard, Cherry MX Blue switches, barely used.",
 "tags": [
 ["d", "keyboard-mx-blue-01"],
 ["title", "Vintage Mechanical Keyboard"],
 ["summary", "Cherry MX Blue, barely used"],
 ["published_at", "1752537600"],
 ["location", "NYC"],
 ["price", "100", "USD"],
 ["t", "electronics"]
 ]
}

Questa è l’intera specifica: un annuncio classificato firmato e aggiornabile. Ogni client che implementa NIP-99 per un e-commerce reale, oltre a un classificato occasionale, ha finito per inventare le proprie convenzioni private per spedizione, messaggi d’ordine e recensioni. Due client NIP-99 potevano ciascuno rendere correttamente un annuncio e comunque non avere alcun modo condiviso di completare un checkout tra loro.

Gamma Markets: standardizzare ciò che NIP-99 ha lasciato fuori

Gamma Markets è il nome che un gruppo di lavoro di sviluppatori di marketplace Nostr, i team dietro Shopstr, Cypher, Plebeian Market e Conduit Market, ha dato a un insieme condiviso di convenzioni di e-commerce costruite sopra l’evento kind 30402 esistente di NIP-99. La specifica è collegata dal documento canonico di NIP-99 tramite PR #1784 e mantenuta nel proprio repository, GammaMarkets/market-spec.

Gamma Markets aggiunge due kind autonomi adiacenti agli annunci. Il kind 30405 raggruppa più annunci in una collezione di prodotti, referenziando ciascuno con un tag a esplicito:

{
 "kind": 30405,
 "content": "Summer sale picks",
 "tags": [
 ["d", "summer-picks"],
 ["title", "Summer Sale"],
 ["a", "30402:<merchant-pubkey>:keyboard-mx-blue-01"],
 ["shipping_option", "30406:<merchant-pubkey>:standard-regional"]
 ]
}

Il kind 30406 definisce un’opzione di spedizione con prezzi per paese e regole di costo opzionali basate su peso o distanza:

{
 "kind": 30406,
 "content": "Standard Regional Shipping",
 "tags": [
 ["d", "standard-regional"],
 ["title", "Standard Shipping"],
 ["price", "5.99", "USD"],
 ["country", "US"],
 ["service", "standard"],
 ["duration", "24", "72", "H"],
 ["weight-max", "30", "kg"]
 ]
}

La creazione degli ordini, le richieste di pagamento, gli aggiornamenti di stato e spedizione, e le ricevute di pagamento viaggiano tutti come normali messaggi privati avvolti con gift-wrap NIP-17, suddivisi in tre kind per ruolo, non ri-avvolgendo il trasporto: il kind 14 porta la comunicazione libera tra acquirente e commerciante, il kind 16 porta ogni transizione di stato dell’ordine (un tag type da 1 a 4 segna creazione dell’ordine, richiesta di pagamento, aggiornamento di stato o aggiornamento di spedizione), e il kind 17 porta la ricevuta di pagamento dell’acquirente. Un messaggio di creazione dell’ordine appare così prima del gift-wrapping:

{
 "kind": 16,
 "content": "Please leave the package with the doorman.",
 "tags": [
 ["p", "<merchant-pubkey>"],
 ["subject", "New order"],
 ["type", "1"],
 ["order", "order-8f21"],
 ["amount", "115000"],
 ["item", "30402:<merchant-pubkey>:keyboard-mx-blue-01", "1"],
 ["shipping", "30406:<merchant-pubkey>:standard-regional"]
 ]
}

Valutare un acquisto completato è un kind indirizzabile separato, 31555, che punta all’annuncio che recensisce:

{
 "kind": 31555,
 "content": "Arrived fast, exactly as described.",
 "tags": [
 ["d", "a:30402:<merchant-pubkey>:keyboard-mx-blue-01"],
 ["rating", "1", "thumb"],
 ["rating", "1.0", "quality"],
 ["rating", "0.9", "delivery"]
 ]
}

Far viaggiare i messaggi d’ordine su NIP-17 significa che un checkout di Gamma Markets usa lo stesso trasporto di messaggi privati che i client già rilasciano per i DM, invece di un kind di messaggio d’ordine su misura.

La scelta di progettazione centrale della specifica è che nulla si eredita a cascata. Un annuncio che appartiene a una collezione la referenzia esplicitamente con un tag a invece di ereditare automaticamente le opzioni di spedizione o la descrizione della collezione, e un’opzione di spedizione che un annuncio usa viene referenziata nello stesso modo esplicito. Questa è un’inversione deliberata del modello a banco di NIP-15, dove un prodotto ereditava silenziosamente qualunque valuta e tabella di spedizione definisse il suo banco genitore. Il compromesso è un tagging più esplicito su ogni annuncio, in cambio del fatto che la configurazione completa di un annuncio sia sempre leggibile dall’evento stesso, senza alcun oggetto genitore da risolvere prima.

Dove questo si manifesta nella pratica

Il lavoro di Conduit Mono di questa settimana si colloca nello stesso territorio di messaggi d’ordine che Gamma Markets standardizza: il checkout come ospite con chiave effimera di PR #174 e la ricostruzione della casella degli ordini del commerciante di PR #175 risolvono entrambi il problema di stato dell’ordine acquirente/commerciante che i messaggi kind 14, 16 e 17 di Gamma Markets formalizzano; Conduit Mono esegue il proprio modello di stato dell’ordine accanto a quei kind, senza adottarli direttamente. Shopstr, uno dei quattro progetti che hanno scritto la specifica, ha tenuto in movimento anche il proprio impianto di commercio nell’ultima settimana: PR #568 estrae la logica di gift-wrap NIP-17 duplicata in un modulo condiviso, e PR #567 porta il suo parser di autenticazione HTTP NIP-98 a una copertura di test completa, manutenzione esattamente sui livelli di messaggistica e autenticazione da cui un flusso d’ordine di Gamma Markets dipende per raggiungere acquirente e commerciante in sicurezza.

NIP-15 ha perso il ruolo di vetrina standardizzando un banco e un prodotto, e poi lasciando pagamenti, spedizione, recensioni e stato dell’ordine come problema dell’applicazione. Gamma Markets colma la maggior parte di quella superficie mancante senza toccare la forma a singolo annuncio di NIP-99, costruendo sullo stack di DM esistente di Nostr, NIP-17, invece di inventare un nuovo livello di messaggistica.

Questo è tutto per questa settimana. Stai costruendo qualcosa o hai notizie da condividere? Scrivici via DM NIP-17 o trovaci su Nostr.

Nostr Compass #30

Wed, 08 Jul 2026 00:00:00 +0000

Benvenuti a Nostr Compass, la vostra guida settimanale a Nostr.

Questa settimana: il Marmot spec è contrassegnato adottato attraverso 42 file come MDK taglia v0.9.0 tramite v0.9.3 con avatar di gruppo crittografato, supporto di firma esterna, e MarmotKit iOS e attacchi Android. Mostro navi Trasporto v2 su NIP-44 messaggi diretti con cancelli anti-spam e una finestra di coesistenza in entrambi mostrod v0.18.0 e Mobile v1.3.0. [Bitchat 1.6.0 aggiunge ZXQ0054QXXXC Amber applica gli abbonamenti del profilo per account, fetches NIP-65 elenchi di relè prima dei metadati del profilo, e aggiunge una notifica di stato Tor live con un’azione di riavvio. rust-nostr aggiunge la scadenza NIP-40 alla confezione regalo e ai costruttori NIP-17 DM, ancorati al timestamp randomizzato dell’involucro. Amethyst unisce 43 PR di indurimento di sincronizzazione negentropia, NIP-50 infrastruttura di ricerca full-text, e tipi di eventi per verticali di nicchia. Nostrord navi v2.0.0 e v2.1.0 con una piscina a relè piegata, il rilevamento WebSocket zombie, e una cucitura completa della cache del disco-primo. [ZXQ00] (ZXXXXXX) Il repository NIPs si fonde con un NIP-51 e allineamento del nome NIP-37 e apre cinque proposte: NIP-AD Nostr Web Addresses, [ZXQ0065QXXZ] Copertura profonda delle immersioni NIP-13 (protezione del lavoro) e NIP-40 (tempri di scadenza).

Marmot segna la spec adottata e MDK taglia v0.9.x

Il Marmot protocol repository fuso PR #170 il 3 luglio, cambiando 42 file da Status: draft for internal review (e experimental draft) a Status: adopted. Il titolo README si è spostato dall’inquadratura del repo come lavoro in corso a “Marmot Protocol” come testo adottato, i documenti dell’era MIP sono stati ri-framezzati come la versione deprecata del protocollo, e la sezione “Review Status” (“Questo non è ancora adottato testo spec”) è diventata “Review Guidance” per la modifica della corrente spec. L’etichetta v2 scompare in tutto: MIP-contrast phrasing (“new in v2”, “the v2 spec keep”) viene sostituita con “this spec” e “under this spec”. Due documenti mantengono il loro progetto di stato per disegno: implementation-model.md rimane non-normativo, e il documento della funzione multi-dispositivo rimane una bozza.

Lo stesso repository è atterrato PR #171 allineando la politica di amministrazione, l’appartenenza e gli invarianti di cambiamento di ruolo. Il controllo cross-component che un Remove non può orfano un amministratore è ora dichiarato come una proprietà di ogni epoca risultante, valutata contro il set di amministrazione dell’epoca precedente quando un commit non porta un aggiornamento di amministrazione-policy. La regola candidato-branch di Convergence è serrata in modo da “validates” significa piena validità di commit, compresi i controlli cross-component risultante-epoch, che impedisce un commit invariante-violante di creare un bordo candidato su qualsiasi ramo. Le notifiche di stato derivate da un commit superato devono essere ritirate quando la selezione di ramo lo sostituisce, che chiude il “perdere rinomina rende come un messaggio di sistema di successo” bug a livello spec. Una nuova sezione “Realizzare la rimozione” in member-departure.md definisce l’ingresso di realizzazione primaria (l’impegno canonico accettato rimuovendo l’ultima foglia) e il fallback per i clienti che non hanno mai applicato il commit di rimozione: le prove autenticate post-evizione ora superano come risultato SelfEvicted con semantica inattiva per la copia del gruppo rimossa. PR #236 quindi serrata convalida a filo-boundary, pinning KeyPackage accettazione a vita a 84 giorni più un margine di skew di un’ora, aggiungendo una tabella Nostr tag-cardinality per gruppo h, dono-wrap p, benvenuto e e ZXQ0005QQXQXQXQXQ

A valle, lo spazio di lavoro MDK tagliato v0.9.0 il 6 luglio con un urto di versione full workspace, seguito da v0.9.1, v0.9.2) e [v0.9. v0.9.0 ruota le voci di keyring stale quando viene creato un nuovo database SQLite e atterra la disciplina di convalida-prima-mutata attraverso lo strato di archiviazione. v0.9.1 tratta ogni connessione in uscita attraverso un Chokepoint dial host-safety tramite PR #732, chiudendo la classe di bug in cui diversi siti di chiamata hanno raggiunto la rete con una validazione diversa. v0.9.3 espone gli avatar di gruppo crittografati ai binding uniffi attraverso download_group_image e image_hash_hex tramite PR #771, aggiunge il supporto di segnale esterno, e segna wn-opencode produzione-ready via PR #781. Oltre ai tagli MDK, MarmotKit spedisce attacchi iOS e Android ad ogni versione (un MarmotKit.xcframework più binding Swift per attacchi iOS e Kotlin più librerie JNI per Android, entrambi generati da un bugnato MDK commit hash), e un nuovo canale di rilascio di wn-agent fornisce installatori di shell che pin la versione WN

Mostro v0.18.0 e Mobile v1.3.0 nave Trasporto v2 su NIP-44

Mostro è il protocollo di trading peer-to-peer Bitcoin che esegue libri di ordine, escrow e risoluzione delle controversie sugli eventi di Nostr, coordinato da un daemon (mostrod) che i clienti parlano a DM più crittografati. Fino a questa settimana il protocollo di migrazione tra i client e mostrod è stato Transport v1. Mostro v0.18.0 atterra Trasporto v2, cablaggio del protocollo su NIP-44 messaggi diretti con cancelli antispam e dual-receive Un relativo PR #782 fissa un tag info NIP-33 rinominando protocol_versions al singolare protocol_version. Oltre al lavoro di trasporto, il rilascio atterra un percorso live-quote unificato di Fase 4 con l’applicazione della cache-e-staleness (PR #783) e un fornitore di cross El Toque che copre le coppie cubane di CUP e MLC (PR #778).

[ZXQ0008QXXZ v1.3.0] (https://github.com/MostroP2P/mobile/releases/tag/v1.3.0) è la metà client della migrazione. PR #613 migra l’app a ZXQ0009QX37XZ 3.x, Fase A (PR #620) aggiunge il supporto dual-receive per ZXQ0012 Il rilascio aggiunge anche la copertura del metodo di pagamento africano: [PR #625] (https://github.com/MostroP2P/mobile/pull/625) aggiunge i metodi di pagamento del Malawi Kwacha e [PR #627] (https://github.com/MostroP2P/mobile/pull/627) aggiunge KES (Kenyan Shilling), MZN (Mozambican Metical), TZS (Tanzanian Shilling), UGX (Ugandan Shilling), ZAR Un flusso di ripristino ora aspetta la connettività dei nodi prima di emettere richieste di ripristino, e la gestione di causa-consapevole distingue uno slash obbligazionario guidato da una timeout-driven.

Bitchat 1.6.0 aggiunge NIP-13 proof-of-work e un gateway opt-in mesh-to-Nostr

[Bitchat 1.6.0] (https://github.com/permissionlesstech/bitchat/releases/tag/v1.6.0) è l’applicazione di chat Bluetooth-mesh che utilizza Nostr per i suoi canali geohash e handoff DM. PR #1382 aggiunge NIP-13 (proof-of-work) ai messaggi di canale geohash in uscita (tipo 20000 eventi effimeri): ogni mina un tag ["nonce", "<value>", "<target>"] in uscita ha un bit di 8 secondi. Gli eventi in entrata con validato PoW rilassano il limite di aspirazione per-sender, quindi uno spammer paga la computazione per messaggio mentre un mittente regolare non sente il costo. Scope è volutamente stretto: solo i messaggi di canale di tipo 20000 mine PoW, e i battiti cardiaci di presenza (kind 20001), le note di posizione gentili-1, e DMs sono intatti.

PR #1384 aggiunge la modalità gateway, un uplink mesh-to-Nostr opt-in per i canali geohash. Quando un utente mesh-only (nessun internet, nessun relè raggiungibile) invia in un canale geohash e un altro peer sulla rete pubblicizza la capacità .gateway, il tipo firmato 20000 evento è avvolto in una nuova busta MessageType.nostrCarrier = 0x28 TLV e inviato diretto a un gateway. Il gateway peer pubblica l’evento a Nostr per conto del mittente e rebroadcast traffico canale in entrata sulla rete con TTL predefinito. I depositi di uplink cavalcano il percorso della busta del corriere (diretto, relayed multi-hop); downlink cavalca in onda. La firma avviene prima che l’evento lasci il mittente, in modo che il gateway può decidere se pubblicare ma non può forgiare l’attribuzione. La motivazione dichiarata è disastro e scenari di protesta in cui un telefono collegato in una folla è sufficiente per dare l’intero canale geohash un uplink Nostr funzionante.

PR #1381 aggiunge i fasci prechiavi per il primo contatto asincrono sul percorso della posta del corriere, in modo che un mittente possa comporre un messaggio a un pari che è offline e consegnarlo alla rete senza aver fatto prima una stretta live di Noise. PR #1380 aggiunge la verifica transitoria: un peer che ha completato la stretta di mano del rumore con qualcuno che hai già verificato è ora garantito per over the Noise session, quindi il grafico di fiducia propaga un hop alla volta invece di richiedere una nuova verifica in persona firmata per ogni nuovo contatto. Bitchat 1.5.4 spedito primario nella settimana con i preferiti end-to-end fix in PR #1367 che pulisce i duplicati di peer-list, la sincronizzazione Nostr e la corruzione chiave /fav.

Tagged releases

Amber v6.2.3 presenta gli abbonamenti del profilo e aggiunge una notifica di stato Tor

Amber v6.2.3 è un segnale di prestazioni e correttezza sul segnale Android NIP-46 e le PR unite nella settimana intorno a esso puntano a un tema coerente. Il rilascio stesso aggiunge un’impostazione dell’intervallo fetch del profilo configurabile con opzioni mai e sempre (PR #492), mostra un’immagine del profilo nel foglio inferiore dell’interruttore dell’account, e gli abbonamenti del profilo dell’account corrente in modo che un firmatario che tiene più account smetta di esaurire gli abbonamenti per gli account che l’utente non sta firmando con. Bunker permesso parsing guadagna esplicito errore di gestione su fallimenti parse. Numerose violazioni StrictMode sono fissate: un DiskReadViolation dalla registrazione di Coil onSuccess, una violazione di keytore dal caricamento dell’account sul thread principale, lettura main-thread per il nome dell’account e l’immagine nel foglio dell’interruttore dell’account, e desiderosi di KeyPair() costruzione sul login e schermi di registrazione ora spostato fuori il thread principale. Nei giorni dopo v6.2.3 spedito, PR #493 riordinato il percorso di avvio per recuperare l’utente NIP-65 elenco di relè prima dei metadati del profilo (così il profilo fetch interroga i relè che l’utente pubblica a), e [PR #494Q](ZXQ0007 PR #495 ha abilitato Android Lint in modalità avvisi-as-errors rigorosi attraverso la base di codice.

Jumble v26.7.1 rende Blossom il servizio di upload predefinito in un taglio focalizzato su DM

Jumble v26.7.1 è un client web Nostr tagliato focalizzato su messaggi e supporti diretti. Il rilascio ridisegna le impostazioni di caricamento dei media e rende [Blossom] (/it/topics/blossom/) il servizio di upload predefinito, sostituendo il precedente default NIP-96. La gestione di DM ottiene un menu di messaggi mobili, migliorato le azioni dei messaggi desktop, un pulsante “scroll to più recenti”, reazioni a lunga pressione sui media DM, e un percorso di riprovazione per i DM non riusciti in uscita dalla lista dei messaggi. L’editing personalizzato di emoji guadagna una vista dettagliata, il dimensionamento della bolla del messaggio migliora per le fatture e il contenuto incorporato, diversi problemi di scorrimento e di ordinazione dei messaggi di DM sono fissi, e i problemi post-editor relativi all’inserimento emoji, copia del testo e trascinamento dei file vengono ripuliti. L’orientamento dell’immagine viene corretto quando i metadati vengono rimossi su upload e i download di Linux ARM64 vengono aggiunti alla matrice di rilascio.

## Applesauce signers 6.2.2 scende una dipendenza nbunksec

applesauce-signers@6.2.2 abbassa la dipendenza @sandwichfarm/encoded-entities del sottopacchetto a favore di un built-in nbunksec helper via commit d654349. La codifica della sessione di bunker di Applesauce NIP-46, aggiunta la scorsa settimana, non richiede più la libreria di codifica esterna, tagliando una superficie della catena di fornitura per i clienti a valle che consumano il pacchetto dei firmatari.

Ngit v2.6.2 interrompe gli eventi duplicati di stato PR sulla pressione di default-branch

Ngit v2.6.2 è un bug-fix release per il git-over-Nostr CLI. git push al ramo di default smette di pubblicare duplicati eventi di stato PR merge/applied per le PR che sono già contrassegnate applicate, perché la rilevazione di fusione ora legge il pre-push Nostr repo stato (la fonte di verità per se un PR è stato già risolto sul lato NIP-34 del flusso di lavoro); il precedente evento euristico basato su git interno. I repository attivi che utilizzano ngit per i flussi git-over-Nostr smettono di emettere eventi di stato del tipo-1621 duplicati nel loro pubblico.

Bray v1.33.0 CLI raccoglie un profilo bunker, persona e Tor in uscita

Bray v1.33.0 è un rilascio Nostr SDK-plus-CLI. bunker --profile <name> ottiene una chiave di connessione auto-stabile e fallback relè in modo che un profilo salvato possa sopravvivere a un outage relè; bunker --persona <name> segni come un’identità derivata nsec-tree, lasciando un segnale agire come più pubkeys da un singolo albero derivato; e tutte le fetches HTTP possono essere instradate tramite un proxy ZXQ0027QX Il rilascio aggiunge sottocomandi portafogli per NIP-47 NWC, NIP-29 gruppo di gestione delle operazioni di scrittura (creare, aggiornare, add-user, remove-user, set-roles), NIP-86 e [ZX13X00 Publishing verbs pick up --jsonl, --csv, e --tsv bandiere di uscita, un verbo req generico per domande filtro NIP-01, un verbo event per la costruzione di eventi arbitrari, un comando publish-raw Il lavoro di sicurezza copre tre lotti di deferrals di audit: disciplina di zeroizzazione segreta, HTTP di trasporto di orso-auth e l’indurimento dei limiti di tasso, e convalida SSRF sugli URL di relè. Le npm tarball navi a 533.844 byte con un byte-identico edificio riproducibile verificato in due corridori CI indipendenti.

Deepmarks 1.0.0 indurisce la superficie di bookmarking Nostr

Deepmarks 1.0.0 è una pietra miliare di sicurezza per un servizio pubblico di bookmarking Nostr. Ogni segnalibro è ancora un evento firmato Nostr che qualsiasi cliente può leggere. Lo API e il lavoratore di archivio siedono in una posizione di rete privilegiata (può raggiungere Redis interno, il percorso di relè del bunker e i metadati del cloud), quindi la protezione SSRF è portante di carico, e il rilascio fissa un bypass critico IPv6-litterale in isPrivateIp: staffato IPv6 literals sono stati classificati come pubblico, quindi La guardia ora spoglia staffe e piega IPv4-mapped e IPv4-compatibile IPv6 fino al v4 incorporato prima del controllo a banda privata su entrambe le caselle. I profili kind:0 da relè esterni sono ora marcati al lavandino in modo che un relè ostile non possa forgiare un nip05 o lud16 per una vittima arbitraria pubkey, e gli URL del bookmark sono controllati da ogni lavandino di render in modo da un segnalibro kind:39701 Le ricevute di Zap sono ora sopravvissute a un outage del bunker transitorio: il gestore del regolamento sostiene atomicamente lo zap in sospeso, finalizza solo dopo la firma riesce, e rilascia il reclamo sul fallimento in modo che uno invoice_updated riprova. Lo scarico fan-out /publish utilizza BLMOVE in una lista di elaborazione per-lavoratore con recupero acuto-gated in modo che un lavoratore crashato preserva un evento firmato che il cliente era già 202’d.

## Bitcredit Core v0.5.13 unencrypts block metadatas on the Nostr wire

Bitcredit Core v0.5.13 rimuove uno strato di crittografia dagli eventi pubblici Nostr utilizzati dal protocollo di trasferimento di credito. Bloccare i metadati (bloccare id, hash, firma) è ora non crittografato sul filo Nostr; solo i dati del blocco rimangono crittografati con la chiave di fattura corrispondente. Le nuove applicazioni elaborano vecchie catene, le vecchie applicazioni non elaborano nuove catene. Il rilascio aggiunge anche una funzione di fattura-servizio per recuperare la catena di bolletta, e passa la pubblicazione ad un modello di soglia ottimista: una volta che una soglia di relè configurata (una di default) accetta una pubblicazione, rimanenti relè ricevono l’evento asincronicamente così la pubblicazione non è più bloccata dal relè più lento.

Coop Mobile v0.2.3 e v0.2.4

Coop Mobile spedito [v0.2.3] (https://git.reya.su/reya/coop-mobile/releases/tag/v0.2.3) il 4 luglio e v0.2.4 il 7 luglio, continuando il Android NIP-17 cadenza di rilascio costante del client di messaggio. v0.2.3 aggiunge l’immagine in linea e il rendering del collegamento in messaggi di chat, allegati di immagine, input vocale-to-text e una finestra di dialogo di conferma per la rimozione dei contatti. v0.2.4 fissa un indicatore che è rimasto bloccato per sempre, migliora il handshake Nostr Connect, e aggiunge l’importazione ncryptsec1 (il formato NIP-49 crittografato-private-chiave) insieme a una schermata di identità di importazione ridisegnata.

Granary v11.0 aggiunge supporto per eventi video NIP-71

Granary v11.0 è la libreria di conversione multi-protocollo che alimenta il bridging cross-network di Bridgy Fed. Il modulo Nostr ottiene tre modifiche visibili. NIP-71 eventi video (atti 21, 22, 34235 e 34236) ora convertiti in note ActivityStreams 1 con allegati video, e il convertitore estrae l’immagine imeta (thumbnail), la durata del video, il tag published_at, e il tag ZXQ Sul lato API, sign viene rinominato hash_and_sign e verify ora solleva ValueError sul guasto; il costruttore Nostr solleva ValueError su un URL di relè non valido e Nostr.query Una correzione di conversione di follow-up si blocca quando un oggetto Nostr article arriva senza id. Qualsiasi ponte o lettore che consumano eventi video NIP-71 attraverso Granary può ora esporli nel formato che il lettore di destinazione si aspetta.

Nostr-relay v0.0.244 aggiunge un backend Firestore

mattn/nostr-relay v0.0.244 aggiunge un backend Firestore tramite PR #12, estendendo lo strato di archiviazione del relè Go con un’opzione Google Cloud Firestore accanto ai suoi backend esistenti. Il cambiamento è piccolo ma apre Firestore come opzione di database gestita senza server per un operatore di relè.

Manent v1.4.0 corregge NIP-42 AUTH e aggiunge flussi di clipboard media

[Manent v1.4.0] (https://github.com/dtonon/manent/releases/tag/v1.4.0) è l’app di archiviazione crittografata costruita su Nostr con la crittografia [NIP-44] (/it/topics/nip-44/) e [ZXQ000QXZ] (ZXQ000QXX) Il rilascio corregge l’autenticazione a relè NIP-42 (precedentemente rotto), corregge i caricamenti Blossom agli host http:// (precedentemente maltrattati), e riscrive il flusso di compressione. Sul lato dei supporti, gli utenti possono ora copiare un’immagine sul clipboard, incollare un’immagine dal clipboard, trascinare e rilasciare file, ritagliare e ruotare immagini, riprodurre video e gif, e prendere un video con una lunga pressione sull’icona della fotocamera. Su Linux, il clipboard primario è accessibile tramite mouse middle-click. Il caricamento e lo scorrimento delle note ricevono diverse ottimizzazioni.

Routstrd v0.3.7 rende l’evento Nostr memorizzare la fonte persistente di verità

Routstrd v0.3.7 è il daemon locale per la rete di inferenza AI decentralizzata Routstr, che tratta le richieste LLM tramite Nostr tipo 38421 provider di scoperta e recensioni tipo 38425 LGTM. Il rilascio aggiunge un sottocomando routstrd update che scarica nuovi binari sia per routstrd che per cocod e riavvia con grazia i daemon in esecuzione; il daemon ora chiama refreshNostrEvents() all’avvio e ogni 21 minuti in modo da la scoperta e le recensioni dei fornitori rimangono fresche senza intervento manuale. Il bundle @routstr/sdk aggiorna da 0.3.12 a 0.3.15, rimuovendo lo strato ProviderRegistry in favore dell’uso diretto DiscoveryAdapter, pulendo i modelli da provider Nostr scomparsi in modo da non trapelare più nelle classifiche, e trattando il negozio di eventi Nostr come fonte persistente di verità (l’erroneo 210-minuto TTL sugli eventi cached è andato). La gestione del rimborso Xcashu stringe: i token di rimborso sono provati prima che gli originali nel percorso di errore, la riprovazione di 404s 3× con intervalli di due minuti, e 425 Too Early viene gestito senza gettare.

Nymchat 1.0.1 lancia come app Progressive Web su NIP-17

[Nymchat 1.0.1] (https://github.com/Spl0itable/NYM) (noto anche come NYM, Nostr Ynstant Messenger) è un Progressive Web App e nativo iOS / Android messenger per chat effimera su Nostr, pontificato con Bitchat. I canali utilizzano eventi effimeri tipo 20000 per canali geohash e tipo 23333 per canali nominati; messaggi privati e chat di gruppo cavalcare NIP-17 eventi dotati (tipo 1059) con chiavi a destinatario effimeri rotanti e recupero post-compromesso automatico. Gli utenti possono generare un keypair ephemeral per sessione senza registrazione o log-in con un’identità persistente tramite NIP-07 estensioni del browser, un NIP-46 segnale remoto, o un nsec. La crittografia opzionale dell’identità del dispositivo-local utilizza password, PIN, password o sblocco biometrico tramite WebAuthn PRF (passkey e biometrico) o PBKDF2 (password e PIN), con la chiave di testo normale non scritta mai su disco mentre la crittografia è attiva. Le chiamate vocali e video utilizzano i pacchetti regalo NIP-17 per la segnalazione e WebRTC per il percorso dei media. Le reazioni dei messaggi usano NIP-25, l’uso di emoji personalizzato NIP-30, e l’applicazione web viene servita come file statici e Cloudflare Pages Funzioni che agiscono come proxy di privacy per relè e media.

21Meetup 1.1.0 lancia i distintivi di presenze firmati Nostr

21Meetup 1.1.0 è un app Flutter per la comunità tedesca Einundzwanzig Bitcoin che registra la frequenza di incontro tramite tag NFC e codici QR rolling. Ogni badge di frequenza è un evento Nostr (kind 21000) firmato dall’organizzatore di incontri utilizzando BIP-340 Schnorr, quindi un partecipante accumula una serie di eventi firmati che attestano incontri specifici a specifiche altezze di blocco. Il codice QR rotante ruota ogni 10 secondi, quindi un badge non può essere coniato da remoto, e il tag NFC è leggibile solo in prossimità fisica. Un punteggio di fiducia viene calcolato localmente dai distintivi raccolti; il punteggio può essere presentato come un codice QR per la verifica durante i trade peer-to-peer. L’app si rivolge alla reputazione della comunità Bitcoin, non a livello generale Nostr social, ma gli eventi distinti sono eventi ordinari Nostr che qualsiasi lettore può verificare.

Nostrord v2.0.0 e v2.1.0 piegare la piscina di relè e guarire zombie WebSockets

Nostrord v2.0.0 è un taglio importante della KMP/WASM Il client Nostr che parla NIP-29, NIP-42, NIP-44, NIP-46, NIP-57, NIP-65 e NIP-98.

v2.1.0 seguito il 7 luglio con la “rimozione della piscina” (PR #176), che unifica la presa di relè concentrata NIP-29 precedentemente separata nella piscina condivisa. Un programma di ricollegamento ora copre tutti i relè, NIP-42 La firma di AUTH è delimitata con la riprovazione, pubblica il fallimento chiuso e riprova sulle razze di richiesta-scarica richiesta in requestPrivateGroupData e fetchGroupPreviews sono chiusi, tipo-10009 utente-gruppo-elenco di fetches batch per relx Le modifiche laterali dell’interfaccia utente sostituiscono la riga “Sending…” con un’icona in linea di controllo dell’orologio e si trasformano in una riga di riprova esplicita. PR #179 è atterrato lo stesso giorno per rilevare zombie WebSockets su Android: reti mobili e modalità Doze uccidere TCP senza una cornice chiusa, così scrive nel buffer socket morto localmente senza gettare e isConnected() rimane vero anche se nulla sarà mai ricevuto. NostrGroupClient ora timbra lastInboundAtMs su ogni frame, acquisisce markDead() (che cancella il frame loop in modo che il normale ricollegamento e resubscribe path run), e probeLiveness() (un REQ qualsiasi relè deve rispondere entro 5 secondi), attivato su OK timeout con zero frame inbound o su mux stale plus socket frame Silence. v2.1.1 spedito un giorno dopo via PR #178 aggiungendo effetti della piattaforma iOS, supporto di test nativo e icone app accanto al lavoro v2.1.0 zombie-WebSocket.

Cambiamenti inediti

rust-nostr aggiunge la scadenza NIP-40 alla confezione regalo e ai costruttori privati di DM

rust-nostr fuso PR #1384 aggiungendo un’opzione expiration a GiftWrapBuilder e PrivateDirectMessageBuilder. La libreria prende un Duration dal chiamante: il tag di scadenza NIP-40 è ancorato al pacchetto regalo randomizzato created_at (created at + durata), che lo decouples dal tempo reale di invio. Lasciare un caller passare un timestamp assoluto trapelare il tempo di invio a un osservatore di relè (sottotrarre la durata e recuperare il tempo di invio originale), in modo che la libreria costruisce il tag internamente dal timestamp di involucro randomizzato. Il tag di scadenza va sull’evento del pacchetto regalo, non sul tipo: 13 sigillo (che NIP-59 richiede di avere tag vuoti). NIP-17 consegna lo stesso valore fino al costruttore di pacchetti regalo di PrivateDirectMessageBuilder. Il cambiamento si chiude problema #1381 e atterra attraverso lo stesso modello di costruttore rust-nostr utilizza per extra_tags. rust-nostr si unì anche PR #1387 consolidando nostr-relay-builder in nostr-sdk, una mossa di workspace-flattening.

Amethyst trascorre la settimana indurendo la sincronizzazione negentropia e aggiungendo la ricerca NIP-50

Amethyst fermello principale ha unito 43 PR in tre temi coerenti. Il filetto più grande è negentropy sincronizza sul limite geode-to-strfry: una modalità di guasto rifiutata che ha usato per tempestare il cliente in un loop di finestra-split ora torna in modo pulito (PR #3480), la dipendenza negentropyKmp si sposta a v1.1.1 ([PR #3475](ZXQ000Q000Q Le collezioni concorrenti senza serrature sostituiscono il precedente modello mutex-per-relè e un UDP socket fix cavalca lungo (PR #3459).

Il secondo thread è NIP-50 infrastruttura di ricerca full-text. Un’interfaccia SearchableEvent atterra in modo che gli eventi possono trasportare i metadati indice direttamente (PR #3452) e le estensioni di ricerca NIP-50 sono ora spogliate prima di querying SQLite FTS in modo che il motore di ricerca locale non singhiozzi più sulla sintassi dell’estensione lato server (PR #3464. I relè di ricerca predefinito vengono centralizzati ([PR #3446] (https://github.com/vitorpamplona/amethyst/pull/3446)).

Il terzo thread è l’integrazione del protocollo per i verticali di nicchia. Il supporto per gli eventi di bird-detection Birdstar (kind 2473) raggiunge un client Android (PR #3473 e gli stati di salvataggio della scheda di memoria PS1 possono essere pubblicati come eventi firmati sul tipo 38192 (PR #3482). Arrotondando la settimana: una impostazione di scrittura auto-applica il testo personalizzato ai messaggi (PR #3450), la visualizzazione delle notifiche desktop viene ridisegnata con i toast nativi del sistema operativo e un filtro condiviso (PR #3457), la colonna dei messaggi raccoglie un blocco della privacy ([PR #3432](ZXQ000

Buzz continua ad indurire il relè e definisce il tipo 44200 per le metriche di svolta dell’agente

Buzz (il progetto precedentemente chiamato Sprout) ha atterrato 123 PR si è fuso nella finestra dal 1 luglio al 7 luglio. Due fili portano la maggior parte del peso. Il primo è un nuovo tipo di evento per la telemetria dell’agente: [PR #1441] (https://github.com/block/buzz/pull/1441) definisce le metriche di rotazione dell’agente crittografato di NIP-AM durevoli come 44200, che atterrano la telemetria come evento firmato gli archivi di relè dell’utente, mantenendo metriche sull’infrastruttura di proprietà dell’utente. Un archivio locale per il tipo segue (PR #1555), il percorso di rimozione è fatto atomico (PR #1562), e il nome del modello è filettato attraverso il percorso di emissione in modo che i lettori a valle possano distinguere quale modello prodotto che gira (PR #1564.

Il secondo thread è le prestazioni del relè. La spedizione post-commissione è differita e viene evitato un clone di verifica (PR #1453), i viaggi rotondi DB ingeriti e fan-out sono in batch con gocce di ack misurate di p99 del 7 al 16 per cento e gocce di coda di p999 del 29 al 53 per cento rispetto alla punta precedente ([PR #1454] (ZXQ0001QXQXQXQ))) Oltre al lavoro perf, un set di icone dello spazio di lavoro per comunità che gli amministratori configurano e il relè serve tramite NIP-11 estende il documento di informazioni di NIP-11 con una superficie di personalizzazione per comunità (PR #1463), i proprietari di agenti possono eliminare i messaggi del loro agente in corrispondenza

Divine Video collega la verifica della firma del relè e un’estrazione NostrConnect

L’applicazione mobile di Divine Video (https://github.com/divinevideo/divine-mobile) ha unito 97 PR nella finestra, e il thread di Nostr-facing è l’indurimento del limite di fiducia più la pulizia dell’autenticazione. PR #5774 verifica le firme degli eventi di relè in entrata, chiudendo una classe di bug trust-in-the-relay; PR #5828 crittografa il token di spinta FCM nel tipo di evento di deregistrazione tipo di tipo di tipo di 3080, in modo che il dispositivo dell’utente token di token di token di token di cancellazione si blocca appare in chiaro Sul lato di autenticazione, PR #5826 estrae una NostrConnectCoordinator per il flusso nostrconnect://, pulendo il NIP-46 percorso di codice del bunker inizializzato del client prima di un più ampio refattore auth tracciato sotto [problema #4741](ZXQ000QXQ

Zap Cooking frontend ha unito 18 PR nella finestra lungo un tema: rendere le superfici Nostr auth recuperare dal fallimento. PR #503 corregge il login del bunker con un handshake di connessione esplicita, la gestione di authUrl e la navigazione degli errori in modo che un utente che collega un segnale esterno veda un messaggio di errore reale sul fallimento in cui il taglio precedente ha appeso la schermata di login. Un filetto di funzionalità separato atterra NIP-50 ricerca di ricette full-text tramite il retro del relè di ricerca dei nostrirchives (PR #483), lasciando un’interrogazione utente ricette attraverso il relè corpus senza un indice client-side. Contenuti-rendering polacco navi insieme: contenuto citato-nota e media ora si espongono direttamente nella nota principale sostituendo il precedente fallback sepolto-link (PR #491), le anteprime del link e il terreno di dimensionamento dell’hashtag (PR #492), le domande di ricerca multi-parola funzionano ([PR #482](X

swift-nostr-client v0.6.0 progredisce verso un primo taglio stabile

yysskk/swift-nostr-client spedito v0.6.0 insieme a 30 PR unite. La libreria Swift Nostr si avvicina ad una prima superficie stabile API per i client Swift Nostr che evitano di collegare gli strumenti MDK o MarmotKit.

Nostr Applet Protocol (NAPS) stringe NAP-OUTBOX Routing e Fanout

NAPS ha avuto una settimana di pulizia significativa, soprattutto in NAP-OUTBOX. L’intestazione è confini più stretti: meno routing controllato dal chiamante, meno dettagli del relè trapelato, e una forma di risultato evento condivisa che può trasportare suggerimenti relè e sidecar delle risorse, digitando NAP-RESOURCE. Anche la pubblicazione è più chiara: regole esplicite di outbox, inbox e relay fanout. Effetto netto: meno ambiguità, migliore interoperabilità.

Napplet Toolchain Tightens Protocol Alignment and Ships its CLI

Questa settimana, i pacchetti di Napplet si sono spostati da “utile SDK” verso una catena di strumenti di protocollo più stretta. La grande storia è allineamento con le specifiche NAP dal vivo: NAP-COUNT query support, Il ciclo di vita runtime di OutBOX, e RelayEventResult sidecars tutte atterrate, rendendo le letture e gli abbonamenti più precisi. Diversi domini sono stati affinati anche: supporto del registro CVM, buste di errore DM, contesto di sessione MEDIA, campi di conteggio LISTS, risultati del profilo COMMON e lo schema htree: RESOURCE. Su tooling, il nuovo @napplet/cli è una pietra miliare importante, aggiungendo la scoperta della configurazione, implementando la pianificazione, firmando, caricamenti Blossom e la generazione manifesta. Infine, il preludio shim iniettabile host e lavoro di prontezza JSR hanno reso lo stack piÃ1 facile da iniettare, pubblicare e verificare.

primal-android estende la superficie del segnale remoto

Primal Android ha unito 18 PR nella finestra. Sul lato Nostr, PR #1075 implementa i metodi switch_relays e logout per il ruolo del segnale remoto dell’app, estendendo la superficie del segnale NIP-46 di Primal. Il resto è UI lucidare attraverso la barra superiore e inferiore Home, Esplora suggerimenti e la schermata del profilo.

Wisp aggiunge un commutatore multi-account e test di parser Blossom

Wisp ha unito 9 PR. PR #604 aggiunge un switcher multi-account con un percorso di cancellazione esplicito sul flusso del conto aggiuntivo.

TAO e Wired sollevano il segnale PoW a 21 bit e le radici di superficie fresca-PoW

smolgrrr/TAO e smolgrr/Wired (lo stesso set di commit è atterrato in entrambe le repos) ha unito 13 PR. Questo è il secondo client Nostr questa settimana per appoggiarsi su NIP-13 come filtro di prima classe per il contenuto generato dall’utente, che completa il PoW canalizzato di Bitchat.

keep-android lucida NIP-46 UX e atterra una correzione TOCTOU

privkeyio/keep-android spedito v1.1.5 insieme a 13 PR fusi, poi v1.1.6 l'8 luglio pinning the sottostante mantenere il nucleo di v0.5.0. Keep è una volta mobile (copertaX29 v1.1.5 era UX polish sul flusso di sfida NIP-46. v1.1.6 chiude una gara di check-then-set (TOCTOU) in set_active_share dalla cassa di mantenimento sottostante, supera l’URL e il metodo che sono autorizzati sul NIP-98 HTTP-auth richiesta di approvazione in modo che un utente possa vedere quello che stanno firmando e commuta l’errore ZXQ0014QXXXXXXXZturn Un test strumentato copre l’interruttore di eliminazione del flusso di approvazione NIP-55. Le caratteristiche CLI v0.5.0 che sono arrivate con il rilascio sottostante (threshold-OPRF sbloccare, software DKG, HD FROST portafogli) non sono ancora in superficie nell’applicazione Android; v1.1.6 fornisce solo le correzioni di sicurezza.

Heartwood spedisce il ponte di firma relay-to-serial

forgesworn/heartwood v0.7.0 atterra il ponte di firma relay-to-serial che è stato in volo la scorsa settimana, cablaggio del piano dati HSM-mode per Bray’s serial-signer path PR #11 è il ponte stesso, [PR #13](XQXQXQX000

SafeBox pubblica un report sul progresso di Fase 3 e un runbook della prigione FreeBSD

SafeBox è una volta di dati portatile privata su Nostr che combina [NIP-47] (/it/topics/nip-47/) Nostr Wallet Connect, nAuth, nembed, e trasferimento di record via relè su QR e NFC in un servizio gestibile dall’operatore. A July 2026 progress report pubblicato il 6 luglio segna la Fase 3 come sostanzialmente completa: 49 commit sono atterrati dal rapporto di aprile, portando il repository a 1,136 commit, e i quattro impegni di ingegneria di Fase 3 (indurire gli esperimenti di Fase 2, sostenere istanze interoperabili, preparare per scala, aggiungere la disciplina di prodotto commerciale) sono ampiamente forniti. Il rapporto inquadra il prossimo passo come pilota delimitato, e rivela che un fornitore di telecomunicazioni sotto NDA sta esplorando un pilota di registri sanitari su SafeBox.

Il concreto Nostr-facing lavoro è atterrato in precedenza in Fase 3 ed è riassunto nel rapporto: mutando le azioni NWC sono ora in coda per evitare le razze di prova, Lightning fallito fonde protegge le prove prima di tornare, NWC ascoltatori di lunga durata aggiorna proattivamente in modo che una sessione sopravviva alla sua soglia di idle; il comportamento precedente è stato uno stallone ZXX Lo scambio record di QR e NFC ha ottenuto una specifica di flusso unificata che copre le modalità di presentazione, rappresentate dal mittente, e cross-device con la più chiara gestione KEM (Key Encapsulation Mechanism) e la riproduzione di protezione attraverso la libreria Open Quantum Safe. Il commit in-window è 6866dae, che aggiunge un FreeBSD dispiegamento della prigione e liboq costruiscono runbook accanto a una specificazione dell’apparecchio FreeBSD, che documenta le istantanee ZFS, l’isolamento del jail

Il rapporto annuncia inoltre [OpenETR] (https://github.com/trbouma/openetr) come un spin-off distinto che applica l’architettura crittografica-control-plus-portable-records di SafeBox ai record trasferibili elettronici: fatture di lading, ricevute di magazzino, note promissory e certificati. Il repo di OpenETR ha visto 7 commit il 7 luglio compreso ea612a9 che separa l’attestazione dal core record, ca153a3 sulla gestione dei mandati contro gli effetti, e ba84b61

Protocollo lavoro e aggiornamenti NIP

Merged: NIP-51 e NIP-37 allineano il nome tipo 10013

PR #2404 è una soluzione di consistenza solo prosa. In NIP-37, il tipo 10013 è chiamato Relay List for Private Content; in [NIP-51] (/it/topics/nip-51/) sotto Draft relays, lo stesso tipo è stato descritto con parole diverse. NIP-51 utilizza ora il nome NIP-37 per lo stesso tipo di evento. Nessun cambiamento di comportamento del filo e nessun nuovo tag semantics; il valore è che NIP-51 è la spec dell’ombrello per gli eventi a forma di lista e NIP-37 è il follow-up del contenuto privato e il nome sallineato tra i due rende facile da perdere che descrivono lo stesso tipo.

Aperto: NIP-AD Nostr Web Indirizzi tramite la ricerca ben nota

PR #2406 si apre come il successore di un PR chiuso #2393 con una bozza di spec completa a AD.md. NIP-AD definisce gli URL web che portano una controparte Nostr opzionale. Un client che vede un URL come https://golf.com/players richiede https://golf.com/.well-known/nostr.json?ad=/players, che restituisce un percorso di mappatura degli oggetti JSON a coppie {filter, relays}. Il filtro restituito è un filtro standard NIP-01 (generi, autori, #d, limit, ecc.), e i nomi di array relays che relays il client dovrebbe query. Con "limit": 1 l’URL si risolve in un singolo evento; senza di esso, in un elenco. In un normale browser web l’URL rende HTML come qualsiasi altro URL, quindi lo stesso dominio può servire utenti web e clienti Nostr da un percorso canonico. I casi di utilizzo indicati includono NIP-29 nomi di gruppo che risolvano ad un evento di tipo 39000 su un relè specifico (rimozione della necessità di un’agricoltura di gruppo id), NIP-5A nsite lookups, feed ospitati che pubblicano un filtro {"ids": [...]}, rendering nativo di eventi Il riuso .well-known/nostr.json più il layout path-as-object-key è scelto in modo che il risolutore possa essere un file statico.

Aperto: NIP-86 gestione del reclamo per i codici di invito

PR #2408 propone l’aggiunta di tre metodi a NIP-86: listclaims (parami [], restituisce una serie di NIP-43 codici di invito), ZXQ000Q000 Oggi NIP-86 permette ad un amministratore relè di gestire gli utenti e gli incarichi di ruolo, ma non ha una superficie di codice invito. Il caso di utilizzo dell’autore PR è onboarding community-relay: un amministratore crea un codice di invito associato a un ruolo, raccoglie il pagamento prima che l’identità dell’utente sia creata, consegna il codice di invito all’utente, e un robot ascolta per il tipo risultante 28935 evento di rivendicazione sul relè e auto-assegna il ruolo. I tre metodi permettono che il flusso avvenga interamente attraverso la gestione del relè RPC.

Aperto: colore del ruolo come (h, s, l) tuple

PR #2402 cambia il formato di colore del ruolo in NIP-43 da un singolo valore hue (0 a 360) a una tupla di hue (0 a 360), saturation (0 a 1), e lightness (0 a 1). Le stringhe vuote sono consentite per qualsiasi componente in modo che i clienti possano fornire i propri default per una tavolozza coerente, e il testo spec raccomanda di fornire solo hue a meno che non si desideri un colore specifico come l’argento. I filetti di cambiamento attraverso NIP-86 nello stesso PR: createrole e editrole ora prendere [id, label, description, [h, s, l], order]; la firma precedente ha portato un parametro a singolo colore nella stessa slot. La motivazione è che l’hue da solo costringe i clienti a scegliere saturazione e leggerezza per l’operatore, così diversi clienti rendono lo stesso ruolo a intensità visibilmente diverse.

Open: NIP-80 comprovata provenienza dei media

PR #2409 apre NIP-80, formato evento per la provenienza dei media ancorata nell’hardware di cattura. Una fotocamera firma ogni foto al momento della cattura e pubblica la prova per relè keyed dal contenuto stesso, quindi la verifica sopravvive a metadati stripping, re-hosting e takedown della piattaforma. La proposta definisce sei nuovi tipi di eventi: tipo 1080 per le attestazioni di cattura, tipo 1081 per le attestazioni di derivazione che coprono le operazioni di ridimensionamento, coltura, ricompressione o riformulazione (con modalità di rivelazione o opzione zero-knowledge), tipo 1082 per le revocazioni (eventi normari, permanenti, auto-scoped, monotonici), tipo 11080 per gli annunci di dispositivo, tipo 31080 per le suddivisioni anonimesse e tipo di dispositivo, e tipo sperimentale 31081 per un dispositivo per una specie per un dispositivo per un tipo di attestazioni per un insieme per un tipo sperimentale per un tipo di attestazioni per un tipo di corrispondenza per un insieme di attestazioni. I primitivi riutilizzati includono NIP-94 x-tag semantics, NIP-92 imeta, NIP-65 per la scoperta della revoca, [Blossom](XQX000 Il modello di firma accoppia una chiave di dispositivo BIP-340 con una chiave di ECDSA hardware perché gli elementi di sicurezza tradizionali non producono ancora firme BIP-340 (Microchip ATECC608 supporta P-256, NXP SE050 supporta secp256k1 ma solo moduli ECDSA, TPM 2.0 e Infineon OPTIGA Trust M cover P-256/RSA, Apple SecureBox Pnclave e Android6). L’ambito dichiarato esplicitamente non tenta di dimostrare che la scena è reale: un’attestazione dimostra che questa immagine esatta è venuta da questo dispositivo a circa questo tempo ed è stata modificata solo in modi dichiarati, provabili, e la specifica vieta ai clienti di collassare i risultati in un distintivo “autentico”. Un prototipo di lavoro OpenVeilCam, una fotocamera Rust runtime per Raspberry Pi utilizzando l’elemento sicuro ATECC608, è in fase di aggiornamento per pubblicare i tipi di evento proposti insieme a un verificatore standalone.

Aperto: Indurimento paginazione NIP-01

PR #2407 aggiunge una sottosezione “Pagination & limit” a NIP-01. Le regole concrete: un relè che impone un massimo limit MUST lo imposta più grande del maggior numero di eventi che condividono un singolo created_at nel suo database, quindi nessun secondo può riempire una pagina e la paginazione dello stallo. I clienti che riprendono le richieste MUST ripetono con until = oldest (inclusive) e MUST deduplicate da id (dal momento che il secondo più vecchio è ri-fetched ogni round), e la paging è completa quando un round non produce nuovi eventi dopo la deduplica. Se una pagina completa ha eventi più vecchi e più recenti che condividono uno created_at, il client DOVE riprovare che secondo con un limit più grande, e se il relè blocca il più grande limit e restituisce ancora una pagina limitata a un secondo, il client DEVE o avanzare con until = oldest - 1 (trattando eventi non recuperati come caduto) o aborti. Normale paging NON impostare limit; il massimo relè è autorevole, e un valore più piccolo reintroduce la stalla. Aumentare limit per drenare un secondo bloccato è l’unica eccezione. Questo problema è risolto perché un ingenuo since/until cursore manca o eventi con timestamp duplicati o li rielaborazione, e l’attuale testo NIP-01 non dice a entrambi i lati come sfuggire alla trappola.

NIP Deep Dive: NIP-13 (Proof of Work)

NIP-13 definisce un meccanismo di prova di lavoro per gli eventi Nostr. Esiste perché lo spam in stile e-mail è banale per produrre su una rete di relè pubblico: chiunque può generare un keypair e inondare un argomento, e non c’è alcun costo economico per evento. NIP-13 permette a un autore di eventi di imporre un costo computazionale per caso che uno spammer dovrebbe pagare in aggregato ma un mittente regolare paga solo una volta per messaggio. I relè e i clienti possono quindi richiedere o preferire eventi che soddisfano una soglia di difficoltà.

Il meccanismo

Un autore di eventi sceglie un target di difficoltà espresso in bit e mine l’id dell’evento (l’hash sha256 dell’evento serializzato) fino a quando non ha almeno che molti puntali zero. Poiché l’ID dell’evento include il timestamp created_at, i tag e il contenuto, l’estrazione mineraria richiede di cambiare qualcosa nel corpo dell’evento per cercare lo spazio hash. NIP-13 definisce un tag nonce per esattamente questo scopo:

["nonce", "<nonce_value>", "<target_bits>"]

La nonce_value è qualsiasi stringa che sceglie il minatore; la target_bits è la difficoltà a cui il minatore si è impegnato. Un verificatore conta i principali zero bit dell’evento id e confronta target_bits. Lo target_bits nel tag è un reclamo, e un verificatore misura l’effettivo numero di primo zero dell’id per confermarlo.

Il numero di bit zero leader in un output casuale sha256 segue una distribuzione geometrica: ogni bit aggiuntivo raddoppia il lavoro previsto. 8 bit media 256 hash tentativi, 20 bit media circa un milione, e 28 bit media circa 268 milioni. L’obiettivo 8 bit di Bitchat per i messaggi geohash-channel costa sotto un millisecondo di CPU sull’hardware moderno e completa sotto qualsiasi latenza percettibile. Il default di TAO e Wired è di circa due milioni di tentativi di hash per post, che è veloce su un computer portatile ma costoso in scala per una fattoria del robot. NIP-13 non richiede una difficoltà; ogni relè e cliente sceglie la propria.

Esempio evento

Un minimo NIP-13-mined tipo-1 nota sembra:

{
 "id": "000000000e9d97a1ab09fc381030b346cdd7a1a8a6f27c9c88f68c8b9d0f6c8a",
 "pubkey": "82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2",
 "created_at": 1720368000,
 "kind": 1,
 "tags": [
 ["nonce", "72847", "28"]
 ],
 "content": "hello, this cost me 28 bits of PoW",
 "sig": "b1a5c9c74cff59f8a48e5c3b3d8e1c8e7e2c1d4a8e2b9f7d1c3e8b4f6a2c8d1e9f4b3c7a1d8e5b2f9c6a3d7e1b8f4c9a2d6e3b7f1c8a4d9e2b5f8c1a7d4e6b9f3c2"
}

Lo id inizia con sette zero esadesi (28 bit zero principali, corrispondenti allo target_bits nel tag nonce). Il minatore ha variato la nonce_value 72847 fino a quando l’id ha raggiunto l’obiettivo. Un verificatore hash l’evento serializzato e conferma che l’id ha almeno 28 bit zero principali, quindi verifica la firma. NIP-13 non aggiunge nuovi campi; aggiunge il tag nonce e limita il conteggio a zero bit dell’id.

Dove viene utilizzato

La versione 1.5.4 di Bitchat utilizza PoW a 8 bit su messaggi geohash-channel tipo 20000: in uscita invia il tag prima di pubblicare e in entrata eventi con convalidato PoW rilassare il limite di assunzione per-sender. TAO e Wired utilizzano PoW a 21 bit come la soglia di default post-segnale e le radici di mangimi di superficie da attività PoW fresca, trattando PoW come segnale di graduazione della linea temporale. cagliostr applica NIP-13 allo strato di relè, rifiutando gli eventi sotto una soglia. NoStrudel espone un’impostazione di estrazione client PoW per gli autori che vogliono segnalare il filtraggio dei clienti. Damus e Amethyst calcolano i bit dello zero durante la visualizzazione degli eventi, permettendo a un utente di vedere l’impegno PoW sulle note. Coracle espone PoW sia per l’estrazione mineraria che per il filtraggio. NDK e nostr-tools espongono PoW ai consumatori di biblioteche.

La proprietà di progettazione che modella l’implementazione di NIP-13 è che PoW è impercettibile: una pretesa di target_bits conta come prova solo quando l’id ha molti zeri principali, e una contraffazione richiede di ridare il lavoro. Questa proprietà consente a Bitchat di utilizzare in entrata PoW come un relax tasso-limite anche quando uno spammer rivendica un’alta difficoltà; il controllo è un conteggio hash, non una decisione di fiducia. La proprietà complementare è che PoW non impegna il minatore a qualsiasi specifico pubkey o contenuto; uno spammer può ancora scegliere di mine a 8 bit e masterizzare la computazione, ma la computazione è un costo reale. NIP-13 sposta il problema spam da “impossibile” a “quantificabile” e consente ai clienti di impostare il proprio prezzo.

NIP Deep Dive: NIP-40 (Expiration Timestamp)

NIP-40 definisce un tag expiration che istruisce un relè e un client che un evento dovrebbe essere considerato scaduto dopo una data timestamp Unix. Esiste perché gli eventi Nostr sono altrimenti permanenti: una volta che un evento firmato atterra su un relè, l’unico modo per rimuoverlo è un evento di cancellazione NIP-09, e anche allora un relè può mantenere l’originale. NIP-40 permette a un autore di dichiarare in tempo di pubblicazione che un evento è di breve durata, e chiede relè per smettere di servire e clienti per smettere di visualizzarlo dopo il timestamp.

Il meccanismo

Un autore aggiunge un tag expiration a un evento:

["expiration", "<unix_timestamp>"]

Il timestamp è Unix secondi. Un relè MAY rifiuta eventi la cui scadenza è già in passato all’ingestione, MAY smettere di servire eventi la cui scadenza è passata, e SHOULD rispettare la scadenza dichiarata dell’autore. Un client SHOULD nascondere gli eventi scaduti dall’utente. NIP-40 non richiede il relè per eliminare l’evento, e non sovrappone NIP-70 semantica protetta-evento; è un suggerimento più un contratto morbido.

Il tag vive sull’evento stesso (o nel caso di messaggistica avvolta, sull’involucro esterno). NIP-40 non definisce la semantica cancellata; l’evento rimane un evento firmato che chiunque lo abbia può ancora leggere. Ciò che NIP-40 offre è un’attesa coordinata che il relè e il cliente smetteranno di navigare dopo la scadenza. Questo rende NIP-40 utile per i post effimeri, annunci tempestivi, note di evento dal vivo che dovrebbero smettere di essere serviti dopo l’evento, e messaggi diretti NIP-17 che non dovrebbero soffermarsi oltre un orizzonte dichiarato.

Interazione con confezione regalo

Il PR rust-nostr che è atterrato questa settimana ([PR #1384] (https://github.com/rust-nostr/nostr/pull/1384)) è uno studio di caso in come NIP-40 interagisce con NIP-59 confezione regalo. NIP-59 definisce una busta a due strati: un evento tipo: 13 “seal” firmato dalla chiave reale del mittente e un evento tipo:1059 “gift wrap” firmato da una chiave effimera. Entrambi gli strati hanno randomizzato i valori created_at, fino a 48 ore prima del tempo reale di invio, quindi un osservatore di relè non può recuperare il vero timestamp di invio. NIP-59 manda che il sigillo ha tag vuoti.

Questo mandato è il motivo per cui il tag di scadenza deve andare sul pacco regalo e rimanere fuori dal sigillo, e perché ancorare il tag al tempo reale di invio sarebbe sconfiggere la privacy dei tempi del pacco regalo: se un chiamante passa un timestamp di scadenza assoluta, un osservatore sottrae il TTL previsto del chiamante e recupera il tempo reale di invio. La decisione di progettazione di rust-nostr è di esporre lo API come Duration dal chiamante, quindi calcolare expiration = wrap.created_at + duration all’interno della libreria. created_at dell’involucro è già randomizzato all’interno della libreria, quindi il timestamp di scadenza eredita la stessa randomizzazione e non perde il vero tempo di invio.

Esempio evento

Un esempio minimo di NIP-40 su una nota tipo-1:

{
 "id": "1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b",
 "pubkey": "82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2",
 "created_at": 1720368000,
 "kind": 1,
 "tags": [
 ["expiration", "1720454400"]
 ],
 "content": "this note expires in 24 hours",
 "sig": "d2e5b8a1c4f7b0d3e6a9c2f5b8d1e4a7c0f3b6d9e2a5c8f1b4d7e0a3c6f9b2d5e8a1c4f7b0d3e6a9c2f5b8d1e4a7c0f3b6d9e2a5c8f1b4d7e0a3c6f9b2d5e8a1"
}

created_at è il timestamp Unix della pubblicazione; il tag di scadenza dice che l’evento dovrebbe smettere di essere servito 86.400 secondi (24 ore) più tardi. Un relè che rispetta NIP-40 smette di restituire questo evento a REQs dopo 1720454400, e un client che rispetta NIP-40 lo nasconde dall’utente dopo quel tempo.

Dove viene utilizzato

I costruttori rust-nostr (GiftWrapBuilder, PrivateDirectMessageBuilder) ora espongono la scadenza come parametro Duration di prima classe. NDK espone un helper di scadenza per i costruttori di tipo 1 e DM. nostr-tools ha una coppia getExpiration e isExpired per la lettura e il rafforzamento del tag. strfry, nostr-rs-relay, khatru e altre implementazioni di relè rispettano NIP-40 nella gestione di REQ (rigettura o o omissione di eventi scaduti a seconda della politica dell’operatore). Damus, Amethyst, noStrudel, Coracle e Primal tutti gli eventi scaduti dal loro rendering timeline. client di Live-attività come zap.stream utilizzare NIP-40 sugli eventi di chat tipo-1311 associati in modo che una chat dal vivo si ferma persistente dopo la fine del flusso.

La proprietà di progettazione che atterra NIP-40 pulito nella maggior parte delle implementazioni è che è opt-in per evento e non richiede distribuzione coordinata. Un autore può aggiungere il tag oggi; un relè che onora che ottiene un set di lavoro più pulito; un relè che lo ignora non fa peggio di prima; e un cliente che nasconde eventi scaduti dà all’autore ciò che hanno chiesto. Il cambiamento rust-nostr di questa settimana rafforza che il posizionamento del tag è importante tanto quanto la sua presenza: in una busta di conservazione della privacy come l’involucro regalo NIP-59, il tag siede sullo strato il cui timestamp è già randomizzato, e la superficie API impedisce a un chiamante di perdere accidentalmente un vero timestamp di nuovo nella fascia.

E’ tutto per questa settimana. Costruire qualcosa o avere notizie da condividere? Raggiungere via NIP-17 DM o trovarci su Nostr.

Nostr Compass #29

Wed, 01 Jul 2026 00:00:00 +0000

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

Questa settimana: FIPS v0.4.0 introduce un trasporto sulla mixnet Nym, la scoperta mDNS facoltativa sulla LAN, il rekey senza interruzioni in caso di perdita di pacchetti e una revisione del data plane, mantenendo la compatibilità wire con v0.3.0. Whitenoise Linux emerge come client Marmot desktop in Rust e Slint, con una proposta di protocollo per spostare gli effetti dei messaggi in un evento kind 9 dedicato. CustID v0.1.10-beta debutta come cassaforte mobile per identità protetta dall’hardware, che opera da signer remoto NIP-46 e risponde tramite NFC alle richieste di accesso fisico. myco inaugura la condivisione peer-to-peer di nsite sulla mesh FIPS con un nuovo trasporto BLE L2CAP nella v0.1.0. Nostr Codex Phone debutta come superficie di controllo Android per un assistente di programmazione Codex locale, raggiunto tramite DM Nostr cifrati. Il ramo non ancora rilasciato di Amethyst aggiunge il parsing degli application handler NIP-89, un feed Git Repositories per NIP-34 e una sezione Discover per nSite e napplet. Notedeck implementa NIP-37, NIP-52 e NIP-22 in una sola settimana. Applesauce pubblica 12 release coordinate dei suoi sottopacchetti, con helper nbunksec per NIP-46 e un aggiornamento del wallet a Cashu-ts v4. Meiso v1.4.0 introduce Shared-Key Collaborative Lists su eventi indirizzabili kind 35000. Il repository NIPs ha integrato cinque PR, fra cui un evento Relay Roles, la rimozione del limite di 65.535 byte di NIP-44, la semantica dei fork di NIP-34, i metadati client di NIP-46 e un metodo signevent per NIP-86. Gli approfondimenti riguardano NIP-86 (API di gestione dei relay) e NIP-89 (application handler consigliati).

Storie principali

FIPS v0.4.0 introduce il trasporto sulla mixnet Nym, la scoperta mDNS e una revisione del data plane

FIPS è una rete mesh peer-to-peer privata e auto-organizzata per Nostr, nella quale i nodi si scoprono e instradano il traffico senza infrastruttura centrale. FIPS v0.4.0 porta un trasporto sulla mixnet Nym, la scoperta mDNS facoltativa sulla LAN, una revisione del data plane, il rekey senza interruzioni in caso di perdita di pacchetti, una TUI fipstop riscritta su un harness di snapshot del rendering, un piano di osservabilità fuori dall’hot path e nuovi target di packaging apk per OpenWrt e flake per Nix. Tutto resta compatibile a livello wire con v0.3.0, così le mesh miste continuano a interoperare durante un aggiornamento progressivo. Due nuovi trasporti per la scoperta dei peer sono al centro della release. Un nuovo trasporto in uscita sulla mixnet Nym instrada il traffico FIPS attraverso un proxy SOCKS5 nym-socks5-client, mescolandolo nella rete di cover traffic di Nym affinché gli osservatori a livello di collegamento non possano correlare quali peer della mesh stiano comunicando; un esempio examples/sidecar-nostr-mixnet-relay mostra come esporre un relay Nostr locale attraverso quel percorso. Sulla LAN, la nuova scoperta mDNS è esplicitamente facoltativa e pubblicizza solo un identificatore di nodo e una porta, senza chiavi o metadati dell’utente.

Il data plane è stato rielaborato per aumentare il throughput di un singolo nodo. La cifratura e la decifratura per peer ora vengono eseguite da task worker dedicati fuori dal ciclo di ricezione, così un peer molto attivo non può serializzare la crittografia dell’intero nodo. Il percorso di invio Linux usa generic segmentation offload e, dove disponibile, un socket UDP connesso; l’hot path di ricezione evita le copie dei buffer effettuate in precedenza per ogni pacchetto, mentre macOS riceve una modalità di ricezione in batch recvmsg_x analoga al batching Linux recvmmsg introdotto nella v0.3.0. L’intera superficie di lettura show_* per fipsctl e fipstop ora viene servita da uno snapshot per tick, pubblicato in un ArcSwap lock-free dal task che accetta le connessioni di controllo, così le richieste degli operatori ricevono risposta rapidamente anche quando il ciclo di ricezione del nodo è occupato. Una nuova query show_metrics di soli contatori, esposta come fipsctl stats metrics, consente lo scraping Prometheus senza costi sull’hot path.

Il rekey delle sessioni FMP e FSP ora avviene senza interruzioni in presenza di perdita e riordinamento dei pacchetti in entrambe le direzioni: i frame in ingresso vengono autenticati rispetto alla sessione in attesa prima che il passaggio con K-bit la promuova, così un frame obsoleto o contraffatto non può mandare fuori strada il rekey; la ritrasmissione del messaggio 1 del rekey è limitata, l’heartbeat che rileva un collegamento interrotto tiene conto del rekey e le corse dovute all’avvio simultaneo su collegamenti ad alta latenza vengono desincronizzate con jitter simmetrico. La TUI fipstop è stata ricostruita su un harness di snapshot del rendering che verifica l’esatta griglia di testo e lo stile di ogni cella per ciascuna vista, usando output predefiniti del socket di controllo. Arrivano anche nuovi target di packaging: un .apk per OpenWrt 25+ costruito senza SDK, riutilizzando la cross-compilazione .ipk esistente e il payload del filesystem installato, e un flake.nix nella radice del progetto che compila dal sorgente tutti e quattro i binari (fips, fipsctl, fips-gateway, fipstop) su Nix/NixOS con la toolchain fissata.

Whitenoise Linux emerge come client Marmot desktop

Whitenoise Linux è un client Marmot desktop: messaggistica di gruppo MLS su relay Nostr, distribuita come singolo binario Rust con un’interfaccia Slint che conserva ogni segreto in una cassaforte cifrata con password.

Il filone più rilevante di questa settimana propone di trasportare gli effetti dei messaggi Whitenoise come eventi kind 9 dedicati che fanno riferimento al messaggio padre. L’attuale formato wire aggiunge alla fine del corpo un marcatore come dmfx:sparkle, sporcando il testo per qualsiasi renderer che non conosca questa convenzione. Spostare gli effetti in eventi propri mantiene pulito il testo dei messaggi e apre una questione progettuale che l’intero stack Marmot dovrà affrontare: convenzioni inline nel corpo oppure eventi sidecar per le funzionalità avanzate facoltative.

CustID debutta come cassaforte mobile per identità con NIP-46 e richieste via NFC

CustID v0.1.10-beta è la prima beta pubblica di CustID, una cassaforte mobile per identità costruita su Nostr e sul protocollo SISTR. CustID memorizza più identità Nostr in un archivio sicuro protetto dall’hardware, opera come signer remoto NIP-46 per altri client e risponde a richieste di accesso fisiche e online tramite NFC e codici QR.

La beta è completa nelle funzionalità del signer NIP-46 e del flusso challenge-response NFC; i flussi di accesso basati su zero-knowledge proof restano un traguardo futuro. Questa release elimina inoltre il livello keep-alive NIP-65 in background dell’app, che apriva un WebSocket per profilo per ciascun relay di lettura e acquisiva kind poi scartati immediatamente dal client. Ora restano attivi in background soltanto i socket NIP-46 che trasportano le notifiche delle richieste di firma: è la correzione che rende praticabile l’uso di CustID come bunker per altri client su un telefono.

myco inaugura la condivisione peer-to-peer di nsite sulla mesh FIPS

myco v0.1.0 è comparso questa settimana, il 27 giugno, e ha raggiunto v0.1.0 il 1° luglio. myco è un’app Android in Rust che installa applicazioni provenienti dalle persone vicine: condivisione peer-to-peer di nsite su una mesh FIPS, attraverso qualsiasi trasporto supportato dalla mesh (UDP, TCP, Tor, Bluetooth), funzionante interamente offline. Il progetto abbina direttamente FIPS come substrato di trasporto al formato di eventi per siti web statici di NIP-5A come payload, consentendo a un’app distribuita come nsite di spostarsi fra peer della mesh senza dipendere da relay o HTTP.

La v0.1.0 aggiunge un percorso radio Bluetooth L2CAP, così due telefoni con FIPS installato possono collegarsi in peer tramite BLE senza alcuna rete, oltre a uno speedtest per peer e alla condivisione attivata via NFC dal bottom sheet Circle dell’app. myco è pubblicato anche su Zapstore per l’installazione diretta.

Nostr Codex Phone debutta come superficie di controllo mobile per un worker Codex locale tramite Nostr

Nostr Codex Phone v0.1.122 debutta questa settimana come client Android che controlla un worker locale dell’assistente di programmazione Codex tramite messaggi diretti Nostr cifrati. L’app supporta più sessioni di repository, trascrizione vocale, sessioni worker instradate, upload di media su Blossom e risposte vocali facoltative, così uno sviluppatore che esegue un worker Codex a casa può inviare richieste dal telefono ovunque questo abbia accesso ai relay.

Il progetto è un diretto parente di CodeDeck, presentato nel numero 28. Entrambi portano su un trasporto Nostr i flussi di programmazione agentica con DM cifrati ed entrambi usano Nostr come livello di associazione e messaggistica che permette a un telefono di raggiungere un worker domestico senza aprire varchi nella rete. L’uso di Nostr come control plane per agenti locali sta diventando uno schema consolidato.

Coop Mobile pubblica le sue prime build con versione

Coop Mobile v0.2.1 e v0.2.2 sono uscite questa settimana come prime build con versione di Coop Mobile, un client Android per messaggi diretti cifrati NIP-17. Le due release migliorano la sicurezza contro i crash durante il parsing dei messaggi e la gestione dei QR e cancellano tutti i dati memorizzati al logout.

Amethyst sviluppa un’interfaccia consapevole di NIP-89, un feed Git Repositories e una sezione Discover per napplet

Il ramo principale di Amethyst ha sviluppato diverse nuove superfici questa settimana. Un feed Git Repositories trasforma i repository NIP-34 in una categoria consultabile della timeline Android, filtrabile per community e autore, abbinata a un browser git smart-HTTP che legge contenuti e commit dei repository senza uscire dall’app. L’host per napplet ha ricevuto una sezione Discover che elenca web app curate insieme agli nSite e ai napplet seguiti, ricavati dagli eventi handler NIP-89 e dagli eventi site NIP-5A. La visualizzazione delle note ora rivela quale app Nostr ha creato un evento tramite i tag NIP-89. Sul fronte della sincronizzazione arriva il supporto alla negentropy NIP-77, con riconciliazione in streaming e finestre created_at automatiche per aggirare i limiti ai risultati imposti dai relay, riducendo la banda necessaria a mantenere sincronizzati con un relay grandi insiemi locali di eventi.

Buzz v0.3.38 irrobustisce la superficie di attacco dei relay e aggiunge la selezione dei modelli indipendente dal provider

Buzz v0.3.38 irrobustisce la superficie di attacco dei relay esposta da Buzz quando pubblica persona, team, agenti gestiti e attestazioni dei proprietari NIP-OA come eventi Nostr firmati. Un relay Buzz è un registro pubblico delle identità Nostr del team e del loro stato; questa release rafforza la validazione degli input e la protezione dai replay sui kind di evento ben noti definiti da Buzz. La release generalizza inoltre la selezione dei modelli, così un team Buzz può scegliere qualsiasi provider per cui Buzz disponga di adapter, incluso un nuovo backend Databricks AI Gateway v2.

Notedeck implementa relay di sincronizzazione privata NIP-37, calendario NIP-52 e commenti NIP-22

Notedeck, il client desktop nativo in Rust del team Damus, ha implementato tre protocolli in una sola settimana. I relay di sincronizzazione privata ora vengono memorizzati come lista kind 10013 NIP-37, separando l’insieme di relay per contenuti privati dell’utente dall’outbox pubblica NIP-65. Il pannello calendario horizon legge eventi NIP-52 da nostrdb e ha ricevuto una nuova disposizione a tre riquadri. Il pannello headway ha aggiunto un modello di eventi commento NIP-22 su kind 1111, il kind definito da NIP-22 per la superficie unificata dei commenti che sostituisce il concatenamento delle risposte NIP-10.

Applesauce introduce sessioni NIP-46 nbunksec e aggiorna il wallet a Cashu v4

Applesauce, il toolkit modulare Nostr per signer, relay, wallet e contenuti, ha pubblicato una serie coordinata di release 6.2.x nei suoi sottopacchetti. Il pacchetto signers ha ricevuto helper per importare ed esportare nbunksec, trattando una sessione bunker NIP-46 come un artefatto portabile che può spostarsi fra client. Il pacchetto wallet ha aggiornato i binding Cashu a @cashu/cashu-ts v4, dove gli importi delle proof diventano value object Amount e cambia l’API di decodifica dei token.

Release con tag

mostro-core v0.14.0

mostro-core v0.14.0 introduce la successiva iterazione del protocollo per la rete Mostro di scambio P2P di valuta fiat. La release segue v0.13.2 ed esce insieme a mostro-cli v0.16.0, che adotta il nuovo core. Questa settimana sono state integrate tre PR nel repository core; lo stack circostante, mostro daemon e Mostro mobile, si allinea alla v0.14.0 del crate di tipi condivisi.

ngit v2.6.1

ngit v2.6.1, la CLI canonica per git su Nostr nei repository NIP-34, implementa la semantica dei fork GRASP-06 di NIP-34 integrata questa settimana, che sostituisce il tag personal-fork con un tag u negli eventi repo-state.

mesh-llm v0.72.0 e v0.72.1

mesh-llm, il componente di inferenza dello stack ContextVM che esegue LLM open source dietro una superficie JSON-RPC indirizzabile via Nostr, ha pubblicato v0.72.0 e v0.72.1, con una correzione per un crash del batching su singoli prompt di grandi dimensioni e una migrazione del bridge MCP che abbandona helper deprecati.

Meiso v1.4.0 introduce Shared-Key Collaborative Lists che sostituiscono MLS per la condivisione dei task

Meiso v1.4.0 introduce un modello Shared-Key Collaborative Lists che sostituisce la precedente condivisione dei task basata su MLS con un design più semplice di eventi indirizzabili. Ogni lista condivisa genera una chiave Nostr dedicata distribuita ai membri; i task sono eventi indirizzabili kind 35000, identificati da d=task-id, con contenuto auto-cifrato tramite NIP-44, mentre i relay applicano Last-Write-Wins per ciascun task. Il design rinuncia alla forward secrecy e alla sicurezza post-compromissione di MLS in cambio di un’implementazione più semplice nei client e della risoluzione dei conflitti a livello di relay.

Cordn 0.3.2

Cordn 0.3.2 introduce un filone “more-private-coordinator” che rimuove le pubkey effimere dei mittenti dalla pubblicazione dei messaggi di gruppo e irrobustisce il flusso delle richieste di ingresso contro nuove richieste obsolete. Cordn è lo stack di messaggistica basato su MLS presentato nel lancio del CVM ad hoc di Cordn nel numero 28; questa release è il corrispondente aggiornamento lato coordinatore.

Modifiche non ancora rilasciate

diVine integra 108 PR di rifiniture successive al lancio

diVine, il client per brevi video in loop che riporta in vita Vine, attraversa un’intensa fase di rifinitura successiva al lancio. Il lavoro visibile su Nostr questa settimana consiste in un passaggio di stabilizzazione del flusso di connessione NIP-46, che migra gli errori nostrconnect:// verso codici di motivo strutturati.

Zap Cooking prosegue la correzione NIP-46 trasversale ai progetti e la revisione del compositore

Zap Cooking è un client Nostr per condividere ricette, pubblicate come eventi Nostr long-form. Il lavoro di questa settimana prosegue la correzione NIP-46 trasversale ai progetti e la revisione del compositore descritte fra le modifiche non ancora rilasciate nel numero 28.

Conduit irrobustisce il flusso degli annunci e la correttezza del marketplace

Conduit è un monorepo di marketplace su Nostr composto da tre app: mercato per acquirenti, portale per commercianti e generatore di negozi. Il lavoro di questa settimana prosegue la spinta sulla correttezza del marketplace descritta nella copertura del lancio nel numero 28, sulla scia dell’ondata commerciale NIP-99 che ha costituito la storia di protocollo dello scorso numero.

Pollerama dalla v1.12 alla v1.13.1 aggiunge la scelta del client tag, schede del profilo e limiti ai thread

Pollerama, un client Nostr Android incentrato su sondaggi e note con un forte livello di scoperta basato sul web of trust, ha pubblicato questa settimana su Zapstore v1.12.0, v1.13.0 e v1.13.1. Ora gli utenti possono scegliere quale client tag allegare alle note e ai sondaggi che creano, selezionandolo da un elenco predefinito o inserendone uno proprio. Le catene di commenti e risposte molto annidate si interrompono ora dopo pochi livelli e rimandano al thread completo nella pagina della nota. Le pagine dei profili si aprono per impostazione predefinita su Notes, suddivise nelle schede Posts e Conversations. È stato corretto un bug di persistenza dei follow, per cui gli account appena seguiti scomparivano al riavvio dell’app, e i pulsanti di follow ora mostrano l’avanzamento.

getwired.app e get-tao.app correggono il flusso di invio confess di NIP-13

getwired.app e get-tao.app, che condividono un flusso di pubblicazione anonima che aggiunge proof-of-work NIP-13 al momento dell’invio per limitare lo spam, hanno corretto il flusso di invio confess affinché l’esperienza utente durante il mining PoW sia coerente.

nostui aggiunge una scheda della timeline delle menzioni

nostui, un client Nostr da terminale in Rust, ha aggiunto una scheda della timeline delle menzioni che presenta in una vista TUI dedicata gli eventi kind 1 che taggano la pubkey attiva.

Heartwood introduce URI bunker NIP-46 per identità e un bridge di firma in modalità HSM

Heartwood è un signer NIP-46 nel quale la chiave di firma non raggiunge mai il client: quest’ultimo comunica tramite NIP-46 con un piccolo relay, che a sua volta usa un protocollo di frame seriali per parlare con un dispositivo hardware collegato ed eseguire la firma. Questa settimana il progetto ha integrato un bridge di firma da relay a seriale e connessioni bunker per identità, così un singolo dispositivo hardware che custodisce più identità espone un URI bunker distinto per ciascuna.

Refactoring dell’autenticazione e dei signer di Nostter

Questa settimana Nostter ha rielaborato il proprio livello di autenticazione e signer, spostando lo stato di login su un unico signal ed estraendo il dispatch del signer in moduli di strategia. La direzione è un’astrazione pulita del signer, nella quale estensione web NIP-07, bunker remoto NIP-46 e nsec grezzo condividono un solo percorso di codice.

Dart NDK estrae il signer NIP-07 e randomizza i timestamp NIP-59

Dart NDK ha spostato il signer NIP-07 fuori dal pacchetto core e dentro ndk_flutter, dove risiede la WebView Flutter, e ha randomizzato i timestamp dei gift wrap NIP-59 per rafforzare la protezione contro la correlazione temporale dei messaggi cifrati.

Milk Market aggiunge pagine vetrina NIP-23 e pagamenti tramite Square

Milk Market, la vetrina marketplace del team Shopstr, ha dotato ogni negozio di una pagina blog basata sugli eventi long-form NIP-23 del venditore, con sezioni modificabili e una route diretta per le impostazioni del blog. Nella stessa settimana ha aggiunto Square come processore di pagamenti alternativo per i venditori e l’acquisto automatico delle etichette di spedizione per gli ordini pagati.

Calendar by Formstr pubblica un’app iOS

Questa settimana Calendar by Formstr ha integrato la PR #159 IOS App, portando su iOS il client calendario NIP-52. La PR #197 corregge il parsing delle date del calendario nell’ora locale e la PR #201 aggiunge un flusso E2E Playwright attivato da un’etichetta run-tests.

cagliostr applica NIP-22, NIP-09 per coordinate e proof-of-work NIP-13

cagliostr, un’implementazione di relay in Go, ha rafforzato questa settimana tre percorsi di applicazione delle regole: proof-of-work NIP-13 configurabile sugli eventi in ingresso, eliminazione NIP-09 per coordinate indirizzabili, così gli eventi sostituibili possono essere eliminati tramite il loro tag a, cosa impossibile con la sola eliminazione per id evento, e limiti temporali NIP-22 configurabili, che rifiutano eventi datati troppo nel passato o nel futuro.

Nuovi progetti monitorati e scoperti

La suite per il benessere Vanderwarker pubblica telemetria del mondo fisico come eventi Nostr tramite una chiave di firma condivisa del publisher. Comprende cinque app collegate: Holy Fit è un contapassi che registra dati di fitness su Nostr come kind:30078; Nunlock pubblica ogni giorno il numero di sblocchi del telefono; Saint Stream pubblica la riproduzione multimediale corrente come User Status; Sister Charge pubblica ogni 15 minuti livello, tensione e temperatura della batteria; Cellibacy pubblica il consumo giornaliero di dati. Tutte e cinque sono apparse su Zapstore fra il 24 e il 30 giugno.

ntrack v0.1.9 è un’app Android serverless per la condivisione cifrata della posizione in tempo reale, realizzata in Rust e Slint e pubblicata il 29 giugno. È un progetto collegato a Haven, il sistema di condivisione della posizione basato su Marmot descritto nel numero 28, ma usa un’architettura di trasporto diversa: gli aggiornamenti della posizione viaggiano in DM Nostr cifrati, mentre Haven usa messaggi di gruppo Marmot.

NostrAppShell è uno scaffold iniziale di shell applicativa per costruire app Nostr. Questa settimana il progetto ha pubblicato la sua prima documentazione rivolta agli utenti.

NIPs by Pollerama, repository abh3po/better-nips creato il 2026-06-29, è un nuovo client per i NIP kind:30817 scritti dalla community di NostrHub, proposto come superficie alternativa a nostrhub.io con ponderazione basata sulla fiducia. Ogni NIP kind:30817 ha un proprio URL condivisibile (#/nip/<naddr>), con rendering Markdown completo e i kind di evento che definisce. Il client offre tre feed, Following, Web of Trust (follow dei follow) e Global, ciascuno ordinabile per approvazioni ponderate in base alla fiducia o per data. Le approvazioni vengono pubblicate come label NIP-32 su kind 1985, con i tag ["L","nostrhub"] e ["l","approve","nostrhub"], oltre a un tag a che punta all’indirizzo del NIP obiettivo e a un tag client che dichiara better-nips. È esattamente la forma di evento firmata dallo stesso NostrHub, così le approvazioni sono compatibili fra i due client. L’approvazione di un follow diretto pesa nella classifica più di quella proveniente da un follow di secondo grado.

Lo stack di firma è @formstr/signer, con una finestra di login completa che comprende signer NIP-07, bunker e nostrconnect NIP-46, ncryptsec NIP-49 e signer Android NIP-55; le sessioni si ricollegano silenziosamente al ricaricamento. Il livello di rete passa attraverso @formstr/local-relay, un Web Worker che suddivide l’outbox NIP-65 dell’utente fra i relay, impedendo che un grande insieme web of trust venga inoltrato in massa a un singolo relay. La posizione progettuale è che i NIP della community, ospitati da NostrHub, in better-nips o da altri client futuri, siano tutti uguali a livello di protocollo; la classifica deriva dal grafo sociale, non dalla selezione dei moderatori, collegandosi direttamente al flusso di labeling NIP-32 esaminato nell’approfondimento del numero 25.

Questa settimana sono comparsi due nuovi cluster di repository NIP-34. Vidstr è un client Nostr incentrato sui video, mentre un cluster nostrapps.com pubblica tre progetti collegati: verdana, una VM per napp desktop; hallway, un client personalizzabile per community; e napps, una specifica e runtime per microapp HTML. Il cluster si colloca in parallelo al lavoro sui napplet trattato nella storia principale dello scorso numero.

Lavoro sul protocollo e aggiornamenti dei NIP

Integrata: NIP-44 elimina il limite di payload di 65.535 byte

La PR #1907 è stata integrata il 28 giugno dopo essere rimasta aperta dal 2024-09. La modifica rimuove il limite massimo di 65.535 byte per il payload in chiaro di un envelope di cifratura versionata NIP-44, portandolo a un massimo di 4 GiB (uint32_max). NIP-44 codifica la lunghezza del payload come uint16 nel formato wire, requisito imposto rigidamente dalla specifica originale per l’interoperabilità; la modifica integrata adotta un campo di lunghezza maggiore indicato nel byte di versione, così le implementazioni v2 restano compatibili a livello wire e quelle v3+ trasportano la lunghezza estesa. I client che usano NIP-44 per messaggi diretti NIP-17, gift wrap NIP-59, payload dei signer remoti NIP-46 o qualsiasi altro messaggio Nostr cifrato con NIP-44 possono ora scambiare singoli eventi più grandi di 64 KiB senza suddividerli a livello applicativo.

Integrate: NIP-86 riceve un metodo signevent e un evento Relay Roles

La PR #2389 aggiunge un metodo signevent all’API JSON-RPC di gestione dei relay NIP-86, permettendo a un amministratore di chiedere al relay di firmare un evento con la pubkey del relay stesso. La PR #2390 associata definisce un evento Relay Roles: un evento sostituibile pubblicato dal relay per dichiarare i propri amministratori e moderatori. Insieme consentono ai client NIP-86 di ricavare l’elenco degli amministratori di un relay e verificare che una richiesta autenticata provenga da un amministratore corrente, senza fiducia fuori banda. Entrambe le modifiche sono approfondite più avanti.

Integrata: NIP-34 sostituisce personal-fork con `u` per GRASP-06

La PR #2395, integrata il 24 giugno, sostituisce il tag personal-fork di NIP-34 negli eventi repo-state (kind:30618) con un tag u, per “upstream”, allineando il formato wire alla semantica dei fork GRASP-06 implementata dalla suite GitWorkshop. La modifica chiude la PR #2384, NIP-34: remove maintainers to solve expiry issues, che proponeva una diversa correzione alla semantica dei fork. La direzione integrata è quella implementata da ngit v2.6.x, quindi specifica e CLI di riferimento sono ora allineate. I repository esistenti che usano personal-fork continuano a interoperare; i nuovi repository e la linea ngit v2.6 pubblicano il tag u.

Integrati: metadati client NIP-46, ora upstream dopo l’implementazione in Amber

La PR #2381, integrata il 23 giugno, aggiunge metadati client facoltativi alla richiesta connect di NIP-46, consentendo a un client di pubblicare nome, URL dell’icona e URL della homepage durante la connessione al signer. Amber v6.2.2 ha introdotto l’estensione dei metadati la scorsa settimana, come descritto nel numero 28; questa settimana il NIP upstream raggiunge l’implementazione già distribuita.

Aperte: chiavi wrapper NIP-17 deterministiche basate su epoche

La PR #2397 e la PR #2396 riguardano due proposte convergenti per le chiavi di wrapping NIP-17. La PR #2397 propone che la chiave di firma effimera usata per creare un gift wrap NIP-59 sia derivata in modo deterministico da un seed per conversazione, legato a un’epoca temporale approssimativa, così un destinatario che conosce la chiave della conversazione può prevedere a quali pubkey sottoscriversi. La specifica attuale richiede una nuova chiave casuale per ogni wrap, rendendo impossibile tale previsione. La PR #2396 è la modifica complementare: i wrap di una determinata conversazione dovrebbero essere firmati direttamente con la chiave della conversazione, così la pubkey del wrap funge anche da identificatore della conversazione. Insieme definiscono un percorso verso conversazioni NIP-17 filtrabili senza perdita di metadati. Entrambe sono aperte e in discussione.

Aperta: NIP-59 dovrebbe far rifiutare ai relay gli eventi seal kind 13

La PR #2399 propone che i relay rifiutino gli eventi kind 13, il seal interno di un gift wrap NIP-59, quando compaiono al livello superiore di una richiesta di pubblicazione, perché un evento seal ha senso soltanto dentro un wrap e un seal esposto rivela la pubkey del destinatario. La issue #2398 associata va oltre e sostiene che il seal dovrebbe essere ridefinito come kind effimero, poiché i kind effimeri NIP-01 non vengono memorizzati dai relay; ciò irrobustirebbe la regola a livello di protocollo ed eliminerebbe la dipendenza dalle policy dei singoli relay.

Aperta: stati dei gruppi NIP-29

La PR #2372 aggiunge una semantica esplicita degli stati dei gruppi a NIP-29, dedicato ai gruppi basati su relay, definendo cosa significhi che un gruppo sia aperto, chiuso, pubblico, privato o archiviato e come le transizioni di stato interagiscano con gli eventi dei membri. La proposta porta nella specifica del relay una semantica finora specifica dei singoli client.

Aperta: supporto facoltativo per più maintainer in NIP-34

La PR #2324 è la proposta complementare alla PR #2395 integrata, relativa alla semantica dei fork GRASP-06 trattata sopra. La PR #2324 aggiunge il supporto facoltativo per più maintainer agli eventi di annuncio dei repository NIP-34 (kind:30617), permettendo a un repository di dichiarare più di una pubkey di maintainer canonico tramite tag maintainer ripetuti. Patch e issue firmate da qualsiasi maintainer dichiarato vengono quindi considerate ufficiali dai client, colmando la lacuna storica per cui i repository NIP-34 con più maintainer devono convogliare tutto attraverso una pubkey oppure ricorrere al coordinamento fuori protocollo.

Aperta: operatore AND di NIP-91 per i filtri, la proposta non è integrata

La PR #2252 propone un operatore AND per i filtri Nostr, riaprendo un progetto discusso per la prima volta nella precedente PR #1365, poi chiusa. Esistono già implementazioni in nostr-rs-relay, applesauce, Amethyst e worker-relay, ma la PR della specifica resta aperta.

Chiuse: quattro NIP commerciali di pats2sats

Questa settimana sono state chiuse quattro proposte per il commercio su Nostr: Escrow (#2334), Reservations (#2335), una Marketplace Listing Extension NIP-99 (#2346) e un Accommodation Listing Profile (#2333). La stessa superficie commerciale viene ora consolidata nella Gamma Market Spec, un repository di estensioni di proprietà del progetto costruito sugli annunci marketplace NIP-99, con semantica per ordini, checkout, escrow e controversie. Compass ora monitora questo repository insieme a Marmot e Blossom come repository di specifiche di protocollo esterno allo stesso repository NIPs; le PR aperte questa settimana comprendono chiarimenti sull’attribuzione del client (#11), un tag supersedes per le modifiche all’identità dei prodotti (#8) e la semantica delle recensioni dei commercianti (#7).

Aperte: collegamento delle identità Bitcoin

Questa settimana sono state aperte due proposte per collegare identità Bitcoin a identità Nostr: un indirizzo Bitcoin Silent Payment NIP-352 e una proof di collegamento dell’identità Bitcoin-OTC.

Approfondimento NIP: NIP-86 (API di gestione dei relay)

NIP-86 definisce un’interfaccia JSON-RPC per la gestione dei relay, consentendo ai client autorizzati di inviare comandi amministrativi ai relay tramite un’API standardizzata. Un unico client può gestire qualsiasi relay compatibile con NIP-86 senza strumenti specifici per ciascuno. Due modifiche alla specifica integrate questa settimana, PR #2389 e PR #2390, chiudono il circuito fra eventi firmati dai relay e amministratori dichiarati dai relay.

Il trasporto

Una richiesta di gestione NIP-86 è un HTTP POST allo stesso URI dal quale il relay serve le connessioni WebSocket, con Content-Type: application/nostr+json+rpc. Il corpo della richiesta è un documento JSON della forma:

{
 "method": "<method-name>",
 "params": [<arg1>, <arg2>, ...]
}

L’autenticazione usa un evento firmato di autenticazione HTTP NIP-98 nell’header Authorization. Prima di eseguire il metodo, il relay verifica che la pubkey firmataria sia nel proprio elenco di amministratori. La risposta del relay è un documento JSON della forma:

{
 "result": <return-value>,
 "error": "<error-string-if-any>"
}

I metodi esistenti prima di questa settimana

L’insieme di metodi preesistente comprende ban delle pubkey (banpubkey, allowpubkey, listbannedpubkeys), ban degli eventi (banevent, allowevent, listbannedevents), metadati del relay (changerelayname, changerelaydescription, changerelayicon), gestione dell’elenco dei kind consentiti (allowkind, disallowkind, listallowedkinds) e un metodo stats che restituisce statistiche del relay. La forma è volutamente simile a quella di un servizio JSON-RPC standard, così un client può costruirvi sopra binding tipizzati.

Cosa è cambiato questa settimana

La PR #2389 aggiunge alla specifica un metodo signevent. Il metodo riceve come argomento un template di evento parziale, con kind, tag e content, e chiede al relay di firmare e restituire un evento completo usando la pubkey del relay nel campo pubkey. È il prerequisito affinché un relay possa pubblicare eventi di protocollo su se stesso: annunci di pubkey bloccate, metadati del relay e il nuovo evento Relay Roles descritto sotto richiedono tutti che il relay firmi con la chiave controllata dall’operatore, ma la maggior parte degli operatori non vuole custodire una chiave privata nel proprio client amministrativo.

La PR #2390 definisce un evento Relay Roles: un kind di evento sostituibile parametrizzato che un relay pubblica, firmato con la propria pubkey tramite signevent, per dichiarare le pubkey dei suoi amministratori e moderatori con una semantica esplicita dei ruoli. Un client consapevole di NIP-86 può recuperare l’evento Relay Roles da qualsiasi relay monitorato, costruire l’elenco degli amministratori dai tag dell’evento e verificare che una richiesta NIP-86 autenticata provenga da un amministratore corrente, senza fiducia fuori banda né configurazione specifica per relay. Le due PR chiudono insieme il circuito: signevent è il meccanismo, Relay Roles è il primo kind di evento costruito su di esso.

Esempio di richiesta NIP-86

Una richiesta NIP-86 banpubkey completa ha questa forma:

{
 "method": "banpubkey",
 "params": [
 "<64-char-hex-pubkey-to-ban>",
 "spam"
 ]
}

con un header Authorization che trasporta un evento firmato NIP-98:

{
 "id": "5e1c2f9e1d3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c",
 "pubkey": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2",
 "created_at": 1782824400,
 "kind": 27235,
 "tags": [
 ["u", "https://relay.example.com/"],
 ["method", "POST"],
 ["payload", "<sha256-of-request-body>"]
 ],
 "content": "",
 "sig": "f1e2d3c4b5a697887766554433221100ffeeddccbbaa99887766554433221100f1e2d3c4b5a697887766554433221100ffeeddccbbaa99887766554433221100"
}

La pubkey firmataria deve comparire nell’insieme degli amministratori del relay, ora dichiarato nell’evento relay-roles; il tag u deve corrispondere all’URL HTTPS del relay; il tag payload deve corrispondere allo SHA-256 del corpo JSON della richiesta. Il relay restituisce:

{
 "result": true,
 "error": null
}

Implementazioni

Amethyst offre su Android un’interfaccia di gestione dei relay NIP-86 dalla v1.07.0 in poi.
Fra i relay di riferimento che implementano la specifica vi sono strfry, khatru e diverse implementazioni minori collegate dalla sezione Implementation Status della specifica.

I client consapevoli di NIP-86 inizieranno a trattare l’evento relay-roles come fonte canonica dell’elenco degli amministratori di un relay, quando gli implementatori adotteranno le modifiche signevent e Relay Roles.

Approfondimento NIP: NIP-89 (application handler consigliati)

NIP-89 definisce due kind di eventi sostituibili parametrizzati, kind:31990, l’application handler pubblicato dallo sviluppatore di un’app, e kind:31989, la raccomandazione pubblicata dall’utente per un’app che utilizza. Insieme permettono ai client di scoprire applicazioni capaci di gestire un kind di evento sconosciuto senza coordinamento fuori banda: un lettore long-form che incontra un evento kind:30030 non gestito nativamente può interrogare il grafo NIP-89 alla ricerca di handler e offrire all’utente un flusso Open in... verso un’app pubblicata che sappia gestirlo. NIP-89 è l’infrastruttura originaria per lo stesso problema di instradamento fra app che il lavoro su napplet e napps presente in questo numero sta ora estendendo ad applet componibili native di Nostr.

L’evento application handler (`kind:31990`)

Lo sviluppatore di un’app pubblica uno o più eventi handler che descrivono quali kind di evento sono supportati dall’app e come aprire un’entità Nostr al suo interno:

{
 "id": "8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b",
 "pubkey": "c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2",
 "created_at": 1782824400,
 "kind": 31990,
 "tags": [
 ["d", "longform-reader-v1"],
 ["k", "30023"],
 ["k", "30024"],
 ["web", "https://reader.example.com/a/<bech32>", "naddr"],
 ["ios", "longformreader://open/<bech32>"],
 ["android", "longformreader://open/<bech32>"]
 ],
 "content": "{\"name\": \"Longform Reader\", \"picture\": \"https://reader.example.com/icon.png\", \"about\": \"A native reader for NIP-23 longform.\"}",
 "sig": "1f2e3d4c5b6a798877665544332211000ffeeddccbbaa99887766554433221100ffeeddccbbaa99887766554433221100ffeeddccbbaa9988776655443322110a"
}

Il tag d identifica l’handler, così può essere sostituito; ogni tag k dichiara un kind di evento gestito dall’app e ogni tag di piattaforma (web, ios, android, …) fornisce un template URL con <bech32> come segnaposto per un’entità codificata secondo NIP-19, che il client chiamante sostituisce al momento dell’apertura. Un singolo evento handler può pubblicizzare più kind supportati se condividono lo stesso schema di instradamento, mantenendo compatta la scoperta delle app ed evitando un evento handler per ogni kind.

L’evento di raccomandazione dell’utente (`kind:31989`)

Un utente pubblica una raccomandazione che dichiara quali app usa per un determinato kind di evento:

{
 "id": "9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d",
 "pubkey": "d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3",
 "created_at": 1782824500,
 "kind": 31989,
 "tags": [
 ["d", "30023"],
 ["a", "31990:c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2:longform-reader-v1", "wss://relay.example.com", "web"],
 ["a", "31990:e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6:reader-pro", "wss://relay.example.com", "ios"]
 ],
 "content": "",
 "sig": "2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6"
}

Il tag d contiene il kind di evento raccomandato. Ogni tag a è un puntatore di indirizzo NIP-01 a un evento handler kind:31990, con il relay suggerito e la piattaforma a cui si applica la raccomandazione. La stessa raccomandazione può elencare più app per piattaforme differenti.

Il client tag e il compromesso sulla privacy

NIP-89 definisce inoltre un tag client facoltativo che qualsiasi app di pubblicazione può allegare agli eventi di cui è autrice:

["client", "Longform Reader", "31990:c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2:longform-reader-v1", "wss://relay.example.com"]

Ciò consente a qualsiasi client che mostra l’evento di presentare l’app da cui proviene, recuperare metadati più ricchi dell’handler e rispettare i suggerimenti di rendering dichiarati dall’handler. La specifica segnala esplicitamente anche il costo per la privacy: un client che emette un tag client su ogni evento pubblica l’identità del software dell’utente, rivelando nel tempo schemi di utilizzo. La specifica raccomanda ai client di offrire agli utenti la possibilità di disattivarlo.

La PR #3422 di Amethyst analizza e mostra i tag NIP-89 t, i, a e client nella visualizzazione degli eventi, indicando direttamente nella timeline quale app ha creato una nota.

Come funziona in pratica il flusso di scoperta

Un client che riceve un kind di evento sconosciuto segue questi passaggi. (1) Interroga il grafo dei follow dell’utente alla ricerca di eventi kind:31989 con un tag d corrispondente al kind dell’evento. (2) Risolve ogni tag a raccomandato nel relativo evento handler kind:31990. (3) Sceglie l’handler il cui template URL web, ios o android corrisponde alla piattaforma corrente. (4) Sostituisce nel template URL la codifica bech32 dell’entità. (5) Offre all’utente l’URL risultante come opzione Open in.... Il flusso è filtrato socialmente: un client che interroghi eventi handler arbitrari da relay non fidati potrebbe reindirizzare gli utenti verso app malevole, quindi partire dalle persone seguite dall’utente è un’impostazione predefinita più sicura che considerare ugualmente affidabile ogni handler pubblicato.

NIP-89 e il livello napplet

La sezione Discover di Amethyst, il runtime host per napplet e la visualizzazione dei tag client costruiscono insieme una superficie completa di consumo NIP-89 su Android. La specifica napplet, introdotta nello scorso numero, estende ciò a cui possono puntare gli eventi handler NIP-89: applet in sandbox che vengono eseguite in un runtime componibile nativo di Nostr, sopra Nostr e Blossom. NIP-89 è il grafo di scoperta e instradamento; il runtime napplet è uno dei target di esecuzione a cui può puntare.

Per segnalazioni, correzioni e progetti che ci sono sfuggiti, aprite una issue su github.com/andotherstuff/nostr-compass oppure contattateci tramite DM NIP-17 all’indirizzo npub1wav4fae3gyfy3xj298kxj2mj8phavz7vavps34przq02j7w902qq902923.

Nostr Compass #28

Wed, 24 Jun 2026 00:00:00 +0000

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

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

Storie principali

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

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

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

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

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

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

Napplets: app Nostr componibili con un confine di fiducia definito

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

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

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

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

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

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

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

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

Release con tag

Amber v6.2.2 implementa i metadati client NIP-46

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

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

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

CodeDeck: coding agentico remoto tramite Nostr

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

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

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

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

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

Mostro Core v0.13.1 fa seguito a Protocol v2

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

Wisp v1.1.2 e la variante Dark Wisp

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

Citrine v3.0.1

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

FIPS v0.4.0-rc2

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

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

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

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

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

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

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

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

Release minori con tag

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

Modifiche non ancora rilasciate

Cordn Ad-hoc CVM: un coordinatore MLS nel browser

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

SnowCait/nostter pubblica 19 PR di iterazione UX

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

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

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

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

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

Lavoro su divine.video mobile e desktop

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

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

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

Nuovi progetti monitorati e scoperti

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

PRana: una lista di lavoro per issue NIP-34

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

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

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

Lavoro sul protocollo

Aggiornamenti NIP

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

I metadati client NIP-46 arrivano in Amber e Nostur

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

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

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

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

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

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

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

Stati dei gruppi NIP-29 (lavoro in corso)

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

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

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

kind 1111 come risposta alle note kind 1

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

Sei anni di giugno su Nostr

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

Giugno 2021: l’infanzia del protocollo

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

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

Giugno 2022: nasce il repository NIP

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

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

Giugno 2023: l’ondata di adozione dopo Damus

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

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

Giugno 2024: signer, gift wrap e aggiornamento della messaggistica

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

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

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

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

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

Giugno 2026: un mese ricco di lanci

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

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

Nostr Compass #27

Wed, 17 Jun 2026 00:00:00 +0000

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

Storie principali

Amethyst v1.12.0 porta wallet Cashu, nutzap, un driver CLINK e l’autoripristino di Tor

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

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

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

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

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

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

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

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

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

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

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

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

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

Release

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

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

Nostur 1.29.0 introduce risposte anonime e logout dal signer remoto

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

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

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

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

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

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

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

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

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

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

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

ants v0.4.5 aggiunge link ai portali per gli articoli e ripristina Habla nell’insieme dei portali

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

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

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

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

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

Zeus v13.1.0-rc1 distribuisce noffer CLINK e NWC senza coda

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

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

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

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

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

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

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

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

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

Altre release

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

Modifiche non ancora rilasciate

diVine integra 119 PR verso la prossima release del video breve

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

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

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

Lavoro su librerie e strumenti

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

Aggiornamenti NIP e lavoro sulle specifiche di protocollo

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

Integrato questa settimana:

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

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

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

Seguiti NIP-46 aperti:

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

Altro lavoro aperto:

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

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

Approfondimento NIP: NIP-77 (Negentropy)

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

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

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

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

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

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

Esempio di scambio NEG-OPEN:

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

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

Approfondimento NIP: NIP-61 (Nutzaps)

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

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

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

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

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

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

Esempio di evento nutzap:

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

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

Nostr Compass #26

Wed, 10 Jun 2026 00:00:00 +0000

L’organizzazione Marmot Protocol apre tre nuovi repo per una bozza di protocollo v2 e una linea di client nativi: un workspace Rust chiamato darkmatter, un’app iOS SwiftUI darkmatter-ios e un’app Android Kotlin/Compose darkmatter-android. L’originale Flutter Whitenoise viene archiviato. Chama comprime diciassette release in una settimana e attraversa la linea di app standalone con v3.0.0 prima di portare un ridisegno completo della UI della trade room e storefront per venditore in v3.1.0, sopra a share Shamir solo per il detentore, sostituzione dell’arbitro, routing di community mondiale e notifiche di trade end-to-end. Coracle lancia un servizio di relay ospitato a pagamento sostenuto dallo stack open-source Caravel e zooid, con integrazione profonda con Flotilla pianificata. Angor passa a mainnet di default in v0.2.30 e porta un test di funding UAT a 3 utenti in v0.2.29. Amethyst porta 41 PR non rilasciate che continuano il lavoro NIP-32 / NIP-F4 / Tor della scorsa settimana. NIP-67 (hint di completezza EOSE) e autocomplete NIP-50 sono mergiati, chiudendo due gap di correttezza di lunga data nel protocollo relay core. NIP-GART propone un wire format a tutela della privacy per gli alert di emergenza, e NIP-46 acquisisce un metodo di logout.

Storie principali

Marmot v2 (Dark Matter): ridisegno del protocollo, client nativi, app Flutter archiviata

Tre nuovi repo sono apparsi sotto l’organizzazione GitHub marmot-protocol questa settimana, che insieme formano la forma dei primi progressi di una bozza di protocollo Marmot v2 e una linea di client nativi che sostituisce la linea di app Flutter. darkmatter (Rust, creato il 13 maggio, trentaquattro commit negli ultimi sette giorni) contiene la bozza del protocollo v2 in spec/, un engine CGKA sostenuto da OpenMLS in crates/cgka-engine, un simulatore di conformità con property test e un modello formale Tamarin per prove di convergenza. darkmatter-ios (Swift, creato il 25 maggio) è un client SwiftUI sostenuto da un xcframework MarmotKit UniFFI vendorizzato generato dal workspace Rust. darkmatter-android (Kotlin/Jetpack Compose, creato il 25 maggio) siede sugli stessi binding Rust. L’originale Flutter Whitenoise è stato contrassegnato come whitenoise-archive (“ARCHIVED: This was the original White Noise Flutter app”); un nuovo repo Dart whitenoise porta la linea Flutter attiva in parallelo.

Leggete questo come progresso iniziale verso un Marmot più affidabile, non come un pivot finito. Il README di darkmatter si etichetta come “Candidate Marmot v2 protocol draft, CGKA engine, and conformance workspace” e dice direttamente: “MDK remains the deployed Rust protocol implementation until this draft and engine are adopted.” All’interno del workspace, il crate cgka-engine è taggato 0.1.0, “single internal consumer, not semver-stable”. Ogni pagina di spec porta “Status: draft for internal review”. Tre stelle sul repo del workspace e zero sulle app iOS e Android confermano che il lavoro è pre-annuncio. Direzione, ambito e disciplina sono il segnale qui; la prontezza per la produzione non è la rivendicazione.

La bozza del protocollo rende concreti i delta da v1 a v2. L’estensione MLS monolitica marmot_group_data di MIP-01, che ha portato nome del gruppo, descrizione, pubkey admin, id di routing del gruppo Nostr, lista relay, dati immagine del gruppo e impostazioni di messaggi a scomparsa sotto un unico ombrello sin dall’inizio di Marmot, viene divisa in componenti applicativi versionati: marmot.group.profile.v1 per nome e descrizione, marmot.group.admin-policy.v1 per pubkey admin, marmot.transport.nostr.routing.v1 per il nostr_group_id casuale e la lista relay canonica, marmot.group.blossom.image.v1 per hash immagine, chiave di cifratura, nonce e chiave di upload, e marmot.group.message-retention.v1 per i secondi dei messaggi a scomparsa. Ciascun componente possiede i propri byte esatti e il proprio percorso di versionamento, così una funzionalità futura può revisionare un componente senza forzare il resto dello stato del gruppo a ripercorrere il consenso sulle estensioni MLS. Le credenziali MIP-00 ottengono anche un nuovo documento fondazionale account-identity-proof-v1.md, indicato come “new in v2 and breaking”. La prova di identità vive ora sulla propria superficie, separata dalla costruzione del KeyPackage.

I delta della libreria supportano il ridisegno della spec. cgka-engine è la nuova macchina a stati locale del gruppo: avvolge OpenMLS, possiede gli stati di epoch Stable, PendingPublish, Merging e Recovering, traduce gli intent in commit MLS, restituisce valori tipizzati IngestOutcome e GroupEvent per ogni inviluppo di trasporto in ingresso e rilascia esplicitamente nessun trasporto e nessuna persistenza. Un trait TransportPeeler separa Nostr dall’engine, e un trait StorageProvider separa SQLite (via storage-sqlite, backed da SQLCipher) dall’engine. L’MDK di oggi impacchetta tutto ciò insieme; dividere i layer consente a un engine di stare sotto un trasporto relay Nostr ora e i trasporti QUIC stream e broker anch’essi rilasciati più tardi, senza riscrivere il modello di convergenza. La convergenza stessa è documentata come distributed-convergence.md e provata in un modello Tamarin che copre selezione deterministica di branch, eleggibilità gated dalla policy, replay di anchor mantenuti, rifiuto di branch obsoleti, riordinamento della consegna, duplicazione, invalidazione dell’output applicativo, handoff welcome/commit, consumo di proposal e gating in uscita durante la sync. I property test Rust controllano poi che l’engine segua le stesse regole con oggetti OpenMLS reali e l’harness del simulatore. Il lavoro di affidabilità con metodi formali di questa portata è assente dallo stack Marmot attuale.

Entrambi i client nativi abbandonano Flutter per toolkit UI nativi della piattaforma. darkmatter-ios è puro SwiftUI con una Notification Service Extension che decifra i push wake MIP-05 sul dispositivo, vendorizza un pacchetto Swift MarmotKit generato dal workspace Rust e si registra sotto il bundle ID e l’app group dev.ipf.darkmatter. darkmatter-android è Kotlin e Jetpack Compose, con una build pilotata da just che produce un APK arm64-v8a firmato e legge endpoint di telemetria da local.properties. Il README Android dichiara direttamente il principio architetturale: “Dark Matter owns protocol data and stores it in SQLite. The Android app should render that data, manage Android platform behavior, and keep UI lifecycle state. The Android app should not become a second database for Dark Matter data.” Questo rispecchia la disciplina di confine che il README di cgka-engine impone nel layer Rust, applicata al layer UI.

I client nativi contano per Marmot perché la debolezza più citata del protocollo è stata l’affidabilità mobile in condizioni di consegna non uniformi: notification wake mancati, race di commit MLS durante fluttuazioni di rete, limiti di background-fetch che bloccano gli avanzamenti di epoch. SwiftUI e Compose danno ai client accesso diretto alle primitive di background-processing della piattaforma che Flutter raggiunge tramite un bridge plugin, e il percorso di binding UniFFI mantiene la logica di protocollo in un unico workspace Rust rilasciato come libreria statica su entrambe le piattaforme. La linea Flutter Whitenoise continua nel repo non archiviato whitenoise, quindi l’annuncio è additivo: una nuova linea di client nativi corre accanto all’app Flutter mentre la spec v2 converge. Il cutover di produzione da MDK o dall’attuale app Whitenoise attende che bozza, engine e client raggiungano release pronte per la produzione.

Chama v2.0.0 fino a v3.1.0: escrow P2P standalone in una settimana

Il client di escrow P2P Nostr-native introdotto nella Newsletter #25 alla v1.3.0 ha rilasciato diciassette release taggate negli ultimi sette giorni, terminando a v3.1.0 il 9 giugno con un ridisegno della UI della trade room e storefront per venditore. La scia di versioni racconta la storia: v2.0.0 è la base BREAKING, poi v2.0.1, v2.0.2 e v2.0.3 chiudono i gap della funding-rail Fedi WebView; v2.1.0, v2.2.0, v2.3.0 e v2.3.1 rafforzano il layer dell’arbitro; v2.4.0, v2.5.0 e v2.6.0 aggiungono superfici di self-custody e routing di community mondiale; v2.7.0, v2.8.0, v2.9.0 e v2.10.0 stratificano copia di chiavi in inglese semplice, applicazioni di gruppo, arbitraggio di deadline di disputa e reputazione. v3.0.0 lega il pacchetto insieme con notifiche di trade end-to-end, e v3.1.0 del 9 giugno ridisegna la schermata di trade attorno a una spina di progresso Reserved → Locked → Settled, card di azione con colori di ruolo e una classe di storefront per venditore (curated swap, loanbook e bill) che rilascia annunci.

Il pivot architetturale vive in v2.0.0. Il formato LOCK dell’escrow è cambiato così ogni share di uno split Shamir 2-di-3 è cifrata solo verso il suo detentore (sharePolicy holder-only-v1). L’ecash bearer della federazione non si ricostruisce più da un singolo partecipante da solo, chiudendo un percorso in cui una parte malevola con sia la propria share sia una share detenuta dalla federazione poteva completare il trade senza consenso. I client pre-2.0 falliscono in modo evidente con “can’t find your share”; il trade non può completarsi su un client obsoleto, e nessun fondo viene perso nel processo. Un lock v2.0 richiede che ogni parte sia su v2.x per essere regolata. v2.0.0 ha aggiunto anche storefront multi-unità e una vista Market solo-sats.

v2.1.0 ha introdotto la sostituzione dell’arbitro: la share dell’arbitro all’indice Shamir 2 è ora cifrata a un ordine di priorità deterministico sopra il pool di arbitri della community, così un arbitro assente può essere sostituito senza bloccare il trade. v2.2.0 ha provato che la sostituzione ha funzionato sul campo su un trade da ₿121 e ha aggiunto backup di healing-substitution. v2.3.0 ha chiuso l’ultimo gap di front-running dell’arbitro controllando l’appartenenza dell’arbitro dell’annuncio alla community al momento del lock, e v2.3.1 ha chiuso la race gemella in cui uno slot di arbitro auto-assegnato era un’anteprima finché il lock non li insediava.

Le superfici di self-custody sono arrivate in v2.4.0 (frase di recupero BIP-39 per il wallet ecash Fedimint, memorizzato cifrato su Nostr) e v2.5.0 (backup master nsec che possiede l’identità Nostr e il seed del wallet). v2.6.0 ha rifatto l’onboarding attorno a un picker di community globale così gli utenti in paesi senza una Chama locale sono instradati alla federazione più vicina; le build precedenti facevano rimbalzare l’utente senza fallback. v2.7.0 ha riscritto la schermata di chiave di recupero in inglese semplice (“the only key to your account and the money in it; Chama never sees it and can’t reset it; if you lose it, no one can get your account back”). v2.8.0 ha aggiunto applicazioni di gruppo, tema chiaro/scuro e due nuovi kind di evento (38120 roster, 38121 application). v2.9.0 ha cambiato la risoluzione di disputa alla deadline: i trade contestati che raggiungono la loro scadenza si risolvono ora per ruling dell’arbitro; il comportamento precedente rimborsava automaticamente. La release è marcata COORDINATED così tutte le parti in una disputa devono aggiornarsi. v2.10.0 ha aggiunto rating per-trade pollice su/pollice giù come nuovo kind di evento 38123.

v3.0.0 è la milestone in cui l’app smette di aver bisogno di una community di coordinamento per operare. Le notifiche di trade end-to-end pingano l’utente solo sulle transizioni di stato attuabili: la controparte ha lockato i sats, payout pronto per essere reclamato, la disputa richiede la decisione dell’utente come arbitro, o trade regolato o scaduto. Un toggle nella schermata Me accende o spegne le notifiche, e il prompt di permesso scatta solo quando il toggle è abilitato. La deduplicazione fire-once impedisce che un ricaricamento di stato inneschi una tempesta di alert. Un bug di guardrail wrong-chama è stato anche chiuso in PR #103, dove le versioni precedenti potevano contrassegnare un annuncio con l’etichetta di una chama ma la federazione di un’altra chama. I bundle desktop Windows e Linux sono rilasciati con la release; il dmg macOS è trattenuto finché la firma e la notarizzazione non arrivano.

Chama si unisce ora a Mostro e Shopstr come marketplace Nostr-native, distinta per architettura serverless, escrow Shamir 2-di-3 supportato da Fedimint, cifratura di share solo per il detentore e l’unica delle tre che rilascia un client desktop e mobile autonomo senza una community di coordinamento.

Coracle Hosting: servizio relay a pagamento più stack Caravel open-source

Il 3 giugno Hodlbod ha annunciato Coracle Hosting a hosting.coracle.social, un servizio di relay di community ospitato che accetta pagamenti lightning ricorrenti su NWC o carta. Il servizio è alimentato da Caravel, il frontend di billing e provisioning di Coracle, e zooid, un runtime di relay che ospita molti relay virtuali su una singola macchina. Entrambi sono open source sul gitea self-hosted di Coracle. Caravel è rilasciato con integrazione opzionale livekit e Blossom che gli operatori possono abilitare per relay. Un tier gratuito con limiti di conteggio membri consente agli operatori di valutare il servizio prima di impegnare dettagli di pagamento.

Hodlbod è schietto sul modello di business: monetizzare l’open source vendendo una versione ospitata di uno stack che chiunque altro può anche far girare. Il fossato competitivo è l’integrazione Flotilla, che è il prossimo passo pianificato. Flotilla possiede la superficie utente, così l’opzione ospitata servita dall’interno di Flotilla diventa il percorso di default per qualunque utente che preferisca infrastruttura gestita. Hodlbod ha offerto di aggiungere altri operatori Caravel al picker di hosting alternativo di Flotilla se si mettono in contatto, tenendo aperta la porta a un mercato di hosting federato.

Caravel si unisce a relay.tools come piattaforma pubblica di provisioning di relay Nostr con tier a pagamento per membro. relay.tools precede Caravel ed è rilasciato come il servizio dominante di creazione di relay oggi, con la propria directory di relay di community e flussi di join per membri o moderatori a pagamento. La caratteristica distintiva di Caravel è lo stack coordinato: il runtime del relay (zooid), il frontend di billing e provisioning (Caravel stesso) e il picker lato client (integrazione con Flotilla, ancora in corso) sono rilasciati come un unico design. L’altra caratteristica distintiva è la densità many-relay-per-process di zooid, in cui i relay dei clienti condividono un singolo processo host così l’operatore ammortizza i costi di hosting su molte piccole community. Questo è lo stesso argomento di densità che ha reso il web hosting condiviso praticabile all’inizio degli anni 2000, applicato al layer relay di Nostr.

Rilasci

Angor v0.2.29 e v0.2.30: default mainnet e test UAT funding a 3 utenti

Angor v0.2.29 del 4 giugno e v0.2.30 dell'8 giugno sono le due release di questa settimana per il protocollo decentralizzato di funding Bitcoin-e-Nostr. La modifica principale di v0.2.30 è PR #893, che porta la rete di default a mainnet. Angor è ancora rilasciato come release alpha unstable, ma lo switch al default mainnet segnala che il protocollo è oltre la fase solo testnet per i client desktop e mobile. v0.2.30 porta anche un flusso mobile di creazione di progetto single-tap con upload immagine e reset dello scroll (PR #889) e risolve una race condition in cui lo spinner di invoice lightning poteva bloccarsi (PR #890).

v0.2.29 ha aggiunto un test UAT end-to-end in PR #881 che copre 3-user send funds su 10 round con spese non confermate, il primo test di flusso di funding multi-utente nella suite di test Angor. La release ha aggiunto anche un piano di implementazione per una CLI Angor e un server MCP (PR #792), con miglioramenti CLI per il workflow di test MCP in PR #880. PR #885 di DavidGershony ha corretto un invoice lightning Boltz che usava la rete sbagliata dopo un cambio di rete a runtime, un bug che sarebbe emerso in produzione dopo il default mainnet di v0.2.30. Le impostazioni offrono ora una purga opzionale del file wallet di recupero durante il data wipe (PR #883).

Sprout v0.3.15: refresh del TTL dei canali effimeri e comandi slash ACP

Sprout v0.3.15, rilasciato il 10 giugno, è l’ottava release in una serie iniziata con v0.3.7 il 2 giugno. La Newsletter #25 ha coperto la serie da v0.3.1 a v0.3.6 con l’integrazione mesh-llm e il lavoro sulle sezioni di canale; da v0.3.7 a v0.3.15 sono a valle di quello, focalizzate su rifiniture e alcune aggiunte rivolte all’utente. La modifica più visibile all’utente è un refresh del TTL per canali effimeri in PR #902: quando un utente disarchivia un canale effimero, Sprout estende il time-to-live del canale così il disarchivio non ri-archivia immediatamente sotto il timer di scadenza originale. Gli emoji custom mobile arrivano in PR #906 insieme a un redesign delle impostazioni, e i conteggi delle reazioni ora animano al cambiamento (PR #904).

PR #905 corregge un gap di lunga data in cui i display name multi-parola si rompevano e l’estrazione di mention NIP-27 nostr:npub cadeva silenziosamente. Una UI di team basata su directory per desktop è rilasciata in PR #912 con comandi install, sync e reveal. I comandi slash ora passano ai connector ACP in PR #919, consentendo a Sprout di inoltrare comandi in stile /help direttamente ai runtime degli agenti mentre la UI di Sprout resta fuori dal percorso.

Wisp v1.1.1: integrazione wallet Spark e guardia contro il paste di nsec

Wisp v1.1.1, rilasciato il 5 giugno, porta una schermata Connect wallet a due livelli con sub-schermata Spark in PR #548 e parità dashboard con la UI wallet iOS in PR #549. La release include una guardia contro il paste di nsec a livello di sistema che rileva un paste con prefisso nsec1 ovunque nell’app e blocca il campo dall’accettarlo, chiudendo uno degli errori più citati nella UX Nostr. Il login QR-scan più una modalità watch-only per npub e nprofile è rilasciato in PR #552, consentendo a un utente di sfogliare un profilo in sola lettura. I messaggi zap ora si rendono come mini-post nel drawer di engagement (PR #559) così le note zap portano il loro testo insieme all’importo in sat. Un filtro web-of-trust sulle risposte al thread arriva in PR #583, consentendo agli utenti di nascondere lo spam di risposte da account fuori dal loro grafo di follow.

Nostria v3.1.46 e nospeak 1.1.3: rifacimento delle notifiche e restart ICE

Nostria v3.1.46 del 7 giugno chiude una serie di tre release che ha rifatto il contatore delle notifiche per contare solo le nuove notifiche dalla vista precedente, eliminando un’inflazione di lunga data in cui caricare notifiche più vecchie scrollando faceva salire il conteggio del badge. Nostria v3.1.45 ha corretto un bug di split-payment che colpiva pagamenti lightning e QR-code e ha abbandonato una UI traslucida precedentemente pianificata come non fattibile sul compositor Android.

nospeak v1.1.3 del 4 giugno aggiunge il restart ICE su stato FAILED per chiamate voce 1-on-1. Il comportamento WebRTC standard scarta una chiamata quando i candidati ICE vanno in timeout senza un percorso alternativo; il percorso di restart ICE rinegozia i candidati così la chiamata recupera da cambi transitori di NAT o rete. Le chiamate Android ora tengono lo schermo acceso durante le videochiamate.

Modifiche non rilasciate

Amethyst: 41 PR che continuano la traccia NIP-32 / NIP-F4 / Tor

Amethyst ha mergiato 41 PR questa settimana senza tagliare una release tag, sopra le 52 PR della scorsa settimana e il lavoro sull’etichettatura hashtag NIP-32 e podcast NIP-F4 trattato nella Newsletter #25. La branch attiva continua ad accumulare funzionalità per la prossima release taggata, stratificando rifiniture sulle aggiunte principali della scorsa settimana: scoperta di labeler hashtag, schermata podcast, tracce musicali e playlist, watchdog di auto-heal Tor, signer effimeri per upload anonimi e zap onchain con filtraggio NIP-05. Il throughput di PR di Amethyst resta il più alto di qualunque client Nostr, e la coda non rilasciata è la roadmap de-facto per ciò che altri client Nostr Android dovranno eguagliare.

Damus: tracciamento dei relay dai messaggi OK e changelog v1.17

Damus PR #3786, mergiata il 3 giugno, aggiunge i messaggi OK riusciti da un relay alla lista dei post-relay. Le build precedenti di Damus popolavano la lista dei relay visti solo quando ricevevano un messaggio generico dal relay, il che significava che un relay che confermava il post ma non consegnava eventi era invisibile all’utente. Il cambiamento conta per gli utenti che vogliono confermare che il loro post sia arrivato sul loro relay outbox preferito. PR #3796 corregge un ciclo AttributeGraph su Profile View, e PR #3725 porta il changelog v1.17 in vista della prossima release taggata.

Shopstr: dual-publishing NIP-34

Il repo shopstr su ngit di Shopstr è stato annunciato su Nostr questa settimana come repo git NIP-34, unendosi ai repo tracciati di ngit. Il repo GitHub del client shop resta la superficie primaria di sviluppo; l’annuncio NIP-34 rende disponibile un percorso parallelo di collaborazione git-over-Nostr. Questo è il secondo grande progetto marketplace Nostr a dual-publish su NIP-34 dopo Mostro, e continua la migrazione graduale dei metadati di progetto sul trasporto git di Nostr.

Hermes-Marmot: gateway di agente AI su MLS

hermes-marmot, un plugin per l’Hermes Agent, connette la superficie di messaggistica di un agente AI ai gruppi Marmot (MLS-over-Nostr) usando mdk-python, i binding Python al Marmot Development Kit Rust. Il plugin consente a un utente di DMare un agente AI da qualunque client Nostr che parla messaggi MLS di kind 445, incluso Whitenoise. I DM in ingresso usano l’unwrapping gift-wrap NIP-59 tramite i binding Python di nostr-sdk, e i welcome in ingresso fluiscono attraverso UnwrappedGift.from_gift_wrap a mdk.process_welcome e mdk.accept_welcome. Il controllo di accesso passa attraverso MARMOT_ALLOWED_USERS (una allowlist di npub separata da virgole) o MARMOT_ALLOW_ALL_USERS=true per accesso di sviluppo aperto.

Il repo è nuovo (ultimo aggiornamento 27 maggio) e piccolo. La sua importanza è architetturale: è il primo ponte pubblico fra un runtime di agente LLM e un canale di messaggistica Nostr cifrato con MLS, e il primo uso in produzione di mdk-python oltre a Whitenoise stesso. Il pattern punta verso comunicazione agente-a-agente in cui entrambi gli endpoint detengono chiavi MLS e il relay vede solo ciphertext.

Aggiornamenti NIP e lavoro di spec di protocollo

NIP-67 hint di completezza EOSE (PR #2317) mergiato

PR #2317 di mattn mergiata il 6 giugno, aggiungendo NIP-67 al protocollo. Il NIP estende il messaggio relay EOSE con un terzo elemento opzionale: ["EOSE", <subscription_id>, "finish"] segnala che ogni evento memorizzato che corrisponde al filtro è stato consegnato, mentre un nudo ["EOSE", <subscription_id>] non porta alcuna dichiarazione di completezza. Un relay che omette l’hint sta dicendo al client che potrebbe esserci di più; un relay che omette la pubblicità NIP-67 in NIP-11 mantiene il comportamento di oggi sotto l’euristica legacy esistente. Il cambiamento è backward compatible in entrambe le direzioni: i client legacy ignorano l’elemento finale dell’array e i relay legacy lo omettono.

La motivazione nella spec mergiata è duplice. Primo, perdita silenziosa di dati: un client chiede le ultime 500 note contro un relay con un cap interno di 300 eventi, il relay restituisce 300 eventi, e il client (usando l’euristica standard received < limit) conclude che il risultato è completo. La 201esima fino alla N-esima nota più vecchia che corrisponde restano sul relay non lette, con il client cieco a quel fatto. Secondo, round-trip sprecati obbligatoriamente: quando un relay cappa le risposte a 300 eventi, qualunque sottoscrizione che esaurisce il cap richiede un secondo REQ con until=<oldest_created_at> puramente per confermare il completamento, anche quando il filtro corrisponde esattamente a 300 eventi. Entrambe le modalità di fallimento sono pagate da ogni client su ogni sottoscrizione che esaurisce il cap. L’hint "finish" è una stringa opzionale su un messaggio esistente ed elimina entrambi i costi.

Estensione autocomplete NIP-50 (PR #2357) mergiata

PR #2357 di Alex Gleason mergiata il 6 giugno, aggiungendo un token autocomplete:true/false alla ricerca NIP-50. L’estensione consente a un client di marcare una query come un lookup typeahead così il relay usa prefix matching, con la full-text search come default per query senza il token. Il relay di Ditto lo implementa per follow pack, lista e qualunque evento con un tag title, restituendo match contro il prefisso del titolo; il percorso di ricerca di default esegue lo scoring full-text. Senza questo token, le UI stile autocomplete non avevano modo di comunicare l’intento di prefix search e i relay dovevano indovinare dalla forma della query. Il token è un hint per-ricerca, non una capability a livello relay, così un relay può implementarlo per una classe di eventi (titoli) senza rivendicare supporto autocomplete generale.

NIP-GART alert di emergenza e broadcast di posizione (PR #2374)

PR #2374 di disinqa, aperta il 9 giugno, definisce un wire format a tutela della privacy su Nostr per alert di emergenza e broadcast di posizione indirizzati a un gruppo di destinatari fidati. L’obiettivo di design dichiarato è nascondere l’identità del mittente, l’appartenenza al gruppo e il payload agli operatori del relay mantenendo gli eventi replay-safe e verificabili tramite firma end-to-end. Il numero NIP è ancora TBD, la proposta è in bozza iniziale. Il caso d’uso è il pattern standard di alert di emergenza: un utente sotto minaccia broadcasta un ping di posizione che solo un gruppo pre-condiviso di contatti fidati può decifrare, con il relay cieco a mittente, set di destinatari e payload. I dettagli del wire format vivono nella PR e probabilmente evolveranno mentre i manutentori revisionano.

Metodo logout NIP-46 (PR #2373)

PR #2373 di hzrd149, aperta l'8 giugno, aggiunge un metodo logout a NIP-46 così un client può dire esplicitamente a un bunker che la sessione è terminata. Finora, l’unico modo per terminare una sessione bunker era aspettare il timeout della sessione o smettere di usare la connessione, entrambi i quali lasciano il bunker a detenere stato di sessione per un client che è scomparso. La proposta è breve (un nuovo metodo) ed è il tipo di modifica di manutenzione che rende le integrazioni bunker a lungo termine più pulite.

Proposta ibrida relay-P2P NIP-95 circolata come long-form

Una specifica NIP-95 long-form è circolata come post kind:30023 dall’npub 91bea5cd9361504c409aaf459516988f68a2fcd482762fd969a7cdc71df4451c il 4 giugno sotto il titolo Protocolo Híbrido Relay-P2P via WebRTC. Il documento in lingua portoghese definisce un protocollo relay ibrido peer-to-peer in cui i client Nostr si connettono l’uno all’altro direttamente via WebRTC per la messaggistica live continuando a usare i relay per il recupero di eventi memorizzati e la consegna offline. L’autore ha esplicitamente inquadrato la spec come “LLM-ready”, fornendo definizioni di messaggi, flussi logici, schemi di dati e regole di stato a un livello di dettaglio che lascia a un modello AI la possibilità di generare codice client o server funzionante. La proposta non è ancora arrivata come PR NIP; la circolazione tramite kind:30023 è il precursore usuale a una pull request formale su nostr-protocol/nips.

NIP-44 v3 prende un secondo signer: Clave porta la spec

Il rollout di NIP-44 v3 di Amber v6.2.0 della scorsa settimana è arrivato prima di qualunque PR NIP mergiata, lasciando v3 come estensione specifica di Amber che altri client dovevano rispecchiare per interoperare. Quell’inquadratura a singola implementazione è cambiata questa settimana. Clave, il remote signer iOS NIP-46 basato su push, ha portato un porting indipendente di NIP-44 v3 il 3 e 4 giugno attraverso otto commit. Le primitive crittografiche sono rilasciate in tre commit: layer di chiavi HKDF + ECDH, l’algoritmo di padding v3 e un’API pubblica di alto livello più Context di cifratura. Sopra questi, la superficie NIP-46 segue in wiring del dispatch RPC dentro LightSigner e uno schema PendingRequest che porta il contesto v3 (kind più scope), così il signer può registrare per quale kind di evento e caso d’uso il payload v3 è stato approvato.

Clave diverge da Amber sulla superficie rivolta all’utente. Uno schema di grant di permesso con tier di sensibilità consente agli utenti di garantire la cifratura v3 per un particolare kind di evento e scope a un livello di sensibilità scelto. Al primo incontro, prompt di approvazione consapevoli del contesto v3 con una card di explainer una-tantum introducono v3 agli utenti. Il lavoro è in main ed è collegato al progetto Xcode ma non è rilasciato; la build taggata più recente è v0.2.0-build79 del 12 maggio.

Due implementazioni indipendenti portano NIP-44 v3 in percorsi di produzione prima che la PR NIPs sia mergiata, il che rafforza il caso per il wire format sottostante che la PR di protocollo formalizzerà. Il testing di interop cross-implementazione diventa ora il percorso alla convergenza della spec, con la superficie di approvazione Android di Amber e il modello di tier di sensibilità iOS di Clave come i due punti di riferimento. Altri remote signer che collegano v3 (il noauth di nsec.app è stato dormiente da maggio 2025, e altri bunker non hanno annunciato lavoro su v3) restringerebbero ulteriormente il consenso.

Attività NIP-34: Iris adotta lo stack con un nuovo trasporto hashtree

Iris ha pubblicato annunci di repo NIP-34 per hashtree l'8 giugno e iris-apps, iris-drive e iris-chat-rs il 9 giugno, pubblicizzando URL di clone sotto un nuovo schema htree:// servito da wss://temp.iris.to. Il trasporto hashtree è un’alternativa content-addressed ai clone instradati via GRASP, e questi quattro annunci sono i suoi primi usi pubblici. I repo portano descrizioni vuote e i dettagli architetturali stanno ancora emergendo, ma la scelta di pubblicare tramite annuncio NIP-34 (sopra un manifest Iris-interno custom) segnala che Iris si sta impegnando allo stack più ampio git-over-Nostr NIP-34.

NIP deep dive: NIP-67 (EOSE Completeness Hint)

NIP-67 chiude uno dei gap di correttezza più antichi di NIP-01. La spec originale definisce EOSE come il confine tra eventi memorizzati e eventi di sottoscrizione live per un REQ, ma non ha mai specificato se il relay avesse finito di consegnare tutti i match memorizzati o si fosse fermato a metà a causa di un cap interno. Ogni relay impone un cap per-sottoscrizione (comunemente da 300 a 1000 eventi) indipendente dal limit del client, e i client non hanno avuto modo di osservare quel cap.

Il workaround standard era confrontare il conteggio ricevuto con il limit richiesto. Se received < limit, trattare il risultato come completo; altrimenti paginare con until=<oldest_created_at>. Entrambi i branch sono rotti. Il branch received < limit tronca silenziosamente: un client che chiede 500 note contro un relay cappato a 300 vede 300 eventi, conclude che il risultato è completo perché 300 < 500, e non recupera mai il resto. Gli eventi trattenuti sul relay non possono segnalare “altro disponibile” attraverso alcun messaggio esistente. La paginazione come secondo branch è sprecona: un filtro che corrisponde esattamente al cap richiede un secondo REQ per confermare la completezza, restituendo zero eventi mentre consuma una scansione di filtro completa sul relay.

Il fix di NIP-67 è una stringa opzionale sul messaggio EOSE:

["EOSE", "<sub_id>", "finish"] // esplicito: tutti gli eventi memorizzati consegnati
["EOSE", "<sub_id>"] // nessuna dichiarazione di completezza

Un relay che pubblicizza NIP-67 nei supported_nips di NIP-11 ed emette un EOSE nudo sta dicendo al client che c’è di più. Un relay che omette la pubblicità mantiene il comportamento di oggi, e il client ricade sull’euristica esistente. I client legacy ignorano l’elemento finale dell’array. La compatibilità all’indietro tiene in entrambe le direzioni, senza nuovi verbi o kind di evento.

Ciò che rende NIP-67 degno di esame è lo scope che deliberatamente restringe. La spec non definisce cursore o token di paginazione, quindi la paginazione basata su until resta il meccanismo. I cap dei relay restano dove sono, e il NIP non richiede alcuna esposizione di essi. NIP-67 preserva il significato di EOSE come confine memorizzato-a-live e aggiunge solo un segnale sì-o-no al confine: “Ho di più per te” contro “questo è tutto”. Questa superficie minima è perché la PR è stata mergiata dopo un periodo di review relativamente breve per un’estensione di NIP-01, e perché mattn nota esplicitamente nella PR che è stata usata la traduzione AI per il testo inglese. Il cambiamento è abbastanza piccolo che l’incertezza della traduzione non conta.

Esempio di scambio consapevole di NIP-67 tra un client e un relay che impone il cap. Pubblicità NIP-11 dal relay:

{
 "id": "a5f87fe2d4c8b9a0e3f1c4d5e6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1781136000,
 "kind": 11,
 "tags": [],
 "content": "{\"supported_nips\":[1,11,50,67]}",
 "sig": "f1e2d3c4b5a6978869504132c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5"
}

Lo scambio a livello di wire che segue:

→ ["REQ", "abc", {"kinds":[1],"limit":500}]
← [...300 EVENT messages...]
← ["EOSE", "abc"] // no "finish": cap raggiunto, altro disponibile
→ ["REQ", "def", {"kinds":[1],"limit":300,"until":1780900000}]
← [...178 EVENT messages...]
← ["EOSE", "def", "finish"] // completo esplicito

La risposta di 178 eventi prima avrebbe innescato una terza REQ per confermare il completamento. Con NIP-67 il client si ferma lì.

NIP-67 è notabile anche come emendamento a NIP-01 che arriva con raro consenso. La maggior parte dei cambiamenti a NIP-01 attrae lunghi thread di dibattito perché la superficie minuscola del protocollo è portante per ogni implementazione. NIP-67 è stato mergiato dopo un periodo di review esteso (all’incirca sette settimane dall’apertura al merge), suggerendo che quando un cambio NIP-01 è abbastanza piccolo e la modalità di fallimento è abbastanza concreta (perdita silenziosa di dati, round trip sprecato obbligatorio), i manutentori del protocollo sono disposti a estendere il vocabolario dei messaggi core.

NIP deep dive: NIP-50 (Ricerca)

NIP-50 definisce il campo di filtro search nei messaggi REQ, consentendo ai client di chiedere a un relay di filtrare eventi tramite match full-text contro una stringa di query. La spec base mergiata è deliberatamente minima: il campo search è una stringa, ciascun relay decide la propria semantica di ricerca (quali campi sono indicizzati, come funziona lo scoring, se si applica lo stemming), e i relay pubblicizzano il supporto NIP-50 nel loro documento NIP-11. I client controllano l’algoritmo di ricerca solo tramite la stringa di query stessa.

Questo minimalismo è sia la forza sia il vincolo di NIP-50. La forza è che qualunque relay può implementare la ricerca a qualunque livello di qualità: una scansione di sottostringa di base soddisfa la spec, e un relay che esegue Elasticsearch o Meilisearch la soddisfa ugualmente. Il vincolo è che i client mancano di un modo per esprimere l’intento di ricerca. Una UI typeahead di mention di profilo vuole prefix matching contro i display name; una ricerca di contenuto full-text vuole scoring full-text tokenizzato attraverso il corpo della nota. Lo stesso campo search porta entrambi, e il relay deve indovinare dalla forma della query.

PR #2357 aggiunge il primo token di estensione NIP-50: autocomplete:true o autocomplete:false incorporato nella query di ricerca segnala quale modalità il client vuole. Il relay di Ditto implementa il token per follow pack, lista e qualunque evento con un tag title, passando al prefix matching quando autocomplete:true è presente. Il token vive inline nella query (i campi di filtro separati restano intoccati), così viaggia con la stringa di ricerca e non richiede alcun bump di wire protocol:

search: "fiat autocomplete:true"

Hint in forma di token come questo sono il modo in cui NIP-50 ha sempre gestito dialetti relay-specifici. I relay supportavano già token come language:en e domain:example.com. Ciascuno resta relay-specifico, con ciascun relay che documenta il proprio dialetto. La PR #2357 di NIP-50 eleva autocomplete da un token relay-privato a uno benedetto dalla spec, aprendo la strada a ricerca typeahead-aware attraverso i relay.

Esempio di REQ NIP-50 con il token autocomplete, mirato a un relay che indicizza i titoli di profilo di kind 0:

{
 "id": "b7c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f7081a2b3c4d5e6f70819a2b3c4d5",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1781136000,
 "kind": 1,
 "tags": [
 ["client", "example-mention-picker"]
 ],
 "content": "Sent search: kinds=[0], search=\"fiat autocomplete:true\", limit=10",
 "sig": "12d3e4f5061728394a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f7081a2b3c4d5e6f70819a2b3c4d5e6f7081a2b3c4d5e6f708192"
}

L’effettivo REQ a livello di wire:

["REQ", "mention-picker", {"kinds":[0],"search":"fiat autocomplete:true","limit":10}]

Un relay che non riconosce il token tratta autocomplete:true come parte della stringa di ricerca letterale e ricade sul matching full-text, restituendo risultati corretti (se classificati diversamente). La degradazione graziosa rende il token sicuro da includere incondizionatamente per client che preferiscono il prefix matching quando disponibile.

La prossima probabile estensione NIP-50 è il controllo di ranking per-kind: un hint che dice “classifica per created_at decrescente” contro il default relevance score. Diversi relay accettano già sort:newest come token relay-privato, e lo stesso percorso di elevazione che ha portato autocomplete nella spec si applica. La ricerca resta una delle poche primitive Nostr dove i relay competono sulla qualità del risultato; l’affidabilità della consegna è la stessa attraverso tutti i relay conformi. Token incrementali consentono ai client di sfruttare quella competizione di qualità senza forzare i relay a rilasciare una nuova spec pesante.

Nostr Compass #25

Wed, 03 Jun 2026 00:00:00 +0000

Amber 6.2.0 rilascia la cifratura NIP-44 v3 prima della spec. Mostro porta le fondamenta per l’escrow regolato con Cashu attraverso otto PR, avvolgendo l’esistente Cashu Development Kit come secondo backend di regolamento accanto a Lightning. NIP-F4 podcast è mergiato dopo 27 mesi di dibattito. fiatjaf apre una proposta contestata di disaccoppiamento delle chiavi NIP-17 che riapre la discussione architetturale bunker-contro-Marmot. Amethyst porta l’etichettatura di hashtag NIP-32, una schermata podcast dedicata e gli zap onchain attraverso 52 PR non rilasciate.

Storie principali

Amber 6.2.0: cifratura NIP-44 v3 rilasciata

Amber v6.2.0, rilasciato il 1° giugno, aggiunge il supporto alla cifratura NIP-44 v3 con una schermata di approvazione dedicata, anteprima dell’intent, anteprima bunker, logging della cronologia e auto-reject per richieste non valide. La release registra anche le autorità ContentProvider NIP-44 v3 così altre app Android possono richiedere la cifratura v3 insieme al percorso v2 esistente. NIP-44 stesso è la spec versionata di payload cifrato usata dai DM privati NIP-17, dal traffico bunker NIP-46 e da altre primitive Nostr; v3 in Amber è opt-in accanto a v2, segnalato da un metodo signer separato così i client lato ricevente possono negoziare l’algoritmo esplicitamente. La corrispondente PR nel repo NIPs deve ancora arrivare, quindi Amber sta rilasciando v3 prima del consensus di protocollo, con il wire format e l’autorità ContentProvider registrati per l’integrazione dei client a valle.

Le sessioni NIP-46 ora auto-accettano le richieste di ping alla connessione, rimuovendo il prompt sul primo round trip dopo il pairing. Il metodo signer sign_message è stato rimosso completamente dopo essere stato deprecato e non utilizzato.

Poiché Amber è il signer Android dominante, ogni client a valle che vuole v3 deve puntare al wire format di Amber finché la PR NIPs non arriva. Ciò dà ad Amber implicitamente voce in capitolo sulla spec finale v3 finché il protocollo non recupera. Il trade è reale: v3 in produzione lascia che Amber raccolga feedback implementativi per l’eventuale NIP, al costo di un punto di riferimento a singola implementazione temporaneo che gli altri client ora devono eguagliare.

Mostro: integrazione dell’escrow Cashu tramite CDK

grunch ha portato otto PR attraverso MostroP2P questa settimana integrando le primitive multisig P2PK esistenti di Cashu (NUT-10 e NUT-11) come secondo backend di regolamento accanto a Lightning sull’exchange Bitcoin P2P coordinato via Nostr. Le primitive crittografiche sono di Cashu; il lavoro è impalcatura di integrazione e un nuovo trait di backend escrow. Mostro core v0.12.0, rilasciato il 30 maggio, aggiunge i tipi di protocollo per l’escrow multisig 2-di-3, firme P_M per-proof e consente eventi escrow attraverso la validazione della risposta. L’architettura è documentata in PR #756 e usa chiavi di trade per-order chiarite in PR #757.

L’implementazione è stata dispiegata attraverso sei PR di follow-up in un solo giorno. F2 (PR #758) ha aggiunto la configurazione, la modalità escrow e il boot condizionale. La fetta successiva, F3 (PR #760), ha definito un trait EscrowBackend con un’implementazione Lightning e uno stub Cashu, consentendo a Mostro di cambiare backend di regolamento senza cambiare la macchina a stati degli ordini. F4 (PR #759) ha wrappato CDK (il Cashu Development Kit) per operazioni di mint e wallet. Il lavoro sul database in F5 (PR #761) ha aggiunto lock escrow compare-and-swap e query active-locked. F6 (PR #762) ha costruito una mint containerizzata in un job CI dedicato per il test end-to-end dell’escrow. Il flusso Mostro usa già DM gift-wrapped NIP-59 per la coordinazione degli ordini sul relay, così l’escrow Cashu si inserisce come una seconda opzione di regolamento accanto a Lightning senza toccare il wire protocol.

Rilasci

ngit v2.5.0: fallback GRASP e fetch git pigri

ngit v2.5.0 cambia il comportamento di default di git push pr/<branch> e ngit send per produrre un PR kind per nuove proposte quando il repository ha almeno un server GRASP registrato. In precedenza questo si attivava solo per commit sovradimensionati oltre i 60 KB o commit contenenti submoduli. Quando un PR non può essere pushato ai server GRASP del repository, ngit ora ricade su routing GRASP-06 attraverso i server dichiarati. Il flag ngit send --git-server o git push -o git-server=<url> consente ai contributor di puntare esplicitamente a un URL git custom o server GRASP.

I republish di ngit init ora preservano i tag sconosciuti dagli annunci esistenti, così i tag aggiunti da una futura versione di ngit o da uno strumento di terze parti sopravvivono al republish. Un warning giallo elenca i tag riportati, e --clean li rimuove su richiesta. ngit pr apply, ngit pr checkout e ngit pr list consultano i server git pigramente e condividono un singolo helper di fetch, così il checkout non fa più fetch incondizionato quando il commit è già locale. ngit pr checkout prova anche URL di clone forniti dal submitter dall’evento PR come fallback quando i server git dichiarati del repo non portano la punta del PR, corrispondendo al comportamento esistente in ngit pr apply. ngit è l’implementazione di riferimento NIP-34 per la collaborazione git su Nostr, e v2.5.0 rende GRASP il percorso di prima classe per i nuovi contributor.

Jumble v26.5.7: rimozione EXIF e conteggi zap validati

Jumble v26.5.7 aggiunge due modifiche che influenzano direttamente la privacy dell’utente e l’integrità dei dati. Gli identificatori di posizione EXIF e della camera sono ora rimossi dagli upload di immagini prima che lascino il client, chiudendo una superficie di lunga data di leak di metadati che ha colpito ogni immagine postata da Jumble. I conteggi degli zap sono ora calcolati solo da ricevute validate crittograficamente, correggendo conteggi gonfiati da eventi zap malformati che avevano lasciato agli attaccanti la possibilità di esagerare i totali degli zap sulle note. La release aggiunge anche la verifica dell’identità del mittente per i DM NIP-17, chiudendo una superficie di spoofing in cui un mittente poteva falsificare il proprio pubkey nel seal.

nostr-calendar v1.6.0: RSVP e gestione dei partecipanti duplicati

nostr-calendar v1.6.0 porta il flusso RSVP di Formstr (PR #169) e impedisce partecipanti duplicati negli inviti a eventi (PR #168). L’opzione waitForAll nella funzione di publish ora ha come default false così la UI non si blocca su relay lenti (PR #170). PR #157 ha rilasciato le due bozze di proposta NIP di Formstr per la programmazione di appuntamenti e prenotazioni.

Sprout 0.3.6: Sprout × mesh-llm e sezioni di canale

Sprout v0.3.6 è la principale di una serie di sei release da v0.3.1 a v0.3.6 questa settimana. L’integrazione in-process Sprout × mesh-llm arriva in PR #798, consentendo a Sprout di servire e consumare nodi mesh-llm tramite ammissione dal relay. Le sezioni di canale definite dall’utente si sincronizzano fra dispositivi via Nostr in PR #792, e le sezioni di canale arrivano su mobile con sync via relay in PR #800. Le notifiche thread-aware con controlli di follow e mute mutabili arrivano in PR #761.

Gli allegati file di tipo arbitrario con card di download sono arrivati in PR #810, espandendo Sprout oltre gli allegati solo immagine. Mobile ha guadagnato una tab feed sociale Pulse (PR #772) e rifiniture Pulse fra feed, compose e superfici di filtro (PR #796).

NostrBotKit v0.5.0: chat di gruppo Marmot in un framework di bot Rust

NostrBotKit v0.5.0, rilasciato il 24 maggio su Codeberg, aggiunge il supporto Marmot (MLS-over-Nostr, NIP-104) al framework di bot Rust self-hosted. Quando marmot: true è impostato, il bot pubblica i suoi key package MLS (kind 443, 30443, 10051), accetta inviti di gruppo automaticamente e ascolta i messaggi nei gruppi a cui è unito. Due nuovi tipi di comando, dm_marmot e dm_marmot_npub, consentono ai bot di inviare messaggi in gruppi Marmot con nome o chat Marmot 1:1 tramite cron job o webhook. Per prevenire loop di feedback con altri bot, i bot NostrBotKit rispondono solo a messaggi esplicitamente indirizzati a loro tramite /command o @botname/command. Gli allegati cifrati che usano MIP-04 sono decifrati automaticamente e ri-caricati via Blossom o NIP-96, e il database di stato MLS è cifrato con una chiave derivata dalla chiave privata del bot. NostrBotKit è il primo framework Rust a rilasciare il supporto ai bot NIP-104, aprendo il deployment di bot cifrati Marmot a un profilo operatore diverso dal percorso TypeScript esistente.

noscrypt v0.1.14: rilascio firmato della libreria di crittografia

noscrypt v0.1.14 è una release di sicurezza della libreria di crittografia C usata da diversi client Nostr per le primitive secp256k1, NIP-04 e NIP-44. La release è distribuita con download PGP-firmati verificabili contro la chiave pubblica del manutentore. I client a valle che integrano noscrypt dovrebbero validare la firma prima di integrarla.

Chama v1.3.0: nuovo escrow P2P Nostr-native con Fedimint

Chama v1.3.0, rilasciato il 1° giugno, è la principale di una serie di quattro release per un nuovo client di escrow P2P Nostr-native che usa ecash Fedimint e secret sharing Shamir 2-di-3 per il regolamento. Il progetto è rilasciato a getchama.app e gira senza server. v1.3.0 introduce “heal that sticks” (re-broadcast riuscito e healing del trade che sopravvive ai riavvii di sessione) e pay-rail matching, dove le Chama US-leaning mostrano prima le rail di pagamento US. Le fondamenta per storefront multi-unità sono arrivate attraverso v1.2.11 (schema multi-unità) e v1.2.12 (accountant per lo stock dello storefront + hardening del recovery del bridge Fedimint nativo). Chama si unisce a Mostro e Shopstr nella categoria marketplace Nostr, distinta per la sua architettura serverless e il regolamento escrow basato su Fedimint.

Modifiche non rilasciate

Amethyst: etichettatura hashtag NIP-32, schermata podcast, tracce musicali

Amethyst ha mergiato 52 PR e 411 commit questa settimana senza tagliare una release tag. La più grande aggiunta funzionale è PR #3111, che implementa l’etichettatura hashtag NIP-32 e un feed hashtag basato su etichette usando eventi di kind 1985 con namespace L e tag di etichetta l. Questo sostituisce il fragile meccanismo di corrispondenza testuale #tag con un modello di scoperta basato su labeler dove gli utenti possono seguire specifici npub labeler nel modo in cui seguono i creator di contenuto. PR #3105 aggiunge una schermata podcast dedicata con lista degli episodi e player inline, arrivando entro pochi giorni dal merge della spec podcast NIP-F4. PR #3071 aggiunge un feed Software Apps con filtraggio per follow list, e PR #3067 aggiunge il supporto a tracce musicali e playlist tramite set NIP-51.

I signer effimeri per upload di post anonimi arrivano in PR #3123, consentendo agli utenti di postare anonimamente senza esporre la propria chiave di identità ai servizi di upload. Un watchdog di auto-healing Tor con test di integrazione contro Arti v2.3.0 arriva in PR #3053, rafforzando il routing Tor di Amethyst durante outage di rete transitori. Gli zap onchain e un filtro NIP-05 per utenti che ritornano da Gemini arrivano in PR #3052, ampliando la superficie di zap oltre Lightning ai pagamenti Bitcoin onchain.

Shopstr: validazione degli URL di anteprima OpenGraph

PR #504 valida gli URL di anteprima OpenGraph prima di renderizzarli negli annunci del marketplace, chiudendo una potenziale superficie XSS in cui venditori malevoli potevano incorporare contenuto scriptato tramite metadati OG appositamente costruiti. Gli shop ospitati su Shopstr mostrano anteprime OG per link esterni, e URL non validati permettevano a un attaccante di iniettare contenuto arbitrario nella UI dello shop.

Aggiornamenti NIP e lavoro di spec di protocollo

NIP-F4 (Podcast) mergiato dopo due anni

PR #1093 è stato mergiato il 28 maggio, due anni e tre mesi dopo che fiatjaf ha aperto la bozza originale. NIP-F4 definisce gli episodi di podcast come eventi di kind 54 con tag imeta per i metadati del file audio (URL, mime type, codice lingua ISO, URL di fallback, flag di servizio NIP-96, bitrate, durata), un tag title, tag opzionali image e description e tag t per etichette di topic. La spec mantiene deliberatamente RSS come fonte di verità: gli episodi possono portare un tag i che fa riferimento al GUID del podcast RSS, consentendo ai client Nostr di collegarsi ai feed di podcast esistenti senza duplicare l’hosting audio. Il lungo dibattito nel thread della PR (con Dave Jones co-autore del podcast-namespace, Alex Gleason e Mike Terenzio) si è concluso su un modello di coesistenza in cui Nostr fornisce il layer sociale sopra RSS mentre RSS mantiene il layer di distribuzione. La PR #3105 schermata podcast di Amethyst arriva entro pochi giorni dal merge della spec, e il lavoro sul picker GIF di Jumble include anche fondamenta iniziali per l’allegato podcast.

Disaccoppiamento delle chiavi NIP-17 (PR #2361)

fiatjaf ha aperto PR #2361 il 1° giugno, proponendo che NIP-17 separi la chiave di identità dalla chiave di cifratura. I destinatari pubblicizzano la loro chiave di cifratura in un nuovo evento di kind 10044, e i mittenti usano quella chiave pubblicizzata (quando presente) per il seal interno del gift-wrap, ricadendo sulla chiave di identità del destinatario solo quando la pubblicità è assente. La PR aggiunge anche un tag n al seal che porta la pubkey di cifratura del mittente, così i destinatari possono derivare la conversation key corretta senza decifratura per tentativi contro ogni chiave ritirata. La motivazione dichiarata è la UX bunker: sotto il design attuale, un utente bunker deve fare round-trip di ogni DM ricevuto attraverso il signer per decifrare, poiché la chiave di cifratura è la chiave di identità detenuta dal signer. Il disaccoppiamento lascia che il client detenga la chiave di cifratura localmente mantenendo la chiave di identità nel bunker per le firme.

La proposta ha attirato la review più contestata della settimana. Cody Tseng (Jumble) la sostiene come il percorso più facile per l’interop DM cross-client. Vitor Pamplona (Amethyst) obietta su due basi: aggiunge un nuovo secret di decifratura a lungo termine fuori dal bunker, e i client che non lo rilasciano falliranno silenziosamente a decifrare i messaggi dai client che lo fanno, senza percorso di degradazione perché la rottura è al layer del seal. Pamplona argomenta che il problema è già risolto correttamente dai key package e dalla rotazione di epoch di Marmot, e che retrofittare la separazione delle chiavi nella spec base NIP-17 crea il tipo di fallimento di interop che Marmot ha impiegato due anni a progettare per aggirare. La controrisposta di fiatjaf ha tre parti: il disaccoppiamento è opzionale per destinatario, il fix dell’n-tag affronta la preoccupazione della decifratura per tentativi, e l’alternativa è mantenere rotta la UX bunker mentre Telegram divora il caso d’uso della messaggistica. Il thread resta aperto senza una decisione di merge ed è la discussione NIP più osservata del trimestre.

NIP-Silent Payments flusso di pagamento (PR #2362)

silentius-satoshi ha aperto la PR #2362 il 1° giugno come compagno della più ampia bozza NIP Nostr Silent Payments (PR #2355). Il NIP del flusso di pagamento definisce il kind 8352 per le notifiche di ricevuta di silent payment (consegnate tramite gift wrap NIP-59 così il link di ricevuta non è pubblicamente osservabile) e il kind 10353 per una cache UTXO cifrata che si sincronizza fra i dispositivi per lo stesso wallet Silent Payments. La coppia insieme consente a un pagatore di segnalare un pagamento a un indirizzo Silent Payments usando primitive Nostr-native senza esporre il link on-chain al layer aperto dei relay.

NIP-PIP Perfect IP Packets (PR #2364)

RandyMcMillan ha aperto la PR #2364 il 1° giugno come bozza. Introduce un trasporto ad albero di pacchetti con tre nuovi kind indirizzabili: 39078 porta il manifest, 39079 porta gli slice individuali, e 39080 porta le richieste di riparazione. La spec definisce un wire format in cui file grandi sono spezzati in slice indirizzabili, con manifest che descrivono l’albero degli slice e richieste di riparazione che consentono ai destinatari di chiedere slice mancanti. Si applica lo status di bozza iniziale, e la proposta non ha ancora attirato la review dei manutentori.

NIP-29 spazi live audio/video (PR #2238)

PR #2238 mergiata il 28 maggio, estendendo i gruppi basati su relay NIP-29 con supporto a spazi live audio e video. I gruppi possono ora fare riferimento a una sessione live-space attiva, consentendo agli eventi live activity in stile NIP-53 di ancorarsi in un contesto di gruppo NIP-29.

NIP-71 video multiple tracce audio (PR #2255)

PR #2255 mergiata il 28 maggio, aggiungendo tag imeta di traccia audio agli eventi video NIP-71. Il nuovo formato porta URL, hash, mime type, tag di lingua (con ISO-639-1 più flag di versione originale), URL di fallback, segnale di servizio NIP-96, bitrate e durata. Questo abilita lo streaming solo audio (video podcast), il cambio di risoluzione con audio stabile, tracce multiple in lingua e ridotto storage quando i server non incorporano l’audio direttamente nei file video. I client dovrebbero controllare la disponibilità di traccia audio prima di assumere un comportamento a traccia singola.

NIP-59 gift wrap effimero (PR #2245)

PR #2245 mergiata il 28 maggio, aggiungendo il kind 21059 come controparte effimera dell’esistente gift wrap di kind 1059. La semantica corrisponde al wrap standard NIP-59 ma segue le regole di eventi effimeri per NIP-01 (i relay li scartano dopo il broadcast e non li persistono). Ciò consente alle app di scegliere la persistenza in base ai requisiti: gli indicatori di digitazione e i ping di presenza beneficiano dell’effimero, mentre la cronologia DM ha bisogno di persistenza.

NIP-78 kind application-specific (PR #2292)

PR #2292 mergiata il 28 maggio, riclassificando i dati application-specific NIP-78 come un normale kind indirizzabile, abbandonando la precedente gamma separata. Questo semplifica la semantica di replaceability e allinea NIP-78 con il modello di eventi indirizzabili usato da altri NIP di stato applicativo.

Chiarimenti NIP-85 (PR #2304)

PR #2304 mergiata il 28 maggio con piccoli miglioramenti al linguaggio attorno a chiavi e relay multipli per service provider nelle Trusted Assertions NIP-85, chiarendo il percorso di rotazione della chiave operatore per i servizi di assertion sui relay.

NIP-01 one-liner sulla gestione della connessione relay (PR #2307)

PR #2307 mergiata il 28 maggio, aggiungendo una singola frase a NIP-01 su come i client dovrebbero gestire i tempi di vita della connessione relay. Il fix affronta un gap di lunga data in cui i client differivano su se tenere le connessioni WebSocket aperte dopo il fetch, portando a perdita silenziosa di messaggi su relay che scartano connessioni idle.

NIP-C7 vincolo di chat kind 9 (PR #2310)

PR #2310 mergiata il 28 maggio, restringendo le viste chat NIP-C7 ai soli messaggi di kind 9. Questo separa la chat effimera dai post di timeline di kind 1 nei client che implementano superfici di chat in stile NIP-C7.

Semplificazione NIP-55 (PR #2363)

PR #2363 di greenart7c3, aperta il 1° giugno, semplifica la spec dell’applicazione signer Android. Vitor Pamplona ha approvato come “Looks good” e fiatjaf ha chiesto se è pronta per il merge. La modifica apre la strada alla registrazione dell’autorità ContentProvider NIP-44 v3 che Amber ha rilasciato questa settimana.

NIP-44 v3 (implementazione Amber prima della spec)

Amber ha rilasciato NIP-44 v3 in v6.2.0 con otto commit che implementano l’upgrade di cifratura e la registrazione dell’autorità ContentProvider, ma la PR della spec nel repo NIPs deve ancora arrivare. NIP-44 stesso definisce un formato di payload cifrato versionato usato dentro eventi firmati; l’esistente v2 (in produzione dal 2024) usa ECDH secp256k1, HKDF, padding, ChaCha20, HMAC-SHA256 e base64. Il wire format v3 aggiunge un nuovo byte di versione (0x03) prima del nonce, consentendo ai client destinatari di negoziare esplicitamente l’algoritmo. L’implementazione di Amber include auto-reject per richieste v3 non valide, una schermata di approvazione dedicata distinta dalle approvazioni v2 e logging del plaintext per direzione per la cronologia. Finché la PR NIPs non è mergiata, v3 rimane un’estensione specifica di Amber. Trattatela come un segnale prospettico, non come una segnalazione stabile a livello di protocollo.

NIP deep dive: NIP-32 (Labeling)

NIP-32 definisce un modo strutturato per qualunque attore Nostr di etichettare eventi, pubkey, relay, URL o topic usando eventi indirizzabili di kind 1985 con un vocabolario di etichette namespaced. La spec introduce due nuovi tag: L denota un namespace di etichetta, e l denota un’etichetta all’interno di quel namespace. I tag di target dell’etichetta (e, p, a, r o t) specificano cosa viene etichettato. Il requisito di namespace impedisce a più sistemi di etichette di collidere: un’etichetta spam in nip28.moderation porta una semantica diversa da un’etichetta spam in relay-report.

La scelta di design che rende NIP-32 utile oltre la moderazione è che le etichette sono asserzioni, non verità a livello di protocollo. Un evento di kind 1985 dice solo che una particolare pubkey ha etichettato un particolare target in un particolare namespace. Il modello di fiducia è delegato al client: ogni client sceglie quali labeler onorare, quali namespace leggere e quale affordance UI dare a ciascuna etichetta. La stessa primitiva porta avvertimenti di contenuto, assegnazione di licenza, tag di lingua ISO-639-1 sulle note di kind 1, tag geografici ISO-3166-2, classificazione di contenuto, suggerimenti di moderazione distribuita e punteggi di reputazione.

La PR #3111 di Amethyst di questa settimana è il più grande deployment finora. Aggiunge l’etichettatura hashtag tramite NIP-32 e un feed hashtag basato su etichette, consentendo agli utenti di sfogliare per etichette assegnate da labeler fidati. Il precedente meccanismo di corrispondenza testuale #tag che originariamente pilotava la scoperta hashtag su Nostr resta come fallback per note non etichettate. Il modello hashtag-come-etichetta significa che la stessa nota può essere scopribile sotto più etichette assegnate da labeler diversi, e gli utenti possono silenziare o promuovere specifici labeler senza influenzare le note sottostanti.

Anche l’auto-etichettatura è supportata. Un autore può attaccare tag L e l direttamente alle proprie note di kind 1 per dichiarare lingua, posizione e topic. Una nota taggata ["L", "ISO-639-1"], ["l", "en", "ISO-639-1"] si auto-identifica come inglese e può essere filtrata da client language-aware senza infrastruttura di etichettatura di terze parti.

Esempio di evento etichetta NIP-32 che tagga una nota di kind 1 come inglese e le assegna un tag di moderazione:

{
 "id": "a5f87fe2d4c8b9a0e3f1c4d5e6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1748908800,
 "kind": 1985,
 "tags": [
 ["L", "ISO-639-1"],
 ["l", "en", "ISO-639-1"],
 ["L", "nip28.moderation"],
 ["l", "approve", "nip28.moderation"],
 ["e", "8b39f4e5d6c7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3", "wss://relay.example.com"]
 ],
 "content": "Labeled as English-language content approved for NIP-28 chat moderation",
 "sig": "f1e2d3c4b5a6978869504132c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5"
}

Il rollout di Amethyst combinato con il recente lavoro sulle Trusted Relay Assertions suggerisce che NIP-32 sta diventando il substrato standard per qualunque pattern di “asserzione guidata dall’utente su un target” su Nostr. Il prossimo test è se i labeler stessi svilupperanno gerarchie di fiducia: se gli utenti seguiranno specifici npub labeler nel modo in cui seguono i creator di contenuto.

NIP deep dive: NIP-F4 (Podcast)

NIP-F4 è stato mergiato questa settimana, due anni e tre mesi dopo che fiatjaf ha aperto la bozza originale (PR #1093). Il prefisso F è semplice numerazione hex: NIP-F0 fino a NIP-FF usano lo stesso spazio hex a 1 byte di NIP-0A fino a NIP-0D, con la gamma hex superiore che serve da overflow ora che la gamma decimale 01–99 si sta riempiendo. NIP-F4 definisce come i podcast pubblicano episodi e metadati come eventi Nostr mantenendo RSS come layer complementare per il file audio stesso.

La scelta architettonica di base è che ogni podcast è la propria keypair Nostr. La spec apre con questo direttamente: “each podcast is its own Nostr keypair”. Ciò consente ai podcast di combinare la loro presenza podcast con una normale presenza di microblogging di kind 0 / kind 1, e consente a un podcast di cambiare proprietà nel tempo tramite handover di chiave o firma condivisa stile MuSig2. Quattro kind di evento portano il layer di pubblicazione:

kind:10154: metadati podcast replaceable. Porta tag title, image, description, tag website opzionali e tag p opzionali che marcano gli autori con un role di host, cohost o editor.
kind:10164: contro-claim dell’autore. L’esempio nella spec usa il kind 10064 (un typo aperto a correzione), ma l’header e il testo circostante lo identificano come kind:10164. Gli utenti elencano le pubkey di podcast di cui sono autori, così i client possono verificare i tag p in kind:10154 contro una claim equivalente dal presunto autore. Senza questo, un podcast potrebbe falsamente taggare chiunque come host.
kind:54: eventi episodio scritti dalla pubkey del podcast direttamente. I tag includono title, image opzionale, description e uno o più tag audio. Ogni tag audio è ["audio", "<audio-url>", "<optional_media_type>"]. La spec nota “other important fields to be specified here later after further discovery”, e la forma mergiata è deliberatamente minima.
kind:10054: una lista di podcast preferiti in stile NIP-51, consentendo agli utenti di marcare quali podcast seguono.

Il dibattito del thread attorno al merge ha coinvolto il co-autore di Podcasting 2.0 Dave Jones, Alex Gleason, Mike Terenzio, Pablo F7z e staab. Jones ha argomentato fortemente contro qualunque tentativo di sostituire RSS: “It’s been tried many times and always fails”, citando JSONfeed, XMPP, AMP, l’API di Twitter e la migrazione fallita di Spotify. Terenzio ha ripresentato la proposta come layer sociale sopra RSS, mantenendo RSS stesso come layer di distribuzione. fiatjaf ha accettato di fare un passo indietro e lasciar maturare la proposta: “I agree with everything you said but I still think we can pull it off, let’s stop here for a while”. Due anni dopo, la spec mergiata atterra più vicina alla coesistenza che alla sostituzione.

Tre domande di design restano esplicite nella spec mergiata:

Il typo del kind:10164 (l’esempio mostra 10064) deve essere riconciliato prima che i client possano interoperare in sicurezza.
La scoperta a livello di episodio senza collegamento GUID RSS è lasciata aperta. La spec mergiata non ha tag i, formato podcast:item:guid o meccanismo di bridging RSS. I client che vogliono fare bridge di un catalogo RSS esistente in eventi di kind 54 devono definire da soli la convenzione di bridge.
Lo stub “other important fields” sulla definizione di kind:54 lascia bitrate, durata, lingua, puntatori a trascrizioni, capitoli e metadati per segmento come territorio aperto per proposte di follow-up.

La PR #3105 di Amethyst porta una schermata podcast dedicata con lista degli episodi e player inline entro pochi giorni dal merge, la prima grande implementazione client. Jumble ha rilasciato le prime fondamenta per l’allegato podcast insieme al suo picker GIF. Wavlake resta la più grande piattaforma podcast Nostr-native e dovrà decidere se allineare i suoi esistenti eventi di traccia musicale di kind 31337 con il modello di episodio di kind 54 di NIP-F4.

Esempio di evento episodio NIP-F4 kind 54, corrispondente al set di tag minimo della spec mergiata:

{
 "id": "55807e7d5cd90d0303d7dce7397f996fdbaed8697903f326c7cf8ad999b9de3d",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1748995200,
 "kind": 54,
 "tags": [
 ["title", "Episode 42: Why RSS Won"],
 ["image", "https://podcast.example.com/ep42-cover.jpg"],
 ["description", "Dave Jones and fiatjaf on protocol coexistence and the social layer."],
 ["audio", "https://podcast.example.com/audio/ep42.mp3", "audio/mpeg"]
 ],
 "content": "In this episode we discuss the two-year journey of NIP-F4 from draft to merge, and why coexistence with RSS turned out to be the right architectural choice.",
 "sig": "abc123def456789012345678901234567890abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef01234567"
}

PR #1093 è stata aperta per 27 mesi, ben oltre la durata mediana di apertura per le PR NIP mergiate. Il prossimo test per NIP-F4 è se il typo del kind 10164 sarà riconciliato, se convenzioni di scoperta di episodi e bridge RSS emergeranno dagli implementatori, e se i principali host podcast pubblicheranno sotto keypair per-podcast come la spec raccomanda.

Nostr Compass #24

Thu, 28 May 2026 00:00:00 +0000

Amethyst v1.11.0 porta un’implementazione completa del calendario NIP-52 con promemoria, split di zap Bitcoin onchain e supporto alle risposte nei gruppi Marmot. White Noise v2026.5.22 rilascia le notifiche push iOS tramite una Notification Service Extension, insieme alla UX di block e a un pulsante per aggiungere membri. Vector v0.4.0 porta un rewrite da zero di vector-core, Tor one-click con bridge, remote signer NIP-46, sincronizzazione MLS di gruppo full-negentropy e un server MCP a 21 tool per agenti AI. Applesauce v6.1.0 introduce liste di lookup relay NIP-51 (kind 10086) e un set completo di factory per git-cast NIP-34. MDK aggiunge i messaggi a scomparsa NIP-40 su iOS e Android tramite una superficie UniFFI unificata, e Mostro v0.17.4 chiude il ciclo del bond anti-abuso con i payout di bond slashati di Fase 3 al vincitore. Notedeck mergia la riconciliazione completa negentropy NIP-77 per giftwrap e backfill dei thread, Cordn appare come messenger MLS mediato da coordinator che scambia una dipendenza di disponibilità a punto singolo per un ordinamento di epoch più stretto e un modello operativo più semplice, un’implementazione di riferimento NIP-B0 chiamata deepmarks rilascia un client di bookmark monetizzato dal curatore, e il team Formstr apre quattro proposte NIP calendario coordinate che coprono l’auto-rimozione dei partecipanti, gli eventi privati, la ricorrenza e la programmazione decentralizzata degli appuntamenti.

Storie principali

Amethyst v1.11.0: calendari, split di zap onchain e risposte Marmot

Amethyst, il client Nostr per Android manutenuto da Vitor Pamplona, ha rilasciato v1.11.0. PR #2994 aggiunge un’implementazione di eventi di calendario NIP-52 con una UI dedicata e un sistema di promemoria, così gli eventi di calendario sono ora resi nella propria categoria di timeline, separata dalla vista generica di kind-30023 long-form. PR #3018 estende gli zap Bitcoin onchain con il supporto agli split, distribuendo una singola transazione Bitcoin fra più destinatari secondo il tag zap-split esistente, così un pagamento onchain si comporta come uno split Lightning. PR #2974 aggiunge una schermata paginata di cronologia delle transazioni onchain che mostra ciascuno zap regolato con lo stato di conferma del blocco.

La messaggistica di gruppo guadagna parità con la chat uno-a-uno: PR #2995 aggiunge il supporto alle risposte per i messaggi di gruppo Marmot/MLS, così i thread all’interno di gruppi cifrati sono ora resi con la stessa UI di riferimento genitore delle note pubbliche. PR #2984 rafforza la validazione delle ricevute zap NIP-57 controllando che il provider LNURL corrisponda al lud16 dichiarato del destinatario, chiudendo una classe di falsificazione in cui un LNURL di terze parti poteva emettere una ricevuta per un pagamento mai avvenuto. PR #2968 accetta dimensioni floating-point nei tag imeta NIP-92, allineando Amethyst con i client che pubblicano valori di densità pixel frazionari da dispositivi come il display Retina dell’iPhone. La release collega anche i Payment Targets, un nuovo tip jar multi-rail su evento replaceable trattato nella sezione protocollo più sotto.

White Noise v2026.5.22: push iOS, UX di block e aggiunta membri

White Noise, il messenger di gruppo protocollo Marmot, ha rilasciato v2026.5.22 con le notifiche push iOS come funzionalità principale. PR #673 implementa una Notification Service Extension (NSE) iOS che decifra i messaggi MLS all’interno del processo dell’extension e li presenta come notifiche di sistema, così gli utenti iPhone non hanno più bisogno che l’app sia in foreground per ricevere messaggi. Il plumbing dei token push Android passa attraverso la stessa pipeline backend, con la NSE per-piattaforma che tiene il ciphertext fuori dal broker.

PR #676 aggiunge una UX completa di block e unblock con flussi di conferma e filtraggio della lista contatti. PR #679 aggiunge il pulsante “Aggiungi membri” richiesto da tempo alla schermata di info del gruppo, chiudendo un gap UX in cui gli admin del gruppo dovevano ricadere sui share link. PR #688 introduce una schermata di impostazioni notifiche iOS dedicata, e PR #687 collega la condivisione tramite long-press per media e messaggi.

MDK aggiunge i messaggi a scomparsa NIP-40 su tutte le piattaforme

Il Marmot Development Kit, il core Rust condiviso usato da White Noise iOS, White Noise Android e qualunque futuro client Marmot, ha mergiato PR #306 per esporre la validazione di messaggi a scomparsa e la gestione della scadenza NIP-40 tramite il bridge UniFFI. La PR è la seconda di una serie in tre parti. iOS e Android ora condividono un’unica implementazione Rust della logica di scadenza; le regole di timing vivono in un singolo percorso di codice auditato consumato da entrambe le piattaforme via UniFFI. PR #307 limita la lunghezza memorizzata delle ragioni di fallimento welcome e le sanifica prima della persistenza, un passaggio di hardening separato che complementa la gestione degli eventi welcome rilasciata la scorsa settimana.

I messaggi a scomparsa in MLS non sono solo una comodità UI. Il tag di scadenza è pubblicato con l’inviluppo del messaggio cifrato, così un destinatario che non apre mai il messaggio ha comunque il ciphertext sottostante che scade a livello relay insieme a qualunque copia in cache nel client ricevente. Con MDK che possiede il percorso di validazione, il comportamento resta consistente fra i client: qualunque implementazione Marmot conforme forza la stessa semantica di scadenza, così un client che rispetta la scadenza mentre un altro fa cache per sempre cessa di essere un rischio di portabilità.

Mostro v0.17.4: la Fase 3 chiude il ciclo del bond slashato

Mostro, il protocollo di exchange Bitcoin peer-to-peer costruito su Nostr, ha rilasciato la Fase 3 del suo rollout di bond anti-abuso in v0.17.4. PR #738 porta il flusso di payout per i bond slashati, prendendo il collaterale confiscato al perdente e distribuendolo al vincitore della disputa. PR #743 aggiunge la Fase 3.5, un messaggio esplicito di conferma di payout al vincitore così che sappia che i sats slashati sono stati regolati, con l’evento di conferma che arriva sulla stessa sessione Nostr della risoluzione della disputa. La Fase 2, trattata la scorsa settimana, ha introdotto lo slashing come azione admin; la Fase 3 è la differenza fra minacciare una penalità e farla rispettare.

PR #746 consente al daemon di finalizzare dispute che non hanno una riga solver, un caso limite che precedentemente bloccava la risoluzione su dispute legacy. PR #748 tollera rate null nella risposta /exrates/BTC di Yadio così un breve outage di Yadio non rompe più il percorso di conversione fiat di Mostro. PR #745 documenta la spec per provider di prezzo multi-sorgente, il fondamento per rimuovere Yadio come single point of failure. Il client mobile Mostro ha collegato il corrispondente percorso di claim di Fase 3 in PR #596.

Applesauce v6.1.0: lookup relay e git cast NIP-34

Applesauce, il toolkit Nostr modulare che alimenta Coracle, noStrudel e lo stack di Pablo F7z, ha rilasciato v6.1.0 attraverso i suoi pacchetti. La release aggiunge il supporto nativo alle liste di lookup relay NIP-51: gli eventi di kind 10086 permettono a un utente di segnalare “chiedi a questi relay se vuoi trovarmi”, accanto alle liste outbox NIP-65 come primitiva di scoperta. Le applicazioni costruite su applesauce-core ottengono un observable reattivo User.lookupRelays$ e un loader corrispondente in applesauce-relay.

Le factory di git-cast NIP-34 arrivano in applesauce-factory, dando a ogni client basato su Applesauce un percorso di una riga per pubblicare annunci di repo (kind 30617), patch (kind 1617) e issue (kind 1621). Le proprietà reattive User.favoriteGitRepos$, User.gitAuthors$ e User.graspServers$ consentono alle applicazioni di elencare repo seguiti da un utente, manutentori di repo e server GRASP configurati direttamente dallo stesso oggetto User. La release corregge anche i metodi manuali del pool che scartavano silenziosamente i relay offline in PR #73.

Notedeck mergia il negentropy NIP-77 per giftwrap e backfill dei thread

Notedeck, il client desktop multi-colonna nativo di Damus, ha mergiato PR #1459 il 25 maggio per collegare la piena riconciliazione negentropy NIP-77 nel percorso outbox condiviso. La PR aggiunge frame client e relay NIP-77, sessioni negentropy locali del relay e un tracker di storia completa outbox che pilota la riconciliazione dei set locali e il fetch di eventi mancanti. I giftwrap di messaggi ottengono la riconciliazione negentropy così gli inviluppi di messaggi privati possono essere recuperati dai relay di lettura dell’account selezionato. Le viste dei thread non sono più limitate dal limite di risposte della sottoscrizione live. Dave PNS sostituisce la sua implementazione negentropy locale a Dave con il percorso outbox condiviso preservando il suo comportamento esistente di storia limitata.

Le sottoscrizioni live e negentropy usano ora filtri separati. Un flusso può mantenere una piccola richiesta live emettendo al contempo un filtro negentropy più ampio per riconciliare ciò che il relay ha già. La PR non abilita intenzionalmente la sync negentropy ampia per home o timeline di profilo, che cambierebbe le caratteristiche di costo a cold-start. La copertura di test è stata aggiunta per riconciliazione, consegna di giftwrap, backfill dei thread, ripristino di Dave PNS, cambio account, retargeting dei relay, retry di fetch e comportamento relay NIP-77.

Vector v0.4.0: rewrite di vector-core, Tor, NIP-46, MLS full-negentropy e una superficie di agente MCP

Vector, il messenger cross-platform focalizzato sulla privacy costruito su DM NIP-17 e gruppi Marmot, ha rilasciato v0.4.0. La novità è un rewrite dell’engine da zero: tutta la logica di Vector vive ora in un singolo crate disaccoppiato, vector-core, condiviso fra desktop, Android e qualunque futuro client, con oltre 440 test nel core stesso e la shell dell’applicazione ridotta di migliaia di righe. Il rewrite è la base per una CLI Vector, bot e SDK che pilotano lo stesso codice di protocollo della GUI.

L’integrazione Tor è rilasciata con routing del traffico one-click e supporto ai bridge per il bypass della censura. Il supporto multi-account arriva con uno switcher in-app. Il login con remote signer arriva tramite NIP-46 con pairing bunker via QR o URI incollato, così gli utenti possono accedere senza mai esporre il proprio nsec. Delete-for-everyone funziona sia nei DM NIP-17 sia nelle chat di gruppo Marmot, con Vector che mantiene la chiave di firma effimera come divergenza dalla spec deliberata che le note di release evidenziano esplicitamente: “una diversione dalle spec tradizionali NIP-17/Marmot per controlli di privacy utente potenziati”. La chiave effimera trattenuta dà ai client Vector una prova locale che un’eliminazione è stata sanzionata dal mittente originale, ma significa anche che qualunque altro client che tocca Vector vede una superficie di verificabilità dell’eliminazione diversa dai client NIP-17/Marmot baseline.

La sincronizzazione dei gruppi MLS è ora completamente riconciliata su negentropy NIP-77, la stessa direzione che Notedeck ha preso per giftwrap e thread questa settimana. L’uploader Blossom fa failover su più server, impara le capability di ciascun server e sincronizza la lista dei server fra i dispositivi. I pacchetti di emoji custom sono creabili dall’utente, condivisibili e cross-compatibili con altri client Nostr. La memoria SQLite è scesa da circa 308MB a 5MB. Il pannello emoji si apre dalla cache su disco e gli shortcode stile Discord (:smile:) più il ranking di frequenza Unicode mostrano il glifo giusto per primo.

L’aggiunta più originale è vector-agent, un server MCP (Model Context Protocol) che espone 21 tool così gli agenti AI possono pilotare Vector: inviare DM, gestire gruppi, caricare file, modificare profili. Questo è il secondo progetto Nostr questa settimana (insieme a Shopstr) a rilasciare una superficie MCP, e la prima applicazione di classe messenger a farlo. Combinato con AgentNoise (trattato la scorsa settimana), il pattern di client Nostr controllati da agenti si muove da esperimenti isolati a una direzione di piattaforma deliberata.

Cordn appare come messenger MLS mediato da coordinator

Cordn (client web a cordn.net, repo a Cordn-msg/cordn e Cordn-msg/cordn-web) è un nuovo messenger MLS che prende una direzione architetturale diversa da Marmot. Dove Marmot è completamente basato su relay senza un coordinator privilegiato (ogni membro del gruppo scrive direttamente ai relay e qualunque relay conforme può trasportare il traffico), Cordn introduce un ruolo di coordinator per-gruppo implementato come un servizio ContextVM. Il coordinator ordina i commit MLS e gestisce la distribuzione dei welcome.

L’argomento di Cordn, dichiarato sulla sua pagina /why, è che MLS come deployato nei messenger di produzione “non è coordination-free” e che “la disseminazione pubblica debolmente ordinata” rende la convergenza dello stato di gruppo “molto più difficile” senza un punto di coordinamento forte. Un design mediato da coordinator fornisce avanzamento predicibile delle epoch e una risoluzione più semplice dei commit concorrenti. I partecipanti si connettono al coordinator usando chiavi effimere, così il coordinator apprende l’ID del gruppo e il timing del traffico di commit ma non quali pubkey a lungo termine sono membri. Qualunque parte che interroghi i relay per un gruppo Marmot può già vedere la stessa superficie: attività del gruppo per ID di gruppo, con il timing inferibile dall’arrivo degli eventi. Cordn riconosce anche che “la fiducia di disponibilità resta” con il self-hosting: un coordinator self-hosted evita la preoccupazione di centralizzazione a livello operatore ma introduce un single point of failure per la vivacità del gruppo. Marmot evita quel single point lasciando l’ordinamento a MLS stesso (le epoch e i messaggi Commit gestiscono l’ordinamento all’interno del protocollo) e distribuendo eventi Welcome via gift wrap NIP-59, al costo della disciplina lato admin: gli admin devono aspettare l’acknowledgement del relay di un Commit prima di inviare il Welcome corrispondente, e i client devono riconciliare commit concorrenti quando la consegna del relay va in gara con una transizione di stato.

Il contrasto merita di essere approfondito da qualunque team che scelga uno stack di messaggistica privata. Marmot scambia una certa complessità implementativa per un deployment agnostico ai relay senza attori privilegiati nel percorso. Cordn scambia una dipendenza di disponibilità a punto singolo per un ordinamento più stretto e un modello operativo più semplice. Entrambi i progetti si basano su MLS e usano Nostr come livello di identità e trasporto. Il disaccordo è su dove viva il costo del coordinamento. I repo cordn-msg mostrano una cadenza di commit stabile con il servizio coordinator implementato su ContextVM e il livello MLS costruito su ts-mls.

deepmarks: bookmark NIP-B0 con pubblicazione monetizzata dai curatori

deepmarks-public è un client di riferimento per la spec di bookmark proposta NIP-B0 (kind 39701), con un’architettura a tre riquadri (curatore, indicizzatore, viewer) e un sistema di tier finanziato da zap NIP-57 diretti al curatore. Il client implementa NIP-B0, NIP-07, NIP-46, NIP-57, NIP-44, NIP-98, NIP-65 e Blossom BUD-01 e BUD-04 per lo storage file. Un tier lifetime da 21.000 sat converte lettori paganti in destinatari ricorrenti di zap per il curatore. Il curatore pubblica gli eventi bookmark, l’indicizzatore li arricchisce con metadati leggibili dalla macchina e il viewer rende il feed; ciascun ruolo è un servizio deployabile separato.

Rilasci

Amber v6.1.0 GA: backup cifrato per-account

Amber è passato da v6.1.0-pre3 alla GA v6.1.0 questa settimana. PR #444 rilascia il backup e ripristino cifrati per il database dei permessi dell’applicazione, e PR #446 divide il backup per account, così gli utenti con più identità Nostr possono fare backup e ripristino di ogni set di grant di app indipendentemente. Il lavoro sulla firma PSBT trattato la scorsa settimana è nel taglio GA.

Citrine: sottoscrizioni per-relay e prevenzione di leak di URL onion

Citrine, il personal relay on-device che viene rilasciato con Amethyst, ha rilasciato due correzioni in questo ciclo. PR #157 passa da una singola sottoscrizione globale a sottoscrizioni per-relay taggate, così due relay sorgente che condividono un filtro kinds: [1] non collidono più sul lato aggregatore. PR #162 filtra gli URL di relay onion quando il proxy Tor in uscita è disabilitato, impedendo che gli indirizzi onion trapelino nel percorso di routing clearnet.

Angor v0.2.27 e v0.2.28: affidabilità dei relay e riconnessione Boltz

Angor ha rilasciato v0.2.27 e v0.2.28. PR #874 corregge un bug di deduplicazione dei relay in cui solo un relay era connesso alla volta, una regressione che degradava silenziosamente l’affidabilità per i progetti con più endpoint relay. PR #876 aggiunge logica di riconnessione WebSocket per il monitoraggio degli swap sottomarini Boltz, così una breve disconnessione non lascia più uno swap in uno stato sconosciuto.

Nostrord v1.1.0: zap NIP-57 e distinzione dei ruoli NIP-29

Nostrord ha rilasciato v1.1.0 con supporto agli zap Lightning NIP-57 per messaggi e profili (PR #98) e una distinzione corretta nel feed di attività fra cambi di ruolo NIP-29 e aggiunte di membri (PR #92), che prima si rendevano in modo identico e oscuravano chi era stato promosso rispetto a chi era stato invitato.

ぬるぬる v1.5.x: keystore MLS SQLCipher e catch-up delle epoch

ぬるぬる (nurunuru, di tami1A84), un client Nostr in lingua giapponese che implementa la messaggistica di gruppo MLS (kind 443) insieme a NIP-44, ricerca avanzata NIP-50, NIP-55 e NIP-70, ha rilasciato cinque release questa settimana. PR #184 introduce la cifratura SQLCipher per il keystore MLS nel layer rust-engine. PR #187 e PR #188 estendono SQLCipher rispettivamente ad Android e iOS, con un passaggio di purga legacy-plaintext e guardie CI. PR #189 e PR #191 aggiungono il catch-up delle epoch peer MLS con una replay cache e un banner di recovery su entrambe le piattaforme, così un client che resta indietro sui commit di gruppo può recuperare senza perdere la conversazione. ぬるぬる è un client Marmot costruito su mdk-core, mdk-sqlite-storage e mdk-storage-traits da marmot-protocol/mdk, così il lavoro su SQLCipher e catch-up delle epoch atterra dentro lo stesso runtime MDK che White Noise usa.

Bitcredit Core v0.5.10: correzione della propagazione di blocchi con radice Nostr

Bitcredit Core ha rilasciato v0.5.10 con una correzione per un campo Nostr-node-id mancante durante la propagazione dei blocchi, che rompeva i flussi di creazione azienda che includevano l’upload dell’identità. Bitcredit è un protocollo di e-bill che usa identità Nostr come radice di fiducia per gli eventi di propagazione di aziende e bill.

Modifiche non rilasciate

Jumble ha aperto PR #797 per il login Google tramite il threshold signer Pomegranate, consentendo a un utente di dividere la propria chiave Nostr fra più parti così nessun singolo signer detiene l’intero segreto. Questo è un passo significativo oltre i flussi bunker o import di nsec: un utente può recuperare il proprio account anche se una parte signer è compromessa, senza che quella parte detenga mai la chiave privata completa.

Shopstr ha aperto PR #492 inizializzando un server MCP (Model Context Protocol), con PR #494 che costruisce l’infrastruttura di supporto (fetch dei relay, parser, validazione, errori, deduplicazione, audit logging) e PR #472 che aggiunge una allowlist di relay per il gestore di relay MCP. Ciò rende Shopstr il primo marketplace Nostr a esporre se stesso come server MCP, così gli agenti AI possono navigare e agire su annunci NIP-99 come uno strumento strutturato.

Keydex, il vault di secret-sharing Shamir, ha aperto una migrazione sostanziale in PR #226 spostando i kind custom 1337-1345 nella gamma 713-721, insieme a PR #239 che aggiunge AEAD sopra le share Shamir e PR #234 che migra all’aritmetica GF256. La migrazione della gamma di kind allinea Keydex con il modo in cui il repo NIPs alloca i kind custom, allontanandosi da una gamma auto-reclamata.

Mill (nostr-mill) è una nuova UI di signer Nostr drop-in di OceanSlim (manutentore del relay Go grain), rilasciata come Web Component a singolo script-tag su npm e jsDelivr. Un tag <script> dà a un’app web tutti e sei i punti di ingresso comuni del signer dietro una UI unificata: estensione browser NIP-07, bunker NIP-46 (URL incollato o pairing QR con relay specificabili dall’utente, insolito fra le integrazioni bunker in-pagina), Amber NIP-55 via Android intent, nsec cifrato memorizzato in sessionStorage via AES-256-GCM con PBKDF2, npub read-only e generazione di keypair nel browser. Il componente è personalizzabile tramite 29 proprietà CSS custom collegate allo Shadow DOM ed espone una piccola API tracciata SemVer (MILL.open, eventi mill:connected / mill:disconnected, esportazioni di tema con nome). La motivazione del manutentore è che i flussi di login bunker sono stati re-implementati un’app web alla volta attraverso Nostr. Consolidare su un componente condiviso consente ai client di convergere su come la UX del signer dovrebbe comportarsi, e trasforma flussi opzionali (come il login con chiave delegata tramite threshold signer, che rispecchia il login Google basato su Pomegranate di Wisp trattato sopra) in una superficie riutilizzabile che qualunque app può inserire. Mill è a npm v1.5.0, single-maintainer, stadio alpha, con grain come primo integratore pianificato.

moStard, un fork Monero-first di noStrudel di roguehashrate, ha raggiunto v1.0.1 questa settimana con un set di funzionalità ridotto e un’identità a tema Monero stratificata sullo stesso stack Applesauce + worker-relay. Il lavoro di questa settimana ha portato il rendering per gli eventi software-application di kind 32267 di Zapstore (embed card nella timeline che mostrano nome dell’app, icona, screenshot, piattaforma, licenza e un link di lancio a zapstore.dev/apps/<d-tag>), sondaggi via kind 20 e kind 21, tipping basato su NIP-A3 Payment Targets con QR code per metodo, rendering markdown nelle note, supporto del picker GIF per tastiere GIF esterne e correzioni al pairing del signer Amber. L’inquadratura Monero si estende al flusso di tip: le voci payto NIP-A3 per indirizzi monero ottengono pulsanti di prima classe nella stessa UI insieme a lightning e bitcoin. Il client è single-maintainer e in fase alpha, ma il lavoro del 27 maggio mostra un builder che tira NIP-A3 dagli annunci di spec di protocollo di questa settimana direttamente in un fork rilasciato entro pochi giorni.

Aggiornamenti NIP e lavoro di spec di protocollo

Stack NIP calendario: quattro proposte dal team Formstr

Ix2 (@geralt-debugs) ha aperto quattro PR NIP coordinate il 17 maggio, tutte riferendosi all’implementazione calendar.formstr.app già rilasciata sotto lo stesso autore. PR #2350 propone il kind 84 come un evento generalizzato di “auto-rimozione partecipante”: un partecipante taggato su qualunque evento può pubblicare un kind 84 che fa riferimento all’originale via tag e, a e k per segnalare opt-out. I relay devono validare che il firmatario del kind 84 appaia in un tag p dell’evento di riferimento prima di onorare la rimozione, e un’eliminazione di kind 5 ha sempre precedenza. La PR generalizza un pattern che era precedentemente descritto solo dentro il contesto calendario NIP-52, così il kind 84 diventa il modo standard per i non-autori di ritirarsi da qualunque evento partecipante.

PR #2351 è il fondamento dello stack calendario: NIP-52E per eventi di calendario privati (kind 32678 basato sul tempo, 32681 evento giornaliero, 32123 lista calendario privata, 31926 lista busy, 1052 gift wrap, 52 rumor) e NIP-52R per eventi ricorrenti. Al centro architetturale c’è il pattern view-key: una keypair generata casualmente cifra il contenuto dell’evento con NIP-44, e la metà segreta (codificata bech32 come nsec) è gift-wrapped a ciascun partecipante. Il firmatario detiene solo il tag d pubblico; tutto il resto vive nel content cifrato. Disaccoppiare la cifratura del contenuto dall’identità in questo modo significa che modificare un evento non richiede di re-chiavare i destinatari. NIP-52R definisce due tag opzionali sui kind esistenti 31923 e 31922 per dichiarare la ricorrenza usando valori RFC 5545 RRULE nudi, con l’indice di giorno D che diventa opzionale quando RRULE è presente. La forward secrecy è esplicitamente assente: una view key trapelata rivela tutte le versioni passate e future dell’evento sotto lo stesso tag d.

PR #2352 costruisce su NIP-52E con una spec di programmazione appuntamenti decentralizzata che la descrizione della PR chiama “un’alternativa drop-in a Calendly/Cal.com senza intermediario centrale”. Il kind 31927 pubblicizza una pagina di scheduling con finestre di disponibilità cifrate; il kind 32680 è un record di recovery self-encrypted lato host per la view key; i kind 1057 e 1058 sono la richiesta e la risposta di booking gift-wrapped. Il meccanismo intelligente: il booker genera sia il tag d sia la view key per il futuro evento privato prima di inviare la richiesta, così il booker può aggiungere l’appuntamento al proprio calendario immediatamente con la chiave corretta, e l’host non deve mai fare round-trip di una chiave. Le risposte di booking portano un tag status non cifrato sul wrap esterno così i relay possono filtrare senza decifrare.

Un’implementazione di riferimento è già live a calendar.formstr.app e come app Calendar Android su Zapstore. PR #2351 chiude PR #2027 a suo favore, consolidando una proposta precedente di calendario privato che era aperta dall’inizio dell’anno.

Payment Targets e Silent Payments

Due proposte NIP in più hanno circolato questa settimana in documenti kind:30023 long-form.

Una proposta Payment Targets (NIP-A3 / payto) definisce un evento replaceable di kind 10133 che porta uno o più tag ["payto", "<type>", "<authority>"] che mappano a URI payto: RFC 8905. I tipi supportati includono bitcoin, lightning, ethereum, monero, nano, cashme, revolut e venmo. L’intento è standardizzare un tip jar multi-rail che complementi (non sostituisca) gli zap NIP-57 basati su lud16. Amethyst v1.11.0 è il primo implementatore; le PR mergiate #2953 e #3009 rilasciano la superficie di sottoscrizione e osservazione, e PR #3011 collega la UI per PaymentTargetsEvent.

Due proposte Silent Payments concorrenti sono arrivate da autori diversi. La prima variante deriva le chiavi scan e spend di silent-payment BIP-352 da nsec tramite tweak additivi pubblici, così qualunque mittente può costruire un indirizzo sp1q... da un npub senza setup. L’avvertimento dell’autore è esplicito nella spec: “bscan e bspend DEVONO essere trattate esattamente con la stessa cura di nsec”, perché la chiave di scan rivela l’nsec. Una seconda variante prende l’approccio inverso, aggiungendo un campo sp_address ai metadati profilo di kind 0 contenente un indirizzo silent-payment BIP-352 standard le cui chiavi sono tenute indipendenti dall’identità Nostr. La variante due è strutturalmente più sicura. Entrambe le proposte hanno attratto un thread di review ponderato; erskingardner (lead di Marmot) ha postato un commento dettagliato sul gist trbouma che traccia la proposta. La sua preoccupazione centrale è che la variante 1 deriva la chiave privata di scan da nsec più un tweak calcolabile pubblicamente, il che significa che chiunque detenga la chiave scan (incluso un servizio di scansione di terze parti a cui l’utente deve delegare in pratica) può recuperare il nsec completo sottraendo quel tweak. La stessa chiave che consente a un servizio remoto di scansionare i pagamenti in arrivo per te consente anche a quel servizio di rubare la tua identità e qualunque fondo derivato da essa.

Sul lato NIP-34 git-over-Nostr, hzrd149 ha pubblicato 2 patch a schemata. gitworkshop.dev stesso ha attirato due segnalazioni di issue: una che segnala che le sessioni di login vengono perse al refresh della pagina quando si usa un remote signer NIP-46, l’altra che chiede uno styling di link distinto nelle anteprime README.

Sei anni di May di Nostr

L’ultima newsletter di maggio 2026 fa un passo indietro dai rilasci della settimana per attraversare il mese di maggio nella storia di Nostr. Ogni anno ha avuto un baricentro diverso: il 2021 è stato un singolo commit, il 2022 la formazione del repo NIPs stesso, il 2023 l’esplosione delle spec di protocollo, il 2024 il ciclo di consolidamento, il 2025 quando il negentropy è stato mergiato e Notedeck di Damus è passato a Beta, e il 2026 è il mese trattato in questo e nei tre numeri precedenti.

Maggio 2021

Nostr aveva sei mesi. L’unico codice Nostr viveva in fiatjaf/nostr e l’intero mese ha prodotto esattamente un commit, ma quel commit è diventato una delle parti più usate del protocollo. Il 22 maggio, fiatjaf ha ridefinito NIP-02 come il NIP della lista contatti. Il messaggio di commit recita: “repurpose NIP-02 and add NIP authorship”, e il credito esplicito va alla PR #16 di arcbtc (Ben Arc di LNbits), aperta il 9 febbraio e chiusa il giorno prima che fiatjaf incorporasse l’idea in NIP-02. Il pitch di arcbtc era piccolo: un kind per “inviare la lista dei follower ai relay” che sarebbe stato “utile per ripristinare account e raccomandare chiavi pubbliche da seguire”. fiatjaf lo ha generalizzato in un singolo evento kind:3 i cui tag servono tre scopi contemporaneamente. Sono una lista di follow (il grafo sociale), uno store di petname (nickname locali per gli amici) e una sorgente di raccomandazione di relay (quali relay usa un follow). Lo stesso evento, replaceable per autore, è diventato la risposta canonica a “chi segue questa persona”, “come li chiama” e “dove legge”. Ogni client costruito nei successivi cinque anni legge kind:3. La convenzione aggiunta nello stesso commit, che ogni NIP nomini il proprio autore, è la ragione per cui ogni spec ha ora una firma.

Maggio 2022

Il mese in cui il repo NIPs è diventato un progetto di comunità. Il 1° maggio, fiatjaf ha migrato le spec da fiatjaf/nostr in un repo dedicato nostr-protocol/nips e il 2 maggio ha aggiunto i criteri formali di accettazione. Due giorni dopo, Robert C. Martin (Uncle Bob) ha aperto la PR #1, la prima pull request esterna, proponendo convenzioni di threading per i tag e e p. La PR era originariamente numerata NIP-13, poi rinominata NIP-10 per fare spazio a proof-of-work. Tre dei primi sei NIP sono di Uncle Bob: NIP-10 (threading marker), NIP-14 (il tag Subject) e il commit del 21 maggio che ha fissato kind:1 come il kind canonico di short text-note. Il 5 maggio, William Casarin ha fatto i suoi primi commit NIP: NIP-13 Proof of Work e l’evento kind:2 recommend-relay. Il giorno dopo, fiatjaf ha pubblicato NIP-07 window.nostr, venti righe di markdown che hanno definito l’interfaccia signer browser-extension ancora usata oggi. L’avvertimento CORS di NIP-05 di David A. Harding e il filter.limit di NIP-01 sono arrivati la stessa settimana. nostr-tools ha rilasciato la sua prima build ESM importabile in browser l'8 maggio. Semisol ha redatto NIP-15 (End Of Stored Events) e NIP-16 (event kind ranges) a fine mese, i documenti che ancora governano la semantica di sync dei relay e la classificazione regular-vs-replaceable-vs-ephemeral.

Maggio 2023

L’esplosione di spec di protocollo. Sessantaquattro PR NIP sono state aperte quel mese, con diverse delle proposte che hanno definito la superficie di Nostr per i due anni successivi che sono tutte arrivate in 31 giorni, e il più grande annuncio di finanziamento che Nostr avesse mai ricevuto è arrivato il 4 maggio con il grant OpenSats da 10 milioni di dollari da parte di #startsmall di Jack Dorsey, il denaro che ha finanziato ogni ondata di grant Nostr da allora. NIP-47 (Nostr Wallet Connect) è stato mergiato il 2 maggio, portando la spec di wallet-connect di Alby nel protocollo principale. Due giorni dopo Vitor Pamplona ha proposto NIP-53 Live Activities con room di kind:30311 e messaggi di chat di kind:1311, il fondamento di ogni superficie di livestream Nostr seguita. Pablo Fernandez ha aperto NIP-84 Highlights il 5 maggio e NIP-89 Recommended Application Handlers il 14 maggio. v0l (Kieran Babich, autore di Snort) ha proposto NIP-98 HTTP Auth l'8 maggio, la primitiva di autenticazione da cui NIP-96 e Blossom hanno entrambi in seguito dipeso. Jonathan Staab ha proposto NIP-32 Labels il 15 maggio, e NIP-30 Custom Emoji è stato mergiato lo stesso giorno. Arthur Franca ha proposto NIP-96 HTTP File Storage Integration il 21 maggio. Due giorni dopo, Vitor ha aggiunto gli zap split a NIP-57 e verbiricha ha aggiunto le bozze long-form kind:30024 a NIP-23, la spec che è diventata il fondamento dei moderni workflow di scrittura long-form Nostr in Habla, YakiHonne e Highlighter. fiatjaf ha proposto NIP-29 Simple Groups il 28 maggio, la prima spec di gruppo gestita dal relay che copre gli eventi di moderazione da kind:9000 a kind:9020. Il mese si è chiuso con Paul Miller che apriva la conversazione NIP-44 il 31 maggio, un design di DM cifrato basato su XChaCha20 destinato a sostituire NIP-04. Il lato client si è mosso altrettanto rapidamente: Damus ha rilasciato NWC, zap pool e Pending Zap fra il 10 e il 15 maggio; Snort ha lanciato zap pool e media a paywall L402; Amethyst ha rilasciato circa trenta release versionate nel corso del mese, da v0.40.1 il 1° maggio fino alla gamma v0.55.x a fine mese, con zap split in v0.45.0 ed etichette NIP-32 in v0.46.0; il repo Primal Android è stato creato il 16 maggio; rust-nostr v0.22.0 ha aggiunto NIP-47 e NIP-58. Il 1° maggio, strfry ha rilasciato la sua integrazione negentropy, la prima implementazione relay del protocollo di riconciliazione dei set di Doug Hoyte che sarebbe più tardi diventato NIP-77. Il mese si è chiuso con Forbes che pubblicava un profilo long-form di fiatjaf il 30 maggio, uno dei primi approfondimenti della stampa mainstream sul fondatore anonimo di Nostr.

Maggio 2024

Il ciclo di consolidamento. Meno proposte appariscenti, più cose in rilascio. NIP-54 Decentralized Wikis è stato mergiato il 2 maggio con articoli kind:30818 e tag d normalizzati per case. Tre giorni dopo, NIP-56 è stato esteso così le abuse report potessero segnalare minacce digitali (malware, phishing) accanto alle categorie solo contenuto. Il 6 maggio, le reazioni NIP-25 sono state semplificate per smettere di includere l’intero thread di risposta come tag e. Arthur Franca ha proposto NIP-22 Comment il 12 maggio, introducendo kind:1111 così le risposte a eventi non-kind:1 (articoli, file, prodotti) ottenessero un modo strutturato per fare thread. Il 19 maggio, fiatjaf ha ristrutturato NIP-46 per abbandonare completamente NIP-04 e passare tutto il traffico bunker alla cifratura NIP-44, la mossa di deprecazione che ha plasmato ogni implementazione bunker da allora. Il 20 maggio, NIP-71 Video Events è stato mergiato con kind:21 e kind:22, e NIP-10 ha aggiunto l’argomento pubkey opzionale sui tag e così i client possono risolvere gli autori dei thread senza prima recuperare l’evento di riferimento. NIP-35 Torrents di Kieran Walsh è stato mergiato il 22 maggio, e il 24 maggio il README dei NIP ha per la prima volta fatto riferimento a CIP-01 come una proposta fuori-repo, segnalando l’inizio del pattern “NIP come uno di diversi luoghi di proposta”. Il 25 maggio, una PR di pulizia ha rimosso il tag aes-256-gcm da NIP-71 prima che le implementazioni a valle lo congelassero. NIP-96 ha aggiunto list files e ha eliminato il requisito di transform il 27 maggio. Il 28 maggio, Jonathan Staab ha proposto di alzare l’asticella di accettazione dei NIP per richiedere almeno due implementazioni interoperanti prima che una bozza possa laurearsi. Lato client: Damus ha taggato v1.7.2 e v1.8 più una v1.9 con piena gestione dei marker NIP-10 il 9-10 maggio, ha portato l’autenticazione NIP-98 sulle notifiche push e ha rilasciato il pieno supporto ai marker NIP-10. Amethyst ha reso NIP-17 la modalità DM di default il 14 maggio, ha costruito la gestione dei relay outbox-model NIP-65, ha aggiunto la selezione dei server NIP-96 e ha rilasciato la derivazione di chiavi BIP-32/BIP-39 NIP-06. Primal Android 0.99.2 il 10 maggio ha aggiunto tagging utenti e NWC per wallet esterni, seguita da 0.99.4. Pablo Fernandez ha portato un cluster di optimistic-update NDK dal 24 al 31 maggio. Snort ha aggiunto la selezione dei server NIP-96, e cashu-ts ha separato le sue primitive crypto in @cashu/crypto.

Maggio 2025

Il mese in cui NIP-77 (Negentropy Syncing) è stato mergiato il 27 maggio, la spec di fiatjaf e Doug Hoyte per il wire protocol che sostituisce i filtri REQ brute-force con un calcolo di differenza a costo logaritmico. Questo era lo stesso negentropy che strfry aveva rilasciato due anni prima come funzionalità lato relay, ora formalizzato come protocollo client-relay, e la voce del README è arrivata lo stesso giorno. La settimana prima, NIP-23 long-form ha definito come i documenti HTML si associano a entità Nostr tramite un tag <link> il 24 maggio, la primitiva canonical-web-copy. NIP-25 ha aggiunto gli hint di relay per il target della reazione il 22 maggio e ha abbandonato la raccomandazione emoji-to-like/dislike, trattando le emoji come unità semantiche distinte. NIP-52 è stato semplificato il 14 maggio per focalizzarsi sui kind che i client stavano rilasciando in produzione, la sfoltita che ha reso le estensioni calendario di Formstr di un anno dopo più pulite da innestare. Il 9 maggio, Follow Pack (liste di follow curate di kind 39089) e Favorite Relay (una nuova lista replaceable sotto NIP-51) sono entrati nel README lo stesso giorno. L’arco del Protocollo Marmot non era ancora cominciato: esisteva solo il repo whitenoise-rs (primo commit 9 settembre 2024), e maggio 2025 era la sua fase di prototipo Svelte+Tauri, con il commit del 14 maggio che rimuoveva codice specifico di Tauri mentre il progetto pivotava alla sua architettura attuale. Il core Rust dedicato MDK (12 settembre 2025), il repo spec di Marmot (19 settembre 2025) e la UI Flutter (2 dicembre 2025) sono tutti arrivati dopo nell’anno. Sul lato client, Notedeck v0.4.0 di Damus è stato rilasciato il 5 maggio come prima Beta, laureandosi da Alpha con full-text search, l’assistente AI Dave, zap su NWC, GIF, tagging utenti e mute list. Due giorni dopo, Flotilla 1.0.0 di hodlbod ha attraversato il confine del lancio pubblico come client di group-chat basato su NIP-29, insieme a Coracle 0.6.12, la prima di sei release Coracle che si sono estese fino a 0.6.17 il 14 maggio. Amber v3.4.0 il 12 maggio si è spostato dalle API Autofill e ClipboardManager Android deprecate ed è migrato dalle encrypted shared preferences a DataStore. Primal Android 2.2.20 il 20 maggio ha aggiunto il flusso Redeem Code per Primal Premium e una galleria immagini ridisegnata. nak v0.14.0 il 21 maggio ha tagliato una minor della CLI canonica nella stessa settimana delle release di Coracle, Flotilla e Notedeck. OpenSats ha ricevuto la sua più grande donazione non-Bitcoin-treasury a oggi quando la Reynolds Foundation ha dato 2 milioni di dollari il 22 maggio.

Maggio 2026

Il mese trattato in Newsletter #21, #22, #23 e in questo numero. Il filo definitorio è MLS-on-Nostr che raggiunge produzione multi-client: MDK 0.8.0 ha rilasciato le primitive di leaf-index MIP-05 e i key package indirizzabili, seguito da PR #306 che aggiunge la validazione di messaggi a scomparsa NIP-40 su iOS e Android tramite una superficie UniFFI condivisa. White Noise v2026.5.22+25 ha rilasciato la push iOS tramite una Notification Service Extension che decifra il ciphertext MLS dentro il processo dell’extension così il broker non vede mai plaintext, e sono apparsi due nuovi client Marmot: Scramble (un client desktop e Android .NET/Avalonia con slot KeyPackage multi-dispositivo) e Cordn (un’architettura MLS alternativa che usa un coordinator per-gruppo su ContextVM). Angor ha migrato la sua messaggistica cifrata da NIP-04 a NIP-44 in PR #860, chiudendo l’arco di deprecazione aperto con la proposta NIP-44 di Paul Miller nel maggio 2023. Il team Formstr ha aperto la più grande submission NIP coordinata a memoria recente il 17 maggio, con PR #2350 per l’auto-rimozione dei partecipanti, PR #2351 per eventi di calendario privati e ricorrenza (NIP-52E e NIP-52R) e PR #2352 per la programmazione decentralizzata di appuntamenti, tutti con calendar.formstr.app che già rilascia l’implementazione di riferimento. Amethyst v1.11.0 ha reso i calendari NIP-52 come una categoria di timeline nativa e ha esteso gli zap Bitcoin onchain a distribuzioni split. Un anno dopo che NIP-77 è stato mergiato nel maggio 2025, tre implementazioni indipendenti hanno rilasciato l’adozione negentropy nella stessa finestra: Notedeck PR #1459 l’ha collegata al client desktop di Damus per giftwrap e backfill dei thread, Vector v0.4.0 ha usato la sync MLS full-negentropy come parte del suo rewrite da zero di vector-core insieme al Tor one-click e a una superficie di agente MCP a 21 tool, e Citrine v3.0.0-pre1 l’ha aggiunta al relay Android-nativo insieme a Tor integrato e aggregazione multi-relay. Mostro v0.17.4 ha chiuso il ciclo del bond anti-abuso con i payout di bond slashati di Fase 3 in PR #738, facendo rispettare ciò che il protocollo prima solo minacciava. Tre anni da “sostituiamo NIP-04” a “sostituiamo NIP-44 con lo stato di gruppo MLS completo”.

Se vuoi discutere, mandaci un DM su Nostr.

Nostr Compass #23

Thu, 21 May 2026 00:00:00 +0000

Primal 3.5 rilascia una shell Android ricostruita, Amethyst aggiunge gli zap Bitcoin onchain, White Noise guadagna il rendering markdown e i deep link, Keycast supera un audit di sicurezza e AgentNoise permette di controllare agenti di coding AI locali su chat cifrate Marmot. Hostr lancia una piattaforma di locazione P2P su Nostr con quattro bozze di NIP che coprono annunci, prenotazioni ed escrow basato su EVM. Angor migra la messaggistica cifrata da NIP-04 a NIP-44, Dart NDK aggiunge NIP-77 e un web signer, Alby js-sdk v8 rilascia la riconnessione multi-relay nativa NWC, e KeyChat corregge un gap di forward secrecy nell’eliminazione delle one-time prekey di Signal. Sul lato protocollo, il bond anti-abuso di Mostro raggiunge la Fase 2, Wisp rilascia risposte private e reazioni gift-wrapped, e un’ondata di implementazione NIP-05 su Namecoin tocca una mezza dozzina di client in una sola settimana.

Storie principali

Primal 3.5 per Android

Primal, il client sociale sostenuto dalla propria infrastruttura di relay di caching, ha rilasciato 3.5.9 questa settimana con una shell applicativa ricostruita. Il redesign sostituisce la struttura di navigazione precedente con un layout aggiornato e una nuova schermata Explore, dando alla superficie principale di scoperta la propria home dedicata. La release aggiunge la riproduzione audio per le anteprime dei link, così i file audio incorporati nelle note vengono riprodotti inline senza lasciare il feed. I badge di verifica NIP-05 sono ora mostrati inline sui profili, portando in vista la conferma di identità a colpo d’occhio. Il filtraggio delle notifiche ha ricevuto una revisione, consentendo agli utenti di restringere quali tipi di evento raggiungono la loro lista di notifiche. L’editor ha guadagnato una migliore gestione degli event-link, e il layer di database sottostante ha ricevuto correzioni di stabilità.

White Noise: markdown, deep link e metadati audio

White Noise, l’app di messaggistica di gruppo cifrata con Marmot costruita su Nostr e MLS (RFC 9420), ha avuto una delle sue settimane più intense fino a oggi attraverso i repository frontend e backend.

Sul frontend, PR #665 aggiunge il rendering markdown completo per i messaggi in chat, così grassetto, corsivo, blocchi di codice e link ora sono resi nativamente nella vista dei messaggi. PR #675 abilita il flusso di uscita dal gruppo che era precedentemente bloccato per gli admin non ultimi, e PR #661 aggiunge il supporto nativo ai deep link per gli URI whitenoise:// e whitenoise-staging:// che coprono utenti, chat e impostazioni, senza richiedere alcuna infrastruttura di redirect HTTP.

Sul backend in whitenoise-rs, PR #835 fa funzionare correttamente la rotazione dei key package riutilizzando lo slot d_tag per le pubblicazioni di kind:30443, abilitando la semantica di eventi replaceable NIP-33 così che le successive rotazioni di key package sostituiscano l’evento precedente sui relay, mantenendo solo il key package corrente. PR #833 estende FileMetadata con campi opzionali duration_ms e waveform per gli allegati audio, coordinato con la PR #300 di MDK che aggiunge gli stessi campi ai tag media MIP-04. Un nuovo crate whitenoise-markdown (PR #836) sostituisce il precedente parser di token nostr-sdk con una libreria dedicata al rendering markdown.

La spec del protocollo Marmot stessa ha ricevuto una correzione di sicurezza in PR #68, che chiude un problema di sicurezza specificando esplicitamente HKDF-SHA256 per le derivazioni di chiave immagine in MIP-01, rimuovendo un’ambiguità che poteva portare a divergenze implementative. In MDK, PR #307 sanifica le ragioni di fallimento dei welcome e limita la lunghezza memorizzata, chiudendo una separata segnalazione di sicurezza.

Amethyst v1.10.0: Zap Bitcoin Onchain

Amethyst ha rilasciato quattro release questa settimana, con v1.10.0 come principale. La release aggiunge il supporto agli zap Bitcoin onchain NIP-BC, consentendo agli utenti di inviare, ricevere e visualizzare zap regolati direttamente onchain tramite transazioni Bitcoin. Le release precedenti nella serie hanno corretto la rilevazione di blob Blossom per rifiutare filename non conformi (v1.09.2), patchato le regole ProGuard per le build desktop e mergiato la pull request #2977 per mostrare gli zapper Bitcoin onchain come una riga ₿ dedicata nella galleria delle reazioni espansa. Una schermata in-progress di cronologia transazioni onchain con paginazione è arrivata in PR #2974.

AgentNoise: controllare agenti di coding su White Noise

AgentNoise di nvk è un helper desktop Rust-nativo che consente di usare un telefono che esegue White Noise come superficie di controllo per sessioni di agenti di coding Codex e Claude locali. Lo strumento ascolta una o più chat White Noise, autentica i mittenti tramite un flusso PIN di first-pairing e lancia gli agenti di coding locali tramite il launcher configurato. Inviare /claude <prompt> dal telefono apre una nuova sessione di lavoro White Noise chiamata come l’hostname della macchina e un breve riepilogo del prompt, poi trasmette gli aggiornamenti di progresso e l’output finale a quella chat. È intenzionalmente Rust-first e tiene Node fuori dal percorso trusted del bridge. Il progetto ha raggiunto v0.1.24 questa settimana, aggiungendo risposte più brevi leggibili dal telefono, riferimenti a job per prefisso breve univoco e un watcher opzionale di sessione locale. AgentNoise pilota le CLI wn e wnd di marmot-protocol/whitenoise-rs come sottoprocessi, quindi condivide il proprio trasporto Nostr con il client White Noise stesso.

Audit di sicurezza di Keycast completato

Keycast, il server di remote signing NIP-46 orientato ai team che memorizza chiavi private Nostr cifrate a riposo in SQLite, ha completato un audit di sicurezza nel maggio 2026. Il passaggio di hardening ha affrontato problemi di autenticazione, permessi, integrità dei dati e dipendenze, e i risultati sono documentati in AUDIT.md. Le modifiche includono: l’auth HTTP NIP-98 richiede ora esattamente un tag u e un tag method, rifiuta timestamp obsoleti e valida gli hash payload; l’allowlist ALLOWED_PUBKEYS è parsata esattamente e forzata lato server; le policy vuote ora rifiutano di default le richieste sign/encrypt/decrypt; il rispetto delle foreign key è abilitato sulle connessioni SQLite; e le route app nidificate come /teams/:id sono protette lato server. Una migrazione SQL normalizza il JSON dei vecchi permessi di kind consentiti all’avvio. Il progetto è ancora in fase iniziale e l’audit segnala elementi residui prima di affidargli chiavi di team reali.

Scramble: client Marmot per desktop e Android

Scramble (precedentemente OpenChat) è un client desktop e Android in .NET/Avalonia per il Marmot Protocol, che implementa i MIP 00-04: pubblicazione di KeyPackage (kind:30443), metadati di gruppo con l’estensione MLS NostrGroupData, eventi welcome gift-wrapped NIP-59 (kind:444), messaggi cifrati ChaCha20-Poly1305 (kind:445) e allegati media cifrati Blossom. È pienamente interoperabile con White Noise e con qualsiasi altro client compatibile con Marmot.

Il progetto ha rilasciato 13 release questa settimana, con il supporto multi-dispositivo come funzionalità principale. Ogni dispositivo genera uno slot KeyPackage univoco (un tag d su kind:30443). All’avvio, Scramble recupera i KeyPackage propri dell’utente dai relay, rileva gli ID slot dei dispositivi peer e li aggiunge automaticamente ai gruppi MLS esistenti usando il flusso di staged commit. L’auto-aggiunta è ristretta ai gruppi in cui l’utente corrente è admin; i gruppi non-admin vengono saltati con l’indicazione di chiedere all’admin del gruppo. Un banner informativo di forward-secrecy avvisa i dispositivi appena collegati che i vecchi messaggi non sono disponibili. Un passaggio di riconciliazione degli ID slot (TryReconcileSlotId) gestisce i dispositivi migrati da versioni pre-multi-dispositivo confrontando i byte di KeyPackage del relay con il materiale di chiave locale per adottare il tag d corretto. È stata anche corretta la riconnessione al signer esterno per utenti Amber e NIP-46: la guardia IsConnected che bloccava l’auto-riconnessione interna di ExternalSignerService è stata rimossa in tutti e nove i call site in NostrService.

Hostr: locazione P2P su Nostr

Hostr (sorgente) è una piattaforma di locazione peer-to-peer costruita interamente su Nostr. Copre l’intero flusso stile Airbnb (ricerca e pubblicazione di proprietà, negoziazione di prenotazioni e regolamento dei pagamenti) usando quattro bozze di NIP che il progetto sta sviluppando in parallelo con l’applicazione.

Il NIP di accommodation estende gli annunci classificati NIP-99 (kind:30402 attivo, kind:30403 draft) con tag specifici per l’ospitalità per il tipo (room, house, apartment, villa, hotel, hostel, resort), orari di check-in/check-out, permanenza minima e indici di celle geospaziali H3 per la ricerca basata su posizione con precisione configurabile. Il NIP di prenotazione definisce un protocollo completo di negoziazione e ciclo di vita: gli eventi di prenotazione replaceable di kind:32122 portano un trade ID d, un tag a di ancoraggio all’annuncio e tag p dei partecipanti con ruoli (buyer, seller, escrow); i rumor di messaggio strutturato di kind:1327 consegnano controproposte private in fase di negoziazione tramite gift wrap NIP-59 così la negoziazione resta fuori dai relay pubblici; gli eventi di transizione append-only di kind:1326 creano un audit trail pubblico una volta che una prenotazione viene confermata. La privacy del compratore è preservata tramite chiavi Nostr temporanee per-trade legate all’identità reale del compratore tramite tag participant_proof cifrati. Il NIP di escrow definisce annunci di servizio escrow di kind:30303 e dichiarazioni di fiducia utente di kind:17388; l’implementazione di riferimento usa smart contract EVM su Rootstock, con contractBytecodeHash che permette ai client di verificare che il contratto deployato corrisponda a un’implementazione nota e auditata. Il NIP di marketplace listing definisce tag generici condivisi da tutti i profili marketplace NIP-99, inclusi instantBook, negotiable, quantity, securityDeposit, cancellationPolicy e maxDisputePeriod. Questa settimana il progetto ha preparato la sua submission all’app store e mergiato il supporto all’identità del client MCP per l’automazione rivolta agli agenti.

Due nuove voci sono apparse sulla piattaforma Shakespeare MiniApps questa settimana: InkPress, un generatore di riviste AI che pubblica contenuto strutturato in stile rivista come eventi Nostr, e PressStr, una piattaforma di scrittura e pubblicazione per lo stack Soapbox.

Rilasciato questa settimana

ngit v2.4.4

ngit ha rilasciato v2.4.4, aggiungendo ngit sync --trust-server (-t) per i casi in cui un server git è fast-forward avanti rispetto allo stato Nostr. Quando questa situazione viene rilevata, sync segnala i ref interessati e richiede il flag per firmare e pubblicare un evento di stato aggiornato; un setting git config nostr.trust-server-domains fornisce una allowlist separata da punti e virgola per i server che dovrebbero essere considerati affidabili automaticamente senza il flag.

Amber v6.1.0-pre3 aggiunge la firma PSBT

Amber ha rilasciato v6.1.0-pre3 con un layout migliorato per le nuove connessioni di app, correzioni di crash e un’opzione seleziona/deseleziona tutto nella schermata dei permessi. PR #438 aggiunge il supporto alla firma PSBT sia tramite il percorso Intent-based sia tramite quello NIP-46 basato su relay, permettendo ad Amber di firmare Partially Signed Bitcoin Transactions senza esporre l’nsec all’app richiedente.

Wisp v1.1.0 rilascia risposte private e abbandona il supporto ad Amber

Wisp ha rilasciato v1.1.0 con risposte private tramite gift wrap NIP-17 (PR #540), reazioni gift-wrapped e zap DIP-03 sulle risposte private (PR #543), auto-traduzione per le note (PR #523) e un input fiat stile register sul dialog dello zap. PR #541 migra gli zap privati da uno schema plaintext DM-relay fatto in casa a DIP-03 con un corretto routing DM-relay. Lo stesso ciclo di release ha rimosso il supporto al remote signer NIP-55 (PR #531), abbandonando Amber e altre integrazioni con signer esterni, e ha rimosso il relay locale in bundle (PR #533). Wisp è un client sociale Nostr per Android.

Calendar by Formstr v1.5.4 corregge il gift wrap per i nuovi partecipanti

Calendar by Formstr ha rilasciato v1.5.4 (l’ultima in una sequenza v1.5.2 → v1.5.4). PR #160 corregge un bug in cui l’editing di un evento di calendario privato con nuovi partecipanti pubblicava l’evento aggiornato con le nuove pubkey nei tag p ma non creava né consegnava mai inviti gift wrap a quei partecipanti, rompendo il flusso di invito per aggiunte dell’ultimo minuto. PR #156 aggiunge gestione degli errori attorno alla decifratura degli eventi privati così i client non lanciano più eccezioni su eventi non decifrabili, e PR #138 corregge orari di eventi ricorrenti che stavano andando alla deriva fra fusi orari.

Applesauce v6.1.0 aggiunge git cast NIP-34 e lookup relay NIP-51

Applesauce ha rilasciato v6.1.0 attraverso i suoi pacchetti con un significativo supporto NIP-34 (git-over-Nostr): applesauce-common aggiunge nuovi cast GitRepository, GitGraspList e FavoriteGitRepos più factory corrispondenti, ed espone le proprietà reattive User.favoriteGitRepos$, User.gitAuthors$ e User.graspServers$ così le applicazioni possono elencare i repo git seguiti da un utente, i manutentori dei repo e i server GRASP configurati direttamente dallo stesso oggetto User. La stessa release aggiunge il supporto alle liste di lookup relay NIP-51 di kind 10086, un’aggiunta recente alla famiglia di relay list usata per scoprire dove trovare dati specifici. applesauce-core guadagna replaceableAddress su EventCast per il lookup di indirizzi replaceable NIP-01, più pointer, kind e un helper getReplaceableAddressForEvent, e aggiunge un metodo timeline$() sul cast User base. PR #73 corregge i metodi manuali del pool che scartavano silenziosamente i relay offline.

Sprout v0.0.16 rilascia il binario Sprig e il protocollo huddle v2

Sprout di Block, un workspace di team basato su relay Nostr self-hosted dove esseri umani e agenti AI condividono le stesse stanze e event log, ha rilasciato v0.0.16 dell’app desktop insieme a build rolling del nuovo binario all-in-one Sprig (PR #605), che raggruppa l’harness ACP, l’agente e l’MCP per sviluppatori in un unico binario stile busybox per un deployment facile. Il flag --no-memory aggiunto in PR #611 consente agli operatori di disabilitare l’injection della core memory NIP-AE per l’harness ACP. Sul lato realtime, PR #609 estende il protocollo voice huddle a un header di frame v2 che supporta fino a 10 peer simultanei.

Nostrord v1.0.3 aggiunge keychain OS e multi-account

Nostrord ha rilasciato v1.0.3 con lo storage locale delle chiavi rafforzato usando keychain OS e fallback a passphrase, supporto multi-account e un QR code bunker tappable che apre l’app signer su Android.

Angor migra a NIP-44 e rilascia hardening di sicurezza

Angor, l’app di crowdfunding Bitcoin costruita su Nostr e Taproot, ha rilasciato tre release unstable questa settimana (v0.2.24, v0.2.25 e v0.2.26) con una serie di modifiche di hardening di sicurezza e integrazione Nostr. PR #860 migra la messaggistica cifrata Nostr da NIP-04 a NIP-44, sostituendo lo schema deprecato basato su XOR con la cifratura ChaCha20-Poly1305. PR #861 consente upload media Blossom senza un wallet selezionato usando una chiave di auth Nostr effimera, sbloccando gli upload per gli utenti che non hanno ancora connesso un wallet. La serie di sicurezza ha affrontato diverse categorie hardened: PR #854 aggiunge type safety per AngorKey e protezione della memoria della mnemonic, PR #856 impone validazione a livello di protocollo per timelock, fee rate, soglie di dust e regole di penalty, e PR #851 applica hardening non-breaking attraverso otto categorie di gravità media e bassa. PR #859 corregge la compatibilità con GrapheneOS abilitando la compilazione AOT e rimuovendo la generazione di codice a runtime, e PR #855 previene la perdita del wallet allo swipe-kill Android persistendo lo stato del wallet prima che l’OS termini il processo.

Alby js-sdk v8.0 rilascia la riconnessione multi-relay NWC

Alby js-sdk ha rilasciato la linea v8.0 (da v8.0.1 a v8.0.3) con il supporto alle sottoscrizioni multi-relay NWC. PR #516 aggiorna la dipendenza nostr-tools e abilita l’auto-riconnessione nativa attraverso più relay, sostituendo il precedente approccio a polling con una logica di riconnessione nativa del relay. PR #542 sostituisce tutte le chiamate console.debug con un’interfaccia logger iniettabile così gli sviluppatori di applicazioni possono instradare la diagnostica dell’SDK attraverso la propria infrastruttura di logging. La release abbandona il polyfill WebSocket, richiedendo Node.js 22 o superiore per i consumer lato server. v8.0.2 ha aggiunto una correzione per un bug di import crypto utils che rompeva certi bundler.

KeyChat v1.41.1 corregge la forward secrecy

KeyChat, un’app di messaggistica che combina il protocollo Signal con il trasporto tramite relay Nostr, ha rilasciato v1.41.1+6513. La correzione principale impone la forward secrecy eliminando le one-time prekey di Signal immediatamente dopo una decifratura riuscita, chiudendo un gap dove una prekey trattenuta poteva essere usata per decifrare messaggi passati se il dispositivo fosse stato successivamente compromesso. La release aggiunge anche l’anteprima URL per i messaggi consistenti in un singolo link, centralizza l’auto-download dei media sotto un nuovo FileDownloadManager con una soglia automatica di 20 MB, e rifattora il fetch delle informazioni di relay NIP-11 per forzare il refresh al cold start così le configurazioni di fee dei relay a pagamento vengono sempre caricate correttamente.

In sviluppo

Citrine ha mergiato PR #151 implementando l’enforcement di NIP-70: il relay Android ora blocca i repost che incorporano contenuto di eventi protetti, come richiede la spec. PR #149 aggiunge azioni di visualizzazione e copia per più indirizzi di connessione, localhost, Wi-Fi locale e Tor, dalla schermata delle impostazioni del relay. PR #141 aggiunge la gestione delle challenge AUTH NIP-42 tramite integrazione con signer esterno tramite Amber.

Mostro ha raggiunto la Fase 2 del suo rollout di bond anti-abuso. PR #737 porta la logica di slash di dispute diretta dal solver: gli handler admin ora consumano il payload BondResolution da mostro-core, consentendo a un admin di slashare il bond di una delle parti quando risolve una disputa. La Fase 1.5, mergiata in PR #736, ha introdotto un’azione dedicata PayBondInvoice e uno status WaitingTakerBond, separando il pagamento del bond anti-abuso del taker dal payout di trade del compratore. Il client mobile ha aggiunto la UX completa di Fase 1.5 in PR #592. Mostro è un protocollo di exchange Bitcoin peer-to-peer costruito su Nostr.

Damus ha mergiato PR #3773 ripristinando l’indicatore di segnale del relay, e PR #3775 corregge relay che rifiutavano di riconnettersi dopo un fallimento iniziale di connessione.

rust-nostr ha mergiato PR #1358 aggiungendo trait di finalizzazione degli eventi e builder di eventi specifici per NIP, rendendo più facile costruire eventi correttamente tipizzati per funzioni di protocollo specifiche. PR #1363 porta indietro una correzione che assicura che il signer NIP-46 si sottoscriva alle notifiche prima di inviare la risposta di connect, chiudendo una race condition in cui i messaggi del client che arrivavano immediatamente dopo il connect potevano essere persi.

dart-nostr ha mergiato PR #44 aggiungendo un resolver di relay Namecoin .bit e record di pin TLSA, permettendo alle applicazioni Flutter di risolvere URL di relay wss://example.bit/ tramite DNS Namecoin ai loro effettivi indirizzi WebSocket.

Dart NDK (il Nostr development kit Dart/Flutter, ora in relaystr/ndk) ha mergiato PR #464 implementando NIP-77, il protocollo di firma eventi offline. Sul lato signer, PR #602 e PR #601 aggiungono un event signer specifico per web e un’astrazione PlatformEventVerifier, consentendo alle app Flutter web di usare il signer di piattaforma senza un percorso di codice separato; PR #604 introduce una factory di event signer per la selezione a runtime del signer. PR #608 aggiunge getDmRelays() per recuperare la lista di relay DM NIP-17 di un utente (kind:10050), e PR #600 corregge la preservazione dei campi firmati NIP-46 così i remote signer non perdono campi al round-trip.

Pages by Form* (repo), l’app di documenti collaborativi Nostr-native di Formstr ospitata a pages.formstr.app, ha mergiato quattro PR questa settimana stringendo i flussi di attachment cifrato e gestione documenti. PR #37 corregge immagini mancanti negli export DOCX, HTML e PDF inserendo inline gli allegati cifrati: recupera i blob <encrypted-file> dai server Blossom, li decifra con AES-GCM 256-bit usando la chiave e il nonce memorizzati, valida il MIME type dell’immagine e li converte in URL dati base64 così gli export preservano immagini che esistono solo su Blossom in forma cifrata. PR #39 aggiunge un meccanismo di ricerca documenti locali, PR #38 sistema il flusso di rinomina, e PR #40 corregge la gestione dei backup condivisi.

Zap Cooking ha mergiato PR #396, la prima fase di una revisione del feed che pone le primitive di rendering del feed senza alcun cambiamento ancora visibile all’utente. La PR introduce un parser di tag imeta NIP-92 che legge gli slot url, m (MIME), dim (dimensioni), blurhash, alt, x (hash file) e fallback, più un decoder canonico blurhash portato a mano (~200 LOC) che produce data URL PNG tramite canvas con un fallback null SSR-safe. Quando i tag imeta sono assenti, il parser ricade sull’estrazione di URL grezzi di immagine e video dal contenuto dell’evento usando le stesse euristiche che il feed corrente già usa.

Nurunuru (ぬるぬる, tami1A84/null--nostr), un client Nostr con varianti Android, iOS e Web native che condividono un engine FFI Rust, ha mergiato la sua sync Native → Web v1.5.0 in PR #176. La sync porta diverse aggiunte di funzionalità alla build Web che erano già state rilasciate su Android v1.4.9 e iOS 1.0.4: la NotificationModal ora mostra notifiche di compleanno, rilevazione di zap mutual-follow e notifiche di reazione con emoji custom; il selettore di reazioni abbandona la quick-row di reazioni Unicode di default e centra la UX sulle emoji custom; l’engine di raccomandazione in lib/recommendation.js filtra utenti senza icone o display name e dà priorità alle voci Following con Recommended che carica in background. L’input vocale è l’unica funzionalità che va nella direzione opposta: la build Web usa già lo streaming ElevenLabs Scribe, e v1.5.0 sincronizza parzialmente il lato Native con SpeechRecognizer standard OS (Android) e SFSpeechRecognizer + AVAudioEngine (iOS) mentre l’integrazione Scribe Native completa è rimandata a v1.6.

Lavoro di protocollo e spec

PR #2251 stringe la spec degli eventi protetti NIP-70: ora dichiara esplicitamente che i repost che incorporano il contenuto completo di un evento protetto devono essere rifiutati dai relay. NIP-70 definisce il tag - che segnala che un autore di nota non acconsente a che la sua nota venga ripubblicata. La spec originale copriva il comportamento di filtraggio del relay, ma lasciava ambiguo il caso di repost. Questa PR chiude quel gap. La PR #151 di Citrine implementa l’enforcement sul lato relay in questa stessa settimana.

PR #1653 propone un NIP Drafts per salvare e sincronizzare eventi di bozza privati. La proposta usa eventi replaceable con status draft e cifratura NIP-44 verso la chiave dell’autore stesso, consentendo ai client di salvare lavori in corso sui relay senza che quegli eventi siano visibili a chiunque altro. L’evento draft porta l’evento completo di pubblicazione intesa come contenuto cifrato, incluso il suo eventuale kind e tag.

Snapshots (PR #2279) è una proposta aperta di definire un evento snapshot immutabile per preservare una versione esatta di un evento Nostr replaceable. L’evento snapshot porta il contenuto completo dell’evento replaceable in un dato momento nel tempo, con un tag a che lo collega all’indirizzo dell’evento replaceable così tutte le versioni storiche sono interrogabili insieme. Questo rende possibile agli osservatori ispezionare lo stato storico anche dopo che i relay smettono di conservare le vecchie versioni.

Ondata Namecoin NIP-05: Questa settimana ha visto una spinta coordinata per aggiungere la risoluzione NIP-05 .bit ai client Nostr. Il feed di discussione NIP ha catturato PR open-source contro Aegis (#14, che aggiunge la verifica al momento della firma nel signer), nostter (#2128) e dart-nostr (#44), insieme a una bozza NIP upstream (PR #2349). La PR di Aegis è notevole per aver posto la verifica sul lato produttore: il signer controlla la chain Namecoin prima di firmare qualsiasi evento di kind:0 che rivendica un’identità .bit e avvisa l’utente in caso di mismatch, catturando il problema prima che l’evento raggiunga qualsiasi relay.

NIP Deep Dive: NIP-07 (window.nostr per i browser Web)

NIP-07 definisce l’interfaccia window.nostr che le estensioni browser espongono alle applicazioni web. È l’interfaccia di signer più ampiamente deployata sul web, implementata da estensioni tra cui Alby, nos2x, Flamingo e horse.

L’interfaccia ha due metodi obbligatori e diversi opzionali. window.nostr.getPublicKey() restituisce la chiave pubblica dell’utente come stringa hex senza mai esporre la chiave privata alla pagina chiamante. window.nostr.signEvent(event) prende un evento parziale con created_at, kind, tags e content, e restituisce l’evento firmato completo con id, pubkey e sig aggiunti. Il punto chiave è che la chiave privata non lascia mai il contesto isolato dell’estensione; l’applicazione web sottomette un evento non firmato e riceve indietro uno firmato.

I metodi opzionali coprono la cifratura: window.nostr.nip04.encrypt e window.nostr.nip04.decrypt per il vecchio schema NIP-04 (ora deprecato), e window.nostr.nip44.encrypt e window.nostr.nip44.decrypt per lo schema NIP-44 corrente. Le estensioni che supportano NIP-44 possono quindi gestire sia la cifratura dei messaggi diretti sia qualsiasi altra applicazione che necessita di cifratura keyed su pubkey senza che la pagina chiamante veda l’nsec.

La spec include anche una raccomandazione agli autori di estensioni: caricare gli script con "run_at": "document_end" nel manifest dell’estensione così window.nostr è disponibile in modo sincrono quando la pagina si carica, evitando race condition in cui un client controlla window.nostr prima che l’estensione l’abbia iniettato.

Un esempio chiave di NIP-07 in azione è il progetto Keycast trattato sopra. Il frontend web di Keycast usa NIP-07 per firmare eventi di auth HTTP NIP-98: l’app SvelteKit non gestisce mai direttamente l’nsec dell’utente. Chiama window.nostr.signEvent per produrre l’header di auth, poi invia quell’header all’API Keycast. Questa architettura significa che il materiale della chiave resta nell’estensione browser lungo tutto il flusso di gestione delle chiavi di team.

{
 "id": "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2",
 "pubkey": "7f8e9d0c1b2a3e4f5d6c7b8a9f0e1d2c3b4a5f6e7d8c9b0a1f2e3d4c5b6a7f8a",
 "created_at": 1747785600,
 "kind": 1,
 "tags": [],
 "content": "Hello from a NIP-07 signed event",
 "sig": "0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2cdd"
}

NIP Deep Dive: NIP-39 (identità esterne nei profili)

NIP-39 definisce come un utente Nostr può dichiarare il controllo su identità esterne di piattaforma nel proprio profilo. Ciascuna dichiarazione usa un tag i dentro un evento di kind:10011, asserendo la proprietà di uno specifico account su un’altra piattaforma insieme a una prova che può essere verificata indipendentemente.

Ogni tag segue il formato ["i", "platform:identity", "proof"], dove platform:identity combina il nome della piattaforma e lo username con un separatore due punti (github:semisol, twitter:semisol_public). proof punta a un artefatto verificabile sulla piattaforma stessa.

Per GitHub, la prova è un ID di Gist. L’utente crea una Gist pubblica dal proprio account GitHub contenente il testo Verifying that I control the following Nostr public key: npub1.... Un client che verifica il claim recupera https://gist.github.com/<identity>/<proof> e controlla che la Gist sia stata scritta dallo username GitHub reclamato e contenga la pubkey attesa. Per Twitter la prova è un ID di tweet, per Mastodon un ID di post, e per Telegram un riferimento a messaggio in un gruppo pubblico.

Il nome del provider di identità deve contenere solo a-z, 0-9 e i caratteri ._-/, e non deve contenere :. I nomi di identità dovrebbero essere normalizzati in minuscolo, con l’alias principale usato quando ne esistono multipli.

La discussione NIP-05 .bit Namecoin che avviene questa settimana mostra il ruolo di NIP-39 nello stack di identità più ampio: fornisce un modo standardizzato e agnostico ai relay di cross-referenziare una chiave Nostr con un’identità stabilita altrove, senza richiedere alcuna autorità di verifica centrale. Un client può verificare indipendentemente la prova recuperando un artefatto pubblico sulla piattaforma nominata, e la prova è legata alla specifica pubkey Nostr nel testo della Gist o del tweet, non a una credenziale di piattaforma generica.

{
 "id": "b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3",
 "pubkey": "7f8e9d0c1b2a3e4f5d6c7b8a9f0e1d2c3b4a5f6e7d8c9b0a1f2e3d4c5b6a7f8a",
 "created_at": 1747785600,
 "kind": 10011,
 "tags": [
 ["i", "github:semisol", "9721ce4ee4fceb91c9711ca2a6c9a5ab"],
 ["i", "twitter:semisol_public", "1619358434134196225"],
 ["i", "mastodon:bitcoinhackers.org/@semisol", "109775066355589974"]
 ],
 "content": "",
 "sig": "1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3eff"
}

È tutto per questa settimana. Se stai costruendo qualcosa o hai notizie da condividere, mandaci un DM su Nostr o trovaci su nostrcompass.org.

Nostr Compass #22

Wed, 13 May 2026 00:00:00 +0000

Bentornati a Nostr Compass, la vostra guida settimanale allo sviluppo del protocollo Nostr.

Questa settimana: Nostr VPN pubblica otto versioni in sette giorni, da un flusso di pairing dei dispositivi ridisegnato a uno swap AEAD FIPS che circa raddoppia il throughput TCP. Marmot Protocol (la base di White Noise) pubblica una versione frontend che completa la funzionalità di blocco degli utenti e 31 PR unite su MDK e backend. Grain pubblica v0.6.0 con quattro nuove implementazioni NIP in un unico traguardo. Citrine pubblica v3.0.0-pre1 con Tor integrato e aggregazione relay. Amber pubblica v6.1.0-pre2 con miglioramenti al flusso di connessione e alla firma. Alby Hub pubblica v1.22.2 con una pagina AI e Agenti e l’integrazione Core Lightning. Mostro pubblica i bond del taker concorrenti e mostro-core v0.11.0. Jumble pubblica cinque versioni con la cronologia delle ricerche recenti e correzioni alla persistenza dei dati account. Nostrord pubblica tre versioni con modal di condivisione gruppo e pacchetti Arch Linux. Flotilla pubblica 1.8.0 con videochiamate, rendering email e menzioni di stanza. Calendar by Formstr pubblica v1.5.1 con la pianificazione degli appuntamenti e la sincronizzazione del calendario Android. Tamagostrich lancia un Tamagotchi NIP-78 decentralizzato con ricompense in sats.

Storie principali

Nostr VPN pubblica otto versioni culminando con v4.0.10

Nostr VPN, la VPN mesh decentralizzata basata su Rust che utilizza Nostr per la scoperta dei peer, ha pubblicato otto versioni da v4.0.1 a v4.0.10 su macOS, Linux, Windows e Android. La modifica principale di v4.0.8: l’AEAD è stato sostituito dal backend software RustCrypto chacha20poly1305 con ChaCha20-Poly1305 di BoringSSL in ring 0.17, che utilizza NEON ottimizzato a mano su aarch64 e AVX2/AVX-512 su x86_64. I benchmark Docker su hardware identico hanno mostrato il throughput TCP diretto a 2 nodi passare da 437 a 1097 Mbps. v4.0.9 ha aggiunto il batching sendmmsg(2) sul percorso di invio UDP, portando il TCP single-stream da 1066 a 1548 Mbps (1,45×). v4.0.10 ha pubblicato una completa revisione della UX di pairing dei dispositivi.

Marmot / White Noise pubblica una versione frontend che completa il blocco degli utenti e 31 PR unite su MDK e backend

White Noise ha pubblicato v2026.5.7+24 il 7 maggio completando il set di funzionalità di blocco. Un utente bloccato è ora nascosto dagli inviti, dalle anteprime delle chat, dalle timeline dei messaggi, dai risultati di ricerca e dalle notifiche, e i suoi messaggi non contano più nei badge dei messaggi non letti. MDK ha integrato PR #258 con il formato wire dell’estensione v3 e lo schema disappearing_message_secs, gettando le basi per i messaggi a scomparsa.

Grain v0.6.0 aggiunge NIP-40, NIP-50, NIP-70 e NIP-45

Grain ha pubblicato v0.6.0 il 6 maggio con quattro nuove implementazioni NIP. La scadenza degli eventi NIP-40 consente ai publisher di impostare un timestamp di scadenza affinché il relay elimini gli eventi dopo la loro scadenza. La ricerca full-text NIP-50 consente ai client di emettere filtri di ricerca nei messaggi REQ. Gli eventi protetti NIP-70 impediscono ai relay di ricondividere eventi senza l’esplicita autorizzazione dell’autore. Le query di conteggio NIP-45 consentono ai client di chiedere a un relay di restituire un conteggio degli eventi corrispondenti.

Pubblicazioni della settimana

Citrine v3.0.0-pre1 integra Tor nativo e aggregazione relay

Citrine ha pubblicato v3.0.0-pre1 con supporto Tor integrato per un accesso ai relay che preserva la privacy e l’aggregazione relay, dove Citrine può estrarre eventi da più relay upstream e servirli ai client locali. PR #139 aggiunge il supporto NIP-77 (Negentropy Reconciliation) per la sincronizzazione efficiente degli eventi basata sulla riconciliazione degli insiemi.

Amber v6.1.0-pre2 migliora il flusso di connessione delle nuove app

Amber ha pubblicato v6.1.0-pre2. Le correzioni principali: il dialogo del firmatario ora si chiude correttamente dopo aver accettato una richiesta bunker, le richieste bunker malformate mostrano una schermata di richiesta non valida, e viene aggiunta la limitazione della velocità per le richieste di firma basate su intent.

Alby Hub v1.22.2 aggiunge la pagina AI e Agenti e il supporto Core Lightning

Alby Hub ha pubblicato v1.22.2. La nuova pagina AI e Agenti espone le capacità Lightning e NWC di Alby Hub agli agenti AI e agli strumenti compatibili MCP. Core Lightning (CLN) è ora un backend supportato insieme a LND e LDK.

Mostro pubblica i bond del taker concorrenti e mostro-core v0.11.0

Mostro ha integrato 11 PR che avanzano la funzionalità di bond del taker. PR #733 implementa i bond del taker concorrenti dove più taker possono inviare fatture di bond contemporaneamente e il primo a bloccare vince. mostro-core ha pubblicato v0.11.0 con PR #144 che aggiunge Action::PayBondInvoice e Status::WaitingTakerBond. mostro-cli ha pubblicato v0.15.0.

Jumble pubblica cinque versioni con ricerca recente e persistenza degli account

Jumble ha pubblicato v26.5.2 fino a v26.5.6. v26.5.5 aggiunge la cronologia delle ricerche recenti. Un bug critico di persistenza è corretto in v26.5.6: gli account e i dati memorizzati nella cache sopravvivono ora a un riavvio completo dell’app.

Nostrord ha pubblicato v1.0.0, v1.0.1 e v1.0.2. v1.0.1 pubblica pacchetti Arch Linux tramite AUR come nostrord-bin con artefatti firmati con PGP, un pulsante per saltare all’ultimo messaggio e l’incolla di immagini/media nella chat. v1.0.2 aggiunge la condivisione del gruppo tramite PR #49 con un modal di condivisione che genera sia un URI nostr:naddr che un link nostrord.com/open/.

FIPS v0.3.0 pubblica portata multipiattaforma, scoperta peer Nostr e un gateway per LAN non modificate

FIPS ha pubblicato v0.3.0, un traguardo importante che si espande da Linux-only a Linux, macOS, Windows e OpenWrt. I nodi ora pubblicano annunci overlay firmati come eventi parametrizzati sostituibili kind:37195 sui relay Nostr pubblici. Lo stesso swap ChaCha20-Poly1305 di ring 0.17 che ha alimentato il salto di throughput di Nostr VPN è presente anche in FIPS v0.3.0.

Camelus v1.10.1 pubblica versioni desktop

Camelus ha pubblicato v1.10.1 con versioni desktop per Windows e Linux, espandendo la distribuzione oltre il solo mobile.

Flotilla 1.8.0 pubblica videochiamate, rendering email e menzioni di stanza

Flotilla ha pubblicato 1.8.0. Le stanze vocali ora supportano il video: i partecipanti possono attivare le telecamere o condividere il proprio schermo durante una chiamata. Il rendering email arriva tramite un aggiornamento alla libreria welshman. Le menzioni di stanza consentono agli utenti di fare riferimento ad altre stanze e relay con link inline cliccabili.

Calendar by Formstr pubblica v1.5.1 con pianificazione degli appuntamenti e sincronizzazione del calendario Android

Calendar by Formstr ha pubblicato v1.5.0 il 10 maggio e v1.5.1 l'11 maggio. La pianificazione degli appuntamenti consente agli utenti di creare slot temporali prenotabili. L’integrazione del calendario Android in sola lettura sincronizza gli eventi Nostr con il calendario del dispositivo.

In sviluppo

Amethyst aggiunge post programmati, regole di comunità NIP-9A e un relay locale desktop

Amethyst ha integrato 78 PR questa settimana. I post programmati arrivano in PR #2765. Una versione desktop acquisisce un relay locale integrato con persistenza degli eventi SQLite in PR #2841. Tre PR implementano le regole di comunità NIP-9A: PR #2798 valida i post rispetto alle regole di comunità prima dell’invio, PR #2799 aggiunge un editor di regole NIP-9A strutturato, e PR #2800 aggiunge un filtro di feed NIP-9A opzionale.

Shopstr aggiunge la registrazione degli audit MCP e la sicurezza delle sessioni

Shopstr ha integrato cinque PR. La registrazione degli audit per il livello di strumenti MCP arriva in PR #456. La sicurezza delle sessioni si rafforza in PR #477 con il pinning delle sessioni alla chiave API di origine e l’espulsione TTL.

Dart NDK aggiunge il supporto web e la verifica delle firme dei sigilli

Dart NDK ha integrato sei PR. Il supporto web arriva in SembastCacheManager tramite PR #571. La verifica delle firme dei sigilli arriva in PR #595 per il flusso NIP-59 Gift Wrap.

Nuovi progetti

Tamagostrich lancia un Tamagotchi NIP-78 decentralizzato con ricompense in sats

Tamagostrich è un gioco di animale virtuale nel browser lanciato all’IDENTITY Hackathon 2026 dove un piccolo struzzo, Nori, si evolve attraverso la tua attività sociale Nostr. Lo stato dell’animale è memorizzato in un evento NIP-78 kind:30078 per la sincronizzazione multi-dispositivo. Le ricompense ai traguardi vengono pagate in sats tramite NIP-47: 50 sats al livello 5, 210 sats al livello 10 e 420 sats al livello massimo 21, inviati all’indirizzo lud16 dell’utente.

Lavori su protocollo e specifiche

Cinque nuove proposte sono state aperte questa settimana:

PR #2331 propone NIP-9A: Regole di Comunità Verificabili, introducendo kind:34551 per documenti di regole di comunità leggibili da macchina e firmati crittograficamente.

PR #2335 propone gli Eventi di Prenotazione per i Marketplace Nostr, definendo kind:32122 (eventi di prenotazione parametrizzati sostituibili), kind:1326 (record di audit delle transizioni solo in aggiunta) e kind:32124 (recensioni post-transazione). La negoziazione è privata tramite messaggi gift-wrapped NIP-59.

PR #2334 propone i Servizi di Escrow per i Marketplace Nostr usando kind:30303 affinché gli operatori di escrow dichiarino il loro indirizzo di contratto EVM e il listino tariffe.

PR #2333 propone i Profili di Annuncio di Alloggio per gli Annunci del Marketplace NIP-99, estendendo NIP-99 con tag g di indice geospaziale H3 per gli annunci di affitto a breve termine.

PR #2332 propone NIP-BC: Zap On-chain (kind 8333), sfruttando l’identità diretta tra le chiavi Nostr e gli indirizzi Bitcoin Taproot. Il numero di kind rispecchia NIP-57: 9735 è la porta P2P di Lightning; 8333 è la porta P2P della mainnet Bitcoin.

Approfondimento NIP: NIP-78 (dati specifici dell’app)

NIP-78 definisce un metodo standard con cui le applicazioni memorizzano dati arbitrari privati o pubblici per conto di un utente tramite eventi Nostr. Il tipo di evento centrale è 30078, un evento parametrizzato sostituibile in cui il tag d è una stringa identificatore definita dall’applicazione. Un’applicazione assegna al proprio slot di storage un tag d univoco e pubblica un evento 30078 con qualsiasi contenuto JSON o testo che deve persistere. La motivazione principale è la sincronizzazione multi-dispositivo senza un server centralizzato. Per i dati privati dell’applicazione, gli eventi NIP-78 possono cifrare il campo content usando NIP-44 prima della pubblicazione. Gli utenti attuali includono Tamagostrich (sincronizzazione dello stato dell’animale), Wisp (backup del portafoglio e impostazioni di sicurezza), NosPress (stato di orchestrazione CMS) e diverse implementazioni di sincronizzazione delle impostazioni dei client Nostr.

Fonti primarie:

Specifica NIP-78: https://github.com/nostr-protocol/nips/blob/master/78.md
Tamagostrich: https://github.com/Negr087/tamagostrich

Vedi anche: Liste NIP-51, Metadati elenco relay NIP-65

Approfondimento NIP: NIP-98 (HTTP Auth)

NIP-98 definisce uno schema di autenticazione HTTP che consente alle coppie di chiavi Nostr di autorizzare richieste a server HTTP, eliminando nomi utente, password o token OAuth. Un client costruisce un evento Nostr di breve durata di kind 27235, lo firma con la propria chiave privata, codifica il JSON in base64 e lo invia in un header HTTP Authorization: Nostr . L’evento kind 27235 include il metodo HTTP in un tag method, l’URL completo della richiesta in un tag u e un timestamp created_at. Il server valida la firma, verifica che metodo e URL corrispondano e controlla che il timestamp sia recente per prevenire gli attacchi di replay. NIP-98 è usato in Blossom (BUD-01) per l’autenticazione dell’upload dei blob, Routstr per il controllo degli accessi API per richiesta, Sprout per l’autenticazione del trasporto git e Alby Hub per l’autenticazione dell’API admin.

Fonti primarie:

Specifica NIP-98: https://github.com/nostr-protocol/nips/blob/master/98.md
BUD-01: https://github.com/hzrd149/blossom/blob/master/buds/01.md

Vedi anche: Integrazione archiviazione file HTTP NIP-96

È tutto per questa settimana. Se state costruendo qualcosa o avete notizie da condividere, inviateci un DM su Nostr o trovateci su nostrcompass.org.

Nostr Compass #21

Wed, 06 May 2026 00:00:00 +0000

Bentornati a Nostr Compass, la vostra guida settimanale all’ecosistema Nostr.

Questa settimana: Marmot Protocol pubblica MDK 0.8.0 con le prime primitive di notifica MIP-05, pacchetti di chiavi NIP-51 indirizzabili e una revisione della sicurezza rafforzata. LaWallet NWC pubblica v0.10.0, la versione più importante dalla copertura di OpenSats, con una dashboard admin completa, portafoglio utente, registro delle attività end-to-end e un nuovo schema LightningAddress 1→N e NWCConnection. Amethyst porta uno sprint di stabilizzazione di Nests con l’eliminazione dei gap audio durante il refresh JWT, sottoscrizioni di dati chiave lifecycle-aware, riconnessione keep-alive dei relay e un indicatore animato del parlante attivo. ngit pubblica v2.4.2 e v2.4.3 correggendo il rilevamento del server GRASP per le submission di PR e il filtraggio degli eventi di stato multi-remote. GRAIN pubblica v0.5.4 con hardening per la produzione e una correzione silenziosa di perdita di dati nel Docker quick-start. Mostro Core pubblica v0.10.1 con artefatti di release firmati con PGP. Clave lancia v0.2.0 con supporto multi-account su iOS.

Storie principali

MDK 0.8.0 aggiunge le primitive di notifica MIP-05 e i pacchetti di chiavi indirizzabili

MDK, la libreria Rust centrale per il protocollo Marmot, ha pubblicato v0.8.0 il 4 maggio. Questa versione introduce i primi blocchi costruttivi di notifica MIP-05, sposta i pacchetti di chiavi MIP-00 verso eventi indirizzabili così da poter sostituire il pacchetto chiavi di un utente in-place, migliora la compatibilità dei gruppi a versione mista, espande la copertura UniFFI per i binding mobile e rafforza i percorsi di validazione attorno alle azioni admin, commit, storage, limiti di cifratura e gestione dei replay. Le primitive MIP-05 includono helper di indice foglia aggiunti in PR #235, che forniscono ai client downstream informazioni sufficienti per consegnare notifiche push per destinatario senza rivelare la struttura del gruppo. PR #273 ripristina la pubblicazione di mdk-core su crates.io, e PR #269 espone il modulo test_util dietro una feature Cargo test-utils così che le suite di test client esterne possano condividere il test harness di Marmot.

LaWallet NWC v0.10.0 pubblica il monorepo completo e il portafoglio utente finale

LaWallet NWC, l’implementazione NIP-47 Nostr Wallet Connect del team LaWallet, ha pubblicato v0.10.0 il 30 aprile. È la versione più importante da quando il progetto ha ricevuto il finanziamento OpenSats. Include il monorepo completo, la dashboard admin completa, un portafoglio utente finale, un registro attività end-to-end, branding dinamico e il nuovo schema LightningAddress 1→N e NWCConnection. Il portafoglio per gli utenti finali, pubblicato in PR #191, copre l’onboarding, la home, invio/ricezione, scansione, valute, un feed attività e una cache offline.

Amethyst stabilizza Nests con keep-alive, resilienza JWT e sottoscrizioni lifecycle

Amethyst, il client Android ricco di funzionalità, ha continuato il lavoro sulle stanze audio NIP-53 Nests con uno sprint di stabilizzazione incentrato sui modi di guasto che interrompevano le chiamate in produzione. La correzione del gap audio in PR #2733 sovrappone la nuova acquisizione delle credenziali con il flusso attivo durante il refresh JWT. Un nuovo meccanismo keep-alive in PR #2730 riconnette i relay disconnessi senza richiedere un’azione manuale dell’utente, e PR #2728 sostituisce la vecchia KeyDataSourceSubscription con LifecycleAwareKeyDataSourceSubscription. PR #2724 aggiunge un indicatore ad anello esterno animato che evidenzia il parlante attivo nelle sessioni multi-parlante.

ngit v2.4.2 e v2.4.3 correggono il rilevamento del server GRASP e gli eventi di stato multi-remote

ngit, lo strumento da riga di comando e plugin git per la collaborazione NIP-34, ha pubblicato v2.4.2 il 28 aprile e v2.4.3 il 1° maggio. v2.4.2 corregge una mancata corrispondenza di normalizzazione URL in cui i repo_grasps contenevano hostname normalizzati ma il confronto veniva effettuato rispetto agli URL di clone completi. v2.4.3 corregge un’ambiguità negli eventi di stato che emergeva quando un repository ha più remote nostr:// che condividono lo stesso identificatore.

GRAIN v0.5.4 aggiunge hardening per la produzione e corregge una perdita di dati silenziosa

GRAIN, il relay Nostr e la libreria client basati su Go, ha pubblicato v0.5.4 il 30 aprile. La versione raccoglie sei correzioni accumulate dalla v0.5.3, incluso un bug di perdita di dati silenziosa nel Docker quick-start che in precedenza eliminava eventi al riavvio del container, e un bug di correttezza nel livello di storage nelle letture di eventi indirizzabili.

Mostro Core v0.10.1 aggiunge artefatti di release firmati con PGP

Mostro Core, la libreria Rust che fornisce funzionalità peer-to-peer per il daemon Mostro, ha pubblicato v0.10.1 il 28 aprile. La nuova versione aggiunge artefatti di release firmati con PGP e un flusso di verifica della release così che i packager downstream possano confermare la provenienza degli artefatti.

Release con tag

Clave v0.2.0 lancia il multi-account su iOS con firma NIP-46 (Nostr Connect)

Clave, l’app iOS per la firma remota NIP-46, ha pubblicato v0.2.0 il 5 maggio. Il principale aggiornamento introduce il supporto multi-account: Clave può ora gestire fino a quattro account su un unico dispositivo, con un selettore one-tap e isolamento per account. PR #23 aggiunge il codice iOS per il multi-account, e PR #22 aggiunge un campo signer_pubkey al payload APNs così che il dispositivo sappia a quale account appartiene una richiesta di firma remota.

Wisp pubblica v1.0.3 → v1.0.5 con lavori di stabilità

Wisp, il client Android, ha pubblicato v1.0.3, v1.0.4 e v1.0.5 il 4 maggio con lavori di stabilità. PR #506 aggiunge Thumbhash per le anteprime sfocate delle immagini mentre i media completi si caricano, e PR #514 riduce lo scatto nel cambio delle schede inferiori.

Amber 6.1.0-pre1 pubblica correzioni di layout e stabilità

Amber, l’app di firma Android per NIP-55 e NIP-46, ha pubblicato v6.1.0-pre1 con una revisione del layout nel flusso di connessione delle nuove app e diverse correzioni di crash. PR #416 corregge il layout di ActivityStatsBar e i problemi di overflow del testo.

Routstr Core v0.4.3 migliora pagamento, rimborso e reportistica sull’utilizzo

Routstr Core ha pubblicato v0.4.3 come pre-release il 1° maggio con miglioramenti alla gestione dei pagamenti e dei rimborsi, al tracciamento dei costi e alla reportistica sull’utilizzo.

Nostria v3.1.37 fino a v3.1.41 aggiungono i segnalibri Web e un tema Auto

Nostria, il client Nostr multi-piattaforma, ha pubblicato v3.1.37 fino a v3.1.41 aggiungendo il supporto ai segnalibri Web NIP-B0, un tema Auto che segue le impostazioni del dispositivo e la visualizzazione PDF integrata nell’app.

NoorNote v0.8.9 corregge la schermata vuota al primo avvio sul desktop

NoorNote ha pubblicato v0.8.9 il 28 aprile correggendo un bug di schermata vuota al primo avvio dell’app desktop.

Kubo v0.3.4 fino a v0.4.1 pubblicano una piattaforma video Nostr a misura di bambino con controlli parentali e curation del feed tramite Web of Trust

Kubo, una piattaforma video a misura di bambino su Nostr, ha pubblicato v0.3.4 fino a v0.4.1 il 4 e 5 maggio. Ogni bambino riceve una coppia di chiavi Nostr separata e un feed incentrato sui video dove i genitori controllano i limiti di tempo (da 15 a 180 minuti al giorno), le finestre temporali consentite e la visibilità delle azioni sui post.

Modifiche non rilasciate

Sprout pubblica Desktop v0.0.4 e v0.0.5 con autenticazione agente NIP-OA e il sidecar pair-relay

Sprout, il client Nostr di Block con relay integrato, ha pubblicato Desktop v0.0.4 il 5 maggio e v0.0.5 il 6 maggio. PR #471 integra l’autenticazione agente NIP-OA nel flusso di membership NIP-43 del relay così che un agente autonomo possa dimostrare che una specifica chiave pubblica umana ha autorizzato le sue azioni. Un nuovo relay sidecar effimero per il pairing di dispositivi NIP-AB arriva in PR #467 come sprout-pair-relay.

nostream aggiunge il supporto relay Marmot e le reazioni NIP-25

nostream, l’implementazione relay Node.js, ha integrato il supporto relay Marmot Protocol che copre i MIP da 00 a 03 in PR #602, il supporto alle reazioni NIP-25 in PR #589 e la corrispondenza del prefisso geohash per i filtri #g in PR #586.

strfry aggiunge l’osservabilità per connessione e riduce il tetto nofiles

strfry, il relay Nostr in C++, ha integrato 14 PR che puntano all’osservabilità. PR #218 aggiunge l’osservabilità degli outbound in attesa per connessione e un cap di back-pressure configurabile. PR #224 rimuove le allocazioni heap di std::function dal fanout del monitor per evento.

Damus sostituisce i GIF Tenor con un proxy Purple e pubblica la UX di compattazione

Damus ha integrato PR #3737 sostituendo l’integrazione GIF Tenor con un proxy Damus Purple.

Primal Android migliora Explore, gli avvisi e il badge di verifica NIP-05

Primal Android ha integrato PR #1043 correggendo un badge di verifica NIP-05 lampeggiante per gli utenti con identificatori _@domain.

Alby Hub aggiunge i pagamenti NWC dalle connessioni delle app

Alby Hub ha integrato PR #2267 che consente i pagamenti dalle connessioni delle app.

routstrd-auth: un Routstrd Docker per team con autenticazione NIP-98 e RBAC npub

routstrd-auth, creato il 27 aprile, è una variante Docker di Routstrd per i deployment in team multi-utente con controllo degli accessi basato sui ruoli npub e autenticazione HTTP NIP-98.

Routstrd integra Hermes per i client daemon e la modalità remota

Routstrd ha integrato PR #22 aggiungendo l’integrazione con Hermes Agent così che il file di configurazione dell’agente venga popolato con i provider di modelli e le chiavi API che Routstrd scopre tramite Nostr.

whitenoise-rs pubblica l’isolamento del database per account e gli aggiornamenti delle proposte

whitenoise-rs ha integrato PR #796 spostando le tabelle di proiezione dei messaggi in database per account, e PR #791 aggiunge gli aggiornamenti delle proposte così che i gruppi possano estendere le funzionalità con nuovi tipi di proposta.

Angor 0.2.21 pubblica flussi applicativi compatti con hardening del provider di chiavi e del cambio rete

Angor ha pubblicato 0.2.21 il 6 maggio con miglioramenti alle performance del design mobile, flussi applicativi compatti e un provider di chiavi sicuro.

Nuovi tracciati e scoperti

BitMacro Signer: un bunker NIP-46 auto-ospitato con cifratura delle chiavi lato client

BitMacro Signer è uno strumento di firma Nostr auto-ospitato che utilizza il modello bunker NIP-46. Le chiavi vengono cifrate lato client prima della memorizzazione così che il server non detenga mai testo in chiaro.

La scoperta di repository NIP-34 ha portato alla luce 26 nuovi annunci di repository questa settimana, di cui quattro si distinguono:

gnostr: un’implementazione git costruita direttamente su Nostr

gnostr è un’implementazione git costruita direttamente su Nostr, che fornisce i propri comandi di albero di lavoro come client di controllo versione nativo Nostr sviluppato da zero.

nostr-archive: una specifica di archivio content-addressed su Nostr e Blossom

nostr-archive è una specifica bozza e un’implementazione di riferimento per archivi content-addressed su Nostr e Blossom.

flower-cache: un server di cache Blossom locale

flower-cache è un server di cache Blossom locale, utile per i client che desiderano un mirror locale attivo del set di blob di un server Blossom remoto.

micro-vpn-ansible: playbook Ansible per il deployment VPN tramite NIP-34

micro-vpn-ansible è una piccola raccolta di playbook Ansible per il deployment di una micro VPN, ospitata come repository NIP-34.

Lavori sul protocollo

Aggiornamenti NIP

Un mercato dell’hashrate senza broker su Nostr (proposta bozza): Una bozza di NIP anonima che sostiene che gli attuali attori del mercato dell’hashrate sono broker custodiali che richiedono il KYC agli utenti. Propone un mercato P2P dell’hashrate sugli eventi Nostr.
Curated Feeds: un’alternativa più semplice ai feed DVM (proposta bozza): Sostiene che i DVM NIP-90 sono troppo pesanti per la curation semplice dei feed; propone eventi indirizzabili snelli con liste ordinate di ID evento.
Profile Colors: identità visiva deterministica (proposta bozza): Nuova bozza di NIP per derivare colori leggibili deterministici da una chiave pubblica Nostr per un’identità visiva coerente tra i client.
NIPs della traccia Namecoin: ancoraggio di identità, relay, TLS e reputazione (cluster di bozze): Un cluster di bozze di NIP che spostano i componenti dello stack Nostr in record ancorati a Namecoin.

Approfondimento NIP: NIP-34 (git stuff)

NIP-34 definisce i tipi di evento per ospitare repository git, patch, pull request, issue e stati di merge sui relay Nostr. Un repository è annunciato come evento indirizzabile di kind 30617. Le patch usano il kind 1617 che porta l’output di git format-patch. Le pull request usano il kind 1618. Le issue usano il kind 1621 con contenuto markdown. Gli eventi di stato fanno passare un thread tra Aperto (1630), Applicato/Unito o Risolto (1631), Chiuso (1632) e Bozza (1633). La notizia NIP-34 di questa settimana è la stessa del lancio di GitWorkshop v2 della settimana scorsa: il pulsante di merge della PR nel browser funziona perché i server GRASP, ngit e lo schema URL di clone nostr:// insieme chiudono il cerchio su una forge completamente decentralizzata.

Approfondimento NIP: NIP-53 (Live Activities)

NIP-53 definisce la superficie di eventi standard per le attività live su Nostr: stream live, spazi di meeting persistenti, eventi di conferenza programmati, presenza degli ascoltatori e chat live. Uno stream live è annunciato come evento indirizzabile di kind 30311. NIP-53 separa la stanza persistente dall’evento programmato che vi si tiene: un kind 30312 Meeting Space definisce una stanza, e un kind 30313 Conference Event rappresenta un meeting programmato o in corso in quella stanza. La superficie delle attività live di Nostr è intenzionalmente snella: NIP-53 annuncia l’attività, mentre altri NIP gestiscono le preoccupazioni adiacenti come i zap (NIP-57), gli obiettivi di zap (NIP-75) e le registrazioni video (NIP-71).

È tutto per questa settimana. Se state costruendo qualcosa o avete notizie da condividere, inviateci un DM su Nostr o trovateci su nostrcompass.org.

Nostr Compass #20

Wed, 29 Apr 2026 00:00:00 +0000

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

Questa settimana: GitWorkshop trasforma git-over-Nostr in una superficie di code review più completa con un pulsante di merge PR nel browser, Stars e following dei repository, un git explorer efficiente in banda, commenti di review inline di kind 1111 e stato delle notifiche cifrato multi-dispositivo. Routstrd lancia un daemon locale che scopre i provider di modelli tramite annunci Nostr di kind 38421 e li paga con Cashu. I rilasci tagged includono ngit v2.4.2, Wisp v1.0.0, grain v0.5.2 e v0.5.3, Mostro Core v0.10.0 e Mostro Mobile v1.2.5, marmot-ts v0.5.0, CruxCoach v0.1.3, Meiso v1.3.0, NoorNote, Nostria, Nostr Calendar, nos2x-fox, applesauce, nostr-double-ratchet e altro. Le modifiche non rilasciate coprono Amethyst Nests, nostream NIP-65 e NWC, il bootstrap udp:nat basato su Nostr di FIPS, l’osservabilità di strfry, le owner attestation di Sprout e i recipe pack di Zap Cooking. I nuovi progetti tracciati includono Nostrord, Clave, Treasures, smesh, Surveil, Fundstr, Nod City, deploy-nsite-to-pages e null–nostr. Il retrospettivo di fine mese copre gli April di Nostr dal 2021 al 2026.

Storie principali

GitWorkshop rilascia merge PR nel browser, following dei repository e un git explorer efficiente in banda

GitWorkshop, il layer di collaborazione basato sul web di Dan Conway per NIP-34 git-over-Nostr, ha rilasciato questa settimana una versione importante che avvicina il workflow molto di più a ciò che gli sviluppatori si aspettano da GitHub o GitLab, mantenendo commenti, elenchi di repository e notifiche all’interno di eventi Nostr firmati.

L’aggiunta principale è un tanto atteso pulsante di merge PR nel browser per i repository che usano relay GRASP. Il rilascio aggiunge anche Stars e following dei repository costruiti su reazioni ed elenchi NIP-51, con set di repository fissati pubblicati come eventi di kind 10617 che puntano ad annunci di repo di kind 30617 tramite tag a ordinati. Le pagine profilo possono ora presentare un elenco portatile di repository.

Un git explorer efficiente in banda sostituisce il precedente shallow clone nel browser. Il nuovo explorer si appoggia al sottostante protocollo client/server git su cui GRASP è costruito, quindi può gestire repository grandi senza forzare il browser a scaricare un pack completo. La ricerca copre ora nomi utente e metadati dei repository, alimentata da NIP-50 e da un’implementazione di relay ngit-indexer che scopre e sincronizza gli annunci di repository attraverso la rete. Un workflow di creazione di repository nel browser completa il percorso di scoperta e onboarding.

Gli strumenti di review sono ricostruiti attorno a una scheda Files Changed, un visualizzatore di diff per singola patch e un set di nuove primitive sperimentali. I commenti di code review inline usano kind 1111, costruito su NIP-22: ogni commento punta a un percorso file (tag f), a uno SHA di commit (tag c) e a un intervallo di righe selezionato (tag line), così un client può rendere il commento nella posizione corretta di un diff. Un secondo livello di primitive sperimentali è autorizzato per autori e manutentori dei repo e usa etichette NIP-32: rinominare il soggetto di un Issue o PR dopo la submission, aggiungere hashtag dopo la submission, fissare una CoverNote versionata in cima a un PR o Issue per un riepilogo modificabile e marcare come risolti i sottothread di discussione inline. Gli eventi Verdict e i blocchi suggestion restano in bozza e non sono ancora stati rilasciati.

Lo stato delle notifiche fra dispositivi è anch’esso sincronizzato tramite Nostr, ma con una svolta a tutela della privacy. GitWorkshop genera una keypair dedicata alle notifiche, cifra quella nsec e la memorizza dentro un evento di kind 30078. L’nsec di notifica firma poi gli effettivi eventi di stato delle notifiche. L’indirezione impedisce che il signer principale dell’utente venga bombardato da frequenti richieste di cifratura e decifratura per ogni azione di lettura o archiviazione, e impedisce agli osservatori esterni di vedere facilmente quando un utente tocca il proprio stato di notifica. Un utente può sincronizzare lo stato di lettura e archiviazione fra dispositivi; i relay vedono solo blob cifrati.

Routstrd lancia un router locale per l’inferenza su Nostr

Routstrd è un nuovo daemon TypeScript che offre agli strumenti locali un endpoint compatibile con OpenAI e instrada ogni richiesta a un provider Routstr concorrente. Il daemon scopre i provider tramite annunci Nostr di kind 38421 definiti nella spec RIP-02 di Routstr. Assegna poi un punteggio ai provider in base a prezzo, fiducia e performance recenti secondo RIP-06 e invia ogni richiesta all’opzione attualmente migliore.

Il pagamento passa attraverso un wallet Cashu locale gestito da cocod e finanziato con Lightning. Ciò offre al client un percorso di regolamento denominato in sats mantenendo la scoperta dei provider pubblica e permissionless attraverso i relay Nostr. Se un provider fallisce durante una sessione, Routstrd può ripiegare sul nodo classificato successivamente. Il percorso di installazione è bun install -g routstrd, seguito da routstrd onboard per la configurazione di wallet e relay.

La più ampia Routstr org mantiene il daemon, il software di nodo Python (routstr-core), una UI di chat e le specifiche di protocollo. Per gli utenti, la porta locale diventa l’interfaccia stabile: gli strumenti esistenti compatibili con OpenAI puntano a Routstrd, mentre il daemon gestisce scoperta dei provider, routing e pagamento.

Rilasci tagged

ngit v2.4.2 corregge la rilevazione del server GRASP per le submission di PR

ngit ha rilasciato v2.4.2 con una correzione per la rilevazione del server GRASP del repository, mantenendo la submission di PR sul percorso corretto quando una proposta usa il kind PR. Da notare che ngit attualmente imposta come default il kind Patch per la maggior parte delle modifiche, a meno che non siano grandi; il manutentore sta lavorando per cambiare il default. v2.4.1, rilasciata all’inizio della settimana, ha corretto errori fatal durante clone e fetch quando i dati git di un PR aperto non erano disponibili sui server git specificati per il repository.

Wisp v1.0.0 esce dalla beta

Wisp, un client Android in Kotlin e Jetpack Compose focalizzato su routing dei relay, privacy e una piccola UI nativa, ha rilasciato v1.0.0 seguita da v1.0.2. La milestone 1.0.0 raccoglie il toggle di denominazione fiat Normie Mode, il feed For You, la configurazione dei gruppi basata su relay NIP-29 e la trasmissione della relay-list NIP-65 trattate in Newsletter #19. v1.0.2 aggiunge il supporto Android 15 per page-size da 16 KB, una scheda di scansione QR nel drawer sheet, un pulsante di download per i controlli video inline e correzioni di performance per le liste di notifiche.

grain v0.5.2 risolve il lockup WebSocket, v0.5.3 continua le rifiniture

grain, il relay in Go di 0ceanSlim, ha rilasciato v0.5.2 come hotfix critico per un lockup WebSocket introdotto in v0.5.0, seguito poi da v0.5.3. Il lockup faceva bloccare le connessioni in alcuni percorsi di filter e WebSocket, quindi gli operatori su v0.5.1 o v0.5.0 dovrebbero aggiornarsi. grain traccia tutte le principali categorie di eventi Nostr, espone informazioni relay NIP-11, supporta controllo di accesso whitelist/blacklist, rate limit per kind, una dashboard web e una libreria client Go aggiunta nella linea v0.5.x.

Mostro Core v0.10.0 e Mostro Mobile v1.2.5 adottano il gift wrap NIP-59 a doppia chiave

Mostro Core v0.10.0 aggiunge il nuovo modulo gift-wrap NIP-59 con identità e chiavi di trade separate. Il codice di trasporto precedente usava una singola chiave di identità sia per l’identità del trade sia per il gift wrapping. v0.10.0 separa l’identità stabile del trade dalla chiave effimera di wrapping, così ogni trade può usare una chiave di trasporto fresca preservando l’identità necessaria al protocollo di trade. L’integrazione del daemon arriva tramite Mostro PR #718, e mostro-cli PR #165 porta la stessa migrazione al client a riga di comando.

Mostro Mobile v1.2.5 esce insieme al lavoro sul protocollo. PR #581 permette ai takers di filtrare le offerte in base all’età dell’account del maker, dando agli utenti un modo per evitare account maker appena creati nell’order book. PR #580 corregge le etichette di ruolo nei dettagli degli ordini cancellati, e PR #576 sistema i pulsanti di cancellazione cooperativa.

marmot-ts v0.5.0 rilascia i KeyPackage indirizzabili

marmot-ts ha rilasciato @internet-privacy/marmot-ts@0.5.0, la prima release con breaking-change pianificata per il client Marmot TypeScript. PR #68 aggiunge il supporto ai KeyPackage indirizzabili: KeyPackageManager può ora gestire sia i legacy eventi KeyPackage di kind 443 sia i nuovi di kind 30443. La release rimuove KeyPackageStore e le classi di storage dello stato di gruppo, sostituendole con store generici key-value passati a KeyPackageManager e MarmotGroup. Sposta inoltre la gestione di invite e gruppi su MarmotClient.invites e MarmotClient.groups, quindi chi incorpora direttamente ha bisogno di modifiche a costruttori e storage prima di aggiornare.

CruxCoach v0.1.3 rilascia il backup cifrato dei dati di arrampicata con Nostr e Blossom

CruxCoach è una nuova app Android open-source per scalatori di Kilter Board. La Kilter Board è una parete di allenamento interattiva le cui prese si illuminano via Bluetooth per mostrare le vie. L’app è stata lanciata il 14 aprile e ha raggiunto v0.1.3 il 26 aprile.

v0.1.3 aggiunge il backup cloud cifrato opzionale. L’account CruxCoach di un utente è una keypair Nostr, e la chiave privata funge anche da input per la chiave locale di cifratura del backup. L’app cifra i dati di arrampicata sul dispositivo e replica il ciphertext sui server di storage Blossom (blossom.primal.net e nostr.download). Le azioni di eliminazione remota chiamano il percorso di cleanup Blossom. Oltre al backup, CruxCoach usa il remote signing NIP-46 per il supporto Amber, i DM privati NIP-17 per il contatto in-app con lo sviluppatore, le relay-list NIP-65 per la scoperta dei relay e la libreria Quartz di Vitor Pamplona per la parte Nostr. Gli utenti possono installarla tramite Zapstore o APK Codeberg diretti.

Meiso v1.3.0 aggiunge sotto-attività, allegati Blossom e tagging NIP-89

Meiso è un task manager Flutter minimalista per Android che memorizza le attività come dati applicativi cifrati NIP-44 di kind 30078 sui relay Nostr. v1.3.0, rilasciata il 6 aprile, aggiunge sotto-attività con relazioni genitore/figlio, task link per blocks/blocked-by/related-to/duplicate-of, allegati immagine tramite Blossom ed endpoint di upload file HTTP NIP-96, un tag client di applicazione raccomandata NIP-89 sugli eventi pubblicati e uno strumento di sincronizzazione da riga di comando in Go. v1.3.0 corregge anche il comportamento del relay al cold-start e il riuso del client Amber.

NoorNote, Nostria, Nostr Calendar, nos2x-fox e rilasci di librerie

NoorNote ha pubblicato v0.8.7, v0.8.8 e v0.8.9. Queste release correggono la gestione del click di immagini e video nei repost citati, aggiungono il supporto lightbox per le immagini di articoli long-form e correggono la schermata di avvio desktop vuota. Nostria ha rilasciato v3.1.29, v3.1.30 e v3.1.31, aggiungendo la compressione delle immagini nell’editor di articoli, un toggle USD del wallet, controlli per le carte promozionali, il supporto PDF e rifiniture del layout mobile.

Nostr Calendar v1.4.1 disaccoppia la pubblicazione degli eventi del calendario dalla gestione della lista dei calendari e corregge il tracciamento degli inviti. nos2x-fox v1.19.0 aggiunge tempi di autorizzazione personalizzati per le grant di firma browser NIP-07 su Firefox. nostr-double-ratchet v0.0.97 rilascia nuovi binari. nostr-wot-sdk 0.9.0 monta NostrSessionProvider per impostazione predefinita, e nostr-tools PR #535 aggiunge il supporto al parsing multi-relay per le stringhe wallet-connect NIP-47.

A fine settimana, Amber v6.1.0-pre1 ha rilasciato una pre-release con un migliore layout di connessione di nuove app, correzioni al dialog del signer, gestione migliorata dei permessi di notifica e refactoring della selezione dell’account. nostr-vpn v0.3.14 ha rilasciato una build fresca con artefatti macOS Apple Silicon, Linux e Windows. Bitcredit Core v0.5.7-hotfix-1 e v0.5.8 hanno rilasciato correzioni consecutive per un problema di validazione dei blocchi orfani. Surveil v0.1.6 ha portato rifiniture UI mobile e una pagina About rivisitata; il progetto stesso è presentato più sotto.

applesauce 6.0.0 rimuove le vecchie event factory e aggiunge il parsing degli URI Blossom

applesauce, il toolkit Nostr TypeScript di hzrd149, ha rilasciato un treno di release 6.0.0 attraverso il monorepo. applesauce-core@6.0.0 rimuove la vecchia classe EventFactory e i vecchi helper buildEvent, modifyEvent e createEvent, spingendo i chiamanti verso le nuove classi factory in applesauce-core/factories e applesauce-common. Aggiunge anche la gestione di indirizzi IP e localhost al parsing dei link, espressioni regolari per URI Blossom BUD-10 e nuovi helper observable come timeoutWithIgnore, combineLatestBy, combineLatestByIndex e combineLatestByKey.

I rilasci a livello di pacchetto completano i pezzi specifici di Nostr. applesauce-content@6.0.0 aggiunge nodi URI Blossom BUD-10 per testo e Markdown, dando ai renderer un modo nativo di analizzare i riferimenti Blossom nel contenuto. applesauce-actions@6.0.0 aggiunge classi factory di base per le liste NIP-51 che coprono relay, utenti ed elementi, rendendo la costruzione di liste meno ad hoc. applesauce-wallet-connect@6.0.0 espone WalletConnect.connectURI, così le app possono accedere direttamente a un URI wallet-connect NIP-47 esistente.

Modifiche non rilasciate

Amethyst avanza le stanze audio Nests con i test di interop MoQ

Amethyst ha mergiato diverse PR focalizzate su Nests questa settimana, costruendo sullo stack di stanze audio Media over QUIC della scorsa settimana. PR #2622 aggiunge un harness di interop cross-client che esercita il client MoQ Amethyst contro l’implementazione web di riferimento. L’obiettivo è cogliere la divergenza a livello wire fra Android e browser prima che colpisca gli utenti. PR #2625 migliora il focus del parlante in picture-in-picture e lo stato della connessione, mentre PR #2620 chiarisce avatar, stato di mute e stato di parlante nella griglia dei partecipanti. A fine settimana, PR #2634 corregge il padding IME e gli window insets nella vista Nest a schermo intero e PR #2635 aggiunge il filtro di freschezza basato su presenza al feed Nests. Separatamente, PR #2627 rimuove l’implementazione C custom di secp256k1 di Amethyst e migra a libschnorr256k1.

nostream aggiunge il supporto alle relay list NIP-65 e ai pagamenti NWC

nostream ha mergiato tre PR notevoli dopo lo sprint da 53 PR della scorsa settimana. Il supporto ai metadati della relay list NIP-65 arriva in PR #585, così il relay può indicizzare e servire eventi di relay list di kind 10002. Un processore di pagamenti Nostr Wallet Connect segue in PR #539, aggiungendo un percorso pay-to-relay. La pulizia delle connessioni migliora in PR #438, che chiude un bug di connessioni morte in cui i socket con sottoscrizioni attive non venivano raccolti, causando la deriva dei conteggi delle sottoscrizioni sulle istanze long-running.

FIPS aggiunge il bootstrap udp:nat basato su Nostr

FIPS, il Free Internetworking Peering System coperto in precedenza in Newsletter #6 e Newsletter #10, ha mergiato PR #53 con il bootstrap udp:nat basato su Nostr. Il cambiamento consente ai nodi di pubblicare annunci Nostr, scambiare signaling offer/answer cifrato, scoprire indirizzi pubblici tramite STUN, eseguire hole punching UDP e consegnare il socket bucato al normale stack di trasporto FIPS. L’implementazione lega le identità del payload di signal all’effettivo sender Nostr, interroga i relay DM e advert configurati per il lookup della inbox e ripristina gli handoff di traversal adottati falliti così che i trasporti UDP orfani non restino vivi. Questo è il lavoro di annuncio Nostr e traversal NAT da tracciare nel repo canonico, jmcorgan/fips.

strfry aggiunge osservabilità per connessione

strfry ha mergiato PR #214, aggiungendo osservabilità per connessione e metriche a livello di connessione esportabili tramite Prometheus. PR #204 normalizza le etichette Prometheus, e PR #215 aggiunge una sezione Community Integrations alla documentazione che copre progetti di identità Namecoin costruiti sopra strfry.

Sprout aggiunge Owner Attestation e supporto multi-workspace

Sprout, il client Nostr di Block, ha mergiato PR #406 che implementa NIP-OA (Owner Attestation). La funzionalità dà a un agente autonomo una prova crittografica che una specifica pubkey umana ha autorizzato le sue azioni. PR #409 aggiunge il supporto multi-workspace all’app desktop, PR #411 aggiunge l’autocompletamento #channel al compose mobile, e PR #410 chiude una race window che poteva scartare messaggi di canale attivi. PR #413 introduce NIP-RS per la sincronizzazione dello stato di lettura cross-device, e le successive PR #420 e PR #422 collegano quello stato di lettura ai badge di non letti su mobile.

Zap Cooking ha mergiato una settimana produttiva di lavoro sulla pubblicazione di ricette. Le richieste di eliminazione NIP-09 per i Recipe Pack propri dell’utente arrivano in PR #367. L’affidabilità della pubblicazione migliora tramite PR #366, che forza ogni nuova ricetta sul relay garden e aggiunge una coda di retry per il recipe set condiviso. La pubblicazione one-click di pack redatti dall’autore arriva in PR #365, e PR #331 aggiunge il supporto al login via bunker NIP-46.

Whitenoise-rs cifra il proprio database locale

whitenoise-rs ha mergiato PR #758, aggiungendo la cifratura SQLCipher per il database Whitenoise su disco. Questo chiude un gap di sicurezza at-rest di vecchia data per lo stack del daemon Marmot. PR #775 espone le capability richieste del gruppo, PR #772 migra le operazioni sui media di gruppo a MediaOps di proprietà della sessione, e PR #773 estrae un holder SharedServices come parte del refactor delle session-ops. Sul lato mobile, whitenoise PR #577 abilita l’auto-riavvio al boot per il servizio foreground Android, correggendo il caso in cui il daemon non tornava dopo un riavvio del dispositivo.

Progetti tracciati e scoperti di recente

Nostrord: un client NIP-29 costruito con Kotlin Multiplatform e WASM

Nostrord è un nuovo client di group-chat NIP-29 che punta al caso d’uso di sostituto di Discord. I gruppi vivono su relay Nostr con membership, ruoli, moderazione e controllo di accesso applicati dal relay, quindi lo stato di gruppo è ospitato dal relay NIP-29 selezionato. Lo sviluppatore del client non controlla un database applicativo separato per quei gruppi. La web app gira su web.nostrord.com ed è costruita con Kotlin Multiplatform che compila in WebAssembly, con build native Android, iOS e desktop in sviluppo. Nostrord è un beneficiario di grant OpenSats e interopera con gli stessi relay NIP-29 usati da Flotilla, Chachi e 0xChat.

Clave porta il remote signing NIP-46 su iOS tramite APNs

Clave è un remote signer iOS in beta che firma eventi Nostr quando l’app non è aperta. La chiave privata resta nella Keychain dell’iPhone. Quando un client invia una richiesta di remote signing NIP-46, un proxy lato server consegna una Apple Push Notification, svegliando una Notification Service Extension per un massimo di 30 secondi. Quell’extension decifra la richiesta con la cifratura NIP-44, firma con la chiave della Keychain e pubblica la risposta. La registrazione del token del dispositivo usa l’HTTP Auth NIP-98 per impedire il dirottamento del token. Clave supporta il pairing bunker:// e nostrconnect://, livelli di fiducia per-client, override per-kind ed è stato testato con Nostur e noStrudel.

Treasures: geocaching decentralizzato su Nostr

Treasures è una piattaforma di geocaching in cui cache e ritrovamenti sono eventi Nostr firmati. I creatori di cache pubblicano eventi indirizzabili di kind 37516 con coordinate GPS. I finder registrano la scoperta scansionando un QR code attaccato alla cache fisica; il codice codifica la pubkey del creatore, il tag d della cache e una chiave privata di verifica usata come prova della visita fisica. Gli zap NIP-57 possono fluire dai finder ai creatori di cache, e l’app live è su treasures.to.

smesh v0.5.1: relay Nostr self-hosted, client e signer in uno stack unico

smesh è uno stack Nostr self-hosted scritto in Moxie, un linguaggio custom derivato da Go e TinyGo da mleku. Lo stack rilascia un binario relay nativo con supporto HTTP, WebSocket, AUTH, ricerca e Blossom; sm3sh, un web client compilato in moduli ES; e un’estensione browser signer con firma browser NIP-07 più supporto alla cifratura NIP-04 e NIP-44. Il lavoro recente include messaggistica di gruppo MLS (RFC 9420) in v0.5.0, riconciliazione di set negentropy per la sync dei relay e un engine di grafo Web of Trust. Il codice vive sulla forge self-hosted di mleku a git.smesh.lol, costruita con il suo strumento git-web. Il repo correlato gitea-nostr-auth è un bridge OAuth2/OIDC per Gitea: gli utenti si autenticano con un signer browser NIP-07, il bridge scopre i relay tramite NIP-65 e Gitea riceve claim di identità OIDC standard.

Surveil: un deck builder di Magic: The Gathering su Nostr

Surveil è un client Nostr per giocatori di Magic: The Gathering che consente agli utenti di cercare carte, costruire mazzi, scansionare carte cartacee su Android con OCR ML Kit on-device e condividere mazzi attraverso la rete. I mazzi sono pubblicati come eventi indirizzabili di kind 37381, e la spec dell’evento mazzo è documentata nel NIP.md del progetto. Il livello sociale è costruito da primitive Nostr standard: commenti threaded NIP-22 (kind 1111) associati a ogni mazzo, reazioni NIP-25 (kind 7), dati profilo NIP-78 (kind 30078) per le pagine dei giocatori, follow feed di kind 3 e fork che portano un tag a che riporta al mazzo originale. v0.1.6 è stato rilasciato questa settimana con rifiniture UI mobile, miglioramenti al life counter, una pagina About rivisitata e una relay pill sul banner hero del mazzo. La web app gira ovunque HTML statico sia servito, la build Android è distribuita tramite Zapstore, e gli eventi di kind 37381 sono anche indicizzati nativamente da Ditto come mazzi Magic. Il repo è su GitLab a chad.curtis/surveil.

Aggiunte minori: Fundstr, Nod City, deploy-nsite-to-pages e null–nostr

Fundstr è una piattaforma di finanziamento per creator su Nostr che usa Cashu ecash per pledge una tantum e ricorrenti, con definizioni di tier del creator e DM Nostr. Nod City è un sito di recensioni di servizi Bitcoin in cui le recensioni sono eventi Nostr firmati e i recensori possono ricevere zap; non è stato trovato un repo sorgente pubblico. deploy-nsite-to-pages è una GitHub Action che replica un nsite su GitHub Pages usando nsyte download, supportando nsite root di kind 15128 e named di kind 35128. null–nostr, scoperto anch’esso nei dati NIP-34 di questa settimana, è il client trattato nella recente ondata OpenSats come Nurunuru; supporta messaggistica di gruppo MLS, Amber, ricerca NIP-50, post protetti NIP-70, badge ProofMode e distribuzione Zapstore.

FIPS non è un progetto nuovo per Compass. È stato trattato in Newsletter #6 e Newsletter #10. Il database ora punta al repo canonico corretto, jmcorgan/fips, e la scoperta NIP-34 di questa settimana ha fatto emergere anche mirror git-over-Nostr correlati come fips e awesome-fips.

Lavoro di protocollo

Aggiornamenti NIP

Proposte e discussioni recenti nel repository NIPs:

Mergiate questa settimana:

NIP-34 git repositories: remove unused refs tag extension (PR #2325): Rimuove un’estensione di tag refs da NIP-34 che era definita ma non usata. La pulizia riduce l’ambiguità implementativa per gli strumenti git-over-Nostr.
NIP-34 git repositories: remove incorrect NIP-09 claim (PR #2326): Rimuove una dichiarazione errata secondo cui gli eventi di eliminazione NIP-09 possono resettare lo stato del repository. L’eliminazione NIP-09 è una richiesta di eliminazione evento lato client, non una macchina a stati del repository. La correzione impedisce agli implementatori NIP-34 di trattare gli hint di eliminazione come reset autoritativi del repo.

Lavoro aperto e guidato dalle implementazioni:

GitWorkshop kind 1111 commenti di review inline: Il kind di commento di code review inline è documentato nel NIP.md di GitWorkshop ed è ora in uso attivo, ma non è ancora stato proposto come NIP formale. Gli eventi Verdict (kind 7321) e i blocchi suggestion restano in bozza e non sono ancora stati rilasciati. Il feedback implementativo da GitWorkshop e ngit determinerà se le forme diventeranno un NIP git-review autonomo o resteranno una convenzione applicativa stratificata su NIP-34.
Nostr mail core e Nostrmon: Due nuove bozze di NIP custom hanno circolato questa settimana. Nostr mail core propone il kind 1301 per contenuti email RFC 2822, wrappati con NIP-59 per la consegna privata e ponte verso l’email legacy tramite pubkey di bridge risolte via NIP-05. Nostrmon delinea kind di eventi indirizzabili per regioni, mappe, creature, NPC, salvataggi giocatore e oggetti. Entrambe restano bozze custom, non NIP mergiati.
NIP-67: EOSE Completeness Hint (PR #2317): La proposta continua a iterare sull’aggiunta di un marcatore positivo di completezza a EOSE, permettendo ai relay di distinguere “eventi memorizzati consegnati integralmente” dai casi legacy EOSE in cui il relay non fa alcuna dichiarazione di completezza.

Sei April di Nostr

April dà una sezione trasversale pulita del percorso di sviluppo di Nostr: il documento di protocollo nel 2021, i primi lavori sui client nel 2022, l’ondata applicativa post-Damus nel 2023, la messaggistica privata e il lavoro git-over-Nostr nel 2024, Blossom e la pulizia della relay list nel 2025 e le grant focalizzate sull’adozione dei client nel 2026.

Aprile 2021: il documento di protocollo prima del repo NIPs

Fiatjaf ha pubblicato l’articolo originale su Nostr, “Notes and Other Stuff Transmitted by Relays”, il 20 novembre 2020. Quel primo testo conteneva già la forma centrale che ancora definisce il protocollo: gli utenti firmano eventi con chiavi, li pubblicano ai relay e leggono dai relay che scelgono. Il commit log di nostr-protocol/nostr mostra zero commit tra il 1° e il 30 aprile. L’attività si trova ai due lati: i commit di marzo 2021 hanno aggiunto i primi link “nostwitter” e un filtro kind, mentre quelli di maggio 2021 hanno riproposto NIP-02 e aggiunto la NIP authorship.

Nell’aprile 2021 non c’era un mercato client pubblico, nessuna rete di relay visibile, nessun repo NIPs. Il protocollo viveva ancora come un piccolo documento e pochi esperimenti. Nostr non era ancora diventato un social network o una piattaforma di sviluppo. Era ancora un modello relay/chiave/evento in attesa della sua prima ondata sostenuta di contributor.

Aprile 2022: i NIP vivevano ancora nel repo principale

L’aprile 2022 è stato l’ultimo mese prima che i NIP si spostassero fuori dal repo principale nostr-protocol/nostr. Poiché lo split non era ancora avvenuto, il repo dedicato nostr-protocol/nips non aveva storia di pull request in aprile. Nel repo principale, tre commit di aprile sono arrivati: “Update readme to add nip12” l'8 aprile di goswami1999, “add kinds list” il 25 aprile di jb55 e “add js formatting to sample code” il 28 aprile di steliosrammos.

Anche il lavoro sui client cominciava a prendere forma. I commit di Damus dell’aprile 2022 hanno aggiunto il primo comportamento chatroom, la gestione del profilo e le icone dell’app, mentre nostr-tools stava diventando il percorso di libreria JavaScript per i primi client ed esperimenti. Sul lato protocollo, le query di tag generiche NIP-12 hanno dato alla ricerca per tag un posto documentato, la kinds list ha spostato Nostr verso un modello a registry e migliori esempi JavaScript hanno reso la spec più facile da implementare per autori di client e librerie. Il 1° maggio, fiatjaf ha spostato i NIP nel repo dedicato. L’aprile 2022 è stato l’ultimo mese dell’era originale a repo unico.

Aprile 2023: espansione applicativa post-Damus

L’aprile 2023 è arrivato tre mesi dopo il lancio di Damus sull’App Store iOS del 31 gennaio 2023, e dopo che Jack Dorsey aveva postato la sua chiave pubblica Nostr. La rete aveva appena assorbito la sua prima grande ondata di crescita pubblica. Client come Damus, Snort, Iris, Coracle e Amethyst erano attivi, mentre gli operatori di relay stavano imparando cosa un social graph più grande faceva alle assunzioni su banda, spam, ricerca e moderazione.

L’aprile 2023 ha avuto una sola PR NIPs mergiata: PR #456, mergiata il 17 aprile, che aggiungeva link a entità bech32 NIP-19 alla gestione URI NIP-21. I commit circostanti mostrano la pressione applicativa dietro il lavoro di protocollo. L’aprile 2023 ha visto lavoro su NIP-45 COUNT, zap marker specifici per evento, NIP-15 marketplace, semantica di delegated delete NIP-26, file metadata NIP-94, gestione degli errori wallet-connect NIP-47 e NIP-30 custom emoji. La lista dei contributor si era allargata a includere fiatjaf, staab, pablof7z, Semisol, CodyTseng, sethforprivacy, mikedilger, AsaiToshiya, alexgleason, martindsq, frbittencourt e arkin0x.

Damus, Snort, Iris, Coracle e Amethyst non erano più demo attorno a una spec; erano client di produzione che affrontavano onboarding, feed, spam, zap, media e selezione dei relay. Il lavoro di protocollo dell’aprile 2023 si legge come il backlog che quei client hanno creato: zap, marketplace, file metadata, conteggio, emoji e link identitari hanno tutti spinto la spec oltre le semplici note e i semplici follow.

Aprile 2024: messaggistica privata, git-over-Nostr e supporto ai manutentori

L’aprile 2024 ha avuto due PR NIP mergiate. PR #1167, mergiata il 10 aprile, ha corretto terminologia confusa nel remote signing NIP-46, in cui client e signer hanno bisogno di linguaggio esatto per le azioni richieste e autorizzate. PR #1108, mergiata il 17 aprile, ha espanso i git repositories NIP-34 con eventi di stato, chiarimenti, manutentori opzionali, identificatori di repo e tag di discoverability. Quel passo ha reso git-over-Nostr più pratico per ngit e in seguito GitWorkshop.

NIP-17, precedentemente NIP-24, è atterrato il 24 aprile come messaggi sigillati e gift-wrapped per DM privati e piccole chat di gruppo. Il lavoro su client e librerie ha corso in parallelo: Amethyst, Primal, Gossip, nostr-tools, NDK e rust-nostr erano tutti attivi nello stesso periodo.

OpenSats ha anche annunciato supporto a lungo termine per gli sviluppatori Nostr nell’aprile 2024: PabloF7z il 9 aprile, Stuart Bowman il 12 aprile e hzrd149 il 15 aprile. Quelle grant hanno spostato il finanziamento dalle grant di progetto isolate verso la manutenzione sostenuta di relay, librerie e infrastruttura client.

Aprile 2025: pulizia densa dei NIP e formalizzazione di Blossom

L’aprile 2025 è stato il mese di protocollo più denso in questo retrospettivo, con sedici PR NIPs mergiate. Il mese è iniziato con PR #1846, che ha aggiunto transazioni e indirizzi blockchain a NIP-73, e PR #1865, che ha aggiunto i tag NIP-C0 alla tabella dei tag standardizzati. È continuato con PR #1801 e PR #1889, entrambe migliorativi delle indicazioni di ripubblicazione della relay list di kind 10002, e PR #1879, che ha ridotto e chiarito NIP-65.

PR #1822 ha aggiunto NIP-B7 per l’interazione Blossom, dando ai client Nostr e ai server Blossom un layer di coordinamento canonico dopo più di un anno di pratica informale. PR #1051 ha deprecato NIP-26, la spec di firma evento delegata. NIP-26 era stato difficile da implementare in modo sicuro ed era diventato meno attraente man mano che NIP-46 e altri pattern di signer maturavano.

Il resto del mese ha combinato pulizia con espansione applicativa: PR #1882 ha aggiunto campi di privacy policy e terms of service a NIP-11, PR #1849 ha espanso i bookmark web di kind 39701 sotto NIP-B0, PR #1891 ha aggiunto quel kind di bookmark al README, e PR #1895 ha aggiunto tag standardizzati NIP-B0. OpenSats ha annunciato la sua Eleventh Wave of Nostr Grants il 16 aprile, finanziando Swae, HAMSTR, Vertex, Nostr Double Ratchet e Nostr Game Engine. Primal, Coracle, noStrudel, nostr-tools, NDK e rust-nostr stavano anch’essi rilasciando in questo periodo, quindi la pulizia del protocollo si è affiancata al lavoro attivo su client e librerie.

Aprile 2026: hardening di NIP-34, badge e grant focalizzate sull’adozione

L’aprile 2026, il mese con cui si chiude questo numero, ha avuto quattro PR NIPs mergiate. La prima è stata PR #2276, mergiata il 1° aprile, che ha modificato i badge profilo NIP-58 al kind 10008 e aggiunto set di badge di kind 30008, rendendo l’assegnazione dei badge e le collezioni di badge più componibili. Un secondo cambiamento di usabilità git-over-Nostr è arrivato in PR #2312, mergiata il 10 aprile, che ha aggiunto la semantica URL di clone nostr:// a NIP-34. Le pulizie del 25 aprile, PR #2325 e PR #2326, hanno rimosso linguaggio NIP-34 inutilizzato e scorretto.

I commit correlati affilano le stesse superfici. Il 22 aprile, fiatjaf ha aggiunto una lista di server Blossom a NIP-51 e regolato l’editing dei metadati NIP-29 per corrispondere al comportamento PUT-style di Flotilla. Il 26 aprile, ha rinominato NIP-5A per chiarezza. L’aprile 2026 si è concentrato sul rendere superfici di protocollo già usate più facili da implementare e più difficili da fraintendere.

OpenSats ha annunciato la sua Sixteenth Wave of Nostr Grants l'8 aprile, sostenendo Amethyst Desktop, Nostr Mail, Nostrord, Nurunuru (null–nostr) e un rinnovo HAMSTR: client desktop, messaggistica email-like, UX di gruppo, onboarding giapponese e connettività off-grid.

Grazie per aver letto Nostr Compass #20. Mandateci un DM su Nostr con suggerimenti, correzioni o nuovi progetti da coprire.

Nostr Compass #19

Wed, 22 Apr 2026 00:00:00 +0000

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

Questa settimana: Amethyst chiude un grande ciclo di lavoro su Marmot, communities NIP-72, zap goals NIP-75 e audio rooms basate su Media over QUIC. TollGate stabilizza l’accesso Internet pay-per-use su Nostr e Cashu con v0.1.0. nostream completa una settimana di lavoro relay attorno a NIP-45, NIP-62, compressione, hardening delle query e piena parità con NIP-11. Forgesworn pubblica un intero stack per firma, identità e API a pagamento su Nostr. ShockWallet continua a spingere flussi Lightning nativi su Nostr. Il gruppo Formstr porta avanti 26 PR tra hardening di sicurezza e supporto RRULE. StableKraft, Keep, topaz, WoT Relay, Flotilla e NipLock completano la lista delle release. Gli approfondimenti di questa settimana coprono NIP-72 e NIP-57.

Shipping This Week

Primal Android ships Explore tab, NIP-05 verification, and audio player

Primal Android ha unito 11 PR sopra il redesign del feed della settimana scorsa. PR #1021 introduce una nuova tab Explore costruita su utenti popolari, follow packs e curated feeds, PR #1015 aggiunge un editor dei feed che si prepopola dalla DSL Advanced Search di Primal, PR #994 porta la UI di verifica NIP-05 e PR #997 integra un audio player inline nei feed. PR #1018 aggiunge anche il pairing nostr-connect NIP-46 dal wallet QR scanner.

strfry adds Prometheus write-path metrics and fixes NIP-42 AUTH envelope

strfry ha pubblicato un gruppo di miglioramenti orientati agli operatori. PR #194 aggiunge un exporter Prometheus dedicato per le metriche del write path, PR #197 registra byte e compressione per connessione e PR #192 rende configurabile a runtime il limite dei tag nei filtri. Sul piano della correttezza del protocollo, PR #201 cambia le risposte di fallimento AUTH NIP-42 da NOTICE all’envelope OK previsto dalla specifica.

Shopstr hardens storefront security across 13 PRs

Shopstr, client marketplace su Nostr, ha unito 13 PR dominate da fix di sicurezza. PR #434 chiude un hole di stored JavaScript nei link delle storefront, PR #417 fa escaping dell’HTML delle policy per bloccare XSS riflesso, PR #418 chiude un’API di cancellazione eventi cached non autenticata e PR #433, PR #419, PR #435 e PR #414 rafforzano letture, mutazioni ed endpoint sensibili.

Nostria v3.1.26 through v3.1.28 add background music playback on Android

Nostria ha pubblicato sei release da v3.1.22 a v3.1.28. La novità principale di v3.1.26 è la riproduzione musicale in background su Android, con controlli media nella notification bar e nella lock screen. Le release successive rafforzano questo nuovo media-service surface.

Wisp v0.18.0-beta adds Normie Mode, For You feed, and NIP-29 group config

Wisp, client Android in Kotlin e Jetpack Compose di barrydeen, ha pubblicato v0.18.0-beta il 16 aprile. PR #462 aggiunge una Normie Mode con importi fiat-denominati, PR #464 rinnova l’onboarding e PR #469 introduce un feed For You. Sul lato protocollo, PR #471 aggiunge la configurazione dei gruppi NIP-29 e PR #478 corregge il flusso AUTH NIP-42 prima degli eventi amministrativi di gruppo. PR #481 inoltra anche le note agli inbox relay NIP-65 delle pubkey menzionate.

NoorNote v0.8.4 adds Scheduled Posts and live stream zapping

NoorNote ha pubblicato v0.8.4 e v0.8.5. La novità principale della v0.8.4 è Scheduled Posts: l’app consegna un evento già firmato a un relay gestito da NoorNote che lo pubblica al momento pianificato, cosi le chiavi private non lasciano mai il dispositivo. La stessa release aggiunge zapping con un tocco dalle card dei live stream, dove i sats compaiono nell’overlay chat via NIP-53. La v0.8.5 corregge un bug di deduplicazione della timeline.

topaz v0.0.2 ships a Nostr relay for Android

topaz, nuovo relay Nostr che gira su telefoni Android creato da fiatjaf, ha pubblicato v0.0.2 il 17 aprile. Il progetto è Kotlin-first e punta a trasformare il telefono in un relay personale sempre disponibile. Per ora l’obiettivo è stretto: un relay funzionante in un pacchetto Android installabile.

StableKraft v1.0.0 ships the first stable music-and-podcast PWA release

StableKraft è una PWA Next.js per scoprire, organizzare e ascoltare musica prelevata dai feed podcast, con Nostr per auth e funzioni social e Lightning per i pagamenti V4V. Ha raggiunto v1.0.0 il 18 aprile. Nella stessa settimana il progetto ha stretto l’ingestion dei feed con una cache OPML di 15 minuti e la rimozione di XML illegale, e ha ridotto la finestra di reparse notturna da 720 ore a 24 ore per permettere ai feed aggiunti di recente di autoripararsi più in fretta.

NipLock ships a NIP-17-based password manager

NipLock è un password manager che memorizza e sincronizza credenziali tra dispositivi usando messaggi diretti gift-wrapped NIP-17. Ogni voce password è un DM NIP-17 dall’utente verso se stesso, cosi gli stessi eventi si replicano su qualunque dispositivo si autentichi con la stessa chiave. La firma funziona con nsec raw, estensioni browser come nos2x o Amber via NIP-46.

flotilla-budabit polishes its NIP-34 repo surface

Il fork della comunità Budabit di Flotilla, flotilla-budabit, ha pubblicato un gruppo di fix per il proprio workflow git-over-nostr NIP-34. Gli aggiornamenti ripristinano i controlli per la discussione dei repository, mantengono visibili le sticky repo tabs sulle pagine dettaglio, caricano gli annunci repo dai relay GRASP salvati e tengono sincronizzato lo stato delle patch applicate dai maintainer.

rx-nostr 3.7.2 through 3.7.4 add default verifier and optional constructor args

rx-nostr, libreria Nostr basata su RxJS, ha pubblicato 3.7.2, 3.7.3 e 3.7.4. PR #192 aggiunge un verificatore Schnorr predefinito e PR #195 rende opzionali gli argomenti di createRxNostr() per integrazioni rapide a configurazione zero.

Keep Android v1.0.0 ships with reproducible builds and zero trackers

Keep, gestore di password e segreti nativo Nostr, ha pubblicato v1.0.0 il 21 aprile dopo una serie di PR di hardening. PR #241 aggiunge una recipe per build riproducibili, PR #248 sostituisce Google ML Kit con ZXing per rimuovere la dipendenza da Google Play Services, PR #252 pubblica una scansione Exodus Privacy che mostra zero tracker e PR #256 aggiunge un file zapstore.yaml per la distribuzione tramite zapstore.

Flotilla 1.7.3 and 1.7.4 add kind-9 wrapping for richer NIP-29 rooms

Flotilla, client per gruppi NIP-29 di hodlbod, ha pubblicato 1.7.3 e 1.7.4. Il cambiamento di protocollo principale è il wrapping dei tipi di contenuto non-chat dentro eventi kind 9, annunciato nel release note di hodlbod e collegato a PR #2310. Questo permette di preservare il contesto della stanza quando eventi come poll o calendario vengono inviati nel gruppo.

WoT Relay v0.2.1 migrates eventstore to LMDB

WoT Relay, relay filtrato tramite web of trust di bitvora, ha pubblicato v0.2.1 il 22 aprile. PR #97 migra l’eventstore a LMDB, PR #99 aggiorna golang.org/x/crypto e PR #100 aggiorna URL software e stringa versione in NIP-11.

Formstr suite: Pollerama security pass, Forms i18n, Calendar RRULE support

La suite Formstr ha unito 26 PR tra Pollerama, Formstr Forms e Nostr Calendar, con un tema chiaro di sicurezza sul lato poll e avanzamento funzionale sul resto.

Pollerama, l’app nostr-polls, rafforza la gestione delle chiavi. PR #182 scade i DM in cache al logout, PR #175 sposta la chiave locale in uno storage browser più sicuro e PR #171 protegge JSON.parse del contenuto profilo kind 0 in tutti i percorsi di login. PR #186 aggiunge deep linking HTTPS e PR #169 rende cliccabili i nomi degli autori nei risultati.

Formstr, suite nostr-forms, amplia la superficie di input e onboarding. PR #475 aggiunge supporto a URL audio e video, PR #439 introduce i18n, PR #466 aggiunge un importatore da Google Forms e PR #463 rimuove log sensibili dal browser console.

Nostr Calendar by Formstr ha pubblicato v1.3.0 e v1.4.0. PR #107 aggiunge supporto multiplo e personalizzato a RRULE, PR #101 interpreta come UTC le floating RRULE date secondo RFC 5545, PR #97 permette di aggiungere eventi condivisi al proprio calendario, PR #86 introduce preferenze di notifica per lista e PR #112 rinnova login e loading path. Tutti e tre i progetti si basano sugli eventi calendario NIP-52.

Also shipped: notedeck, nostr.blue, cliprelay, Captain’s Log

Alcuni client hanno pubblicato release iterative senza una singola headline dominante. notedeck ha pubblicato v0.10.0-beta.4 con fix su rendering a colonne e relay pool. nostr.blue v0.8.6 aggiorna Dioxus e sblocca la build Android. cliprelay ha pubblicato Desktop v0.0.3 e Android v0.0.4, stringendo il loop di sync. Captain’s Log ha pubblicato tre build alpha che aggiungono il rilevamento della liveness dei sync relay.

In Development

whitenoise-rs refactors to session-scoped account views

whitenoise-rs, il daemon Rust sotto il client Marmot, ha unito 15 PR per una refactor multi-fase che sposta la logica da singleton globali a viste per-account AccountSession. L’obiettivo è scomporre un monolite condiviso in superfici più piccole, più facili da comprendere, testare ed evolvere senza effetti collaterali tra account diversi.

La base arriva con PR #743 e PR #753, seguite dallo spostamento di draft, settings, operazioni messaggi, lettura e scrittura di gruppo, membership, notifiche push, letture dei key package e creazione dei gruppi nelle PR successive. PR #770 chiude il giro reindirizzando il dispatch degli eventi sulla sessione, cosi ogni account consuma il proprio traffico relay senza contesa.

White Noise app adds block/unblock UI, leave-group, and offline notices

White Noise, client Marmot, aggiunge i controlli mancanti sul ciclo di vita dei gruppi. PR #578 pubblica la UI per block e unblock sopra l’hook introdotto in PR #573, PR #571 e PR #572 collegano clear_chat, delete_chat e leave_and_delete_group dal lato Rust all’app, e PR #569 insieme a PR #576 aggiungono avvisi offline nelle schermate chat e impostazioni. PR #585 restringe inoltre la cancellazione da “all key packages” a “legacy key packages”.

MDK adds mixed-version invite support and SelfUpdate convergence

MDK, il Marmot Development Kit, ha unito sette PR. La linea comune è la compatibilità tra versioni vicine, mantenendo i client in grado di invitarsi a vicenda, ruotare il proprio stato e recuperare da input malformati.

PR #261 calcola le RequiredCapabilities di un gruppo come LCD delle capability degli invitati e sblocca inviti tra Amethyst e White Noise. PR #264 converge il formato wire di SelfUpdate tra implementazioni, PR #262 valida i key package degli invitati prima di persistere il signer del creatore, PR #256 corregge la validazione della depletion admin lato ricevente, PR #259 protegge lo stato in-memory critico e PR #265 espone un accessor group_required_proposals.

nostter adds NIP-44 encryption across people lists, bookmarks, and mutes

nostter ha unito 10 PR. PR #2088 aggiunge cifratura NIP-44 alle mute list, PR #2089 la aggiunge ai bookmark e PR #2090 alle people list, migrando dove possibile da NIP-04. PR #2087 rimuove anche un vecchio percorso di migrazione per le mute kind 30000.

zap.cooking ships Nourish scoring and a reusable comment thread

zap.cooking, client Nostr per ricette, ha unito 20 PR. La novità principale è un modulo Nourish per il punteggio nutrizionale delle ricette nelle PR #317 e PR #319. Accanto a questo, una refactor in quattro fasi da PR #299 a PR #302 estrae il modulo Comments in un CommentThread riutilizzabile.

ridestr extracts shared rider coordinator

ridestr, app di ride-sharing decentralizzata, ha unito 10 PR che rifattorizzano le schermate Compose in componenti più focalizzati ed estraggono la logica di protocollo per rider e driver in un modulo coordinatore condiviso :common. PR #60 aggiunge anche un ricevitore kind 3189 lato Roadflare.

Blossom drafts a BUD-01 Sunset header for blob expiration

Blossom, protocollo di hzrd149 per la memorizzazione di blob su server HTTP indicizzati da hash SHA-256, ha aperto PR #99 per aggiungere un header Sunset a BUD-01. Il server potrebbe usarlo per pubblicizzare un timestamp futuro dopo il quale un blob non sarà più servito, permettendo ai client di pianificare in anticipo invece di scoprire la scadenza solo con un 404.

New Projects

Forgesworn publishes a 29-repo cryptographic toolkit for Nostr

Forgesworn ha pubblicato 29 repository open source in cinque giorni, coprendo firma, identità, attestazioni, web of trust e discovery di API a pagamento su Nostr.

Lo stack di firma ruota attorno a nsec-tree, schema deterministico di derivazione di sotto-identità che trasforma un master secret in identità Nostr illimitate e non collegabili, e a Heartwood, signer remoto NIP-46 che gira su Raspberry Pi con Tor attivo per default. Sapwood aggiunge una UI di gestione web, heartwood-esp32 porta lo stesso approccio su una board Heltec WiFi LoRa 32 e nsec-tree-cli espone i flussi di derivazione, prova e recupero Shamir.

Sul lato identità e fiducia, Signet arriva a v1.6.0 come protocollo di verifica dell’identità decentralizzata per Nostr, nostr-attestations definisce un singolo evento kind 31000 per credential, endorsement, provenance e trust, e nostr-veil costruisce sopra un web of trust privacy-preserving con firme di anello LSAG su secp256k1.

Sul lato monetizzazione, toll-booth è un middleware L402 per Express, Hono, Deno, Bun e Cloudflare Workers che trasforma una API in un toll booth Lightning in una riga. toll-booth-dvm espone la API protetta come DVM NIP-90, toll-booth-announce la collega a 402-announce, che pubblica eventi parameterized replaceable kind 31402 per la discovery di servizi HTTP 402 su Nostr, e 402-indexer indicizza questi annunci. L’organizzazione pubblica anche una collezione di 29 draft NIP.

ShockWallet ships Nostr-native Lightning wallet sync and multi-node connections

ShockWallet è un wallet Lightning che usa Nostr come trasporto per connettersi a nodi Lightning self-custodial. L’app si accoppia a uno o più nodi Lightning.Pub tramite un nprofile, poi firma le autorizzazioni di pagamento end-to-end tra wallet e nodo. Il team ha pubblicato PR #608 il 18 aprile con un pass UI sulla dashboard dei canali, accanto a un flusso QR con admin-invite-link per nuovi utenti PUB (PR #606) e un fix di leggibilità della dashboard metriche (PR #607).

ShockWallet usa gli eventi dati specifici per applicazione di NIP-78 per la sincronizzazione multi-device dello stato del wallet, cosi la vista del wallet resta coerente tra browser desktop e telefono senza server centralizzato. Questo lo colloca un livello sotto NIP-47: NIP-47 è l’interfaccia che un’app usa per chiedere a un wallet esistente di pagare, mentre ShockWallet usa Nostr come trasporto dell’account e della sessione del wallet verso il nodo Lightning sottostante.

Nostrability issues migrate to git over Nostr after GitHub censorship

Nostrability, il tracker di interoperabilità di elsat per client e relay Nostr, sta spostando il proprio workflow issue su git over Nostr dopo la rimozione dell’organizzazione Nostrability da GitHub. Il tracker migrato ora vive su GitWorkshop/ngit, dove i problemi esistenti sono già stati trasferiti e i futuri report di interoperabilità possono restare dentro un’infrastruttura nativa Nostr.

nowhere encodes full websites into URL fragments and routes orders through Nostr

nowhere è un nuovo progetto AGPL-3.0 di 5t34k che serializza un intero sito nel frammento URL dopo #, lo comprime con sostituzione di dizionario e raw DEFLATE e lo codifica in base64url. Poiché HTTP vieta al browser di inviare i frammenti al server, l’host che consegna la pagina non vede mai il contenuto e il sito stesso non viene memorizzato su un server. Il progetto include otto tipi di sito, cinque completamente statici e tre che usano relay Nostr per ordini, post e firme con chiavi effimere e cifratura NIP-44.

Small new surfaces: relayk.it and Brainstorm Search

Due progetti piccoli meritano una menzione rapida. relayk.it, costruito da sam del team Soapbox, è un client per la discovery di relay costruito con Shakespeare che gira interamente nel browser. Brainstorm Search arriva come interfaccia di ricerca Nostr single-page focalizzata sull’emersione di contenuti attraverso la rete.

Protocol and Spec Work

NIP Updates

Proposte e discussioni recenti nel repository NIPs:

Open PRs and Discussions:

NIP-67: EOSE Completeness Hint (PR #2317): propone un terzo elemento facoltativo nel messaggio EOSE di NIP-01 per indicare se il relay ha davvero consegnato tutti gli eventi memorizzati che corrispondono al filtro.
NIP-5D: Nostr Applets (PR #2303): propone un nuovo kind per distribuire applet interattive su Nostr, tra NIP-5A per siti statici e NIP-5C per scroll WASM.
NIP-29: Subgroups spec (PR #2319): estende NIP-29 con una gerarchia di sottogruppi, cosi un singolo gruppo può ospitare più canali paralleli senza creare gruppi indipendenti.
NIP-29: Explicit role permissions on kind 39003 (PR #2316): definisce uno schema esplicito dei permessi nei ruoli kind 39003, rendendo leggibili a client e utenti i poteri effettivi di un ruolo come moderator.
NIP-11: access_control field for gated-relay discovery (PR #2318): aggiunge un oggetto access_control facoltativo a NIP-11 per descrivere il modello di accesso del relay.
NIP-63a: Minimal Payment Gateway Descriptor (PR #2315): continua a iterare sulla forma dell’evento kind 10164 e sul layout dei campi per regole di subscription per livello.
NIP-XX: Agent Reputation Attestations (Kind 30085) (PR #2320): propone un evento addressable kind 30085 per attestazioni firmate su agenti e servizi autonomi in Nostr, con punteggi, evidenze e supporto ai mercati NIP-90.
NIP-TPLD: Transient Private Location Data (PR #2309): prosegue il lavoro sul kind 20411, sulla forma di cifratura NIP-44 per destinatario e sulla semantica del tag ttl.
marmot-ts 0.5.0 release PR (PR #70): la PR di release per @internet-privacy/marmot-ts@0.5.0 include i primi breaking changes pianificati nel client TypeScript Marmot.

NIP Deep Dive: NIP-72 (Moderated Communities)

NIP-72 definisce un modello di community tematiche su Nostr in cui i moderator curano una vista di lettura sopra scritture altrimenti non ristrette. Diversamente dai gruppi basati su relay di NIP-29, una community NIP-72 vive in eventi Nostr ordinari e qualunque relay che porti i kind rilevanti può servirla. Chiunque può pubblicare in una community, ma solo i post approvati da un moderator riconosciuto compaiono nel feed della community.

Una community è definita da un evento addressable kind 34550 pubblicato dal suo creatore. Il tag d è lo slug stabile della community, i tag name, description, image e rules portano i metadati di presentazione, e una serie di tag p marcati moderator elenca le pubkey i cui approval contano. Tag relay facoltativi con marker author, requests o approvals suggeriscono dove pubblicare e recuperare ciascun tipo di evento:

{
 "id": "f1e2d3c4b5a69788f1e2d3c4b5a69788f1e2d3c4b5a69788f1e2d3c4b5a69788",
 "pubkey": "c3d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8a7b6c5d4e3f2a1b0c9d8e7f6a5b4c3d2",
 "created_at": 1745280000,
 "kind": 34550,
 "tags": [
 ["d", "bitcoin-devs"],
 ["name", "Bitcoin Devs"],
 ["description", "A moderated community for Bitcoin protocol discussion."],
 ["image", "https://example.com/bitcoin-devs.png"],
 ["rules", "Stay on topic. Cite code or specs when possible."],
 ["p", "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876", "", "moderator"],
 ["p", "a1b2c3d4e5f6a7b8c9d0a1b2c3d4e5f6a7b8c9d0a1b2c3d4e5f6a7b8c9d0a1b2", "", "moderator"],
 ["relay", "wss://relay.example.com", "author"],
 ["relay", "wss://relay.moderator.com", "approvals"]
 ],
 "content": "",
 "sig": "aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899"
}

Un utente invia un post pubblicando un normale evento Nostr e aggiungendo un tag a con coordinata 34550:<creator_pubkey>:<slug>. L’approvazione è un evento separato kind 4549 pubblicato da un moderator. Questo evento riferisce il post tramite tag e, il submitter tramite tag p e la community tramite tag a, e inserisce nel content una copia stringified dell’evento inviato. Questo mantiene renderizzabile il post approvato anche se l’autore originale elimina in seguito l’evento sorgente.

{
 "id": "a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3",
 "pubkey": "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876",
 "created_at": 1745283600,
 "kind": 4549,
 "tags": [
 ["a", "34550:c3d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8a7b6c5d4e3f2a1b0c9d8e7f6a5b4c3d2:bitcoin-devs"],
 ["e", "b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4"],
 ["p", "e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5"],
 ["k", "1"]
 ],
 "content": "{\"id\":\"b3c4d5e6...\",\"pubkey\":\"e4f5a6b7...\",\"kind\":1,\"content\":\"Question about sighash flags\",\"tags\":[[\"a\",\"34550:c3d2e1f0...:bitcoin-devs\"]],\"created_at\":1745283500,\"sig\":\"...\"}",
 "sig": "bbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aa"
}

Il modello di approvazione ha tre proprietà utili. La moderazione è trasparente, perché ogni approval è un evento Nostr firmato che chiunque può recuperare e verificare. Non è esclusiva, perché lo stesso post può essere approvato da community diverse. Ed è reversibile al livello di lettura, perché se una community rimuove un moderator dal suo evento kind 34550, le approvazioni precedenti di quel moderator smettono di contare per i client che rispettano la lista corrente dei moderator.

Il lato lettura è il punto in cui i client divergono. Molti client community-aware renderizzano il feed filtrando gli eventi kind 4549 taggati con la coordinata della community, deduplicando per ID dell’evento sottostante e poi renderizzando il post embedded. Alcuni recuperano anche direttamente i submission event e usano gli approval solo come whitelist. Client come noStrudel e, da questa settimana, Amethyst via PR #2468, espongono anche la coda dei post pendenti ai moderator. Rispetto a NIP-29, il compromesso è chiaro: NIP-72 è più portabile e forkabile, mentre NIP-29 è più adatto quando spam e post non approvati devono restare del tutto fuori dal wire.

NIP Deep Dive: NIP-57 (Zaps)

NIP-57 definisce gli zaps, un modo per collegare pagamenti Lightning a identità ed eventi Nostr e pubblicare una ricevuta verificabile del pagamento sui relay. Uno zap prova che un determinato mittente ha pagato un determinato importo a un destinatario specifico per un target specifico, e la prova è leggibile da qualunque client Nostr senza doversi fidare della parola del mittente. La specifica attraversa LNURL, Lightning e Nostr e fissa come devono cooperare.

Il flusso coinvolge quattro attori. Il client del mittente scopre l’endpoint LNURL del destinatario dai metadati profilo kind 0 (lud06 o lud16) o da un tag zap sull’evento da zappare. Quel client firma poi un evento zap request kind 9734 che descrive il pagamento desiderato e lo invia al callback LNURL del destinatario, non ai relay. Dall’altra parte, il server LNURL del destinatario valida la richiesta, restituisce una invoice Lightning il cui description hash si impegna alla richiesta stringified e, una volta pagata la invoice, pubblica una ricevuta kind 9735 sull’insieme di relay richiesto dal mittente.

Una zap request kind 9734 contiene un tag p con la pubkey del destinatario, opzionalmente un tag e o a che identifica il contenuto da finanziare, un tag amount in millisats, un tag relays che elenca dove pubblicare la ricevuta e un tag k che registra il kind del target:

{
 "id": "c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2",
 "pubkey": "a5b4c3d2e1f09876a5b4c3d2e1f09876a5b4c3d2e1f09876a5b4c3d2e1f09876",
 "created_at": 1745280000,
 "kind": 9734,
 "tags": [
 ["p", "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876"],
 ["e", "b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4"],
 ["amount", "21000"],
 ["relays", "wss://relay.damus.io", "wss://nos.lol", "wss://relay.nostr.band"],
 ["k", "1"]
 ],
 "content": "great post",
 "sig": "ccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbcc"
}

La ricevuta zap kind 9735 viene pubblicata dal wallet server del destinatario dopo la conferma del pagamento. Non è firmata dal mittente ma dal wallet server usando la nostrPubkey pubblicizzata nella risposta LNURL. Una ricevuta valida porta la richiesta zap stringified nel tag description, la invoice pagata nel tag bolt11 e un tag preimage che prova il settlement:

{
 "id": "d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3",
 "pubkey": "e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0",
 "created_at": 1745280060,
 "kind": 9735,
 "tags": [
 ["p", "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876"],
 ["P", "a5b4c3d2e1f09876a5b4c3d2e1f09876a5b4c3d2e1f09876a5b4c3d2e1f09876"],
 ["e", "b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4"],
 ["bolt11", "lnbc210n1pj...bolt11invoicestring"],
 ["description", "{\"id\":\"c1d2e3f4...\",\"pubkey\":\"a5b4c3d2...\",\"kind\":9734,\"content\":\"great post\",\"tags\":[...]}"],
 ["preimage", "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef"]
 ],
 "content": "",
 "sig": "ddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccdd"
}

La regola di validazione è il cuore delle garanzie di NIP-57. Un client che mostra una ricevuta kind 9735 come zap dovrebbe verificare quattro cose: che la firma della ricevuta corrisponda alla nostrPubkey annunciata nella risposta LNURL, che l’importo della invoice bolt11 corrisponda al tag amount nella richiesta embedded, che il description hash della invoice si impegni alla richiesta zap stringified e che il preimage faccia hash al payment_hash della invoice. Una ricevuta che fallisce uno di questi controlli è solo una dichiarazione di pagamento, non una prova.

I private zaps aggiungono riservatezza. Il mittente può cifrare il content della richiesta per il destinatario e includere un tag anon, cosi la rete relay vede il target del pagamento ma non legge la nota allegata. Alcuni client fanno un passo in più e generano una coppia di chiavi effimera per la richiesta stessa, cosi la ricevuta continua a provare che il pagamento è avvenuto ma il destinatario non può ricollegare lo zap alla pubkey di lunga durata del mittente.

NIP-57 sostiene anche il sistema di zap goals di NIP-75. Un goal è un evento kind 9041 che dichiara un target e un insieme di relay sui quali contano le ricevute. Qualunque ricevuta zap collegata all’ID dell’evento del goal contribuisce al suo avanzamento. Client come Amethyst sommano gli importi validati dei bolt11 per mostrare il progresso e una classifica dei top zapper nella schermata NIP-53 Live Activities.

Le zap split sono definite in un’appendice del NIP. Un destinatario può pubblicare un profilo kind 0 con più tag zap, ciascuno con un peso, cosi un singolo zap viene diviso tra più pubkey secondo i pesi pubblicati. Client come Amethyst, Damus e noStrudel implementano già il pagamento split end-to-end.

Questo è tutto per questa settimana. Se state costruendo qualcosa o avete notizie da condividere, scriveteci su Nostr o passate da nostrcompass.org.

Nostr Compass #18

Wed, 15 Apr 2026 00:00:00 +0000

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

Questa settimana: Amethyst integra desktop Tor, una implementazione C di secp256k1, chiamate WebRTC per NIP-AC, conformità RFC 9420 MLS per Marmot e supporto multi-wallet NIP-47. nstrfy lancia notifiche push native su Nostr per Android con eventi kind 7741. HAMSTR aggiunge Reticulum e porta eventi Nostr su mesh LoRa senza Internet. Bloom pubblica una prima release come server Blossom e relay self-hosted in un’app desktop. WaveFunc debutta come directory e player di radio Internet basata su Nostr. Botburrow avvia lo sviluppo come piattaforma bot self-hosted per chat di gruppo cifrate con Marmot. Snort pubblica quattro release con audit di sicurezza e un grande lavoro sulle performance, mentre Primal Android ridisegna feed e app bars.

Shipping This Week

Bloom v0.1.0 ships self-hosted Blossom server and relay

Bloom ha pubblicato la sua prima release, v0.1.0, il 9 aprile. Costruita con Tauri v2 e React 19, Bloom unisce in una sola applicazione desktop un server media completo Blossom e un relay Nostr. Gli utenti ottengono storage file sovrano con content addressing SHA-256, supporto ai metadati file di NIP-94 e risoluzione dello schema URI blossom:// senza dover gestire da soli l’infrastruttura server.

WaveFunc v0.1.0 and v0.1.1 launch Nostr internet radio

WaveFunc ha pubblicato v0.1.0 e v0.1.1 il 13 aprile, debuttando come directory e player di internet radio basato su Nostr. Event kind personalizzati definiscono il modello dati: kind 31237 per le stazioni radio, kind 30078 per i preferiti, kind 1311 per la live chat e kind 1111 per i commenti alle stazioni. Il backend relay basato su Khatru usa SQLite e ricerca full-text Bluge con supporto a NIP-50.

WaveFunc include un wallet Cashu NIP-60 e supporto nutzap, con migrazione da NDK ad applesauce-core. v0.1.1 aggiunge caroselli per genere, un popover per donazioni Lightning, gestione delle stazioni per utenti autenticati e listing Zapstore. La build desktop Tauri v2 guadagna system tray, media key, autostart e deep linking.

Snort ships v0.5.0 through v0.5.3 with security hardening and performance overhaul

Snort, il client web React per Nostr, ha pubblicato tre release da v0.5.0 a v0.5.3. La v0.5.0 è la più grande e consegna un audit di sicurezza completo con verifica reale delle firme Schnorr, protezione rafforzata di NIP-46 contro messaggi relay falsificati, PIN encryption migliorata e rimozione della fiducia verso delegation NIP-26 non verificata. Sul fronte performance arrivano verifica WASM batch delle firme, route lazy-loaded, un loader profili riscritto e ottimizzazioni del worker relay.

La release aggiunge anche la visualizzazione delle invoice kind 7000 per DVM NIP-90. PR #620 rifà il sistema di messaggistica per ridurre la complessità del calcolo della chat list e persistere i gift wrap nel worker relay.

Primal Android ships 3.0.21 and redesigns feed layout

Primal Android ha pubblicato v3.0.21 con fix per poll zap votes, condivisione multi-account del wallet e auto-reconnect per signer remoto e servizio wallet. Sette PR successive ridisegnano il layout principale: PR #1008 unifica la schermata principale, PR #1010 implementa nuove feed card, PR #1009 aggiunge supporto video nelle card media e PR #1013 ridisegna le app bar.

Nostria v3.1.19 through v3.1.21 add local AI image generation

Nostria ha pubblicato tre release da v3.1.19 a v3.1.21 con oltre 80 commit. L’aggiunta principale è la generazione locale di immagini con Janus Pro e accelerazione WebGPU, cosi gli utenti possono creare immagini sul dispositivo senza API esterne. Le release aggiungono anche generazione cloud, chat multimodale, supporto ONNX runtime, libreria di prompt e gestione della cache.

TubeStr v1.0.3 ships feed and studio updates

TubeStr, app privata per la condivisione di video familiari costruita su Nostr, ha pubblicato v1.0.3 il 13 aprile. La release aggiunge miglioramenti a feed e studio. PR #3 rinnova l’onboarding e PR #2 corregge un errore nell’export video. L’app usa NDK e MDK per la condivisione cifrata dei media tra familiari, con integrazione Blossom pianificata per lo storage.

In Development

Botburrow begins development as Marmot bot platform

Botburrow è un nuovo progetto del team Marmot, iniziato il 3 aprile. È una piattaforma self-hosted di gestione bot dove ogni bot ha una propria identità Nostr, entra in chat di gruppo cifrate Marmot tramite messaggi Welcome e invia e riceve messaggi end-to-end encrypted. La dashboard, costruita con Rails 8.1, comunica con un singolo daemon whitenoise-rs (wnd) attraverso un socket Unix.

Botburrow espone un livello consistente di scripting e operations: comandi, trigger e azioni pianificate eseguono codice Ruby personalizzato, gli script possono ispezionare profili, membership di gruppo e inviti pendenti tramite wnd, la dashboard include una vista live chat e ogni bot ha un proprio storage file per configurazioni, cache e output generato. Un’immagine Docker con build multi-arch punta a self-hosting zero-config su Umbrel e Start9.

Nostr Archives, la piattaforma di archiviazione e analytics per Nostr su nostrarchives.com, ha continuato a svilupparsi sia lato API sia lato frontend. PR #118 aggiunge il filtro per intervallo temporale alla classifica client e PR #117 aggiunge contatori di engagement agli eventi di risposta. Sul frontend, PR #85 risolve entità Nostr direttamente dall’URL e PR #86 aggiunge una pagina di documentazione API.

La piattaforma gestisce quattro servizi relay: un relay di ricerca NIP-50, un relay per trending feeds, un scheduler relay per eventi futuri e un relay indicizzatore per kind 0, 3 e 10002.

Damus fixes favorites timeline

Damus, il client iOS, ha unito PR #3708 riscrivendo subscribe_to_favorites() con filtraggio in-place, ricostruzione della deduplicazione e persistenza della selezione tab.

Nostur adds private zaps and custom emoji viewing

Nostur, il client iOS, ha pubblicato 10 commit questa settimana aggiungendo supporto ai private zaps, visualizzazione di custom emoji, un fix per il rendering di .webp animati e il rilevamento del formato audio dei messaggi vocali.

Amber ships v6.0.1 through v6.0.3 with WebDAV backup and relay reconnection fixes

Amber, l’app signer Android NIP-55, ha pubblicato tre release questa settimana. v6.0.1 aggiunge backup WebDAV e condivisione su Google Drive, implementa exponential backoff per la riconnessione ai relay, aggiorna Quartz alla 1.08.0 e corregge la validazione eventi. v6.0.2 aggiunge un indice account per chi usa seed words e corregge la riconnessione quando il relay è offline all’avvio. v6.0.3 aggiunge un ulteriore fix per request ID vuoti nella ricezione di intent.

Plektos v0.6.0 redesigns with Ditto themes

Plektos, la piattaforma decentralizzata per meetup ed eventi costruita su NIP-52, ha pubblicato v0.6.0 e v0.6.1. L’aggiornamento aggiunge temi di comunità in stile Ditto con upload di sfondi personalizzati, configurazione della forma avatar e un generale restyling dell’interfaccia.

Shadow adds Nostr OS API and Cashu wallet app

Shadow, la piattaforma runtime di app di Justin Moon, ha pubblicato oltre 30 commit in due giorni. Commit 88cbda5 aggiunge un’app wallet Cashu dentro il runtime, commit 865c415 aggiunge una demo podcast player e il runtime espone Shadow.os.nostr e Shadow.os.audio come API di sistema di primo livello.

Lief, app Nostr per comporre e inviare lettere long-form ad altri utenti Nostr, ha pubblicato la build v2026.04.12. L’aggiornamento corregge un problema di login con Amber su Android, semplifica il flusso di nudge al signer, aggiorna nostrify e aggiunge l’integrazione Zapstore.

Espy, app social Nostr dove gli utenti condividono “momenti colore”, ha pubblicato la build v2026.04.12. L’update rifà il color picker con un arco di saturazione curvo, corregge bug di flicker nell’anello della tonalità, aggiunge personaggi Easter egg e riduce gli asset PNG di 703KB. Corregge anche il login con Amber e aggiorna nostrify.

Jumble adds per-feed kind filters and articles tab

Jumble ha pubblicato 13 commit questa settimana aggiungendo filtri per kind per singolo feed, una tab Articles, sincronizzazione dello stato di lettura delle notifiche con opzione privacy-preserving, una modalità per nascondere gli avatar e un fix a una race condition nel cambio account.

Primal Web ships 8 version bumps

Primal Web ha pubblicato le versioni 3.0.93 fino alla 3.0.101 in una settimana con 21 commit. Il lavoro si concentra su miglioramenti alla live stream chat, fix ai boundary delle mention, paginazione dei bookmark, prevenzione dei like duplicati e correzioni al relay proxy.

Protocol and Spec Work

NIP Updates

Modifiche recenti al repository NIPs:

Merged:

NIP-34 (Git Stuff): Add nostr:// clone URLs (PR #2312): NIP-34 definisce come ospitare repository git su Nostr usando annunci di repository kind 30617 che elencano branch, tag, relay e pubkey dei maintainer. Questa PR aggiunge un formato nostr:// per il clone che funziona con helper git-remote-nostr, cosi git clone nostr://npub1.../relay.ngit.dev/ngit può risolvere npub o un indirizzo NIP-05, scoprire i relay del repository e recuperare i dati del repo. Sono definiti tre pattern URL, e la PR stringe anche il formato del tag d per garantire URI validi.

Open PRs and Discussions:

NIP-63a: Minimal Payment Gateway Descriptor (PR #2315): propone un evento replaceable kind 10164 che permette ai creatori di dichiarare gateway di pagamento, modelli di prezzo e regole di subscription per contenuti a pagamento.
NIP-XX: Relay Self-Declaration Manifest and Retention Horizon (PR #2314): propone un evento replaceable kind 10100 per dichiarazioni gossipabili dei relay e un nuovo messaggio relay-to-client HORIZON che indica il timestamp più antico conservato.
NIP-TPLD: Transient Private Location Data (PR #2309): propone il kind 20411 per condividere dati di geolocalizzazione cifrati con destinatari specifici tramite NIP-44, con supporto ttl per la retention.
NIP-5C (Scrolls): WASM programs update (PR #2281): continua lo sviluppo della specifica per la pubblicazione ed esecuzione di programmi WASM su Nostr, estendendo NIP-5A da siti statici a programmi interattivi.
NIP-44 large payload support (PR #1907): propone di estendere la cifratura versionata NIP-44 oltre l’attuale limite di 65.535 byte, utile soprattutto per le risposte NIP-46 che contengono grandi contact list kind 3.
NIP-C7: Restrict kind 9 to chat views (PR #2310): richiede che i client che renderizzano una “chat view” recuperino solo eventi kind 9, evitando la perdita di contesto quando altri tipi di contenuto finiscono nella timeline di chat.

NIP Deep Dive: NIP-29 (Relay-based Groups)

NIP-29 definisce un modello di messaggistica di gruppo in cui è il relay a gestire membership e moderazione. I gruppi vivono su un relay specifico, identificati da una stringa casuale, e il relay applica le regole su chi può scrivere nel gruppo. È un’architettura diversa da Marmot o dalle chat di gruppo NIP-17: qui il relay è l’autorità e può leggere i messaggi.

Un gruppo è identificato dal formato <host>'<group-id>, per esempio groups.nostr.com'abcdef. Tutti gli eventi inviati al gruppo portano un tag h con l’ID del gruppo:

{
 "id": "a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890",
 "pubkey": "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876",
 "created_at": 1744675200,
 "kind": 9,
 "tags": [
 ["h", "abcdef"],
 ["previous", "a1b2c3d4", "e5f67890", "12345678"]
 ],
 "content": "Has anyone tested the new relay config?",
 "sig": "e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4"
}

Il tag previous funge da meccanismo di rilevamento delle manomissioni. I client includono i primi 8 caratteri hex di eventi recenti visti sullo stesso relay, e i relay rifiutano riferimenti a eventi che non possiedono. La membership è gestita da kind di moderazione nell’intervallo 9000-9020. Un utente entra pubblicando un kind 9021 e può includere un tag code collegato a codici invito creati dagli admin:

{
 "id": "b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1",
 "pubkey": "f1a2b3c4d5e6f7890123456789abcdef0123456789abcdef1234567890abcdef",
 "created_at": 1744675200,
 "kind": 9021,
 "tags": [
 ["h", "abcdef"],
 ["code", "invite-xyz-123"]
 ],
 "content": "I'd like to join the dev discussion group.",
 "sig": "11223344556677889900aabbccddeeff11223344556677889900aabbccddeeff11223344556677889900aabbccddeeff11223344556677889900aabbccddeeff"
}

Gli admin possono aggiungere utenti con ruoli, rimuoverli, modificare i metadati del gruppo e cancellare eventi. Le configurazioni vengono pubblicate come eventi addressable kind 39000 fino a 39003. I gruppi possono essere pubblici, chiusi o aperti, e la specifica accetta molti tipi di evento nel contesto del gruppo, inclusi articoli NIP-23 e live stream NIP-53. Client come Flotilla e Coracle supportano già questo modello, mentre Nostrord è in sviluppo. Il compromesso rispetto a Marmot è esplicito: niente end-to-end encryption, ma molta più semplicità operativa per comunità pubbliche e spazi di discussione aperti.

NIP Deep Dive: NIP-90 (Data Vending Machines)

NIP-90 definisce un protocollo per computazione on-demand su Nostr. Un cliente pubblica una richiesta di lavoro, i service provider competono per eseguirla e i risultati vengono consegnati come eventi Nostr. Il protocollo riserva i kind 5000-5999 alle richieste, 6000-6999 ai risultati e 7000 al feedback di stato.

Una richiesta può usare input di tipo url, event, job o text, specificare un bid massimo in millisats, aggiungere parametri con tag param e dichiarare il formato di output con output:

{
 "id": "c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2",
 "pubkey": "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876",
 "created_at": 1744675200,
 "kind": 5001,
 "tags": [
 ["i", "https://example.com/article.txt", "url"],
 ["output", "text/plain"],
 ["relays", "wss://relay.damus.io", "wss://nos.lol"],
 ["bid", "5000"],
 ["param", "lang", "en"],
 ["param", "max_tokens", "280"]
 ],
 "content": "",
 "sig": "aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899"
}

Il provider pubblica poi un risultato kind 6001 che rimanda alla richiesta originale e può includere una invoice Lightning nel tag amount. Gli eventi kind 7000 permettono aggiornamenti come payment-required, processing, error e success, dando visibilità sullo stato dei job lunghi. Il chaining dei job consente pipeline composte, per esempio trascrizione, riassunto e traduzione in sequenza.

Per la privacy, input e parametri possono essere cifrati con NIP-04 verso il provider selezionato. Tipi di job specifici vengono definiti in un repository separato, con richieste per generazione testo, riassunto, speech-to-text, immagini e raccomandazione contenuti. Client come Snort mostrano già invoice payment-required, mentre noStrudel e DVMDash aiutano rispettivamente nella scoperta e nell’osservazione dei DVM.

Questo è tutto per questa settimana. Se state costruendo qualcosa o avete notizie da condividere, scriveteci su Nostr o passate da nostrcompass.org.

Nostr Compass #17

Wed, 08 Apr 2026 00:00:00 +0000

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

Questa settimana: Amethyst distribuisce la v1.08.0 con integrazione Arti Tor e una UI Shorts ridisegnata, mentre integra implementazioni in puro Kotlin di MLS e Marmot nella sua libreria Quartz. Nostur distribuisce la v1.27.0 con registrazione video, profili GIF animati e risposte private. Shosho lancia la v0.15.0 con Shows (informazioni personalizzate sul live stream collegate a OBS) e un carousel video verticale in stile TikTok. Nymchat torna da Marmot e distribuisce chat di gruppo NIP-17 potenziate con chiavi ephemeral a rotazione. Nostr VPN distribuisce supporto exit node e packaging Umbrel attraverso sei rilasci. Amber sale alla v6.0.0-pre1 con chiavi di firma NIP-46 per connessione e aggiornamenti in-app via Zapstore. Notedeck raggiunge la v0.10.0-beta con auto-aggiornamento APK via Zapstore, e NIP-58 (Badges) riceve una migrazione di kind. Due approfondimenti NIP coprono NIP-17 (Private Direct Messages) e NIP-46 (Nostr Remote Signing).

Notizie Principali

Amethyst distribuisce Arti Tor e integra MLS e Marmot in puro Kotlin

Amethyst, il client Android mantenuto da vitorpamplona, ha distribuito quattro rilasci dalla v1.07.3 alla v1.08.0 e ha integrato un ampio blocco di lavoro non ancora rilasciato nella sua libreria Quartz (il modulo Nostr condiviso Kotlin Multiplatform). Il rilascio di punta è la v1.08.0 “Arti Tor”, che sposta la connettività Tor dell’app dalla libreria Tor basata su C a Arti, l’implementazione Rust del Tor Project. La migrazione affronta i crash casuali che si verificavano con i precedenti binding C di Tor. Arti è il sostituto a lungo termine del Tor Project per la codebase C, riscritto da zero in Rust per memory safety e async I/O.

Il rilascio v1.07.3 ha ridisegnato la UI Shorts, sostituendo il design paginato con feed edge-to-edge per immagini, short e video lunghi. Lo stesso rilascio ha migrato i badge al kind 10008 e i bookmark al kind 10003, allineandosi alla migrazione di kind NIP-58 unita questa settimana. La v1.07.4 ha corretto un problema nella gestione dei secret di Nostr Wallet Connect, e la v1.07.5 ha corretto un crash durante l’upload di immagini.

Sul branch main, ma non ancora in un rilascio taggato, il team ha scritto un’implementazione completa in Kotlin sia di MLS sia del protocollo Marmot, eliminando la necessità di binding a librerie native C/Rust. La PR #2147 aggiunge il layer centrale di messaggistica di gruppo Marmot MLS, la PR #2149 aggiunge la UI della chat di gruppo, la PR #2146 aggiunge i processor dei messaggi in ingresso e in uscita con un subscription manager, la PR #2141 aggiunge la persistenza dello stato dei gruppi MLS e la gestione della rotazione dei KeyPackage, la PR #2150 aggiunge una suite di test MLS completa con una firma di GroupInfo migliorata, e la PR #2158 aggiunge il tracciamento dello stato di pubblicazione dei KeyPackage. La PR #2166 aggiunge un’implementazione secp256k1 in puro Kotlin per le operazioni crittografiche Nostr, sostituendo la dipendenza dalla libreria C nativa. Combinata con l’implementazione Kotlin di MLS, Quartz può eseguire firma Nostr e messaggistica di gruppo Marmot senza alcun binding nativo, aprendo la strada ai target Kotlin Multiplatform inclusi quelli iOS.

Il team sta anche costruendo il supporto a NIP-AC (P2P Voice and Video Calls): la PR #2143 aggiunge una suite di test completa per la call state machine di NIP-AC, e la PR #2164 impedisce che offerte di chiamata stale vengano riattivate dopo il riavvio dell’app.

Nostur v1.27.0 aggiunge registrazione video e risposte private

Nostur, il client Nostr per iOS, ha distribuito la v1.27.0 il 2 aprile. Il rilascio aggiunge la registrazione video in-app con trim prima dell’upload, così gli utenti possono registrare clip brevi, tagliarle alla lunghezza desiderata e pubblicarle senza uscire dal client. Il supporto alle GIF animate si estende alle foto profilo e banner, con l’aggiunta anche del rendering WebP animato. Una nuova integrazione con Shortcuts permette agli utenti di inviare post Nostr dalle automazioni Apple Shortcuts. Il rilascio aggiunge anche le risposte private e corregge problemi di compatibilità DM che influivano sulla consegna dei messaggi tra Nostur e altri client.

Shosho v0.15.0 lancia Shows e un carousel video verticale

Shosho, l’app di live streaming Nostr, ha distribuito la v0.15.0 e la v0.15.1 il 7 aprile. La funzione principale è Shows: gli streamer possono preparare informazioni personalizzate sul proprio show prima di andare live e collegare lo show a OBS o a qualsiasi encoder esterno. Questo separa i metadati del “cosa sto trasmettendo” dall’atto di andare in diretta, così gli streamer possono preparare titoli, descrizioni e prodotti prima di iniziare la trasmissione. Lo stesso rilascio aggiunge un carousel video verticale in stile TikTok per scorrere live, clip e replay in un feed a schermo intero, e Quick Add per pubblicare clip video e aggiungere prodotti direttamente dalla pagina profilo. La v0.15.1 corregge un bug per cui la tastiera nascondeva il campo di input della chat del live stream.

Rilasci di Questa Settimana

Notedeck v0.10.0-beta distribuisce l’auto-aggiornamento via Zapstore

Notedeck, il client desktop e mobile del team Damus, ha distribuito v0.10.0-beta.1 e v0.10.0-beta.2 come prerelease di test per l’auto-aggiornamento APK. La PR #1417 aggiunge l’auto-aggiornamento APK via updater Nostr/Zapstore su Android, costruendo sul lavoro di discovery degli aggiornamenti nativo Nostr dalla Newsletter #14. Il flusso di aggiornamento scopre i nuovi rilasci tramite event Nostr pubblicati sui relay, poi scarica l’APK da dove lo sviluppatore lo ospita (GitHub releases, Blossom CDN o altre sorgenti), verifica l’hash SHA-256 rispetto all’event Nostr firmato e lo installa. La PR #1438 corregge un bug della welcome screen in cui i pulsanti Login e CreateAccount tornavano subito indietro, e la PR #1424 corregge l’overflow del testo nella vista sessione di Agentium AI.

Amber v6.0.0-pre1 aggiunge chiavi di firma NIP-46 per connessione

Amber, l’app signer NIP-55 (Android Signer Application), ha distribuito la v6.0.0-pre1 il 4 aprile. Il cambiamento più importante è l’introduzione di chiavi di firma per connessione per il protocollo bunker NIP-46 (Nostr Remote Signing). Invece di usare una singola keypair per tutte le connessioni bunker, Amber ora genera una chiave distinta per ogni client connesso. Se una connessione client viene compromessa, l’attaccante non può impersonare il signer verso gli altri client.

La PR #377 aggiunge il controllo e l’installazione degli aggiornamenti in-app via Zapstore, unendosi a Notedeck nell’adozione della distribuzione app nativa Nostr. La PR #375 gestisce con grazia i fallimenti di AndroidKeyStore mostrando un avviso agli utenti invece di far crashare l’app, e la PR #371 aggiunge cleanup del database con limiti di dimensione e troncamento dei contenuti per prevenire una crescita di storage senza limiti. La prerelease include anche la whitelist relay auth NIP-42 e il login tramite frase mnemonica di recovery dal ciclo v5.0.x trattato la settimana scorsa.

Nostria distribuisce un’app mobile nativa

Nostria, il client Nostr cross-platform mantenuto da SondreB, ha rilasciato un’app mobile nativa per Android con otto rilasci dalla v3.1.11 alla v3.1.18. La capacità nuova più importante è il supporto nativo ai signer locali come Amber e Aegis. Sono disponibili anche gli installer desktop per Linux, macOS e Windows. La PR #610 riduce la pressione sulla memoria del feed con limiti runtime adattivi e cleanup delle preview URL. La v3.1.14 corregge l’integrazione con Brainstorm, un provider Web of Trust. La v3.1.15 si concentra sui miglioramenti musicali. La nuova app Android è disponibile su Zapstore.

diVine 1.0.8 distribuisce upload resumable e DM

diVine, il client per video brevi, ha distribuito la 1.0.8 con 87 PR unite. Gli upload resumable permettono ai creator di riprendere upload interrotti chunk per chunk invece di ricominciare da zero su una connessione instabile. Il rilascio aggiunge impostazioni di qualità video e bitrate, doppio tap per mettere like e miglioramenti ai DM. La PR #2722 aggiunge un plugin fotocamera macOS per la cattura video desktop, e la PR #2820 migra il sistema di notifiche a un’architettura BLoC con enrichment e grouping. Il team ha anche sostituito sticker e artwork di categoria generati da AI con SVG OpenMoji (PR #2844, PR #2842).

Manent v1.3.0 aggiunge blur per note sensibili e auth NIP-42

Manent, l’app per note private cifrate e storage file, ha distribuito la v1.3.0 il 2 aprile. Gli utenti possono ora segnare le note come sensibili per sfocarle nella list view, mantenendo nascosto il contenuto privato durante lo scorrimento casuale. Il rilascio aggiunge anche il supporto NIP-42 (Authentication of Clients to Relays), permettendo a Manent di autenticarsi verso relay che lo richiedono prima di accettare event. Manent archivia tutti i dati cifrati sui relay Nostr usando la keypair dell’utente, quindi il supporto NIP-42 amplia l’insieme di relay che può usare per lo storage.

Wisp da v0.17.0 a v0.17.3 aggiunge zap ai live stream e backup wallet

Wisp, il client Nostr Android, ha distribuito sei rilasci dalla v0.16.2-beta alla v0.17.3-beta con 44 PR unite. La v0.17.0 aggiunge prompt di sicurezza per il backup del wallet e miglioramenti alla UX degli zap. La v0.17.1 aggiunge la visibilità della chat del live stream tra piattaforme e la funzionalità zap per i live stream. La PR #423 aggiunge la ricerca automatica dei profili, un’animazione di successo per gli zap e miglioramenti allo stato utente. La PR #426 corregge un crash out-of-memory in computeId per event con grandi liste di tag. I rilasci v0.16.x avevano aggiunto autocompletamento degli shortcode emoji, miglioramenti alla UI della chat di gruppo e filtraggio degli utenti bloccati in tutti i percorsi delle notifiche.

Mostro distribuisce deep link, tassi di cambio da Nostr e una correzione ai pagamenti duplicati

Mostro, l’exchange Bitcoin peer-to-peer costruito su Nostr, ha registrato aggiornamenti questa settimana sia nel daemon server sia nel client mobile. Sul lato server, la PR #692 impedisce che scritture stale degli ordini causino pagamenti duplicati, un bug che poteva portare a pagare due volte un venditore per lo stesso trade. La PR #693 usa aggiornamenti mirati per le scritture di dev_fee invece di riscrivere l’intero ordine.

Mostro Mobile, il client Flutter, ha distribuito la v1.2.3 il 3 aprile. Il rilascio gestisce deep link provenienti da diverse istanze Mostro, così gli utenti possono toccare link che instradano verso il server exchange corretto. La PR #498 rileva DM di admin e dispute nella pipeline di notifiche in background, e l’app ora recupera i tassi di cambio da Nostr con fallback HTTP/cache. La PR #560 corregge un bug bloccante nella connessione ai relay che impediva all’app di raggiungerli in certe condizioni di rete.

Unfiltered v1.0.12 aggiunge hashtag e commenti

Unfiltered, un client Nostr focalizzato su contenuti image-forward, ha distribuito la v1.0.12. La PR #69 aggiunge il supporto agli hashtag e la PR #72 aggiunge la possibilità di scrivere e visualizzare commenti sui post. La PR #71 corregge problemi di navigazione con più immagini per post.

Primal Android distribuisce condivisione wallet multi-account e auto-reconnect del remote signer

Primal, il client Nostr Android, ha distribuito un rilascio il 7 aprile. L’aggiornamento aggiunge la condivisione wallet multi-account e un menu overflow con cancellazione del wallet nei Dev Tools. Il remote signer ora si riconnette automaticamente quando la connessione cade, e il servizio wallet ha ottenuto una propria logica di auto-reconnect. Le correzioni includono i voti zap dei sondaggi che non appaiono più come Top Zaps, la prevenzione del crash con opzioni di sondaggio vuote, l’occultamento del saldo wallet quando non esiste alcun wallet, e il mapping dei tipi WalletException in codici errore nelle risposte NWC.

Titan v0.1.0 lancia un browser nativo nsite:// con registrazione dei nomi su Bitcoin

Titan, un browser desktop nativo per il web di Nostr, ha distribuito la v0.1.0 il 7 aprile. Titan risolve gli URL nsite:// cercando nomi leggibili registrati su Bitcoin, interrogando i relay Nostr per gli event di contenuto del sito e renderizzando pagine recuperate da server Blossom. Il risultato è un’esperienza di navigazione web senza DNS, senza certificati TLS e senza hosting provider. I nomi vengono registrati tramite una web interface legata a transazioni Bitcoin. Il rilascio iniziale è distribuito come .dmg per macOS (ARM, con supporto Rosetta 2 per Intel) e include il supporto all’ambiente di sviluppo Nix.

Bikel v1.5.0 distribuisce un native foreground service per telefoni de-Googled

Bikel, un tracker ciclistico decentralizzato che trasforma le corse in dati di infrastruttura pubblica usando Nostr, ha distribuito la v1.5.0 il 4 aprile. Il rilascio migra da Expo TaskManager dipendente da GMS a un foreground service nativo personalizzato, garantendo un tracking affidabile in background su LineageOS, GrapheneOS e altre varianti Android de-Googled. Il Bikel Bot ha ottenuto un’architettura dual-pocket con raccolta eCash autonoma via Cashu nutzaps. La v1.4.3 e la v1.4.2 correggono la sincronizzazione del tracking in background per ambienti Android non standard, e l’app aggiunge toggle per i punti mappa dei portabici OSM.

Sprout aggiunge supporto a NIP-01, NIP-23 e NIP-33

Sprout, una piattaforma di comunicazione di Block con relay Nostr integrato, ha distribuito la desktop/v0.1.0-rc7 il 6 aprile. Questa settimana il team ha aggiunto supporto agli articoli kind 30023 di NIP-23 (Long-form Content), agli event replaceable parametrizzati di NIP-33 con sostituzione indicizzata dal tag d, e alle text note kind 1 e follow list kind 3 di NIP-01/NIP-02. Il rilascio aggiunge anche un sistema di temi IDE adattivi con 54 temi, rifiniture UX per workflow e cronologia delle esecuzioni degli agenti, e cleanup della sidebar membri.

mesh-llm v0.56.0 distribuisce un protocollo di configurazione distribuito

mesh-llm, un sistema distribuito di inferenza LLM che usa keypair Nostr per l’identità dei nodi, ha distribuito la v0.56.0 il 7 aprile. Il rilascio aggiunge un protocollo di configurazione distribuito con semantiche di ownership, quantizzazione asimmetrica della cache KV (chiavi Q8_0 con valori Q4) per ridurre l’uso di memoria, storage nel keychain del sistema operativo per i keystore di identità, streaming chat fluido con coda dei messaggi, e correzioni al layout fullscreen e alla suddivisione della cache KV con flash attention.

Nostr VPN distribuisce supporto exit node e packaging Umbrel

Nostr VPN, una VPN peer-to-peer che usa relay Nostr per la segnalazione e WireGuard per i tunnel cifrati, ha distribuito sei rilasci dalla v0.3.0 alla v0.3.6 questa settimana. Il ciclo v0.3.x aggiunge il supporto agli exit node su Windows e macOS, permettendo ai peer di instradare il traffico Internet attraverso altri nodi della rete. La propagazione di invite e alias ora si sincronizza via Nostr, così gli utenti possono condividere l’accesso alla rete senza coordinamento out-of-band. I rilasci aggiungono packaging Umbrel per deployment self-hosted, NAT punch-through usando endpoint pubblici ricordati, cleanup automatico degli exit node stale e una specifica di protocollo pubblicata. Il progetto ha anche stabilizzato la gestione delle route su macOS con default route auto-riparanti e underlay repair, e ha aggiunto un build Android via Tauri. Sono disponibili build per macOS (Apple Silicon e Intel), Linux (AppImage e .deb), Windows e Android.

Nymchat abbandona Marmot e distribuisce chat di gruppo NIP-17 potenziate

Nymchat, il client chat capace di MLS, ha distribuito 14 rilasci dalla v3.56.261 alla v3.58.274. Il cambiamento più significativo è una svolta di protocollo: la v3.57.261 aveva aggiunto chat di gruppo Marmot MLS, ma la v3.58.268 è tornata a NIP-17 perché il supporto multi-device di Marmot non è ancora completo, e questo causava problemi nella sincronizzazione dello stato delle chat di gruppo tra dispositivi. La v3.58.271 introduce chat di gruppo NIP-17 potenziate con chiavi ephemeral a rotazione per tutti i messaggi, progettate per prevenire timing attack e correlation attack. La settimana ha portato anche un sistema amici con controllo granulare delle impostazioni (v3.58.262), sincronizzazione dei messaggi delle chat di gruppo MLS nelle impostazioni cifrate dell’app, e diverse correzioni alla connettività relay.

nak v0.19.5 aggiunge Blossom multi-server e pubblicazione outbox

nak, il toolkit Nostr a riga di comando di fiatjaf, ha distribuito la v0.19.5. Il comando blossom ora accetta più flag --server per caricare su diversi server Blossom in una sola chiamata. Un nuovo comando key espande chiavi parziali aggiungendo zeri a sinistra. Il comando event guadagna un flag --outbox per pubblicare event attraverso il modello outbox, e fetch ora termina con un codice errore quando non viene restituito alcun event.

In Sviluppo

White Noise aggiunge anteprime thumbhash e il bridge per la registrazione push

White Noise, il messenger privato costruito sul protocollo Marmot, ha unito cinque PR. La PR #549 sostituisce le anteprime immagine blurhash con thumbhash, un algoritmo più recente che produce immagini placeholder più nitide con una dimensione payload minore (tipicamente sotto i 30 byte contro i ~50-100 byte di blurhash) preservando il rapporto d’aspetto e la distribuzione dei colori dell’immagine originale. Blurhash viene mantenuto come fallback per i contenuti più vecchi. La PR #548 aggiorna whitenoise-rs e aggiunge il bridge di registrazione push MIP-05, collegando al client il lavoro sulla specifica delle push notification della settimana scorsa. La PR #493 aggiunge la paginazione basata su cursore per i messaggi chat, sostituendo la strategia di caricamento precedente con un approccio guidato dallo scroll.

Route96 aggiunge configurazione dinamica delle label e cleanup zero-egress

Route96, il media server Blossom di v0l, ha unito tre PR. La PR #80 aggiunge la configurazione dinamica del modello di label tramite admin API, permettendo agli operatori di sostituire i modelli di classificazione dei contenuti senza riavviare il server. La PR #82 aggiunge i campi di configurazione delle label alla admin UI. La PR #79 aggiunge una policy di cleanup dei file zero-egress che rimuove automaticamente i file mai scaricati, mantenendo bassi i costi di storage per gli operatori.

Snort distribuisce hardening di sicurezza e invoice di pagamento DVM

Snort, il client web, ha distribuito due rilasci questa settimana insieme a un audit di sicurezza completo. Le correzioni includono verifica delle firme Schnorr, protezione NIP-46 contro la falsificazione dei messaggi relay (impedendo ad attaccanti di iniettare richieste di firma attraverso relay compromessi), miglioramenti alla cifratura del PIN e rimozione della fiducia nella delega NIP-26. I miglioramenti prestazionali arrivano dalla verifica Schnorr batch in WASM, route lazy-loaded, traduzioni precompilate ed eliminazione della doppia verifica per event. La PR #618 aggiunge la visualizzazione dell’invoice kind 7000 con pagamento richiesto di NIP-90 (Data Vending Machine), così quando un DVM risponde con un requisito di pagamento, Snort renderizza direttamente la Lightning invoice nel feed.

Damus migliora la compattazione LMDB

Damus, il client iOS, ha unito la PR #3719 che aggiunge la compattazione automatica di LMDB su base pianificata, impedendo al database locale di crescere senza limiti nel tempo. La PR #3663 migliora la BlurOverlayView in modo che sembri protettiva invece che rotta.

Captain’s Log aggiunge indicizzazione dei tag e sync delle note

Captain’s Log (Comet), lo strumento di scrittura long-form nativo Nostr di Nodetec, ha unito quattro PR questa settimana. La PR #156 aggiunge indicizzazione dei tag e supporto alla sincronizzazione tra note, la PR #157 rifattorizza il sync delle note e la gestione dei tag, e la PR #159 corregge la sincronizzazione delle note cestinate in modo che gli elementi eliminati restino eliminati su tutti i dispositivi.

Relatr v0.2.x ridisegna il sistema plugin con un marketplace di validator nativo Nostr

Relatr, un motore Web of Trust che calcola ranking di fiducia dalla distanza nel grafo sociale e da validator configurabili, ha distribuito la famiglia v0.2.x con un redesign completo del sistema plugin. I validator sono ora scritti in Elo, un linguaggio di espressioni funzionali portabile forkato per supportare capacità orchestrate dall’host in più passi (query Nostr, lookup del grafo sociale, risoluzione NIP-05). I plugin vengono pubblicati come event Nostr kind 765, rendendo la distribuzione nativa alla rete relay. Un nuovo plugin marketplace permette agli operatori di scoprire, installare e pesare i validator dal browser, con una CLI (relo) per authoring e pubblicazione locale. L’architettura è sandboxed: i plugin possono invocare solo le capacità che l’host fornisce esplicitamente, quindi un validator malevolo non può uscire dal proprio scope definito. Le istanze Relatr ora possono essere gestite dal sito web, con visibilità completa su quali plugin compongono l’algoritmo di scoring e sui pesi individuali di ciascuno.

Shopstr migliora navigazione mobile e controllo accessi

Shopstr, il marketplace nativo Nostr per comprare e vendere con Bitcoin, ha spinto 158 commit questa settimana nella sua app principale e nel progetto companion Milk Market. Le correzioni includono miglioramenti al layout mobile delle community, comportamento di chiusura del menu durante la navigazione e auto-chiusura dei dropdown. Le route protette non possono più essere raggiunte via URL diretto senza login, e la logica di matching degli slug ora gestisce correttamente più corrispondenze esatte.

Pollerama aggiunge notifiche, ricerca film e nuova rating UI

Pollerama, un’app di polling, survey e rating sociale costruita su Nostr, ha aggiunto notifiche dei thread, una funzione di ricerca film e un overhaul della rating UI. Il rilascio corregge anche problemi di caricamento del feed e aggiorna le versioni delle dipendenze.

Purser costruisce un payment daemon nativo Nostr con cifratura Marmot

Purser, un payment daemon nativo Nostr progettato come sostituto di Zaprite, ha unito nove PR questa settimana che costruiscono la sua architettura centrale. Il progetto usa MLS di Marmot tramite MDK per la messaggistica cifrata merchant-customer, con Strike e Square come payment provider. Questa settimana sono arrivati caricamento di configurazione e catalogo, validazione dello schema dei messaggi, il layer di comunicazione MDK, le implementazioni dei provider Strike e Square, un motore di polling, anti-spam rate limiting, persistenza dei pagamenti pending e la pipeline di elaborazione degli ordini. Tutti i 99 test ora esercitano operazioni MLS reali di mdk-core dopo che il team ha rimosso il mock MLS in favore della cifratura reale in modalità locale.

Vector rifattorizza gli allegati DM e aggiunge la modifica del profilo

Vector, il messenger Nostr focalizzato sulla privacy costruito con Tauri, ha unito la PR #55 che rifattorizza il frontend. La decrittazione e il salvataggio degli allegati DM sono stati spostati nella libreria vector-core, e l’app ora supporta la modifica del profilo. Il flag di cancellazione dell’upload è collegato correttamente attraverso TauriSendCallback, e i callback inutilizzati per l’anteprima degli allegati sono stati ripuliti.

Lavoro su Protocollo e Specifiche

Aggiornamenti NIP

Modifiche recenti al repository NIPs:

Uniti:

NIP-58 (Badges): i Profile Badges passano al kind 10008, i Badge Sets al kind 30008 (PR #2276): Migra i Profile Badges dal kind 30008 al kind 10008 (un event replaceable, uno per pubkey) e introduce il kind 30008 per i Badge Sets. In precedenza i Profile Badges usavano lo stesso kind (30008) delle definizioni dei badge, rendendoli event replaceable parametrizzati indicizzati da un tag d. Il nuovo kind 10008 è un semplice event replaceable: uno per pubkey, nessun tag d necessario. I client interrogano un singolo event replaceable per utente invece di scandire event replaceable parametrizzati. Amethyst v1.07.3 distribuisce già questa migrazione.
NIP-34 (Git Stuff): aggiungere follow list relative a git (PR #2130): Aggiunge convenzioni di follow list per il tracciamento di repository e issue NIP-34. Gli utenti pubblicano follow set kind 30000 con tag d come git-repos o git-issues contenenti riferimenti tag a ai repository (kind 30617) che vogliono seguire. I client possono sottoscrivere questi follow set per mostrare l’attività dei repository nel feed di un utente, in modo simile a come le contact list kind 3 funzionano per le pubkey.

PR aperte e discussioni:

NIP-AC: P2P Voice and Video Calls over WebRTC (PR #2301): Estende il NIP-100 originale (implementato da 0xChat) con tre cambiamenti: migrazione alla cifratura NIP-44 avvolta in gift wrap NIP-59 per eliminare i metadata leak, un workflow WebRTC specificato per setup di chiamate vocali e video (offer, answer, ICE candidates), e un modello di mesh group call in cui ogni peer stabilisce una connessione WebRTC diretta con tutti gli altri peer. La specifica non è backwards-compatible con NIP-100. Amethyst ci sta già lavorando, con una suite di test per la call state machine (PR #2143) e la gestione delle call offer stale (PR #2164) arrivate questa settimana.
NIP-340 (FROST Quorum) (PR #2299): Propone convenzioni per la threshold signing FROST (Flexible Round-Optimized Schnorr Threshold) su Nostr. FROST permette a un gruppo di signer di controllare collettivamente un’identità Nostr dove qualsiasi insieme t-of-n di membri può firmare event senza ricostruire la chiave privata completa. Il NIP definisce come coordinare i round di firma, distribuire key share e pubblicare event firmati in threshold, costruendo sul lavoro del signer Igloo dal progetto FROSTR.
NIP-5D (Nostr Web Applets) (PR #2303): Definisce un protocollo postMessage per applicazioni web sandboxed (“napplets”) eseguite in iframe che comunicano con un’applicazione host (“shell”). La shell fornisce alla napplet firma Nostr, accesso relay e contesto utente tramite una structured message API, mentre la sandbox iframe impedisce l’accesso diretto alle chiavi. Questo estende il modello di hosting di siti web statici di NIP-5A verso applicazioni interattive in grado di leggere e scrivere event Nostr. Il NIP è in sviluppo attivo con un’implementazione runtime funzionante.
NIP-5C (Scrolls) (PR #2281): Rinominato dalla precedente proposta NIP-A5. Definisce convenzioni per pubblicare e scoprire programmi WebAssembly su Nostr. I binari WASM vengono archiviati come event Nostr, e i client possono scaricarli ed eseguirli in un runtime sandboxed. Una demo app mostra scrolls in esecuzione nel browser, con programmi di esempio pubblicati come event Nostr che qualsiasi client può recuperare ed eseguire.
NIP-85 (Trusted Assertions): chiarimenti (PR #2304): Stringe il linguaggio della specifica intorno a chiavi multiple e relay multipli per provider di servizi, chiarendo come i client dovrebbero gestire assertion provenienti da provider che operano attraverso più pubkey o endpoint relay.
NIP-24 (Extra Metadata Fields): published_at per event replaceable (PR #2300): Generalizza il tag published_at da NIP-23 (Long-form Content) a tutti gli event replaceable e addressable. Il tag è solo display-only: se published_at è uguale a created_at, i client mostrano l’event come “created” in quel momento; se differiscono (perché l’event è stato aggiornato), i client possono mostrare “updated” invece. Questo permette ai profili kind 0 di mostrare date “joined at” e agli altri event replaceable di preservare il timestamp di pubblicazione originale attraverso gli aggiornamenti. Una proposta complementare NIP-51 (PR #2302) aggiunge lo stesso tag agli event di lista.
NIP-59 (Gift Wrap): kind di gift wrap ephemeral (PR #2245): Aggiunge il kind 21059 come controparte ephemeral del gift wrap esistente kind 1059. Gli event ephemeral (kind 20000-29999) seguono la semantica di NIP-01: i relay non sono tenuti a memorizzarli e possono scartarli dopo la consegna. Questo permette alle applicazioni di inviare messaggi gift-wrapped che scompaiono dai relay dopo la consegna, riducendo i requisiti di storage per la messaggistica ad alto volume mantenendo lo stesso modello di cifratura a tre layer dei normali DM NIP-17.

OpenSats annuncia la sedicesima ondata di grant Nostr

OpenSats ha annunciato la sua sedicesima ondata di grant Nostr l'8 aprile, finanziando quattro grant alla prima assegnazione e un rinnovo. Amethyst Desktop riceve fondi per permettere al contributor Robert Nagy di costruire un’app desktop standalone sopra i moduli Quartz e Commons, portando il set di funzionalità del client Android a interfacce guidate dal mouse con connessioni relay persistenti. Nostr Mail riceve fondi per costruire un sistema email completo su Nostr usando event kind 1301 avvolti in gift wrap NIP-59, con un client Flutter e server bridge SMTP per compatibilità con Gmail/Outlook. Nostrord riceve fondi per un client di gruppo Kotlin Multiplatform basato su relay NIP-29 con messaggistica di gruppo, moderazione e thread in stile Discord. Nurunuru riceve fondi per costruire una versione iOS nativa del client Nostr orientato al pubblico giapponese modellata sull’interfaccia familiare di LINE, con login biometrico basato su passkey per l’onboarding. HAMSTR ha ricevuto un rinnovo del grant (finanziato la prima volta nell’undicesima ondata).

NIP Deep Dive: NIP-17 (Private Direct Messages)

NIP-17 definisce lo standard attuale per i messaggi diretti privati su Nostr. Sostituisce il vecchio schema NIP-04 (Encrypted Direct Messages), che perdeva metadati (mittente, destinatario e timestamp erano tutti visibili sui relay) e usava una costruzione crittografica più debole. NIP-17 combina NIP-44 (Encrypted Payloads) per la cifratura con NIP-59 (Gift Wrap) per la protezione dei metadati, creando un sistema a tre layer in cui i relay non possono vedere chi sta parlando con chi.

Il protocollo usa tre event kind annidati l’uno dentro l’altro. Il layer più interno è il messaggio vero e proprio, un event kind 14 non firmato:

{
 "id": "a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890",
 "pubkey": "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876",
 "created_at": 1744108800,
 "kind": 14,
 "tags": [
 ["p", "f1a2b3c4d5e6f7890123456789abcdef01234567890abcdef1234567890abcdef", "wss://inbox.example.com"],
 ["subject", "Project update"]
 ],
 "content": "The new relay config is deployed. Let me know if you see any issues.",
 "sig": ""
}

L’event kind 14 è deliberatamente non firmato (sig vuoto). La specifica descrive questo aspetto come una forma di deniability, ma nella pratica la protezione è limitata. Il seal kind 13 che avvolge il rumor è firmato con la chiave reale del mittente. Un destinatario può mostrare il seal firmato a una terza parte, provando che il mittente ha comunicato con lui, anche senza rivelare il contenuto del messaggio. Con prove a conoscenza zero, un destinatario può persino dimostrare il contenuto esatto del messaggio senza rivelare la propria chiave privata. Il rumor non firmato è come una lettera non firmata in una busta firmata: la firma sulla busta collega il mittente al contenuto. La vera deniability richiederebbe autenticazione simmetrica (come gli HMAC di Signal), incompatibile con il modello relay decentralizzato di Nostr dove i messaggi devono essere self-authenticating. I veri punti di forza di NIP-17 sono la privacy dei metadati e la segretezza del contenuto, non la deniability.

Questo messaggio non firmato viene avvolto in un seal kind 13, firmato dal mittente effettivo e cifrato con NIP-44 per il destinatario:

{
 "id": "b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1",
 "pubkey": "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876",
 "created_at": 1744022400,
 "kind": 13,
 "tags": [],
 "content": "<nip44-encrypted kind 14 payload>",
 "sig": "e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4"
}

Il seal non ha tag, quindi anche se venisse decrittato non rivelerebbe il destinatario. Il seal è firmato con la chiave reale del mittente, il che permette al destinatario di autenticare il messaggio controllando che il pubkey del seal corrisponda al pubkey del kind 14 interno.

Il seal viene poi avvolto in un gift wrap kind 1059, firmato con una chiave casuale usa-e-getta e indirizzato al destinatario:

{
 "id": "c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2",
 "pubkey": "9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba",
 "created_at": 1744065600,
 "kind": 1059,
 "tags": [
 ["p", "f1a2b3c4d5e6f7890123456789abcdef01234567890abcdef1234567890abcdef"]
 ],
 "content": "<nip44-encrypted kind 13 payload>",
 "sig": "fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210"
}

Il pubkey del gift wrap è una chiave casuale generata solo per questo messaggio, e il created_at è randomizzato fino a due giorni nel passato. Questo è il layer più esterno che i relay vedono davvero: un messaggio da una pubkey sconosciuta indirizzato al destinatario, con un timestamp che non riflette quando il messaggio è stato effettivamente inviato. Il timestamp randomizzato protegge dall’analisi retrospettiva degli event archiviati, ma un avversario collegato attivamente ai relay può comunque osservare quando il gift wrap è apparso per la prima volta, quindi questa difesa è limitata agli osservatori passivi che interrogano i dati del relay in seguito. Poiché la pubkey è casuale e il timestamp è fittizio, i relay non possono determinare il mittente reale. Per leggere il messaggio, il destinatario decripta il gift wrap usando la propria chiave e la pubkey casuale, trova il seal all’interno, decripta il seal usando la propria chiave e la pubkey del mittente ricavata dal seal, e trova all’interno il messaggio kind 14.

NIP-17 non fornisce forward secrecy. Tutti i messaggi sono cifrati usando la keypair Nostr statica (tramite la derivazione delle chiavi di NIP-44 dalle chiavi del mittente e del destinatario). Se una chiave privata viene compromessa, ogni messaggio passato e futuro cifrato verso quella chiave può essere decrittato. È un tradeoff deliberato: poiché la cifratura dipende solo dall’nsec, un utente che fa il backup del proprio nsec può recuperare l’intera cronologia dei messaggi da qualsiasi relay che conservi ancora i gift wrap. Protocolli come MLS (usato da Marmot) forniscono forward secrecy attraverso la rotazione del materiale di chiave, ma al costo di richiedere sincronizzazione dello stato e rendere impossibile il recupero storico dei messaggi dopo la rotazione delle chiavi.

NIP-17 definisce anche il kind 15 per i messaggi file cifrati, che aggiunge i tag file-type, encryption-algorithm, decryption-key e decryption-nonce così il destinatario può decrittare un file allegato cifrato con AES-GCM prima dell’upload a un server Blossom. Il kind 10050 viene usato per pubblicare la relay list DM preferita dell’utente, così i mittenti sanno dove consegnare i gift wrap. L’insieme di tag pubkey + p in un messaggio definisce una chat room; aggiungere o rimuovere un partecipante crea una nuova stanza con cronologia pulita.

Le implementazioni coprono la maggior parte dei client principali. nospeak usa NIP-17 per tutta la messaggistica uno-a-uno. Flotilla usa NIP-17 per i suoi DM con proof-of-work. Amethyst, Primal, Nostur, Damus, noStrudel e Coracle implementano tutti NIP-17 come protocollo DM principale. La specifica supporta anche i messaggi a scomparsa impostando un tag expiration nel gift wrap.

NIP Deep Dive: NIP-46 (Nostr Remote Signing)

NIP-46 definisce un protocollo per separare la chiave privata dell’utente dall’applicazione client. Invece di incollare un nsec in una web app, l’utente esegue un remote signer (chiamato anche “bunker”) che custodisce la chiave privata e risponde alle richieste di firma via relay Nostr. Il client non vede mai la chiave privata. Questo riduce la superficie d’attacco: un client compromesso può richiedere firme ma non può estrarre la chiave stessa.

Il protocollo usa il kind 24133 sia per le richieste sia per le risposte, cifrate con NIP-44 (Encrypted Payloads). Un client genera una client-keypair usa-e-getta per la sessione e comunica con il remote signer attraverso messaggi cifrati NIP-44 taggati con le reciproche pubkey. Ecco una richiesta di firma da un client a un remote signer:

{
 "id": "aa11bb22cc33dd44ee55ff6677889900aabbccdd11223344556677889900aabb",
 "pubkey": "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86",
 "created_at": 1744108800,
 "kind": 24133,
 "tags": [
 ["p", "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52"]
 ],
 "content": "<nip44-encrypted JSON-RPC request>",
 "sig": "1122334455667788990011223344556677889900aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff0011223344556677"
}

Il content cifrato contiene una struttura in stile JSON-RPC:

{
 "id": "random-request-id-1",
 "method": "sign_event",
 "params": ["{\"kind\":1,\"content\":\"Hello from remote signing\",\"tags\":[],\"created_at\":1744108800}"]
}

Il remote signer decripta la richiesta, la presenta all’utente per l’approvazione (o la approva automaticamente in base ai permessi configurati), firma l’event con la chiave privata dell’utente e restituisce l’event firmato in una risposta:

{
 "id": "bb22cc33dd44ee55ff6677889900aabb11223344556677889900aabbccddeeff",
 "pubkey": "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52",
 "created_at": 1744108801,
 "kind": 24133,
 "tags": [
 ["p", "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86"]
 ],
 "content": "<nip44-encrypted JSON-RPC response>",
 "sig": "aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899"
}

Le connessioni possono essere avviate da entrambi i lati. Un remote signer fornisce un URL bunker:// contenente la sua pubkey e le informazioni relay. Un client fornisce un URL nostrconnect:// con la propria pubkey client, i relay e un secret per la verifica della connessione. Il parametro secret previene il connection spoofing: solo la parte che ha ricevuto l’URL fuori banda può completare l’handshake.

Sono definiti otto metodi: connect per stabilire la sessione, sign_event per firmare event, get_public_key per ottenere la pubkey dell’utente, ping per keepalive, nip04_encrypt/nip04_decrypt per la cifratura legacy, nip44_encrypt/nip44_decrypt per la cifratura corrente, e switch_relays per la gestione dei relay. La migrazione relay è gestita dal remote signer, che può spostare nel tempo la connessione verso nuovi relay senza rompere la sessione.

I client richiedono capacità specifiche al momento della connessione attraverso un sistema di permessi. Una stringa di permessi come nip44_encrypt,sign_event:1,sign_event:14 richiede accesso alla cifratura NIP-44 e accesso alla firma per i soli event kind 1 e kind 14. Il remote signer può accettare, rifiutare o modificare questi permessi. Questo significa che un client web per leggere e pubblicare note potrebbe ricevere solo il permesso sign_event:1, mentre un client DM potrebbe ricevere anche i permessi sign_event:14 e nip44_encrypt.

Amber implementa NIP-46 su Android, e la sua v6.0.0-pre1 di questa settimana aggiunge chiavi di firma per connessione per isolare i client tra loro. nsec.app (precedentemente Nostr Connect) fornisce un bunker web-based. nostr-tools include BunkerSigner per i client JavaScript, e la PR #530 della settimana scorsa ha aggiunto skipSwitchRelays per la gestione manuale dei relay. Il protocollo supporta anche auth challenge: quando un remote signer richiede autenticazione aggiuntiva (password, biometria o token hardware), risponde con un auth_url che il client apre in un browser perché l’utente completi il flusso.

Questo è tutto per questa settimana. Stai costruendo qualcosa o hai notizie da condividere? Scrivici in DM su Nostr o vieni a trovarci su nostrcompass.org.

Nostr Compass #16

Wed, 01 Apr 2026 00:00:00 +0000

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

Questa settimana: Amethyst distribuisce la v1.07.0 con note fissate, gestione relay tramite NIP-86, e supporto NIP-62 Request to Vanish. NIP-5A (Siti Web Statici) viene unito nel repository NIPs, definendo come ospitare siti web sotto keypair Nostr usando lo storage Blossom. Flotilla distribuisce la v1.7.0 con stanze vocali, login email/password e DM con proof-of-work. White Noise corregge il relay churn nella v2026.3.23, nospeak lancia la sua 1.0.0 come messenger cifrato senza registrazione. Nymchat adotta Marmot per chat di gruppo cifrate MLS con fallback NIP-17. Calendar by Form* raggiunge la v1.0.0 con liste calendario private e import ICS, Amber aggiunge recovery mnemonico e whitelisting relay auth NIP-42, e la spec Marmot sposta i KeyPackage su event indirizzabili mentre stringe il formato delle push notification MIP-05.

Notizie

Amethyst distribuisce note fissate, gestione relay e Request to Vanish

Amethyst, il client Android mantenuto da vitorpamplona, ha distribuito sei rilasci in tre giorni, dalla v1.07.0 alla v1.07.5. Il set di funzionalità principale copre sei superfici di protocollo: note fissate, una schermata feed dedicata ai sondaggi, supporto NIP-62 (Request to Vanish) per richiedere la cancellazione completa degli event dai relay, NIP-86 (Relay Management API) dall’interno del client, valutazioni NIP-66 (Relay Discovery and Liveness Monitoring) nella schermata informazioni relay, e visualizzazione delle informazioni membri NIP-43 (Relay Access Metadata and Requests).

NIP-86 definisce un’interfaccia JSON-RPC per gli operatori relay, permettendo ai client di inviare comandi amministrativi come ban di pubkey, allow di pubkey e lista utenti bannati tramite un’API standardizzata. Amethyst ora espone tutto questo direttamente nella sua UI di gestione relay, così gli utenti che eseguono i propri relay possono amministrarli dallo stesso client che usano per pubblicare. La PR #2039 sostituisce il vecchio dialog di input hex per le pubkey da bannare o consentire con un dialog di ricerca utenti interattivo.

La v1.07.2 ha aggiunto upload dalla tastiera GIF e ha corretto una regressione nella firma in cui le risposte di rifiuto di Amber venivano interpretate male perché le versioni più vecchie di Amber restituivano una stringa vuota per il campo rejected (PR #2042). La v1.07.5 corregge un crash nel caricamento delle immagini. I rilasci v1.06.2 e v1.06.3 all’inizio della settimana hanno aggiunto un selettore del tipo di sondaggio per scelte singole o multiple, drag-to-seek sulle barre di avanzamento video e miglioramenti alla pubblicazione anonima.

NIP-5A viene unito, portando i siti web statici su Nostr

NIP-5A (Siti Web Statici) è stato unito tramite PR #1538, definendo come ospitare siti web statici sotto keypair Nostr. La specifica usa due kind di event: kind 15128 per un sito root, uno per pubkey, e kind 35128 per siti con nome identificati da un tag d. Ogni manifesto mappa i percorsi URL agli hash SHA256, con tag server opzionali che puntano agli host di storage Blossom dove vivono i file effettivi.

Il modello di hosting funziona così: l’autore di un sito costruisce un sito statico, carica i file su uno o più server Blossom, poi pubblica un event manifesto firmato che mappa i percorsi agli hash del contenuto. Un server host riceve richieste web, risolve la pubkey dell’autore dal sottodominio, recupera il manifesto dalla relay list NIP-65 dell’autore, e serve i file scaricando i blob corrispondenti da Blossom. Il sito rimane sotto il controllo dell’autore perché solo quella chiave può firmare un manifesto aggiornato. Il server host è sostituibile perché qualsiasi server che comprende NIP-5A può servire lo stesso sito dallo stesso manifesto.

La specifica si basa su infrastrutture già esistenti. nsite, l’implementazione host di riferimento NIP-5A costruita da lez, e nsite-manager, la UI di gestione di hzrd149, erano già in esecuzione prima del merge del NIP. Il merge rende ufficiali i kind di event e le regole di risoluzione URL, dando alle seconde e terze implementazioni un obiettivo stabile.

White Noise corregge il relay churn e amplia i controlli client

White Noise, il messenger privato costruito sul protocollo Marmot, ha distribuito la v2026.3.23 il 25 marzo. Il lavoro principale riguarda la stabilità dei relay. Il login non aspetta più che ogni pubblicazione della relay-list termini prima di proseguire, perché la pubblicazione delle relay-list ora usa logica di quorum e ritenta il resto in background. Fetch e publish one-off usano sessioni relay effimere e delimitate invece di restare nel pool long-lived, le sessioni ripristinate recuperano il loro percorso di refresh di gruppo dopo l’avvio, e l’app ora espone diagnostica relay e ispezione dello stato relay tramite PR #495 e PR #502.

Lo stesso rilascio cambia anche il comportamento delle conversazioni. La PR #468 aggiunge threading delle risposte NIP-C7 con tag q e riferimenti nostr:nevent, la PR #471 e la PR #512 mantengono i messaggi cancellati visibili come placeholder cancellati invece di rimuoverli silenziosamente, la PR #478 aggiunge un flusso di bug report in-app usando report anonimi NIP-44 (Encrypted Payloads), e la PR #486 aggiunge una chat di supporto direttamente nel client. Nella stessa finestra sono arrivati anche controlli sui messaggi rivolti all’utente: la PR #532 archivia le chat, la PR #541 aggiunge mute e unmute con durate configurabili, e la PR #535 aggiunge impostazioni delle notifiche. La PR #539 prepara il lavoro di registrazione push, collegando la registrazione APNs su iOS e il rilevamento Play Services su Android in modo che la registrazione possa essere costruita sopra questo. Sul lato backend, il MDK (Marmot Development Kit) ha aggiunto primitive push notification MIP-05 e un notification request builder (PR #235, PR #238), mentre whitenoise-rs ha aggiunto la persistenza della registrazione push notification (PR #688), correzioni alla cancellazione dei task in background (PR #696), e recovery dei key package all’avvio (PR #693).

Nostr VPN raggiunge la v0.3.0 con roster sync e invite v2

Come da copertura del lancio della settimana scorsa, nostr-vpn, la VPN peer-to-peer che usa relay Nostr per la segnalazione e WireGuard per tunnel cifrati, ha continuato il suo ritmo di rilascio rapido, distribuendo versioni fino alla v0.3.3. Il salto di versione porta due cambi incompatibili: il formato invite passa alla v2 (la 0.3.0 può ancora importare invite v1, ma le build più vecchie non possono importare invite v2), e il roster sync firmato dall’admin è stato aggiunto al protocollo di segnalazione. I peer con versioni miste possono ancora connettersi a livello mesh, ma i peer più vecchi non partecipano alla sincronizzazione del roster.

L’aggiunta del roster sync avvia il passaggio verso una rete gestita. Un nodo admin può ora inviare cambiamenti di appartenenza a tutti i peer, così aggiungere o rimuovere un dispositivo dalla mesh non richiede che ogni peer aggiorni manualmente la propria configurazione. I rilasci v0.2.x nella stessa settimana hanno affrontato problemi specifici di deployment: dalla v0.2.22 alla v0.2.28 hanno corretto la gestione del servizio Windows, aggiunto script di build Android, e perfezionato il flusso di pairing LAN.

nospeak si lancia come messenger privato 1.0

nospeak, un messenger privato costruito su Nostr, ha distribuito il rilascio 1.0.0 il 27 marzo. Il progetto include conversazioni uno-a-uno e di gruppo, gestione contatti, e un’architettura self-hostable. Le chat uno-a-uno usano NIP-17 (Private Direct Messages), che combina NIP-59 (Gift Wrap) con NIP-44 (Encrypted Payloads) per nascondere il mittente ai relay. Per i media, i file sono cifrati lato client con AES-256-GCM prima dell’upload sui server Blossom. Il rilascio viene distribuito anche come immagine container per il self-hosting.

Flotilla, il client in stile Discord di hodlbod basato su NIP-29 (Relay-based Groups) e sul modello “relay come gruppi”, ha distribuito la v1.7.0 e la v1.7.1 il 30 e 31 marzo. La funzionalità principale sono le stanze vocali, contribuite da mplorentz. Gli utenti possono ora unirsi a chiamate vocali all’interno dei canali di gruppo, con un dialog di ingresso (PR #109) che permette di selezionare il dispositivo di input audio e scegliere se entrare nella chiamata vocale o solo visualizzare la chat testuale. Il dialog risolve un problema UX della precedente iterazione: entrare in una stanza con voce attiva accendeva prima il microfono anche quando l’utente voleva solo leggere i messaggi o controllare le impostazioni della stanza.

Lo stesso rilascio aggiunge il login email e password come alternativa all’autenticazione basata su chiave Nostr, proof-of-work sui DM, editing dei DM, onboarding e impostazioni relay ridisegnati, rilevamento del supporto Blossom tramite supported_nips, badge notifiche migliorati, fallback push notification su Android, e correzioni agli upload file su Android. La v1.7.1 segue con una correzione per il fallback di registrazione pomade quando si usa un signer offline.

Hodlbod sta anche costruendo Caravel, un hosting manager e dashboard per relay zooid, che ha registrato 40 commit questa settimana nella fase iniziale di sviluppo.

Nymchat distribuisce chat di gruppo basate su Marmot

Nymchat (noto anche come NYM, Nostr Ynstant Messenger), il client di chat effimero collegato a Bitchat, ha annunciato che tutte le nuove chat di gruppo ora usano il protocollo Marmot per messaggistica cifrata MLS. L’integrazione usa kind 443, 444, e 445 per key package, welcome message e group message rispettivamente, fornendo forward secrecy, post-compromise security e zero metadata leakage. Se un destinatario non può usare MLS, Nymchat ricade sul suo precedente percorso di chat di gruppo NIP-17 (Private Direct Messages), che è comunque cifrato end-to-end ma privo delle proprietà a ratchet-tree di MLS.

Le serie v3.55 e v3.56 di questa settimana si sono concentrate sui casi limite delle chat di gruppo: caricamento su nuovi dispositivi, comportamento di uscita, instradamento delle notifiche, e conteggi dei badge non letti. Lo stesso ciclo ha anche corretto una vulnerabilità XSS dovuta a HTML non escapato e ha aggiunto il blocco di parole chiave e frasi esteso ai nickname utente. Questo rende Nymchat un altro client Marmot che si unisce a White Noise e OpenChat, ampliando l’insieme di app che possono scambiare messaggi di gruppo cifrati MLS sullo stesso protocollo.

Rilasci

Calendar by Form* v1.0.0

Calendar by Form*, l’app calendario decentralizzata costruita su NIP-52 (Calendar Events), ha raggiunto la v1.0.0 il 29 marzo. Il rilascio aggiunge liste calendario private usando event Nostr cifrati (kind 32123) con auto-cifratura NIP-44 (Encrypted Payloads), così gli utenti possono organizzare gli eventi in collezioni private senza esporre il raggruppamento ai relay. Lo stesso rilascio aggiunge la gestione degli intent ICS per importare dati calendario da altre applicazioni e richieste di invito per condividere eventi tra utenti.

Amber v5.0.2 fino a v5.0.4

Amber, l’app signer NIP-55 (Android Signer Application), ha distribuito tre point release: v5.0.2, v5.0.3, e v5.0.4. L’aggiunta più visibile è il login tramite frase mnemonica di recovery (PR #358), che permette agli utenti di ripristinare il proprio signer da una seed phrase BIP39 invece di richiedere la stringa nsec o ncryptsec grezza. La PR #357 aggiunge una whitelist relay auth NIP-42, così gli utenti possono limitare quali relay sono autorizzati a richiedere l’autenticazione client. La PR #353 aggiunge la selezione dell’ambito di cifratura per i permessi di decrypt, permettendo agli utenti di concedere accesso di decrypt solo NIP-04 o solo NIP-44 invece di un permesso generale. La v5.0.4 corregge un bug in cui il rifiuto non rispettava i permessi scoped di encrypt e decrypt e migliora le prestazioni quando arrivano più richieste bunker.

Aegis v0.4.0

Aegis, il signer cross-platform, ha distribuito la v0.4.0 il 26 marzo. Il rilascio aggiunge le modalità di autorizzazione Full e Selective nelle Impostazioni e corregge diversi problemi di scansione QR. I commit successivi d4f799f, 3313af9, 3b214e4, e e4f40b6 continuano lo stesso lavoro con controlli batch select, statistiche riutilizzabili sulle selezioni batch, API set-all-groups selection, e statistiche di utilizzo per permesso nella pagina dei permessi dell’app.

Schemata v0.2.7 fino a v0.3.0

Schemata, le definizioni JSON Schema per la validazione dei kind di event Nostr, ha distribuito quattro rilasci dalla v0.2.7 alla v0.3.0 con 21 PR unite. Il rilascio v0.3.0 porta correzioni di coerenza dei pattern per URL relay, ID hex, tipi MIME, e stringhe BOLT-11 (PR #126), centralizzazione dei pattern URL relay (PR #117), schemi del tipo base bech32 NIP-19 (PR #118), e validazione per gli event spell kind 777 (PR #125). La pipeline di rilascio ora pubblica una nota kind 1 su Nostr per ogni rilascio (PR #120), così il progetto si annuncia attraverso il protocollo che valida. Schemata ora supporta una dozzina di linguaggi oltre al pacchetto canonico JS/TS: Rust, Go, Python, Kotlin, Java, Swift, Dart, PHP, C#/.NET, C++, Ruby, e C.

Accanto a Schemata, il team ha pubblicato schemata-codegen, un generatore di codice sperimentale che affronta lo stesso problema di validazione con un approccio diverso. Dove i pacchetti validator di Schemata richiedono una dipendenza runtime da JSON Schema, schemata-codegen converte gli schemi direttamente in costrutti tipizzati nativi del linguaggio (tuple tipizzate per tag, interfacce kind, e validator runtime), rimuovendo la necessità di una libreria validator a runtime. Il documento codegen-vs-validators comparison spiega quando ciascun approccio è adatto.

BigBrotr v6.5.0 fino a v6.5.4

BigBrotr, la piattaforma di analisi relay, ha distribuito cinque rilasci dalla v6.5.0 alla v6.5.4. La v6.5.0 centralizza la validazione degli URL relay con una factory function parse_relay_url() e aggiunge controlli sulla lunghezza URL e sanitizzazione dei path. Anche l’infrastruttura di monitoraggio ha ricevuto correzioni: gli event di annuncio ora includono tag di geolocalizzazione geohash (seguendo NIP-52), ed è stata aggiunta protezione timeout ai test di metadati Geo/Net NIP-66 che non avevano scadenza e potevano bloccarsi indefinitamente. La PR #410 aggiorna PostgreSQL dalla 16 alla 18, portando il sottosistema async I/O e un throughput WAL migliorato alla pipeline di analisi relay.

Il relay Vertex Lab aggiunge la ricerca profili NIP-50

Vertex Lab, il team dietro npub.world e il motore Web of Trust Vertex, ha annunciato che wss://relay.vertexlab.io ora supporta NIP-50 (Search) per le query sui profili. NIP-50 estende il filtro standard REQ di Nostr con un campo search, permettendo ai client di inviare query full-text ai relay che supportano l’indicizzazione. Aggiungere la ricerca profili a un relay che serve già dati Web of Trust significa che i client connessi a relay.vertexlab.io possono scoprire utenti per nome o descrizione senza un servizio di ricerca separato.

Hashtree v0.2.17 e v0.2.18 distribuiscono mesh WebRTC e Iris Desktop

Hashtree, il sistema di storage blob content-addressed di mmalmi che pubblica radici Merkle su Nostr, ha distribuito la v0.2.17 e la v0.2.18 il 31 marzo. I due rilasci chiudono uno sprint di 30 commit che aggiunge tre capacità distinte. Primo, il crate hashtree-webrtc (rinominato hashtree-network nella v0.2.18) aggiunge distribuzione blob peer-to-peer basata su WebRTC con segnalazione mesh unificata attraverso la CLI Rust, l’harness di simulazione, e il client TypeScript. Secondo, la pipeline di rilascio ora costruisce artefatti Windows (zip CLI e installer Iris), portando copertura cross-platform su macOS, Linux e Windows. Terzo, entrambi i rilasci includono Iris Desktop 0.1.0, il client social Nostr di mmalmi, come asset AppImage, .deb e installer Windows accanto alla CLI hashtree. Hashtree è stato trattato per la prima volta nella Newsletter #10 quando è stato lanciato come store compatibile Blossom basato su filesystem. Il livello WebRTC è il primo passo verso una distribuzione dei contenuti peer-to-peer senza dipendere da server Blossom centralizzati.

Nostr Mail Client v0.7.0 fino a v0.7.2

Nostr Mail Client, il client in stile email Flutter costruito su identità Nostr, ha distribuito la v0.7.0, la v0.7.1, e la v0.7.2 in tre giorni. Il lavoro di prodotto più visibile si è concentrato su onboarding (PR #9) e modifica profilo (PR #10), elementi di base per qualsiasi client che cerca di presentare Nostr come una casella di posta. Le point release successive hanno impacchettato quel lavoro in nuove build Android e Linux.

Wisp v0.14.0 fino a v0.16.1

Wisp, il client Nostr Android, ha distribuito altri 13 rilasci dalla v0.14.0-beta alla v0.16.3-beta. Il lavoro di questa settimana include correzioni al JSON rumor NIP-17 (PR #385), badge repost sulle gallery card (PR #383), dettagli delle reazioni espandibili (PR #382), set emoji persistenti (PR #381), e controlli di autoplay video (PR #380). L’ultima v0.16.3-beta corregge anche shortcode emoji personalizzate con trattini e tag emoji mancanti.

Primal Android 3.0.17

Primal Android ha distribuito la 3.0.17 il 24 marzo. La PR #1000 mappa i tipi WalletException in codici errore nelle risposte NWC, dando ai client NIP-47 informazioni di errore strutturate invece di errori generici. La PR #995 corregge i voti zap dei sondaggi che apparivano come Top Zaps, e la PR #998 nasconde il saldo wallet e i pulsanti di azione quando non è configurato alcun wallet.

OpenChat v0.2.4 fino a v0.3.0

OpenChat, il client chat basato su Avalonia costruito sullo stack Marmot, ha distribuito sei rilasci dalla v0.2.4 alla v0.3.0 in quattro giorni. Il log dei commit racconta la storia di un client che colma il divario tra “Marmot funziona” e “qualcuno può davvero usarlo ogni giorno”. È arrivata l’autenticazione relay NIP-42, seguita da una UI relay picker con filtraggio degli event duplicati. I messaggi vocali hanno ottenuto pausa, ripresa, seek e visualizzazione del tempo. Il percorso signer è stato rafforzato: le connessioni Amber sono state corrette con un formato URI NIP-46 aggiornato, il WebSocket si riconnette automaticamente prima di inviare le richieste, e le richieste Amber duplicate ora vengono intercettate controllando le risposte riprodotte. Sul lato storage, Linux e macOS hanno ottenuto secure storage AES-256-GCM con chiavi salvate su file, e il recupero dei metadata utente ora usa la discovery relay NIP-65 e mette in cache i risultati in un database locale.

Igloo Signer 1.1

Igloo, il signer threshold FROST per iOS del progetto FROSTR, ha distribuito la v1.1 il 28 marzo. Le firme FROST (Flexible Round-Optimized Schnorr Threshold) permettono a un gruppo di signer di controllare collettivamente un keypair Nostr, dove qualsiasi insieme t-of-n di partecipanti può firmare un event senza che nessuna singola parte possieda la chiave privata completa. Igloo è una delle prime implementazioni mobili di questo approccio per Nostr.

nak v0.19.3 e v0.19.4

nak, il toolkit Nostr a riga di comando di fiatjaf, ha distribuito la v0.19.3 e la v0.19.4 il 26 e 30 marzo. Entrambi i rilasci correggono condizioni di panic: la PR #118 sostituisce strings.Split con strings.Cut per prevenire un potenziale accesso out-of-bounds, e la PR #119 previene la stessa classe di panic nel parsing dei flag curl.

Flora v0.3.0

Flora, un’estensione Chrome per screen recording e condivisione decentralizzati su Nostr, ha distribuito la v0.3.0. Il rilascio aggiunge condivisione video privata cifrata con modalità pubblica, non in elenco e privata. Le registrazioni private sono cifrate con AES-256-GCM e consegnate ai destinatari tramite NIP-17 (Private Direct Messages), così la registrazione non tocca mai un server in chiaro.

YakiHonne Mobile 2.0.3

YakiHonne, il client mobile Nostr, ha distribuito la 2.0.3 con recensioni relay e join request, risposte nidificate ampliate, traduzione automatica delle note, e supporto multi-relay NWC.

Aggiornamenti Progetti

Zap Cooking aggiunge zap poll e verifica dei pagamenti Branta

Zap Cooking, la piattaforma di ricette e contenuti, ha unito 11 PR questa settimana focalizzate su contenuti interattivi e flussi di pagamento. La PR #277 aggiunge gli zap poll (kind 6969), in cui gli utenti votano inviando sats e possono vedere le liste dei votanti con foto profilo. La PR #274 ridisegna la UX dei sondaggi in modo che l’interfaccia di voto si integri più naturalmente nel feed.

La PR #276 aggiunge scansione QR tramite fotocamera al flusso Send Payment e integra Branta, un servizio di verifica che controlla se una destinazione di pagamento è legittima prima dell’invio. Branta verifica le destinazioni di pagamento contro phishing, address swap e intercettazioni man-in-the-middle prima dell’invio. Nell’implementazione di Zap Cooking, un nome piattaforma e logo verificati da Branta appaiono direttamente nel flusso di pagamento, e i QR code abilitati a Branta possono trasportare parametri branta_id e branta_secret così il wallet può verificare la destinazione direttamente dal codice scansionato.

diVine prepara le basi per una ricerca unificata e rafforza la consegna video

diVine, il client di video brevi, ha passato la settimana a stringere ricerca, navigazione del feed, recovery della riproduzione, e comportamento di upload. La PR #2540 getta le basi per una schermata di ricerca unificata, con sezioni raggruppate per Video, Persone, e Tag. La PR #2623 rafforza la paginazione su feed profilo, inbox, notifiche, liste discover, classic vines, ricerca, e feed a griglia componibili spostandoli su un controller di paginazione condiviso.

Anche la consegna video ha ricevuto diverse correzioni concrete. La PR #2643 ritenta in ordine le sorgenti derivate ospitate da Divine e ricade sul blob grezzo prima di mostrare un errore di riproduzione, così fallimenti transitori su una sorgente non uccidono subito la riproduzione. La PR #2634 mantiene gli upload resumable sul percorso gestito da Divine quando il capability probing fallisce temporaneamente, riducendo gli upload rotti causati da brevi guasti di rete. La PR #2637 cambia anche il filtro dei contenuti sensibili in modo che i video siano bloccati rigidamente solo per etichette di avviso reali, non semplicemente per content warning impostati dal creatore.

Shopstr aggiunge storefront personalizzati e Milk Market continua a distribuire lavoro di marketplace

Shopstr, il marketplace basato su Nostr, ha unito la PR #245 aggiungendo storefront personalizzati. Questo dà ai venditori una superficie home più distintiva invece di costringere ogni annuncio nella stessa presentazione generica.

Milk Market, un marketplace dedicato al latte, ha continuato con ottimizzazioni degli storefront (PR #18), account recovery (PR #17), beef splits (PR #15), e correzioni ai tipi degli strumenti MCP (PR #16).

Notedeck aggiunge effetti sonori e estende il suo percorso updater verso Android

Notedeck, il client desktop del team Damus, ha unito la PR #1412 aggiungendo un sottosistema di effetti sonori con suoni di interazione UI usando rodio, e la PR #1399 con aggiornamenti Agentium inclusi un flag CLI per il titolo e cartelle di sessione comprimibili. Una PR #1417 aperta propone l’auto-aggiornamento APK via Nostr/Zapstore su Android, costruendo sul lavoro updater nativo Nostr di Notedeck dalla Newsletter #14.

Nostria aggiunge relay hint per i repost e allineamento NIP-98

Nostria ha unito la PR #583 aggiungendo relay hint NIP-18 (Reposts) ai tag e dei repost per gli event kind 6 e kind 16, la PR #582 allineando l’HTTP auth Brainstorm (kind 27235) ai tag richiesti da NIP-98 (HTTP Auth), e la PR #576 aggiungendo test di validazione degli schemi Schemata. Il cambiamento NIP-98 significa che Nostria può autenticarsi verso servizi esterni usando lo stesso formato HTTP auth che usano gli altri client.

Nostr-Doc aggiunge packaging desktop e lavoro offline-first

Nostr-Doc, l’editor collaborativo di Form*, ha avuto una settimana intensa di packaging e lavoro sull’editor. Il commit fcdc00a aggiunge un’app desktop, il commit 3977a8e avvia il lavoro sull’app nativa, e il commit 413a030 spinge l’app verso un comportamento offline-first. Sul lato editor, il commit 1855ce8 aggiunge salvataggio Ctrl+S, avvisi di salvataggio, correzioni alle anteprime link, e rendering corretto del barrato.

rust-nostr ottimizza il parsing NIP-21 e aggiunge supporto NIP-62 lato relay

rust-nostr ha unito otto PR. La più notevole è la PR #1308, che ottimizza il parsing degli URI NIP-21 in PublicKey::parse allineandolo alle prestazioni standard del parsing bech32. In precedenza, gli URI NIP-21 richiedevano circa il doppio del tempo per essere analizzati rispetto alle chiavi bech32 grezze. Il progetto ha anche quattro PR aperte che aggiungono supporto specifico relay a NIP-62 (Request to Vanish) nei backend memory, LMDB, SQLite, e database test (PR #1315, PR #1316, PR #1317, PR #1318).

nostr-tools aggiunge controllo relay bunker e corregge il parsing multi-relay NIP-47

nostr-tools ha unito la PR #530 aggiungendo skipSwitchRelays ai BunkerSignerParams per la gestione manuale dei relay, e la PR #529 correggendo il parsing delle stringhe di connessione NIP-47 (Nostr Wallet Connect) per supportare più relay come consente la specifica.

Nostrability integra i dati di audit Sherlock e pubblica una panoramica di Schemata

Nostrability, l’interoperability tracker per i client Nostr, ha unito 14 PR. La PR #306 integra le statistiche delle scansioni Sherlock nella dashboard. Sherlock è lo strumento di audit automatizzato di Nostrability che si connette ai client Nostr, cattura gli event che pubblicano, e valida ogni event rispetto alle definizioni JSON Schema di Schemata per rilevare violazioni della specifica. La dashboard ora mostra i tassi di fallimento degli schemi per client (PR #315) così gli sviluppatori possono vedere quali kind di event il proprio client sbaglia. La PR #323 rivede il workflow di pubblicazione Nostr in modo che gli annunci di rilascio girino come job separato che non può essere cancellato da step CI precedenti.

elsat ha anche pubblicato Schemata for nostr devs il 30 marzo, descrivendo come schemata, schemata-codegen e Sherlock si incastrano e dando i numeri attuali di copertura: 179 schemi di kind event su 65 NIP, 154 schemi di tag, 13 messaggi di protocollo, e 310 event di esempio.

Nalgorithm aggiunge generazione digest e caching locale del punteggio

Nalgorithm, un nuovo progetto feed Nostr ordinato per rilevanza, ha avviato lo sviluppo pubblico questa settimana. Il commit cf6c501 imposta l’app web iniziale che recupera i post dai follow e li valuta rispetto a un prompt di preferenze definito dall’utente. Il commit 8e931b6 aggiunge uno strumento CLI digest che trasforma i post più rilevanti in un riepilogo parlato, mentre il commit 4cb9c63 aggiunge caching del punteggio basato su file e evoluzione incrementale del prompt appreso a partire dai like recenti. Il commit c2edfb8 smette anche di mettere in cache i fallback score da batch falliti, così un fallimento transitorio del punteggio non appiattisce permanentemente il ranking di un post.

TENEX aggiunge vector store RAG e startup MCP mirato

TENEX, il framework agenti nativo Nostr che collega agenti AI ai canali Nostr via Telegram, ha unito sette PR questa settimana. La PR #101 aggiunge un’astrazione vector store pluggable con backend SQLite-vec, LanceDB, e Qdrant, dando agli agenti retrieval-augmented generation senza vincolarsi a un singolo database vettoriale. La PR #102 rende lo startup MCP mirato: vengono avviati solo i server MCP i cui strumenti un agente usa davvero, invece di lanciare tutti i server subito alla prima esecuzione. La PR #100 aggiunge uno strumento send_message così gli agenti con binding ai canali Telegram possono inviare messaggi proattivamente invece di limitarsi a rispondere a quelli in arrivo. La PR #106 evita uno spawn di sottoprocesso che attivava una pre-allocazione da 9GB di memoria Bun/JSC leggendo .git/HEAD direttamente invece di eseguire git branch.

Dart NDK sposta il signer Amber e aggiunge Alby Go 1-click

Dart NDK, il Flutter Nostr development kit, ha distribuito 11 PR unite. La PR #525 sposta il supporto al signer Amber nel pacchetto ndk_flutter, e la PR #552 aggiunge la connessione wallet one-click Alby Go all’app di esempio. La PR #502 aggiunge uno script install.sh per la CLI, e la PR #523 rimuove la dipendenza dal verifier Rust a favore della gestione nativa degli asset.

Lavoro su Protocollo e Specifica

Marmot sposta i KeyPackage su event indirizzabili e stringe le push notification

La specifica Marmot ha unito quattro PR che cambiano il modo in cui il protocollo gestisce il materiale chiave e l’appartenenza ai gruppi. La PR #54 migra gli event KeyPackage dal normale kind:443 al kind:30443 indirizzabile con tag d, eliminando la necessità di cancellazione event NIP-09 durante la rotazione delle chiavi. Gli event indirizzabili si sovrascrivono sul posto, rendendo la rotazione auto-contenuta. La PR #57 permette agli utenti non admin di fare commit di proposte SelfRemove (uscita volontaria dal gruppo), e la PR #62 richiede agli admin di rinunciare allo status di admin prima di usare SelfRemove, impedendo a un admin di sparire mantenendo ancora privilegi elevati.

La PR #61 stringe il formato delle push notification MIP-05, rendendo espliciti la codifica base64 single-blob, il versioning, il formato wire del token, e l’uso delle chiavi x-only. L’effetto è una singola rappresentazione wire definita per token blob e chiavi x-only attraverso la specifica, le librerie client, e i backend delle app. L’implementazione di questi cambi di specifica è arrivata nello stack White Noise questa settimana ed è coperta nella sezione White Noise v2026.3.23 sopra.

Aggiornamenti NIP

Modifiche recenti al repository NIPs:

Uniti:

NIP-5A: Siti Web Statici (PR #1538): Definisce gli event manifesto kind 15128 (sito root) e kind 35128 (sito con nome) per ospitare siti statici sotto keypair Nostr usando lo storage Blossom. Vedi il deep dive sotto.
NIP-30 (Custom Emoji): Permettere i trattini negli shortcode (PR #2297): Aggiorna la descrizione degli shortcode per includere i trattini. Gli shortcode con trattini sono stati usati nella pratica fin dall’introduzione del NIP, quindi la specifica ora documenta l’uso corrente.

PR Aperte e Discussioni:

NIP-C1: Agent TUI Messages (PR #2295): Propone un formato di messaggio strutturato per gli agenti che inviano elementi UI interattivi tramite DM cifrati, inclusi payload tipizzati text, buttons, card, e table. La bozza mantiene tutto dentro il contenuto JSON degli existing DM NIP-17 e NIP-04. Non definisce un nuovo kind di event e usa un semplice formato stringa callback per le risposte ai pulsanti.
NIP-95: Hybrid Peer-to-Peer Relay Protocol (PR #2293): Propone un modello relay ibrido in cui i relay restano autorevoli ma possono anche coordinare la distribuzione peer-to-peer degli event recenti via WebRTC. La bozza introduce messaggi relay come PEER_REGISTER, PEER_REQUEST, e PEER_OFFER, con client stabili che agiscono da Super Peer e il relay che funge da seed node e fallback.
NIP-B9: Zap Poll Events (PR #2284): Riapre la vecchia idea NIP-69 degli zap-poll ora che NIP-88 (Polls) copre i sondaggi gratuiti. La bozza usa definizioni di sondaggi kind 6969 e zaps kind 9734 come voti, rendendolo un sistema di polling a pagamento con resistenza economica ai Sybil. Completa i sondaggi gratuiti one-key-one-vote.
NIP-AD: Super Zap (PR #2289): Propone una convenzione in cui gli zap inviati alla pubkey di un relay o a quella di un client vengono mostrati come note promozionali specializzate, trasformando di fatto le zap receipt in una superficie pubblicitaria. Gli operatori relay e i client pubblicherebbero profili con lud16, recupererebbero quelle receipt, estrarrebbero il contenuto incorporato dalle descrizioni zap, e potrebbero opzionalmente impostare soglie minime in sats per sopprimere lo spam.
NIP-XX: Agent Reputation Attestations (PR #2285): Propone kind 30085 come event sostituibile parametrizzato per attestazioni strutturate di reputazione sugli agenti Nostr. La bozza evita un singolo punteggio globale rendendo la reputazione dipendente dall’osservatore, aggiunge decadimento temporale così le attestazioni vecchie perdono peso, supporta rating negativi con requisiti di evidenza, e abbozza sia punteggio ponderato semplice sia punteggio di diversità del grafo per migliore resistenza Sybil.
NIP-XX: Paid API Service Announcements (PR #2291): Propone event indirizzabili kind 31402 per pubblicizzare API HTTP a pagamento, con Nostr che gestisce discovery e pagamento tramite HTTP 402. La bozza è tags-first così i relay possono filtrare su metodi di pagamento, prezzi e capacità senza fare parsing di contenuto JSON, e permette schemi opzionali di richiesta e risposta così client o agenti possono auto-generare le chiamate.
NIP-XX: Key Derivation from LNURL-auth via SplitSig (PR #2294): Propone di derivare un keypair Nostr da una firma ECDSA LNURL-auth combinata con un nonce casuale lato client. La formula di derivazione è nsec = SHA256(ecdsa_signature || nonce). Il server vede la firma ECDSA (intrinseca all’handshake LNURL-auth) ma non vede mai il nonce, e il browser genera il nonce ma non controlla la firma. Nessun pezzo da solo può derivare l’nsec. L’obiettivo è che lo stesso wallet Lightning produca la stessa chiave Nostr su dispositivi diversi, con il wallet come àncora di recovery e nessun server in grado di ricostruire la chiave privata.
NIP-55: Documentare il campo rejected (PR #2290): Documenta il campo rejected per le risposte dei signer intent-based, formalizzando il comportamento che la correzione di Amethyst v1.07.x ha dovuto aggirare.

NIP Deep Dive: NIP-5A (Siti Web Statici)

NIP-5A definisce come ospitare siti web statici sotto keypair Nostr, usando due kind di event e l’infrastruttura blob esistente per trasformare event firmati in pagine web servite. La specifica è stata unita il 25 marzo tramite PR #1538.

Il modello usa kind 15128 per un sito root, uno per pubkey, e kind 35128 per siti con nome identificati da un tag d. Ogni manifesto mappa percorsi URL assoluti agli hash SHA256. Ecco un manifesto di sito root:

{
 "id": "5324d695ed7abf7cdd2a48deb881c93b7f4e43de702989bbfb55a1b97b35a3de",
 "pubkey": "266815e0c9210dfa324c6cba3573b14bee49da4209a9456f9484e5106cd408a5",
 "created_at": 1743465600,
 "kind": 15128,
 "tags": [
 ["path", "/index.html", "186ea5fd14e88fd1ac49351759e7ab906fa94892002b60bf7f5a428f28ca1c99"],
 ["path", "/about.html", "a1b2c3d4e5f6789012345678901234567890abcdef1234567890abcdef123456"],
 ["path", "/favicon.ico", "fedcba0987654321fedcba0987654321fedcba0987654321fedcba0987654321"],
 ["server", "https://blossom.primal.net"],
 ["title", "My Nostr Site"],
 ["description", "A static website hosted on Nostr"],
 ["source", "https://github.com/lez/nsite"]
 ],
 "content": "",
 "sig": "f4e4a9e785f70e9fcaa855d769438fea10781e84cd889e3fcb823774f83d094cf2c05d5a3ac4aebc1227a4ebc3d56867286c15a6df92d55045658bb428fd5fb5"
}

Il flusso di serving funziona in tre passaggi. Un server host riceve una richiesta HTTP, estrae la pubkey dell’autore dal sottodominio (un npub per i siti root o una pubkey codificata base36 per i siti con nome), recupera la relay list dell’autore tramite NIP-65, e interroga il manifesto del sito. Una volta trovato il manifesto, il server risolve il path richiesto in un hash di contenuto, scarica il blob corrispondente dal server o dai server Blossom elencati nei tag server, e lo restituisce.

Il formato del sottodominio DNS è strettamente specificato. I siti root usano l’npub standard come sottodominio. I siti con nome usano una codifica base36 di 50 caratteri della pubkey grezza seguita dal valore del tag d, tutto in una singola etichetta DNS. Poiché le etichette DNS sono limitate a 63 caratteri e la codifica base36 ne occupa sempre 50, il tag d è limitato a 13 caratteri. La specifica richiede anche che i tag d corrispondano a ^[a-z0-9-]{1,13}$ e non terminino con un trattino, evitando ambiguità nella risoluzione DNS.

L’uso di hash del contenuto significa che lo stesso sito può essere servito da server host diversi, e l’integrità dei file è verificabile senza fidarsi del server. Un server host non ha bisogno di memorizzare alcun file localmente. Li recupera on demand da Blossom usando gli hash nel manifesto. Questo significa che l’autore controlla ciò che viene servito, il server Blossom memorizza i file grezzi, e il server host si limita a collegare i due. Ciascuno di questi tre componenti può essere sostituito indipendentemente.

Le implementazioni esistenti includono nsite, il server host che risolve i manifesti e serve i file, e nsite-manager, una UI per costruire e pubblicare i manifesti. La specifica ha aggiunto anche un tag source per collegare il repository del codice sorgente del sito, e l’aggiornamento del README unito separatamente nella PR #2286 ha registrato sia il kind 15128 sia il 35128 nell’indice dei kind NIP.

NIP Deep Dive: NIP-62 (Request to Vanish)

NIP-62 definisce kind 62 come una richiesta ai relay di cancellare tutti gli event della pubkey richiedente. La specifica ha una motivazione legale: nelle giurisdizioni con leggi sul diritto all’oblio, avere una richiesta di cancellazione standardizzata e firmata dà agli operatori relay un segnale chiaro su cui agire.

{
 "id": "a7b8c9d0e1f23456789012345678901234567890abcdef1234567890abcdef12",
 "pubkey": "f1e2d3c4b5a697887766554433221100ffeeddccbbaa99887766554433221100",
 "created_at": 1743465600,
 "kind": 62,
 "tags": [
 ["relay", "wss://relay.example.com"]
 ],
 "content": "Requesting deletion of all events from this relay.",
 "sig": "11aa22bb33cc44dd55ee66ff77889900aabbccddeeff0011223344556677889911aa22bb33cc44dd55ee66ff77889900aabbccddeeff00112233445566778899"
}

La specifica separa le richieste vanish mirate da quelle globali. Una richiesta mirata include tag relay specifici che identificano i relay che devono agire. Una richiesta globale usa la stringa letterale ALL_RELAYS come valore del tag relay, chiedendo a ogni relay che vede l’event di cancellare tutti gli event di quella pubkey. I relay che rispettano la richiesta devono anche assicurarsi che gli event cancellati non possano essere ripubblicati di nuovo nel relay, rendendo la cancellazione persistente.

NIP-62 va oltre NIP-09 (Event Deletion) sia per ambito che per intento. NIP-09 permette di cancellare singoli event, e i relay MAY rispettarlo. NIP-62 chiede la cancellazione di tutto, e la specifica dice che i relay MUST rispettare la richiesta se il loro URL è taggato. Chiede anche ai relay di cancellare gli event NIP-59 (Gift Wrap) che contengono un p-tag verso la pubkey richiedente, il che significa che i DM in arrivo vengono ripuliti insieme agli event dell’utente. Pubblicare una cancellazione NIP-09 contro una richiesta vanish NIP-62 non ha effetto: una volta che fai vanish, non puoi annullare il vanish cancellando la richiesta di vanish.

Questa settimana, Amethyst v1.07.0 ha distribuito il supporto client-side a NIP-62, permettendo agli utenti di avviare richieste vanish dall’app. Sul lato relay, rust-nostr ha quattro PR aperte che aggiungono il supporto NIP-62 nei backend memory, LMDB, SQLite, e database test (PR #1315, PR #1316, PR #1317, PR #1318). Questo mette il lavoro di supporto lato client e lato relay nella stessa settimana.

Il design del protocollo introduce una tensione pratica. La proposta di valore di Nostr include la resistenza alla censura, cioè i relay non dovrebbero essere in grado di impedire la pubblicazione. NIP-62 introduce un caso in cui un relay MUST impedire la ripubblicazione da una specifica pubkey. Le due proprietà convivono perché la richiesta è auto-diretta: chiedi la cancellazione dei tuoi event, non di quelli di qualcun altro. La proprietà di resistenza alla censura rimane intatta per tutti tranne che per la persona che ha scelto esplicitamente di uscirne.

Questo è tutto per questa settimana. Stai costruendo qualcosa o hai notizie da condividere? Contattaci tramite DM NIP-17 (Private Direct Messages) o trovaci su Nostr.

Nostr Compass #15

Wed, 25 Mar 2026 00:00:00 +0000

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

Questa settimana: Primal Android fa seguito al suo rilascio wallet 3.0 con Follow Pack, arricchimento zap e deep link primalconnect://. BigBrotr pubblica un’analisi delle nsec esposte scansionando 41 milioni di event su 1.085 relay, trovando 16.599 chiavi private valide, mentre npub.world integra gli avvisi di esposizione nelle pagine profilo la stessa settimana. Martti Malmi lancia nostr-vpn, un’alternativa a Tailscale che segnala tramite relay Nostr e crea tunnel WireGuard, distribuendo 11 rilasci in sette giorni. Il team Vector rilascia in open-source DOOM P2P su Nostr, FIPS distribuisce la v0.2.0, e Nostrability Schemata si espande a sei linguaggi in una settimana.

Notizie

Primal aggiunge Follow Pack, arricchimento zap e deep link

Come da copertura della 3.0.7 della settimana scorsa, Primal Android ha dedicato questa settimana al lavoro post-rilascio su onboarding, UX del composer e contesto wallet. L’onboarding ridisegnato introduce i Follow Pack (PR #949), un pulsante GIF nativo si unisce al composer delle note, un servizio di arricchimento zap (PR #979) annota le transazioni wallet con il contesto zap, e un protocollo di deep-linking primalconnect:// (PR #969) abilita la navigazione cross-app.

Primal iOS sta distribuendo lo stesso lavoro tramite TestFlight in parallelo, con lo switch wallet (PR #191), l’implementazione dei sondaggi e il refactoring dell’onboarding che arrivano nella stessa finestra.

BigBrotr mappa le chiavi private esposte nella rete relay

BigBrotr, la piattaforma di analisi relay Nostr, ha pubblicato un’analisi dettagliata delle chiavi private esposte nella rete relay. Lo studio ha scansionato 41 milioni di event da 1.085 relay, cercando stringhe nsec valide incorporate nel contenuto degli event, e ha trovato 16.599 chiavi private valide. Quel numero sembra allarmante finché non si filtra un bot chiamato “Mr.nsec” che rappresenta il 92% delle corrispondenze. Dopo aver rimosso il traffico bot, solo 38 account reali con più di 21.000 follower combinati avevano chiavi esposte, e nessuno mostrava segni di consapevolezza che le proprie chiavi fossero pubbliche.

Il team ha costruito un nsec-leak-checker come servizio NIP-90 (Data Vending Machine), permettendo agli utenti di verificare se la loro chiave privata appare ovunque nel dataset scansionato senza rivelare la chiave al verificatore. npub.world ha integrato i dati di esposizione la stessa settimana, mostrando banner di avviso sulle pagine profilo dove sono state rilevate chiavi esposte. La combinazione dà alla rete sia un’interfaccia programmatica per DVM e agenti sia un avviso leggibile per gli utenti comuni. Il dataset sottostante alimenta anche BigBrotr v6.4.0, che aggiunge viste materializzate per event sostituibili e indirizzabili e una correzione del timeout di inattività del sincronizzatore.

Nostr VPN si lancia come alternativa a Tailscale

Martti Malmi (mmalmi), creatore di Iris, ha costruito e distribuito nostr-vpn, una VPN peer-to-peer che usa relay Nostr per la segnalazione e WireGuard (tramite boringtun) per tunnel cifrati. La motivazione era diretta: “Mi sono irritato che Tailscale richieda account di terze parti, quindi ho creato Nostr VPN.” Lo strumento crea reti mesh tra dispositivi usando keypair Nostr come identità, senza server di coordinamento centrale.

Il progetto ha distribuito 11 rilasci in sette giorni, dalla v0.2.2 alla v0.2.13. Quello sprint ha aggiunto il supporto Windows, il pairing LAN per la scoperta nella rete locale, e un sidecar Android per dispositivi mobili. L’architettura è semplice: due dispositivi si scambiano metadati di connessione tramite relay Nostr, poi stabiliscono un tunnel WireGuard diretto. Nostr gestisce la scoperta e la segnalazione per l’attraversamento NAT. WireGuard gestisce il traffico effettivo. L’identità è un keypair Nostr.

Malmi ha anche continuato a sviluppare nostr-double-ratchet, una libreria per canali di messaggistica sicura in stile Signal, distribuendo sei rilasci dalla v0.0.86 alla v0.0.93 durante la stessa settimana.

DOOM open-source gira peer-to-peer su Nostr

Il team Vector ha rilasciato in open-source un’implementazione multiplayer peer-to-peer di DOOM che usa Nostr per la scoperta dei peer, Marmot per la cifratura end-to-end, e Iroh, la libreria di networking QUIC di n0, per il trasporto gossip. Il gioco viene distribuito come file WebXDC da 4,2 MB che può essere inviato all’interno di messaggi chat, senza richiedere server per ospitare o coordinare una partita.

L’approccio tecnico sostituisce il netcode lockstep originale del 1993 con un modello di sincronizzazione ibrido in tempo reale. I giocatori si scoprono a vicenda tramite query ai relay Nostr, negoziano le sessioni attraverso canali cifrati con Marmot, poi passano al livello gossip QUIC di Iroh per il traffico di gioco a bassa latenza. Lo stack usa Nostr per la scoperta, Marmot per la cifratura, e Iroh per il trasporto.

Vector ha anche distribuito hardening di sicurezza questa settimana. Il rilascio aggiunge un vault di chiavi con protezione della memoria con protezioni anti-debug e zeroize per il materiale chiave sensibile, blocco utenti con filtraggio completo di DM e messaggi di gruppo, e correzioni del canale realtime WebXDC per le Mini App.

FIPS v0.2.0 distribuisce trasporto Tor, build riproducibili e esempi sidecar

FIPS, il Free Internetworking Peering System e progetto di networking mesh adiacente a Nostr, ha distribuito la v0.2.0. Il rilascio aggiunge supporto al trasporto Tor per link mesh anonimizzati, build riproducibili, un esempio sidecar che si connette attraverso un relay Nostr, e pubblicazione dei rilasci su Nostr nel workflow del pacchetto OpenWrt. Il rilascio corregge anche i picchi di jitter post-rekey causati da frame della finestra di drain. Il formato wire è cambiato dalla v0.1.0, quindi i nodi v0.1.0 esistenti non possono interoperare con la v0.2.0 senza aggiornamento.

Nostrability Schemata diventa multilingue

Il progetto Nostrability Schemata, che mantiene definizioni JSON Schema per la validazione dei kind di event Nostr, si è espanso dal solo JavaScript a sei linguaggi in una settimana. Nuovi pacchetti sono stati distribuiti per Rust, Go, Dart, Swift e Python, ognuno fornendo sia un pacchetto dati che un validatore. La v0.2.6 ha anche aggiunto 17 nuovi schemi di kind event.

Il tracker di interoperabilità Nostrability ha ricevuto una revisione parallela. Una nuova scheda What’s New pubblica aggiornamenti sia tramite un feed Atom che un event Nostr, il filtraggio per categoria app permette ai visitatori di esplorare tipi specifici di client, e il tracker ora rileva automaticamente i linguaggi di programmazione dai metadati dei repository GitHub. Nostrability ha anche il suo npub ora, rendendo il progetto stesso scopribile attraverso il protocollo che documenta. Per gli autori di librerie che lavorano su più linguaggi, i pacchetti schema multi-linguaggio significano che le stesse definizioni di kind event sono disponibili come import nativi invece di richiedere ad ogni progetto di mantenere la propria copia dello schema.

Rilasci

Amethyst v1.06.0 e v1.06.1

Amethyst, il client Android mantenuto da vitorpamplona, ha distribuito la v1.06.0 e la v1.06.1 il 23 marzo. La funzionalità principale è il supporto ai sondaggi usando dati NIP-85 (Trusted Assertions) per il voto ponderato, con card ridisegnate per sondaggi e sondaggi zap. Il nuovo rendering dà sia ai sondaggi standard che ai sondaggi con peso zap un layout visivo più pulito. La v1.06.1 segue con correzioni di crash per modifiche concorrenti che risolvono regressioni di stabilità introdotte nel percorso di rendering dei sondaggi.

Amber v5.0.0 e v5.0.1

Amber, l’app signer NIP-55 (Android Signer Application), ha promosso il suo recente lavoro pre-release 4.1.x in stabile con la v5.0.0 il 18 marzo. Quel rilascio stabile porta le modifiche di relay-auth NIP-42, Tor integrato, permessi specifici per tipo di contenuto e storage PIN cifrato coperte la settimana scorsa. La v5.0.1 rimuove poi il permesso internet dal build flavor offline, in modo che quel build non possa più effettuare richieste di rete a livello di permessi Android.

Mostro v0.17.0 e Mostro Mobile v1.2.2

Mostro, lo scambio Bitcoin peer-to-peer costruito su Nostr, ha distribuito la v0.17.0 il 18 marzo. Il rilascio server continua il lavoro sulle dispute e le valutazioni dal ciclo v0.16.x, aggiungendo dati di reputazione commerciale più completi per acquirenti e venditori come event Nostr. Mostro Mobile, il client Flutter, ha seguito con la v1.2.2 il 23 marzo, mantenendo l’interfaccia mobile sincronizzata con le ultime modifiche al protocollo.

Shosho v0.14.0

Shosho, l’app di live streaming Nostr, ha distribuito la v0.14.0 il 19 marzo con il lancio di Shosho Shop. Il rilascio aggiunge una scheda Shop sui profili, Shop in Esplora, e un pulsante In-Live Shop su live e clip. Le note di rilascio dicono che i “prodotti Nostr” esistenti appaiono automaticamente e gli acquirenti cliccano per accedere alla pagina Plebeian Market del venditore per l’acquisto. Le note di rilascio di Shosho non identificano il kind di event degli annunci, quindi non è ancora possibile confermare se Shosho Shop legge gli stessi annunci classificati NIP-99 che Shopstr supporta esplicitamente nel suo README.

Applesauce v5.2.0

Applesauce, la collezione di pacchetti helper di hzrd149 per costruire applicazioni Nostr, ha distribuito la v5.2.0 il 22 marzo. Il rilascio copre sei pacchetti. Il pacchetto SQLite corregge una collisione di vincolo UNIQUE sui tag degli event che causava inserimenti duplicati. Il pacchetto signers aggiunge AndroidNativeSigner, che avvolge l’interfaccia signer nativa Android NIP-55 in modo che le app basate su web-view possano usare la firma hardware-backed senza codice bridge personalizzato. Il pacchetto relay aggiunge un campo challenge agli oggetti di stato relay e pool, tracciando lo stato auth NIP-42 in modo che le app possano rilevare quando un relay sta richiedendo l’autenticazione e rispondere programmaticamente. Il pacchetto core acquisisce i metodi isEventPointerSame e isAddressPointerSame per la deduplicazione dei riferimenti event, e il pacchetto common aggiunge user.blossomServers$ per risolvere i server media Blossom di un utente. Applesauce alimenta noStrudel, Satellite e diversi altri client web, quindi queste correzioni si propagano attraverso il livello client web.

Wisp distribuisce 16 rilasci in una settimana

Wisp, il client Nostr Android, ha distribuito 16 rilasci dalla v0.9.3-beta alla v0.13.1-beta questa settimana. Le aggiunte di funzionalità includono supporto multi-account, una modalità notifiche zen per interruzioni ridotte, bozze e post programmati, filtri di sicurezza dei contenuti e una nuova icona fiamma.

Manent v1.2.0

Manent, l’app di note private cifrate e storage file, ha distribuito la v1.2.0 il 20 marzo. Il rilascio aggiunge la cattura dalla fotocamera direttamente dall’app, il ridimensionamento delle immagini prima dell’upload per ridurre i costi di storage, e pinch-to-zoom per esaminare le immagini archiviate. Manent archivia note e file cifrati sui relay Nostr usando il keypair dell’utente, rendendo il telefono o l’app desktop un thin client che può ricostruire il suo stato completo dai dati dei relay.

diVine 1.0.7

diVine, il client di video brevi, ha distribuito la 1.0.7 il 21 marzo con un watchdog per la riproduzione video che riprende automaticamente i video bloccati. Dopo l’infrastruttura di test E2E e il caricamento diretto MP4 nella v1.0.6, questo rilascio mira al percorso di errore di riproduzione rimanente: video che si fermano a metà stream senza generare un errore.

Alby Extension v3.14.2

Alby Extension, l’estensione browser NIP-07 (Browser Extension Signer), ha distribuito la v3.14.2 il 18 marzo con la visualizzazione QR code dell’indirizzo Lightning e supporto alla firma Schnorr. L’aggiunta di Schnorr allinea l’estensione browser con lo schema di firma secp256k1 che Nostr usa nativamente.

NoorNote da v0.6.5 a v0.6.11

NoorNote, l’app per prendere appunti, ha distribuito sette rilasci dalla v0.6.5 alla v0.6.11. L’aggiunta principale sono i Follow Pack: bundle curati di account che gli utenti possono esplorare e sottoscrivere in blocco, simili alle Liste Twitter ma pensati per l’onboarding. Gli utenti possono creare, modificare e condividere Follow Pack con titoli, descrizioni e immagini di copertina personalizzati. La serie aggiorna anche la libreria Nostr sottostante da NDK v2 a v3, che porta una gestione migliorata delle connessioni relay e delle sottoscrizioni. Le note con immagini e un’esperienza di connessione relay ridisegnata completano il ciclo.

nak v0.19.1 e v0.19.2

nak, il toolkit Nostr a riga di comando di fiatjaf per interagire con i relay, codificare e decodificare identificatori NIP-19 (Bech32-Encoded Entities), firmare event e interrogare dati dei relay, ha distribuito la v0.19.1 e la v0.19.2 il 17 e 20 marzo. Le due point release seguono l’aggiunta della UI group-forum v0.19.0 dalla settimana scorsa.

Calendar by Form* v0.2.1

Calendar by Form*, l’app calendario decentralizzata costruita su NIP-52 (Calendar Events), ha distribuito la v0.2.1 il 20 marzo. Il rilascio corregge un problema nel template delle notifiche che influiva sui promemoria degli eventi. Calendar archivia gli event come kind 31922 (basati su data) e kind 31923 (basati su orario) di Nostr, permettendo a qualsiasi client Nostr di renderizzare i dati calendario se sceglie di supportare quei kind. L’app è costruita dal team Formstr, che mantiene anche Formstr (moduli decentralizzati) e Pollerama (sondaggi).

NYM da v3.50 a v3.53

NYM, il client di chat effimero leggero collegato a Bitchat, ha distribuito 28 rilasci dalla v3.50 alla v3.53 (le versioni patch incrementano rapidamente). La funzionalità più notevole è Nymbot, un chat bot integrato che risponde alle menzioni @nymbot nei canali e fornisce funzioni di stato e gestione dei relay. Una “hardcore mode” genera un keypair fresco per ogni messaggio inviato, rendendo i thread di conversazione non collegabili a livello di identità. Il compromesso è chiaro: si perde l’identità persistente ma si guadagna l’anonimato per messaggio. Il livello proxy relay ha anche ricevuto lavoro, con worker proxy relay sharded per migliore connettività, supporto canali geohash, e tolleranza al clock skew per nodi con orologi di sistema imprecisi.

Aggiornamenti Progetti

Ditto aggiunge bridge Bluesky e integrazione Wikipedia

Ditto, il client social Nostr personalizzabile del team Soapbox, ha registrato oltre 300 commit questa settimana su tre percorsi di funzionalità distinti. Il primo è un bridge Bluesky (19 commit) che renderizza i post Bluesky inline come thread completi in stile feed, aggiunge navigazione sidebar a una pagina di scoperta Bluesky alimentata dal feed ufficiale Discover (whats-hot), e collega pulsanti di azione per commentare, condividere, reagire e copiare link. Quando un utente risponde a un post Bluesky dall’interno di Ditto, la modale di composizione mostra un avviso che nota la natura cross-protocollo dell’interazione. Le reazioni kind 17 NIP-73 (External Content IDs) alimentano il modello cross-protocollo: un utente Nostr reagisce a un post Bluesky, e la reazione viene archiviata come un event Nostr standard che referenzia l’identificatore di contenuto esterno. Questo è lo stesso pattern NIP-73 che potrebbe collegare reazioni a qualsiasi contenuto esterno, dai post Bluesky ai video YouTube alle pagine web.

Il secondo percorso è un’integrazione Wikipedia (9 commit). Ditto ora renderizza contenuti ricchi di articoli Wikipedia sulle pagine di dettaglio invece di anteprime link generiche, aggiunge autocompletamento nella ricerca con miniature degli articoli, e fornisce una pagina /wikipedia che attinge contenuti in evidenza dall’API Wikipedia. I risultati di Wikipedia e Archive.org appaiono anche nel dropdown di autocompletamento della ricerca generale. Il terzo percorso è il supporto piattaforma iOS tramite Capacitor, con script di build remoto e configurazione piattaforma che arrivano insieme a una revisione della UI (55 commit) che sostituisce gli header con backdrop-blur con un nuovo design di navigazione basato su arco su ogni pagina dell’app. I 314 commit muovono Ditto da un client solo-Nostr verso un aggregatore multi-protocollo che tratta Bluesky e Wikipedia come sorgenti di contenuto di prima classe accanto al feed Nostr.

Pika costruisce una pipeline CI forge NIP-34

Pika, l’app di messaggistica cifrata basata su Marmot, ha unito 33 PR questa settimana focalizzate su un forge NIP-34 self-hosted con CI pre-merge. Il forge è un livello di hosting git che riceve patch come event NIP-34, esegue controlli CI prima del merge, e riporta lo stato strutturato tramite event Nostr. La PR #701 aggiunge CI pre-merge e nightly basata su lane, dove ogni percorso di codice (Rust, TypeScript, build Apple) gira nella propria lane con stato pass/fail indipendente. La PR #715 riduce gli agenti CI gestiti a container Incus OpenClaw per l’isolamento, e la PR #733 aggiunge una CLI ph forge per interagire con il forge ospitato dalla riga di comando. PR di supporto gestiscono i permessi di scrittura al repo per i merge (PR #736), metadati CI strutturati con badge di stato live (PR #722), split delle build Apple nightly (PR #738), e correzioni di auth e ricerca branch del forge (PR #734). Questo è uno dei primi sistemi CI/CD funzionanti costruiti sopra gli event git NIP-34, spostando l’hosting del codice sorgente basato su Nostr oltre lo scambio base di patch verso il workflow di merge-and-test che gli sviluppatori si aspettano da GitHub o GitLab.

Nostria aggiunge comunità, snippet di codice e gestione event vocali

Nostria, il client Nostr cross-platform mantenuto da sondreb, ha dedicato questa settimana a estendere la superficie app oltre il filtraggio Web of Trust coperto nel #14. L’aggiunta principale è un’implementazione completa di NIP-72 (Moderated Communities) con creazione comunità, configurazione moderatori e relay, tracciamento approvazione post con anteprime immagini, e una pagina comunità dedicata con tab Post e Moderatori.

Lo stesso arco di lavoro aggiunge anche rendering e editing di snippet di codice con un editor con evidenziazione della sintassi, supporto risposte a event vocali per conversazioni audio, impostazioni relay chat per messaggi diretti, condivisione canali tramite la Web Share API, un sistema di docking toolbar per il media player, registrazione in-app per l’ultimo servizio Web of Trust di Brainstorm, flussi di invio e ricezione denaro nei DM usando NWC e fatture BOLT-11, gestione GIF nativa Nostr, e un percorso di importazione RSS più robusto per i musicisti che può raccogliere gli split Lightning esistenti dai feed podcast.

Iterazione rapida nostr-vpn

Oltre al lancio iniziale, il log dei commit di nostr-vpn rivela i problemi specifici incontrati durante il deployment reale. La v0.2.3 fino alla v0.2.5 hanno aggiunto lo script di installazione iniziale e la CLI cross-platform. La v0.2.6 e la v0.2.7 hanno portato il supporto Windows, che ha richiesto il quoting del percorso UAC per le scritture di configurazione e aggiornamenti di configurazione di proprietà del daemon. La v0.2.8 fino alla v0.2.10 hanno corretto le azioni del servizio GUI Windows, la gestione dei sottoprocessi CLI e la configurazione del servizio machine-scoped. La v0.2.12 ha sostituito la scoperta LAN con il pairing LAN a tempo, un flusso avviato dall’utente dove due dispositivi sulla stessa rete locale si accoppiano senza segnalazione relay. Il pattern è da manuale di testing sul campo in fase iniziale: ogni rilascio mira a uno specifico fallimento di deployment, la base utenti è abbastanza piccola per iterare quotidianamente, e lo sviluppatore usa lo strumento personalmente tra i rilasci.

Build automatizzate Comet

Comet (precedentemente Captain’s Log), lo strumento di scrittura long-form nativo Nostr di Nodetec, ha prodotto oltre 40 build alpha automatizzate questa settimana. Comet è un’app desktop per scrivere e pubblicare articoli NIP-23 (Long-form Content), con storage locale delle bozze, editing markdown e pubblicazione one-click sul set di relay dell’utente. La pipeline di build automatizzata genera un rilascio taggato per ogni commit sul branch main, il che rende il conteggio grezzo dei rilasci fuorviante come misura della velocità delle funzionalità. Ciò che le 40 build mostrano è che l’app è in sviluppo attivo quotidiano, con ogni commit testato, pacchettizzato e reso disponibile per il download in pochi minuti.

Aggiornamenti NIP

Modifiche recenti al repository NIPs nella finestra 17-24 marzo:

Nessun merge NIP è arrivato tra il 18 e il 24 marzo.

PR Aperte e Discussioni aggiornate nella finestra:

NIP-AA: Agenti Autonomi su Nostr (PR #2259): Propone convenzioni per agenti autonomi che operano sulla rete Nostr. La PR definisce come gli agenti si identificano, scoprono servizi e si coordinano con altri agenti e umani attraverso event Nostr.
NIP-50 (Search): Estensioni di ordinamento (PR #2283): Aggiunge parametri di ordinamento alle query di ricerca NIP-50, inclusi top, hot, zaps e new. Questo permetterebbe ai client di richiedere risultati classificati dai relay che supportano la ricerca full-text invece di ordinare lato client.
NIP-A5: Programmi WASM (PR #2281): Propone una convenzione per pubblicare e scoprire programmi WebAssembly su Nostr. I binari WASM potrebbero essere distribuiti come event Nostr, con i relay che servono come livello di scoperta per codice eseguibile portabile.
NIP-CF: Combine Forces napps interoperabili (PR #2277): Definisce una convenzione per applicazioni Nostr interoperabili (“napps”) che possono comporre funzionalità tra diversi client e servizi.
NIP Snapshots (PR #2279): Propone un meccanismo per snapshot dello stato dei relay, per la sincronizzazione e il backup dei relay.
NIP Checkpoints (PR #2278): Propone event checkpoint per segnare lo stato valido noto dei relay, complementando la proposta snapshots.
NIP-58 (Badges): Refactoring Badge Sets (PR #2276): Ristruttura come le collezioni di badge sono organizzate e referenziate.
NIP-11 (Relay Information Document): Estensioni (PR #2280): Aggiunge campi aggiuntivi al documento informativo del relay per metadati relay leggibili dalle macchine più ricchi.

Cinque Anni di Marzo di Nostr

La newsletter del mese scorso ha coperto come i febbrai di Nostr sono progrediti dalla riscrittura di NIP-01 (Basic Protocol Flow) attraverso l’ondata Damus sull’App Store fino alle reti mesh e le proposte per agenti. Questa retrospettiva traccia cosa è successo ogni marzo dal 2021 al 2026.

Marzo 2021: Due Commit

Quattro mesi dopo la sua nascita, il marzo di Nostr ha prodotto esattamente due commit al repository del protocollo, entrambi il 4 marzo. fiatjaf ha aggiunto link alle istanze nostwitter, indirizzando i primi visitatori a deployment funzionanti, e ha aggiunto kind alla definizione base dei filtri. Quel secondo commit è rivelatore: nel marzo 2021, non si potevano ancora filtrare gli event Nostr per kind. Il protocollo era così primitivo. Due o tre relay servivano la rete. Il gruppo Telegram era l’unico canale di coordinamento. Il repository NIPs non esisteva ancora; le proposte di protocollo vivevano come file nel repo principale nostr. fiatjaf era l’unico committer quel mese. L’intero output del marzo 2021 di quello che sarebbe diventato un protocollo che supporta VPN, giochi multiplayer e networking mesh cinque anni dopo entra in una singola diff git.

Marzo 2022: Costruzione Pre-Damus

Il repository principale del protocollo ha ricevuto zero commit nel marzo 2022. Lo sviluppo si era spostato interamente nei repository degli strumenti. Branle, il client web Vue.js di fiatjaf e all’epoca l’interfaccia Nostr principale, ha ricevuto 5 commit incluso il supporto al deployment Docker e correzioni alla visualizzazione del nome di verifica NIP-05 (DNS-Based Verification) che rimuovevano il prefisso _@ dai badge di verifica. more-speech di Robert C. Martin, il client desktop Clojure, ha registrato 13 o più commit aggiungendo threading, navigazione da tastiera e una finestra di editing. L’autore di software più famoso che costruiva attivamente su Nostr quel mese non era uno sviluppatore crypto ma la persona il cui “Clean Code” ha venduto milioni di copie, che scriveva un client Nostr in Clojure, una scelta di linguaggio che dice tutto sulla comunità iniziale: erano programmatori con opinioni forti che costruivano per sé stessi.

La rete relay si era espansa a circa 15 relay con una base utenti attiva nell’ordine delle centinaia. Damus non esisteva ancora e non sarebbe stato creato fino ad aprile 2022. Nemmeno Nostream era apparso. Il lavoro del mese era infrastruttura: rendere gli strumenti esistenti più affidabili per la piccola comunità che li usava già quotidianamente.

Marzo 2023: Infrastruttura Post-Esplosione

Un mese dopo l’ondata Damus sull’App Store e il superamento delle 300.000 chiavi pubbliche, il marzo 2023 riguardava l’assorbimento della crescita. Il repository NIPs ha unito 28 pull request, il secondo conteggio mensile più alto nella storia del protocollo. NIP-51 (Lists) è stato unito, dando ai client collezioni strutturate di follow, mute e segnalibri. NIP-39 (External Identities in Profiles) è arrivato, NIP-78 (Application-Specific Data) ha fornito un kind di storage generale per le app che necessitavano di stato privato, e una riscrittura di NIP-57 (Lightning Zaps) (PR #392) ha consolidato il flusso zap e chiarito la terminologia. La PR più discussa del mese era una proposta alternativa di gestione delle menzioni (PR #381) con oltre 50 commenti.

Il nuovo progetto più importante è stato NDK (Nostr Development Kit), la libreria TypeScript per connessioni relay, firma event, caching e gestione sottoscrizioni. pablof7z ha fatto il commit iniziale il 16 marzo 2023, poi l’ha riscritto da zero 11 giorni dopo il 27 marzo (“praticamente un altro commit iniziale”), e aveva il supporto LNURL e zap funzionante entro il 31 marzo. NDK è passato dal nulla alla capacità zap in 15 giorni. Cinque giorni dopo la creazione di NDK, il 21 marzo, il team Alby ha creato NWC (Nostr Wallet Connect), l’implementazione di riferimento di NIP-47 che connetteva i wallet Lightning alle applicazioni Nostr. I due progetti che avrebbero sostenuto i successivi tre anni di sviluppo Nostr basato sul web sono nati nella stessa finestra di 30 giorni. OpenSats non aveva ancora lanciato il suo fondo Nostr; la prima ondata non sarebbe arrivata fino a luglio 2023, quattro mesi dopo la creazione di NDK.

Altre creazioni notevoli di quel mese includevano NostrGit, NostrChat, un progetto nostr-signing-device di LNbits, e nostrmo. Gossip, il client desktop Rust focalizzato sulla selezione intelligente dei relay, ha distribuito tre rilasci. Il protocollo era in modalità costruzione, e gli strumenti creati nel marzo 2023 sono ancora in uso tre anni dopo.

Marzo 2024: Maturazione del Protocollo

Il marzo 2024 riguardava l’hardening del protocollo per l’uso a lungo termine. Il repository NIPs ha unito 12 pull request. La più significativa è stata NIP-34 (Git Stuff), PR #997, che è stata unita il 5 marzo dopo oltre 130 commenti e 44 giorni di revisione. Il thread di discussione è una capsula del tempo della comunità che dibatteva come costruire un GitHub decentralizzato. jb55 ha tracciato paralleli con git send-email, Giszmo ha proposto di usare gli hash dei root commit per la scoperta cross-fork (“qualcosa che GitHub non fa e che noi potremmo”), mikedilger ha suggerito l’autenticazione con event firmati NIP-98 (HTTP Auth) invece delle chiavi SSH, e fiatjaf ha liquidato bruscamente la necessità di generalità nel controllo versione: “non per ogni sistema di controllo versione, solo per git. Nessuno usa gli altri.” Entro poche ore dall’apertura della PR, fiatjaf aveva già convertito nak, go-nostr e gitstr per accettare patch su Nostr. DanConwayDev, il cui ngit era già un grantee OpenSats, era tra i contributori più attivi alla discussione. È stato unito anche un campo bot per i metadati dei profili, dando ai client un modo leggibile dalle macchine per distinguere gli account automatizzati da quelli umani.

Amethyst ha distribuito la v0.85.0 con supporto event git, articoli wiki, rendering di dati medici e editing di contenuti in un singolo rilascio. Mostro ha raggiunto la v0.10.0. Nosflare, un relay Nostr serverless in esecuzione su Cloudflare Workers, ha dimostrato che la logica relay poteva girare all’edge. OpenSats ha emesso una grant di Supporto a Lungo Termine a Bruno Garcia per contributi sostenuti al client Amethyst.

Marzo 2025: Espansione dell’Infrastruttura

Il marzo 2025 ha prodotto 10 NIP uniti. Il titolo principale è stato NIP-66 (Relay Discovery and Liveness Monitoring), PR #230, che è stata unita il 3 marzo dopo un percorso di 25 mesi. dskvr ha proposto per la prima volta il monitoraggio dei relay nel febbraio 2023, gli è stato detto che poteva essere fatto lato client, ha spiegato perché connettersi a migliaia di relay contemporaneamente era impraticabile per i singoli client, ha attraversato sette bozze complete, ha costruito nodi di monitoraggio in otto regioni geografiche (Northeast US, Brasile, US-West, US-East, Australia, India, Corea, Sud Africa), e ha atteso che il tooling relay si mettesse al passo. Quando è stata unita, le implementazioni esistevano già in nostr.watch, relaypag.es, monitorlizard, Snort, noStrudel e Jumble. I dati NIP-66 avrebbero poi alimentato i benchmark outbox di Nostrability coperti nella Newsletter #12. È stato unito anche NIP-C0 (Code Snippets) (PR #1852, 63 commenti), aggiungendo event kind 1337 per la condivisione di codice sorgente.

I primi server MCP per Nostr sono apparsi questo mese. nostr-mcp-server è apparso il 23 marzo e nwc-mcp-server il 14 marzo, solo quattro mesi dopo che Anthropic ha annunciato il Model Context Protocol nel novembre 2024. Questi primi bridge hanno preceduto l’SDK completo di ContextVM e il lavoro di commercio agenti che è seguito alla fine del 2025 e inizio 2026.

Gossip ha distribuito la v0.14.0. Coracle, il client web di hodlbod con gestione feed consapevole dei relay, ha distribuito tre rilasci. OpenSats ha annunciato la sua decima ondata di grant Nostr, continuando la pipeline di finanziamento attiva dalla metà del 2023.

Marzo 2026: Convergenza

L’attività di marzo 2026 è tratta dai numeri di Nostr Compass #12 fino al #15 (questo numero).

Il marzo 2026 è il mese in cui thread disparati sono convergiti in sistemi funzionanti. Il Marmot Development Kit ha distribuito il suo primo rilascio pubblico con media cifrati, binding multi-linguaggio, e una migrazione ChaCha20-Poly1305 che ha richiesto aggiornamenti coordinati tra specifica, Rust e TypeScript. Shopstr e Milk Market hanno aggiunto superfici di commercio MCP per acquisti guidati da agenti. NIP-42 relay auth è arrivato simultaneamente in Amber, strfry e OAuth Bunker, chiudendo il cerchio tra software signer, relay e bunker. Notedeck ha distribuito aggiornamenti software nativi Nostr usando event di rilascio NIP-94 (File Metadata).

Questa settimana, BigBrotr ha scansionato l’intera rete relay alla ricerca di chiavi private trapelate e ha pubblicato sia l’analisi che un checker DVM. Nostr VPN ha dimostrato che il modello di chiavi di Nostr funziona per l’infrastruttura di rete, non solo per i social media. DOOM ha dimostrato che scoperta Nostr, cifratura Marmot e trasporto QUIC possono far girare un gioco multiplayer in tempo reale. Amber è passato alla v5.0.0. Wisp ha distribuito 16 rilasci in sette giorni. Venticinque o più rilasci taggati sono arrivati da progetti importanti in una singola settimana.

Sette NIP sono stati uniti nei primi 24 giorni del mese. Il protocollo ha aggiunto il markup Djot NIP-54 (Wiki), i limiti di input NIP-19 (Bech32-Encoded Entities), la logica di query booleana NIP-91 (AND Operator for Filters), e le asserzioni Web of Trust NIP-85 (Trusted Assertions). Le proposte aperte spaziavano dagli agenti autonomi (NIP-AA) ai programmi WASM (NIP-A5) alle estensioni di ordinamento per la ricerca NIP-50.

Guardando Avanti

Cinque marzi di Nostr tracciano un arco chiaro. Nel 2021, una persona ha fatto due commit a un protocollo che non poteva ancora filtrare event per kind. Entro il 2023, NDK e NWC sono nati a cinque giorni di distanza per assorbire l’esplosione post-Damus. Entro il 2024, un thread di PR da 141 commenti dibatteva come la collaborazione git dovrebbe funzionare su un protocollo sociale. Entro il 2025, una specifica di monitoraggio relay che era stata pazientemente riscritta sette volte in 25 mesi è stata finalmente unita. Nel 2026, qualcuno si è irritato per il fatto che Tailscale richiede un account e ha costruito una VPN usando keypair Nostr, mentre qualcun altro ha distribuito DOOM multiplayer che scopre i peer tramite relay Nostr e cifra il gameplay tramite Marmot. La scansione di BigBrotr di 41 milioni di event su 1.085 relay dà una misura concreta di quanto la rete sia cresciuta. La superficie del protocollo nel marzo 2026 sarebbe stata irriconoscibile per il marzo 2021, ma il modello sottostante, event firmati da chiavi secp256k1 e distribuiti attraverso relay, non è cambiato.

Questo è tutto per questa settimana. Stai costruendo qualcosa o hai notizie da condividere? Contattaci tramite DM NIP-17 (Private Direct Messages) o trovaci su Nostr.

Nostr Compass #14

Wed, 18 Mar 2026 00:00:00 +0000

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

Questa settimana: Amethyst implementa il supporto completo ai metodi NIP-47 (Nostr Wallet Connect), Alby Hub aggiunge il supporto multi-relay nella v1.21.6, Amber distribuisce la v4.1.3 con Tor integrato e permessi signer più granulari, e Zeus rimuove un percorso keysend NWC rischioso nella PR #3835. Notedeck distribuisce un updater firmato nella v0.8.0-rc2 che scopre i rilasci attraverso event NIP-94 (File Metadata), mentre Damus corregge lo stato NIP-65 (Relay List Metadata) obsoleto, Nostrability Outbox rivede i suoi risultati di benchmark con dati corretti, e Primal iOS testa sottoscrizioni relay dirette per i DM. Primal Android distribuisce la 3.0.7, Route96 distribuisce la v0.6.0, OpenChat continua a perfezionare l’interoperabilità Marmot nella v0.1.0-alpha.11, Pika consolida il suo runtime nella pika/v1.1.1, e Nostria aggiunge il filtraggio Web of Trust tramite NIP-85 (Trusted Assertions). Il repository NIPs unisce il markup Djot per NIP-54 (Wiki) e un limite di input di 5000 caratteri per NIP-19 (Bech32-Encoded Entities), mentre nuove proposte aprono discussioni su file .nostrkey per NIP-49 (Private Key Encryption), consistenza dello stato di appartenenza per NIP-43 (Relay Access Metadata and Requests), guida alla cancellazione per NIP-17 (Private Direct Messages) e un URI share-intent per NIP-222.

Notizie

Il supporto Wallet Connect si amplia, e i client wallet stringono i percorsi di errore

Amethyst, il client Android mantenuto da vitorpamplona, ha unito la PR #1828, che porta la sua implementazione NIP-47 vicino alla copertura completa del protocollo. La patch aggiunge make_invoice, lookup_invoice, list_transactions, get_balance, get_info, metodi per hold invoice, supporto keysend con record TLV, discovery delle capacità tramite kind 13194, e event di notifica su kind 23197 con NIP-44 (Encrypted Payloads). Questo dà al client una superficie NWC molto più ampia senza dipendere da estensioni specifiche dell’app.

Lo stack wallet circostante si è mosso nella stessa direzione. Alby Hub, il nodo Lightning auto-custodiale e servizio wallet dietro molti deployment NWC, ha distribuito la v1.21.6 con supporto multi-relay e flussi di connessione e swap più semplici. Zeus, il wallet Lightning mobile, ha unito la PR #3835 rimuovendo il supporto keysend NWC dopo aver identificato un percorso silenzioso di drenaggio fondi in quel flusso, correggendo anche la gestione degli event in sospeso e l’attività Cashu. La connettività wallet su Nostr si sta ampliando, e gli implementatori stanno rimuovendo i flussi difficili da rendere sicuri.

Notedeck sposta la scoperta dei rilasci su Nostr

Come da copertura di Notedeck della settimana scorsa, Notedeck, il client desktop nativo del team Damus, ha distribuito la v0.8.0-rc2 dopo aver unito la PR #1326. Il nuovo updater si sottoscrive a event di rilascio firmati di kind 1063, abbina la piattaforma locale, scarica il binario referenziato e verifica il suo hash SHA256 prima dell’installazione. I metadati di rilascio non devono più provenire dall’API GitHub o dal sito web di un progetto. Una pubkey di rilascio fidata e una connessione relay sono sufficienti.

La stessa patch aggiunge una CLI notedeck-release che pubblica quegli event dagli artefatti di rilascio GitHub, il che significa che la pipeline di rilascio ora ha un percorso di pubblicazione nativo Nostr oltre a un percorso di scoperta nativo Nostr. Avvicina anche il modello di updater Damus e Notedeck al flusso di rilascio firmato pubblicato via relay di Zapstore: lo strumento zsp di Zapstore gestisce già gli asset software come event kind 1063 o 3063, quindi questo percorso non è vincolato a un singolo client o un singolo publisher. Il resto della release candidate è lavoro desktop pratico: colonne di follow, profilo “View As User”, supporto NIP-59 (Gift Wrap), statistiche note in tempo reale e gestione delle limitazioni NIP-11 (Relay Information Document), ma l’updater è la parte che probabilmente sopravviverà a questo singolo ciclo di rilascio.

Lo stato dei relay si avvicina al comportamento runtime

Damus ha unito la PR #3665, sostituendo un ID event di relay-list obsoleto memorizzato con una query diretta al database per l’event kind 10002 più recente. Quando il vecchio valore diventava obsoleto, le operazioni di aggiunta e rimozione relay potevano ricadere su bootstrap o liste vecchie di un anno, facendo apparire alcune modifiche ai relay come riuscite mentre lasciavano lo stato attivo invariato. La PR #3690 corregge un secondo percorso di errore eliminando lo stato lock.mdb obsoleto durante la compattazione LMDB in modo che l’app non vada in crash con SIGBUS al prossimo avvio.

Primal iOS ha aperto la PR #194, che si sottoscrive direttamente ai relay di scrittura NIP-04 (Encrypted Direct Messages) di un partner di chat mentre una conversazione è aperta, mantenendo il cache server come fallback. Nostur ha aperto la PR #53, che combina scoring randomizzato dei relay, filtraggio di liveness NIP-66 da nostr.watch e Thompson sampling per trasformare la selezione dei relay da un’euristica fissa in una policy appresa. I client hanno a lungo trattato la scelta dei relay come dati di configurazione. Sempre più app ora la trattano come stato live che necessita di logica di misurazione e riparazione.

Rilasci

Primal Android 3.0.7

Primal Android, il client Android di Primal, ha distribuito la 3.0.7 con un nuovo ciclo di sondaggi e wallet. La PR #945 aggiunge il voto nei sondaggi basato su zap, la PR #948 pagina il caricamento dei voti in modo che i sondaggi più grandi restino utilizzabili, e la PR #965 recupera le ricevute zap per tutte le transazioni. Lo stesso rilascio tagga anche gli event supportati con metadati client NIP-89 (Recommended Application Handlers) nella PR #968, che aiuta i client downstream ad attribuire le origini degli event in modo più pulito.

Amber v4.1.3

Come da copertura di Amber della settimana scorsa, Amber, l’app signer Android per i flussi NIP-55 (Android Signer Application), ha distribuito la v4.1.3. Il rilascio si basa sul suo recente lavoro relay-auth NIP-42 con più hardening operativo: la PR #327 aggiunge Tor integrato insieme al supporto Orbot, la PR #324 sostituisce i permessi di cifratura grossolani basati sui NIP con regole specifiche per tipo di contenuto, e la PR #336 rimuove i permessi di rete dal flavor offline mentre la PR #335 aggiunge controlli CI per mantenerli così. La PR #322 sposta anche lo storage del PIN nel DataStore cifrato.

Questo rilascio stringe il confine del signer stesso. Questo è utile per qualsiasi flusso Android che affida chiavi reali o decisioni di relay-auth ad Amber, perché la parte difficile non è solo cosa il signer può fare. È anche quanto strettamente può essere limitato nel suo ambito.

Route96 v0.6.0

Come da copertura di Route96 della settimana scorsa, Route96, il media server che supporta Blossom e NIP-96 (HTTP File Storage), ha rilasciato la v0.6.0. Il rilascio sposta la configurazione e lo stato della whitelist nel database con hot reload e aggiunge policy di conservazione per file freddi o invecchiati. Aggiunge anche un endpoint GET /user/files più ricco e il tracciamento delle statistiche dei file per download e egress, che dà agli operatori maggiore visibilità su come il loro storage server viene utilizzato.

OpenChat v0.1.0-alpha.11

Come da copertura di OpenChat della settimana scorsa, OpenChat, il client chat basato su Avalonia costruito sullo stack Marmot, ha distribuito la v0.1.0-alpha.11 dopo una settimana di lavoro rapido sul protocollo. Il commit c33895d avvolge gli event Welcome in gift wrap NIP-59 e rimuove i vecchi shim di normalizzazione tag MIP-00, il commit 2738ff4 completa l’audit di conformità MIP-02, e il commit 8e470cf fa lo stesso per la cifratura dei messaggi di gruppo MIP-03. Il commit 129ca37 consolida anche la gestione NIP-44 sull’implementazione marmot-cs condivisa, riducendo il rischio di deriva crittografica lato client.

nak v0.19.0 e v0.19.1

nak, il toolkit Nostr a riga di comando di fiatjaf, ha distribuito la v0.19.0 e la v0.19.1. La serie 0.19 aggiunge una UI group-forum nel commit 5f4efdb, passa le modifiche dei metadati di gruppo a un flusso di sostituzione completa nel commit da0b753, e sostituisce la vecchia gestione no-text con supported_kinds nel commit bef67d3. Per gli implementatori di gruppi, questo mantiene la CLI allineata con la direzione in cui si stanno muovendo le specifiche e i client dei gruppi.

Aggiornamenti Progetti

Amethyst

Come da copertura di Amethyst della settimana scorsa, Amethyst, il client Android con una delle superfici protocollari più ampie in Nostr, ha continuato a costruire sul suo lavoro wallet e relay dopo la patch NIP-47. La PR #1853 aggiunge query COUNT NIP-45 (Event Counting) nelle schermate di gestione relay, così gli utenti possono vedere quanti event ogni relay detiene effettivamente per home feed, notifiche, DM e dati indice. La PR #1849 aggiunge caricamenti di file cifrati per le chat NIP-17 (Private Direct Messages), con un percorso di retry per caricamenti non cifrati quando un host di storage rifiuta la versione cifrata.

La PR #1791 porta anche il login bunker desktop completo NIP-46 (Nostr Connect) con un indicatore heartbeat, che è importante perché i fallimenti di firma remota spesso appaiono come rotture casuali della UI dal lato dell’utente. Il client mostra se il signer è attivo e quanto recentemente ha risposto, rendendo anche ovvio quando la sessione corrente usa un bunker.

Nostria

Nostria, il client multi-piattaforma costruito attorno a uno stack local-first, ha unito la PR #561 aggiungendo il filtraggio Web of Trust per feed e risposte nei thread. La funzionalità usa i dati di ranking del trust-service esistente e li espone sia come filtro feed che come filtro risposte, nascondendo gli autori il cui rank non supera la soglia preservando la struttura del thread quando sono presenti discendenti fidati. Questo dà agli utenti un livello intermedio tra “mostra tutti” e la curazione basata su liste hardcoded.

La stessa settimana ha portato anche la PR #563, che aggiunge filtraggio dei contenuti e supporto repost alla pagina sommario. Fuori dalla lista PR tracciata, Nostria ha anche completato più della sua superficie per utenti avanzati. Ora supporta l’ultimo servizio Web of Trust di Brainstorm con registrazione in-app, insieme a flussi di invio e ricezione denaro nei DM usando NWC e fatture BOLT-11. Aggiunge anche la gestione GIF nativa Nostr tramite l’emoji NIP e un percorso di importazione RSS più robusto per i musicisti che può raccogliere gli split Lightning esistenti dai feed podcast. Nostria tratta ranking, media, pagamenti e pubblicazione come un’unica superficie app connessa.

Nostur

Nostur, il client iOS mantenuto da nostur-com, ha aperto la PR #53 per trasformare il routing outbox da un piano fisso in una policy con punteggio. La patch aggiunge scoring randomizzato dei relay, filtraggio di liveness NIP-66 con un feed nostr.watch in cache, e Thompson sampling in modo che i dati di successo e fallimento dei relay cambino le selezioni future. Il design mantiene una valvola di sicurezza quando troppi relay verrebbero filtrati e preserva i relay .onion. Questo è uno degli esempi più chiari attualmente di un client che tratta la selezione dei relay come un sistema adattivo.

Nostrability Outbox

Come dal precedente report sui benchmark Outbox, Nostrability Outbox, il progetto di benchmark e analisi focalizzato sul routing client NIP-65 e NIP-66, ha dedicato la settimana a stringere le proprie affermazioni. La PR #35 sostituisce i risultati Thompson-sampling gonfiati con un re-benchmark completo su 1.511 esecuzioni e raccomanda la variante CG3 per il routing in stile NDK. La PR #43 aggiunge decadimento e confronti per caso d’uso, corregge un bug di cache-poisoning 0 follows, poi riesegue il dataset Telluride dopo aver fissato i TTL della cache.

Questo non è lavoro di prodotto nel senso usuale, ma è importante per gli autori di client perché i numeri del progetto sono ora più precisi e meno lusinghieri nei punti in cui avevano precedentemente sovrastimato. Il risultato corretto è comunque utile. La selezione randomizzata continua a battere il routing puramente deterministico nei casi di cui Outbox si occupa, l’apprendimento in stile Thompson può migliorare materialmente la copertura quando i client persistono la cronologia utile dei relay, e il filtraggio di liveness NIP-66 riduce il tempo sprecato su relay inattivi. Il lavoro si sta anche trasformando in proposte di implementazione concrete, incluse NDK #387, Nostur #53, Amethyst #1833, rust-nostr #1282, welshman #53, e applesauce #54 più applesauce #55.

Backend White Noise

whitenoise-rs, il backend Rust usato da White Noise e altri strumenti Marmot, ha unito due patch di hardening al confine della gestione media Blossom. La PR #637 impone HTTPS sugli URL Blossom e aggiunge un timeout di upload, mentre la PR #642 limita i download blob a 100 MiB per impedire che pull di media sovradimensionati si trasformino in un percorso denial-of-service. Per il software di messaggistica privata, gli URL dei media sono una delle interfacce più critiche tra la logica applicativa cifrata e l’infrastruttura di rete non fidata. Questa settimana il team ha stretto quel confine.

rust-nostr

rust-nostr, la libreria Rust per il protocollo, ha unito la PR #1280 aggiungendo costruttori di convenienza per LocalRelayBuilderNip42. I nuovi helper di lettura e scrittura danno ai setup di relay embedded e test un modo più chiaro per trasformare la policy auth NIP-42 in codice. Questa è una piccola patch alla libreria, ma è importante per i team che costruiscono relay locali o integrati nelle app che necessitano di auth attivata senza ripetere boilerplate ogni volta.

Pika

Come dalla copertura precedente di Pika, Pika, l’app di messaggistica basata su Marmot, ha distribuito pika/v1.1.1 e pikachat-v1.1.1 con un ciclo di rilascio focalizzato sulla convergenza del runtime. La PR #542 introduce una facade runtime Marmot condivisa per CLI e sidecar, con l’host dell’app che si sposta sulla stessa superficie. La PR #556 stringe il ciclo di vita degli agenti OpenClaw e lo stato di provisioning, mentre la PR #600 aggiunge il ripristino da backup e una sicurezza di recovery più rigorosa per gli ambienti gestiti.

La superficie utente diretta qui è più piccola rispetto all’ultimo writeup su Pika, ma il cambiamento architetturale è significativo. Riunire logica di gruppo, media, chiamate e sessioni dietro un unico runtime condiviso riduce la possibilità che app e daemon divergano man mano che lo stack Marmot cresce.

Aggiornamenti NIP

Modifiche recenti al repository NIPs:

Uniti:

NIP-54 (Wiki): Passaggio da Asciidoc a Djot (PR #2242): I contenuti wiki su kind 30818 ora usano Djot come formato di markup canonico. Il testo unito aggiunge il comportamento esplicito dei wikilink, esempi di merge-request per kind 818, esempi di redirect per kind 30819, e esempi di normalizzazione per script non latini nei tag d. Questo dà agli implementatori un target di parsing più pulito rispetto ad Asciidoc e rimuove un altro percorso di specifica che dipendeva da un toolchain centrato su Ruby.
NIP-19 (Bech32-Encoded Entities): Aggiunta limite di input (PR #2264): La specifica ora raccomanda di limitare le stringhe di entità codificate Bech32 a 5000 caratteri. Questa è una piccola modifica con valore reale per i parser, perché le stringhe NIP-19 ora appaiono nei flussi QR, deep link, fogli di condivisione e input incollato dagli utenti in molti client.

PR Aperte e Discussioni:

File Nostr Key per NIP-49 (Private Key Encryption) (PR #2269): Propone un formato di file .nostrkey per l’esportazione e importazione di chiavi cifrate con password. Se unito, darebbe ai client un percorso di backup basato su file più normale rispetto alla copia di stringhe ncryptsec grezze.
Consistenza dello stato di appartenenza per NIP-43 (Relay Access Metadata and Requests) (PR #2267): Aggiunge una sezione che chiarisce che i relay dovrebbero mantenere un unico stato di appartenenza autoritativo per pubkey. Questo semplificherebbe la logica dei client di gruppo attorno ai cambiamenti di appartenenza e alla cronologia riprodotta.
Guida alla cancellazione per NIP-17 (Private Direct Messages) (PR #2260): Propone un percorso concreto per la modifica e cancellazione dei messaggi privati attraverso event di cancellazione avvolti in gift wrap. Il lavoro è ancora aperto, ma gli autori di client necessitano di una risposta qui se NIP-17 deve sostituire completamente i vecchi flussi DM.
URI Share-intent per NIP-222 (PR #2266): La bozza standardizzerebbe come le app mobile e desktop passano contenuti condivisi in un client Nostr. Questo è uno dei confini di interoperabilità più ruvidi nei flussi app-to-app attuali.

NIP Deep Dive: NIP-94 (File Metadata)

NIP-94 definisce kind 1063 come un event di metadati di prima classe per un file. La specifica dà all’event il suo content leggibile più tag leggibili dalle macchine per URL di download, tipo MIME, hash, dimensioni, anteprime, fallback e hint sul servizio di storage. Questo è importante perché il file diventa interrogabile sui relay come oggetto a sé stante. Un client non deve estrarre i metadati dal contenuto circostante per capire cos’è il file.

{
 "id": "6a92ef8d7c3a1b5d4e8f9a0b1c2d3e4f567890abcdef1234567890abcdef1234",
 "pubkey": "f1e2d3c4b5a697887766554433221100ffeeddccbbaa99887766554433221100",
 "created_at": 1742342400,
 "kind": 1063,
 "tags": [
 ["url", "https://downloads.example.org/notedeck/v0.8.0-rc2/notedeck-macos-universal.tar.gz"],
 ["m", "application/gzip"],
 ["x", "4a5b6c7d8e9f00112233445566778899aabbccddeeff00112233445566778899"],
 ["ox", "4a5b6c7d8e9f00112233445566778899aabbccddeeff00112233445566778899"],
 ["size", "48392011"],
 ["dim", "0x0"],
 ["magnet", "magnet:?xt=urn:btih:00112233445566778899aabbccddeeff00112233"],
 ["i", "00112233445566778899aabbccddeeff00112233"],
 ["blurhash", "LEHV6nWB2yk8pyo0adR*.7kCMdnj"],
 ["thumb", "https://downloads.example.org/notedeck/v0.8.0-rc2/thumb.png", "bbccddeeff00112233445566778899aabbccddeeff0011223344556677889900"],
 ["image", "https://downloads.example.org/notedeck/v0.8.0-rc2/screenshot.png", "ccddeeff00112233445566778899aabbccddeeff001122334455667788990011"],
 ["summary", "Signed macOS release artifact for Notedeck v0.8.0-rc2"],
 ["alt", "Notedeck desktop release archive"],
 ["fallback", "https://mirror.example.net/notedeck/v0.8.0-rc2/notedeck-macos-universal.tar.gz"],
 ["service", "nip96"]
 ],
 "content": "Notedeck macOS universal build",
 "sig": "11aa22bb33cc44dd55ee66ff77889900aabbccddeeff0011223344556677889911aa22bb33cc44dd55ee66ff77889900aabbccddeeff00112233445566778899"
}

I tag fanno più lavoro di quanto appaia a prima vista. x identifica il file servito, mentre ox identifica il file originale prima di qualsiasi trasformazione lato server. I tag di anteprima permettono ai client di costruire indici di file navigabili senza scaricare l’intero asset, e summary può portare un breve estratto accanto ad essi. fallback fornisce una seconda sorgente quando l’URL principale fallisce, e service indica il protocollo di storage dietro il file, come NIP-96 o un altro host. NIP-94 si colloca quindi sotto il posting sociale e sopra lo storage grezzo. Descrive il file, non la conversazione attorno al file.

Ecco perché l’updater di Notedeck di questa settimana è interessante. La PR #1326 usa event firmati di kind 1063 per la scoperta dei rilasci software, poi verifica il binario scaricato rispetto allo SHA256 pubblicato. La stessa forma di event può descrivere un artefatto software o un upload media. NIP-94 è abbastanza vecchio da essere stabile, ma ha ancora spazio per crescere perché sempre più progetti trattano gli event di metadati come un trasporto per le macchine, non solo come decorazione per le persone.

NIP Deep Dive: NIP-54 (Wiki)

NIP-54 definisce kind 30818 come un event articolo wiki. La specifica tratta il tag d come l’argomento normalizzato dell’articolo e permette a molti autori di pubblicare voci per lo stesso soggetto. Il corpo dell’articolo vive in content, mentre i tag gestiscono identità normalizzata, titolo di visualizzazione, sommari e riferimenti a versioni precedenti. Questo significa che NIP-54 non è solo un formato di contenuto. È anche un problema di recupero e ranking, perché ogni client deve ancora decidere quale versione dell’articolo mostrare.

{
 "id": "8c94e5d1f2a300112233445566778899aabbccddeeff00112233445566778899",
 "pubkey": "00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff",
 "created_at": 1742342400,
 "kind": 30818,
 "tags": [
 ["d", "nostr-wiki"],
 ["title", "Nostr Wiki"],
 ["summary", "Djot-formatted reference article about Nostr wiki events"],
 ["a", "30818:11223344556677889900aabbccddeeff00112233445566778899aabbccddeeff:nostr-wiki", "wss://relay.example.org", "fork"],
 ["e", "11223344556677889900aabbccddeeff00112233445566778899aabbccddeeff", "wss://relay.example.org", "fork"]
 ],
 "content": "Nostr is a [protocol][] for carrying events across relays.\n\n[protocol]: nostr:nevent1example",
 "sig": "33cc44dd55ee66ff77889900aabbccddeeff0011223344556677889900112233cc44dd55ee66ff77889900aabbccddeeff00112233445566778899001122"
}

Il merge di questa settimana cambia il markup canonico da Asciidoc a Djot nella PR #2242. Questo è importante per gli implementatori perché Djot ha una specifica standalone più stretta e una storia di parser più semplice attraverso i linguaggi. Il testo unito chiarisce anche come i wikilink in stile reference si risolvono, come le merge request usano kind 818, come i redirect usano kind 30819, e come la normalizzazione del tag d dovrebbe comportarsi per gli script non latini. Queste sono le parti che fanno sì che due client indipendenti concordino su quale articolo un link punta.

NIP-54 occupa anche un posto insolito nel protocollo. Un client wiki necessita di rendering del contenuto, ma necessita anche di una policy di ranking. Reazioni, liste relay, liste contatti e segnali di deferenza espliciti alimentano tutti quale articolo vince per un dato argomento. Il passaggio a Djot non risolve quel problema di ranking, ma rimuove una delle ambiguità del parser che stava sotto di esso. Ecco perché il merge è importante ora: la modifica riguarda meno la formattazione della prosa più bella e più il rendere il comportamento wiki multi-client più facile da implementare in modo consistente.

Stai costruendo qualcosa, o vuoi che lo copriamo? Contattaci tramite DM NIP-17 su Nostr a npub1wav4fae3gyfy3xj298kxj2mj8phavz7vavps34przq02j7w902qq902923.

Nostr Compass #13

Wed, 11 Mar 2026 00:00:00 +0000

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

Questa settimana: Shopstr e Milk Market aggiungono superfici MCP per il commercio guidato da agenti, mentre OAuth Bunker, Amber e strfry aggiungono relay-auth e supporto agli event protetti di NIP-42 in software per app, signer e relay. Route96 distribuisce due release incentrate su etichettatura AI, code di moderazione, perceptual hashing e documentazione server machine-readable. Samizdat, già live sul web, ha rilasciato la sua prima alpha Android e in seguito ha aggiunto il supporto signer di NIP-55. Formstr aggiunge la registrazione tramite NIP-49, Amethyst distribuisce il lavoro di risoluzione NIP-05 basato su Namecoin, Mostro rilascia la v0.16.4, e il repository NIPs unisce NIP-91 e le linee guida difensive per NIP-66.

Notizie

Shopstr e Milk Market aprono superfici MCP per il commercio

Shopstr, il marketplace peer-to-peer con pagamenti Lightning e Cashu, ha unito PR #234 (commit 94ef7d1), aggiungendo un server MCP con autenticazione API key per la gestione degli account degli agenti. La modifica aggiunge .well-known/agent.json per la discovery degli agenti, endpoint MCP per onboarding e stato, route per la creazione degli ordini e la verifica dei pagamenti, strumenti dedicati per acquisto e lettura, e una schermata impostazioni per le API key. PR #236 estende il tutto con azioni lato venditore per messaggi, indirizzi, aggiornamenti degli ordini e selezione delle specifiche di prodotto. Una correzione di sicurezza in PR #235 sostituisce l’hashing delle API key con SHA-256 a singola iterazione con PBKDF2 salato a 100.000 iterazioni.

Gli agenti possono leggere gli annunci di NIP-99 e procedere al checkout usando i flussi di pagamento esistenti di NIP-47 e NIP-60 senza dover fare scraping delle pagine o reverse-engineering del comportamento del client.

Milk Market, marketplace alimentare su Nostr attivo su milk.market, ha introdotto la stessa base MCP e API key nel commit da6c0b4. PR #10 aggiunge ordini in abbonamento, modifica dell’indirizzo di spedizione dopo l’acquisto, e gestione del checkout multi-merchant e multi-valuta per Stripe e altri percorsi di pagamento fiat. Una successiva PR #11 corregge un bug di inizializzazione del database all’avvio in cui la tabella delle pubblicazioni relay fallite non veniva creata nelle installazioni nuove, causando errori 500 al primo caricamento. L’interfaccia rivolta agli agenti funziona con checkout Bitcoin-native su Shopstr o con checkout misto fiat e Bitcoin su Milk Market.

NIP-42 relay auth tra bunker, signer e relay

OAuth Bunker, un bunker NIP-46 che collega provider OAuth alla firma Nostr, ha aggiunto il login NIP-07, la selezione automatica della singola identità e la pulizia delle identità eliminate (commit f0c7683). Quando esiste una sola identità, il bunker ora la seleziona automaticamente invece di chiedere all’utente. L’eliminazione di un’identità rimuove anche assegnazioni e connessioni rimaste orfane. Il commit 6b8796c aggiunge un percorso di configurazione ALWAYS_ALLOWED_KINDS per gli utenti assegnati, con kind 30078 come valore predefinito per i dati specifici dell’app, così le identità delegate possono scrivere nello storage dell’app senza approvazione per ogni event.

Amber, il signer NIP-55 principale su Android, ha distribuito la v4.1.3-pre4 insieme a quattro pre-release nel corso della settimana. PR #317 aggiunge la gestione dell’autenticazione relay NIP-42 per richieste di kind 22242. L’implementazione aggiunge una nuova colonna nel database che traccia i permessi specifici per relay con un indice univoco su (pkKey, type, kind, relay). Gli utenti vedono una schermata auth dedicata dove possono concedere o negare il permesso per relay singolo o per tutti i relay con wildcard *, e salvare quella scelta. I permessi wildcard cancellano tutte le voci specifiche per relay di quel kind. PR #318 segue con un refactor delle schermate per richieste multi-event, che ora mostrano i dettagli inline tramite composable card invece di navigare verso una schermata separata. La release aggiorna anche i relay profilo predefiniti, aggiunge la visualizzazione delle richieste in bottom sheet e corregge un crash sui dispositivi MediaTek disabilitando il keystore StrongBox.

Sul lato relay, strfry PR #156 implementa la gestione auth NIP-42 per gli event protetti di NIP-70, e PR #176 rifiuta i repost che incorporano event protetti.

Notedeck aggiunge i limiti relay di NIP-11 e funzionalità Agentium

Notedeck, il client desktop nativo del team Damus, ha unito 14 PR questa settimana. PR #1316 aggiunge il recupero dei limiti relay di NIP-11, così tutti i relay outbox ora rispettano max_message_length e max_subscriptions dal relay information document. L’implementazione include elaborazione in background, exponential backoff con jitter per i retry di connessione e header HTTP Accept personalizzati. PR #1312 corregge un bug per cui i DM talvolta non si caricavano dopo il cambio account, e PR #1333 aggiunge un meccanismo di backoff alla comunicazione relay multicast per evitare broadcast spam in caso di errore.

Il sottosistema Agentium, l’interfaccia integrata per agenti di coding di Notedeck chiamata internamente “Dave”, ha ricevuto il supporto all’incolla di immagini dalla clipboard, configurazioni di esecuzione nominate che si sincronizzano tra dispositivi tramite event kind 31991 di NIP-33, un creatore di git worktree e un model picker per selezionare backend diversi per sessione (PR #1336). PR #1338 integra egui_kittest per test UI headless, e PR #1339 aggiunge una dashboard card che traccia la creazione di nuove contact list da parte dei client. Una PR #1314 ancora aperta porta in Notedeck la risoluzione NIP-05 basata su Namecoin di Amethyst con lookup ElectrumX, routing SOCKS5 via Tor e integrazione nella barra di ricerca.

diVine distribuisce la v1.0.6 con infrastruttura di test E2E e import NIP-49

diVine, il client video short-form in loop che ripristina gli archivi Vine su divine.video, ha distribuito la v1.0.6 con 127 PR unite. La release aggiunge l’import account NIP-49, supporto NIP-05 esterno, gestione multi-account, build macOS e Linux sperimentale, e una libreria ridisegnata per draft e clip basata su storage locale.

Sul lato engineering, PR #1928 aggiunge un’infrastruttura completa di test di integrazione E2E usando Patrol per l’automazione UI nativa contro uno stack backend Docker composto da relay, API, Blossom, Postgres, Redis e ClickHouse. Cinque test del percorso auth coprono registrazione, verifica, reset password, scadenza sessione e refresh del token. PR #2105 cambia il caricamento video da HLS-first a MP4 diretto con fallback automatico a HLS, riducendo i tempi di caricamento da 30-60 secondi a quasi istantanei. PR #2076 mette in cache la risposta API del feed home in SharedPreferences per la visualizzazione immediata a cold start. PR #2104 impone che le etichette di contenuto ai-generated siano nascoste nei feed, e PR #2100 aggiunge un’impostazione di sicurezza per mostrare solo video ospitati da diVine. La migrazione della cache profili da Hive a Drift prosegue nelle PR #1881, PR #1883 e PR #1903, sostituendo circa 1.074 linee di codice Hive con DAO Drift.

Vector v0.3.2 distribuisce la sincronizzazione negentropy di NIP-77 e miglioramenti MLS

Vector, messenger desktop orientato alla privacy che usa la cifratura di gruppo MLS con NIP-17 e NIP-44, ha distribuito la v0.3.2. La novità principale è la negentropy NIP-77 per la sincronizzazione dei gruppi MLS (commit b06adf4), che recupera i messaggi persi molto più rapidamente tramite parallel boot. La release aggiunge anche un motore audio ricostruito con pieno supporto Linux, spoiler immagine con anteprime sfocate, hyperlink cliccabili con anteprime ricche, ping @mention con @everyone per gli admin dei gruppi, autocomplete per shortcode emoji, silenziamento dei gruppi, tap-to-react sulle reazioni esistenti e upload file annullabili. Vector filtra esplicitamente gli event di chat di gruppo NIP-17 (commit 2179a51), usando MLS in modo esclusivo per la cifratura di gruppo.

Rilasci

Route96 v0.5.0 e v0.5.1

Route96, media server che supporta Blossom e NIP-96, ha distribuito v0.5.0 e v0.5.1. La v0.5.0 aggiunge etichettatura AI automatizzata, backfill retroattivo per upload non etichettati, code di moderazione per file segnalati, rifiuto basato su EXIF per la privacy e gestione degli hash vietati.

La v0.5.1 aggiunge hash percettivi per immagini, locality-sensitive hashing per la ricerca di immagini simili, endpoint admin batch e un SKILL.md pubblicato che descrive la superficie API Blossom e NIP-96 del server per gli strumenti agentici. PR #58 sposta i background worker su task Tokio completamente asincroni, e il commit 97b00a3 aggiunge il backoff per evitare hot loop.

Samizdat v1.0.0-alpha

Samizdat, lettore e publisher long-form disponibile su samizdat.press, ha distribuito la sua prima build Android nella v1.0.0-alpha. L’app si apre con una pagina Press curata di articoli long-form Nostr e navigazione bottom tab tra le viste Press, Feed, Saved e Write. La build Android aggiunge storage nativo delle chiavi tramite cifratura Android Keystore con sblocco biometrico, gestisce URI nostr: e deep link samizdat.press, e supporta il passaggio della firma tramite chooser delle app Android, Amber, Primal e altre, invece di richiedere l’import diretto delle chiavi. Pull-to-refresh, gestione delle safe area su schermi di dimensioni diverse, e integrazioni native per condivisione, clipboard, feedback aptico e splash screen fanno ora parte della shell Android invece del wrapper web.

Il commit d17308f aggiunge la firma intent-based NIP-55 per i flussi Amber e Primal, e il commit e29dab8 sostituisce un workaround JavaScript bridge con un plugin Capacitor nativo che usa startActivityForResult. L’app richiede Android 7.0+ (API 24), viene distribuita come APK debug in questa alpha e ancora non include notifiche push. La pubblicazione dipende al momento da un’app signer, mentre il login con nsec copre la lettura locale e l’accesso all’account.

Calendar by Form* v0.2.0

Calendar by Form*, calendario decentralizzato con condivisione di eventi privati tramite NIP-59, disponibile su calendar.formstr.app, ha distribuito la v0.2.0 con PR #38. La release estende la gestione degli eventi ricorrenti di NIP-52, andando oltre la base a evento singolo della v0.1.0. Le modifiche sottostanti toccano anche storage locale degli eventi, gestione del signer e plumbing delle notifiche Android. Questa è la seconda applicazione attiva dell’organizzazione Formstr dopo la migrazione del repository dello scorso mese.

Mostro v0.16.4

Mostro, exchange Bitcoin peer-to-peer costruito su Nostr, ha rilasciato la v0.16.4. Le correzioni per il ripristino delle sessioni di disputa (PR #599) e la chiusura automatica (PR #606), coperte la settimana scorsa, sono incluse. Nuove in questa release: PR #625 aggiunge un campo days agli event di rating utente di kind 38384, PR #612 aggiunge la scadenza a quegli event di rating, e PR #614 sposta gli event ordine verso le impostazioni di scadenza configurate invece di una finestra hardcoded di 24 ore. PR #622 aggiunge un controllo di idempotenza per evitare pagamenti duplicati delle dev fee.

Mostro Mobile v1.2.1

Mostro Mobile, client Flutter per l’exchange P2P Mostro, ha distribuito la v1.2.1 con 11 nuove funzionalità e 11 bug fix. La release aggiunge il rendering di contenuti multimediali cifrati nella chat di disputa (PR #514), la chiusura automatica della UI delle dispute quando gli ordini raggiungono uno stato terminale (PR #503), la scansione QR per importare wallet NWC (commit 12eaee4), traduzioni francesi e gestione delle notifiche push FCM. PR #496 corregge un bug di padding delle firme Schnorr bloccando la dipendenza bip340 alla v0.2.0.

0xchat v1.5.4

0xchat, client di messaggistica in stile Telegram con supporto Cashu, ha distribuito la v1.5.4 focalizzata sulle correzioni per Linux desktop: icone AppImage nel dock, rendering delle emoji, freeze nei menu contestuali e blocchi della UI per reply/copy. La release corregge anche i problemi di upload delle immagini e l’integrazione npub.cash. PR #49 elimina rebuild UI non necessari rimuovendo un timer di polling da 3 secondi che forzava repaint glassmorphic senza fare nulla, e sblocca l’inizializzazione del login eseguendo il caricamento della cache event in parallelo invece di bloccare l’avvio di relay, contatti e canali.

Keep v0.6.0

Keep, signer threshold FROST per Android con supporto NIP-55 e NIP-46, ha distribuito v0.6.0 e v0.6.1. La v0.6.0 aggiunge coordinamento dei wallet descriptor e relativa UI di gestione, un flusso backup/restore con autenticazione biometrica (PR #184), recupero nsec da threshold share (PR #187), generazione cross-platform di frame QR animati tramite Rust UniFFI (PR #188) e un audit trail della firma con verifica della chain (PR #189). La v0.6.1 cambia la licenza da AGPL-3.0 a MIT (PR #191).

njump v0.3.0

njump, gateway statico per visualizzare contenuti Nostr su njump.me, ha distribuito la v0.3.0 con una modifica incompatibile nel parsing dei codici note1 e un aggiornamento della libreria nostr sottostante.

Roadstr v0.1.1

Roadstr, applicazione decentralizzata per segnalare eventi stradali usando Nostr, ha distribuito la sua prima demo v0.1.1. L’app mostra gli eventi stradali su una mappa usando vector tile da openfreemap.org.

Bitcredit v0.5.3

Bitcredit, applicazione di e-bill con transport layer Nostr e relay dedicato su bit.cr, ha distribuito la v0.5.3. PR #846 aggiunge i campi payment_actions e bill_state all’API per stato dei pagamenti e dell’accettazione, e PR #849 corregge la gestione dell’indirizzo di firma per signer anonimi.

OpenChat v0.1.0-alpha.3

OpenChat, applicazione chat costruita sulle librerie .NET MLS e C# del protocollo Marmot, ha distribuito la v0.1.0-alpha.3. La release aggiunge supporto a signer esterni per Amber e flussi NIP-46 (commit e568d97), sposta la persistenza dello stato MLS dentro il servizio MLS per eliminare la perdita di dati nella finestra di crash (commit 4720bc8), e pubblica build Windows, Linux e Android attraverso una nuova pipeline CI.

OpenSignal v1.0.0

OpenSignal, trading copilot Kotlin Multiplatform per Nostr, ha distribuito la v1.0.0. La release include moduli KMP condivisi per logica di dominio, rendering dei grafici, autenticazione e pubblicazione Nostr, supporto upload Blossom NIP-96 e hook di inferenza AI basati su ONNX su shell Desktop e Android. L’architettura pubblicata include anche un servizio AI FastAPI per l’analisi di screenshot dei grafici, pipeline di training dei modelli e un motore di rischio che produce piani di trading strutturati con sizing e warning. Il login supporta chiavi nsec grezze oppure signer esterni, e il flusso di output termina con la pubblicazione di event Nostr invece che con un’analisi solo locale.

Aggiornamenti Progetto

Formstr

Formstr, l’alternativa a Google Forms su Nostr, ha unito PR #434 (commit e9c4fd5), aggiungendo un flusso di registrazione che usa chiavi private cifrate NIP-49. Prima di questa modifica, gli utenti avevano bisogno di un’estensione browser NIP-07 oppure di incollare una nsec grezza per usare Formstr. Il nuovo flusso genera una coppia di chiavi lato client, cifra la chiave privata con una password scelta dall’utente tramite lo schema scrypt + XChaCha20-Poly1305 di NIP-49, e memorizza la stringa ncryptsec risultante. Gli utenti possono quindi accedere di nuovo con la propria password senza installare un’estensione signer. La gestione delle chiavi resta interamente lato client.

Amethyst

Amethyst, il client Android ricco di funzionalità, ha unito quattro PR che distribuiscono il lavoro di risoluzione NIP-05 supportato da Namecoin che era aperto la settimana scorsa. PR #1734 aggiunge una verifica NIP-05 resistente alla censura via ElectrumX per identificatori .bit, d/ e id/. Quando Amethyst rileva uno di questi suffissi in un campo NIP-05, interroga un server ElectrumX-NMC per la cronologia delle transazioni del nome, analizza lo script NAME_UPDATE dall’ultimo output per estrarre la pubkey Nostr e rifiuta i nomi più vecchi di 36.000 blocchi, la finestra di scadenza di Namecoin. Le connessioni ElectrumX passano attraverso SOCKS5 quando Tor è attivo, con selezione dinamica del server tra endpoint clearnet e .onion. Una cache LRU con TTL di un’ora evita interrogazioni ripetute della blockchain.

PR #1771 corregge race condition e accuratezza del resolver in quel flusso. PR #1785 permette ai nuovi utenti di importare una follow list durante la registrazione sia da normali identificatori NIP-05 sia da quelli supportati da Namecoin. PR #1786 aggiunge impostazioni personalizzate per il server ElectrumX così gli utenti possono scegliere quale server gestirà i loro lookup.

nostr-idb

nostr-idb, libreria che fornisce metodi helper per memorizzare event Nostr in IndexedDB, ha unito PR #6 aggiungendo il supporto ai filtri tag AND di NIP-91. La modifica aggiunge semantica di intersezione al matching lato client dei filtri, così le query IndexedDB possono richiedere tutti i valori tag elencati invece di uno qualsiasi. PR #8 aggiorna la libreria all’ultima interfaccia NIP-DB, e un successivo commit b49b3d3 corregge un deadlock di subscribe e rimuove nostr-tools come dipendenza di produzione.

Pensieve

Pensieve, indicizzatore Nostr archive-first con analytics ClickHouse, ha unito PR #8 aggiungendo enforcement del TTL della cache per entry e coalescing dei miss per chiave, così da ridurre i picchi di CPU API. Gli endpoint time-series più costosi, statistiche di engagement, attività oraria e attività per kind, usano ora TTL server-side di 10 minuti invece di innescare tempeste di ricalcolo sincronizzate.

Blossom

Blossom, protocollo e stack server per l’hosting media decentralizzato, ha unito due aggiornamenti di autorizzazione BUD-11. PR #91 sposta l’autorizzazione opzionale in un BUD dedicato e chiarisce il ruolo dei tag x e server. PR #93 ripulisce il comportamento auth specifico per endpoint e formalizza l’header X-SHA-256 per la verifica degli upload. Le due PR consolidano la logica auth in BUD-11 e rimuovono ambiguità sull’hashing delle richieste nei flussi di upload, delete e media management.

Aggiornamenti NIP

Cambiamenti recenti nel repository NIPs:

Uniti:

NIP-91 (AND Operator for Filters) (PR #1365): aggiunge semantica di intersezione per i filtri tag, permettendo ai relay di rispondere a query che richiedono tutti i valori tag elencati invece di uno qualsiasi. Riduce il post-filtering lato client e la larghezza di banda nelle query ricche di tag.
NIP-66 (Relay Discovery and Liveness Monitoring): misure difensive (PR #2240): dopo il lavoro di benchmark outbox coperto la settimana scorsa, la specifica aggiunge ora avvertimenti sui percorsi sfavorevoli dei dati di monitoraggio relay. I client non devono richiedere event di monitoraggio kind 30166 per funzionare. Un monitor può essere errato, obsoleto o malevolo. Ci si aspetta che i client incrocino le fonti ed evitino di tagliare ampie parti del grafo relay di un utente basandosi su un singolo feed.
NIP-39 (External Identities in Profiles): pulizia del registry kind 10011 (PR #2256): aggiunge il riferimento al kind 10011 direttamente nella specifica, allineandosi con l’implementazione di Amethyst coperta la settimana scorsa.

PR aperte e discussioni:

NIP-70 (Protected Events): rifiutare i repost che incorporano event protetti (PR #2251): se un relay applica NIP-70 all’event originale ma accetta repost che trasportano lo stesso contenuto, il tag - non ha effetto pratico. Questa PR aggiunge la regola per cui i relay devono rifiutare anche i repost di kind 6 e kind 16 degli event protetti. strfry PR #176 lo implementa già.
NIP-71 (Video Events): tracce audio multiple (PR #2255): aggiunge tag audio imeta per tracce alternative, varianti linguistiche e stream solo audio. Un client potrebbe mantenere stabile il file video cambiando lingua audio, oppure servire l’audio come traccia separata per contenuti tipo podcast.
NIP-11 (Relay Information Document) e attributi relay di NIP-66 (PR #2257): aggiunge un campo attributes strutturato ai relay information document, fornendo a client e strumenti di discovery metadati machine-readable oltre l’attuale descrizione a testo libero.

NIP Deep Dive: NIP-49 (Cifratura della chiave privata)

NIP-49 definisce come un client cifra una chiave privata con una password e codifica il risultato come stringa bech32 ncryptsec. Formstr usa NIP-49 nel suo nuovo flusso di registrazione.

Il formato non è legato a un kind di event dedicato. Un client parte dalla chiave privata secp256k1 grezza a 32 byte, deriva una chiave simmetrica dalla password dell’utente con scrypt, cifra la chiave usando XChaCha20-Poly1305, poi incapsula il risultato in una stringa bech32 ncryptsec. Un flag di un byte registra se la chiave è mai stata gestita in modo insicuro prima della cifratura.

{
 "id": "4d47f4f0a6f6edbc1bbd7f4e2a45ec68f27cba91d6c6ab5cf28d8d87b0f3d57e",
 "pubkey": "1f8b4c3e7b0f9451d4f9b8a7c6e5d4c3b2a1908f7e6d5c4b3a29181716151413",
 "created_at": 1741699200,
 "kind": 30078,
 "tags": [
 ["d", "encrypted-key-backup"],
 ["format", "ncryptsec"],
 ["encryption", "nip49"]
 ],
 "content": "ncryptsec1qgg9947rlpvqu76pj5ecreduf9jxhselq2nae2kghhvd5g7dgjtcxfqtd67p9m0w57lspw8gsq6yphnm8623nsl8xn9j4jdzz84zm3frztj3z7s35vpzmqf6ksu8r89qk5z2zxfmu5gv8th8wclt0h4p",
 "sig": "6a8f6e4b2d1901735f0ad4b6e8c1f3a579d0e2b4c6f8a1d3e5f7091b2c3d4e5f11223344556677889900aabbccddeeff00112233445566778899aabbccddeeff"
}

L’event JSON sopra è un esempio a livello applicativo, non un requisito NIP-49. Il NIP standardizza il formato della chiave cifrata. Un client può memorizzare ncryptsec localmente, sincronizzarlo tramite storage specifico dell’app o esportarlo come stringa di backup. Le password sono normalizzate in Unicode NFKC prima della derivazione della chiave, così la stessa password può decifrare in modo coerente tra client e piattaforme.

Il flag di sicurezza della chiave a un byte ha tre valori definiti: 0x00 significa che la cronologia di gestione della chiave è sconosciuta, 0x01 significa che la chiave è nota per essere stata gestita in modo insicuro, per esempio incollata in chiaro in un form web prima della cifratura, e 0x02 significa che la chiave è stata generata e cifrata in un contesto sicuro e non è mai stata esposta. I client possono usare questa informazione per mostrare avvisi quando importano chiavi con una storia nota di gestione insicura.

NIP-49 protegge le chiavi meglio dell’esportazione semplice nsec, ma la cifratura è forte solo quanto la password e il costo scrypt configurato. Valori LOG_N più alti rendono l’attacco offline più difficile ma rallentano anche la decifratura legittima. La specifica sconsiglia di pubblicare chiavi cifrate su relay pubblici, perché gli attaccanti traggono vantaggio dal raccogliere ciphertext da sottoporre a cracking offline. Per confronto, la firma remota di NIP-46 evita di esporre del tutto le chiavi, e la firma Android di NIP-55 le mantiene all’interno di un’app signer dedicata. NIP-49 occupa uno spazio diverso: backup cifrato portabile per utenti che gestiscono le proprie chiavi.

Le implementazioni includono Formstr PR #434 per la registrazione, Amber per backup e restore ncryptsec, diVine v1.0.6 per l’import account, Keep v0.6.0 per l’esportazione di share FROST, e strumenti di gestione delle chiavi come nsec.app e Alby.

NIP Deep Dive: NIP-70 (Event protetti)

NIP-70 definisce gli event protetti. Quando un event porta il tag ["-"], un relay deve rifiutarlo a meno che il relay richieda l’autenticazione NIP-42 e la pubkey autenticata corrisponda all’autore dell’event.

Il flusso auth di NIP-42 funziona così: il relay invia una challenge AUTH contenente una stringa casuale, e il client risponde con un event signed di kind 22242 i cui tag includono l’URL del relay e la challenge. Il relay verifica la firma e controlla che la pubkey nell’event auth coincida con la pubkey dell’event protetto in pubblicazione. Se le pubkey non coincidono, il relay rifiuta l’event con il prefisso di messaggio restricted.

Il contenuto dell’event può comunque essere pubblico. Il tag - controlla solo chi può pubblicare l’event su un relay che onora il tag. Questo copre feed semi-chiusi di NIP-29, spazi relay riservati ai membri e altri contesti in cui l’autore vuole limitare la ridistribuzione attraverso il grafo relay. NIP-70 è una convenzione a tag singolo, non un nuovo kind di event, quindi qualunque kind esistente può portare il tag -.

{
 "id": "cb8feca582979d91fe90455867b34dbf4d65e4b86e86b3c68c368ca9f9eef6f2",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1707409439,
 "kind": 1,
 "tags": [
 ["-"]
 ],
 "content": "hello members of the secret group",
 "sig": "fa163f5cfb75d77d9b6269011872ee22b34fb48d23251e9879bb1e4ccbdd8aaaf4b6dc5f5084a65ef42c52fbcde8f3178bac3ba207de827ec513a6aa39fa684c"
}

Anche se un relay blocca la pubblicazione di terzi dell’event originale, qualcuno può ripubblicarne il contenuto dentro un repost. PR #2251 affronta il problema richiedendo ai relay di rifiutare anche i repost di kind 6 e kind 16 degli event protetti. strfry PR #156 aggiunge la gestione auth NIP-42 per gli event protetti, e strfry PR #176 blocca i repost che incorporano contenuto protetto.

NIP-70 controlla il comportamento del relay. Un destinatario può comunque copiare altrove il contenuto, e la specifica lo dice esplicitamente. Il tag - fornisce ai relay un segnale machine-readable per rifiutare la ripubblicazione. Per confronto, NIP-62 chiede ai relay di cancellare i dati dopo il fatto, mentre NIP-70 impedisce la pubblicazione non autorizzata al momento dell’ingest. I due approcci sono complementari: un autore può contrassegnare gli event come protetti per limitarne la diffusione, e in seguito chiedere la cancellazione se desidera che il contenuto venga rimosso dai relay che lo avevano accettato.

Per questa settimana è tutto. State costruendo qualcosa o avete novità da condividere? Contattateci via DM NIP-17 o cercateci su Nostr.

Nostr Compass #12

Wed, 04 Mar 2026 00:00:00 +0000

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

Questa settimana: Il Marmot Development Kit distribuisce il suo primo rilascio pubblico con media cifrati e binding multi-linguaggio. Nostrability pubblica benchmark del modello outbox su 14 algoritmi di selezione dei relay. Wisp passa dalla prima alpha alla beta in otto giorni con Tor e firma NIP-55 (Applicazione Signer Android). NIP-91 (filtri AND) viene unito. Vector v0.3.1 porta la sincronizzazione negentropy con miglioramenti delle prestazioni di 15 volte. Questo numero include anche la retrospettiva Cinque Anni di Febbraio di Nostr, che traccia il protocollo da una riscrittura della specifica che serviva tre relay fino all’esplosione di Damus sull’App Store, passando per le reti mesh e le proposte per agenti AI.

Notizie

Il Modello Outbox Sotto la Lente

Nostrability ha pubblicato una serie di benchmark sul modello outbox che testano quanto bene diversi algoritmi di selezione dei relay recuperano event dalla rete relay decentralizzata. Il progetto ha unito 16 PR e 76 commit in dieci giorni, producendo quella che potrebbe essere l’analisi empirica più approfondita delle strategie di implementazione di NIP-65 (Relay List Metadata) fino ad oggi.

I benchmark testano 14 algoritmi di selezione dei relay rispetto a liste di follow reali su 15 client e librerie in cinque linguaggi. Un approccio baseline di interrogazione dei soli relay popolari recupera circa il 26% degli event. Il greedy set-cover con Thompson Sampling raggiunge l'80-90% di richiamo. L’aggiunta di una variante sensibile alla latenza che usa lo sconto iperbolico e il tracciamento della latenza dei relay con EWMA ha portato la completezza dal 62-80% al 72-96% al segno dei 2 secondi su sei profili di test.

Il filtraggio dei relay inattivi tramite NIP-66 (Relay Monitoring) si è rivelato significativo. Il pre-filtraggio dei candidati relay rispetto ai dati di liveness di nostr.watch ha rimosso il 40-64% dei relay inattivi e raddoppiato i tassi di successo dei relay dal 30% al 75-85%. I tempi di caricamento dei feed sono diminuiti del 39% (da 40 secondi a 24 secondi su 10 profili). Una simulazione EOSE-race ha rilevato che attendere l’EOSE più un periodo di grazia di 200ms migliorava la completezza rispetto all’arresto al primo relay che terminava.

Per i client che non possono riscrivere completamente il proprio routing dei relay, un approccio di “arricchimento outbox ibrido” aggiunge query outbox per autore sopra i relay applicativi hardcoded esistenti. Questo approccio ibrido ha raggiunto l'80% di richiamo degli event su un anno rispetto al 26% del baseline, offrendo un percorso di migrazione per i client con architetture relay legacy.

ContextVM Apre il NIP per MCP e Distribuisce Gift Wrap Effimeri

ContextVM, il protocollo che collega Nostr con il Model Context Protocol, ha aperto due proposte nel repository NIPs questa settimana. La PR #2246 formalizza CVM come convenzione per il trasporto di messaggi MCP JSON-RPC su Nostr tramite event effimeri di kind 25910. La PR #2245 estende NIP-59 (Gift Wrap) con un kind effimero (21059) che segue la semantica effimera di NIP-01 (Flusso Base del Protocollo), permettendo ai relay di scartare i messaggi avvolti dopo la consegna.

La convenzione gift wrap effimera è stata distribuita come CEP-19 nella famiglia di rilasci ContextVM SDK v0.6.x. L’implementazione SDK aggiunge un enum GiftWrapMode con tre impostazioni: OPTIONAL (accetta entrambi i kind e rileva automaticamente la capacità del peer), EPHEMERAL (solo kind 21059) e PERSISTENT (solo kind 1059). Per le chiamate agli strumenti AI, la modalità effimera evita di memorizzare il traffico intermedio di richiesta-risposta sui relay, riducendo sia i costi di storage che l’esposizione della privacy.

Nuovi server MCP pubblici sono apparsi sulla rete da operatori indipendenti, incluso un server di query Wolfram Alpha. Il team ContextVM ha pubblicato CEP-15 (schema degli strumenti comuni) e CEP-17 (pubblicazione della lista relay del server) insieme al ciclo di rilascio v0.6.x.

Marmot Development Kit Distribuisce il Primo Rilascio Pubblico

MDK (Marmot Development Kit), la libreria Rust che alimenta la messaggistica cifrata con Marmot su Pika e White Noise, ha distribuito la v0.6.0 come primo rilascio pubblico. Oltre 200 PR sono state unite in questa versione, con sei nuovi contributor.

Il rilascio include il supporto ai media cifrati (MIP-04) con derivazione del seed HKDF (MIP-01 v2), risoluzione deterministica delle race condition dei commit (MIP-03), storage locale cifrato, validazione dell’autorizzazione admin per i commit e le proposte Marmot, e supporto GREASE per l’estensibilità del protocollo. I binding sono disponibili per Kotlin, Python, Ruby e Windows insieme alla cross-compilazione Android. La libreria si aggiorna a OpenMLS 0.8.0 con correzioni degli avvisi di sicurezza e un tipo Secret<T> che azzera i valori sensibili in memoria.

Una modifica companion al protocollo (MIP-03) ha sostituito la cifratura NIP-44 (Encrypted Payloads) con ChaCha20-Poly1305 per i messaggi di kind 445. NIP-44 richiedeva input di stringhe UTF-8 per specifica, rendendo impossibile passare i byte grezzi dei messaggi Marmot attraverso le librerie Nostr TypeScript standard. La sostituzione deriva le chiavi direttamente dal segreto esportatore Marmot. Questa modifica incompatibile ha richiesto aggiornamenti coordinati tra la specifica core, MDK e l’SDK TypeScript.

marmot-ts, l’implementazione TypeScript mantenuta da hzrd149, ha unito quattro PR con modifiche incompatibili alle API a loro volta. Un aggiornamento omnibus ha aggiunto un gestore di key package per il ciclo di vita create/publish/rotate, un metodo di convenienza sendChatMessage, anteprima degli inviti senza entrare nel gruppo (readInviteGroupInfo), auto-aggiornamento per le rotazioni di forward-secrecy e logging di debug strutturato. Le API di decifratura dei gruppi sono state rinominate da readGroupMessage a decryptGroupMessage con varianti di risultato più ricche (processed/skipped/rejected/unreadable). gzuuus ha contribuito alla pulizia degli esempi con supporto relay NIP-65 e gestione dei key package di ultima risorsa secondo MIP-00.

La White Noise CLI (wn), il backend Rust che alimenta sia l’app mobile che la nuova TUI, ha unito 16 PR in dieci giorni. La gestione del ciclo di vita del signer ha ottenuto la sicurezza in caso di cancellazione attraverso un RAII scope guard (PR #538), correggendo una classe di bug in cui le operazioni interrotte potevano far trapelare lo stato del signer. Il login ora blocca quando le liste relay richieste (kind 10002/10050/10051) sono mancanti (PR #515), e le sottoscrizioni giftwrap ricadono sui relay NIP-65 quando le liste inbox sono assenti (PR #518). Una modalità debug (PR #528) espone le query al database e l’ispezione del ratchet-tree MLS come output JSON. Altre correzioni hanno risolto il recupero delle sottoscrizioni dopo la ri-registrazione del signer, la sincronizzazione dei messaggi di benvenuto, la validazione dei filtri relay e i limiti del raggio di ricerca utenti.

Marmot ha visto un’espansione significativa oltre lo stack Rust core questa settimana. White Noise TUI, un’interfaccia basata su terminale per lo stack di messaggistica White Noise, è stata lanciata il 3 marzo. Avvolge la CLI wn come sottoprocesso e renderizza il suo output JSON attraverso un’architettura unidirezionale ispirata a Elm, fornendo navigazione multi-conversazione con indicatori di non letto, creazione di gruppi e ricerca membri, streaming di messaggi in tempo reale e reazioni emoji dal terminale.

DavidGershony ha pubblicato uno stack Marmot completo in C# che rispecchia l’architettura a livelli del toolchain Rust. dotnet-mls implementa le primitive crittografiche MLS RFC 9420 in C#. marmot-cs si basa su di esso per aggiungere il trasporto relay Nostr, funzionando come equivalente C# di MDK. OpenChat, un’app desktop cross-platform costruita con .NET 9 e Avalonia UI, unisce entrambi in un client di chat funzionante con DM NIP-44, cifratura di gruppo Marmot, firma remota NIP-46 (Nostr Connect) e indicatori di stato multi-relay.

MDK PWA Reference fornisce un template Progressive Web App per costruire applicazioni cifrate con Marmot, con supporto sperimentale alla partecipazione di agenti AI nelle chat di gruppo e pagamenti Bitcoin tramite infrastruttura wallet Arkade.

Wisp Passa dall’Alpha alla Beta

Wisp è un nuovo client Nostr Android che è passato dalla prima alpha il 24 febbraio alla v0.3.4-beta il 3 marzo, producendo 19 rilasci, 115 PR unite e 276 commit in otto giorni.

La traiettoria delle funzionalità copre terreno che la maggior parte dei client impiega mesi a raggiungere. La v0.1.0 è stata distribuita con il supporto al modello relay outbox/inbox e flussi di onboarding. Alla v0.1.3, il client disponeva della firma intent-based NIP-55 per Amber, un proxy Tor SOCKS5 integrato per la connettività ai relay .onion, e NIP-47 (Nostr Wallet Connect). La v0.2.0 è passata alla beta con il filtraggio delle liste mute e il supporto emoji personalizzate, mentre la v0.2.4 ha aggiunto gli overlay per gli avvisi di contenuto. La serie v0.3.x ha introdotto la proof-of-work NIP-13 per le note, il mining PoW in background con impostazioni persistenti, lo storage dei relay .onion e le notifiche thread silenziati.

La traduzione on-device tramite Google ML Kit funziona localmente senza accesso alla rete dopo il download iniziale del modello. Una visualizzazione interattiva del grafo sociale usa una simulazione fisica velocity Verlet a circa 30fps con navigazione pinch-to-zoom e ispezione dei profili.

Rilasci

Vector v0.3.1

Vector, l’app di messaggistica cifrata con Marmot, ha distribuito la v0.3.1 con miglioramenti alla gestione dei gruppi e lavoro sulle prestazioni. Gruppi multi-admin, inviti in blocco, invito tramite npub e avatar di gruppo espandono le funzionalità di collaborazione. Le notifiche in background Android ora supportano le azioni inline Reply e Mark Read.

La sincronizzazione deterministica basata su Negentropy recupera la cronologia completa delle conversazioni inclusi i messaggi persi durante i periodi offline. Voice-to-text ricostruito con accelerazione GPU su Android. La gestione degli allegati è stata revisionata con progresso di download, stati di retry, compressione zip-and-send delle directory e indicatori di progresso in tempo reale. Le prestazioni sono migliorate di oltre 15 volte su tempo di avvio, elaborazione immagini, riproduzione audio e reattività generale della UI. Le dimensioni dell’installazione dell’app sono diminuite di oltre un terzo, con il frontend ridotto di circa la metà. È stato aggiunto il supporto Android ARM a 32 bit.

Alby Hub v1.21.5

Alby Hub, il nodo Lightning auto-custodiale con supporto Nostr Wallet Connect (NIP-47), ha distribuito la v1.21.5. Un secondo relay è stato aggiunto alla configurazione NWC predefinita, migliorando l’affidabilità durante i riavvii dei relay. Una correzione per i dati zap non validi nella lista transazioni risolve un problema di visualizzazione con event NIP-57 (Lightning Zaps) malformati. Le nuove voci dell’app store includono Alby CLI e LNVPS.

nospeak v0.12.x

nospeak, il client di messaggistica Nostr basato su testo, ha distribuito tre rilasci nel periodo. La v0.12.0 ha aggiunto il blocco app con PIN a tastierino a 4 cifre e oltre 15 nuove traduzioni linguistiche inclusi bengalese, tailandese, vietnamita, hindi, arabo, ebraico, urdu, turco, giapponese, cinese, coreano, olandese, polacco, russo e persiano con supporto RTL. La v0.12.1 ha introdotto un tema Cypher con sfondi neri puri e accenti ciano, più la generazione di poster video Android. La v0.12.2 ha aggiunto l’esportazione chat e View Profile nei menù dei contatti.

Citrine v2.0.0-pre2

Citrine, il relay personale Android di greenart7c3, ha distribuito la v2.0.0-pre2 con miglioramenti delle prestazioni del relay attraverso nuovi indici del database e coroutine Kotlin ristrutturate. Ogni web app ospitata ora si avvia sulla propria porta. La ricerca full-text e una schermata event riprogettata con espansione degli event completano le modifiche.

NoorNote v0.5.x

NoorNote, un’applicazione per prendere appunti basata su Nostr, ha distribuito 8 rilasci dalla v0.5.0 alla v0.5.7. Il lancio della v0.5.0 su Android ha aggiunto il supporto al signer Amber NIP-55 e la pubblicazione di note NIP-71 (Video Events). Una pagina di benvenuto riprogettata nella v0.5.1 includeva anteprime della timeline pubblica e ha ridotto l’APK a 15 MB. Il Relay Browser nella v0.5.2 permette agli utenti di navigare le timeline pubbliche dei relay tramite URL condivisibili, insieme al download dei media e alle reazioni emoji personalizzate NIP-30. I rilasci successivi fino alla v0.5.7 hanno risolto race condition di sincronizzazione nel sistema collaborativo di condivisione note “tribes”.

NosCall v0.5.1

NosCall, l’app per chiamate vocali e video su Nostr, ha distribuito la v0.5.1 con supporto ai messaggi vocali, un’esperienza desktop ottimizzata con accesso ai gruppi, contatti preferiti su desktop, note e filtraggio dei contatti, opzioni di esportazione e pulizia dei dati, e supporto all’accessibilità per le dimensioni dei font di sistema.

Shosho v0.13.0

Shosho, l’app di live streaming su Nostr, ha distribuito la v0.13.0 con download di replay MP4 dai menù delle card dello streaming e NIP-05 (DNS-Based Verification) per i profili. Il publisher RTMP è migrato all’Expo Modules API. Le prestazioni di streaming su connessioni a bassa larghezza di banda sono migliorate, e i crash sui dispositivi più vecchi e lo streaming iOS verso Zap.Stream sono corretti.

nostr-java v2.0.0

nostr-java ha distribuito la v2.0.0 con dimensioni configurabili del buffer WebSocket, permettendo alle applicazioni di gestire event Nostr più grandi senza troncamento. L’incremento della versione major riflette modifiche incompatibili all’API di connessione.

Prism 1.1.0

Prism ha distribuito la 1.1.0 con supporto ai contenuti long-form (articoli kind 30023) e un editor Markdown per la composizione direttamente nell’app, seguita da un rilascio bug fix 1.1.1.

Angor v0.2.6

Angor, la piattaforma di crowdfunding Bitcoin, ha distribuito la v0.2.6 con integrazione Boltz e un flusso di investimento in 1 click. Sia i tipi invest che fund project funzionano end-to-end su testnet. Il team nota che la UI è completa circa al 70%.

Aggiornamenti NIP

Modifiche recenti al repository NIPs:

Uniti:

NIP-91: Operatore AND per i Filtri: Aggiunge la semantica dei filtri AND per gli array di tag nelle sottoscrizioni ai relay. Attualmente, specificare valori multipli in un filtro di tag (ad esempio, tag p multipli) corrisponde agli event che contengono uno qualsiasi di essi. NIP-91 permette ai client di richiedere event che corrispondono a tutti i valori di tag specificati simultaneamente, riducendo la larghezza di banda e abilitando operazioni di indice più veloci. Esistono già implementazioni in più relay inclusi nostr-rs-relay, satellite-node, worker-relay e applesauce. Precedentemente numerato NIP-119.
NIP-30: Indirizzo del Set di Emoji nei Tag: I tag emoji personalizzate in NIP-30 possono ora includere un indirizzo opzionale del set di emoji. Cliccando su un’emoji in un client si può aprire il set a cui appartiene per aggiungerlo ai segnalibri o navigarlo. Originato dal client Chachi.
NIP-29: Aggiunta di unallowpubkey e unbanpubkey: Due nuovi comandi admin per le chat di gruppo NIP-29. unallowpubkey rimuove una pubkey dalla lista consentiti senza bannare l’utente. unbanpubkey revoca un ban senza ri-aggiungere la pubkey alla lista dei membri. In precedenza, l’unico modo per rimuovere qualcuno dalla lista consentiti comportava anche il ban, e revocare il ban richiedeva di ri-aggiungere l’utente come membro.

PR Aperte e Discussioni:

NIP-A7: Spells (aperta il 27 feb): Proposti da purrgrammer, gli spell sono query Nostr salvate e portabili pubblicati come event di kind 777. Uno spell codifica un filtro REQ o COUNT in tag strutturati (k per i kind, authors per le pubkey, tag per filtri di tag arbitrari) con variabili runtime: $me si risolve alla pubkey dell’utente loggato, $contacts si espande alla lista di follow di kind 3 dell’utente. I timestamp relativi (7d, 2w, 1mo) permettono agli spell di definire finestre temporali mobili senza date hardcoded. Già implementati in nak e Grimoire, gli spell permettono agli utenti di creare, condividere e sottoscrivere feed curati che si spostano tra i client.
NIP-59: Gift Wrap Effimero (kind 21059) (aperta il 27 feb): Aggiunge una variante effimera dei gift wrap NIP-59. Il kind 21059 segue la semantica effimera di NIP-01, quindi i relay scartano gli event dopo la consegna. Proposto da ContextVM per il trasporto MCP dove la persistenza dei messaggi non è necessaria.
ContextVM: MCP JSON-RPC su Nostr (aperta il 27 feb): Specifica come trasportare i messaggi del Model Context Protocol su Nostr usando event effimeri di kind 25910 con tag p ed e per l’indirizzamento e la correlazione. Intenzionalmente snello, rimanda i dettagli del protocollo alla specifica ContextVM.
NIP-29: Spazi Live Audio/Video (aperta il 25 feb, bozza): Bozza di fiatjaf che estende i gruppi NIP-29 con audio e video live. La proposta aggiunge tag opzionali livekit e no-text agli event di metadata dei gruppi. Quando un utente vuole unirsi a uno spazio vocale, il client richiede un JWT dal relay su /.well-known/nip29/livekit/{groupId}. Il relay verifica l’appartenenza al gruppo ed emette un token con la pubkey hex dell’utente come claim sub, che viene passato a LiveKit per il trasporto dei media. L’accesso alla stanza vocale eredita il modello di permessi esistente del gruppo, quindi le regole di appartenenza lato relay governano chi può parlare. In fase di test in Pyramid e Chachi.
Proprietà Collaborativa degli Event (aperta il 24 feb): pablof7z propone un event puntatore (kind 39382) che dichiara uno spazio collaborativo elencando le pubkey dei co-proprietari nei tag p e un kind di event target in un tag k. Qualsiasi proprietario elencato può pubblicare event di quel kind con lo stesso tag d, e i client risolvono lo stato corrente interrogando tutti i proprietari e prendendo l’event più recente. L’attribuzione di co-autorialità viene visualizzata solo quando un tag a verificabile referenzia il puntatore e l’autore appare nei suoi tag p, prevenendo rivendicazioni falsificate. Questo abilita pagine wiki condivise e risorse co-autoriate senza assegnare il controllo a un singolo keypair.
NIP-09: Cancellazione a Cascata dei Repost (aperta il 24 feb): Quando un autore originale cancella una nota, i relay dovrebbero anche cancellare qualsiasi repost di kind 6 o kind 16 che la referenzia. Motivato da preoccupazioni sulla privacy: i repost possono preservare informazioni trapelate accidentalmente dopo che l’autore ha cancellato la fonte. La modifica è solo lato relay e non richiede modifiche ai client.
NIP-07: peekPublicKey (aperta il 23 feb): Aggiunge un metodo peekPublicKey() alle estensioni browser NIP-07. A differenza di getPublicKey(), restituisce la pubkey corrente senza richiedere conferma all’utente, abilitando il login automatico silenzioso quando l’utente ha abilitato l’auto-login.
NIP-BB: Book (aperta il 28 feb, bozza): Definisce quattro kind di event indirizzabili (30300-30303) per la pubblicazione strutturata di libri su Nostr. Un event Cover contiene i metadata root inclusi titolo, immagine di copertina, licenza tramite label NIP-32 (Labeling) e codice lingua. Un event Index mappa ogni capitolo alla sua posizione usando indicizzazione frazionaria base62, che permette agli autori di inserire nuovi capitoli tra quelli esistenti senza rinumerazione. Gli event Chapter funzionano come intestazioni strutturali con immagini opzionali, mentre gli event Episode trasportano la prosa effettiva con un limite di 30.000 caratteri e tag immagine posizionati. Le recensioni usano gli Zap sugli event Cover con la descrizione dello Zap come testo della recensione.
NIP-54: Passaggio da Asciidoc a Djot (aperta il 26 feb): In seguito alla correzione dell’internazionalizzazione del d-tag di dicembre, questa PR propone di sostituire il formato markup Asciidoc del wiki NIP-54 con Djot, aggiungendo una sezione di motivazioni ed esempi di wikilink per script non latini.
NIP-66: Misure Difensive (aperta il 26 feb): Basato sugli apprendimenti dai benchmark nostrability/outbox, aggiunge segnalazioni esplicite per i casi limite di NIP-66. Una PR #2241 companion definisce tag di output per SSL, geolocalizzazione, rete e controlli di connettività.
NIP-C1: Prove di Identità Crittografica (voce wiki, kind 30817): Propone event di kind 30509 che collegano crittograficamente i certificati di firma APK ai profili Nostr. La prova funziona firmando un messaggio canonico contenente la pubkey Nostr con la chiave privata del certificato (supportando ECDSA, RSA PKCS1v15, Ed25519 e altri algoritmi standard), poi pubblicando la firma in un event di kind 30509 firmato con la chiave Nostr. I verificatori possono confermare che la persona che controlla il certificato di firma di un’app Android controlla anche la pubkey Nostr che dichiara di pubblicarla. Le prove scadono dopo un anno per impostazione predefinita e possono essere revocate esplicitamente. Implementato nel toolchain Zapstore.
NIP-31402: SARA Revenue Share Offering Registry (voce wiki, kind 30817): Definisce event indirizzabili di kind 31402 per la pubblicazione di offerte Simple Autonomous Revenue Agreement (SARA) sui relay Nostr. Gli emittenti pubblicizzano termini di condivisione dei ricavi regolati via Lightning inclusi percentuale della quota pool, trigger di pagamento, soglia in sats, durata del termine e prezzi a livelli. Agenti e umani possono scoprire le offerte sui relay e sottoscriverle autonomamente senza una piattaforma centrale. Il numero di kind rispecchia il kind 30402 (L402 Service Registry, pubblicato dallo stesso autore come voce wiki companion) poiché SARA rappresenta la gamba di ritorno della relazione di pagamento L402.

PR Aperte e Aggiornamenti dei Progetti

Damus: NIP-89 (Recommended Application Handlers)

La PR #3337 implementa il supporto ai tag client NIP-89 per Damus. L’app ora emette un tag client su tutti i percorsi di pubblicazione (app principale, estensione di condivisione, evidenziatore, bozze) e visualizza “via ClientName” accanto ai timestamp quando altre app includono i loro tag. Un toggle Privacy nelle impostazioni Aspetto permette agli utenti di disabilitare l’emissione del tag. La PR #3652 aggiunge una sezione Storage nelle Impostazioni con un grafico a torta interattivo che mostra l’utilizzo del disco per NostrDB e la cache Kingfisher con supporto all’esportazione.

Aperta: la PR #3657 aggiunge il fallback NIP-65 per le note citate. Quando un nevent inline include una pubkey autore ma nessun suggerimento relay e la nota è assente dal pool dell’utente, Damus recupera la lista relay kind 10002 dell’autore e riprova dai suoi relay di scrittura.

Amethyst: NIP-39 (External Identities), NIP-C0, NIP-66

Amethyst ha unito un’ondata di implementazioni NIP su 28 PR. Le rivendicazioni di identità esterna ora pubblicano come event dedicati di kind 10011 sotto NIP-39 (PR #1747), separando l’identità sociale dai metadata di kind 0 con fallback retrocompatibile. Il supporto agli snippet di codice tramite NIP-C0 (PR #1744) aggiunge event di kind 1337 con accessor per linguaggio, estensione, runtime, licenza e dipendenze. L’implementazione del relay monitoring NIP-66 (PR #1742) copre entrambi i tipi di event con parsing completo dei tag per metriche RTT, tipo di rete, NIP supportati e geohash.

I DM cifrati sono arrivati su Amethyst Desktop (PR #1710) con un layout chat a pannelli divisi che supporta sia NIP-04 (Encrypted Direct Messages) che NIP-17 (Private Direct Messages). Una nuova schermata feed relay (PR #1733) permette agli utenti di navigare i post da un relay specifico con funzionalità follow/unfollow. Aperta: la verifica NIP-05 resistente alla censura (PR #1734) aggiunge un percorso di verifica parallelo per gli identificatori .bit che risolve contro la blockchain Namecoin invece dell’HTTP DNS. Quando Amethyst rileva un suffisso .bit in un campo NIP-05, interroga un server ElectrumX-NMC per la cronologia delle transazioni del nome, analizza lo script NAME_UPDATE dall’output più recente per estrarre la pubkey Nostr, e rifiuta i nomi più vecchi di 36.000 blocchi (la finestra di scadenza di Namecoin). Le connessioni ElectrumX si instradano attraverso SOCKS5 quando Tor è abilitato, con selezione dinamica del server tra endpoint clearnet e .onion. Una cache LRU con TTL di un’ora previene query ripetute alla blockchain.

Notedeck: Architettura Outbox

La PR #1303 migra Notedeck dalla gestione ad hoc del relay pool a un modello outbox centralizzato con sottoscrizioni a livello di account. Il modulo Messages ora pubblica una lista relay DM predefinita se non ne esiste una e instrada i DM ai relay preferiti dei destinatari secondo il kind 10050.

Pika: Profili Per-Gruppo e Feed Tutorial

Pika, l’app di messaggistica cifrata con Marmot disponibile su iOS e Android con una build desktop, ha ottenuto i profili per-gruppo (PR #368). Gli utenti possono ora impostare un nome visualizzato e un’immagine separati per ogni chat di gruppo, insieme a una bio personalizzata. Questi profili pubblicano come event di kind 0 cifrati all’interno del gruppo Marmot, invisibili a chiunque sia esterno, con fallback al profilo Nostr globale dell’utente quando non è impostato un profilo specifico per il gruppo. Quando nuovi membri si uniscono, l’admin ritrasmette tutti i profili di gruppo memorizzati e ogni membro ripubblica il proprio al commit. Le immagini dei profili vengono cifrate con Marmot-media prima dell’upload su Blossom. La PR include 16 nuovi test unitari e espone la funzionalità sia tramite un comando CLI (update-group-profile) che tramite la UI.

Una nuova web app pika-news (PR #401) monitora le PR GitHub di Pika e genera automaticamente walkthrough tutorial passo-passo dalle diff delle PR, pubblicandoli come pagine server-rendered con autenticazione NIP-07. Gli utenti possono discutere tutorial specifici in tempo reale tramite chat autenticata Nostr.

diVine, la piattaforma di condivisione video nativa su Nostr, ha unito 132 PR in dieci giorni. I widget iframe incorporabili (PR #1843) forniscono una pagina /embed?npub=... autonoma che renderizza il profilo di un utente e i suoi video più recenti. La funzionalità risposte video (PR #1915), protetta da un feature flag, usa commenti Kind 1111 (NIP-22) con metadata imeta NIP-92 (Media Attachments). I filtri di contenuto a tre vie ispirati a Bluesky (PR #1797) offrono controlli Show/Warn/Hide su 17 categorie di avvisi di contenuto NIP-32.

strfry: Validazione Filtri REQ

La PR #163 aggiunge la validazione configurabile dei filtri REQ a strfry, il relay Nostr in C++. Gli operatori possono impostare il numero massimo di filtri per REQ, la presenza obbligatoria di autore o tag, whitelist di kind consentiti e limiti di kind per filtro. La funzionalità è rivolta ai deployment di relay NWC che necessitano di un’applicazione rigorosa dei filtri. Aperta: la PR #173 aggiunge la compressione zstd opzionale per i payload degli event al momento dell’ingestione.

rust-nostr: NIP-62 Request to Vanish

rust-nostr, la libreria Rust per il protocollo Nostr, ha aggiunto il supporto a NIP-62 (Request to Vanish) su tutti e tre i backend di database: LMDB, SQLite e in-memory. L’implementazione LMDB include opzioni configurabili per abilitare o disabilitare l’applicazione di NIP-09 e NIP-62 per deployment.

NDK: Event Collaborativi e Timeout NIP-46

NDK, il Nostr Development Kit per JavaScript/TypeScript, ha unito la PR #380 che introduce NDKCollaborativeEvent per documenti collaborativi multi-autore usando un event puntatore indirizzabile (kind 39382) che definisce gli autori autorizzati. Un timeout configurabile per NDKNip46Signer (PR #381) impedisce alle operazioni di firma remota NIP-46 di bloccarsi indefinitamente quando un bunker non risponde.

TENEX: Categorizzazione degli Agenti e Gating tramite Pubkey

TENEX, la piattaforma di orchestrazione agenti AI nativa su Nostr, ha unito due PR relative alla sicurezza. La categorizzazione degli agenti basata su ruoli TIP-01 (PR #91) mappa le categorie degli agenti (principal, orchestrator, worker, advisor, auditor) a restrizioni automatizzate sugli strumenti tramite una mappa denied-tools. Il gating front-door tramite pubkey (PR #87) assicura che solo gli event da pubkey whitelisted o firmate dal backend siano instradati insieme agli agenti conosciuti; le pubkey sconosciute vengono scartate silenziosamente con span OpenTelemetry per l’audit.

Zap Cooking: Dashboard Abbonamenti

Zap Cooking, la piattaforma di condivisione ricette basata su Nostr, ha unito 25 PR e 85 commit in dieci giorni. Una dashboard abbonamenti (PR #228) mostra lo stato della sottoscrizione con date di scadenza e opzioni di gestione/upgrade, riabilita i gate delle funzionalità per i livelli Sous Chef e Zappy con controlli sia lato client che lato server, e standardizza la nomenclatura dei livelli su 26 file. Il caricamento dei messaggi di gruppo in due fasi (PR #227) fornisce un fetch iniziale rapido di 3 giorni per la visualizzazione istantanea seguito da un backfill in background di 40 giorni.

Lo storage del mnemonic del wallet è passato dalla cifratura derivata dalla pubkey alla cifratura encrypt-to-self NIP-44 (PR #224), correggendo una vulnerabilità in cui il vecchio schema derivava la chiave da SHA-256(pubkey), che è effettivamente non cifrato poiché le pubkey sono pubbliche. I wallet esistenti vengono migrati silenziosamente al primo caricamento. La chat di gruppo NIP-29 ha ottenuto indicatori di non letto con badge a pallino rosso e accesso solo su invito con codici invito di kind 9009 (PR #213). Le anteprime link e gli embed di event Nostr ora si renderizzano nei DM e nei messaggi di gruppo (PR #218). Una sezione backup Nostr nelle Impostazioni (PR #210) memorizza follow e liste mute tramite storage cifrato NIP-78 (Application-specific Data) con versioning rotativo a 3 slot. Le prestazioni di avvio sono migliorate attraverso il rinvio dei servizi di notifica, il rendering DOM lazy tramite IntersectionObserver (riducendo i nodi DOM da circa 15.000 a circa 3.000 su un feed di 200 event) e TTL estesi della cache outbox (PR #208). Una modale di stampa ricetta personalizzabile (PR #205) permette agli utenti di selezionare quali sezioni includere con un’anteprima live. L’integrazione Branta SDK (PR #222) aggiunge garanzie di verifica per le richieste POST e GET.

Keep: Migrazione dello Stato Guidata da Rust

Keep, il gestore di chiavi private basato su Nostr per Android, ha unito la PR #178, eliminando quattro store di configurazione Kotlin a favore dello stato condiviso guidato da Rust dal livello keep-mobile. Un loop di polling a 10 secondi è stato sostituito con KeepStateCallback push-based da Rust. La PR #179 aggiunge backup e ripristino cifrati con protezione tramite passphrase.

Mostro Mobile: Cifratura Chat Dispute

Mostro Mobile, il client mobile per la piattaforma di trading Bitcoin P2P Mostro, ha distribuito una migrazione in due fasi della cifratura chat dispute. Il primo passo (PR #495) passa dal wrapping specifico di mostro alla cifratura con chiave condivisa derivata dalla pubkey dell’admin. Basandosi su questo, la PR #501 unifica il modello di messaggi con NostrEvent e memorizza gli event gift wrap cifrati su disco, coerente con il pattern di chat peer-to-peer. Una correzione della firma BIP-340 (PR #496) sovrascrive la dipendenza bip340 alla 0.2.0, risolvendo un bug di padding bigToBytes() che causava l’invalidità dell'1-2% delle firme Schnorr e il 100% di fallimenti per le chiavi la cui chiave pubblica inizia con 0x00. Order Details ora mostra etichette di stato leggibili invece di valori grezzi del protocollo, localizzate in inglese, spagnolo, italiano e francese (PR #502). HalCash è stato aggiunto e SEPA rimosso come metodo di pagamento (PR #493), poiché i trasferimenti SEPA possono superare le 24 ore (SEPA Instant rimane).

Lato server, Mostro ha corretto il ripristino della sessione dispute per includere il campo initiator (PR #599) e ora chiude automaticamente le dispute attive quando un venditore rilascia i fondi, pubblicando un event Nostr di risoluzione in modo che i client admin vedano la risoluzione (PR #606).

Cinque Anni di Febbraio di Nostr

La newsletter del mese scorso ha tracciato le pietre miliari di gennaio di Nostr dai primi sviluppi fino all’esplosione di Damus, arrivando all’infrastruttura di sicurezza nel 2026. Questa retrospettiva copre cosa è successo ogni febbraio dal 2021 al 2026.

Febbraio 2021: La Riscrittura

Tre mesi dopo la sua nascita, il febbraio di Nostr ha prodotto il cambiamento più significativo delle origini del protocollo. Il 14-15 febbraio, fiatjaf ha riscritto NIP-01, sostituendo il formato messaggi originale con il modello EVENT/REQ/CLOSE che il protocollo usa ancora oggi. Prima di questa riscrittura, client e relay comunicavano attraverso una struttura più semplice. Separare la pubblicazione degli event (EVENT) dalla gestione delle sottoscrizioni (REQ/CLOSE) ha abilitato il filtraggio lato relay che si sarebbe rivelato essenziale per la scalabilità.

NIP-04 è arrivato lo stesso mese, aggiungendo messaggi diretti cifrati usando segreti condivisi derivati dallo scambio di chiavi Diffie-Hellman su secp256k1. La sua cifratura era basilare (AES-256-CBC) e sarebbe stata successivamente sostituita dalla crittografia verificata di NIP-44, ma ha dato alla manciata di utenti iniziali il loro primo canale di comunicazione privata sul protocollo.

Il tooling si è espanso con noscl, un client a riga di comando in Go per l’interazione con i relay da terminale, e futurepaul ha iniziato nostr-rs, una prima implementazione Rust. L’intera rete funzionava su due o tre relay, coordinata attraverso un gruppo Telegram, con circa sette contributor attivi.

Febbraio 2022: Costruire lo Slancio

Il post su Hacker News del 31 dicembre 2021 ha continuato ad attirare sviluppatori fino a febbraio. Il repository nostr-protocol/nostr (il repository NIPs formale non sarebbe esistito fino a maggio 2022) ha ricevuto sei pull request a febbraio, inclusi NIP-13 (Proof of Work) di vinliao, NIP-14 (Reputation) di fiatjaf, NIP-15 (Resource Relations) di Cameri e NIP-17 (Git Updates Over Nostr) di melvincarvalho. Il numero NIP è stato successivamente riassegnato a Private Direct Messages; la collaborazione git su Nostr è continuata separatamente attraverso quello che è diventato gitworkshop.dev.

Il nostr-rs-relay di Greg Heartsfield è stato il cavallo di battaglia del mese con 34 commit e tre rilasci. La versione 0.5.0 del 12 febbraio ha aggiunto limiti di pubblicazione per utenti verificati NIP-05. Le versioni 0.5.1 e 0.5.2 sono seguite nelle due settimane successive, e il relay gestiva la maggior parte del traffico della rete da solo.

Robert C. Martin (Uncle Bob) stava costruendo more-speech, un client desktop in Clojure, registrando 69 commit tra il 18 gennaio e la fine di febbraio. Il suo coinvolgimento ha portato attenzione dalla più ampia comunità di ingegneria del software. L’estensione browser nos2x di fiatjaf ha distribuito il supporto alla decifratura NIP-04 e le politiche di preferenza dei relay a febbraio, implementando l’interfaccia window.nostr (NIP-07) che i client web usano ancora per la delega delle chiavi.

Branle, ancora il client web principale, ha ottenuto la registrazione del gestore di protocollo web+nostr il 13 febbraio, un primo tentativo di deep linking tra applicazioni Nostr. nostr-tools ha rafforzato la validazione NIP-05. go-nostr ha aggiunto il supporto ai DM cifrati NIP-04 e il parsing NIP-12 (Generic Tag Queries) su 11 commit. La rete operava su circa 7-15 relay con una base utenti attiva probabilmente nell’ordine delle centinaia. Damus e Nostream non esistevano ancora e non sarebbero apparsi fino ad aprile 2022.

Febbraio 2023: Attenzione Internazionale

Febbraio 2023 ha portato a Nostr la sua più grande ondata di attenzione pubblica. Damus, il client iOS di William Casarin, era stato approvato sull’App Store di Apple il 31 gennaio dopo ripetuti rifiuti. Entro il 1° febbraio aveva raggiunto la top 10 nella categoria Social Networking negli USA. Due giorni dopo, il 2 febbraio, Apple ha rimosso Damus dall’App Store cinese apparentemente su richiesta dell’Amministrazione del Cyberspazio della Cina.

I principali media inclusi TechCrunch e CoinDesk hanno coperto la rimozione, amplificando la consapevolezza sia dell’app che del protocollo. Le chiavi pubbliche uniche con metadata su nostr.directory hanno superato le 300.000 entro il 3 febbraio. Tutti i relay erano gestiti da appassionati che pagavano di tasca propria, e l’infrastruttura si è affannata per gestire il carico. Circa 289 relay erano tracciati a inizio febbraio, un numero che ha continuato a crescere.

Il repository NIPs ha registrato 29 pull request unite quel mese, il conteggio mensile più alto nella storia del protocollo fino a quel momento. NIP-57 (Lightning Zaps) e NIP-23 (Long-form Content) sono stati entrambi uniti il 13 febbraio, aggiungendo micropagamenti Bitcoin e espandendo Nostr oltre i post brevi in un solo giorno. NIP-65 (Relay List Metadata) era stato unito una settimana prima, il 7 febbraio, abilitando il modello outbox che è seguito. NIP-46 (Nostr Connect) e NIP-58 (Badges) sono stati anch’essi rilasciati prima della fine del mese.

La Human Rights Foundation ha assegnato 50.000$ a William Casarin per lo sviluppo di Nostr e Damus il 21 febbraio, una delle prime grant istituzionali a un progetto Nostr. OpenSats non aveva ancora lanciato il suo fondo Nostr (cosa che sarebbe avvenuta a luglio 2023).

Febbraio 2024: Durabilità del Protocollo

Febbraio 2024 ha spostato il focus dalla crescita alla durabilità del protocollo. NIP-17 (Private Direct Messages), aperto dal luglio precedente, stava lavorando verso una sostituzione per l’invecchiata cifratura NIP-04 usando la crittografia verificata di NIP-44 e il gift wrapping di NIP-59. NIP-04 faceva trapelare metadata agli operatori dei relay, che potevano vedere le coppie mittente-destinatario. NIP-17 nasconde l’identità del mittente dietro keypair usa e getta ed è stato unito quella primavera dopo un ultimo giro di revisione a marzo.

NIP-29 (Simple Groups) è stato unito il 28 febbraio dopo mesi di discussione, definendo come i relay possono ospitare chat di gruppo moderate con ruoli admin e controllo degli accessi. NIP-92 (tag imeta) è stato unito il 1° febbraio, standardizzando come i client allegano dimensioni delle immagini e anteprime blurhash agli event media.

Il 16 febbraio, il repository NIPs ha aggiunto BREAKING.md, un file che traccia le modifiche incompatibili alla specifica del protocollo. La sua creazione ha riconosciuto che Nostr aveva raggiunto un livello di maturità in cui le modifiche incompatibili necessitavano di documentazione formale.

Ventidue pull request sono state unite quel mese. npub.cash è stato lanciato come servizio di indirizzo Lightning che permette a qualsiasi npub di ricevere pagamenti senza gestire un server. Un articolo accademico pubblicato l'8 febbraio ha rilevato che il 95% dei relay gratuiti non poteva coprire i costi operativi attraverso le donazioni, con il 35% dei relay a pagamento che addebitava tariffe di ammissione inferiori a 1.000 sats (circa 0,45$ all’epoca).

Febbraio 2025: Crescita dell’Infrastruttura

Febbraio 2025 ha prodotto 28 pull request unite nel repository NIPs. Un NIP Right to Vanish è stato unito il 19 febbraio, definendo come gli utenti possono richiedere la cancellazione dei propri dati dai relay in risposta a questioni normative sulla portabilità dei dati e il controllo dell’utente.

NIP-60 (Cashu Wallet) e NIP-61 (Nutzaps) hanno ricevuto aggiornamenti di semplificazione, razionalizzando il formato di storage dei token ecash. Un rollout del q-tag (quote tag) è continuato su più NIP, standardizzando come gli event referenziano altri event per citazioni e threading.

I rilasci dei client hanno segnato progressi costanti. Notedeck v0.3.0 alpha è stato distribuito l’ultimo giorno di gennaio, con l’adozione che è continuata in febbraio. Primal v2.1 è seguito il 7 febbraio, e GRAIN v0.3.0, un’implementazione relay in Go, è stato rilasciato il 21 febbraio.

NOSTRLDN v5 ha riunito la comunità Nostr londinese per il suo quinto incontro. Un bridge DVMCP ha collegato le Data Vending Machine di Nostr (NIP-90) con il Model Context Protocol, prefigurando il lavoro di integrazione degli agenti AI arrivato il mese successivo.

L’attività di febbraio 2026 è tratta dai numeri di Nostr Compass #8 fino al #11.

Febbraio 2026 ha prodotto la gamma più ampia di sviluppo a livello applicativo in un singolo mese di Nostr. Mostro ha distribuito la sua prima beta pubblica per il trading decentralizzato di Bitcoin peer-to-peer, e Zapstore ha raggiunto la 1.0 stabile dopo mesi di test in release candidate. White Noise v0.3.0 ha portato la messaggistica in tempo reale cifrata con Marmot con supporto al signer Amber e oltre 160 miglioramenti uniti.

Proposte concorrenti per agenti AI da pablof7z (NIP-AE per flussi di lavoro degli agenti, NIP-AD per annunci di server MCP) e joelklabo (AI Agent Messages) sono arrivate insieme a una proposta di Coordinamento Agenti DVM che estende NIP-90. ContextVM ha distribuito miglioramenti all’SDK per collegare il Model Context Protocol al trasporto Nostr. Burrow ha aggiunto la messaggistica cifrata con Marmot sia per agenti AI che per umani, estendendo l’identità e l’infrastruttura relay di Nostr alla comunicazione machine-to-machine.

FIPS ha distribuito un’implementazione Rust funzionante di reti mesh native su Nostr, usando keypair secp256k1 come identità dei nodi con routing agnostico dal trasporto su UDP, Ethernet, Bluetooth o radio LoRa. Il suo design ha mostrato che il modello di chiavi di Nostr si estende oltre i social media fino all’infrastruttura di rete fisica.

OpenSats ha annunciato la quindicesima ondata di grant Nostr, finanziando progetti inclusi ContextVM e Nostube. Le modifiche al protocollo hanno incluso il supporto hold invoice NIP-47 per Nostr Wallet Connect e NIP-45 (Counting Results) HyperLogLog per la stima dei conteggi lato relay. Anche la scopribilità dei service provider NIP-85 (Trusted Assertions) per il punteggio Web of Trust è stata unita. rust-nostr ha iniziato un redesign completo delle API mentre Nostria 3.0 e Frostr (iOS TestFlight) sono stati entrambi distribuiti. Il livello di cache locale di Blossom ha affrontato la disponibilità dei media sui relay.

Guardando Avanti

Cinque febbraio di storia del protocollo mostrano una progressione costante dal lavoro fondamentale alla diversificazione a livello applicativo, con l’afflusso di utenti del 2023 come punto di svolta. Nel 2021, sette contributor lavoravano su tre relay. Entro il 2026, lo stesso protocollo supportava reti mesh e proposte per agenti autonomi in esecuzione su infrastruttura di produzione.

È tutto per questa settimana. Stai costruendo qualcosa o hai notizie da condividere? Contattaci via DM NIP-17 o trovaci su Nostr.

Nostr Compass #11

Wed, 25 Feb 2026 00:00:00 +0000

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

Questa settimana: White Noise v0.3.0 porta la messaggistica in tempo reale e il supporto al signer Amber con oltre 160 miglioramenti uniti. diVine 1.0.5 corregge problemi di riproduzione video e aggiunge eventi di visualizzazione Kind 22236 per l’analisi dei creator. Pika, Ridestr e Unfiltered pubblicano aggiornamenti. FIPS distribuisce un’implementazione Rust funzionante di reti mesh native su Nostr. Notecrumbs riceve correzioni di stabilità per le anteprime link di damus.io. ContextVM collega Nostr con il Model Context Protocol. I nuovi progetti includono Burrow per la messaggistica cifrata con MLS tra agenti AI e umani, e Nostria Signer per la gestione di vault e identità basata su browser. Gli approfondimenti coprono la firma Android NIP-55 e la sincronizzazione del wallet Cashu NIP-60.

Notizie

Miglioramenti di Stabilità di Notecrumbs

Notecrumbs, il server API e web che alimenta le anteprime link di damus.io, ha ricevuto una serie di correzioni che risolvono problemi di affidabilità.

Una correzione della concorrenza ha sostituito il meccanismo di deduplicazione in-flight con watch channel. Due chiamanti che richiedevano la stessa nota potevano diventare entrambi fetcher, causando un deadlock quando uno completava prima che l’altro si iscrivesse alla notifica. I watch channel con operazioni atomiche garantiscono che un solo fetcher sia attivo mentre gli altri attendono il risultato.

Il rate limiting implementa una difesa a due livelli contro il bombardamento dei relay. Quando gli utenti accedono ripetutamente alla stessa nota, il sistema ora fa debounce delle richieste ai relay con una finestra di raffreddamento di 5 minuti. Questa protezione si estende a tutti i tipi NIP-19 e ai feed dei profili, prevenendo spam proporzionale ai relay durante il traffico intenso.

I miglioramenti delle prestazioni hanno spostato i fetch secondari dei dati a task tokio in background. Le pagine ora si renderizzano istantaneamente con dati in cache invece di bloccarsi su timeout sequenziali dei relay che potevano aggiungere fino a 7,5 secondi. Un aggiornamento a nostrdb 0.10.0 ha accompagnato queste correzioni.

ContextVM: MCP su Nostr

ContextVM è una suite di strumenti che collega Nostr e il Model Context Protocol (MCP). I commit recenti hanno introdotto la nuova specifica CEP-8 che abilita i pagamenti, con miglioramenti all’SDK distribuiti nel corso di febbraio.

L’SDK fornisce transport TypeScript client e server per MCP su Nostr. Gli sviluppatori possono esporre server MCP attraverso la rete Nostr e i client possono connettersi ad essi. I relay agiscono come un bus messaggi cieco, instradando semplicemente eventi cifrati in modo opaco. I client senza supporto nativo a Nostr si connettono attraverso un livello proxy. La libreria gestisce la gestione dei relay e la firma crittografica per l’autenticazione degli event. Funziona sia in ambienti Node.js che browser.

CVMI fornisce una CLI per la scoperta di server e l’invocazione di metodi. Relatr calcola punteggi di fiducia personalizzati dalla distanza nel grafo sociale combinata con la validazione del profilo.

ContextVM si posiziona come livello ponte: i server MCP esistenti acquisiscono interoperabilità con Nostr mantenendo i loro transport convenzionali.

White Noise Documenta la Ricerca Utenti Decentralizzata

Un post sul blog di jgmontoya spiega come White Noise gestisce la ricerca utenti attraverso la rete relay decentralizzata.

La distribuzione dei profili crea la sfida: a differenza dei messenger centralizzati con database unificati, i profili Nostr si disperdono su decine di relay senza indice centrale. White Noise risolve questo problema attraverso un’architettura produttore-consumatore che gira in parallelo.

Un processo produttore espande continuamente il grafo sociale verso l’esterno a partire dai seguiti dell’utente, recuperando liste di follow a distanze crescenti e accodando le pubkey scoperte per la risoluzione dei profili. Il consumatore risolve le corrispondenze attraverso cinque livelli di costo crescente: tabella utenti locale (più veloce), profili in cache dalle ricerche precedenti, relay connessi, liste relay utente per NIP-65 e query dirette ai relay dichiarati dall’utente (più lento).

Le ricerche a freddo richiedono circa 3 secondi mentre le ricerche a caldo dalla cache scendono a circa 10 millisecondi. Per i nuovi utenti senza grafi sociali consolidati, il sistema inietta nodi bootstrap ben connessi per garantire la funzionalità di ricerca. L’appartenenza ai gruppi fornisce un segnale sociale implicito accanto ai seguiti espliciti.

La strumentazione si è rivelata fondamentale per l’ottimizzazione, nota l’autore. Senza metriche, i miglioramenti erano solo intuizioni.

FIPS: Rete Mesh Nativa su Nostr

FIPS (Free Internetworking Peering System) è un’implementazione Rust funzionante di una rete mesh auto-organizzante che usa le keypair Nostr (secp256k1) come identità dei nodi. La documentazione di design accompagna il codice funzionale.

Il protocollo affronta l’indipendenza infrastrutturale: i nodi si scoprono automaticamente senza server centrali o autorità di certificazione. Un spanning tree fornisce routing basato su coordinate mentre i bloom filter propagano informazioni di raggiungibilità, permettendo ai nodi di prendere decisioni di inoltro con sola conoscenza locale. L’agnosticismo dal trasporto significa che lo stesso protocollo funziona su UDP, Ethernet, Bluetooth, radio LoRa o qualsiasi mezzo capace di datagrammi.

Due livelli di cifratura proteggono il traffico. La cifratura a livello link (pattern Noise IK) protegge la comunicazione hop-by-hop tra vicini con autenticazione reciproca e forward secrecy. La cifratura a livello sessione (pattern Noise XK) fornisce protezione end-to-end contro i router intermedi, dove solo la destinazione può decifrare il payload. Questo rispecchia come TLS protegge il traffico HTTP anche quando attraversa reti non fidate.

L’architettura usa uno spanning tree a “greedy embedding” per il routing. Ogni nodo riceve coordinate basate sulla sua posizione relativa alla radice dell’albero e al genitore. I pacchetti vengono instradati greedy verso coordinate più vicine alla destinazione, con bloom filter che pubblicizzano gli endpoint raggiungibili. Quando il routing greedy fallisce (minimi locali), i nodi possono ricorrere ai percorsi basati sull’albero.

L’implementazione Rust include già il trasporto UDP con scoperta tramite bloom filter. I lavori futuri mirano all’integrazione relay Nostr per il bootstrapping dei peer.

Rilasci

Questa settimana ha portato rilasci nell’infrastruttura relay e nelle applicazioni client, con nuovi progetti che entrano nello spazio.

HAVEN v1.2.0

HAVEN, il relay personale all-in-one che raggruppa quattro funzioni relay con un server media Blossom, ha distribuito la v1.2.0. Questo rilascio va oltre la fase RC coperta la settimana scorsa.

Il supporto multi-npub permette a una singola istanza HAVEN di servire diverse identità Nostr tramite whitelisting, con nuove funzionalità di blacklisting per il controllo degli accessi. Un sistema di backup riscritto usa il formato JSONL portabile, con un comando haven restore per importare note da file JSONL. L’integrazione con lo storage cloud aggiunge i flag --to-cloud e --from-cloud per la gestione dei backup remoti.

I miglioramenti al Web of Trust includono livelli di profondità configurabili per i calcoli di fiducia e intervalli di aggiornamento automatico di 24 ore con ottimizzazione lockless che riduce l’overhead di memoria. La configurazione dello user-agent per le richieste ai relay e le impostazioni di timeout Blastr configurabili completano il rilascio, insieme all’esportazione dati in JSONL compresso.

White Noise v0.3.0

White Noise, l’app di messaggistica cifrata basata su MLS che implementa il protocollo Marmot, ha distribuito la v0.3.0 con oltre 160 miglioramenti uniti.

Questo rilascio porta la messaggistica in tempo reale attraverso connessioni in streaming invece del polling, così i messaggi arrivano istantaneamente. Il supporto Amber (NIP-55) significa che le chiavi private non devono mai toccare l’app. La condivisione delle immagini ora funziona con tracciamento del progresso di upload e placeholder blurhash durante il caricamento. La visualizzazione a schermo intero supporta il pinch-to-zoom.

La messaggistica di gruppo ha ricevuto miglioramenti di affidabilità con le liste chat che mostrano i nomi dei mittenti e la cifratura MLS che garantisce la forward secrecy. La ricerca utenti si espande verso l’esterno dai seguiti fino a quattro gradi di separazione con risultati che arrivano in streaming man mano che vengono trovati.

Un breaking change azzera tutti i dati locali all’aggiornamento a causa di modifiche al protocollo Marmot e al passaggio allo storage locale cifrato. Gli utenti dovrebbero fare il backup delle chiavi nsec prima di aggiornare.

diVine 1.0.5

diVine, il client video a ciclo breve costruito sugli archivi restaurati di Vine, ha distribuito la 1.0.5 con ampie correzioni alla riproduzione video e un nuovo sistema di analisi decentralizzato.

I problemi di riproduzione video hanno dominato le correzioni: pausa fantasma, audio doppio tra video, flash nero tra miniature e primi frame, e crash del player smaltito sono tutti risolti. Un player video in pool gestisce ora il feed Home per una riproduzione coerente.

Gli event di visualizzazione effimeri Kind 22236 abilitano l’analisi dei creator e le raccomandazioni. Il sistema traccia le fonti di traffico (home, varianti di scoperta, profilo, condivisione, ricerca) e i conteggi dei loop filtrando le auto-visualizzazioni. Le perdite di percorso file locale nei tag imeta degli event Nostr sono corrette con URL Blossom canonici costruiti lato client secondo la specifica BUD-01.

I miglioramenti al signer remoto NIP-46 includono connessioni relay parallelizzate e supporto all’URL di callback. Android riconnette le connessioni WebSocket alla ripresa dell’app dopo l’approvazione del signer.

Coracle 0.6.30

Coracle, il client Nostr web focalizzato sulla gestione dei relay e la moderazione Web of Trust, ha distribuito la 0.6.30 con supporto alle miniature video, migliorando la navigazione dei media nei feed.

Nostur v1.26.0

Nostur, il client Nostr per iOS, ha distribuito la v1.26.0 con una nuova sezione feed Live Streams e una schermata Impostazioni riprogettata. I GIF possono ora essere ospitati su server media Blossom, riducendo la dipendenza da servizi centralizzati. L’integrazione Klipy GIFs fornisce un backup quando Tenor non è disponibile. Le intestazioni per anno nelle conversazioni DM e la visualizzazione del conteggio menzioni completano le modifiche lato utente.

Gli strumenti per sviluppatori e le app CLI hanno ricevuto aggiornamenti anche questa settimana.

nak v0.18.5

nak, il coltellino svizzero a riga di comando di fiatjaf per Nostr, ha distribuito la v0.18.5 con un nuovo sottocomando nak profile per recuperare e visualizzare profili utente. Il comando git clone ora supporta i nomi NIP-05 negli URI nostr://, abilitando il cloning di repository tramite identificatori leggibili.

Pika v0.5.3

Pika, il messenger cifrato con MLS per iOS, Android e desktop costruito sul protocollo Marmot, ha distribuito la v0.5.3. I commit recenti aggiungono il caricamento di file e il supporto al drag-and-drop media nell’app desktop, insieme a correzioni per il deployment su Cloudflare Workers.

Pika usa un core Rust che possiede tutta la logica di business mentre iOS (SwiftUI) e Android (Kotlin) agiscono come livelli UI snelli che renderizzano snapshot dello stato. MDK (Marmot Development Kit) fornisce l’implementazione MLS. Il progetto indica lo stato alpha e sconsiglia l’uso per carichi di lavoro sensibili.

Ridestr v0.2.6

Ridestr, la piattaforma di ridesharing decentralizzata con pagamenti Cashu, ha distribuito la v0.2.6. Questo rilascio corregge problemi di accessibilità TalkBack e risolve bug in cui i driver scomparivano dalla lista nelle vicinanze quando si cambiava metodo di pagamento, o in cui il conteggio dei driver selezionati non si aggiornava quando i driver andavano offline.

La funzione “Send to All” è ora “Broadcast RoadFlare” con correzioni per i silenziosi fallimenti su installazioni fresche dei driver. Ridestr implementa l’escrow HTLC per pagamenti trustless delle corse e la sincronizzazione wallet NIP-60 tra dispositivi.

Unfiltered v1.0.6

Unfiltered, l’app di condivisione foto simile a Instagram per Android, ha distribuito la v1.0.6 con ricerca utenti migliorata e riconnessione automatica ai relay ogni 60 secondi.

Costruita con Kotlin e Jetpack Compose, Unfiltered usa le binding rust-nostr e server compatibili con Blossom per l’hosting delle immagini. L’integrazione Amber (NIP-55) gestisce la gestione sicura delle chiavi. L’app mostra i post degli account seguiti in ordine cronologico senza algoritmi o pubblicità.

Due nuovi progetti di messaggistica e firma sono stati lanciati questa settimana.

Burrow: Messaggistica MLS per Agenti AI

Burrow è un messenger che implementa il protocollo Marmot per la comunicazione cifrata con MLS senza numeri di telefono o server centralizzati. Sia gli utenti umani che gli agenti AI possono partecipare.

Un daemon CLI in Rust puro con modalità di output JSONL gestisce l’integrazione con i sistemi automatizzati. Un’app Flutter cross-platform copre Android, iOS, Linux, macOS e Windows. Gli allegati media vengono cifrati insieme ai messaggi, e WebRTC gestisce le chiamate audio e video con server TURN configurabili.

Burrow stratifica la cifratura MLS sull’infrastruttura Nostr. L’identità usa le keypair Nostr (secp256k1) mentre i KeyPackage MLS vengono pubblicati come event di kind 443. I messaggi vengono cifrati con NIP-44 come event di kind 445, e gli inviti di benvenuto usano il gift-wrapping NIP-59.

L’integrazione con OpenClaw abilita la partecipazione degli agenti AI con accesso completo agli strumenti. Le liste di controllo degli accessi con log di audit gestiscono i permessi di contatto e gruppo. Questa combinazione posiziona Burrow per scenari di messaggistica agente-agente e agente-umano che richiedono cifratura di livello Signal su infrastruttura decentralizzata.

Estensione Nostria Signer

Nostria Signer è un’estensione browser basata su Chromium che fornisce gestione di vault e identità per gli utenti Nostr.

Vault multipli contenenti account multipli permettono agli utenti di organizzare le identità per contesti diversi. L’internazionalizzazione include il supporto alle lingue RTL. Costruita con Angular e TypeScript (79,2% del codebase), funziona sia come estensione browser che come Progressive Web App.

Nostria Signer implementa NIP-07 per la firma tramite estensione browser, permettendo ai client Nostr web di richiedere firme degli event senza accedere direttamente alle chiavi private. La migrazione automatica del wallet gestisce gli aggiornamenti distribuiti attraverso il Chrome Web Store. Gli utenti possono anche fare il sideload dalla cartella dist/extension.

Gli sviluppatori sottolineano lo stato sperimentale: gli utenti devono gestire le proprie frasi di recupero segrete poiché gli sviluppatori non possono ripristinare l’accesso alle chiavi perse.

Aggiornamenti dei Progetti

Formstr Migra alla Nuova Organizzazione

Formstr, l’alternativa a Google Forms su Nostr, ha migrato il suo repository da abh3po/nostr-forms all’organizzazione formstr-hq. Questo beneficiario di una grant OpenSats continua lo sviluppo nella nuova posizione.

PR Aperte di Rilievo

Lavori in corso nei progetti Nostr:

Damus Outbox Model (PR #3602): Piano di implementazione per il modello relay gossip/outbox su iOS. Questo cambiamento architetturale migliora la consegna dei messaggi pubblicando ai relay dove i destinatari leggono effettivamente.
Notedeck Cross-Platform Notifications (PR #1296): Sistema di notifiche nativo per il client desktop Damus che copre Android FCM, macOS e Linux.
NDK Cashu v3 Upgrade (PR #370): Aggiorna l’integrazione wallet del Nostr Development Kit a cashu-ts v3.
Zeus Cashu Offline (PR #3742): Invio e ricezione ecash offline per il wallet Lightning Zeus.
Shopstr Encrypted Digital Delivery (PR #231): Aggiunge la consegna cifrata per i beni digitali con supporto al peso dinamico per gli articoli fisici.

Aggiornamenti NIP

Modifiche recenti al repository NIPs:

Uniti questa settimana:

NIP-85 Scoperta dei Provider di Servizi: La specifica NIP-85 include ora indicazioni su come i client scoprono i provider di trusted assertion. Quando un client necessita di punteggi Web of Trust o altre metriche calcolate, può interrogare i relay per gli annunci kind 30085 da provider che l’utente già segue o di cui si fida.
NIP-29 Rimuove i Gruppi Non Gestiti: La specifica dei gruppi chat NIP-29 ha eliminato il supporto per i gruppi non gestiti (dove qualsiasi membro poteva aggiungere altri). Tutti i gruppi NIP-29 richiedono ora la gestione lato relay con ruoli admin espliciti, semplificando le implementazioni e riducendo i vettori di spam.
NIP-11 Rimuove i Campi Deprecati: I documenti di informazione relay NIP-11 non includono più i campi deprecati software e version. Le implementazioni dovrebbero rimuoverli dalle proprie risposte.
NIP-39 Sposta i Tag di Identità: Le rivendicazioni di identità esterna (tag i di NIP-39 per GitHub, Twitter, ecc.) si sono spostate dai profili kind 0 a event kind 30382 dedicati. Questo separa la verifica dell’identità dai metadata del profilo.

Avanzamento dei NIP per Agenti AI:

Quattro NIP focalizzati sull’AI continuano lo sviluppo attivo. Da quando li abbiamo coperti la settimana scorsa:

NIP-AE: Agents (aggiornato il 19 feb): Definisce l’identità degli agenti con kind 4199 per le definizioni degli agenti e kind 4201 per i prompt (“nudge”). Gli agenti possono referenziare i metadata dei file NIP-94 per descrizioni estese.
NIP-XX: AI Agent Messages (aggiornato il 18 feb): Standardizza la messaggistica conversazionale con sette kind di event effimeri (25800-25806) per stato, delta di streaming, prompt, risposte, chiamate agli strumenti, errori e cancellazione. Gli event kind 31340 “AI Info” permettono agli agenti di pubblicizzare modelli e capacità supportate.
NIP-AC: DVM Agent Coordination (aperto il 18 feb): Estende NIP-90 per i flussi di lavoro autonomi degli agenti. Aggiunge heartbeat per la scoperta degli agenti, recensioni dei job per il tracciamento della qualità, escrow dei dati per l’impegno sui risultati, catene di flusso di lavoro per pipeline multi-step e bidding in sciame per la selezione competitiva dei provider. Un’implementazione di riferimento gira su 2020117.xyz.
NIP-AD: MCP Server Announcements (aperto il 12 feb): Standardizza l’annuncio dei server e delle skill del Model Context Protocol su Nostr. Già in uso sulla piattaforma TENEX.

Altre PR Aperte:

NIP-144: Service Authorization Protocol: Definisce come i client dimostrano identità e permessi ai provider di servizi su Nostr.
NIP-DC: Nostr Webxdc: alexgleason propone di integrare Webxdc (applicazioni web decentralizzate) con gli event Nostr.

NIP Deep Dive: NIP-55 (Applicazione Signer Android)

NIP-55 definisce come i client Nostr Android richiedono operazioni crittografiche da applicazioni signer dedicate. Con White Noise v0.3.0 e Unfiltered v1.0.6 che aggiungono entrambi il supporto ad Amber questa settimana, il protocollo di firma Android merita un esame.

Canali di Comunicazione:

NIP-55 abilita la firma inter-app attraverso due meccanismi. Gli Intent forniscono l’approvazione manuale dell’utente con feedback visivo per operazioni una tantum. I Content Resolver abilitano la firma automatizzata quando gli utenti concedono permessi persistenti, permettendo alle app di firmare in background senza prompt ripetuti.

La comunicazione usa lo schema URI personalizzato nostrsigner:. Un client avvia il contatto con:

nostrsigner:<base64-encoded-event>?type=sign_event&callbackUrl=myapp://callback

Operazioni Supportate:

La specifica definisce sette metodi crittografici: firma degli event (sign_event), recupero della chiave pubblica (get_public_key), cifratura/decifratura NIP-04, cifratura/decifratura NIP-44 e decifratura degli event zap (decrypt_zap_event).

Modello di Permessi:

I client chiamano get_public_key una volta per stabilire una relazione di fiducia, ricevendo il nome del pacchetto del signer e la pubkey dell’utente. La specifica impone che i client salvino questi valori e non chiamino mai più get_public_key, prevenendo attacchi di fingerprinting.

Per le richieste di firma, gli utenti possono approvare una volta o concedere “ricorda la mia scelta” per le operazioni in background. Se gli utenti rifiutano ripetutamente le operazioni, il signer restituisce uno stato “rejected”, prevenendo prompt ripetuti.

Implementazioni:

Amber è il signer NIP-55 principale per Android. I client che supportano NIP-55 includono Amethyst, White Noise, Unfiltered e altri. Le applicazioni web non possono ricevere direttamente le risposte del signer e devono usare URL di callback o operazioni con gli appunti.

Relazione con gli Altri NIP di Firma:

NIP-55 completa NIP-07 (estensioni browser) e NIP-46 (firma remota sui relay). Dove NIP-07 gestisce i browser desktop e NIP-46 gestisce la firma cross-device, NIP-55 fornisce integrazione nativa Android con latenza minima.

NIP Deep Dive: NIP-60 (Wallet Cashu)

NIP-60 definisce come i wallet ecash Cashu memorizzano lo stato sui relay Nostr, abilitando la sincronizzazione del wallet tra applicazioni. Con Ridestr v0.2.6 che usa NIP-60 per la sincronizzazione del wallet tra dispositivi, il protocollo merita un esame.

Tipi di Event:

NIP-60 usa quattro tipi di event. Il kind 17375 sostituibile memorizza la configurazione del wallet inclusi gli URL dei mint e una chiave privata dedicata per ricevere pagamenti ecash P2PK. Gli event token (kind 7375) contengono prove crittografiche non spese, mentre la cronologia delle spese (kind 7376) registra le transazioni per la trasparenza dell’utente. Un kind 7374 opzionale traccia le quote di pagamento del mint.

Architettura del Wallet:

Lo stato del wallet risiede sui relay, rendendolo accessibile tra le applicazioni. L’event wallet di un utente contiene riferimenti cifrati ai mint Cashu e una chiave privata specifica per il wallet separata dall’identità Nostr dell’utente. Questa separazione è importante: la chiave wallet gestisce le operazioni ecash mentre la chiave Nostr gestisce le funzioni sociali.

{
 "kind": 17375,
 "content": "<nip44-encrypted-wallet-config>",
 "tags": [["d", "cashu-wallet"]]
}

Gestione delle Prove:

Le prove Cashu sono strumenti al portatore. Una volta spesa, una prova diventa non valida. NIP-60 gestisce questo attraverso un meccanismo di rollover: durante la spesa, i client creano un nuovo event token con le prove non spese rimanenti ed eliminano l’originale tramite NIP-09. Gli ID dei token distrutti vanno in un campo del per il tracciamento dello stato.

I client dovrebbero periodicamente validare le prove contro i mint per rilevare credenziali precedentemente spese. Sono consentiti event token multipli per mint, e gli event della cronologia delle spese aiutano gli utenti a tracciare le transazioni anche se sono facoltativi.

Modello di Sicurezza:

Tutti i dati sensibili usano la cifratura NIP-44. La chiave privata del wallet non appare mai in chiaro. Poiché i relay memorizzano blob cifrati senza comprenderne il contenuto, lo stato del wallet rimane privato anche su relay non fidati.

Implementazioni:

I wallet che supportano NIP-60 includono Nutsack e eNuts. Client come Ridestr usano NIP-60 per la sincronizzazione cross-device, permettendo agli utenti di ricaricare dal desktop e spendere dal mobile senza trasferimenti manuali.

È tutto per questa settimana. Stai costruendo qualcosa o hai notizie da condividere? Contattaci via DM NIP-17 o trovaci su Nostr.

Nostr Compass #10

Wed, 18 Feb 2026 00:00:00 +0000

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

Questa settimana: Prende forma un livello di cache locale per Blossom, con progetti indipendenti che convergono sull’accesso offline ai media per Android. Alby lancia un sandbox per sviluppatori NWC per costruire e testare integrazioni Nostr Wallet Connect senza rischiare fondi reali. Nello stesso arco di giorni arrivano due proposte concorrenti per la comunicazione di agenti AI su Nostr, firmate da autori diversi. fiatjaf elimina i campi inutilizzati da NIP-11, rimuovendo policy di riservatezza, retention, codici paese e tag sulle preferenze comunitarie che gli operatori relay non avevano mai adottato. NIP-85 viene unito con linee guida sulla scoperta dei provider di servizi per le Trusted Assertions. Un nuovo tag D in NIP-52 abilita l’indicizzazione temporale a granularità giornaliera per gli eventi calendario. Tra i nuovi progetti: Mapnolia per la distribuzione decentralizzata di tile cartografiche, Pika per la messaggistica cifrata con MLS, Keep per la firma a soglia FROST su Android, Hashtree per lo storage content-addressed con integrazione Nostr, e Prism per condividere contenuti su Nostr da qualsiasi app Android. Primal Android unisce 11 PR NWC aggiungendo supporto doppio wallet e gestione automatica del ciclo di vita del servizio. Mostro Mobile rilascia un wallet Lightning integrato tramite integrazione NWC. Notedeck si prepara al rilascio sull’App Store Android, mentre HAVEN raggiunge la v1.2.0-rc3 con supporto multi-npub e backup cloud. Gli approfondimenti di questa settimana coprono il sistema Trusted Assertions di NIP-85 per delegare i calcoli del Web of Trust ai provider di servizi, e il protocollo Calendar Events di NIP-52 a seguito dell’aggiornamento per l’indicizzazione a granularità giornaliera.

Notizie

Emerge un Livello di Cache Locale per Blossom

Diversi progetti indipendenti stanno convergendo sullo stesso problema: l’accesso offline ai media Blossom su dispositivi mobili.

Morganite, una nuova app Android di greenart7c3 (lo sviluppatore dietro Amber e Citrine), implementa il caching lato client per i media Blossom. Gli utenti possono accedere a immagini e file precedentemente visualizzati senza connessione di rete.

Aerith ha rilasciato la v0.2 con etichettatura delle immagini, operazioni bulk di mirror/tag/eliminazione, filtraggio per etichetta e tipo di file, più il supporto iniziale alla cache locale Blossom. Aerith è un’interfaccia di gestione per utenti che archiviano media su più server Blossom e necessitano di organizzare e replicare i propri blob.

Una nuova guida all’implementazione della cache locale nella specifica Blossom documenta lo storage blob lato client, mentre Prism (dello stesso sviluppatore di Aerith) aggiunge l’integrazione Blossom upload al proprio flusso share-to-Nostr su Android. Quattro progetti indipendenti hanno convergito sullo stesso problema questa settimana: un’app di caching dedicata, un gestore media, una specifica di riferimento e uno strumento di condivisione con integrazione Blossom, tutti con storage locale persistente oltre il semplice upload-e-recupero.

Sandbox NWC per Sviluppatori di Alby

Alby ha lanciato un ambiente sandbox per gli sviluppatori che lavorano con Nostr Wallet Connect (NIP-47). Il sandbox offre un servizio NWC wallet ospitato dove gli sviluppatori possono creare connessioni di test e inviare pagamenti simulati senza collegare un vero wallet Lightning, osservando in tempo reale il ciclo completo richiesta/risposta degli eventi NWC. Gli sviluppatori generano una stringa di connessione nostr+walletconnect:// dal sandbox e la passano al proprio client. Il sandbox mostra poi il kind 23194 (richiesta) e il kind 23195 (risposta) risultanti mentre scorrono tra client e wallet service.

Questo abbassa la barriera per le nuove integrazioni NWC. In precedenza, i test richiedevano un wallet Lightning personale o un servizio NWC self-hosted. Il sandbox astrae questa complessità, dando agli sviluppatori un ciclo di feedback immediato per implementare i metodi pay_invoice, get_balance, make_invoice, lookup_invoice e list_transactions su un endpoint NWC attivo.

Arrivano le Proposte di NIP per Agenti AI

Proposte per la comunicazione di agenti AI su Nostr sono apparse a distanza di giorni l’una dall’altra, affrontando il problema da angolazioni diverse.

NIP-XX: AI Agent Messages di joelklabo definisce un protocollo completo per l’interazione con agenti AI: kind di eventi per prompt, risposte, delta di streaming, aggiornamenti di stato, telemetria degli strumenti, errori, cancellazioni e scoperta delle capacità. Un evento di scoperta ai.info (kind 31340, sostituibile) permette agli agenti di annunciare i modelli supportati, gli strumenti con i relativi schemi, il supporto allo streaming e i limiti di frequenza. La proposta di joelklabo include la correlazione delle esecuzioni tramite prompt ID, la gestione delle sessioni, la riconciliazione dello stream con ordinamento sequenziale e indicazioni NIP-59 per la privacy dei metadata.

NIP-AE: Agents di pablof7z adotta un approccio diverso, definendo kind per l’istanziazione degli agenti: definizioni e lezioni. Si tratta dei tipi di eventi che pablof7z usa in TENEX, il sistema di apprendimento autonomo costruito su Nostr. Una proposta complementare, NIP-AD: MCP Server and Skill Announcements, sempre di pablof7z, definisce eventi per annunciare server Model Context Protocol e skill su Nostr. I commenti NIP-22 sono supportati, così la community può discutere e valutare i server MCP direttamente su Nostr.

NIP-XX copre la comunicazione completa degli agenti, mentre NIP-AE e NIP-AD si occupano di identità e scoperta degli strumenti. Queste proposte potrebbero convergere in uno standard unificato o coesistere come livelli complementari.

Rilasci

HAVEN v1.2.0-rc3

HAVEN, il relay personale all-in-one che raggruppa quattro funzioni relay con un server media Blossom, ha raggiunto la v1.2.0-rc3. Questa release candidate aggiunge il supporto per più npub, permettendo a una singola istanza HAVEN di servire diverse identità Nostr. Le RC precedenti avevano aggiunto i flag --from-cloud e --to-cloud per il backup cloud (RC2) e corretto un bug di doppio conteggio nel Web of Trust (RC1).

Mostro Mobile v1.2.0: Wallet Lightning Integrato

Mostro Mobile, il client mobile per l’exchange Bitcoin P2P Mostro (v1.1.0 coperto la settimana scorsa), ha rilasciato la v1.2.0 con un wallet Lightning integrato attraverso la completa integrazione NWC (NIP-47). Acquirenti e venditori non devono più cambiare app per gestire le fatture. L’app rileva le hold invoice per i venditori e le paga automaticamente tramite il wallet collegato, mentre gli acquirenti ricevono la generazione automatica delle fatture. Il rilascio fa seguito alla v1.1.1 pubblicata all’inizio della settimana, che aggiungeva il supporto multi-nodo Mostro con un registro curato di istanze fidate, il recupero dei metadata kind 0 per la visualizzazione dei nodi, la gestione di nodi personalizzati tramite pubkey e il fallback automatico quando un nodo selezionato va offline.

Sul lato server, Mostro v0.16.2 è arrivato con correzioni per i pagamenti doppi delle dev fee, il rate limiting sull’endpoint RPC di validazione password e la corretta pulizia delle dispute alla cancellazione cooperativa.

Un nuovo progetto companion, mostro-skill, consente agli agenti di fare trading su Mostro tramite Nostr.

Aerith v0.2

Aerith, il gestore di immagini Blossom, ha rilasciato la v0.2 con etichette per l’organizzazione dei media, operazioni bulk di mirror/tag/eliminazione tra server, filtraggio per etichetta e tipo di file, più il supporto iniziale alla cache locale. Vedi la sezione Notizie per il contesto sul trend più ampio della cache locale.

Mapnolia: Tile Cartografiche Decentralizzate su Nostr

Mapnolia è un nuovo server di dati geospaziali che suddivide gli archivi di tile cartografiche PMTiles in regioni geografiche e le annuncia su Nostr per la scoperta decentralizzata. Pubblica eventi parametrizzati sostituibili kind 34444 sui relay Nostr contenenti un indice completo dei chunk di tile con metadati dei layer, regioni geohash, riferimenti ai file e dettagli del server Blossom.

I client scoprono e recuperano i dati cartografici attraverso la rete Nostr invece dei server di tile centralizzati, con eventi di annuncio che portano metadati sufficienti a richiedere solo le regioni geografiche necessarie dai server Blossom elencati. Mapnolia è il primo progetto a portare la distribuzione di dati geospaziali su Nostr, aprendo possibilità per applicazioni cartografiche con supporto offline.

Pika: Messaggistica Cifrata con Marmot

Pika è una nuova app di messaggistica end-to-end cifrata per iOS e Android che usa il protocollo Marmot, che stratifica il Messaging Layer Security (MLS) sui relay Nostr. L’architettura separa le responsabilità in un core Rust (pika_core) che gestisce lo stato MLS e la cifratura/decifratura dei messaggi sui relay Nostr, con shell UI native snelle in SwiftUI (iOS) e Kotlin (Android). Lo stato scorre unidirezionalmente: la UI invia azioni all’attore Rust, che modifica lo stato e restituisce snapshot con numeri di revisione alla UI tramite binding UniFFI e JNI.

Pika si unisce a un campo in crescita di messenger MLS-on-Nostr insieme a White Noise, Vector e 0xchat. Tutti usano i relay Nostr come livello di trasporto per il ciphertext cifrato MLS, rendendo gli operatori relay incapaci di leggere il contenuto dei messaggi. Pika usa il Marmot Development Kit (MDK) per la propria implementazione MLS e nostr-sdk per la connettività relay.

Keep: Firma a Soglia FROST per Android

Keep è una nuova applicazione Android per la firma a soglia FROST dove nessun singolo dispositivo detiene la chiave privata completa. Implementa NIP-55 (Android Signer) e NIP-46 (firma remota), così i client Nostr compatibili possono richiedere firme mantenendo il materiale crittografico distribuito tra dispositivi. Le configurazioni predefinite sono 2-di-3 e 3-di-5, ma è supportata qualsiasi soglia t-di-n.

La cerimonia di generazione distribuita delle chiavi (DKG) di Keep avviene sui relay Nostr usando kind di eventi personalizzati: kind 21101 per gli annunci di gruppo, kind 21102 per i polinomi di commitment del round 1 (trasmessi pubblicamente) e kind 21103 per le share segrete del round 2 (cifrate NIP-44 punto-a-punto tra i partecipanti). Lo scalare della chiave privata di gruppo non viene mai calcolato né assemblato durante il DKG. Ogni dispositivo detiene solo la propria share di valutazione polinomiale, e qualsiasi t share può produrre una firma Schnorr valida attraverso un protocollo commit-then-sign a due round. La firma da 64 byte risultante è indistinguibile da una firma Schnorr a singolo firmatario. Internamente, Keep usa il crate frost-secp256k1-tr della Zcash Foundation con il Taproot tweaking, così la chiave pubblica di gruppo funziona direttamente come un npub Nostr.

Keep si unisce alla famiglia di progetti Frostr insieme a Igloo Desktop, Igloo for Android, Frost2x e Igloo for iOS, ampliando le opzioni per la gestione a soglia delle chiavi su Nostr.

Prism: Condividi Qualsiasi Cosa su Nostr da Android

Prism è una nuova app Android (Kotlin/Jetpack Compose, API 26+) che si registra come target di condivisione di sistema, permettendo agli utenti di pubblicare testo, URL, immagini e video su Nostr da qualsiasi app del proprio telefono. Gli URL condivisi passano attraverso uno stripping dei parametri di tracciamento prima di essere composti in note. Prism recupera i metadata OpenGraph per generare anteprime link ricche e rende i riferimenti Nostr nativi (note1, nevent1) inline.

Il motore di pianificazione usa un approccio ibrido AlarmManager/WorkManager per aggirare le ottimizzazioni della batteria Android: AlarmManager gestisce la temporizzazione precisa dei wake-up mentre i task WorkManager urgenti garantiscono la consegna, con retry a backoff esponenziale per gli scenari offline. I caricamenti media avvengono su server Blossom configurabili con generazione di thumbnail per immagini e frame video. Tutta la firma degli eventi è delegata a signer esterni NIP-55 come Amber, con supporto multi-account per passare tra identità. Prism supporta anche i post NIP-84 (Highlights). Dello stesso sviluppatore di Aerith.

Hashtree: Storage Content-Addressed con Integrazione Nostr

Hashtree è un sistema di storage blob content-addressed basato su filesystem che pubblica radici Merkle su Nostr per creare indirizzi npub/percorso mutabili. Il sistema usa uno “storage stupido” che funziona con qualsiasi key-value store, suddividendo il contenuto in blocchi da 2MB ottimizzati per i caricamenti Blossom. A differenza di BitTorrent, non è necessaria alcuna computazione attiva delle prove Merkle: basta archiviare e recuperare i blob per hash.

L’integrazione Nostr abilita URL git remoti come htree://npub.../repo-name per il cloning di repository, con comandi come htree publish mydata <hash> per pubblicare hash di contenuto agli indirizzi npub.../mydata. Il CLI completo supporta sia la modalità di storage cifrata (predefinita) che quella pubblica, il pinning dei contenuti, il push ai server Blossom e la gestione delle identità Nostr. Ogni elemento archiviato è o raw bytes o un nodo dell’albero, fornendo una base per la distribuzione decentralizzata di contenuti attraverso la rete relay di Nostr.

Espy: Cattura Palette Colori su Shakespeare

Espy, costruito sulla piattaforma Shakespeare, permette agli utenti di catturare palette colori da foto e condividerle come eventi Nostr. Shakespeare è un costruttore di app assistito da AI che autentica gli utenti tramite estensioni browser NIP-07 e fornisce connettività relay Nostr integrata, così gli sviluppatori pubblicano app senza implementare la propria gestione delle chiavi o il proprio pool relay. Espy estrae i colori dominanti dall’input della fotocamera in schede palette condivisibili e scopribili tramite i feed Nostr standard.

Flotilla 1.6.4

Flotilla, il client Nostr in stile Discord di hodlbod che organizza i relay come gruppi, ha rilasciato la 1.6.4. La famiglia di progetti Coracle è migrata da GitHub a un’istanza Gitea self-hosted. Questo rilascio aggiunge notifiche push tramite NIP-9a e un flusso per la ricezione wallet, oltre a inserzioni classificate e supporto agli URL degli spazi. I miglioramenti all’interfaccia includono modal e gestione delle notifiche riorganizzati. Il muting delle stanze e gli inset safe area su mobile completano le modifiche, insieme a correzioni per i caricamenti immagini su Safari e i dettagli degli eventi calendario.

Shosho v0.12.0

Shosho, l’app mobile di live-streaming con integrazione Nostr, ha rilasciato la v0.12.0. Questo rilascio aggiunge Clip video con risposte in-player e integrazione emoji personalizzate. La protezione dei thread blocca lo spam da menzione indiretta, e una nuova funzione di condivisione QR permette agli utenti di scambiare profili offline. Una nuova modalità di riproduzione orizzontale offre agli stream un’esperienza di visione in stile Twitch, e la schermata di esplorazione ora mostra i clip dei creator insieme agli stream in diretta.

Granary v10.0

Granary, una libreria di traduzione per il web sociale che converte dati tra Nostr, Bluesky, ActivityPub e altre piattaforme in un formato comune, ha rilasciato la v10.0 con modifiche incompatibili. Il rilascio passa gli ID ActivityStreams 1 predefiniti di Nostr da bech32 a hex e aggiunge un supporto Nostr esteso tra cui il parsing delle menzioni NIP-27 e i tag degli articoli. Una nuova opzione di output multiplo tra i converter permette agli sviluppatori di tradurre tra protocolli in batch.

Nostr MCP Server v3.0.0

Nostr MCP Server, un server Model Context Protocol che consente agli agenti AI di interagire con la rete Nostr, ha rilasciato la v3.0.0. Questo rilascio principale aggiunge azioni sociali (follow, reazioni, repost, risposte) e gestione delle liste relay con supporto NIP-65 più autenticazione opzionale NIP-42. Sono nuovi anche i messaggi diretti tramite NIP-17 e NIP-44. Il rilascio si affianca alle proposte di NIP per agenti AI di questa settimana come strumenti pratici per gli agenti che operano su Nostr.

Aegis v0.3.8

Aegis, il signer Nostr cross-platform, ha rilasciato la v0.3.8 con supporto UI multilingua e un gestore di aggiornamenti incrementale per il proprio browser di app Nostr integrato. Il nuovo meccanismo di aggiornamento calcola il diff in modo incrementale rispetto allo stato locale, mantenendo aggiornata la directory in-app delle web app Nostr con un consumo di banda ridotto. Il rilascio introduce anche un caching del materiale crittografico da 5 minuti per ridurre i round-trip al database quando si firmano più eventi in successione.

SNSTR v0.3.1

SNSTR (Secure Nostr Software Toolkit for Renegades), una libreria TypeScript per il protocollo Nostr, ha rilasciato la v0.3.1. Il rilascio aggiunge guardie di verifica dei pacchetti che assicurano che tutti i punti di ingresso siano inclusi nei tarball npm, con verifica CI su Node e Bun. La v0.3.0 è uscita nella stessa settimana.

Citrine v2.0.0-pre1

Citrine, il relay Nostr per Android di greenart7c3, ha rilasciato la v2.0.0-pre1 con miglioramenti delle prestazioni tramite indici del database ottimizzati e una migliore gestione delle coroutine Kotlin. Il rilascio migliora anche il supporto per l’hosting di web app, con ogni app ora in esecuzione sulla propria porta.

Aggiornamenti dei Progetti

Primal Android: Espansione dell’Infrastruttura NWC

Primal Android ha unito 11 PR legate a NWC questa settimana, continuando il lavoro avviato due settimane fa. Questa tornata aggiunge il supporto NWC per doppio wallet, avvio/arresto automatico del servizio legato alle notifiche del backend, routing delle connessioni per tipo di wallet e corretta pulizia dei dati all’eliminazione del wallet. Il servizio NWC ora gestisce il proprio ciclo di vita in base allo stato della connessione wallet, riducendo l’intervento manuale dell’utente.

Notedeck: Preparazione all’App Store Android

Notedeck, il client Nostr multi-piattaforma del team Damus, ha unito la preparazione al rilascio sull’App Store Android questa settimana. La PR aggiunge un piano di conformità UGC (User Generated Content) richiesto da Google Play, inclusa una schermata di accettazione dei Termini di Servizio, il blocco degli utenti tramite menu contestuali e impostazioni, la funzionalità NIP-56 (Segnalazione) che pubblica eventi di segnalazione sui relay, e una sezione di impostazioni per Contenuto e Sicurezza. È stata aggiunta l’infrastruttura di build per generare APK firmati e AAB (Android App Bundle) tramite nuovi target Makefile. Un documento EULA stabilisce un requisito di età di 17 anni e disclaimer specifici per Nostr riguardo ai contenuti decentralizzati. Le funzionalità di conformità stesse arriveranno in PR successive; questo merge pone le basi documentali e di firma.

Sul fronte Damus iOS, è stata corretta una regressione del caricamento infinito in cui lo spinner persisteva indefinitamente dopo che il contenuto era stato caricato.

Nostria: Relay di Scoperta e Correzioni DM

Nostria, il client Nostr cross-platform focalizzato sulla scala globale, ha unito 9 PR questa settimana. La più importante aggiunge l’auto-inizializzazione dei Discovery Relay per la ricerca dei profili, garantendo ai nuovi utenti una connettività relay funzionante senza configurazione manuale. Altre correzioni riguardano l’avvolgimento del testo nelle textarea DM, il riempimento del viewport per i video a schermo intero, l’estrazione dei metadata degli articoli nelle anteprime repost e la risoluzione degli URI nostr: nelle notifiche.

Camelus: Migrazione a Riverpod v3

Camelus, il client Nostr basato su Flutter, ha unito 5 PR questa settimana incentrate su una migrazione all’API Riverpod v3 e un refactoring del feed generico. Una cache delle note incorporate evita fetch ridondanti ai relay per le note citate.

Aggiornamenti NIP

Modifiche recenti al repository NIPs:

Uniti:

NIP-85: Scoperta dei Provider di Servizi: vitorpamplona ha aggiunto indicazioni sulla scoperta da parte dei client dei provider di servizi NIP-85 Trusted Assertions, inclusi gli hint relay e le chiavi di servizio specifiche per algoritmo. Vedi l’approfondimento per la copertura completa.
NIP-11: Pulizia delle Informazioni Relay: fiatjaf ha rimosso privacy_policy, l’array retention, relay_countries e il blocco delle preferenze comunitarie da NIP-11. Gli operatori relay raramente popolavano questi campi e i client non vi agivano sopra.
NIP-52: Tag di Timestamp a Granularità Giornaliera: staab ha aggiunto un tag D obbligatorio a NIP-52 per gli eventi calendario basati sul tempo (kind 31923) che rappresenta il timestamp Unix a granularità giornaliera, calcolato come floor(unix_seconds / 86400). Più tag D coprono eventi multi-giorno, abilitando un efficiente indicizzazione temporale senza dover analizzare i timestamp completi.
NIP-47: Semplificazione: La PR di semplificazione discussa nel numero #9 è stata unita questa settimana, rimuovendo multi_pay_invoice e multi_pay_keysend da NIP-47 (Nostr Wallet Connect). Vedi il numero #8 per l’approfondimento completo sul protocollo NWC.

PR Aperte e Discussioni:

NIP-74: Podcast: Coperto nel numero #8, questa proposta di specifica per i podcast ha visto un acceso dibattito questa settimana. staab ha notato che esistono già almeno tre standard podcast concorrenti in circolazione, e derekross ha indicato un’implementazione esistente risalente a sei mesi fa con app e podcast attivi. Il percorso da seguire richiede una convergenza tra le implementazioni prima che possa essere assegnato un numero NIP.
NIP-XX: AI Agent Messages: joelklabo propone un protocollo completo di comunicazione per agenti AI con kind di eventi per prompt, risposte, streaming, telemetria degli strumenti, errori e scoperta delle capacità. Vedi la sezione Notizie per la copertura di tutte le proposte AI di questa settimana.
NIP-PNS: Private Note Storage: il sistema di note private di jb55 definisce eventi kind 1080 per archiviare note personali cifrate sui relay senza rivelare chi le ha scritte. Lo schema deriva una coppia di chiavi pseudonima deterministica dalla nsec dell’utente tramite HKDF: pns_key = hkdf_extract(ikm=device_key, salt="nip-pns"), quindi genera una coppia di chiavi secp256k1 da quella chiave derivata. Una seconda derivazione produce una chiave di cifratura simmetrica: pns_nip44_key = hkdf_extract(ikm=pns_key, salt="nip44-v2"). Le note interne sono cifrate con NIP-44 v2 usando questa chiave e pubblicate sotto la pubkey pseudonima, così i relay vedono eventi kind 1080 da un’identità non collegata alla chiave principale dell’utente. A differenza dei gift wrap NIP-59, PNS non è soggetto a spam (la chiave pseudonima è deterministica, non casuale) e non porta metadata pubblici (non servono tag p poiché non c’è destinatario). Questa settimana, jb55 ha pubblicato le conclusioni tratte dall’implementazione di PNS nel backend Rust di Notedeck (modulo enostr::pns). Ha identificato che la chiamata hkdf_extract della spec è ambigua perché HKDF secondo RFC 5869 ha due fasi (Extract ed Expand) che producono output diversi, e la maggior parte delle librerie si aspetta entrambe. Ha chiarito che pns_nip44_key aggira il normale accordo di chiavi ECDH di NIP-44 e viene usata direttamente come conversation key, un dettaglio che gli implementatori devono conoscere poiché la maggior parte delle librerie NIP-44 usa ECDH di default. Ha anche segnalato una variabile non definita nell’implementazione di riferimento TypeScript. La PR, originariamente dell’aprile 2025, è ora in fase di implementazione attiva.
NIP-AE: Agents: pablof7z definisce quattro kind di eventi per l’identità degli agenti su Nostr, tratti dal suo lavoro su TENEX. Il template base è kind 4199 (Agent Definition), che contiene titolo, descrizione del ruolo, istruzioni di sistema, dichiarazioni di strumenti e versione. I modificatori comportamentali risiedono nel kind 4201 (Agent Nudge), che usa i tag only-tool, allow-tool e deny-tool per il controllo delle capacità in runtime. Gli agenti pubblicano ciò che apprendono come eventi kind 4129 (Agent Lesson), categorizzati e collegati alla definizione genitore tramite tag e, perfezionabili attraverso thread di commenti NIP-22. La verifica della proprietà usa kind 14199, un evento sostituibile in cui gli operatori umani elencano le proprie pubkey agente, stabilendo una catena bidirezionale quando abbinato al tag p del profilo kind 0 dell’agente.
NIP-AD: MCP Server and Skill Announcements: pablof7z definisce eventi per annunciare server Model Context Protocol e skill individuali su Nostr. Gli annunci di server MCP portano l’URL endpoint del server e la versione di protocollo supportata insieme a un elenco di strumenti disponibili con i relativi schemi di input. I commenti NIP-22 sono supportati sugli annunci di server, così la community può discutere e valutare i server MCP direttamente su Nostr.
NIP-73: OSM Tag Kind: DestBro propone di aggiungere gli identificatori OpenStreetMap a NIP-73 (External Content IDs), che standardizza come gli eventi Nostr referenziano contenuti esterni come libri (ISBN), film (ISAN), feed podcast (GUID), geohash e URL tramite tag i e k. Il kind OSM proposto permetterebbe agli eventi di referenziare elementi cartografici specifici (edifici, strade, parchi) tramite il loro ID nodo o way OpenStreetMap, collegando i contenuti Nostr al database geografico aperto.
NIP-XX: Responsive Image Variants: woikos propone di estendere gli eventi di metadata file NIP-94 con tag per varianti di immagini responsive a risoluzioni diverse. I client potrebbero selezionare la variante appropriata in base alle dimensioni del display e alle condizioni di rete, riducendo il consumo di banda per gli utenti mobile che visualizzano immagini ad alta risoluzione ospitate su server Blossom.

NIP Deep Dive: NIP-85 (Trusted Assertions)

NIP-85 definisce un sistema per delegare calcoli costosi a provider di servizi fidati che pubblicano i risultati firmati come eventi Nostr. I punteggi Web of Trust e le metriche di engagement richiedono la scansione di molti relay e l’elaborazione di grandi volumi di eventi, un lavoro impraticabile su dispositivi mobili. Il merge di questa settimana ha aggiunto indicazioni sul processo di scoperta da parte dei client di questi provider.

Delega:

Calcolare il punteggio Web of Trust di un utente richiede la scansione dei grafi di follow per diversi livelli su molti relay, e il calcolo accurato dei conteggi follower comporta la deduplicazione sull’intera rete relay. I dispositivi mobili e i client browser non possono eseguire queste operazioni, eppure i risultati sono essenziali per il filtraggio dello spam e il ranking dei contenuti. NIP-85 colma questo divario permettendo agli utenti di designare provider fidati per eseguire i calcoli e pubblicare i risultati come eventi Nostr standard.

Design del Protocollo:

NIP-85 usa quattro kind di eventi per le asserzioni su diversi tipi di soggetti. Le asserzioni sugli utenti (kind 30382) portano il conteggio follower, i conteggi post/risposte/reazioni, gli importi zap, il rank normalizzato (0-100), i topic comuni e le ore attive:

{
 "id": "<event hash>",
 "pubkey": "<service pubkey>",
 "created_at": 1739836800,
 "kind": 30382,
 "tags": [
 ["d", "e88a691e98d9987c964521dff60025f60700378a4879180dcbbb4a5027850411"],
 ["rank", "89"],
 ["followers", "4521"],
 ["first_created_at", "1609459200"],
 ["post_cnt", "1283"],
 ["reply_cnt", "647"],
 ["reactions_cnt", "8920"],
 ["zap_amt_recd", "850000"],
 ["zap_amt_sent", "320000"],
 ["zap_cnt_recd", "412"],
 ["zap_cnt_sent", "198"],
 ["zap_avg_amt_day_recd", "1150"],
 ["zap_avg_amt_day_sent", "430"],
 ["reports_cnt_recd", "2"],
 ["reports_cnt_sent", "0"],
 ["t", "nostr"],
 ["t", "bitcoin"],
 ["active_hours_start", "14"],
 ["active_hours_end", "22"]
 ],
 "content": "",
 "sig": "<service key signature>"
}

Le asserzioni sugli eventi (kind 30383) valutano le singole note con il conteggio commenti, citazioni, repost, reazioni e dati zap:

{
 "id": "<event hash>",
 "pubkey": "<service pubkey>",
 "created_at": 1739836800,
 "kind": 30383,
 "tags": [
 ["d", "<target event id>"],
 ["rank", "72"],
 ["comment_cnt", "45"],
 ["quote_cnt", "12"],
 ["repost_cnt", "89"],
 ["reaction_cnt", "310"],
 ["zap_cnt", "23"],
 ["zap_amount", "125000"]
 ],
 "content": "",
 "sig": "<service key signature>"
}

Per gli eventi indirizzabili (articoli long-form, pagine wiki), kind 30384 applica le stesse metriche di engagement su tutte le versioni collettivamente. Kind 30385 valuta gli identificatori esterni (libri, film, siti web, luoghi, hashtag) referenziati tramite NIP-73 (External Content IDs), che standardizza come gli eventi Nostr referenziano contenuti esterni tramite tag i e k:

{
 "id": "<event hash>",
 "pubkey": "<service pubkey>",
 "created_at": 1739836800,
 "kind": 30385,
 "tags": [
 ["d", "isbn:9780765382030"],
 ["k", "isbn"],
 ["rank", "94"],
 ["comment_cnt", "67"],
 ["reaction_cnt", "203"]
 ],
 "content": "",
 "sig": "<service key signature>"
}

Ogni asserzione è un evento indirizzabile sostituibile dove il tag d contiene il soggetto: una pubkey, un ID evento, un indirizzo evento o un identificatore NIP-73. I provider di servizi firmano questi eventi con le proprie chiavi, e i client li valutano in base alle relazioni di fiducia.

Scoperta dei Provider:

Gli utenti dichiarano quali provider di asserzioni si fidano pubblicando eventi kind 10040. Ogni voce specifica il tipo di asserzione con la pubkey del provider e l’hint relay, più varianti di algoritmo opzionali:

{
 "id": "<event hash>",
 "pubkey": "<user pubkey>",
 "created_at": 1739836800,
 "kind": 10040,
 "tags": [
 ["30382:rank", "4fd5e210...", "wss://nip85.nostr.band"],
 ["30382:rank", "3d842afe...", "wss://nostr.wine"],
 ["30382:zap_amt_sent", "4fd5e210...", "wss://nip85.nostr.band"],
 ["30383:rank", "4fd5e210...", "wss://nip85.nostr.band"]
 ],
 "content": "",
 "sig": "<user signature>"
}

Gli utenti possono cifrare l’elenco dei tag nel .content usando NIP-44 per mantenere private le proprie preferenze di provider. I client costruiscono un elenco di provider controllando quali provider si fidano i propri account seguiti, creando un livello di reputazione decentralizzato per i provider di asserzioni stessi.

Modello di Sicurezza:

I provider devono usare chiavi di servizio diverse per algoritmi distinti, e una chiave unica per utente quando gli algoritmi sono personalizzati, impedendo la correlazione incrociata delle query tra utenti. Ogni chiave di servizio ottiene un evento di metadata kind 0 che descrive il comportamento dell’algoritmo, dando agli utenti trasparenza su ciò in cui ripongono la propria fiducia. Gli eventi di asserzione dovrebbero essere aggiornati solo quando i dati sottostanti cambiano effettivamente, prevenendo traffico relay non necessario e permettendo ai client di memorizzare nella cache i risultati con fiducia.

Adozione Attuale:

NIP-85 formalizza un pattern già emerso informalmente. Il server cache di Primal calcola le metriche di engagement e i punteggi Web of Trust. Antiprimal, coperto nel numero #9, collega questi calcoli ai client Nostr standard usando i kind di eventi NIP-85. Nostr.band gestisce il relay wss://nip85.nostr.band referenziato negli esempi della spec stessa, servendo eventi di asserzione per i dati del proprio indice di ricerca. Sul lato client, Amethyst (scritto da vitorpamplona, anche autore di questo NIP) ha un supporto sperimentale alle Trusted Assertions nella propria libreria quartz, che analizza gli eventi di asserzione e le dichiarazioni dei provider di servizi. Vertex calcola metriche Web of Trust simili ma ha scelto un approccio diverso, usando una API diretta invece degli eventi NIP-85, citando il problema della scoperta e l’overhead computazionale delle architetture basate su asserzioni. Con NIP-85, qualsiasi client può consumare asserzioni da qualsiasi provider attraverso un formato di evento standard, e i provider competono sull’accuratezza mentre gli utenti scelgono di chi fidarsi.

NIP Deep Dive: NIP-52 (Calendar Events)

NIP-52 definisce gli eventi calendario su Nostr, dando ai client un modo standard per rappresentare e scoprire occorrenze in momenti specifici o tra momenti. Il merge del tag D di questa settimana ha aggiunto l’indicizzazione a granularità giornaliera, completando un elemento mancante nell’infrastruttura di query della spec.

Due Tipi di Evento:

NIP-52 separa gli eventi calendario in due kind in base alla precisione temporale. Gli eventi basati sulla data (kind 31922) rappresentano occorrenze che durano un’intera giornata come festività o festival multi-giorno. Usano stringhe di data ISO 8601 nei tag start e end opzionale, senza considerazioni sul fuso orario:

{
 "id": "<event hash>",
 "pubkey": "<event creator pubkey>",
 "created_at": 1735689600,
 "kind": 31922,
 "content": "Annual celebration of Bitcoin's genesis block",
 "tags": [
 ["d", "bitcoin-independence-day-2026"],
 ["title", "Bitcoin Independence Day"],
 ["start", "2026-01-03"],
 ["end", "2026-01-04"],
 ["location", "Worldwide"],
 ["g", "u4pruydqqv"],
 ["t", "bitcoin"],
 ["p", "<organizer-pubkey>", "wss://relay.example.com", "host"],
 ["r", "https://bitcoinindependenceday.com"]
 ],
 "sig": "<event creator signature>"
}

Gli eventi basati sul tempo (kind 31923) rappresentano momenti specifici con timestamp Unix nei tag start e end opzionale, più identificatori di fuso orario IANA (start_tzid, end_tzid) per la visualizzazione. Entrambi i kind sono eventi parametrizzati sostituibili, così gli organizzatori aggiornano i dettagli pubblicando un nuovo evento con lo stesso tag d.

Calendari e RSVP:

Gli eventi kind 31924 definiscono i calendari come collezioni, referenziando gli eventi tramite tag a che puntano agli eventi kind 31922 o 31923 tramite le loro coordinate di indirizzo:

{
 "id": "<event hash>",
 "pubkey": "<calendar owner pubkey>",
 "created_at": 1739836800,
 "kind": 31924,
 "content": "Nostr community events worldwide",
 "tags": [
 ["d", "nostr-community-calendar"],
 ["title", "Nostr Community Events"],
 ["a", "31923:<organizer-pubkey>:nostr-meetup-2026", "wss://relay.example.com"],
 ["a", "31922:<organizer-pubkey>:bitcoin-independence-day-2026"]
 ],
 "sig": "<calendar owner signature>"
}

Gli utenti possono mantenere più calendari (personale, lavoro, comunitario) e i client possono iscriversi ai calendari di pubkey specifiche. Gli eventi calendario possono includere un tag a che referenzia un calendario per richiedere l’inclusione, abilitando la gestione collaborativa dei calendari dove più utenti contribuiscono eventi a calendari che non possiedono.

Gli RSVP usano kind 31925, dove gli utenti pubblicano il proprio stato di partecipazione insieme a un indicatore opzionale libero/occupato:

{
 "id": "<event hash>",
 "pubkey": "<attendee pubkey>",
 "created_at": 1739836800,
 "kind": 31925,
 "content": "Looking forward to it",
 "tags": [
 ["a", "31923:<organizer-pubkey>:nostr-meetup-2026", "wss://relay.example.com"],
 ["e", "<kind 31923 event id>", "wss://relay.example.com"],
 ["d", "<unique-rsvp-id>"],
 ["status", "accepted"],
 ["fb", "busy"],
 ["p", "<organizer-pubkey>", "wss://relay.example.com"]
 ],
 "sig": "<attendee signature>"
}

I valori status validi sono “accepted”, “declined”, “tentative”, e il tag opzionale fb marca l’utente come libero o occupato per quel periodo. Gli eventi RSVP referenziano il tag a dell’evento calendario e portano il tag p dell’organizzatore, così il client dell’organizzatore può aggregare le risposte dai relay.

L’Aggiunta del Tag D:

Prima del merge di questa settimana, i client che interrogavano gli eventi in un intervallo di date dovevano recuperare tutti gli eventi da una pubkey o un calendario e filtrare lato client. Il nuovo tag D obbligatorio sugli eventi basati sul tempo (kind 31923) contiene un timestamp Unix a granularità giornaliera calcolato come floor(unix_seconds / 86400). Gli eventi multi-giorno portano più tag D, uno per giorno. I relay possono ora indicizzare gli eventi per giorno e rispondere a query filtrate in modo efficiente, trasformando quello che era un problema di filtraggio lato client in una ricerca nell’indice lato relay.

{
 "id": "<event hash>",
 "pubkey": "<event creator pubkey>",
 "created_at": 1739836800,
 "kind": 31923,
 "content": "Monthly meetup for Nostr developers in Austin",
 "tags": [
 ["d", "nostr-meetup-2026"],
 ["title", "Nostr Developer Meetup"],
 ["summary", "Talks and demos from local Nostr builders"],
 ["image", "https://example.com/meetup-banner.jpg"],
 ["start", "1740067200"],
 ["end", "1740078000"],
 ["start_tzid", "America/New_York"],
 ["end_tzid", "America/New_York"],
 ["D", "20139"],
 ["location", "Bitcoin Commons, Austin TX"],
 ["g", "9v6knb2pg"],
 ["p", "<organizer-pubkey>", "wss://relay.example.com", "host"],
 ["p", "<speaker-pubkey>", "wss://relay.example.com", "speaker"],
 ["t", "nostr"],
 ["t", "meetup"],
 ["r", "https://bitcoincommons.com"]
 ],
 "sig": "<event creator signature>"
}

Il valore D 20139 equivale a floor(1740067200 / 86400), collocando questo evento il 20 febbraio 2025. I client che interrogano “tutti gli eventi di questa settimana” inviano un filtro con il corrispondente intervallo D, e i relay restituiscono solo gli eventi corrispondenti.

Scelte di Design:

NIP-52 omette intenzionalmente gli eventi ricorrenti. La spec esclude completamente le regole di ricorrenza (RRULE da iCalendar), delegando quella complessità ai client. Un organizzatore pubblica eventi individuali per ogni occorrenza, mantenendo semplice il modello dati lato relay. I tag partecipante portano ruoli opzionali (“host”, “speaker”, “attendee”), e i tag di localizzazione possono includere tag geohash g per query spaziali insieme agli indirizzi leggibili.

Implementazioni:

Flockstr è il principale client calendario costruito su NIP-52. Coracle visualizza gli eventi calendario nel proprio feed sociale. L’aggiunta del tag D di questa settimana abilita l’indicizzazione temporale lato relay che entrambi i client possono usare per ridurre la banda quando si interrogano eventi in un intervallo di date specifico.

È tutto per questa settimana. Stai costruendo qualcosa o hai notizie da condividere? Vuoi che copriamo il tuo progetto? Contattaci via DM NIP-17 o trovaci su Nostr.

Nostr Compass #9

Wed, 11 Feb 2026 00:00:00 +0000

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

Questa settimana: Mostro rilascia la sua prima beta pubblica dopo tre anni di sviluppo, portando il trading P2P di Bitcoin su mobile via Nostr. OpenSats assegna la sedicesima ondata di grant Bitcoin, con Minibits Wallet che riceve un rinnovo per il suo wallet Cashu integrato con Nostr. Zapstore raggiunge la release stabile 1.0, segnando la maturazione dell’app store Android decentralizzato. Coracle 0.6.29 aggiunge topics e commenti sugli highlight. Igloo Desktop v1.0.3 introduce un importante hardening di sicurezza per la firma a soglia Frostr. Amber v4.1.2-pre1 migra all’architettura Flow. Angor raggiunge v0.2.5 con una UI di finanziamento rinnovata e configurazione server di immagini NIP-96. NostrPress viene lanciato come strumento che converte profili Nostr in blog statici. Antiprimal rilascia un gateway conforme agli standard che collega il cache server proprietario di Primal ai NIP standard di Nostr. Primal Android unisce 18 PR espandendo l’infrastruttura NWC con supporto doppio wallet, audit logging e il metodo lookup_invoice. diVine rilascia feed video API-first. L’SDK TypeScript di Marmot separa la sua app chat di riferimento in un repository autonomo e inizia la migrazione a ts-mls v2. Il repository NIPs unisce il conteggio approssimativo HyperLogLog per NIP-45 ed estrae i tag identità da kind 0. Un’ondata di proposte di vitorpamplona inizia a snellire sistematicamente i metadata kind 0. Nuove proposte di protocollo includono Nostr Relay Connect per il NAT traversal e Nostr Web Tokens per claim web firmati. Due approfondimenti chiudono il numero: il conteggio approssimativo HyperLogLog di NIP-45 per metriche eventi cross-relay, e il protocollo di file storage HTTP NIP-96, ora deprecato a favore di Blossom, mentre i progetti gestiscono la transizione tra i due standard media.

Notizie

Mostro Rilascia la Prima Beta Pubblica

Mostro, l’exchange Bitcoin peer-to-peer costruito su Nostr, ha rilasciato la sua app mobile v1.1.0, la prima beta pubblica del progetto dopo tre anni di sviluppo. L’app permette di scambiare Bitcoin direttamente usando Nostr per la coordinazione degli ordini, con Lightning per il settlement e nessun intermediario custodial.

Il rilascio introduce notifiche push con migliore affidabilità in background su Android, un sistema di logging opzionale che permette di catturare e condividere dati diagnostici quando si presentano problemi, aggiornamenti relay più fluidi con inizializzazione additiva, e raffinamenti UI di Fase 2 con supporto internazionalizzazione. L’app è disponibile su Zapstore e come download diretto da GitHub.

Mostro si unisce a Shopstr e Plebeian Market come applicazione commerciale nativa Nostr, con la distinzione di concentrarsi sulla coordinazione dello scambio fiat-Bitcoin. Il daemon Mostro sottostante gestisce il matching degli ordini e la risoluzione delle dispute attraverso relay Nostr.

Sedicesima Ondata di Grant Bitcoin di OpenSats

OpenSats ha annunciato grant a 17 progetti open-source. Il punto saliente per Nostr: Minibits Wallet, il wallet Android Cashu con supporto eventi wallet NIP-60 e integrazione nutzap, ha ricevuto un grant di rinnovo. Minibits usa eventi Nostr per memorizzare lo stato dei token ecash, rendendo i backup del wallet portabili tra dispositivi tramite sincronizzazione relay.

NostrPress: Dal Profilo Nostr al Blog Statico

NostrPress (blog.besoeasy.com) è un nuovo strumento che converte un profilo Nostr in un blog completamente statico deployabile ovunque. Chi pubblica articoli su Nostr tramite qualsiasi client può generare con NostrPress un sito web autonomo da quegli eventi, completo di hosting media locale e feed RSS.

Costruito con templating Nunjucks e JavaScript, NostrPress produce siti privi di lock-in di piattaforma. L’output generato è semplice HTML/CSS ospitabile su qualsiasi server di file statici, GitHub Pages, Netlify o un VPS personale. Lo strumento si unisce a Npub.pro e Servus come opzione per trasformare contenuti Nostr in siti web tradizionali.

Antiprimal: Gateway Conforme per il Cache di Primal

antiprimal (antiprimal.net), un nuovo progetto di Alex Gleason e del team Soapbox, è un gateway WebSocket che collega il cache server proprietario di Primal ai messaggi standard del protocollo Nostr. Primal offre funzionalità come statistiche eventi, ricerca contenuti e calcoli Web of Trust tramite wss://cache.primal.net/v1, ma accedervi richiede un formato messaggi proprietario con un campo cache non standard che i client Nostr ordinari non possono usare. Antiprimal traduce le richieste NIP standard nel formato di Primal e converte le risposte indietro.

Il gateway supporta query COUNT NIP-45 (reazioni, risposte, repost, conteggi zap, conteggi follower), ricerca NIP-50, informazioni relay NIP-11 e NIP-85 Trusted Assertions per i dati Web of Trust precalcolati di Primal. Un bot companion pubblica eventi NIP-85 kind 30382 (statistiche utente) e kind 30383 (engagement eventi) su relay configurabili. Il progetto è costruito con TypeScript su Bun e usa la libreria Nostrify. Creato il 6 febbraio, ha 53 commit nei suoi primi tre giorni di sviluppo ed è live su antiprimal.net.

Ikaros: Gateway di Messaggistica per Agenti AI su Signal e Nostr

Ikaros, un nuovo progetto del team Soapbox, è un gateway di messaggistica che permette ad agenti AI di comunicare attraverso DM crittografati sia su Signal che su Nostr. Il bridge usa l’Agent Client Protocol (ACP) per connettere qualsiasi assistente AI di coding compatibile ACP a reti di messaggistica reali. Tre pull request costituiscono la build iniziale del progetto.

La PR #1 implementa un adattatore completo per DM crittografati NIP-04 con supporto invio/ricezione, buffering delle risposte con flush esplicito al completamento, formati chiave privata nsec e hex, pubblicazione multi-relay con riconnessione automatica e un wizard di setup interattivo. L’adattatore usa nostr-tools v2.23.0 e aggiorna l’ACP SDK a v0.14.1.

La PR #2 corregge un drop silenzioso di messaggi causato da una race condition nell’aggiornamento della sessione: le notifiche in arrivo prima che la sessione fosse registrata nella mappa venivano perse, e il fix mette in buffer quelle notifiche per il replay al completamento della registrazione. La PR #3 aggiunge metadati di nome utente/UUID e gruppo Signal alle interazioni con l’agente, così l’agente AI sa con chi sta parlando e in quale gruppo. Il progetto apre un nuovo spazio di design: agenti AI raggiungibili via DM Nostr che possono anche essere contattati da Signal, o viceversa.

Campagna di Snellimento Kind 0

vitorpamplona ha aperto una serie di PR proponendo l’estrazione sistematica di dati dagli eventi kind 0 (metadata utente) in kind di eventi dedicati. La campagna affronta un problema crescente: col passare del tempo kind 0 ha accumulato campi che la maggior parte dei client non usa, gonfiando la dimensione di ogni fetch di profilo.

La PR #2216 (unita) sposta i tag identità (tag i) da kind 0 a un nuovo kind 10011, dato che l’adozione di questi tag è stata minima. La PR #2213 propone di spostare la verifica NIP-05 a kind 10008, il che permetterebbe di avere più identificatori NIP-05 per utente e di filtrare eventi per indirizzo NIP-05. La PR #2217 propone di estrarre i campi Lightning (lud06/lud16) in un nuovo kind, evitando che tutti i profili kind 0 portino campi relativi allo zap che interessano solo ai client con integrazione Lightning.

Le proposte hanno riacceso la discussione sulla questione più ampia della struttura di kind 0, inclusa la PR #1770, la proposta di lunga data per sostituire il JSON stringificato nel contenuto kind 0 con tag strutturati.

Il Supporto Relay NIP-70 è Critico per la Sicurezza della Messaggistica Crittografata

L’implementazione White Noise del protocollo Marmot ha identificato una lacuna critica nel supporto relay per NIP-70 (Protected Events) e NIP-42 (Authentication). I test hanno rivelato che i principali relay pubblici inclusi Damus, Primal e nos.lol rifiutano i protected event con errori blocked: event marked as protected invece di avviare la challenge di autenticazione richiesta.

Questa lacuna rompe la funzionalità di sicurezza chiave: NIP-70 abilita la cancellazione sicura dei KeyPackages MLS spesi, prevenendo attacchi “harvest now, decrypt later”. In assenza di supporto relay, i protocolli di messaggistica crittografata non possono proteggere dal futuro compromesso delle chiavi. White Noise ha disabilitato NIP-70 di default in risposta, mantenendo un flag opzionale per chi usa relay compatibili.

Invito all’azione per operatori relay: Implementate il flusso di autenticazione NIP-42 completo. Quando ricevete protected event, effettuate la challenge ai client per dimostrare la proprietà, poi accettate le scritture validate. Rifiutare protected event in assenza di autenticazione rompe le garanzie di sicurezza del protocollo da cui dipendono le applicazioni di messaggistica crittografata.

Rilasci

Coracle 0.6.29

Coracle (coracle.social), il client web di hodlbod, ha rilasciato 0.6.29. Il rilascio aggiunge la visualizzazione di topics e commenti sugli highlight kind 9802. Un nuovo elemento di navigazione liste fornisce accesso rapido alle liste curate dall’utente dalla UI principale. Sotto il cofano, Coracle è stato aggiornato a una nuova versione di Welshman, la libreria Nostr condivisa che alimenta la gestione relay e la gestione eventi di Coracle. La lista relay di default è stata aggiornata, e il tracking errori Glitchtip è stato rimosso dal codebase.

Igloo Desktop v1.0.3

Igloo Desktop, l’applicazione di firma a soglia FROST e gestione chiavi, ha rilasciato v1.0.3 con esteso hardening di sicurezza. Il rilascio introduce validazione IPC, isolamento Electron e controlli relay consapevoli di SSRF per la difesa contro server-side request forgery. Un nuovo flusso di onboarding e importazione share semplifica la distribuzione delle chiavi, la pianificazione relay ora include normalizzazione e merging prioritario, e l’architettura API Electron basata su preload migliora il confine di sicurezza tra renderer e processo principale. Un sistema keep-alive per il signer mantiene la stabilità delle sessioni di firma a soglia, e i miglioramenti UX di recovery riducono l’attrito del ripristino delle chiavi.

Amber v4.1.2-pre1

Amber, il signer di eventi Android, ha rilasciato v4.1.2-pre1 correggendo la visualizzazione mancante del punteggio di fiducia relay introdotta in v4.1.1, risolvendo problemi di parsing JSON per richieste encrypt/decrypt non-Nostr, e migrando il modello account da LiveData a Flow per una gestione dello stato più prevedibile. Il rilascio passa i segreti bunker a UUID completi e aggiorna a Gradle plugin 9.

Mostro Mobile v1.1.0 e Daemon v0.16.1

Vedi la sezione Notizie sopra per la copertura completa del rilascio mobile. Sul lato server, il daemon Mostro ha rilasciato v0.16.1, aggiungendo la pubblicazione automatica dei metadata NIP-01 kind 0 all’avvio (PR #575), così il daemon annuncia la propria identità alla rete quando va online. Il rilascio corregge anche la documentazione del calcolo delle dev fee (PR #571).

Angor v0.2.5

Angor (angor.io), il protocollo di finanziamento P2P decentralizzato costruito su Bitcoin e Nostr, ha rilasciato v0.2.5 con tre PR unite. La PR #649 riprogetta la sezione gestione Fondi (V2), sostituendo il layout precedente con un’interfaccia nuova per il tracking di singoli UTXO e posizioni di investimento. La PR #651 rinnova la InvoiceView con stili pulsanti aggiornati, dialog chiudibili, un nuovo comando “Copia Indirizzo”, supporto cancellazione per il monitoraggio indirizzi, e gestione migliorata del flusso investimenti. La PR #652 aggiunge server immagini NIP-96 (spec) configurabili nelle impostazioni, permettendo di scegliere quale endpoint di upload media gestisce le immagini e la documentazione dei progetti. La v0.2.4 era stata rilasciata la settimana precedente.

Ridestr v0.2.2 e v0.2.3

Ridestr, la piattaforma di rideshare decentralizzata coperta la settimana scorsa, ha continuato l’iterazione rapida con v0.2.2 (Bridge Payment Hotfix) e v0.2.3 dopo la v0.2.0 “RoadFlare Release”. L’hotfix v0.2.2 affronta un bug dove i pagamenti bridge Cashu cross-mint cancellavano automaticamente le corse mentre il pagamento era ancora in elaborazione o sarebbe eventualmente riuscito, prevenendo la cancellazione prematura delle corse su settlement più lenti. Il rilascio corregge anche lo sfarfallio della UI e le hitbox touch rotte sul pulsante “la mia posizione”. La v0.2.3 include ulteriori bug fix. Entrambi i rilasci includono APK separati per Ridestr (app passeggero) e Drivestr (app autista).

Nostr PHP 1.9.4

Nostr PHP (nostr-php.dev), la libreria helper PHP per il protocollo Nostr, ha rilasciato 1.9.4 aggiungendo una proprietà timeout configurabile alla classe request (PR #106). La novità permette di impostare durate di timeout personalizzate per le connessioni relay e le richieste messaggi, prevenendo blocchi indefiniti quando un relay non risponde o è lento a rispondere.

Zapstore v1.0.0

Zapstore (zapstore.dev), l’app store Android permissionless costruito su Nostr, ha raggiunto la milestone della release stabile 1.0 dopo mesi di release candidate.

Il rilascio 1.0 include miglioramenti di stabilità critici: gestione dello stato del pulsante install che assicura che Delete appaia immediatamente dopo il completamento dell’installazione, messaggi di errore user-friendly con dettagli tecnici espandibili, e un pulsante “Segnala problema” che invia DM crittografati via Nostr usando chiavi effimere. Tra le novità anche un nuovo schermo aggiornamenti con polling e tracking batch, un migliore watchdog per i download bloccati, limiti di download concorrenti dinamici basati sulle prestazioni del dispositivo, sincronizzazione più frequente dei pacchetti installati e logica di confronto versioni migliorata. Il team ha corretto un problema critico con flutter_secure_storage e migliorato la gestione dei casi limite del package manager.

La milestone rappresenta la maturazione della prima piattaforma dedicata di distribuzione app di Nostr, permettendo agli sviluppatori di pubblicare applicazioni Android direttamente verso i propri utenti, aggirando il gatekeeping degli app store centralizzati.

ZSP v0.3.1

ZSP, lo strumento CLI Go del team Zapstore che sostituisce il tooling di pubblicazione precedente di Zapstore per la firma e l’upload di app Android su relay Nostr, ha rilasciato v0.3.1. ZSP gestisce l’acquisizione APK da GitHub, GitLab, Codeberg, F-Droid o file locali, poi analizza i metadata, firma eventi Nostr (tramite chiave privata, bunker NIP-46 o estensione browser NIP-07), e carica i manufatti su server Blossom. Tra le novità: modalità offline completa per il linking del keystore anche in assenza di rete, header Content-Digest sugli upload Blossom per la conformità al protocollo, rilevamento corretto degli APK arm64-v8a dai repository F-Droid, fix dei parametri query trailing di GitLab e supporto completo file .env per la configurazione.

Damus iOS 1.17

Damus, il client Nostr per iOS, è passato alla versione 1.17 (PR #3606). Il rilascio corregge un problema RelayPool dove le connessioni si chiudevano dopo il rilascio del lease effimero (PR #3605), che poteva causare il drop inatteso delle sottoscrizioni. Risolve anche un bug dove la timeline dei preferiti non mostrava eventi nel passaggio tra tab (PR #3603).

nak v0.18.3

nak, il Nostr army knife CLI, ha rilasciato v0.18.3 con tre fix di stabilità: prevenzione di un panic quando i tag AUTH challenge sono nil o troppo corti, controllo degli errori del dateparser prima di usare il valore analizzato, e gestione degli URL mint Cashu che mancano del separatore ://.

Mi: Relay Locale Basato su Browser

Mi (mi.shakespeare.wtf), la nuova MiniApp Shakespeare, è un relay locale basato su browser che archivia in IndexedDB gli eventi Nostr dell’utente. Mi recupera profili (kind 0), liste contatti (kind 3), liste relay (kind 10002) e eventi wallet dai relay connessi e li memorizza localmente, dando accesso offline ai propri dati. Costruito con React e nostr-tools 2.15.0.

Agora v1.0.2

Agora (agora.spot), piattaforma decentralizzata di attivismo e raccolta fondi del team Soapbox, ha rilasciato v1.0.2 con un APK Android disponibile per installazione diretta. Si tratta della prima menzione di Agora su Compass; la piattaforma è stata lanciata il 17 gennaio con la dichiarazione di missione: “Unisciti al movimento globale per la libertà. Invia supporto agli attivisti sul campo a livello internazionale e partecipa alle azioni locali.”

La piattaforma si centra su una mappa mondiale dove chi la usa naviga per paese, crea “azioni” geolocalizzate (proteste, campagne, organizzazione comunitaria) e le discute tramite commenti threaded. Tutti i contenuti si propagano tramite relay Nostr, quindi nessun server centrale può essere messo offline per silenziare la coordinazione. Agora supporta più lingue con parità di traduzione imposta da CI, integra server media Blossom per gli upload, e include ricerca, navigazione hashtag con toggle globale/regionale, profili utente e sistemi di reazione. Il rilascio v1.0.2 è la build Android corrente, disponibile come download APK diretto.

xonos v0.1.6

xonos, il client Nostr 3D sperimentale costruito con il motore di gioco Bevy, ha rilasciato v0.1.6. xonos renderizza eventi Nostr in un ambiente spaziale 3D con capacità text-to-speech, esplorando come i dati del protocollo sociale potrebbero funzionare al di fuori delle interfacce 2D convenzionali.

Aggiornamenti dei Progetti

Primal Android Espande l’Infrastruttura NWC

Primal Android ha unito 18 PR in settimana, continuando il lavoro NWC iniziato la settimana scorsa. La PR #883 aggiunge supporto per connessioni NWC attraverso entrambi i wallet (Spark ed esterno), e la PR #879 implementa il metodo NWC lookup_invoice per controllare lo stato dei pagamenti.

La PR #880 aggiunge audit logging request-response NWC per il debugging delle interazioni wallet. La PR #877 introduce il supporto multi-account a PrimalNwcService, permettendo a chi ha più profili di mantenere connessioni wallet separate. La PR #882 implementa la pulizia periodica dei budget hold scaduti, prevenendo che prenotazioni di pagamento stale blocchino le operazioni wallet.

Il lavoro UI include ridisegno della schermata upgrade wallet (PR #889), FAQ sull’upgrade wallet (PR #885), impostazione indirizzo Lightning durante l’onboarding (PR #888) e un fix per le transazioni zap che apparivano come pagamenti regolari per i tipi non-Lightning (PR #887).

diVine Rilascia Feed Video API-First

diVine, il client video short-form, ha unito 19 PR in settimana, spostandosi verso l’architettura API-first. La PR #1468 introduce feed video API-first, e la PR #1466 aggiunge endpoint API trending, recent e home. La PR #1433 indicizza controller video specifici per un rendering efficiente dei feed.

La gestione profili è migliorata con la PR #1440 che implementa un pattern cache-plus-fresh per la visualizzazione di altri profili, riducendo i tempi di caricamento garantendo al contempo la freschezza dei dati. Il team ha anche rilasciato fix per le notifiche (PR #1437), refactoring del flusso commenti (PR #1431) e tab swiping sulla schermata Notifiche (PR #1388).

White Noise: Unificazione Keyring e Ricerca Utenti

Il backend White Noise per il protocollo Marmot ha unito 4 PR in settimana. Due PR hanno migliorato la gestione del keyring: la PR #468 rende l’identificatore del servizio keyring configurabile tramite WhitenoiseConfig, e la PR #475 unifica l’implementazione su un singolo crate keyring-core con store nativi per piattaforma, sostituendo codice frammentato specifico per piattaforma. Separatamente, la PR #470 aggiunge funzionalità di ricerca utenti.

Marmot TS Estrae l’App Chat di Riferimento

L’SDK TypeScript di Marmot (marmot-ts) ha unito la PR #40, rimuovendo l’applicazione chat di riferimento integrata e separandola in un repository autonomo: marmots-web-chat. Il nuovo repo, creato il 6 febbraio, è un’implementazione di riferimento dell’SDK TypeScript Marmot con la propria pipeline CI, vista chat a tab e sistema di build indipendente. La separazione permette all’SDK di concentrarsi sulle funzioni di libreria mentre l’app chat itera sulla UX in modo indipendente.

Una PR aperta (#41) migra marmot-ts a ts-mls v2.0.0, portando un’API ridisegnata con oggetti contesto unificati, nuove utility di gestione messaggi (creazione eventi, lettura, deserializzazione), helper per i metadata dei key package, e supporto eventi di cancellazione.

Aggiornamenti Alby Hub

Alby Hub ha unito 5 PR in settimana. La PR #2049 aggiunge un Alby CLI all’interfaccia dell’app store. La PR #2033 corregge la gestione di dati zap invalidi nella lista transazioni, e la PR #2046 rimuove il metodo ListTransactions non utilizzato dall’interfaccia LNClient.

Notedeck Rilascia Dashboard e Agentium

Notedeck, il client Nostr cross-platform di Damus, ha unito 6 PR in settimana. La PR #1247 aggiunge un’app dashboard iniziale. La PR #1293 introduce Agentium, un ambiente di sviluppo multi-agente che trasforma l’assistente AI Dave in un sistema con due modalità AI e gestione agenti basata su scene. La PR #1276 aggiunge un compositore messaggi multilinea con keybinding stile Signal, e la PR #1278 fornisce miglioramenti delle prestazioni media. PR aperte degne di nota includono infrastruttura outbox e pianificazione Git App NIP-34.

Agora Rilascia un Importante Rinnovo della UI

Agora ha unito 7 PR in settimana insieme al rilascio v1.0.2. La PR #106 è la più grande, chiudendo 11 task UI attraverso impostazioni, modifica profilo, interazioni mappa, risultati ricerca, filtraggio commenti e gestione server Blossom. Il merge ha disabilitato i pulsanti reazione per chi non è autenticato (che prima riceveva errori silenziosi cercando di reagire ai post sulla mappa), corretto il panning della mappa sulla linea di cambio data, e aggiunto testo corrispondente in grassetto nei risultati di ricerca.

La PR #108 aggiunge conteggi commenti sotto i post del feed e nelle pagine thread. La PR #107 aggiunge retry automatico sui fallimenti di caricamento eventi con un pulsante di reload esplicito quando i tentativi si esauriscono. La PR #104 cambia la navigazione hashtag per default allo scope globale, dato che il default precedente limitato per paese spesso restituiva zero risultati.

La PR #109 aggiunge un passaggio CI che verifica la parità di traduzione tra tutte le lingue, facendo fallire la build se a qualche chiave manca un valore. La PR #110 taglia le note lunghe nei feed per preservare il ritmo di scroll, e la PR #111 corregge un problema di zoom iOS mobile quando si commentano azioni causato da font di dimensioni ridotte.

Clawstr Rilascia CLI e Pulsanti Zap Lightning

Clawstr, la piattaforma ispirata a Reddit dove agenti AI creano e gestiscono community su Nostr, ha unito 3 PR in settimana. La PR #11 sostituisce tutti i comandi manuali nak nelle definizioni skill dell’agente AI con il nuovo pacchetto @clawstr/cli (npx -y @clawstr/cli@latest), rimuovendo la costruzione manuale di eventi JSON a favore di comandi CLI e aggiungendo operazioni wallet (init, balance, zap, npc) e ricerca full-text NIP-50.

La PR #13 aggiunge la pagina di documentazione “For Humans” e un componente ProfileZapDialog. Il pulsante zap appare sulle pagine profilo quando l’utente ha un indirizzo Lightning configurato e funziona anche non autenticati, usando LNURL-pay direttamente con importi sats preimpostati e visualizzazione codice QR. La PR #12 documenta il comando wallet sync, spiegando come i pagamenti verso indirizzi Lightning vengono trattenuti da NPC fino a che i rispettivi agenti sincronizzano esplicitamente i wallet.

Aggiornamenti NIP

Modifiche recenti al repository NIPs:

Uniti:

NIP-45: Risposta Relay HyperLogLog - NIP-45 (Event Counting) ora supporta il conteggio approssimativo HyperLogLog (HLL). I relay possono restituire valori registro HLL da 256 byte insieme alle risposte COUNT. I client uniscono questi registri da più relay per calcolare la cardinalità approssimativa evitando di scaricare set completi di eventi. Il caso d’uso principale: conteggi follower e reazioni indipendenti da un singolo relay come fonte autoritativa. Anche solo due eventi reazione consumano più banda del payload HLL da 256 byte. I client possono applicare le correzioni HyperLogLog++ per migliorare l’accuratezza su cardinalità ridotte.
NIP-39: Tag Identità Spostati da Kind 0 - I tag di claim identità NIP-39 (tag i) sono stati estratti dagli eventi metadata kind 0 a un nuovo kind dedicato 10011. La motivazione: quasi nessun client supporta questi tag, quindi aggiungono dimensione a ogni fetch kind 0 senza valore reale. Si tratta della prima di un ciclo di PR di estrazione kind 0 di vitorpamplona (vedi sezione Notizie).

PR Aperte e Discussioni:

NIP-XX: Nostr Relay Connect (NRC) - woikos propone un protocollo per accedere ai relay Nostr attraverso tunneling crittografato tramite un relay rendezvous pubblico. Il meccanismo abilita l’accesso a relay dietro NAT o firewall, inclusi relay personali in esecuzione su home server o dispositivi mobili. Il tunneling usa eventi kind 24891/24892 con crittografia NIP-44 attraverso un relay rendezvous che non può decrittare il traffico. Applicazione pratica: qualsiasi client Nostr può esporre lo storage locale (IndexedDB, SQLite) come endpoint relay per la sincronizzazione cross-device. La semantica standard NIP-01 (REQ, EVENT, CLOSE, COUNT) passa attraverso il tunnel in modo trasparente. Implementazioni di riferimento esistono in Go (ORLY Relay) e TypeScript (Smesh).
Nostr Web Tokens (NWT) - pippellia-btc propone Nostr Web Tokens, un formato evento Nostr per trasmettere claim firmati tra parti web, ispirato ai JSON Web Tokens (JWT). NWT può rappresentare sia NIP-98 (HTTP Auth) che eventi di autorizzazione Blossom, dando ai client flessibilità su come e quanto a lungo i token rimangono validi. Sono disponibili la libreria Go di riferimento, la spiegazione video e il confronto dettagliato con NIP-98 e Blossom Auth.
Semplificazione NIP-47 - rolznz propone di rimuovere i metodi multi_ da NIP-47 (Nostr Wallet Connect), complessi da implementare e privi di adozione. La PR riduce anche la duplicazione nella gestione crittografia e retrocompatibilità, ripulendo la spec dopo l’aggiunta hold invoice della settimana scorsa.
NIP-05: Spostamento in un Kind Evento Proprio - vitorpamplona propone di spostare la verifica NIP-05 da kind 0 a un nuovo kind 10008, abilitando più identificatori NIP-05 per utente e il filtraggio per indirizzo NIP-05. Parte della campagna di snellimento kind 0.
NIP-57: Indirizzi Lightning da Kind 0 - vitorpamplona propone di estrarre lud06/lud16 (indirizzi Lightning) da kind 0 a un kind evento dedicato per NIP-57, continuando lo sforzo di snellimento kind 0.
Iperpersonalizzazione Profilo - fiatjaf propone capacità estese di personalizzazione profilo oltre a quanto kind 0 supporta attualmente.

NIP Deep Dive: NIP-45 (Event Counting) e HyperLogLog

NIP-45 (spec) definisce come i client possono chiedere ai relay di contare eventi corrispondenti a un filtro evitando di trasferire gli eventi stessi. Il merge del supporto HyperLogLog aggiunge una struttura dati probabilistica che risolve un problema fondamentale: come contare cose attraverso più relay indipendenti.

Il Problema:

Contare eventi su un singolo relay è semplice: invia una richiesta COUNT, ottieni un numero indietro. Contare attraverso la rete è più difficile. Se il relay A riporta 50 reazioni e il relay B ne riporta 40, il totale non è 90 perché molti eventi esistono su entrambi i relay. Non è possibile calcolare il conteggio reale in assenza del download completo per deduplicare.

HyperLogLog:

HyperLogLog (HLL) è un algoritmo probabilistico che stima il numero di elementi distinti in un insieme usando un quantitativo fisso di memoria. L’implementazione NIP-45 usa 256 registri di un byte ciascuno, consumando esattamente 256 byte indipendentemente dal numero di eventi contati. L’algoritmo funziona esaminando la rappresentazione binaria di ciascun ID evento e tracciando la posizione degli zeri iniziali. ID evento che iniziano con molti zeri sono statisticamente rari, e la loro occorrenza indica un insieme grande.

Come Funziona in NIP-45:

Un relay che risponde a una richiesta COUNT può includere un campo hll contenente valori registro codificati in base64:

["COUNT", "<subscription_id>", {"count": 4527, "hll": "<base64 encoded 256 bytes>"}]

Il client raccoglie i valori HLL da più relay e li unisce prendendo il valore massimo a ciascuna posizione registro. L’HLL unito rappresenta l’unione di tutti gli insiemi di eventi attraverso i relay, gestendo automaticamente la deduplicazione. La stima finale di cardinalità viene calcolata dai registri uniti.

Accuratezza:

Con 256 registri, l’errore standard è di circa il 5,2%. Per un conteggio reale di 1.000, la stima cadrà tipicamente tra 948 e 1.052. Per conteggi più grandi, l’errore relativo rimane costante: un conteggio reale di 100.000 verrà stimato in circa 94.800-105.200. Le correzioni HyperLogLog++ migliorano l’accuratezza per cardinalità ridotte (sotto ~200), dove l’algoritmo base tende a sovrastimare.

Perché è Importante:

Le metriche social (conteggi follower, conteggi reazioni, conteggi repost) sono tra le funzionalità core dei client social media. In assenza di HLL, i client devono interrogare un singolo relay “fidato” (centralizzando il conteggio) o scaricare tutti gli eventi da tutti i relay (sprecando banda). HLL permette ai client di ottenere un buon conteggio approssimativo da più relay con un overhead totale di 256 byte per relay, indipendentemente dal conteggio effettivo. Anche solo due eventi reazione consumano più banda di un payload HLL completo.

La spec fissa il numero di registri a 256 per l’interoperabilità. Tutti i relay producono valori HLL che i client possono unire, indipendentemente da quale implementazione relay usano. I client possono implementare il supporto HLL una volta e beneficiare di ogni relay che lo supporta.

Stato Attuale:

La PR è stata aperta da fiatjaf ed era in discussione da diversi mesi prima del merge avvenuto in settimana. Le implementazioni relay dovranno aggiungere il calcolo HLL ai loro handler COUNT. Le implementazioni client dovranno aggiungere il merging HLL alla propria logica di aggregazione conteggi.

NIP Deep Dive: NIP-96 (HTTP File Storage) e la Transizione a Blossom

NIP-96 (spec) definiva come i client Nostr caricavano, scaricavano e gestivano file su server media HTTP. Ora contrassegnato come “non raccomandato” a favore di Blossom (hosting media basato su BUD), NIP-96 resta rilevante in settimana perché Angor v0.2.5 ha aggiunto la configurazione server NIP-96 e ZSP v0.3.1 carica su server Blossom, illustrando la transizione di protocollo in corso.

Come Funziona NIP-96:

Un client scopre le capacità di un file server recuperando /.well-known/nostr/nip96.json, che restituisce l’URL API, i tipi di contenuto supportati, i limiti di dimensione e le trasformazioni media disponibili:

{
 "api_url": "https://file-server.example/api",
 "download_url": "https://cdn.example/files",
 "content_types": ["image/jpeg", "video/webm", "audio/*"],
 "plans": {
 "free": {
 "is_nip98_required": true,
 "max_byte_size": 10485760,
 "media_transformations": {
 "image": ["resizing"]
 }
 }
 }
}

Per caricare, il client invia un POST multipart/form-data all’URL API con un header di autorizzazione NIP-98 (un evento Nostr firmato che prova l’identità di chi carica). Il server restituisce una struttura metadata file NIP-94 contenente l’URL del file, i hash SHA-256 originali e trasformati, il tipo MIME e le dimensioni:

{
 "status": "success",
 "nip94_event": {
 "tags": [
 ["url", "https://cdn.example/files/<hash>.png"],
 ["ox", "<original-file-hash>"],
 ["x", "<transformed-file-hash>"],
 ["m", "image/png"],
 ["dim", "800x600"]
 ]
 }
}

I download usano richieste GET a <api_url>/<sha256-hash>, con parametri query opzionali per trasformazioni server-side come il ridimensionamento immagini (?w=320). La cancellazione usa DELETE con auth NIP-98, e solo chi ha caricato il file originale può cancellare i propri file. Un endpoint di elenco file restituisce risultati paginati dei caricamenti di un utente.

Chi pubblica eventi kind 10096 dichiara i propri server di upload preferiti, permettendo ai client di selezionare automaticamente il server giusto in assenza di configurazione manuale.

Perché È Stato Deprecato:

NIP-96 legava gli URL dei file a server specifici. Se files.example.com andava giù, ogni nota Nostr che referenziava quegli URL perdeva i suoi media. Il server era l’indirizzo, e l’indirizzo era fragile.

Blossom (Blobs Stored Simply on Mediaservers) inverte il modello rendendo l’hash SHA-256 del contenuto del file l’identificatore canonico. Un URL Blossom ha la forma https://blossom.example/<sha256>.png, ma qualsiasi server Blossom che ospita lo stesso file lo serve allo stesso percorso hash. Se un server scompare, i client interrogano un altro server per lo stesso hash. L’indirizzamento basato sul contenuto rende i dati portabili tra server di default.

Blossom semplifica anche l’API. NIP-96 usava upload multipart form con risposte JSON, policy di trasformazione e un endpoint di discovery. Blossom usa semplice PUT per gli upload, GET per i download, ed eventi Nostr firmati (non header HTTP) per l’autorizzazione. La specifica Blossom è divisa in documenti modulari: BUD-01 copre il protocollo server, l’autorizzazione e il recupero, BUD-02 copre l’upload blob, BUD-03 copre i server utente, e BUD-04 copre il mirroring tra server.

La deprecazione è avvenuta a settembre 2025 tramite PR #2047, che ha contrassegnato NIP-96 come “non raccomandato” nell’indice NIPs.

La Transizione in Pratica:

Server come nostr.build e void.cat supportavano NIP-96 e hanno aggiunto o migrato a endpoint Blossom. I client sono a vari stadi: il rilascio v0.2.5 di Angor in settimana ha aggiunto la configurazione server NIP-96 per le immagini dei progetti, mentre il rilascio v0.3.1 di ZSP carica artefatti esclusivamente su server Blossom con header Content-Digest per la conformità al protocollo. Amethyst e Primal supportano gli upload Blossom. La coesistenza probabilmente continuerà fino a quando le rimanenti implementazioni NIP-96 completeranno la propria migrazione.

Cosa Viene Preservato:

I preference event kind 10096 rimangono utili per la selezione server Blossom. I metadata file NIP-94 (eventi kind 1063) descrivono ancora le proprietà dei file indipendentemente da quale protocollo di upload li ha creati. L’hashing SHA-256 che NIP-96 usava per gli URL di download è diventato la base dell’indirizzamento basato sul contenuto di Blossom. Il design di NIP-96 ha informato ciò che Blossom ha semplificato: la lezione è stata che l’hosting media su rete decentralizzata richiede storage indirizzato per contenuto per corrispondere alla resistenza alla censura del livello relay.

È tutto per questa settimana. Stai costruendo qualcosa? Hai notizie da condividere? Vuoi che copriamo il tuo progetto? Contattaci via DM NIP-17 o trovaci su Nostr.

Nostr Compass #8

Wed, 04 Feb 2026 00:00:00 +0000

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

Questa settimana: rust-nostr rilascia una importante riprogettazione dell’API con 21 PR che rivedono l’architettura dell’SDK. Nostria 3.0 viene lanciato con navigazione a doppio pannello, gestione liste e una completa revisione dell’UI. Vector aggiunge accelerazione SIMD raggiungendo speedup di 65x-184x e rilascia supporto per il protocollo Marmot per la messaggistica di gruppo crittografata. Frostr porta la firma a soglia su iOS tramite TestFlight. Damus implementa i suggerimenti relay NIP-19 (Entità Codificate Bech32) per la scoperta di contenuti cross-relay. Primal Android aggiunge crittografia NWC e esportazione transazioni wallet. nostr-tools e NDK ricevono miglioramenti di affidabilità. NIP-82 (Applicazioni Software) si espande per coprire il 98% delle piattaforme dispositivo. Il repository NIPs unisce il supporto hold invoice per NIP-47 (Nostr Wallet Connect). Nuove proposte di protocollo includono NIP-74 per il podcasting, NIP-DB per database eventi nel browser e una suite TRUSTed Filters per la curation decentralizzata dei contenuti. Nuovi progetti includono Instagram to Nostr v2 per la migrazione dei contenuti, Pod21 che lancia un marketplace decentralizzato di stampa 3D, Clawstr che introduce community gestite da agenti AI, e Shosho e NosCall che espandono le capacità di live streaming e videochiamate.

Notizie

rust-nostr Rilascia una Importante Riprogettazione dell’API

L’SDK rust-nostr ha subito una significativa revisione dell’architettura questa settimana con 21 PR unite che introducono breaking changes attraverso la libreria. La riprogettazione riguarda le API core su cui la maggior parte degli sviluppatori Rust fa affidamento.

PR #1245 riprogetta le API di notifica, mentre PR #1244 sostituisce RelayNotification::Shutdown con RelayStatus::Shutdown per una gestione dello stato più pulita. Le API del signer ora si allineano con altri pattern dell’SDK tramite PR #1243. I metodi Client e Relay hanno ricevuto una pulizia in PR #1242, e le opzioni client ora usano un builder pattern (PR #1241).

Le API di invio messaggi sono state riprogettate in PR #1240, l’unsubscription REQ in PR #1239, e la rimozione relay in PR #1229. Una PR aperta #1246 aggiunge supporto per le API bloccanti per completare la riprogettazione.

Le modifiche portano consistenza all’SDK ma richiederanno sforzo di migrazione dai progetti esistenti. Gli sviluppatori che costruiscono su rust-nostr dovrebbero rivedere attentamente il changelog prima di aggiornare.

Instagram to Nostr v2 Abilita la Migrazione dei Contenuti

Un nuovo strumento permette ai creatori di migrare i loro contenuti esistenti dalle piattaforme centralizzate a Nostr. Instagram to Nostr v2 supporta l’importazione da Instagram, TikTok, Twitter e Substack senza richiedere accesso alle chiavi private dell’utente.

Lo strumento affronta una barriera comune all’onboarding: gli utenti esitanti a ricominciare da zero su una nuova piattaforma possono ora preservare la loro cronologia di contenuti. Supporta anche il regalare account Nostr a nuovi utenti o proporre contenuti ad account esistenti, rendendolo utile per aiutare altri nella transizione al protocollo.

Pod21: Rete di Stampa 3D Decentralizzata

Pod21 (pod21.com) connette operatori di stampanti 3D con acquirenti usando Nostr per la coordinazione del marketplace. La piattaforma include un bot DM compatibile NIP-17 (Messaggi Diretti Privati) che gestisce le interazioni del marketplace, permettendo agli acquirenti di richiedere stampe e negoziare con i maker attraverso messaggi diretti crittografati.

I maker elencano la loro capacità e competenze di stampa; gli acquirenti sfogliano le inserzioni e avviano ordini tramite il bot. L’architettura segue un pattern simile ad altre applicazioni commerciali Nostr: scoperta basata su relay, messaggistica crittografata per la coordinazione degli ordini, e Lightning per il settlement. Pod21 si unisce a Ridestr e Shopstr come applicazioni Nostr che coordinano transazioni nel mondo reale attraverso il protocollo.

Clawstr si lancia come piattaforma ispirata a Reddit dove agenti AI creano e gestiscono community su Nostr. La piattaforma permette ad agenti autonomi di stabilire community tematiche, curare contenuti e interagire con gli utenti. Le community funzionano come subreddit ma con moderatori e curatori AI che guidano le discussioni. L’architettura usa il protocollo aperto di Nostr per interazioni agente-agente e agente-umano, stabilendo un nuovo modello per la formazione di community sui social media decentralizzati.

Rilasci

Ridestr v0.2.0: RoadFlare Release

Ridestr ha rilasciato v0.2.0, denominato “RoadFlare Release”, introducendo reti personali di rideshare. La funzionalità permette ai passeggeri di aggiungere autisti preferiti a una rete fidata. Gli autisti approvano i follower e condividono posizioni crittografate, permettendo ai passeggeri di vedere quando autisti fidati sono online e nelle vicinanze. Le richieste di corsa vanno direttamente agli autisti conosciuti.

L’affidabilità dei pagamenti è migliorata con recupero automatico dell’escrow, migliore sincronizzazione wallet tra dispositivi e elaborazione pagamenti più veloce tramite polling progressivo. PR #37 aggiunge l’infrastruttura Fase 5-6 che supporta queste funzionalità. v0.2.1 ha seguito con hotfix per bug della dialog di pagamento e il flusso “Aggiungi ai Preferiti” post-corsa.

Nostria 3.0

Nostria, il client cross-platform di sondreb costruito per scala globale, ha rilasciato la versione 3.0 con una completa revisione dell’UI, nuovo logo e centinaia di fix. Il rilascio rappresenta un intensivo ciclo di sviluppo di sei settimane.

La navigazione a doppio pannello è il cambiamento UX più grande, permettendo agli utenti desktop di ridurre il cambio di contesto quando si spostano tra liste, dettagli e thread. Una nuova sezione Home fornisce una panoramica di tutte le funzionalità disponibili, e tutti gli schermi condividono toolbar, layout e funzionalità unificati.

La gestione delle liste è l’aggiornamento funzionale più significativo, integrato in tutta l’applicazione. Gli utenti possono gestire liste di profili e filtrare contenuti in qualsiasi funzionalità: Stream, Musica o Feed. Stanchi dello spam nei thread? Filtra per preferiti per vedere solo le loro risposte. Quick Zaps aggiunge zapping con un tap con valori configurabili. Copia/Screenshot genera screenshot per la clipboard per condividere eventi ovunque. Parole Silenziate ora filtra sui campi del profilo (name, display_name, NIP-05), permettendo agli utenti di bloccare tutti i profili bridged con una singola parola bannata. Le Impostazioni sono diventate ricercabili per modifiche di configurazione più veloci.

Il rilascio aggiunge rendering delle richieste di pagamento BOLT11 e BOLT12, selezione dimensione testo e font, e messaggistica “Nota-a-Te-Stesso” nella sezione Messaggi con rendering di contenuti referenziati come articoli ed eventi. La nuova dialog Condividi permette condivisione rapida via email, siti web o messaggi diretti a più destinatari. Funzionalità aggiuntive includono set di emoji personalizzati, Interessi (liste hashtag come feed dinamici), Segnalibri, Feed Relay Pubblici e personalizzazione completa del menu inclusa quale opzione apre l’icona Nostria.

Disponibile su Android, iOS, Windows e web su nostria.app.

Applesauce v5.1.0

La suite di librerie Applesauce di hzrd149 ha rilasciato v5.1.0 su tutti i pacchetti. applesauce-signers aggiunge supporto per i metodi switch_relays e ping sui signer remoti Nostr Connect, utili per gestire le connessioni signer programmaticamente. applesauce-loaders introduce loadAsyncMap per caricamento asincrono parallelo. applesauce-react aggiunge argomenti padding a useAction().run(). applesauce-core aggiorna il mapping event-to-store per gestire stringhe direttamente senza richiedere onlyEvents.

nak v0.18.3

Il nak (Nostr Army Knife) di fiatjaf ha raggiunto v0.18.3 con fix di stabilità da mattn. Il rilascio previene panic quando gli URL mint mancano del separatore ://, valida gli errori del dateparser prima di usare i valori data e gestisce casi limite nel parsing dei tag AUTH challenge. Questi fix difensivi rendono la CLI più resiliente quando elabora input malformati.

Aegis v0.3.7

Aegis, il signer desktop cross-platform, ha rilasciato v0.3.7 aggiungendo supporto Nostr App Browser con firma NIP-07 (Interfaccia Estensione Browser). Il rilascio registra eventi di crittografia NIP-04 (Messaggi Diretti Crittografati) e NIP-44 (Crittografia Versionata), permettendo agli utenti di tracciare quali applicazioni richiedono operazioni di crittografia. Il segmento browser ora filtra per piattaforma per mostrare solo app web.

Bitchat v1.5.1 (iOS)

Bitchat, l’app di messaggistica offline-capable che usa Nostr e mesh Bluetooth, ha rilasciato v1.5.1 con hardening di sicurezza iOS. PR #1012 valida le firme degli eventi Nostr prima dell’elaborazione, rifiuta giftwrap e pacchetti embedded invalidi, limita i payload sovradimensionati e blocca gli ID mittente BLE announce spoofati. PR #998 corregge l’autenticazione mesh BLE iOS legando gli ID mittente agli UUID di connessione, prevenendo lo spoofing di identità nella rete mesh. PR #972 aggiunge rate limiting delle notifiche per prevenire flood di peer discovery quando più dispositivi mesh sono nelle vicinanze.

KeyChat v1.39.2

KeyChat ha rilasciato v1.39.2 aggiungendo supporto NIP-47 Nostr Wallet Connect tramite PR #148. Gli utenti possono ora connettere wallet Lightning esterni per i pagamenti all’interno dell’app di messaggistica. Il rilascio aggiunge anche notifiche desktop macOS.

Nostrmo v3.5.0

Nostrmo, il client Flutter cross-platform, ha rilasciato v3.5.0 rivedendo il suo sistema di feed. L’aggiornamento sostituisce i feed fissi con alternative personalizzabili: Feed Generale, Feed Menzioni e Feed Relay, ciascuno configurabile attraverso nuove pagine di modifica. Il rilascio implementa supporto per il modello outbox per un migliore routing degli eventi ed espande la funzionalità relay locale con limiti di dimensione configurabili e supporto sottoscrizioni.

Shosho v0.11.1

Shosho, l’app di live streaming per Nostr, ha rilasciato v0.11.1 con capacità di registrazione e VOD. L’aggiornamento aggiunge indicatori di presenza nella stanza che mostrano chi sta guardando gli stream, conversazioni chat threaded per una migliore organizzazione delle discussioni e supporto Nostr Connect su iOS tramite NIP-46. Gli streamer possono ora salvare le loro trasmissioni per la visione successiva mantenendo interazioni chat in tempo reale con il loro pubblico.

NosCall v0.5.0

NosCall, l’app per chiamate audio e video per Nostr, ha rilasciato v0.5.0 con gruppi di contatti per organizzare le chiamate per categoria, gestione relay per l’ottimizzazione delle connessioni e impostazioni server ICE configurabili per una migliore traversal NAT. Il rilascio aggiunge anche supporto per la modalità scura. NosCall usa Nostr per il signaling e la coordinazione delle chiamate, abilitando chiamate peer-to-peer senza server centralizzati.

diVine 1.0.4

diVine, il client video short-form looping di rabble, ha rilasciato 1.0.4 come pre-release alpha Android prima della sua sottomissione a Zapstore. Il rilascio si concentra sul test della gestione delle chiavi Nostr, incluso import nsec, firma remota NIP-46 (Nostr Connect) con nsecBunker e Amber, e gestione URL nostrconnect://. Il team sta sollecitando feedback sulla compatibilità relay e l’interoperabilità video con altri client. PR #1265 corregge la gestione dei percorsi file iOS che causava l’inutilizzabilità dei clip video dopo gli aggiornamenti dell’app memorizzando percorsi relativi invece di percorsi container assoluti. PR #1251 corregge problemi di navigazione quando si visualizzano profili dai commenti.

Zeus v0.12.2

Zeus ha rilasciato v0.12.2 come rilascio stabile, consolidando i fix NWC coperti nelle edizioni precedenti.

Frostr Igloo iOS TestFlight

Frostr (frostr.org) ha lanciato Igloo per iOS su TestFlight, espandendo la firma a soglia ai dispositivi Apple. Frostr usa firme FROST (Flexible Round-Optimized Schnorr Threshold) per dividere le chiavi nsec in quote distribuite tra dispositivi, abilitando firma k-di-n con tolleranza ai guasti. Gli utenti che si uniscono in “demo mode” partecipano a un esperimento live di firma a soglia 2-di-2, dimostrando le capacità di coordinazione in tempo reale del protocollo. Il rilascio iOS si unisce a Igloo per Android (v0.1.2), rilasciato a dicembre con supporto NIP-55 (Android Signer) per richieste di firma cross-app. Entrambi i client mobile complementano Igloo desktop e l’estensione browser Frost2x.

Aggiornamenti dei Progetti

Damus Implementa Suggerimenti Relay NIP-19

Damus ha unito PR #3477, implementando il consumo di suggerimenti relay NIP-19 per il recupero degli eventi. La funzionalità permette di visualizzare note su relay non nel pool configurato dell’utente estraendo suggerimenti da riferimenti NIP-10 (Thread di Risposta), NIP-18 (Repost) e NIP-19. L’implementazione usa connessioni relay effimere con cleanup reference-counted, evitando l’espansione permanente del pool di relay.

Fix aggiuntivi includono parsing di Lightning invoice (PR #3566), caricamento vista wallet (PR #3554), timing lista relay (PR #3553) e precaricamento profili per ridurre il “popping” visivo (PR #3550). Una bozza PR #3590 mostra il supporto DM privati NIP-17 in corso.

Primal Android Rilascia Crittografia NWC

Primal Android ha avuto una settimana molto attiva con 18 PR unite focalizzate sull’infrastruttura wallet. L’app ora si integra con Spark, il protocollo Lightning self-custodial di Lightspark. PR #874 aggiunge supporto crittografia NWC, mentre PR #872 invia eventi info NWC quando le connessioni si stabiliscono.

PR #870 abilita l’export CSV per le transazioni wallet, utile per contabilità e fini fiscali. PR #716 aggiunge uno switcher account locale nell’Editor Note. Molteplici fix di ripristino wallet (PR #876, PR #875, PR #873) affrontano casi limite per utenti con configurazioni wallet non-Spark.

Marmot TypeScript SDK Aggiunge Cronologia Messaggi

L’implementazione TypeScript del protocollo Marmot continua lo sviluppo. PR #38 di hzrd149 implementa la persistenza della cronologia messaggi con paginazione per l’applicazione chat di riferimento, mentre PR #39 migliora l’ergonomia della libreria.

Sul lato Rust, PR #161 implementa gestione dello stato riprovabile per preservare il contesto dei messaggi in caso di fallimento, e PR #164 passa a std::sync::Mutex per evitare panic tokio con SQLite. Il backend whitenoise-rs aggiunge integrazione Amber (PR #418), upgrade a MDK e nostr-sdk 0.44 (PR #467), e introduce streaming notifiche in tempo reale tramite PR #460 con tipi evento NewMessage e GroupInvite.

HAVEN Aggiunge Refresh Periodico WoT

HAVEN, il relay personale, ha unito PR #108 aggiungendo refresh periodico Web of Trust. La funzionalità assicura che i punteggi di fiducia rimangano aggiornati mentre i grafi sociali degli utenti evolvono, migliorando l’accuratezza del filtraggio spam nel tempo.

nostr-tools

nostr-tools, la libreria JavaScript core, ha ricevuto molteplici miglioramenti questa settimana. I commit includono un fix per il parsing degli hashtag dopo le newline nelle menzioni NIP-27 (Riferimenti nelle Note di Testo), pruning automatico di oggetti relay rotti con tracking idle per cleanup delle connessioni, rimozione della coda messaggi per ottimizzazione delle prestazioni single-threaded, e export dei file sorgente per migliori import TypeScript.

NDK

NDK ha rilasciato beta.71 con un fix per la riconnessione dopo cicli sleep/wake del dispositivo e gestione connessioni stale, affrontando problemi di affidabilità per le applicazioni mobile.

Notedeck

Notedeck, il client desktop del team Damus, ha una PR aperta #1279 che aggiunge un visualizzatore NIP-34 (Collaborazione Git). Questo permetterebbe di sfogliare repository git, patch e issue pubblicati sui relay Nostr direttamente nel client, rendendo Notedeck un potenziale front-end per workflow basati su ngit.

njump

njump, il gateway web Nostr, ha aggiunto supporto per due tipi di evento NIP-51 (Liste) tramite PR #152. Il gateway ora renderizza Follow Sets kind:30000, che sono raggruppamenti categorizzati di utenti che i client possono visualizzare in contesti diversi, e Starter Packs kind:39089, che sono collezioni di profili curate progettate per la condivisione e il following di gruppo. Queste aggiunte permettono a njump di visualizzare liste curate dalla community quando gli utenti condividono link nevent.

Amethyst

Amethyst, il client Android, ha corretto un bug che impediva la condivisione video dalla vista player (PR #1695). L’opzione “Condividi video” non appariva perché il parametro content non veniva passato al componente pulsanti di controllo. Gli utenti possono ora condividere contenuti video Nostr ad altre app direttamente dal player. PR #1693 corregge crash di deserializzazione Jackson JSON che si verificavano durante il parsing di certi eventi malformati.

Jumble

Jumble, il client web focalizzato sul browsing dei feed relay, ha aggiunto upload di file audio tramite clipboard in PR #743. Gli utenti possono ora incollare file audio direttamente nell’editor post, che li carica sui media server configurati e incorpora l’URL nella nota. La funzionalità rispecchia la funzionalità esistente di incolla immagini.

Flotilla

Flotilla, il client community NIP-29 (Gruppi Basati su Relay) di hodlbod, ha rilasciato notifiche tramite PR #270. L’aggiornamento rifà il sistema di alert da polling basato su anchor a notifiche pull locali per web e notifiche push per mobile. L’architettura implementa lo standard proposto NIP-9a (vedi PR #2194 sotto), dove gli utenti registrano callback webhook con i relay e ricevono payload evento crittografati quando i filtri corrispondono.

Formstr

Formstr, l’applicazione form nativa Nostr, ha aggiunto import form e supporto form crittografati in PR #422. Gli utenti possono ora importare form esistenti tramite un link di risposta o altre istanze Formstr. La funzionalità di crittografia permette ai creatori di form di restringere le risposte in modo che solo i destinatari designati possano leggere le sottomissioni, utile per sondaggi che raccolgono informazioni sensibili.

Pollerama

Pollerama (pollerama.fun), costruito su nostr-tools, ha aggiunto condivisione DM NIP-17 per i sondaggi tramite PR #141 e PR #142. Gli utenti possono ora condividere sondaggi direttamente ai contatti attraverso messaggi diretti crittografati.

Nostrability Schemata

Nostrability schemata, la collezione di schema di verifica JSON per eventi Nostr, ha aggiunto copertura NIP-59 (Gift Wrap) tramite PR #59. L’aggiornamento include schema per eventi kind 13 (seal) e kind 1059 (gift wrap), complementando la copertura schema NIP-17 esistente.

Vector

Vector, il messenger desktop privacy-focused che usa NIP-17, NIP-44 e NIP-59 per crittografia zero-metadata, ha unito PR #39 introducendo ottimizzazioni di prestazioni accelerate SIMD. La codifica hex gira 65x più veloce, la generazione preview immagini fino a 38x più veloce, e le ricerche messaggi 184x più veloci tramite indicizzazione binary search. La PR aggiunge intrinsics ARM64 NEON per Apple Silicon e x86_64 AVX2/SSE2 con rilevamento runtime per Windows e Linux. L’uso di memoria è calato con struct messaggi ridotte da 472 a 128 byte e storage npub tagliato del 99.6% attraverso interning.

Vector v0.3.0 (Dicembre 2025) ha integrato MDK (Marmot Development Kit) per messaggistica di gruppo basata su protocollo MLS, portando gruppi crittografati end-to-end con forward secrecy al client. La condivisione file MIP-04 ora gestisce attachment imeta per gruppi MLS, progettata per interoperabilità con White Noise. Il rilascio ha anche introdotto una piattaforma Mini Apps con giochi multiplayer P2P basati su WebXDC, un app store decentralizzato chiamato The Nexus, integrazione wallet PIVX per pagamenti in-app, editing messaggi con tracking completo della cronologia e riduzione memoria 4x durante gli upload di immagini.

Aggiornamenti NIP

Modifiche recenti al repository NIPs:

Uniti:

NIP-47: Supporto Hold Invoice - NIP-47 (Nostr Wallet Connect) ora supporta hold invoice, abilitando workflow di pagamento avanzati dove i riceventi devono esplicitamente settlare o cancellare i pagamenti. La PR aggiunge tre nuovi metodi RPC: make_hold_invoice crea un hold invoice usando preimage e payment hash pre-generati, settle_hold_invoice reclama il pagamento fornendo la preimage originale, e cancel_hold_invoice rifiuta il pagamento usando il suo payment hash. Una nuova notifica hold_invoice_accepted scatta quando un pagante blocca il pagamento. Questo abilita casi d’uso come pay-to-unlock content, sistemi escrow marketplace e payment gating. Le implementazioni sono già in corso in Alby Hub, Alby JS-SDK e dart NDK.
NIP-05: Requisito Minuscole - NIP-05 (Verifica del Dominio) ora richiede esplicitamente minuscole sia per le chiavi pubbliche esadecimali che per i nomi locali nel file nostr.json. Questo era implicito nella spec ma non dichiarato, causando problemi di interoperabilità quando alcune implementazioni usavano case misto mentre altre normalizzavano a minuscole. I client che validano identificatori NIP-05 dovrebbero ora rifiutare qualsiasi risposta nostr.json contenente caratteri maiuscoli in chiavi o nomi.
NIP-73: Codici Paese - NIP-73 (Geotag) ora supporta codici paese ISO 3166 come alternativa ai geohash. Gli eventi possono includere tag ["g", "US", "countryCode"] per indicare posizione a livello paese senza richiedere coordinate precise. Questo abilita filtraggio e scoperta contenuti basati sul paese per applicazioni dove la posizione esatta è non necessaria o indesiderata. La PR ha anche aggiunto un esempio geohash mancante alla documentazione spec.

PR Aperte e Discussioni:

NIP-82: Applicazioni Software - franzap ha annunciato un importante aggiornamento a questa specifica bozza, che definisce come le applicazioni software vengono distribuite via Nostr usando eventi release kind 30063. L’aggiornamento ora copre approssimativamente il 98% delle piattaforme dispositivo globalmente, incluso macOS, Linux, Windows, FreeBSD, ambienti WASM, estensioni VS Code, estensioni Chrome e Web Bundles/PWA. Il team si sta concentrando poi su Android, PWA e supporto iOS, invitando gli sviluppatori a convergere su questo standard condiviso. Zapstore pianifica di migrare al nuovo formato nelle prossime settimane.
NIP-74: Podcast - Definisce eventi addressable per show podcast (kind 30074) ed episodi (kind 30075). Gli show includono metadati come titolo, descrizione, categorie e immagini copertina. Gli episodi referenziano il loro show genitore e includono URL enclosure, durate e marcatori capitoli. La spec si integra con gli standard metadati Podcasting 2.0 e include tag value per monetizzazione V4V (value-for-value) via Lightning. Piattaforme come transmit.fm, una piattaforma di pubblicazione podcast nativa Nostr, possono pubblicare direttamente sui relay usando questo formato, permettendo ai podcaster di distribuire contenuti senza intermediari.
NIP-FR: Note Solo-Amici - Propone un meccanismo per pubblicare note visibili solo a una lista di amici definita dall’utente usando una chiave simmetrica condivisa chiamata ViewKey. L’autore crittografa le note (kind 2044) con il ViewKey usando NIP-44. Il ViewKey stesso viene distribuito a ciascun amico una sola volta tramite NIP-59 (Gift Wrap). Gli amici che possiedono il ViewKey possono decifrare e leggere le note; tutti gli altri vedono solo testo cifrato. Quando l’autore rimuove un amico, il ViewKey viene ruotato: una nuova chiave viene generata e ridistribuita a tutti gli amici rimanenti tramite gift wrap, assicurando che l’amico rimosso perda l’accesso ai post futuri. Questo approccio separa la crittografia del contenuto (simmetrica, efficiente) dalla distribuzione delle chiavi (asimmetrica, per-amico), mantenendo il protocollo leggero abilitando una funzionalità privacy frequentemente richiesta.
NIP-DB: Interfaccia Database Eventi Nostr nel Browser (spec) - Propone un’interfaccia standard window.nostrdb per estensioni browser che forniscono storage eventi Nostr locale. L’API include metodi per aggiungere eventi, query per ID o filtro, conteggio match e sottoscrizione agli aggiornamenti. Le applicazioni web possono usare questa interfaccia per leggere da eventi cached localmente senza fare richieste relay, riducendo banda e latenza. L’estensione browser nostr-bucket di hzrd149 fornisce un’implementazione di riferimento, iniettando l’interfaccia in tutti i tab del browser. Una libreria polyfill complementare implementa la stessa API usando IndexedDB per ambienti senza l’estensione.
TRUSTed Filters - Una suite di cinque proposte correlate per la curation decentralizzata dei contenuti, costruendo sulla PR #1534 Trusted Assertions unita di vitorpamplona. La specifica core introduce eventi kind 17570 per dichiarare Trust Provider Preferences, permettendo agli utenti di specificare quali servizi fidano per filtraggio e ranking degli eventi. I trust provider pubblicano assertions (kind 37571), statistiche (kind 37572) e rankings (kind 37573) a cui i client possono sottoscriversi. Il sistema usa un’architettura plugin con tag W/w per specificare tipi di filtro e trasformazioni. Questo permette a operazioni computazionalmente costose come spam detection, reputation scoring e content ranking di girare su infrastruttura dedicata mentre gli utenti mantengono controllo su quali provider fidano. La suite include spec separate per filter presets, user rankings, trusted events e definizioni plugin.
NIP-9a: Notifiche Push - hodlbod propone uno standard per notifiche push basate su relay usando eventi registrazione kind 30390. Gli utenti creano una registrazione contenente filtri per eventi che vogliono ricevere e un URL callback webhook. La registrazione è crittografata alla pubkey del relay (dal suo campo self NIP-11). Quando si verificano eventi corrispondenti, i relay POSTano al callback con l’ID evento (plaintext per deduplicazione) e l’evento stesso (crittografato NIP-44 all’utente). Questa architettura permette ai relay di pushare notifiche proteggendo il contenuto degli eventi dai server push intermediari. La PR #270 di Flotilla implementa questo standard.
Catallax - Propone un protocollo decentralizzato per lavoro a contratto con escrow usando eventi kind 33400. Il sistema definisce tre ruoli: gli arbiter annunciano disponibilità e termini, i patron creano task finanziati con Bitcoin in escrow, e i free agent completano lavoro per reclamare il pagamento. Gli arbiter risolvono le dispute quando necessario. Il protocollo abilita coordinazione di lavoro freelance trustless dove i fondi sono bloccati fino a che i deliverable sono accettati o l’arbitrato conclude.

NIP Deep Dive: NIP-47 (Nostr Wallet Connect)

NIP-47 definisce Nostr Wallet Connect (NWC), un protocollo per il controllo remoto di wallet Lightning usando Nostr come layer di comunicazione. Con l’aggiunta del supporto hold invoice di questa settimana, NWC ora copre l’intera gamma di operazioni Lightning.

Il protocollo funziona attraverso uno scambio semplice. Un’applicazione wallet pubblica un evento “wallet info” (kind 13194) che descrive le sue capacità. Le applicazioni client inviano richieste crittografate (kind 23194) chiedendo al wallet di eseguire operazioni come pagare invoice, creare invoice o controllare saldi. Il wallet risponde con risultati crittografati (kind 23195).

NWC usa crittografia NIP-44 tra client e wallet, con una keypair dedicata per le operazioni wallet, mantenendola separata dall’identità principale dell’utente. Questa separazione significa che compromettere una connessione NWC non espone l’identità Nostr dell’utente.

Metodi Supportati:

La spec definisce metodi per operazioni Lightning core: pay_invoice invia pagamenti, make_invoice genera invoice per ricevere, lookup_invoice controlla lo stato del pagamento, get_balance restituisce il saldo wallet, e list_transactions fornisce la cronologia pagamenti. I nuovi pay_keysend appena uniti abilitano pagamenti senza invoice, e hold_invoice supporta pagamenti condizionali.

Eventi di Esempio:

Il servizio wallet pubblica un evento info (kind 13194) pubblicizzando le sue capacità:

{
 "kind": 13194,
 "pubkey": "<pubkey servizio wallet>",
 "content": "pay_invoice get_balance make_invoice lookup_invoice list_transactions notifications",
 "tags": [
 ["encryption", "nip44_v2"],
 ["notifications", "payment_received payment_sent"]
 ],
 "created_at": "<timestamp unix>",
 "id": "<hash evento>",
 "sig": "<firma servizio wallet>"
}

Un client invia una richiesta crittografata (kind 23194) per pagare un invoice:

{
 "kind": 23194,
 "pubkey": "<pubkey effimera client dall'URI connection secret>",
 "content": "<NIP-44 crittografato: {\"method\": \"pay_invoice\", \"params\": {\"invoice\": \"lnbc50n1...\"}}>",
 "tags": [
 ["p", "<pubkey servizio wallet>"],
 ["encryption", "nip44_v2"]
 ],
 "created_at": "<timestamp unix>",
 "id": "<hash evento>",
 "sig": "<firma chiave effimera client>"
}

Il servizio wallet risponde (kind 23195) con il risultato del pagamento:

{
 "kind": 23195,
 "pubkey": "<pubkey servizio wallet>",
 "content": "<NIP-44 crittografato: {\"result_type\": \"pay_invoice\", \"result\": {\"preimage\": \"...\"}, \"error\": null}>",
 "tags": [
 ["p", "<pubkey effimera client>"],
 ["e", "<id evento richiesta>"]
 ],
 "created_at": "<timestamp unix>",
 "id": "<hash evento>",
 "sig": "<firma servizio wallet>"
}

Il tag e nella risposta referenzia la richiesta originale, permettendo ai client di abbinare le risposte alle loro richieste.

Hold Invoice:

La PR #1913 di questa settimana ha aggiunto supporto hold invoice, abilitando pagamenti stile escrow. A differenza degli invoice standard dove il ricevente reclama immediatamente il pagamento rilasciando la preimage, gli hold invoice permettono al ricevente di differire questa decisione. Quando un pagante invia a un hold invoice, i fondi si bloccano lungo il percorso di pagamento. Il ricevente poi sceglie se settlare (rilasciare la preimage e reclamare i fondi) o cancellare (rifiutare il pagamento, restituendo i fondi al pagante). Se nessuna azione avviene, il pagamento va in timeout e i fondi ritornano automaticamente. La PR aggiunge tre metodi NWC: make_hold_invoice, settle_hold_invoice e cancel_hold_invoice, più una notifica hold_invoice_accepted. Questo meccanismo alimenta applicazioni come l’escrow rideshare di Ridestr e la risoluzione dispute marketplace.

Implementazioni Attuali:

I wallet principali supportano NWC: Zeus, Alby e Primal (dalla PR #874 di questa settimana) tutti implementano supporto lato wallet. Sul lato client, Damus, Amethyst e la maggior parte dei client Nostr principali possono connettersi a wallet NWC per zapping e pagamenti.

Il protocollo abilita una separazione delle responsabilità: gli utenti possono far girare il loro wallet su un dispositivo mentre interagiscono con Nostr da un altro, con i relay Nostr che servono come canale di comunicazione. Questa architettura significa che i client mobile non devono detenere fondi direttamente, migliorando la sicurezza mantenendo l’infrastruttura wallet separata dai client social.

Considerazioni sulla Sicurezza:

Le connessioni NWC dovrebbero essere trattate come sensibili. Mentre la crittografia protegge il contenuto dei messaggi, la pubkey wallet e il connection secret devono essere custoditi. Le applicazioni dovrebbero permettere agli utenti di revocare connessioni e impostare limiti di spesa. Il protocollo supporta restrizioni di capacità, così i wallet possono limitare quali operazioni una particolare connessione può eseguire.

NIP Deep Dive: NIP-59 (Gift Wrap)

NIP-59 definisce un protocollo per incapsulare qualsiasi evento Nostr in più livelli di crittografia, nascondendo l’identità del mittente dai relay e dagli osservatori. Le proposte di questa settimana per note solo-amici (NIP-FR) e notifiche push (NIP-9a) entrambe si basano sul gift wrapping, rendendolo una primitiva privacy fondamentale da comprendere.

I Tre Livelli:

Il gift wrapping usa tre strutture annidate:

Rumor (evento non firmato): Il contenuto originale come evento Nostr senza firma. Il rumor non può essere inviato direttamente ai relay perché i relay rifiutano eventi non firmati.
Seal (kind 13): Il rumor è crittografato usando NIP-44 e posto in un evento kind 13. Il seal E’ firmato dalla chiave reale dell’autore. Questa è la prova crittografica di paternità.
Gift Wrap (kind 1059): Il seal è crittografato e posto in un evento kind 1059 firmato da una keypair casuale, usa-e-getta. Il gift wrap include un tag p per il routing al destinatario.

Un Malinteso Comune: La Negabilità

La spec menziona che i rumor non firmati forniscono “negabilità”, ma questo è fuorviante. Il livello seal E’ firmato dal vero autore. Quando il destinatario decritta il gift wrap e poi il seal, ha prova crittografica di chi ha inviato il messaggio. Il destinatario potrebbe persino costruire una prova zero-knowledge rivelando l’identità del mittente senza esporre la propria chiave privata.

Quello che il gift wrap in realtà fornisce è privacy del mittente dagli osservatori: i relay e le terze parti non possono determinare chi ha inviato il messaggio perché vedono solo il gift wrap firmato da una chiave casuale. Ma il destinatario sa sempre, e può provarlo.

Eventi di Esempio:

Ecco la struttura completa a tre livelli dalla spec (invio “Vai alla festa stasera?”):

Il rumor (non firmato, non può essere pubblicato sui relay):

{
 "created_at": 1691518405,
 "content": "Are you going to the party tonight?",
 "tags": [],
 "kind": 1,
 "pubkey": "611df01bfcf85c26ae65453b772d8f1dfd25c264621c0277e1fc1518686faef9",
 "id": "9dd003c6d3b73b74a85a9ab099469ce251653a7af76f523671ab828acd2a0ef9"
}

Il seal (kind 13, firmato dal vero autore, contiene rumor crittografato):

{
 "kind": 13,
 "pubkey": "611df01bfcf85c26ae65453b772d8f1dfd25c264621c0277e1fc1518686faef9",
 "content": "AqBCdwoS7/tPK+QGkPCadJTn8FxGkd24iApo3BR9/M0uw6n4RFAFSPAKKMgkzVMo...",
 "created_at": 1703015180,
 "tags": [],
 "id": "28a87d7c074d94a58e9e89bb3e9e4e813e2189f285d797b1c56069d36f59eaa7",
 "sig": "02fc3facf6621196c32912b1ef53bac8f8bfe9db51c0e7102c073103586b0d29..."
}

Il gift wrap (kind 1059, firmato da chiave effimera casuale, contiene seal crittografato):

{
 "kind": 1059,
 "pubkey": "18b1a75918f1f2c90c23da616bce317d36e348bcf5f7ba55e75949319210c87c",
 "content": "AhC3Qj/QsKJFWuf6xroiYip+2yK95qPwJjVvFujhzSguJWb/6TlPpBW0CGFwfuf...",
 "created_at": 1703021488,
 "tags": [["p", "166bf3765ebd1fc55decfe395beff2ea3b2a4e0a8946e7eb578512b555737c99"]],
 "id": "5c005f3ccf01950aa8d131203248544fb1e41a0d698e846bd419cec3890903ac",
 "sig": "35fabdae4634eb630880a1896a886e40fd6ea8a60958e30b89b33a93e6235df7..."
}

Nota: la pubkey del seal è il vero autore (611df01...), mentre la pubkey del gift wrap è una chiave casuale usa-e-getta (18b1a75...). I relay vedono solo il gift wrap, quindi non possono attribuire il messaggio al vero autore.

Cosa Protegge Ogni Livello:

Il rumor non è firmato e non può essere pubblicato direttamente sui relay. Il seal è firmato dal vero autore e prova la paternità al destinatario. Il gift wrap è firmato da una chiave casuale usa-e-getta, nascondendo il vero autore dai relay e dagli osservatori. Solo il destinatario può decrittare attraverso entrambi i livelli per raggiungere il contenuto originale e verificare la firma dell’autore sul seal.

Applicazioni Attuali:

NIP-17 (Messaggi Diretti Privati) usa gift wrap per DM crittografati, sostituendo il vecchio schema NIP-04. Il proposto NIP-FR (note solo per amici) usa il gift wrapping per distribuire ViewKeys agli amici, che poi decifrano le note cifrate con quelle chiavi. NIP-9a (notifiche push) critta i payload di notifica usando principi gift wrap.

Protezione dei Metadati:

I timestamp dovrebbero essere randomizzati per contrastare l’analisi temporale. I relay dovrebbero richiedere AUTH prima di servire eventi kind 1059 e servirli solo al destinatario marcato. Quando si invia a più destinatari, creare gift wrap separati per ciascuno.

È tutto per questa settimana. Stai costruendo qualcosa? Hai notizie da condividere? Vuoi che copriamo il tuo progetto? Contattaci via DM NIP-17 o trovaci su Nostr.

Nostr Compass #7

Wed, 28 Jan 2026 00:00:00 +0000

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

Questa settimana: Ridestr porta il ridesharing decentralizzato su Nostr con pagamenti Cashu e condivisione crittografata della posizione. Pomade introduce il recupero basato su email per i firmatari multisig. Damus implementa negentropy per una sincronizzazione affidabile dei DM. L’app desktop di Amethyst aggiunge ricerca, segnalibri e zap. Amber v4.1.1 mostra i punteggi di fiducia dei relay. Marmot unisce MIP-03 e costruisce un’app di chat di riferimento in TypeScript. diVine aggiunge l’autenticazione QR NIP-46 e il supporto alle menzioni. Nuove proposte NIP affrontano la gestione delle community, la sincronizzazione basata su sequenze e l’archiviazione crittografata dei file. Diamo anche uno sguardo a cinque anni di gennaio di Nostr, tracciando l’evoluzione del protocollo da una manciata di primi utilizzatori nel 2021, attraverso l’esplosivo lancio di Damus sull’App Store nel 2023, fino all’ecosistema client in maturazione del 2025.

Notizie

Ridestr Porta il Ridesharing Decentralizzato su Nostr

Ridestr sta sviluppando un’applicazione di ridesharing peer-to-peer costruita interamente su Nostr, che consente transazioni dirette tra autisti e passeggeri con pagamenti in Bitcoin e Cashu. Il protocollo utilizza tipi di evento personalizzati (30173, 3173-3175, 30180/30181) per coordinare le corse mantenendo la privacy attraverso la divulgazione progressiva della posizione e la crittografia NIP-44.

Il sistema funziona attraverso un flusso attentamente coreografato: gli autisti trasmettono la disponibilità usando posizioni codificate in geohash (precisione ~5km) tramite eventi kind 30173, i passeggeri richiedono corse con stime delle tariffe attraverso kind 3173, e i pagamenti sono protetti usando token escrow HTLC prima dell’inizio della corsa. La privacy della posizione è preservata attraverso la divulgazione progressiva, dove i dettagli del ritiro vengono rivelati solo quando gli autisti arrivano e le destinazioni sono condivise dopo la verifica del PIN. Tutta la comunicazione tra le parti utilizza la crittografia NIP-44 per la privacy.

Ridestr implementa la sicurezza dei pagamenti attraverso escrow HTLC con firme P2PK. Quando un passeggero accetta l’offerta di un autista, blocca i token Cashu con un hash di pagamento che solo l’autista può reclamare dopo il completamento della corsa. Il protocollo attualmente opera con un’architettura single-mint, richiedendo che passeggeri e autisti utilizzino lo stesso mint Cashu. L’implementazione Android basata su Kotlin gestisce la verifica delle prove e il recupero delle prove obsolete attraverso i controlli di stato NUT-07.

Ridestr affronta sfide che la maggior parte delle applicazioni Nostr evita: coordinamento della posizione in tempo reale, escrow dei pagamenti con risoluzione delle dispute e sistemi di reputazione per interazioni nel mondo fisico. Il progetto è in beta e dimostra che il modello di eventi di Nostr può supportare marketplace di servizi peer-to-peer, non solo la condivisione di contenuti.

Pomade Lancia il Sistema di Recupero Alpha per Firmatari Multisig

Pomade, sviluppato da hodlbod, si basa sull’ecosistema FROSTR esistente per fornire un servizio di firma a soglia focalizzato sul recupero. Utilizzando le firme FROST (Flexible Round-Optimized Schnorr Threshold) tramite la libreria @frostr/bifrost, Pomade aggiunge flussi di recupero basati su email sopra la crittografia a soglia. Il sistema frammenta la chiave segreta di un utente usando Shamir Secret Sharing, distribuendo le quote tra più firmatari indipendenti con una soglia configurabile (2-di-3, 3-di-5, ecc.).

Il protocollo opera interamente su Nostr usando un singolo tipo di evento (28350) con payload crittografati NIP-44. Durante la firma, il client richiede firme parziali da almeno threshold firmatari, poi le aggrega in una firma Schnorr valida. Per la crittografia, i firmatari collaborano per derivare segreti condivisi via ECDH senza che nessuna singola parte apprenda la chiave completa.

Il recupero funziona attraverso due metodi di autenticazione: basato su password (usando argon2id con la pubkey del firmatario come salt) o OTP via email. Per prevenire attacchi MITM durante il recupero OTP, ogni firmatario genera il proprio codice di verifica con un prefisso fornito dal client, richiedendo agli utenti di autenticarsi indipendentemente con ogni firmatario. Il protocollo richiede proof-of-work sugli eventi di registrazione (20+ bit secondo NIP-13) per prevenire lo spam.

Il modello di fiducia è esplicito: se threshold firmatari colludono, possono rubare la chiave. I provider email sono completamente fidati poiché possono intercettare gli OTP. Gli utenti non possono recuperare indipendentemente la loro chiave segreta completa; farlo richiede la cooperazione di threshold firmatari. Il protocollo è progettato per l’onboarding di nuovi utenti non familiari con la gestione delle chiavi, con la raccomandazione esplicita che gli utenti migrino all’auto-custodia una volta a loro agio. Pomade avverte di potenziali “perdite di chiavi, furti, denial of service o fughe di metadati” dato il suo stato alpha non auditato.

Rilasci

Damus Implementa Negentropy per la Sincronizzazione Affidabile dei DM

Damus v1.13 implementa l’implementazione negentropy che abbiamo presentato come PR aperta la settimana scorsa. PR #3536 aggiunge il supporto base negentropy al livello di rete, abilitando la riconciliazione degli insiemi con i relay che supportano il protocollo. Una PR #3547 complementare aggiunge la sincronizzazione DM pull-to-refresh che usa negentropy per recuperare i messaggi mancanti quando le sottoscrizioni REQ standard falliscono.

L’implementazione segue un approccio conservativo: il caricamento normale dei DM continua invariato, con negentropy disponibile come meccanismo di recupero quando gli utenti aggiornano manualmente. I test automatizzati dimostrano la correzione generando un DM con un timestamp vecchio che le query standard mancherebbero, poi usando la sincronizzazione negentropy per recuperarlo con successo. Mentre il supporto negentropy richiede relay compatibili, l’implementazione gestisce elegantemente ambienti con relay misti usando il protocollo dove disponibile.

Amber v4.1.1 - Punteggi di Fiducia dei Relay

Amber v4.1.1 implementa la visualizzazione dei punteggi di fiducia dei relay (PR #289), implementando i concetti di valutazione dei relay discussi nella copertura dei Trusted Relay Assertions della settimana scorsa. I punteggi di fiducia ora appaiono nella pagina Relays e per le richieste di connessione NostrConnect, aiutando gli utenti a valutare l’affidabilità dei relay prima di autorizzare le connessioni. Il rilascio include anche una UI ridisegnata per login/eventi/permessi e supporto per il metodo switch_relays. I miglioramenti delle prestazioni memorizzano in cache le operazioni del keystore, affrontando le segnalazioni di tempi di caricamento di oltre 20 secondi su dispositivi più vecchi.

nak v0.18.2 - Integrazione MCP

Il nak di fiatjaf (Nostr Army Knife) v0.18.2 aggiunge il supporto Model Context Protocol tramite nak mcp, permettendo agli agenti AI di cercare persone su Nostr, pubblicare note, menzionare utenti e leggere contenuti usando il modello outbox. Il rilascio introduce anche un installer con una sola riga (curl -sSL https://raw.githubusercontent.com/fiatjaf/nak/master/install.sh | sh) che scarica binari precompilati, eliminando il requisito della toolchain Go per gli utenti finali. La modalità Bunker ora supporta Unix socket e switch_relays.

Zeus v0.12.2 Beta - Fix NWC

Zeus v0.12.2-beta1 implementa multiple correzioni NWC che affrontano i problemi coperti nella copertura di Zeus della settimana scorsa.

Aggiornamenti dei Progetti

Amethyst Desktop - Fase 2A Rilasciata

Amethyst ha rilasciato la Fase 2A della sua app desktop, aggiungendo Ricerca, Segnalibri, Zap, viste Thread e contenuti long-form (Letture) all’esperienza desktop. Una PR #1683 complementare aggiunge feedback trasparente sulla trasmissione degli eventi così gli utenti ora vedono lo stato in tempo reale per-relay mentre i loro eventi si propagano attraverso la rete, rendendo più facile diagnosticare problemi di connettività.

Progressi di Notedeck: App Calendario e Rifinitura UX

L’app desktop Notedeck del team Damus ha unito il comportamento di auto-nascondimento della toolbar (PR #1268) che risponde alla velocità di scorrimento per più spazio sullo schermo nelle viste mobile. Una bozza PR #1271 aggiunge un’app Calendario NIP-52 completa con viste mese/settimana/giorno/agenda, supporto RSVP e commenti NIP-22 sugli eventi del calendario, attualmente con feature-flag per i test.

Jumble Aggiunge Modalità Community

Jumble, il client web focalizzato sui relay, ha aggiunto modalità community e supporto per preset di set di relay tramite variabili d’ambiente, rendendo più facile distribuire istanze tematiche come nostr.moe.

Dashboard Ordini di Shopstr

Shopstr ha sostituito la sua gestione ordini basata su chat con una Dashboard Ordini dedicata. La nuova interfaccia fornisce una vista centralizzata per i merchant per tracciare lo stato degli ordini, segnare i messaggi come letti e gestire l’evasione senza scorrere le conversazioni chat. L’aggiornamento depreca il caching IndexedDB in favore delle API server-side per lo stato degli ordini e rivede come i DM degli ordini vengono taggati per un miglior filtraggio.

Formstr Aggiunge Domande a Griglia

Formstr, l’app form nativa Nostr, ha aggiunto domande a griglia e riscritto il suo SDK con supporto per embed. Una [correzione per firmatari non-NIP-07](https://github.com/abh3po/nostr-forms/pull/418) ha risolto problemi per utenti con bunker o firmatari locali che tentavano di inviare form con la loro identità.

nostr-tools Aggiorna le Dipendenze Crittografiche

nostr-tools, la libreria JavaScript core, ha aggiornato a @noble/curves v2.0.1, affrontando modifiche API breaking attraverso 27 file e adottando le ultime librerie noble auditate. fiatjaf ha anche aggiunto il supporto switch_relays a NIP-46, permettendo ai client bunker di cambiare dinamicamente le connessioni ai relay.

Zeus Lavora sulle Recensioni Mint NIP-87

Zeus ha una [PR aperta per le recensioni mint NIP-87](https://github.com/ZeusLN/zeus/pull/3576), permettendo agli utenti di scoprire e recensire i mint Cashu filtrati dai seguiti Nostr. Le recensioni includono valutazioni a stelle e possono essere inviate anonimamente o con l’nsec dell’utente.

Camelus Implementa Supporto DM Completo

Camelus, un client Android basato su Flutter costruito con Dart NDK per prestazioni mobile efficienti in termini di batteria, ha aggiunto messaggistica diretta completa con oltre 20 commit questa settimana. L’aggiornamento include categorie chat, date dei messaggi, UI di invio ottimistica, funzionalità nota-a-se-stessi e gestione corretta dei relay DM.

Aggiornamenti del Protocollo Marmot

La risoluzione deterministica dei commit MIP-03 che abbiamo coperto come PR aperta la settimana scorsa è stata ora unita. MDK PR #152 assicura che tutte le chat di gruppo basate su MLS convergano sullo stesso stato quando più commit validi arrivano per la stessa epoca.

Una PR spec #28 complementare aggiunge requisiti del ciclo di vita init_key che affrontano lacune dagli audit di implementazione: il materiale della chiave privata dai messaggi Welcome deve essere cancellato in modo sicuro dopo l’elaborazione (zeroizzazione, pulizia dello storage), e i nuovi membri devono eseguire auto-aggiornamenti entro 24 ore per la forward secrecy.

L’SDK TypeScript (marmot-ts) sta costruendo un’applicazione di chat di riferimento. PR #37 aggiunge creazione/lista gruppi, gestione key package con flussi di pubblicazione/trasmissione/cancellazione e inviti tramite codice QR. Una PR aperta #38 di hzrd149 implementa la persistenza della cronologia messaggi con paginazione. Il backend whitenoise-rs ha unito 15 PR questa settimana incluso il supporto multi-lingua (PR #455) e i riferimenti media MIP-04 v2 (PR #450).

diVine Aggiunge Funzionalità di Integrazione Nostr

diVine, l’app video short-form, continua la rapida integrazione Nostr.

Le PR aperte includono l’autenticazione tramite codice QR NIP-46 (PR #1019) e la messaggistica diretta crittografata NIP-17 (PR #834). L’attività di questa settimana si è concentrata sul supporto menzioni che converte URI nostr: e @menzioni in link profilo cliccabili, fallback avatar Classic Viners usando profili Nostr, e strumenti di editing video inclusi disegno, filtri e sticker.

Aggiornamenti NIP

Modifiche recenti al repository NIPs:

Uniti:

Trusted Relay Assertions - La proposta per standardizzare i punteggi di fiducia dei relay che abbiamo coperto la settimana scorsa è stata unita. La specifica definisce eventi kind 30385 per le asserzioni di fiducia dei relay con punteggio su affidabilità, qualità e accessibilità. Il dibattito che ha portato all’unione si è concentrato sul fatto che i punteggi di fiducia debbano essere “globali” (calcolati una volta per tutti gli utenti) o “personalizzati” (relativi al grafo sociale di ogni osservatore). Algoritmi in stile PageRank come Trust Rank di nostr.band e GrapeRank resistono agli attacchi sybil dividendo qualsiasi rank passato attraverso account falsi per la dimensione della bot farm.

PR Aperte e Discussioni:

Communikeys - Una proposta completa per la gestione delle community che usa npub esistenti come identificatori di community invece di approcci basati su relay. Qualsiasi npub può diventare una community pubblicando un evento kind 10222; le pubblicazioni mirano alle community tramite eventi kind 30222. Il controllo degli accessi usa badge NIP-58, abilitando la gestione delegata dell’appartenenza con cold storage per le chiavi della community.
NIP-CF: Changes Feed - Una bozza che propone la sincronizzazione degli eventi basata su sequenze come alternativa ai filtri since basati su timestamp. Il problema: la sincronizzazione Nostr standard usando timestamp since può perdere eventi quando più eventi condividono lo stesso timestamp con precisione al secondo, gli orologi del client e del relay divergono, o il checkpointing è impreciso. NIP-CF risolve questo facendo assegnare ai relay numeri di sequenza monotonicamente crescenti agli eventi memorizzati, fornendo un ordinamento totale rigoroso. I client richiedono modifiche da un numero di sequenza specifico e ricevono eventi in ordine garantito, con checkpointing preciso che non perde mai eventi. La proposta supporta anche la modalità live/continua dove le sottoscrizioni rimangono aperte dopo la sincronizzazione iniziale per aggiornamenti in tempo reale.
NIP-XX: Encrypted File Sync - Un protocollo che definisce i kind 30800 (file crittografati), 30801 (indici vault) e 30802 (documenti condivisi) per sincronizzare contenuti crittografati tra dispositivi usando i relay Nostr. Il protocollo abilita app di note-taking local-first per fornire sincronizzazione crittografata end-to-end senza server centralizzati. Contenuti dei file, percorsi, nomi e struttura delle cartelle sono tutti crittografati usando l’auto-crittografia NIP-44, così i relay memorizzano blob che non possono leggere. Gli allegati binari come le immagini usano server Blossom con crittografia lato client. Il kind 30802 abilita la condivisione di documenti tra utenti crittografando verso la chiave pubblica del destinatario.

Cinque Anni di Gennaio di Nostr

La newsletter del mese scorso ha tracciato le pietre miliari di dicembre di Nostr dal primo rilascio client di fiatjaf attraverso la donazione catalizzatrice di Jack Dorsey. Questa retrospettiva traccia cosa è successo ogni gennaio dal 2021 al 2025, concentrandosi sugli sviluppi tecnici verificati.

Gennaio 2021: Sviluppo Iniziale

Il terzo mese di Nostr vide lo sviluppo continuato di Branle, il client Vue.js di fiatjaf lanciato a dicembre 2020. Un piccolo gruppo di primi utilizzatori, probabilmente meno di 15 persone, si coordinava attraverso il gruppo Telegram @nostr_protocol (creato il 16 novembre 2020), testando il protocollo su uno o due relay sperimentali. Il client da riga di comando noscl forniva interazione basata su terminale.

Le fondamenta tecniche erano già bloccate: utenti identificati da chiavi pubbliche secp256k1, post firmati crittograficamente con firme Schnorr, e relay che servono come storage stupido che non comunicano tra loro. Questa era crittografia deliberatamente nativa di Bitcoin, una scelta di design che avrebbe plasmato i pattern di adozione anni dopo.

Gennaio 2022: Scoperta degli Sviluppatori

Gennaio 2022 si aprì con Nostr ancora in fermento dalla sua prima apparizione su Hacker News (31 dicembre 2021), che generò 110 punti e 138 commenti. Al momento di quel post, solo circa sette relay alimentavano l’intera rete, con i commentatori che notavano “lo spam non è ancora un problema perché nostr è super nuovo e nessuno lo usa ancora”. Robert C. Martin (“Uncle Bob”) aveva appoggiato Nostr come potenzialmente “la soluzione definitiva per la comunicazione sociale”. La discussione continuò a gennaio, con sviluppatori che dibattevano architettura relay versus vero P2P, resistenza alla censura versus moderazione, e se la semplicità potesse scalare.

Il post HN scatenò un’ondata di nuove implementazioni. Uncle Bob stesso iniziò more-speech, un client desktop Clojure, il 18 gennaio. La libreria go-nostr di fiatjaf (creata gennaio 2021) e il client da riga di comando noscl fornivano strumenti Go, mentre nostr-tools offriva supporto JavaScript. Entro dicembre 2022, circa 800 profili avevano bio. Branle rimase il client web principale, ricevendo aggiornamenti inclusi import della chiave privata e supporto multi-relay. Le sfide tecniche erano evidenti: le chiavi esadecimali da 64 caratteri si rivelarono non intuitive, i ritardi dei messaggi frustravano gli utenti, e la community si chiedeva se l’architettura potesse gestire traffico a scala Twitter.

Gennaio 2023: La Svolta

Gennaio 2023 trasformò Nostr da esperimento a movimento. Damus, il client iOS di William Casarin (jb55), lottava con il processo di approvazione dell’App Store di Apple. Rifiutato il 1° gennaio, rifiutato di nuovo il 26 gennaio, fu finalmente approvato il 31 gennaio. Quell’approvazione scatenò una cascata: Damus raggiunse immediatamente la posizione #10 in U.S. Social Networking. Jack Dorsey lo definì “una pietra miliare per i protocolli aperti”.

Otto giorni prima, il 23 gennaio, Edward Snowden annunciò la sua presenza su Nostr: “Una delle cose cool di Nostr… oltre alla resistenza alla censura, è che non sei limitato a 280 caratteri”. Il suo endorsement da parte di un whistleblower della NSA aveva peso nei circoli attenti alla privacy, e gli utenti iniziarono immediatamente a inviargli zap in sats via Lightning.

I client web corsero per gestire l’afflusso. Snort, creato da kieran a dicembre 2022, emerse come un client React ricco di funzionalità; il 13 gennaio, Snort integrò la registrazione NIP-05 tramite l’API Nostr Plebs, permettendo ai nuovi utenti di reclamare identità leggibili durante l’onboarding. Iris, sviluppato a tempo pieno da Martti Malmi (un early contributor di Bitcoin che ricevette la seconda transazione Bitcoin mai fatta da Satoshi), offriva interfacce sia web che mobile con identità NIP-05 gratuite su iris.to. Astral, costruito da monlovesmango con Quasar (Vue.js) come fork di Branle, si concentrava sulla gestione dei relay con la sua funzionalità di raggruppamento relay che permetteva agli utenti di organizzare i relay in set per la pubblicazione e il filtraggio. Le beta TestFlight per i client iOS si riempivano in poche ore, e Amethyst dominava su Android.

L’infrastruttura faticava a tenere il passo. Tutti i relay erano gestiti da appassionati che pagavano di tasca propria. I relay a pagamento che usavano micropagamenti Lightning creavano un filtraggio naturale dello spam ma introducevano frizione nell’accesso. Damus fu rimosso dall’App Store della Cina solo due giorni dopo l’approvazione, riferibilmente su richiesta del principale organo di vigilanza internet della Cina.

Gennaio 2024: Consolidamento del Protocollo

Gennaio 2024 si concentrò sulla standardizzazione del protocollo e sulla costruzione della community. Nostr PHX iniziò l’anno con un meetup il 5 gennaio a Phoenix, riunendo cypherpunk locali. Questo fu il primo di molti eventi della community quell’anno inclusi BTC Prague (giugno), Nostriga a Riga (agosto) e Nostrasia.

Lo sviluppo del protocollo più significativo fu NIP-59 (Gift Wrap) unito il 29 gennaio, fornendo protezione dei metadati per le comunicazioni crittografate. Gift Wrap si basa sullo standard di crittografia NIP-44 (che era stato auditato da Cure53 a dicembre 2023) per nascondere l’identità del mittente dai relay. Il protocollo avvolge i messaggi crittografati all’interno di un evento esterno firmato da una keypair casuale, usa-e-getta. I relay vedono solo la pubkey usa-e-getta, mentre la vera identità del mittente è sepolta nel payload crittografato che solo il destinatario può decifrare. Questo impedisce agli operatori dei relay e agli osservatori della rete di sapere chi sta messaggiando chi. I timestamp possono anche essere randomizzati per sconfiggere l’analisi temporale.

L’ecosistema si espanse oltre i social media. Plebeian Market diventò completamente Nostr-native con conformità NIP-15, abilitando carrelli cross-stall e un browser di stall per scoprire i merchant. Shopstr emerse come un marketplace permissionless che facilitava il commercio Bitcoin. Zap.stream, costruito da kieran, portò lo streaming live su Nostr con pagamenti Lightning a 21 sats/minuto. Gli strumenti per sviluppatori maturarono con NDK che forniva astrazioni TypeScript e rust-nostr che offriva binding Rust. Zeus v0.8.1 fu rilasciato con import contatti Nostr e LND persistente, gettando le basi per l’integrazione Nostr Wallet Connect nei rilasci successivi.

Eppure la sostenibilità dell’infrastruttura rimaneva una sfida. La ricerca accademica di questo periodo trovò che il 95% dei relay faticava a coprire i costi operativi, con il 20% che sperimentava significativi tempi di inattività. La tariffa di ammissione per i relay a pagamento era in media meno di 1.000 sats (~$0.45), insufficiente a sostenere le operazioni.

Una nota sulle truffe: Il “Nostr Assets Protocol” e il token “$NOSTR” associato che furono lanciati in questo periodo furono pubblicamente denunciati da fiatjaf come “100% fraudolenti” e “una truffa di affinità” senza alcuna connessione con il vero protocollo Nostr.

Gennaio 2025: Maturazione dei Client

Gennaio 2025 vide lo sviluppo continuato dei client attraverso l’ecosistema. Nostur 1.17.0 fu rilasciato il 13 gennaio con sincronizzazione cross-device per gli stati di lettura, supporto login multi-sig FROST e prestazioni ottimizzate del database locale. Amethyst continuò la sua transizione al modello outbox, compilando automaticamente set di relay basati sulle liste di follow piuttosto che richiedere configurazione manuale.

I principali client iniziarono ad allontanarsi da NIP-04 per i messaggi diretti, migrando verso NIP-17 e il proposto NIP-104 per crittografia migliorata e protezione dei metadati. Il modello Gossip (comunicazione outbox/inbox) guadagnò adozione mentre l’ecosistema convergeva verso pattern di utilizzo dei relay più efficienti. Gli osservatori del settore prevedevano che questo sarebbe stato l’anno in cui Nostr transita da protocollo di nicchia a riconoscimento mainstream, con una potenziale migrazione di piattaforma ad alto profilo che potrebbe raddoppiare l’attività giornaliera.

Gennaio 2026: Sicurezza e Infrastruttura di Firma

Gennaio 2026 portò significativi avanzamenti nella sicurezza e nell’infrastruttura di firma. Primal Android 2.6.18 fu rilasciato con firma remota NIP-46 e supporto per firmatario locale NIP-55, unendosi ad Amber e Aegis come hub di firma completo per altre app Android. Bitchat completò un audit di sicurezza Cure53, la stessa azienda che auditò Signal e NIP-44, con oltre 17 PR che correggevano problemi critici inclusa la cancellazione dei segreti DH e problemi di thread safety. Sia Bitchat che Damus migrarono da C Tor a Rust Arti per maggiore affidabilità e sicurezza della memoria.

Il lavoro sul protocollo continuò con NIP-71 (eventi video addressable) unito e una NIP sulla crittografia post-quantistica che aprì la discussione sul future-proofing di Nostr contro attacchi quantistici. La bozza Trusted Relay Assertions propose la standardizzazione del punteggio di fiducia dei relay attraverso attestazioni firmate. Il Protocollo Marmot rafforzò la sua messaggistica crittografata basata su MLS con 18 PR unite che affrontavano le scoperte dell’audit.

Le applicazioni nel mondo reale si espansero con Ridestr che sviluppa ridesharing decentralizzato usando escrow Cashu e crittografia NIP-44, e Pomade che aggiunge flussi di recupero basati su email alla firma a soglia FROST. Damus rilasciò negentropy per la sincronizzazione affidabile dei DM, mentre l’app desktop di Amethyst raggiunse la Fase 2A con ricerca, segnalibri e zap.

Guardando Avanti

Sei anni di gennaio rivelano l’evoluzione di Nostr dallo sviluppo iniziale (2021) alla scoperta pubblica (2022) alla crescita esplosiva (2023) al consolidamento del protocollo (2024) alla maturazione dei client (2025) all’infrastruttura di sicurezza (2026). Il pattern è familiare a chiunque abbia osservato la crescita dei protocolli aperti: anni di costruzione silenziosa, un’esplosione improvvisa quando le condizioni si allineano, poi il lavoro più lungo di rendere tutto affidabile. Quello che è iniziato con sette relay e un thread su Hacker News è ora infrastruttura auditata con applicazioni reali. La domanda per il 2027: quando qualcuno chiamerà una corsa, invierà un messaggio crittografato o recupererà una chiave persa usando Nostr, sapranno anche che lo stanno usando?

È tutto per questa settimana. Stai costruendo qualcosa? Hai notizie da condividere? Vuoi che copriamo il tuo progetto? Contattaci via DM NIP-17 o trovaci su Nostr.

Nostr Compass #6

Wed, 21 Jan 2026 00:00:00 +0000

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

Questa settimana: Bitchat sostituisce C Tor con l’implementazione Rust Arti per una maggiore affidabilità e prestazioni. nostrdb-rs ottiene query fold streaming che abilitano operazioni di database a zero allocazioni. Listr riceve un importante refactoring con la migrazione a NDK 3 beta e manutenzione assistita da AI dopo un anno di inattività. Zeus spedisce 17 PR unite focalizzate su correzioni NIP-47 (Nostr Wallet Connect per il controllo remoto di Lightning) e miglioramenti Cashu, mentre Primal Android aggiunge flussi di backup del wallet e supporto NIP-92 (dimensioni dei media per rapporti di aspetto corretti). Una nuova bozza di NIP propone Trusted Relay Assertions per la valutazione standardizzata della fiducia nei relay.

Notizie

Bitchat Migra ad Arti Rust per il Supporto Tor

Bitchat è migrato da C Tor ad Arti, l’implementazione Rust del protocollo Tor. PR #958 rimuove la dipendenza da C Tor e integra Arti, portando garanzie di sicurezza della memoria e maggiore affidabilità. Il cambiamento elimina i tentativi di riattivazione dormiente che causavano riavvii del servizio in primo piano, un problema di lunga data con l’implementazione C.

Cosa significa per gli utenti: Messaggistica crittografata più stabile con meno disconnessioni, specialmente su dispositivi mobili. L’implementazione Rust riduce i rischi di crash e il consumo della batteria dai tentativi di riconnessione costanti.

Arti è una riscrittura completa di Tor in Rust, sviluppata dal Tor Project per fornire maggiore sicurezza attraverso la sicurezza della memoria e un’integrazione più facile nelle applicazioni. Per Bitchat, le proprietà di sicurezza della memoria riducono la superficie di attacco durante la gestione di messaggi crittografati e connessioni relay. La migrazione segue il recente audit di sicurezza Cure53 del team (trattato nella Newsletter #5), continuando i loro miglioramenti di sicurezza.

Il PR introduce anche una copertura di test completa per ChatViewModel e BLEService, rimuove codice morto e stabilizza la suite di test. I miglioramenti di affidabilità della mesh Bluetooth Low Energy accompagnano le modifiche Tor, affrontando i fallimenti di trasferimenti grandi. Insieme, questi cambiamenti migliorano la resilienza di Bitchat per scenari di rete mesh offline dove Tor fornisce connettività internet insieme alla comunicazione BLE locale.

Listr Rivitalizzato con Manutenzione Potenziata dall’AI

JeffG ha annunciato un importante refactoring di Listr, l’applicazione di gestione liste Nostr disponibile su listr.lol, dopo che il progetto era rimasto inattivo per oltre un anno. Usando l’assistenza dell’AI, ha completato un aggiornamento completo includendo la migrazione a NDK 3 beta, aggiornamenti alle ultime versioni di Svelte e Vite, e tutte le dipendenze portate alla versione corrente. Il refactoring aggiunge supporto di prima classe per i pacchetti di following, implementa la paginazione per liste che superano i 50 elementi e corregge numerosi bug che si erano accumulati durante il periodo di inattività.

Cosa significa per gli utenti: Listr è tornato online con prestazioni migliorate e nuove funzionalità per gestire liste di following, collezioni di contenuti e curatela di argomenti. La correzione della paginazione rende effettivamente utilizzabili le liste grandi.

JeffG ha notato che senza l’assistenza dell’AI, questo lavoro di manutenzione probabilmente non sarebbe mai avvenuto, impedendo che il progetto venisse abbandonato. Listr abilita la curatela dei contenuti su Nostr, permettendo agli utenti di creare, gestire e condividere liste di profili, argomenti e risorse. L’aggiornamento mantiene l’applicazione compatibile con gli standard Nostr correnti e le aspettative dei client man mano che la gestione delle liste diventa più centrale per la scoperta dei contenuti sul protocollo.

Aggiornamenti NIP

Modifiche recenti al repository NIPs:

Unite:

NIP-29 (Gruppi basati su relay) - Chiarimento Chiave Relay (#2190 - unito) chiarisce che la chiave relay è l’URL del relay stesso, non una pubkey. La specifica ora afferma esplicitamente “La chiave relay è l’URL WebSocket del relay (es. wss://groups.example.com)” per evitare confusione. Questo influisce su come i client identificano quale relay ospita un determinato gruppo, garantendo che i gruppi siano correttamente attribuiti ai loro relay ospitanti.

PR Aperte e Discussioni:

Trusted Relay Assertions - Una bozza di NIP propone di standardizzare il punteggio di fiducia nei relay attraverso eventi kind 30385 contenenti punteggi di fiducia (0-100) calcolati da metriche NIP-66 (scoperta e monitoraggio relay), reputazione dell’operatore e segnalazioni degli utenti. La specifica divide la fiducia in componenti di affidabilità (uptime, latenza), qualità (TLS, documentazione, verifica operatore) e accessibilità (giurisdizione, barriere, rischio sorveglianza). La verifica dell’operatore include firme crittografiche tramite NIP-11 (documenti informativi relay), record TXT DNS e file .well-known. Gli utenti dichiarano i fornitori di asserzioni fidati tramite eventi kind 10385, permettendo ai client di interrogare più fornitori per prospettive diverse. La proposta complementa la scoperta NIP-66 con la valutazione, aiutando NIP-46 (firma remota/Nostr Connect) a valutare l’affidabilità dei relay negli URI di connessione.
Crittografia Post-Quantistica - PR #2185 (aperta) continua ad evolversi da quando la Newsletter #5 ha introdotto la proposta per algoritmi resistenti ai computer quantistici. La discussione di questa settimana si è concentrata sui dettagli di implementazione per la crypto-agility: come i client gestiscono le firme doppie durante la migrazione, la compatibilità retroattiva per i client più vecchi e le implicazioni prestazionali delle firme quantistiche resistenti più grandi. I contributori hanno dibattuto se imporre solo ML-DSA-44 o supportare più algoritmi (ML-DSA-44, Falcon-512, Dilithium) per flessibilità. Il consenso propende verso un approccio graduale: firme quantistiche opzionali inizialmente, diventando obbligatorie solo dopo un ampio supporto dei client e l’emergere di una reale minaccia quantistica.

Approfondimento NIP: NIP-11 e NIP-66

Questa settimana esaminiamo due NIP che lavorano insieme per abilitare la scoperta e valutazione dei relay: NIP-11 definisce come i relay si descrivono, e NIP-66 standardizza come misuriamo il comportamento dei relay. Insieme formano la base per i sistemi di valutazione della fiducia nei relay.

NIP-11: Documento Informativo Relay

NIP-11 definisce un documento JSON che i relay servono via HTTP per descrivere le loro capacità, politiche e informazioni sull’operatore. Quando un client si connette a wss://relay.example.com, può recuperare https://relay.example.com (sostituendo wss:// con https://) per ottenere il documento informativo del relay.

Il documento usa la negoziazione standard del contenuto HTTP con l’header Accept: application/nostr+json. Questo permette ai relay di servire il loro sito web normale ai browser mentre forniscono metadati leggibili dalle macchine ai client Nostr. La risposta include il nome del software relay e la versione, informazioni di contatto dell’operatore (pubkey, email, contatto alternativo), NIP supportati e parametri operativi come requisiti di pagamento o restrizioni di contenuto.

Importante notare che i documenti NIP-11 di base sono JSON non firmati serviti via HTTPS, affidandosi esclusivamente ai certificati TLS per l’autenticità. Questo significa che chiunque controlli il server web del relay può modificare il documento, rendendo non verificabili le affermazioni dell’operatore. La proposta Trusted Relay Assertions affronta questa lacuna introducendo attestazioni firmate attraverso il campo self pubkey di un relay, abilitando la prova crittografica dell’identità dell’operatore in modo simile a come i relay usano eventi firmati per i meccanismi di autenticazione.

{
 "name": "relay.example.com",
 "description": "Un relay pubblico per uso generale",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "contact": "admin@example.com",
 "supported_nips": [1, 2, 4, 9, 11, 12, 16, 20, 22],
 "software": "git+https://github.com/relay/relay.git",
 "version": "1.2.3",
 "limitation": {
 "max_message_length": 16384,
 "max_subscriptions": 20,
 "max_filters": 100,
 "max_limit": 5000,
 "max_subid_length": 100,
 "min_prefix": 4,
 "max_event_tags": 2000,
 "max_content_length": 8196,
 "min_pow_difficulty": 0,
 "auth_required": false,
 "payment_required": false
 },
 "payments_url": "https://relay.example.com/payments",
 "fees": {
 "admission": [{"amount": 5000, "unit": "msats"}],
 "subscription": [{"amount": 1000, "unit": "msats", "period": 2592000}],
 "publication": []
 }
}

L’oggetto limitation indica ai client quali vincoli applica il relay. max_message_length limita la dimensione del frame WebSocket, max_subscriptions limita le sottoscrizioni REQ concorrenti per connessione, max_filters limita i filtri per REQ, e max_limit vincola quanti eventi può richiedere un singolo filtro. Questi parametri aiutano i client ad adattare il loro comportamento alle capacità del relay, evitando disconnessioni dal superamento dei limiti.

Le informazioni di pagamento appaiono in fees e payments_url. I relay possono addebitare per l’ammissione (accesso una tantum), l’abbonamento (accesso ricorrente) o la pubblicazione (tariffe per evento). Il payments_url punta ai dettagli sui metodi di pagamento, tipicamente fatture Lightning o mint ecash. I relay a pagamento usano questi campi per comunicare i prezzi prima che i client tentino l’autenticazione.

L’array supported_nips permette ai client di scoprire le capacità del relay. Se un relay elenca NIP-50, i client sanno di poter inviare query di ricerca full-text. Se appare NIP-42, i client dovrebbero aspettarsi challenge di autenticazione. Questa pubblicità dichiarativa delle capacità abilita il miglioramento progressivo: i client possono usare funzionalità avanzate dove disponibili mentre degradano elegantemente su relay con supporto limitato.

Le informazioni sull’operatore costruiscono responsabilità. Il campo pubkey identifica l’operatore del relay su Nostr, abilitando la comunicazione diretta tramite DM NIP-17 o menzioni pubbliche. L’contact email fornisce un fallback fuori protocollo. Insieme, questi campi aiutano gli utenti a raggiungere gli operatori per segnalazioni di abuso, richieste di accesso o problemi tecnici.

I documenti NIP-11 sono auto-riportati: i relay descrivono cosa affermano di supportare, non necessariamente cosa fanno effettivamente. Qui è dove NIP-66 diventa importante.

NIP-66: Scoperta Relay e Monitoraggio Liveness

NIP-66 standardizza la pubblicazione di dati di monitoraggio relay su Nostr. I servizi di monitoraggio testano continuamente i relay per disponibilità, latenza, conformità al protocollo e NIP supportati. Pubblicano i risultati come eventi kind 30166, fornendo lo stato relay in tempo reale indipendente dall’auto-segnalazione del relay.

I monitor controllano la disponibilità del relay connettendosi e inviando sottoscrizioni di test. Le misurazioni di latenza tracciano il tempo di connessione, il tempo di risposta alle sottoscrizioni e il ritardo di propagazione degli eventi. I test di conformità al protocollo verificano che il comportamento del relay corrisponda alle specifiche, individuando bug di implementazione o deviazioni intenzionali. La verifica del supporto NIP va oltre le affermazioni NIP-11 testando effettivamente se le funzionalità pubblicizzate funzionano correttamente.

{
 "id": "a34b5c7d89e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7",
 "pubkey": "4e2d0bc6f8e7c3a5b9f1d2e3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4",
 "created_at": 1736784000,
 "kind": 30166,
 "tags": [
 ["d", "wss://relay.example.com"],
 ["rtt", "open", "143", "1736784000"],
 ["rtt", "read", "89", "1736784000"],
 ["rtt", "write", "92", "1736784000"],
 ["nips", "1", "2", "4", "9", "11", "12"],
 ["geo", "US", "United States", "New York"],
 ["other", "network", "clearnet"],
 ["other", "payment_required", "false"],
 ["other", "auth_required", "false"]
 ],
 "content": "{\"last_check\": 1736784000, \"checks\": 8760}",
 "sig": "8b9c4d5e6a7f8b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b"
}

Il tag d contiene l’URL del relay, rendendo questo un evento sostituibile parametrizzato. Ogni monitor pubblica un evento per relay, aggiornato al cambiare delle misurazioni. Più monitor possono tracciare lo stesso relay, fornendo ridondanza e validazione incrociata. I client interrogano più pubkey di monitor per ottenere prospettive diverse sulla salute del relay.

I tag round-trip time (rtt) misurano la latenza per diverse operazioni. rtt open traccia l’instaurazione della connessione WebSocket, rtt read misura il tempo di risposta alle sottoscrizioni, e rtt write testa la velocità di pubblicazione degli eventi. Tutti i valori sono in millisecondi. I client usano queste metriche per preferire relay a bassa latenza per operazioni sensibili al tempo o deprioritizzare relay lenti.

Il tag nips elenca il supporto NIP effettivamente verificato, non solo il supporto dichiarato. I monitor testano ogni NIP esercitando la sua funzionalità. Se un relay rivendica la ricerca NIP-50 nel suo documento NIP-11 ma le query di ricerca falliscono, i monitor ometteranno NIP-50 dalla lista verificata. Questo fornisce la verità di base sulle capacità del relay.

Le informazioni geografiche aiutano i client a selezionare relay vicini per una migliore latenza e resistenza alla censura. Il tag geo contiene il codice paese, il nome paese e la regione. Il tag network distingue i relay clearnet dai servizi nascosti Tor o endpoint I2P. Insieme, questi tag abilitano la diversità geografica: i client possono connettersi a relay in più giurisdizioni per resistere alla censura regionale.

I dati dei monitor alimentano i selettori di relay nei client, i siti web esploratori e la proposta Trusted Relay Assertions. Combinando documenti auto-riportati NIP-11 con dati misurati NIP-66 e asserzioni di fiducia calcolate, l’ecosistema si muove verso la selezione informata dei relay piuttosto che fare affidamento su default codificati o raccomandazioni di passa-parola.

Rilasci

0xchat v1.5.3 - Funzionalità di Messaggistica Migliorate

0xchat v1.5.3 porta miglioramenti significativi al client di messaggistica Nostr stile Telegram. Il rilascio affronta problemi di conformità NIP-55 (applicazione signer Android) che impedivano la corretta firma degli eventi attraverso signer esterni come Amber. La piena conformità significa che 0xchat ora delega correttamente le operazioni di firma, migliorando la sicurezza mantenendo le chiavi private isolate.

L’aggiornamento integra sia FileDropServer che BlossomServer come opzioni di archiviazione media predefinite, offrendo agli utenti ridondanza per i caricamenti di file. Blossom fornisce archiviazione indirizzata ai contenuti dove i file sono referenziati dai loro hash SHA-256, garantendo integrità e abilitando la deduplicazione sulla rete. Il salvataggio automatico delle bozze per Moments previene la perdita di dati quando si compone contenuto long-form, affrontando le lamentele degli utenti sui post persi durante i cambi di app o le interruzioni di connettività.

L’integrazione del wallet Cashu riceve una lucidatura con il filtraggio automatico delle prove che rimuove i token spesi dalla vista del wallet. Questo risolve la UX confusa dove gli utenti vedevano prove invalide insieme a ecash valido, rendendo inaffidabili i calcoli del saldo. Il filtraggio avviene lato client, mantenendo la privacy mentre migliora l’esperienza di pagamento per le transazioni peer-to-peer nelle chat.

Amber v4.1.0 Pre-releases - Revisione UI

Amber v4.1.0-pre1 fino a v4.1.0-pre3 introducono un’interfaccia ridisegnata per il popolare signer di eventi Android. La schermata di login ora visualizza chiaramente quale applicazione sta richiedendo permessi di firma, affrontando la confusione degli utenti sui flussi di autorizzazione. La nuova schermata eventi fornisce un’ispezione dettagliata di quali dati le applicazioni vogliono firmare, permettendo agli utenti di prendere decisioni di sicurezza informate prima di approvare le operazioni.

La gestione dei permessi riceve attenzione significativa con un’interfaccia rinnovata che mostra esattamente quali capacità è stata concessa a ogni applicazione connessa. Gli utenti possono revocare permessi specifici senza disconnettersi completamente, abilitando il controllo a grana fine sulla delegazione della firma. I contatori relay rifattorizzati usando la libreria quartz aggiornata forniscono statistiche in tempo reale sul throughput degli eventi e le prestazioni dei relay. Le connessioni bunker NIP-46 (Nostr Connect) ora mostrano messaggi di errore dettagliati quando le connessioni falliscono, sostituendo gli errori di timeout criptici con diagnostiche azionabili.

Modifiche notevoli a codice e documentazione

Queste sono pull request unite e sviluppi in fase iniziale che vale la pena tracciare. Alcuni sono funzionalità sperimentali che potrebbero evolversi prima del rilascio.

Zeus (Wallet Lightning con Nostr Wallet Connect)

Zeus ha unito 17 pull request questa settimana, rafforzando la sua posizione come implementazione NIP-47 Nostr Wallet Connect leader. Le correzioni più significative affrontano problemi di consistenza dei dati e conformità al protocollo che stavano causando problemi di interoperabilità con i client Nostr.

Correzione Cronologia Transazioni - PR #3542 risolve un bug critico dove le liste transazioni NWC visualizzavano voci errate o duplicate. Il problema si verificava quando Zeus metteva in cache i dati delle transazioni senza gestire correttamente gli aggiornamenti degli eventi, causando agli utenti di vedere transazioni fantasma o pagamenti mancanti. La correzione implementa la deduplicazione corretta degli eventi e l’invalidazione della cache, garantendo che la cronologia delle transazioni rifletta accuratamente lo stato del nodo Lightning.

Conformità al Protocollo - PR #3548 affronta risposte getInfo incomplete che rompevano la compatibilità con i client che si aspettano la piena conformità NIP-47. Alcuni client Nostr crashavano quando ricevevano risposte parziali mancanti di campi come block_height o network. Il PR garantisce che tutti i campi richiesti ritornino con default sensati anche quando l’implementazione Lightning sottostante non li fornisce, migliorando la compatibilità di Zeus nell’ecosistema.

Resilienza della Connessione - PR #3543 implementa notifiche di timeout per connessioni Nostr bloccate. Precedentemente, gli utenti aspettavano indefinitamente quando le connessioni relay cadevano silenziosamente. Ora Zeus visualizza messaggi di timeout chiari dopo 30 secondi di inattività, permettendo agli utenti di riprovare o cambiare relay. PR #3541 aggiunge validazione backend per prevenire l’attivazione NWC su implementazioni Lightning incompatibili, individuando errori di configurazione prima che causino crash runtime.

Race Condition Cashu - PR #3531 corregge un bug di concorrenza nella gestione dei token Cashu dove operazioni di mint simultanee potevano corrompere il database dei token. La race condition si verificava quando più thread aggiornava i conteggi dei token senza un locking appropriato, risultando occasionalmente in saldi errati. La correzione aggiunge protezione mutex attorno alle sezioni critiche, garantendo aggiornamenti atomici allo stato dei token.

Primal Android (Client)

Primal Android ha spedito 12 PR unite con miglioramenti significativi alla sicurezza del wallet e alla gestione dei media. L’implementazione del backup del wallet affronta una delle funzionalità più richieste, mentre il supporto NIP-92 migliora l’esperienza visiva nell’applicazione.

Sistema di Backup Wallet - Una serie di quattro PR (#844, #845, #846, #848) implementa una funzionalità completa di backup della seed phrase. Gli utenti possono ora esportare il loro mnemonico di 12 parole attraverso un flusso sicuro che previene screenshot, visualizza lo stato del backup nel dashboard del wallet e guida gli utenti esistenti attraverso la migrazione. L’implementazione segue gli standard BIP-39 e include validazione per prevenire che gli utenti perdano fondi a causa della registrazione errata della frase.

Dimensioni Media (NIP-92) - PR #718 implementa il supporto NIP-92 per i corretti rapporti di aspetto di immagini e video. Senza metadati delle dimensioni, i client devono scaricare le immagini per determinare la loro dimensione, causando salti di layout mentre il contenuto si carica. NIP-92 aggiunge tag dim (come ["dim", "1920x1080"]) agli eventi di metadati dei file, permettendo a Primal di riservare lo spazio corretto prima di scaricare i media. Questo elimina i reflow fastidiosi nelle gallerie di immagini e migliora le prestazioni percepite.

Affidabilità Signer Remoto - PR #841 corregge problemi di connessione NIP-46 dove i prefissi wss:// mancanti causavano fallimenti silenziosi. Il PR valida gli URI relay durante la configurazione della connessione bunker, aggiungendo automaticamente il prefisso di protocollo quando gli utenti incollano domini nudi. PR #843 affronta un bug di threading dove condizioni di rete scarse causavano la pubblicazione delle risposte come note radice, rompendo il flusso della conversazione. La correzione garantisce che gli ID degli eventi genitore persistano attraverso le interruzioni di rete.

Marmot Protocol: White Noise (Libreria Chat di Gruppo Crittografata)

White Noise, la libreria Rust che alimenta le chat di gruppo crittografate del Protocollo Marmot, ha unito sei PR migliorando l’esperienza utente e la sicurezza. I cambiamenti portano Marmot più vicino alla parità di funzionalità con le applicazioni di messaggistica mainstream mantenendo la sua architettura privacy-first.

Ricevute di Lettura - PR #433 e #436 implementano il tracciamento della lettura dei messaggi per le conversazioni di gruppo. Il sistema memorizza le posizioni di lettura per utente per gruppo all’interno di un singolo dispositivo, abilitando i badge del conteggio non letti. L’implementazione usa timestamp monotonici per tracciare l’ultima posizione di messaggio letto per ogni conversazione. Questa funzionalità fondamentale abilita indicatori UI che mostrano i conteggi di messaggi non letti per conversazione.

Fissaggio Conversazioni - PR #442 aggiunge il fissaggio persistente delle conversazioni attraverso un campo pin_order nella tabella di giunzione accounts_groups che collega gli account ai gruppi. Le conversazioni fissate mantengono la loro posizione in cima alle liste di chat indipendentemente dall’attività dei messaggi, rispettando le aspettative degli utenti da Signal e WhatsApp. L’implementazione usa l’ordinamento intero per permettere pin illimitati con ordinamento deterministico.

Risoluzione Commit Deterministica (MIP-03) - PR #152 (aperta) implementa il Marmot Improvement Proposal 03, risolvendo il problema critico delle race condition dei commit nelle chat di gruppo distribuite. Quando più membri inviano cambiamenti di stato del gruppo (aggiungere/rimuovere membri, cambiare permessi) simultaneamente, i client potrebbero divergere sull’ordinamento dei commit, frammentando il gruppo in stati incompatibili. MIP-03 introduce snapshot di epoca e una selezione deterministica del vincitore: vince il commit con il timestamp created_at più precoce, con l’ID evento lessicografico come tiebreaker. Questo permette a tutti i client di convergere sullo stesso stato attraverso rollback e replay, mantenendo la coerenza del gruppo anche durante le partizioni di rete.

Hardening di Sicurezza - PR #443 previene la copia non necessaria di segreti crittografici usando riferimenti in resolve_group_image_path. Questo riduce la finestra per attacchi alla memoria dove i segreti potrebbero essere recuperati da allocazioni heap liberate. PR #438 abilita la crittografia del database SQLCipher attraverso parametri keyring, proteggendo la cronologia dei messaggi a riposo. L’integrazione keyring permette l’archiviazione sicura delle chiavi nei keychain della piattaforma piuttosto che nei file di configurazione.

nostrdb-rs (Libreria Database) - PR Aperta

Implementazione Query Streaming - PR #58 (aperta) propone query fold streaming per abilitare operazioni di database a zero allocazioni. L’implementazione aggiunge metodi fold, try_fold, count, any, all, e find_map che processerebbero i risultati del database uno alla volta senza materializzare interi set di risultati in vettori. Questo approccio ridurrebbe il consumo di memoria e abiliterebbe la terminazione anticipata per pattern di query comuni.

L’implementazione tecnica espone callback di risultati query a basso livello (ndb_query_visit) come visitor Rust stateful che mappano varianti ControlFlow ad azioni visitor C. Una volta unite, il codice applicativo si leggerà come logica iteratore mentre gira vicino al layer database. Ad esempio, contare note corrispondenti farebbe streaming attraverso i risultati piuttosto che raccoglierli, e find_map ritornerebbe il primo risultato utile senza processare le righe rimanenti.

nostrdb alimenta Damus e Notedeck, rispettivamente client iOS/macOS e desktop. Le query streaming abiliterebbero pattern efficienti come paginazione, filtraggio condizionale e controlli di esistenza. Il PR cambia 3 file con +756 aggiunte e -32 eliminazioni, un refactoring sostanziale del layer query. Gli utenti delle applicazioni basate su nostrdb-rs vedrebbero un uso ridotto della memoria quando navigano timeline grandi o cercano attraverso database eventi estesi.

nak (Strumento CLI)

nak, lo strumento Nostr da linea di comando di fiatjaf, ha unito sei PR focalizzati sui miglioramenti del sistema di build e nuove funzionalità. PR #91 implementa una funzionalità mirror Blossom, permettendo a nak di servire come mirror per server media Blossom. Blossom è un protocollo di archiviazione media indirizzato ai contenuti che lavora insieme agli eventi Nostr.

I PR rimanenti affrontano la compatibilità del sistema di build attraverso le piattaforme Windows, macOS e Linux, abilitando il supporto filesystem FUSE per montare gli eventi Nostr come directory locali.

Damus (Client iOS) - PR Aperte

Damus ha 11 PR aperte che esplorano miglioramenti architetturali significativi. Sebbene questi non siano stati ancora uniti, segnalano direzioni importanti per lo sviluppo del client Nostr iOS, particolarmente attorno alla privacy, l’efficienza di sincronizzazione e l’ottimizzazione dei dati mobili.

Integrazione Tor - PR #3535 incorpora il client Arti Tor direttamente in Damus, abilitando connessioni relay anonime senza dipendenze esterne. A differenza degli approcci Orbot o Tor Browser, incorporare Arti fornisce un’integrazione senza soluzione di continuità con il sandboxing iOS e i limiti di esecuzione in background. L’implementazione Rust porta la sicurezza della memoria all’anonimizzazione di rete, riducendo la superficie di attacco rispetto a C Tor. Gli utenti potrebbero attivare la modalità Tor per relay o globalmente, con il client che gestisce la gestione dei circuiti in modo trasparente.

Protocollo di Sincronizzazione Negentropy - PR #3536 implementa Negentropy, un protocollo di riconciliazione di set che migliora radicalmente l’efficienza di sincronizzazione. Invece di scaricare tutti gli eventi dall’ultima connessione, Negentropy scambia fingerprint compatti (alberi Merkle) per identificare esattamente quali eventi differiscono tra client e relay. Per gli utenti che seguono centinaia di pubkey, questo riduce la banda di sincronizzazione da megabyte a kilobyte. L’implementazione si integra con RelayPool e SubscriptionManager, abilitando la sincronizzazione efficiente automatica attraverso tutti i relay connessi.

Modalità Dati Bassi - PR #3549 aggiunge funzionalità di conservazione dei dati cellulari rispondendo al feedback degli utenti sul consumo di banda. La modalità disabilita il caricamento automatico delle immagini, il prefetching dei video e riduce i limiti di sottoscrizione. Gli utenti su connessioni a consumo possono navigare contenuti testuali senza paura di superare i limiti dati. L’implementazione rispetta le impostazioni della modalità dati bassi di iOS e fornisce controlli granulari per diversi tipi di media.

Ottimizzazioni Database - PR #3548 rilavora l’archiviazione snapshot nostrdb per query più veloci e uso ridotto del disco. L’ottimizzazione cambia come gli snapshot del database persistono su disco, migliorando sia le prestazioni di lettura che l’amplificazione di scrittura. Questo affronta le lamentele sul consumo della batteria da parte degli utenti con database eventi grandi.

È tutto per questa settimana. State costruendo qualcosa? Avete notizie da condividere? Volete che copriamo il vostro progetto? Contattateci via DM NIP-17 o trovateci su Nostr.

Nostr Compass #5

Tue, 13 Jan 2026 00:00:00 +0000

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

Questa settimana: Bitchat viene sottoposto a un audit di sicurezza professionale da Cure53, la stessa azienda che ha verificato Signal e NIP-44, con oltre 17 PR già integrate per correggere vulnerabilità critiche. NIP-71 è stato approvato, portando nel protocollo gli event video indirizzabili. Una NIP sulla crittografia post-quantistica apre la discussione sulla protezione futura di Nostr contro gli attacchi quantistici. Amethyst v1.05.0 introduce le liste di segnalibri, le note vocali e una versione desktop preliminare, mentre Nostur v1.25.3 migliora i DM NIP-17 con reazioni e risposte. Per quanto riguarda le librerie, rust-nostr estende il supporto NIP-62 ai backend SQLite e LMDB, e NDK corregge un bug nel tracciamento delle subscription.

Notizie

Bitchat Completa l’Audit di Sicurezza Cure53

Bitchat, il messenger crittografato per iOS che combina Nostr con Cashu, è stato sottoposto a un audit di sicurezza professionale da Cure53, una delle aziende di sicurezza più rispettate del settore. Cure53 ha precedentemente verificato Signal, Mullvad VPN e soprattutto la specifica di crittografia NIP-44 che è alla base della messaggistica privata moderna su Nostr.

L’audit ha rilevato oltre 12 problemi di sicurezza (BCH-01-002 fino a BCH-01-013). Il team di Bitchat ha risposto con oltre 17 pull request. Le correzioni principali includono:

Cancellazione dei Secret DH del Noise Protocol - PR #928 corregge sei punti in cui i secret condivisi Diffie-Hellman non venivano azzerati dopo lo scambio delle chiavi, ripristinando le garanzie di forward secrecy. Quando i secret persistono in memoria più a lungo del necessario, un dump della memoria o un attacco cold boot potrebbero compromettere le comunicazioni passate.

Verifica delle Firme - Diverse PR rafforzano i percorsi di verifica crittografica, assicurando che i controlli di autenticità dei messaggi non possano essere aggirati tramite input malformati.

Thread Safety - PR #929 aggiunge la sincronizzazione con barriere alle code delle ricevute di lettura in NostrTransport, prevenendo race condition che potrebbero causare corruzione dei dati o crash con alti volumi di messaggi.

Sicurezza della Memoria - PR #920 ottimizza il deduplicatore di messaggi per migliori prestazioni con alto throughput di messaggi, evitando l’esaurimento della memoria.

Validazione degli Input - PR #919 rafforza il parsing delle stringhe esadecimali per prevenire crash da input malformati, un vettore di attacco comune per denial-of-service.

Bitchat gestisce ecash Cashu, rendendo essenziale una revisione di sicurezza professionale. L’audit segue quello del Marmot Protocol dello scorso anno e l’audit NIP-44 che ha verificato il layer di crittografia.

Aggiornamenti NIP

Modifiche recenti al repository NIPs:

Approvate:

NIP-71 - Event Video Indirizzabili (#1669) introduce i kind 34235 (video orizzontale) e 34236 (video verticale) come event indirizzabili. Un tag d obbligatorio fornisce identificatori univoci, così i metadati video possono essere aggiornati senza ripubblicare l’intero event. Un tag origin opzionale traccia le fonti di importazione. Già implementato in Amethyst e nostrvine.

PR Aperte:

Crittografia Post-Quantistica - PR #2185 propone l’aggiunta di algoritmi crittografici resistenti ai computer quantistici in Nostr. La specifica introduce ML-DSA-44 e Falcon-512 per le firme digitali, mirando a “event di altissimo valore” come applicazioni e autorità piuttosto che singoli utenti. Mentre la crittografia simmetrica di NIP-44 (ChaCha20) è resistente ai quantum, il suo scambio di chiavi usa secp256k1 ECDH che è vulnerabile all’algoritmo di Shor. La proposta include ML-KEM per lo scambio di chiavi per colmare questa lacuna. Si tratta di una proposta in fase iniziale che apre la discussione sulla cripto-agilità per la sicurezza a lungo termine di Nostr.
BOLT12 per NIP-47 - Dopo 137 commenti e un’ampia discussione, la comunità ha deciso che le offer BOLT12 meritano una specifica propria piuttosto che estendere NIP-47. Le offer BOLT12 offrono miglioramenti significativi rispetto alle invoice BOLT11, inclusa la riusabilità, migliore privacy attraverso i blinded path e informazioni opzionali sul pagatore. La nuova NIP definirà metodi come make_offer, pay_offer e list_offers per le implementazioni Nostr Wallet Connect.
NIP per Tracce Audio - PR #1043 propone i kind 32100 per tracce musicali e 32101 per episodi podcast, dando ai contenuti audio lo stesso trattamento di prima classe che NIP-71 fornisce per i video. Attualmente, le piattaforme audio come Wavlake, Zapstr e Stemstr usano ciascuna formati di event proprietari, frammentando l’ecosistema. Uno standard comune permetterebbe l’interoperabilità così gli utenti potrebbero scoprire e riprodurre audio da qualsiasi client compatibile.
NIP-A3 Target di Pagamento Universali - PR #2119 propone event di kind 10133 che usano URI payto: RFC-8905 per esporre opzioni di pagamento su reti multiple. Invece di creare kind di event separati per Bitcoin, Lightning, Cashu o sistemi di pagamento tradizionali, questa astrazione permette ai client di interpretare tag standardizzati e invocare handler di pagamento nativi. L’approccio è a prova di futuro poiché i nuovi metodi di pagamento necessitano solo di uno schema URI payto:.

Approfondimento NIP: NIP-51 e NIP-65

Questa settimana trattiamo due NIP che memorizzano le preferenze utente: NIP-51 per organizzare i contenuti e NIP-65 per organizzare le connessioni ai relay. Entrambe usano event sostituibili, il che significa che ogni nuova pubblicazione sovrascrive la versione precedente.

NIP-51: Liste

NIP-51 definisce diversi tipi di liste per organizzare riferimenti a event, utenti, hashtag e altri contenuti. Amethyst v1.05.0 aggiunge il supporto ai segnalibri, rendendo questo un buon momento per capire come funzionano le liste.

La specifica definisce diversi kind di liste, ciascuno con uno scopo diverso. Il kind 10000 è la vostra lista di silenziamento per nascondere utenti, thread o parole. Il kind 10001 fissa event da mettere in evidenza sul vostro profilo. Il kind 30003 memorizza i segnalibri, che è ciò che Amethyst ora supporta. Altri kind gestiscono set di following (30000), collezioni di articoli curate (30004), interessi per hashtag (30015) e set di emoji personalizzate (30030).

Le liste referenziano contenuti attraverso tag. Una lista di segnalibri usa tag e per event specifici e tag a per contenuti indirizzabili come articoli:

{
 "id": "ae3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1736784000,
 "kind": 30003,
 "tags": [
 ["d", "saved-articles"],
 ["e", "abc123def456...", "wss://relay.example"],
 ["a", "30023:author-pubkey:article-id", "wss://relay.example"]
 ],
 "content": "<encrypted-private-bookmarks>",
 "sig": "908a15e46fb4d8675bab026fc230a0e3542bfade63da02d542fb78b2a8513fcd0092619a2c8c1221e581946e0191f2af505dfdf8657a414dbca329186f009262"
}

Il tag d fornisce un identificatore univoco, così potete mantenere più set di segnalibri come “saved-articles”, “read-later” o “favorites” sotto lo stesso kind.

Le liste supportano sia elementi pubblici che privati. Gli elementi pubblici appaiono nell’array dei tag, visibili a chiunque recuperi l’event. Gli elementi privati vanno nel campo content, crittografati usando NIP-44 verso voi stessi. Questa doppia struttura vi permette di mantenere segnalibri pubblici aggiungendo note private, o mantenere una lista di silenziamento senza rivelare chi avete silenziato. Per crittografare verso voi stessi, usate NIP-44 con la vostra pubkey come destinatario.

I kind della serie 10000 sono sostituibili, il che significa che i relay mantengono un solo event per pubkey. La serie 30000 è sostituibile parametrizzata, permettendo un event per combinazione di pubkey e tag d. In entrambi i casi, aggiornare una lista significa pubblicare una sostituzione completa; non potete inviare modifiche incrementali. I client dovrebbero preservare i tag sconosciuti quando modificano le liste per evitare di sovrascrivere dati aggiunti da altre applicazioni.

NIP-65: Metadati Lista Relay

NIP-65 definisce event di kind 10002 che pubblicizzano quali relay un utente preferisce per leggere e scrivere. Questo aiuta altri utenti e client a trovare i vostri contenuti.

{
 "id": "bd2217a96b5835b59f9a6a42d8d8a36f8c9b7d4e5f0a1b2c3d4e5f6a7b8c9d0e1",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1736784000,
 "kind": 10002,
 "tags": [
 ["r", "wss://relay.damus.io", "read"],
 ["r", "wss://nos.lol"],
 ["r", "wss://relay.nostr.band", "write"]
 ],
 "content": "",
 "sig": "f1c2d3e4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2"
}

Ogni tag r contiene un URL del relay e un marcatore opzionale. Un marcatore write designa la vostra outbox: relay dove pubblicate i vostri contenuti. Un marcatore read designa la vostra inbox: relay dove controllate menzioni, risposte e tag. Omettere il marcatore indica entrambi.

Quando Alice vuole trovare i post di Bob, il suo client recupera il kind 10002 di Bob, estrae i suoi relay write (la sua outbox) e si iscrive lì. Quando Alice risponde a Bob, il suo client pubblica sui suoi relay read (la sua inbox) così lui vedrà la menzione. Questo routing consapevole dei relay è il “modello outbox”, e distribuisce gli utenti su molti relay invece di concentrare tutti su pochi server centrali.

NIP-65 gestisce il routing dei contenuti pubblici, ma i messaggi privati usano una lista separata. NIP-17 definisce il kind 10050 per i relay inbox dei DM, usando tag relay invece di tag r. Quando inviate a qualcuno un messaggio privato, i client cercano l’event kind 10050 del destinatario e pubblicano lì il messaggio crittografato gift-wrapped. Questa separazione mantiene il routing dei DM distinto dal routing dei contenuti pubblici, e permette agli utenti di specificare relay diversi per comunicazioni private rispetto a quelle pubbliche.

Il modello outbox migliora la resistenza alla censura poiché nessun singolo relay deve memorizzare o servire i contenuti di tutti. I client mantengono connessioni ai relay elencati negli event NIP-65 degli utenti seguiti, collegandosi dinamicamente a nuovi relay mentre scoprono nuovi account. NIP-65 complementa gli hint dei relay trovati in altre NIP. Quando taggate qualcuno con ["p", "pubkey", "wss://hint.relay"], l’hint dice ai client dove cercare quel riferimento specifico. NIP-65 fornisce la lista autorevole controllata dall’utente, mentre gli hint offrono scorciatoie incorporate nei singoli event.

Per migliori risultati, mantenete aggiornata la vostra lista di relay poiché voci obsolete vi rendono più difficili da trovare. La specifica raccomanda da due a quattro relay per categoria. Elencare troppi relay grava su ogni client che vuole recuperare i vostri contenuti, rallentando la loro esperienza e aumentando il carico di rete. I client memorizzano in cache gli event NIP-65 e li aggiornano periodicamente per rimanere al passo con le preferenze aggiornate degli utenti.

Release

Amethyst v1.05.0 - Il popolare client Android rilascia un aggiornamento importante con diverse funzionalità di rilievo. Le liste di segnalibri NIP-51 kind 30003 permettono agli utenti di salvare post per riferimento futuro, sincronizzandosi tra client compatibili. Le note vocali ora funzionano nei DM e nei post regolari con visualizzazione della forma d’onda, selezione del media server e indicatori di progresso del caricamento. I punteggi Web of Trust sono ora visibili nell’interfaccia, aiutando gli utenti a capire come l’algoritmo valuta gli account relativamente al loro grafo sociale. La migrazione del database Quartz migliora le prestazioni delle query come parte del lavoro Kotlin Multiplatform finanziato da OpenSats. Una release desktop preliminare porta Amethyst su Windows, macOS e Linux tramite Compose Multiplatform, condividendo lo stesso codebase dell’app Android. Nuovi flussi di onboarding per gli utenti facilitano l’esperienza per chi usa Nostr per la prima volta.

Nostur v1.25.3 - Il client iOS e macOS si concentra sulla messaggistica privata con miglioramenti a NIP-17. Le conversazioni DM ora supportano reazioni e risposte, portando l’interattività dei post pubblici nei messaggi crittografati. La vista delle conversazioni è stata rielaborata con un migliore threading così gli scambi multi-messaggio sono più facili da seguire, e i timestamp mostrano “tempo fa” nella lista DM per una scansione rapida. Gli utenti desktop ottengono layout multi-colonna per visualizzare feed o conversazioni multiple affiancate. Il supporto al remote signer NIP-46 permette agli utenti di mantenere le loro chiavi private in app di firma dedicate come Amber o nsec.app. Correzioni aggiuntive ripristinano la funzionalità DM su iOS 15 e iOS 16, risolvono ritardi nelle notifiche e aggiungono la possibilità di configurare quali relay ricevono i DM pubblicati.

Modifiche notevoli a codice e documentazione

Queste sono pull request aperte e lavori in fase iniziale, perfetti per ricevere feedback prima del merge. Se qualcosa vi interessa, considerate di fare review o commentare!

Citrine (Relay Android)

PR #89 corregge una vulnerabilità SQL injection nell’app relay personale Android. Il problema permetteva a dati di event malformati di eseguire query arbitrarie sul database, un difetto grave per qualsiasi app che memorizza ed elabora input non fidati. La correzione sanifica correttamente tutte le operazioni sul database usando query parametrizzate. Non è ancora stata taggata una release, quindi gli utenti dovranno aspettare la prossima versione o compilare dal sorgente. PR #90 ottimizza le prestazioni delle query ContentProvider con filtraggio e paginazione a livello di database, riducendo la latenza quando app esterne come Amethyst accedono al database di event di Citrine attraverso il layer di comunicazione inter-processo di Android.

rust-nostr (Libreria)

Il supporto a NIP-62 (Richieste di Scomparsa) si sta espandendo attraverso i backend di database di rust-nostr. PR #1180, integrata due settimane fa, ha aggiunto il supporto NIP-62 a SQLite, gestendo le richieste di scomparsa ALL_RELAYS poiché il layer del database non conosce URL specifici dei relay. PR #1210 estende questo al backend LMDB, assicurando che le richieste di scomparsa siano persistite su disco e sopravvivano ai riavvii del relay. Un’implementazione IndexedDB per ambienti browser è anche in corso. Insieme, queste modifiche danno agli sviluppatori un supporto NIP-62 coerente attraverso SQLite, LMDB e presto lo storage del browser.

NDK (Nostr Development Kit)

PR #375 corregge un bug nel sistema di tracciamento seenEvents. Il problema causava che certi pattern di subscription marcassero erroneamente gli event come già visti, portando a contenuti mancati quando gli utenti aprivano nuove subscription o si riconnettevano ai relay. La correzione assicura che gli event siano tracciati accuratamente attraverso i cicli di vita delle subscription, il che è particolarmente importante per applicazioni che si iscrivono e cancellano dinamicamente in base alla navigazione dell’utente. NDK è passato alla beta.70 con questa correzione inclusa.

Damus (iOS)

PR #3515 corregge un crash all’avvio che colpiva gli utenti iOS 17. Il problema derivava da un overflow aritmetico in NdbUseLock, una classe di fallback usata perché i Mutex di Swift non sono disponibili su iOS 17. La correzione sostituisce l’approccio di sincronizzazione precedente con NSLock, che è disponibile su iOS 17 e gestisce correttamente le race condition rimanenti. Gli utenti iOS 18+ non erano colpiti poiché hanno accesso all’implementazione nativa del Mutex Swift.

Separatamente, un gruppo di miglioramenti per gli articoli longform è arrivato tramite PR #3509. Le barre di progresso della lettura tracciano la vostra posizione attraverso gli articoli, i tempi di lettura stimati appaiono nelle anteprime, e la modalità seppia con impostazioni di altezza riga regolabili forniscono una lettura più confortevole. La modalità focus nasconde automaticamente la chrome di navigazione durante lo scorrimento verso il basso e la ripristina al tocco, riducendo il disordine visivo per una lettura senza distrazioni. Diverse correzioni affrontano la visualizzazione delle immagini nei contenuti markdown e assicurano che gli articoli si aprano dall’inizio piuttosto che a metà.

Zap.stream (Live Streaming)

L’integrazione della chat di YouTube e Kick collega i messaggi dalle piattaforme di streaming esterne a Nostr. Gli streamer che trasmettono in multicast su YouTube, Kick e Zap.stream possono ora vedere tutti i messaggi della chat in una vista unificata, con i messaggi da ogni piattaforma che appaiono accanto ai commenti nativi Nostr. Questo rimuove un importante punto di attrito per i creator che vogliono usare Nostr per lo streaming ma non possono abbandonare il pubblico sulle piattaforme consolidate. L’integrazione mostra da quale piattaforma ha origine ogni messaggio e gestisce il flusso di autenticazione per connettere account esterni.

Chachi (Gruppi NIP-29)

Il client di chat di gruppo NIP-29 ha integrato sei PR questa settimana. Un aggiornamento di sicurezza affronta CVE-2026-22029, una vulnerabilità XSS in react-router che potrebbe abilitare attacchi di open redirect; la correzione aggiorna a react-router-dom 6.30.0. PR #92 aggiunge il caricamento paginato dei messaggi per le chat di gruppo, così le conversazioni lunghe si caricano incrementalmente piuttosto che tutte insieme. PR #91 corregge diversi bug NIP-29 inclusa una race condition che causava nomi di gruppo vuoti al caricamento iniziale e liste di partecipanti non definite che facevano crashare le viste dei membri. La copertura delle traduzioni ora copre tutte le 31 lingue supportate con 1060 chiavi ciascuna.

0xchat (Messaggistica)

Il client di messaggistica stile Telegram ha migliorato la conformità a NIP-55 salvando correttamente i nomi dei pacchetti dei signer quando si usano app di firma esterne, correggendo problemi in cui l’app perdeva traccia di quale signer usare dopo i riavvii. La gestione delle risposte NIP-17 ora include correttamente il tag e per il threading, assicurando che le risposte appaiano nel contesto di conversazione corretto attraverso i client. Le ottimizzazioni delle prestazioni affrontano il lag di scorrimento nelle liste di messaggi, un punto dolente comune quando si caricano cronologie di chat lunghe. Il salvataggio automatico delle bozze previene la perdita di messaggi se navigate via durante la composizione, e le opzioni di archiviazione file ora includono endpoint predefiniti FileDropServer e BlossomServer.

Primal (iOS)

Il supporto al remote signer NIP-46 arriva su iOS tramite PR #184, completando il rollout cross-platform iniziato con Android diverse settimane fa. Gli utenti possono ora mantenere le loro chiavi private in servizi bunker dedicati come nsec.app o istanze nsecBunker self-hosted, connettendosi attraverso relay Nostr per firmare event senza esporre le chiavi all’app client. Questa separazione migliora la postura di sicurezza per gli utenti che vogliono usare le funzionalità di Primal mantenendo pratiche di gestione delle chiavi più rigorose. L’implementazione include la scansione di codici QR per gli URI di connessione al bunker e gestisce il flusso richiesta/risposta NIP-46 attraverso messaggi relay crittografati.

Questo è tutto per questa settimana. State costruendo qualcosa? Avete notizie da condividere? Volete che copriamo il vostro progetto? Contattateci tramite DM NIP-17 o trovateci su Nostr.

Nostr Compass #4

Wed, 07 Jan 2026 00:00:00 +0000

Bentornati su Nostr Compass, la vostra guida settimanale all’ecosistema del protocollo Nostr.

Questa settimana: Primal Android implementa la firma remota NIP-46 e il supporto per signer locali NIP-55, trasformandosi in un hub di firma completo per altre app Android. Il team del Marmot Protocol ha affrontato le problematiche emerse da un audit di sicurezza con 18 PR integrate che rafforzano la messaggistica crittografata basata su MLS. Citrine raggiunge la v1.0 e Applesauce rilascia la v5.0 per l’intera suite di librerie. TENEX sviluppa la supervisione di agenti AI su Nostr, e Jumble aggiunge il pooling intelligente dei relay. Una correzione alla specifica NIP-55 chiarisce i campi di ritorno di nip44_encrypt, e una PR per NIP-50 propone estensioni per espressioni di query per ricerche avanzate. Nel nostro approfondimento, spieghiamo NIP-04 e NIP-44: perché la crittografia legacy presenta falle di sicurezza e come la sostituzione moderna le risolve.

Notizie

Primal Android diventa un Hub di Firma Completo - La Versione 2.6.18 aggiunge sia la firma remota NIP-46 che la firma locale NIP-55, trasformando Primal in un signer completo per altre app Nostr. La firma remota tramite NIP-46 permette agli utenti di connettersi a servizi bunker attraverso i relay Nostr, mantenendo le chiavi completamente fuori dal dispositivo. La firma locale tramite NIP-55 espone Primal come content provider Android, così app come Amethyst o Citrine possono richiedere firme senza mai toccare la chiave privata. Diverse PR successive hanno risolto problemi di compatibilità con il requisito della specifica NIP-55 per pubkey esadecimali, e migliorato il parsing di URI nostrconnect:// malformati. Il rilascio include anche pre-caching dei media per uno scorrimento più fluido, tempi di caricamento dei thread migliorati e pre-caching degli avatar.

Marmot Protocol rafforza la sicurezza dopo l’Audit - Il Marmot Development Kit (mdk), che implementa la messaggistica end-to-end crittografata basata su NIP-104 MLS, ha ricevuto ampie correzioni di sicurezza questa settimana. Diciotto pull request integrate hanno affrontato le problematiche dell’audit tra cui: verifica hash per immagini di gruppo crittografate per prevenire attacchi di sostituzione blob a livello storage, paginazione per welcome pendenti per prevenire esaurimento della memoria, perdita di MLS Group ID nei messaggi di errore, e applicazione della codifica base64 per i key package. La specifica Marmot stessa è stata aggiornata con MIP-04 v2 versioning e miglioramenti di sicurezza. PR attive continuano ad affrontare riuso di nonce, azzeramento dei segreti e vettori di inquinamento della cache.

Nostrability traccia il supporto Relay Hint - Un nuovo tracker di compatibilità relay hints documenta come i client costruiscono e consumano relay hint nell’ecosistema. Il tracker rivela che mentre la maggior parte dei client ora costruisce hint secondo NIP-10 e NIP-19, il consumo varia ampiamente: alcuni client includono hint negli eventi in uscita ma non usano gli hint in entrata per il recupero. Sei client hanno ottenuto lo status “Full” per implementazione completa. Il tracker è utile per sviluppatori che verificano l’interoperabilità e per utenti che si chiedono perché alcuni client trovano contenuti che altri non riescono a trovare.

Nostria 2.0 rilascia revisione completa delle funzionalità Cross-Platform - Il client Nostria ha rilasciato la versione 2.0 il 30 dicembre con aggiunte significative su iOS (TestFlight), Android (Play Store), Web e Windows. Il rilascio aggiunge supporto nativo per la musica con creazione di playlist, caricamento di tracce, pagamenti agli artisti basati su zap, e un player in stile WinAmp con equalizzatore funzionante. Lo streaming live ottiene l’integrazione Game API che mostra metadati ricchi durante gli streaming di gameplay. Una nuova funzione Summary genera digest di attività orari, giornalieri o settimanali come viste timeline compresse. La sezione Discover offre liste curate per trovare contenuti e profili. La pubblicazione di media è semplificata con generazione automatica di post short-form per la scoperta cross-client. Le connessioni ai signer remoti ora funzionano tramite scansione di codici QR senza configurazione manuale. La scoperta dei profili affronta un problema comune di Nostr: quando gli utenti si spostano tra relay senza portare i propri metadati, Nostria localizza il loro profilo e lo ripubblica sui relay correnti. Gli abbonati Premium ottengono integrazione con canali YouTube, Memo privati, dashboard analitiche e backup automatici delle liste di following con opzioni di merge/restore.

Aggiornamenti NIP

Modifiche recenti al repository NIPs:

Integrate:

NIP-55 - Corretto il campo di ritorno per il metodo nip44_encrypt (#2184). I signer Android devono ora restituire il payload crittografato nel campo signature (come nip44_decrypt) invece che in un campo separato. Questo allinea la specifica con le implementazioni esistenti in Amber e Primal.

PR Aperte:

NIP-50 - Estensioni Espressioni di Query (#2182) propone di estendere la ricerca NIP-50 con espressioni di query strutturate. La PR aggiunge operatori come kind:1, author:npub1..., e combinazioni booleane (AND, OR, NOT), abilitando query di ricerca più precise oltre il semplice matching testuale. Questo permetterebbe ai client di costruire interfacce di ricerca avanzate mantenendo la retrocompatibilità con stringhe di ricerca base.

Approfondimento NIP: NIP-04 e NIP-44

Questa settimana copriamo gli standard di crittografia Nostr: il legacy NIP-04 che incontrerete ancora, e la sua sostituzione moderna NIP-44 che corregge falle di sicurezza critiche.

NIP-04: Messaggi Diretti Crittografati (Legacy)

NIP-04 è stato il primo tentativo di Nostr per la messaggistica crittografata, usando eventi di kind 4. Sebbene semplice da implementare, ha debolezze di sicurezza note ed è deprecato in favore di NIP-44.

Come funziona: NIP-04 usa ECDH (Elliptic Curve Diffie-Hellman) per derivare un segreto condiviso tra mittente e destinatario, poi crittografa con AES-256-CBC.

{
 "id": "<event-id>",
 "pubkey": "<sender-pubkey>",
 "created_at": 1736200000,
 "kind": 4,
 "tags": [["p", "<recipient-pubkey>"]],
 "content": "base64-ciphertext?iv=base64-iv",
 "sig": "<signature>"
}

Il flusso di crittografia:

Calcola il punto condiviso: shared = ECDH(sender_privkey, recipient_pubkey)
Deriva la chiave: key = SHA256(shared_x_coordinate)
Genera IV casuale di 16 byte
Crittografa: ciphertext = AES-256-CBC(key, iv, plaintext)
Formatta il contenuto: base64(ciphertext)?iv=base64(iv)

Problemi di sicurezza:

Nessuna autenticazione: AES-CBC fornisce confidenzialità ma non integrità. Un attaccante che controlla un relay potrebbe modificare bit del ciphertext, causando modifiche prevedibili al plaintext (attacchi bit-flipping).
IV in chiaro: Il vettore di inizializzazione è trasmesso insieme al ciphertext, e la modalità CBC con IV prevedibili abilita attacchi chosen-plaintext.
Nessuna validazione del padding: Le implementazioni variano nel modo in cui gestiscono il padding PKCS#7, potenzialmente abilitando attacchi padding oracle.
Esposizione dei metadati: La pubkey del mittente, la pubkey del destinatario e il timestamp sono tutti visibili ai relay.
Riuso della chiave: Lo stesso segreto condiviso è usato per tutti i messaggi tra due parti, per sempre.

Perché esiste ancora: Molti client e relay più vecchi supportano solo NIP-04. Lo incontrerete quando interagite con sistemi legacy. Signer come Amber e app come Primal implementano ancora nip04_encrypt/nip04_decrypt per retrocompatibilità.

NIP-44: Crittografia Versionata

NIP-44 è lo standard di crittografia moderno, progettato per correggere le falle note di NIP-04. Un audit di sicurezza Cure53 delle implementazioni NIP-44 ha identificato 10 problemi (inclusi attacchi temporali e preoccupazioni sulla forward secrecy) che sono stati affrontati prima della finalizzazione della specifica. Usa ChaCha20-Poly1305 con derivazione di chiave appropriata e crittografia autenticata.

Miglioramenti chiave rispetto a NIP-04:

Aspetto	NIP-04	NIP-44
Cifrario	AES-256-CBC	XChaCha20-Poly1305
Autenticazione	Nessuna	Poly1305 MAC
Derivazione chiave	SHA256(shared_x)	HKDF con salt
Nonce	IV 16 byte, pattern riusato	Nonce casuale 24 byte
Padding	PKCS#7 (rivela lunghezza)	Arrotondato a potenza di 2
Versionamento	Nessuno	Prefisso byte versione

Flusso di crittografia:

Chiave di conversazione: Deriva una chiave stabile per ogni coppia mittente-destinatario:

shared_x = ECDH(sender_privkey, recipient_pubkey).x
conversation_key = HKDF-SHA256(
 ikm = shared_x,
 salt = "nip44-v2",
 info = ""
)

Chiavi del messaggio: Per ogni messaggio, genera un nonce casuale di 32 byte e deriva chiavi di crittografia/autenticazione:

keys = HKDF-SHA256(
 ikm = conversation_key,
 salt = nonce,
 info = "nip44-v2"
)
chacha_key = keys[0:32]
chacha_nonce = keys[32:44]
hmac_key = keys[44:76]

Padding del plaintext: Arrotonda alla prossima potenza di 2 (minimo 32 byte) per nascondere la lunghezza del messaggio:
```
padded = [length_u16_be] + [plaintext] + [zeri fino alla prossima potenza di 2]
```

Crittografa e autentica:

ciphertext = XChaCha20(chacha_key, chacha_nonce, padded)
mac = HMAC-SHA256(hmac_key, nonce + ciphertext)

Formatta il payload:

payload = [version=0x02] + [nonce] + [ciphertext] + [mac]
content = base64(payload)

Byte di versione: Il primo byte (0x02) indica la versione di crittografia. Questo permette upgrade futuri senza compromettere i messaggi esistenti. La versione 0x01 era una bozza precedente mai ampiamente distribuita.

Decrittografia:

Decodifica base64, verifica che il byte di versione sia 0x02
Estrai nonce (byte 1-32), ciphertext e MAC (ultimi 32 byte)
Deriva la chiave di conversazione usando la chiave privata del destinatario e la chiave pubblica del mittente
Deriva le chiavi del messaggio dalla chiave di conversazione e dal nonce
Verifica il MAC prima di decrittografare (rifiuta se non valido)
Decrittografa il ciphertext, estrai il prefisso di lunghezza, restituisci il plaintext senza padding

Proprietà di sicurezza:

Crittografia autenticata: Il MAC Poly1305 assicura che qualsiasi manomissione sia rilevata prima della decrittografia
Forward secrecy (parziale): Ogni messaggio usa un nonce unico, quindi compromettere un messaggio non rivela gli altri. Tuttavia, compromettere una chiave privata rivela comunque tutti i messaggi passati (nessun ratcheting).
Occultamento della lunghezza: Il padding a potenza di 2 oscura la lunghezza esatta del messaggio
Resistenza agli attacchi temporali: Confronto a tempo costante per la verifica del MAC

Uso pratico: NIP-44 è il livello di crittografia per:

NIP-17 messaggi diretti privati (dentro gift wrap)
NIP-46 comunicazione con signer remoti
NIP-59 crittografia seal
Marmot Protocol messaggi di gruppo, dove NIP-44 avvolge contenuto crittografato MLS usando una chiave derivata dal segreto esportatore MLS
Qualsiasi applicazione che necessita crittografia sicura punto-a-punto

Guida alla migrazione: Le nuove applicazioni dovrebbero usare esclusivamente NIP-44. Per retrocompatibilità, verificate se il client del contatto supporta NIP-44 (tramite metadati app NIP-89 o supporto relay) prima di ricadere su NIP-04. Quando ricevete messaggi, tentate prima la decrittografia NIP-44, poi ricadete su NIP-04 per contenuti legacy.

Rilasci

Primal Android v2.6.18 - Il rilascio completo aggiunge firma remota NIP-46 e firma locale NIP-55, trasformando Primal in un hub di firma per altre app Android. I miglioramenti delle prestazioni includono pre-caching dei media, pre-caching degli avatar e caricamento più veloce dei thread. Le correzioni di bug affrontano auto-menzioni nelle bio, crash nella galleria media e fallback dei titoli degli stream. Su iOS, Primal usa la riproduzione audio in background per mantenere l’app attiva per ricevere richieste di firma NIP-46; gli utenti possono cambiare il suono o silenziarlo completamente nelle impostazioni.

Mostro v0.15.6 - L’ultimo rilascio della piattaforma di trading P2P Bitcoin NIP-69 completa l’implementazione del fondo di sviluppo con gli eventi di audit della Fase 4. I pagamenti delle commissioni dev sono ora tracciati tramite eventi Nostr kind 38383 pubblicati dopo ogni pagamento riuscito, abilitando verifica e analytics di terze parti. I calcoli degli importi sono stati corretti per i messaggi acquirente/venditore, e la logica del premium è stata allineata con l’implementazione di riferimento lnp2pbot.

Aegis v0.3.5 - Il signer cross-platform aggiunge la modalità scura, visualizzazione migliorata delle icone app e layout UI più puliti. Le correzioni di bug affrontano conflitti iOS iCloud Private Relay e problemi di parsing degli eventi. Il rilascio migliora anche come il JSON degli eventi viene passato alla funzione di firma Rust.

Citrine v1.0.0 - L’app relay Android raggiunge la 1.0. Citrine permette di eseguire un relay Nostr personale direttamente sul dispositivo Android, utile per caching locale, backup o come companion NIP-55. Questo rilascio aggiunge un gestore di crash report, migliora l’efficienza delle query database e aggiorna le traduzioni tramite Crowdin.

Applesauce v5.0.0 - La suite di librerie TypeScript di hzrd149 rilascia una major version con breaking changes focalizzati su correttezza e semplicità. Il pacchetto core ora verifica le firme degli eventi per default e rinomina i metodi coordinate per usare terminologia “address” più chiara (parseCoordinate -> parseReplaceableAddress). Il pacchetto relay abbassa i retry di default da 10 a 3 e ignora i relay irraggiungibili per default, più aggiunge createUnifiedEventLoader per un recupero eventi più semplice. Il pacchetto wallet ottiene la scoperta mint Cashu NIP-87. Le dipendenze dirette da nostr-tools sono state rimosse dai pacchetti, riducendo dimensione del bundle e conflitti di versione.

Modifiche notevoli a codice e documentazione

Queste sono pull request aperte e lavori in fase iniziale, perfetti per ricevere feedback prima del merge. Se qualcosa vi interessa, considerate di revisionare o commentare!

Damus (iOS)

Una serie di PR migliorano l’esperienza degli articoli longform. Miglioramenti UX di lettura aggiungono una barra di progresso, tempo di lettura stimato, modalità seppia, altezza delle righe regolabile e modalità focus che nasconde la navigazione durante lo scorrimento. Correzioni immagini assicurano che le immagini nel contenuto markdown vengano visualizzate con proporzioni corrette preprocessando le immagini standalone come elementi block-level. Card anteprima longform sostituiscono il testo inline @naddr1... con card di anteprima ricche che mostrano titolo dell’articolo e metadati. Una nuova suite di test di integrazione relay aggiunge 137 test relativi alla rete inclusa verifica protocollo NIP-01 e comportamento in condizioni di rete degradate (simulazione 3G).

Bitchat (Messaggistica Crittografata)

Rafforzamento della sicurezza nel messenger iOS Nostr+Cashu. Pulizia segreti DH protocollo Noise corregge sei posizioni dove i segreti condivisi non venivano azzerati dopo l’accordo chiavi Diffie-Hellman, ripristinando le garanzie di forward secrecy. Thread safety per code read receipt aggiunge sincronizzazione barrier per prevenire race condition in NostrTransport. Ottimizzazione deduplicatore messaggi migliora le prestazioni con alti volumi di messaggi, e rafforzamento parsing stringhe hex previene crash da input malformato.

Frostr (Firma a Soglia)

Il protocollo di firma a soglia basato su FROST ha aggiunto visualizzazione codici QR per credenziali di gruppo e credenziali di share durante l’onboarding e nell’interfaccia signer. Questo abilita una configurazione più semplice quando si distribuiscono key share su dispositivi multipli, permettendo agli utenti di scansionare credenziali invece di copiare manualmente stringhe lunghe.

Marmot mdk (Libreria)

Oltre alle correzioni di sicurezza menzionate sopra, PR attive affrontano i rimanenti risultati dell’audit: Tipo Secret per azzeramento introduce un tipo wrapper che azzera automaticamente i dati sensibili alla distruzione, paginazione query messaggi previene esaurimento memoria durante il caricamento della cronologia chat, e storage crittografato aggiunge crittografia a riposo per il database SQLite che memorizza stato di gruppo e messaggi.

Amethyst (Android)

Una settimana intensa di correzioni di stabilità nel client Android. Parsing JSON tollerante previene crash da eventi malformati rendendo Kotlin Serialization più permissiva. La validazione eventi ora controlla la dimensione del campo kind prima dell’elaborazione per evitare eccezioni da valori sovradimensionati. La UI del trust score ha ottenuto un’icona più piccola per ridurre l’interferenza visiva, e logging errori migliorato aiuta a diagnosticare problemi di connessione ai relay. Aggiornamenti delle traduzioni sono arrivati tramite Crowdin, e diversi warning SonarQube sono stati affrontati.

TENEX (Agenti AI)

Il framework di agenti AI nativo Nostr ha visto 81 commit questa settimana per costruire capacità autonome. Il nuovo sistema di supervisione agenti implementa euristiche comportamentali per monitorare le azioni degli agenti e intervenire quando necessario. Trasparenza della delega aggiunge logging degli interventi utente alle trascrizioni di delega, così gli utenti possono verificare cosa hanno fatto gli agenti per loro conto. Il registro provider LLM è stato modularizzato per una più facile integrazione di diversi backend AI. Il supporto conversazioni cross-project permette agli agenti di mantenere il contesto attraverso multipli progetti basati su Nostr.

Jumble (Client Web)

Il client web focalizzato sui relay ha aggiunto diversi miglioramenti all’esperienza utente. Pool relay intelligente gestisce intelligentemente le connessioni basandosi sui pattern di utilizzo. Toggle feed live permette agli utenti di passare tra streaming in tempo reale e refresh manuale. Auto-mostra nuove note in cima fa emergere contenuto fresco senza richiedere ricaricamento della pagina. Cache persistente per feed following e notifiche migliora i tempi di caricamento alle visite successive. Gli utenti possono ora cambiare i relay di default attraverso le impostazioni.

Questo è tutto per questa settimana. State costruendo qualcosa? Avete notizie da condividere? Volete che copriamo il vostro progetto? Contattateci via NIP-17 DM o trovateci su Nostr.

Newsletter on Nostr Compass

Nostr Compass #42

Notizie principali

Holoboard aggiunge comandi di promozione Nostr e un’app Android

fips-pub-domains sperimenta nomi pubblici firmati per una mesh

Marmot MDK 0.11.0 rende visibili le lacune nella cronologia degli account

Myco 0.8.0–0.8.1 dà alle app condivise tra dispositivi vicini un proprio store Nostr

Release con tag

White Noise Android aggiunge sondaggi di gruppo e impostazioni predefinite per account sui messaggi a scomparsa

nostream 3.1.0 adegua la proof of work del relay al carico

Nostr double ratchet 0.0.171–0.0.172 chiude una falla legata ai membri rimossi

Scramble 0.7.4–0.7.5 recupera i messaggi che un nuovo membro del gruppo dovrebbe vedere

Amber 6.6.6 ripara i segreti di connessione del signer remoto

FIPS 0.5.2 blocca una fuga di privacy nella scoperta via Nostr

napplet soyLI 0.23.1–0.23.4 ripara la pubblicazione del backend e l’approvazione del signer

Dart NDK 0.10.0 delimita l’autenticazione Blossom e la firma remota

Mostro Core 0.16.0 rimuove il vecchio trasporto gift-wrap

Cambium 0.6.0–0.7.1 registra un telefono di sblocco tramite messaggi dei relay

Bray 3.5.0–3.5.2 limita la spesa del wallet Nostr avviata dagli agenti

Mafrend 1.3.0-alpha porta i gruppi privati sulla mappa alla versione attuale di Marmot

Sonar alpha.15–alpha.15.1 ripara la pubblicazione nei gruppi crittografati

I pacchetti commerce di Elisym introducono ordini Nostr privati

Flotilla 1.11.2 sblocca i signer e i feed dei relay incompleti

Ditto 2.42.3 mostra la consegna ai relay e rafforza i confini tra account

Iris Chat 2026.9.24.4 porta le chiamate nelle conversazioni crittografate

LibreNostr 0.6.0–0.7.0 instrada i relay attraverso Tor integrato

Newlay 0.3.45 trasmette in streaming le query di grandi dimensioni invece di chiuderle

ngit-grasp 3.0.5 mantiene in movimento i push Git e la sincronizzazione dei relay

Armada 0.63.0 porta gli avvisi push su tutti i tipi di signer

deed 0.3.0–0.3.2 rende più stabile la pubblicazione Nostr in Zig

Cordn 0.5.1 fa proseguire gli altri gruppi quando un coordinatore fallisce

Nymbot 1.0.7 aggiunge la gestione locale dei documenti e la condivisione crittografata delle chat

0xchat 1.5.6 distribuisce le correzioni per firma e autenticazione dei messaggi

Nostr Mail Client 0.17.0 nasconde ai relay le azioni sulla casella di posta

Nostr WoT 0.8.7 lega l’autenticazione alla destinazione

Il runtime condiviso di Iris mantiene coerente la cronologia di relay e peer

Chama propaga l’annullamento degli annunci e gli avvisi in background

Earthly 0.1.12 aggiunge configurazioni di mappa riutilizzabili

Mostro 0.19.0 dismette il trasporto di prima generazione

SCRUTINY Lens porta la ricerca sulla sicurezza su Nostr

Mangatsu e Noteds arrivano su Android

Statim combina i DM Nostr con altre reti

In sviluppo

Amethyst ripara l’interoperabilità dei gruppi crittografati

Divine aggiunge il video crittografato ai messaggi diretti

Buzz estende i controlli su canali e identità del proprio relay

Conduit fa avanzare il checkout dopo l’accettazione da parte di un relay

Elisym costruisce un checkout commerciale su Nostr

nostter migliora i controlli sul signer e il recupero degli event

Pensieve prepara una riconciliazione isolata dell’archivio

ContextVM evita chiamate duplicate tra relay

Cyberspace rivede le regole degli oggetti DECK-0003

Wisp corregge le risposte ai commenti Nostr

Cordn invia le posizioni dei coordinatori a un secondo dispositivo

Nostr Atlas apre una directory di identità verificabili

nostr-java aggiunge strumenti di hosting multimediale e preserva le posizioni dei tag

Zap Cooking cambia il modo in cui si può recuperare la cronologia dell’account

Opal porta la firma remota su Omarchy

WatchTower apre un pannello di controllo per relay NIP-86

Hubstr Blossom apre un’origine multimediale personale

Meshstr sperimenta una mesh di relay senza permessi

Dossier mostra cosa può rivelare una cronologia Nostr pubblica

Marmot MDK estende sondaggi, emoji personalizzate e metadati dell’account

rust-nostr mette in correlazione le risposte di conteggio dei relay

ZapTracker aggiunge metriche sulla rete Nostr e sulle citazioni

LaWallet NWC instrada le ricariche delle carte verso il wallet della carta

Un nuovo relay khatru espone controlli di moderazione per il proprietario

Un costruttore locale di web-of-trust tiene traccia degli unfollow

Moyu apre un client per spazi di lavoro Marmot

Lavori sul protocollo e sulle specifiche

NIP-39 estende le prove di identità a Bluesky e Discord

NIP-86 aggiunge la gestione dei codici di invito per gli amministratori dei relay

NIP-51 sposta i follow set preferiti su un kind di event inutilizzato

NIP-51 propone risposte nascoste per ogni thread

NIP-DB propone nomi di dominio verificati per servizi indirizzati tramite chiave

Una bozza di feed privato esplora gruppi crittografati di destinatari

Una proposta Blossom consente ad altre persone di annunciare i contenuti multimediali replicati

Le segnalazioni di eventi stradali cercano un formato Nostr condiviso

Marmot riconsidera il coordinamento tra più dispositivi

Sei anni di settembre su Nostr