Nostr Compass #42

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 1.0.7 aggiunge la gestione locale dei documenti e la condivisione crittografata delle chat

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.