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

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

Storie principali

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

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

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

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

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

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

GitWorkshop coordina i manutentori e mantiene indipendente la sincronizzazione dei repository

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

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

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

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

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

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

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

Rilasci taggati

Kairos 0.1.1 aggiunge promemoria e un’istruzione locale per Astraea

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

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

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

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

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

Shosho 1.0.0 amplia il proprio marketplace per le dirette streaming

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

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

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

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

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

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

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

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

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

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

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

NoorNote 1.3.1

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

algia 0.0.133

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

swift-nostr 0.7.0

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

lawallet-nwc 2.0.0

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

MDK 0.9.10

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

pakstr 0.3.1

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

Ditto 2.34.2

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

Earthly 0.0.9

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

In sviluppo

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

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

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

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

Imwald Android chiarisce lo stato della pubblicazione offline

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

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

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

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

Zap Cooking programma i post e vincola le richieste dello scanner

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

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

Citrine trasforma un dispositivo Android in un relay gestibile

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

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

Wired recupera conversazioni complete nel browser

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

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

Lavoro su protocolli e specifiche

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

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

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

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

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

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

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

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

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

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

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

Marmot: la specifica definisce uno stato terminale del gruppo

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

Gamma Markets: nessuna modifica pubblica alle specifiche è stata integrata

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

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

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

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

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

Sei anni di luglio su Nostr

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

Luglio 2021

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

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

Luglio 2022

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

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

Luglio 2023

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

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

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

Luglio 2024

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

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

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

Luglio 2025

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

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

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

Luglio 2026

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

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

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

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