Newsletter on Nostr Compass

Nostr Compass #26

Wed, 10 Jun 2026 00:00:00 +0000

L’organizzazione Marmot Protocol apre tre nuovi repo per una bozza di protocollo v2 e una linea di client nativi: un workspace Rust chiamato darkmatter, un’app iOS SwiftUI darkmatter-ios e un’app Android Kotlin/Compose darkmatter-android. L’originale Flutter Whitenoise viene archiviato. Chama comprime diciassette release in una settimana e attraversa la linea di app standalone con v3.0.0 prima di portare un ridisegno completo della UI della trade room e storefront per venditore in v3.1.0, sopra a share Shamir solo per il detentore, sostituzione dell’arbitro, routing di community mondiale e notifiche di trade end-to-end. Coracle lancia un servizio di relay ospitato a pagamento sostenuto dallo stack open-source Caravel e zooid, con integrazione profonda con Flotilla pianificata. Angor passa a mainnet di default in v0.2.30 e porta un test di funding UAT a 3 utenti in v0.2.29. Amethyst porta 41 PR non rilasciate che continuano il lavoro NIP-32 / NIP-F4 / Tor della scorsa settimana. NIP-67 (hint di completezza EOSE) e autocomplete NIP-50 sono mergiati, chiudendo due gap di correttezza di lunga data nel protocollo relay core. NIP-GART propone un wire format a tutela della privacy per gli alert di emergenza, e NIP-46 acquisisce un metodo di logout.

Storie principali

Marmot v2 (Dark Matter): ridisegno del protocollo, client nativi, app Flutter archiviata

Tre nuovi repo sono apparsi sotto l’organizzazione GitHub marmot-protocol questa settimana, che insieme formano la forma dei primi progressi di una bozza di protocollo Marmot v2 e una linea di client nativi che sostituisce la linea di app Flutter. darkmatter (Rust, creato il 13 maggio, trentaquattro commit negli ultimi sette giorni) contiene la bozza del protocollo v2 in spec/, un engine CGKA sostenuto da OpenMLS in crates/cgka-engine, un simulatore di conformità con property test e un modello formale Tamarin per prove di convergenza. darkmatter-ios (Swift, creato il 25 maggio) è un client SwiftUI sostenuto da un xcframework MarmotKit UniFFI vendorizzato generato dal workspace Rust. darkmatter-android (Kotlin/Jetpack Compose, creato il 25 maggio) siede sugli stessi binding Rust. L’originale Flutter Whitenoise è stato contrassegnato come whitenoise-archive (“ARCHIVED: This was the original White Noise Flutter app”); un nuovo repo Dart whitenoise porta la linea Flutter attiva in parallelo.

Leggete questo come progresso iniziale verso un Marmot più affidabile, non come un pivot finito. Il README di darkmatter si etichetta come “Candidate Marmot v2 protocol draft, CGKA engine, and conformance workspace” e dice direttamente: “MDK remains the deployed Rust protocol implementation until this draft and engine are adopted.” All’interno del workspace, il crate cgka-engine è taggato 0.1.0, “single internal consumer, not semver-stable”. Ogni pagina di spec porta “Status: draft for internal review”. Tre stelle sul repo del workspace e zero sulle app iOS e Android confermano che il lavoro è pre-annuncio. Direzione, ambito e disciplina sono il segnale qui; la prontezza per la produzione non è la rivendicazione.

La bozza del protocollo rende concreti i delta da v1 a v2. L’estensione MLS monolitica marmot_group_data di MIP-01, che ha portato nome del gruppo, descrizione, pubkey admin, id di routing del gruppo Nostr, lista relay, dati immagine del gruppo e impostazioni di messaggi a scomparsa sotto un unico ombrello sin dall’inizio di Marmot, viene divisa in componenti applicativi versionati: marmot.group.profile.v1 per nome e descrizione, marmot.group.admin-policy.v1 per pubkey admin, marmot.transport.nostr.routing.v1 per il nostr_group_id casuale e la lista relay canonica, marmot.group.blossom.image.v1 per hash immagine, chiave di cifratura, nonce e chiave di upload, e marmot.group.message-retention.v1 per i secondi dei messaggi a scomparsa. Ciascun componente possiede i propri byte esatti e il proprio percorso di versionamento, così una funzionalità futura può revisionare un componente senza forzare il resto dello stato del gruppo a ripercorrere il consenso sulle estensioni MLS. Le credenziali MIP-00 ottengono anche un nuovo documento fondazionale account-identity-proof-v1.md, indicato come “new in v2 and breaking”. La prova di identità vive ora sulla propria superficie, separata dalla costruzione del KeyPackage.

I delta della libreria supportano il ridisegno della spec. cgka-engine è la nuova macchina a stati locale del gruppo: avvolge OpenMLS, possiede gli stati di epoch Stable, PendingPublish, Merging e Recovering, traduce gli intent in commit MLS, restituisce valori tipizzati IngestOutcome e GroupEvent per ogni inviluppo di trasporto in ingresso e rilascia esplicitamente nessun trasporto e nessuna persistenza. Un trait TransportPeeler separa Nostr dall’engine, e un trait StorageProvider separa SQLite (via storage-sqlite, backed da SQLCipher) dall’engine. L’MDK di oggi impacchetta tutto ciò insieme; dividere i layer consente a un engine di stare sotto un trasporto relay Nostr ora e i trasporti QUIC stream e broker anch’essi rilasciati più tardi, senza riscrivere il modello di convergenza. La convergenza stessa è documentata come distributed-convergence.md e provata in un modello Tamarin che copre selezione deterministica di branch, eleggibilità gated dalla policy, replay di anchor mantenuti, rifiuto di branch obsoleti, riordinamento della consegna, duplicazione, invalidazione dell’output applicativo, handoff welcome/commit, consumo di proposal e gating in uscita durante la sync. I property test Rust controllano poi che l’engine segua le stesse regole con oggetti OpenMLS reali e l’harness del simulatore. Il lavoro di affidabilità con metodi formali di questa portata è assente dallo stack Marmot attuale.

Entrambi i client nativi abbandonano Flutter per toolkit UI nativi della piattaforma. darkmatter-ios è puro SwiftUI con una Notification Service Extension che decifra i push wake MIP-05 sul dispositivo, vendorizza un pacchetto Swift MarmotKit generato dal workspace Rust e si registra sotto il bundle ID e l’app group dev.ipf.darkmatter. darkmatter-android è Kotlin e Jetpack Compose, con una build pilotata da just che produce un APK arm64-v8a firmato e legge endpoint di telemetria da local.properties. Il README Android dichiara direttamente il principio architetturale: “Dark Matter owns protocol data and stores it in SQLite. The Android app should render that data, manage Android platform behavior, and keep UI lifecycle state. The Android app should not become a second database for Dark Matter data.” Questo rispecchia la disciplina di confine che il README di cgka-engine impone nel layer Rust, applicata al layer UI.

I client nativi contano per Marmot perché la debolezza più citata del protocollo è stata l’affidabilità mobile in condizioni di consegna non uniformi: notification wake mancati, race di commit MLS durante fluttuazioni di rete, limiti di background-fetch che bloccano gli avanzamenti di epoch. SwiftUI e Compose danno ai client accesso diretto alle primitive di background-processing della piattaforma che Flutter raggiunge tramite un bridge plugin, e il percorso di binding UniFFI mantiene la logica di protocollo in un unico workspace Rust rilasciato come libreria statica su entrambe le piattaforme. La linea Flutter Whitenoise continua nel repo non archiviato whitenoise, quindi l’annuncio è additivo: una nuova linea di client nativi corre accanto all’app Flutter mentre la spec v2 converge. Il cutover di produzione da MDK o dall’attuale app Whitenoise attende che bozza, engine e client raggiungano release pronte per la produzione.

Chama v2.0.0 fino a v3.1.0: escrow P2P standalone in una settimana

Il client di escrow P2P Nostr-native introdotto nella Newsletter #25 alla v1.3.0 ha rilasciato diciassette release taggate negli ultimi sette giorni, terminando a v3.1.0 il 9 giugno con un ridisegno della UI della trade room e storefront per venditore. La scia di versioni racconta la storia: v2.0.0 è la base BREAKING, poi v2.0.1, v2.0.2 e v2.0.3 chiudono i gap della funding-rail Fedi WebView; v2.1.0, v2.2.0, v2.3.0 e v2.3.1 rafforzano il layer dell’arbitro; v2.4.0, v2.5.0 e v2.6.0 aggiungono superfici di self-custody e routing di community mondiale; v2.7.0, v2.8.0, v2.9.0 e v2.10.0 stratificano copia di chiavi in inglese semplice, applicazioni di gruppo, arbitraggio di deadline di disputa e reputazione. v3.0.0 lega il pacchetto insieme con notifiche di trade end-to-end, e v3.1.0 del 9 giugno ridisegna la schermata di trade attorno a una spina di progresso Reserved → Locked → Settled, card di azione con colori di ruolo e una classe di storefront per venditore (curated swap, loanbook e bill) che rilascia annunci.

Il pivot architetturale vive in v2.0.0. Il formato LOCK dell’escrow è cambiato così ogni share di uno split Shamir 2-di-3 è cifrata solo verso il suo detentore (sharePolicy holder-only-v1). L’ecash bearer della federazione non si ricostruisce più da un singolo partecipante da solo, chiudendo un percorso in cui una parte malevola con sia la propria share sia una share detenuta dalla federazione poteva completare il trade senza consenso. I client pre-2.0 falliscono in modo evidente con “can’t find your share”; il trade non può completarsi su un client obsoleto, e nessun fondo viene perso nel processo. Un lock v2.0 richiede che ogni parte sia su v2.x per essere regolata. v2.0.0 ha aggiunto anche storefront multi-unità e una vista Market solo-sats.

v2.1.0 ha introdotto la sostituzione dell’arbitro: la share dell’arbitro all’indice Shamir 2 è ora cifrata a un ordine di priorità deterministico sopra il pool di arbitri della community, così un arbitro assente può essere sostituito senza bloccare il trade. v2.2.0 ha provato che la sostituzione ha funzionato sul campo su un trade da ₿121 e ha aggiunto backup di healing-substitution. v2.3.0 ha chiuso l’ultimo gap di front-running dell’arbitro controllando l’appartenenza dell’arbitro dell’annuncio alla community al momento del lock, e v2.3.1 ha chiuso la race gemella in cui uno slot di arbitro auto-assegnato era un’anteprima finché il lock non li insediava.

Le superfici di self-custody sono arrivate in v2.4.0 (frase di recupero BIP-39 per il wallet ecash Fedimint, memorizzato cifrato su Nostr) e v2.5.0 (backup master nsec che possiede l’identità Nostr e il seed del wallet). v2.6.0 ha rifatto l’onboarding attorno a un picker di community globale così gli utenti in paesi senza una Chama locale sono instradati alla federazione più vicina; le build precedenti facevano rimbalzare l’utente senza fallback. v2.7.0 ha riscritto la schermata di chiave di recupero in inglese semplice (“the only key to your account and the money in it; Chama never sees it and can’t reset it; if you lose it, no one can get your account back”). v2.8.0 ha aggiunto applicazioni di gruppo, tema chiaro/scuro e due nuovi kind di evento (38120 roster, 38121 application). v2.9.0 ha cambiato la risoluzione di disputa alla deadline: i trade contestati che raggiungono la loro scadenza si risolvono ora per ruling dell’arbitro; il comportamento precedente rimborsava automaticamente. La release è marcata COORDINATED così tutte le parti in una disputa devono aggiornarsi. v2.10.0 ha aggiunto rating per-trade pollice su/pollice giù come nuovo kind di evento 38123.

v3.0.0 è la milestone in cui l’app smette di aver bisogno di una community di coordinamento per operare. Le notifiche di trade end-to-end pingano l’utente solo sulle transizioni di stato attuabili: la controparte ha lockato i sats, payout pronto per essere reclamato, la disputa richiede la decisione dell’utente come arbitro, o trade regolato o scaduto. Un toggle nella schermata Me accende o spegne le notifiche, e il prompt di permesso scatta solo quando il toggle è abilitato. La deduplicazione fire-once impedisce che un ricaricamento di stato inneschi una tempesta di alert. Un bug di guardrail wrong-chama è stato anche chiuso in PR #103, dove le versioni precedenti potevano contrassegnare un annuncio con l’etichetta di una chama ma la federazione di un’altra chama. I bundle desktop Windows e Linux sono rilasciati con la release; il dmg macOS è trattenuto finché la firma e la notarizzazione non arrivano.

Chama si unisce ora a Mostro e Shopstr come marketplace Nostr-native, distinta per architettura serverless, escrow Shamir 2-di-3 supportato da Fedimint, cifratura di share solo per il detentore e l’unica delle tre che rilascia un client desktop e mobile autonomo senza una community di coordinamento.

Coracle Hosting: servizio relay a pagamento più stack Caravel open-source

Il 3 giugno Hodlbod ha annunciato Coracle Hosting a hosting.coracle.social, un servizio di relay di community ospitato che accetta pagamenti lightning ricorrenti su NWC o carta. Il servizio è alimentato da Caravel, il frontend di billing e provisioning di Coracle, e zooid, un runtime di relay che ospita molti relay virtuali su una singola macchina. Entrambi sono open source sul gitea self-hosted di Coracle. Caravel è rilasciato con integrazione opzionale livekit e Blossom che gli operatori possono abilitare per relay. Un tier gratuito con limiti di conteggio membri consente agli operatori di valutare il servizio prima di impegnare dettagli di pagamento.

Hodlbod è schietto sul modello di business: monetizzare l’open source vendendo una versione ospitata di uno stack che chiunque altro può anche far girare. Il fossato competitivo è l’integrazione Flotilla, che è il prossimo passo pianificato. Flotilla possiede la superficie utente, così l’opzione ospitata servita dall’interno di Flotilla diventa il percorso di default per qualunque utente che preferisca infrastruttura gestita. Hodlbod ha offerto di aggiungere altri operatori Caravel al picker di hosting alternativo di Flotilla se si mettono in contatto, tenendo aperta la porta a un mercato di hosting federato.

Caravel si unisce a relay.tools come piattaforma pubblica di provisioning di relay Nostr con tier a pagamento per membro. relay.tools precede Caravel ed è rilasciato come il servizio dominante di creazione di relay oggi, con la propria directory di relay di community e flussi di join per membri o moderatori a pagamento. La caratteristica distintiva di Caravel è lo stack coordinato: il runtime del relay (zooid), il frontend di billing e provisioning (Caravel stesso) e il picker lato client (integrazione con Flotilla, ancora in corso) sono rilasciati come un unico design. L’altra caratteristica distintiva è la densità many-relay-per-process di zooid, in cui i relay dei clienti condividono un singolo processo host così l’operatore ammortizza i costi di hosting su molte piccole community. Questo è lo stesso argomento di densità che ha reso il web hosting condiviso praticabile all’inizio degli anni 2000, applicato al layer relay di Nostr.

Rilasci

Angor v0.2.29 e v0.2.30: default mainnet e test UAT funding a 3 utenti

Angor v0.2.29 del 4 giugno e v0.2.30 dell'8 giugno sono le due release di questa settimana per il protocollo decentralizzato di funding Bitcoin-e-Nostr. La modifica principale di v0.2.30 è PR #893, che porta la rete di default a mainnet. Angor è ancora rilasciato come release alpha unstable, ma lo switch al default mainnet segnala che il protocollo è oltre la fase solo testnet per i client desktop e mobile. v0.2.30 porta anche un flusso mobile di creazione di progetto single-tap con upload immagine e reset dello scroll (PR #889) e risolve una race condition in cui lo spinner di invoice lightning poteva bloccarsi (PR #890).

v0.2.29 ha aggiunto un test UAT end-to-end in PR #881 che copre 3-user send funds su 10 round con spese non confermate, il primo test di flusso di funding multi-utente nella suite di test Angor. La release ha aggiunto anche un piano di implementazione per una CLI Angor e un server MCP (PR #792), con miglioramenti CLI per il workflow di test MCP in PR #880. PR #885 di DavidGershony ha corretto un invoice lightning Boltz che usava la rete sbagliata dopo un cambio di rete a runtime, un bug che sarebbe emerso in produzione dopo il default mainnet di v0.2.30. Le impostazioni offrono ora una purga opzionale del file wallet di recupero durante il data wipe (PR #883).

Sprout v0.3.15: refresh del TTL dei canali effimeri e comandi slash ACP

Sprout v0.3.15, rilasciato il 10 giugno, è l’ottava release in una serie iniziata con v0.3.7 il 2 giugno. La Newsletter #25 ha coperto la serie da v0.3.1 a v0.3.6 con l’integrazione mesh-llm e il lavoro sulle sezioni di canale; da v0.3.7 a v0.3.15 sono a valle di quello, focalizzate su rifiniture e alcune aggiunte rivolte all’utente. La modifica più visibile all’utente è un refresh del TTL per canali effimeri in PR #902: quando un utente disarchivia un canale effimero, Sprout estende il time-to-live del canale così il disarchivio non ri-archivia immediatamente sotto il timer di scadenza originale. Gli emoji custom mobile arrivano in PR #906 insieme a un redesign delle impostazioni, e i conteggi delle reazioni ora animano al cambiamento (PR #904).

PR #905 corregge un gap di lunga data in cui i display name multi-parola si rompevano e l’estrazione di mention NIP-27 nostr:npub cadeva silenziosamente. Una UI di team basata su directory per desktop è rilasciata in PR #912 con comandi install, sync e reveal. I comandi slash ora passano ai connector ACP in PR #919, consentendo a Sprout di inoltrare comandi in stile /help direttamente ai runtime degli agenti mentre la UI di Sprout resta fuori dal percorso.

Wisp v1.1.1: integrazione wallet Spark e guardia contro il paste di nsec

Wisp v1.1.1, rilasciato il 5 giugno, porta una schermata Connect wallet a due livelli con sub-schermata Spark in PR #548 e parità dashboard con la UI wallet iOS in PR #549. La release include una guardia contro il paste di nsec a livello di sistema che rileva un paste con prefisso nsec1 ovunque nell’app e blocca il campo dall’accettarlo, chiudendo uno degli errori più citati nella UX Nostr. Il login QR-scan più una modalità watch-only per npub e nprofile è rilasciato in PR #552, consentendo a un utente di sfogliare un profilo in sola lettura. I messaggi zap ora si rendono come mini-post nel drawer di engagement (PR #559) così le note zap portano il loro testo insieme all’importo in sat. Un filtro web-of-trust sulle risposte al thread arriva in PR #583, consentendo agli utenti di nascondere lo spam di risposte da account fuori dal loro grafo di follow.

Nostria v3.1.46 e nospeak 1.1.3: rifacimento delle notifiche e restart ICE

Nostria v3.1.46 del 7 giugno chiude una serie di tre release che ha rifatto il contatore delle notifiche per contare solo le nuove notifiche dalla vista precedente, eliminando un’inflazione di lunga data in cui caricare notifiche più vecchie scrollando faceva salire il conteggio del badge. Nostria v3.1.45 ha corretto un bug di split-payment che colpiva pagamenti lightning e QR-code e ha abbandonato una UI traslucida precedentemente pianificata come non fattibile sul compositor Android.

nospeak v1.1.3 del 4 giugno aggiunge il restart ICE su stato FAILED per chiamate voce 1-on-1. Il comportamento WebRTC standard scarta una chiamata quando i candidati ICE vanno in timeout senza un percorso alternativo; il percorso di restart ICE rinegozia i candidati così la chiamata recupera da cambi transitori di NAT o rete. Le chiamate Android ora tengono lo schermo acceso durante le videochiamate.

Modifiche non rilasciate

Amethyst: 41 PR che continuano la traccia NIP-32 / NIP-F4 / Tor

Amethyst ha mergiato 41 PR questa settimana senza tagliare una release tag, sopra le 52 PR della scorsa settimana e il lavoro sull’etichettatura hashtag NIP-32 e podcast NIP-F4 trattato nella Newsletter #25. La branch attiva continua ad accumulare funzionalità per la prossima release taggata, stratificando rifiniture sulle aggiunte principali della scorsa settimana: scoperta di labeler hashtag, schermata podcast, tracce musicali e playlist, watchdog di auto-heal Tor, signer effimeri per upload anonimi e zap onchain con filtraggio NIP-05. Il throughput di PR di Amethyst resta il più alto di qualunque client Nostr, e la coda non rilasciata è la roadmap de-facto per ciò che altri client Nostr Android dovranno eguagliare.

Damus: tracciamento dei relay dai messaggi OK e changelog v1.17

Damus PR #3786, mergiata il 3 giugno, aggiunge i messaggi OK riusciti da un relay alla lista dei post-relay. Le build precedenti di Damus popolavano la lista dei relay visti solo quando ricevevano un messaggio generico dal relay, il che significava che un relay che confermava il post ma non consegnava eventi era invisibile all’utente. Il cambiamento conta per gli utenti che vogliono confermare che il loro post sia arrivato sul loro relay outbox preferito. PR #3796 corregge un ciclo AttributeGraph su Profile View, e PR #3725 porta il changelog v1.17 in vista della prossima release taggata.

Shopstr: dual-publishing NIP-34

Il repo shopstr su ngit di Shopstr è stato annunciato su Nostr questa settimana come repo git NIP-34, unendosi ai repo tracciati di ngit. Il repo GitHub del client shop resta la superficie primaria di sviluppo; l’annuncio NIP-34 rende disponibile un percorso parallelo di collaborazione git-over-Nostr. Questo è il secondo grande progetto marketplace Nostr a dual-publish su NIP-34 dopo Mostro, e continua la migrazione graduale dei metadati di progetto sul trasporto git di Nostr.

Hermes-Marmot: gateway di agente AI su MLS

hermes-marmot, un plugin per l’Hermes Agent, connette la superficie di messaggistica di un agente AI ai gruppi Marmot (MLS-over-Nostr) usando mdk-python, i binding Python al Marmot Development Kit Rust. Il plugin consente a un utente di DMare un agente AI da qualunque client Nostr che parla messaggi MLS di kind 445, incluso Whitenoise. I DM in ingresso usano l’unwrapping gift-wrap NIP-59 tramite i binding Python di nostr-sdk, e i welcome in ingresso fluiscono attraverso UnwrappedGift.from_gift_wrap a mdk.process_welcome e mdk.accept_welcome. Il controllo di accesso passa attraverso MARMOT_ALLOWED_USERS (una allowlist di npub separata da virgole) o MARMOT_ALLOW_ALL_USERS=true per accesso di sviluppo aperto.

Il repo è nuovo (ultimo aggiornamento 27 maggio) e piccolo. La sua importanza è architetturale: è il primo ponte pubblico fra un runtime di agente LLM e un canale di messaggistica Nostr cifrato con MLS, e il primo uso in produzione di mdk-python oltre a Whitenoise stesso. Il pattern punta verso comunicazione agente-a-agente in cui entrambi gli endpoint detengono chiavi MLS e il relay vede solo ciphertext.

Aggiornamenti NIP e lavoro di spec di protocollo

NIP-67 hint di completezza EOSE (PR #2317) mergiato

PR #2317 di mattn mergiata il 6 giugno, aggiungendo NIP-67 al protocollo. Il NIP estende il messaggio relay EOSE con un terzo elemento opzionale: ["EOSE", <subscription_id>, "finish"] segnala che ogni evento memorizzato che corrisponde al filtro è stato consegnato, mentre un nudo ["EOSE", <subscription_id>] non porta alcuna dichiarazione di completezza. Un relay che omette l’hint sta dicendo al client che potrebbe esserci di più; un relay che omette la pubblicità NIP-67 in NIP-11 mantiene il comportamento di oggi sotto l’euristica legacy esistente. Il cambiamento è backward compatible in entrambe le direzioni: i client legacy ignorano l’elemento finale dell’array e i relay legacy lo omettono.

La motivazione nella spec mergiata è duplice. Primo, perdita silenziosa di dati: un client chiede le ultime 500 note contro un relay con un cap interno di 300 eventi, il relay restituisce 300 eventi, e il client (usando l’euristica standard received < limit) conclude che il risultato è completo. La 201esima fino alla N-esima nota più vecchia che corrisponde restano sul relay non lette, con il client cieco a quel fatto. Secondo, round-trip sprecati obbligatoriamente: quando un relay cappa le risposte a 300 eventi, qualunque sottoscrizione che esaurisce il cap richiede un secondo REQ con until=<oldest_created_at> puramente per confermare il completamento, anche quando il filtro corrisponde esattamente a 300 eventi. Entrambe le modalità di fallimento sono pagate da ogni client su ogni sottoscrizione che esaurisce il cap. L’hint "finish" è una stringa opzionale su un messaggio esistente ed elimina entrambi i costi.

Estensione autocomplete NIP-50 (PR #2357) mergiata

PR #2357 di Alex Gleason mergiata il 6 giugno, aggiungendo un token autocomplete:true/false alla ricerca NIP-50. L’estensione consente a un client di marcare una query come un lookup typeahead così il relay usa prefix matching, con la full-text search come default per query senza il token. Il relay di Ditto lo implementa per follow pack, lista e qualunque evento con un tag title, restituendo match contro il prefisso del titolo; il percorso di ricerca di default esegue lo scoring full-text. Senza questo token, le UI stile autocomplete non avevano modo di comunicare l’intento di prefix search e i relay dovevano indovinare dalla forma della query. Il token è un hint per-ricerca, non una capability a livello relay, così un relay può implementarlo per una classe di eventi (titoli) senza rivendicare supporto autocomplete generale.

NIP-GART alert di emergenza e broadcast di posizione (PR #2374)

PR #2374 di disinqa, aperta il 9 giugno, definisce un wire format a tutela della privacy su Nostr per alert di emergenza e broadcast di posizione indirizzati a un gruppo di destinatari fidati. L’obiettivo di design dichiarato è nascondere l’identità del mittente, l’appartenenza al gruppo e il payload agli operatori del relay mantenendo gli eventi replay-safe e verificabili tramite firma end-to-end. Il numero NIP è ancora TBD, la proposta è in bozza iniziale. Il caso d’uso è il pattern standard di alert di emergenza: un utente sotto minaccia broadcasta un ping di posizione che solo un gruppo pre-condiviso di contatti fidati può decifrare, con il relay cieco a mittente, set di destinatari e payload. I dettagli del wire format vivono nella PR e probabilmente evolveranno mentre i manutentori revisionano.

Metodo logout NIP-46 (PR #2373)

PR #2373 di hzrd149, aperta l'8 giugno, aggiunge un metodo logout a NIP-46 così un client può dire esplicitamente a un bunker che la sessione è terminata. Finora, l’unico modo per terminare una sessione bunker era aspettare il timeout della sessione o smettere di usare la connessione, entrambi i quali lasciano il bunker a detenere stato di sessione per un client che è scomparso. La proposta è breve (un nuovo metodo) ed è il tipo di modifica di manutenzione che rende le integrazioni bunker a lungo termine più pulite.

Proposta ibrida relay-P2P NIP-95 circolata come long-form

Una specifica NIP-95 long-form è circolata come post kind:30023 dall’npub 91bea5cd9361504c409aaf459516988f68a2fcd482762fd969a7cdc71df4451c il 4 giugno sotto il titolo Protocolo Híbrido Relay-P2P via WebRTC. Il documento in lingua portoghese definisce un protocollo relay ibrido peer-to-peer in cui i client Nostr si connettono l’uno all’altro direttamente via WebRTC per la messaggistica live continuando a usare i relay per il recupero di eventi memorizzati e la consegna offline. L’autore ha esplicitamente inquadrato la spec come “LLM-ready”, fornendo definizioni di messaggi, flussi logici, schemi di dati e regole di stato a un livello di dettaglio che lascia a un modello AI la possibilità di generare codice client o server funzionante. La proposta non è ancora arrivata come PR NIP; la circolazione tramite kind:30023 è il precursore usuale a una pull request formale su nostr-protocol/nips.

NIP-44 v3 prende un secondo signer: Clave porta la spec

Il rollout di NIP-44 v3 di Amber v6.2.0 della scorsa settimana è arrivato prima di qualunque PR NIP mergiata, lasciando v3 come estensione specifica di Amber che altri client dovevano rispecchiare per interoperare. Quell’inquadratura a singola implementazione è cambiata questa settimana. Clave, il remote signer iOS NIP-46 basato su push, ha portato un porting indipendente di NIP-44 v3 il 3 e 4 giugno attraverso otto commit. Le primitive crittografiche sono rilasciate in tre commit: layer di chiavi HKDF + ECDH, l’algoritmo di padding v3 e un’API pubblica di alto livello più Context di cifratura. Sopra questi, la superficie NIP-46 segue in wiring del dispatch RPC dentro LightSigner e uno schema PendingRequest che porta il contesto v3 (kind più scope), così il signer può registrare per quale kind di evento e caso d’uso il payload v3 è stato approvato.

Clave diverge da Amber sulla superficie rivolta all’utente. Uno schema di grant di permesso con tier di sensibilità consente agli utenti di garantire la cifratura v3 per un particolare kind di evento e scope a un livello di sensibilità scelto. Al primo incontro, prompt di approvazione consapevoli del contesto v3 con una card di explainer una-tantum introducono v3 agli utenti. Il lavoro è in main ed è collegato al progetto Xcode ma non è rilasciato; la build taggata più recente è v0.2.0-build79 del 12 maggio.

Due implementazioni indipendenti portano NIP-44 v3 in percorsi di produzione prima che la PR NIPs sia mergiata, il che rafforza il caso per il wire format sottostante che la PR di protocollo formalizzerà. Il testing di interop cross-implementazione diventa ora il percorso alla convergenza della spec, con la superficie di approvazione Android di Amber e il modello di tier di sensibilità iOS di Clave come i due punti di riferimento. Altri remote signer che collegano v3 (il noauth di nsec.app è stato dormiente da maggio 2025, e altri bunker non hanno annunciato lavoro su v3) restringerebbero ulteriormente il consenso.

Attività NIP-34: Iris adotta lo stack con un nuovo trasporto hashtree

Iris ha pubblicato annunci di repo NIP-34 per hashtree l'8 giugno e iris-apps, iris-drive e iris-chat-rs il 9 giugno, pubblicizzando URL di clone sotto un nuovo schema htree:// servito da wss://temp.iris.to. Il trasporto hashtree è un’alternativa content-addressed ai clone instradati via GRASP, e questi quattro annunci sono i suoi primi usi pubblici. I repo portano descrizioni vuote e i dettagli architetturali stanno ancora emergendo, ma la scelta di pubblicare tramite annuncio NIP-34 (sopra un manifest Iris-interno custom) segnala che Iris si sta impegnando allo stack più ampio git-over-Nostr NIP-34.

NIP deep dive: NIP-67 (EOSE Completeness Hint)

NIP-67 chiude uno dei gap di correttezza più antichi di NIP-01. La spec originale definisce EOSE come il confine tra eventi memorizzati e eventi di sottoscrizione live per un REQ, ma non ha mai specificato se il relay avesse finito di consegnare tutti i match memorizzati o si fosse fermato a metà a causa di un cap interno. Ogni relay impone un cap per-sottoscrizione (comunemente da 300 a 1000 eventi) indipendente dal limit del client, e i client non hanno avuto modo di osservare quel cap.

Il workaround standard era confrontare il conteggio ricevuto con il limit richiesto. Se received < limit, trattare il risultato come completo; altrimenti paginare con until=<oldest_created_at>. Entrambi i branch sono rotti. Il branch received < limit tronca silenziosamente: un client che chiede 500 note contro un relay cappato a 300 vede 300 eventi, conclude che il risultato è completo perché 300 < 500, e non recupera mai il resto. Gli eventi trattenuti sul relay non possono segnalare “altro disponibile” attraverso alcun messaggio esistente. La paginazione come secondo branch è sprecona: un filtro che corrisponde esattamente al cap richiede un secondo REQ per confermare la completezza, restituendo zero eventi mentre consuma una scansione di filtro completa sul relay.

Il fix di NIP-67 è una stringa opzionale sul messaggio EOSE:

["EOSE", "<sub_id>", "finish"] // esplicito: tutti gli eventi memorizzati consegnati
["EOSE", "<sub_id>"] // nessuna dichiarazione di completezza

Un relay che pubblicizza NIP-67 nei supported_nips di NIP-11 ed emette un EOSE nudo sta dicendo al client che c’è di più. Un relay che omette la pubblicità mantiene il comportamento di oggi, e il client ricade sull’euristica esistente. I client legacy ignorano l’elemento finale dell’array. La compatibilità all’indietro tiene in entrambe le direzioni, senza nuovi verbi o kind di evento.

Ciò che rende NIP-67 degno di esame è lo scope che deliberatamente restringe. La spec non definisce cursore o token di paginazione, quindi la paginazione basata su until resta il meccanismo. I cap dei relay restano dove sono, e il NIP non richiede alcuna esposizione di essi. NIP-67 preserva il significato di EOSE come confine memorizzato-a-live e aggiunge solo un segnale sì-o-no al confine: “Ho di più per te” contro “questo è tutto”. Questa superficie minima è perché la PR è stata mergiata dopo un periodo di review relativamente breve per un’estensione di NIP-01, e perché mattn nota esplicitamente nella PR che è stata usata la traduzione AI per il testo inglese. Il cambiamento è abbastanza piccolo che l’incertezza della traduzione non conta.

Esempio di scambio consapevole di NIP-67 tra un client e un relay che impone il cap. Pubblicità NIP-11 dal relay:

{
 "id": "a5f87fe2d4c8b9a0e3f1c4d5e6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1781136000,
 "kind": 11,
 "tags": [],
 "content": "{\"supported_nips\":[1,11,50,67]}",
 "sig": "f1e2d3c4b5a6978869504132c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5"
}

Lo scambio a livello di wire che segue:

→ ["REQ", "abc", {"kinds":[1],"limit":500}]
← [...300 EVENT messages...]
← ["EOSE", "abc"] // no "finish": cap raggiunto, altro disponibile
→ ["REQ", "def", {"kinds":[1],"limit":300,"until":1780900000}]
← [...178 EVENT messages...]
← ["EOSE", "def", "finish"] // completo esplicito

La risposta di 178 eventi prima avrebbe innescato una terza REQ per confermare il completamento. Con NIP-67 il client si ferma lì.

NIP-67 è notabile anche come emendamento a NIP-01 che arriva con raro consenso. La maggior parte dei cambiamenti a NIP-01 attrae lunghi thread di dibattito perché la superficie minuscola del protocollo è portante per ogni implementazione. NIP-67 è stato mergiato dopo un periodo di review esteso (all’incirca sette settimane dall’apertura al merge), suggerendo che quando un cambio NIP-01 è abbastanza piccolo e la modalità di fallimento è abbastanza concreta (perdita silenziosa di dati, round trip sprecato obbligatorio), i manutentori del protocollo sono disposti a estendere il vocabolario dei messaggi core.

NIP deep dive: NIP-50 (Ricerca)

NIP-50 definisce il campo di filtro search nei messaggi REQ, consentendo ai client di chiedere a un relay di filtrare eventi tramite match full-text contro una stringa di query. La spec base mergiata è deliberatamente minima: il campo search è una stringa, ciascun relay decide la propria semantica di ricerca (quali campi sono indicizzati, come funziona lo scoring, se si applica lo stemming), e i relay pubblicizzano il supporto NIP-50 nel loro documento NIP-11. I client controllano l’algoritmo di ricerca solo tramite la stringa di query stessa.

Questo minimalismo è sia la forza sia il vincolo di NIP-50. La forza è che qualunque relay può implementare la ricerca a qualunque livello di qualità: una scansione di sottostringa di base soddisfa la spec, e un relay che esegue Elasticsearch o Meilisearch la soddisfa ugualmente. Il vincolo è che i client mancano di un modo per esprimere l’intento di ricerca. Una UI typeahead di mention di profilo vuole prefix matching contro i display name; una ricerca di contenuto full-text vuole scoring full-text tokenizzato attraverso il corpo della nota. Lo stesso campo search porta entrambi, e il relay deve indovinare dalla forma della query.

PR #2357 aggiunge il primo token di estensione NIP-50: autocomplete:true o autocomplete:false incorporato nella query di ricerca segnala quale modalità il client vuole. Il relay di Ditto implementa il token per follow pack, lista e qualunque evento con un tag title, passando al prefix matching quando autocomplete:true è presente. Il token vive inline nella query (i campi di filtro separati restano intoccati), così viaggia con la stringa di ricerca e non richiede alcun bump di wire protocol:

search: "fiat autocomplete:true"

Hint in forma di token come questo sono il modo in cui NIP-50 ha sempre gestito dialetti relay-specifici. I relay supportavano già token come language:en e domain:example.com. Ciascuno resta relay-specifico, con ciascun relay che documenta il proprio dialetto. La PR #2357 di NIP-50 eleva autocomplete da un token relay-privato a uno benedetto dalla spec, aprendo la strada a ricerca typeahead-aware attraverso i relay.

Esempio di REQ NIP-50 con il token autocomplete, mirato a un relay che indicizza i titoli di profilo di kind 0:

{
 "id": "b7c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f7081a2b3c4d5e6f70819a2b3c4d5",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1781136000,
 "kind": 1,
 "tags": [
 ["client", "example-mention-picker"]
 ],
 "content": "Sent search: kinds=[0], search=\"fiat autocomplete:true\", limit=10",
 "sig": "12d3e4f5061728394a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f7081a2b3c4d5e6f70819a2b3c4d5e6f7081a2b3c4d5e6f708192"
}

L’effettivo REQ a livello di wire:

["REQ", "mention-picker", {"kinds":[0],"search":"fiat autocomplete:true","limit":10}]

Un relay che non riconosce il token tratta autocomplete:true come parte della stringa di ricerca letterale e ricade sul matching full-text, restituendo risultati corretti (se classificati diversamente). La degradazione graziosa rende il token sicuro da includere incondizionatamente per client che preferiscono il prefix matching quando disponibile.

La prossima probabile estensione NIP-50 è il controllo di ranking per-kind: un hint che dice “classifica per created_at decrescente” contro il default relevance score. Diversi relay accettano già sort:newest come token relay-privato, e lo stesso percorso di elevazione che ha portato autocomplete nella spec si applica. La ricerca resta una delle poche primitive Nostr dove i relay competono sulla qualità del risultato; l’affidabilità della consegna è la stessa attraverso tutti i relay conformi. Token incrementali consentono ai client di sfruttare quella competizione di qualità senza forzare i relay a rilasciare una nuova spec pesante.

Nostr Compass #25

Wed, 03 Jun 2026 00:00:00 +0000

Amber 6.2.0 rilascia la cifratura NIP-44 v3 prima della spec. Mostro porta le fondamenta per l’escrow regolato con Cashu attraverso otto PR, avvolgendo l’esistente Cashu Development Kit come secondo backend di regolamento accanto a Lightning. NIP-F4 podcast è mergiato dopo 27 mesi di dibattito. fiatjaf apre una proposta contestata di disaccoppiamento delle chiavi NIP-17 che riapre la discussione architetturale bunker-contro-Marmot. Amethyst porta l’etichettatura di hashtag NIP-32, una schermata podcast dedicata e gli zap onchain attraverso 52 PR non rilasciate.

Storie principali

Amber 6.2.0: cifratura NIP-44 v3 rilasciata

Amber v6.2.0, rilasciato il 1° giugno, aggiunge il supporto alla cifratura NIP-44 v3 con una schermata di approvazione dedicata, anteprima dell’intent, anteprima bunker, logging della cronologia e auto-reject per richieste non valide. La release registra anche le autorità ContentProvider NIP-44 v3 così altre app Android possono richiedere la cifratura v3 insieme al percorso v2 esistente. NIP-44 stesso è la spec versionata di payload cifrato usata dai DM privati NIP-17, dal traffico bunker NIP-46 e da altre primitive Nostr; v3 in Amber è opt-in accanto a v2, segnalato da un metodo signer separato così i client lato ricevente possono negoziare l’algoritmo esplicitamente. La corrispondente PR nel repo NIPs deve ancora arrivare, quindi Amber sta rilasciando v3 prima del consensus di protocollo, con il wire format e l’autorità ContentProvider registrati per l’integrazione dei client a valle.

Le sessioni NIP-46 ora auto-accettano le richieste di ping alla connessione, rimuovendo il prompt sul primo round trip dopo il pairing. Il metodo signer sign_message è stato rimosso completamente dopo essere stato deprecato e non utilizzato.

Poiché Amber è il signer Android dominante, ogni client a valle che vuole v3 deve puntare al wire format di Amber finché la PR NIPs non arriva. Ciò dà ad Amber implicitamente voce in capitolo sulla spec finale v3 finché il protocollo non recupera. Il trade è reale: v3 in produzione lascia che Amber raccolga feedback implementativi per l’eventuale NIP, al costo di un punto di riferimento a singola implementazione temporaneo che gli altri client ora devono eguagliare.

Mostro: integrazione dell’escrow Cashu tramite CDK

grunch ha portato otto PR attraverso MostroP2P questa settimana integrando le primitive multisig P2PK esistenti di Cashu (NUT-10 e NUT-11) come secondo backend di regolamento accanto a Lightning sull’exchange Bitcoin P2P coordinato via Nostr. Le primitive crittografiche sono di Cashu; il lavoro è impalcatura di integrazione e un nuovo trait di backend escrow. Mostro core v0.12.0, rilasciato il 30 maggio, aggiunge i tipi di protocollo per l’escrow multisig 2-di-3, firme P_M per-proof e consente eventi escrow attraverso la validazione della risposta. L’architettura è documentata in PR #756 e usa chiavi di trade per-order chiarite in PR #757.

L’implementazione è stata dispiegata attraverso sei PR di follow-up in un solo giorno. F2 (PR #758) ha aggiunto la configurazione, la modalità escrow e il boot condizionale. La fetta successiva, F3 (PR #760), ha definito un trait EscrowBackend con un’implementazione Lightning e uno stub Cashu, consentendo a Mostro di cambiare backend di regolamento senza cambiare la macchina a stati degli ordini. F4 (PR #759) ha wrappato CDK (il Cashu Development Kit) per operazioni di mint e wallet. Il lavoro sul database in F5 (PR #761) ha aggiunto lock escrow compare-and-swap e query active-locked. F6 (PR #762) ha costruito una mint containerizzata in un job CI dedicato per il test end-to-end dell’escrow. Il flusso Mostro usa già DM gift-wrapped NIP-59 per la coordinazione degli ordini sul relay, così l’escrow Cashu si inserisce come una seconda opzione di regolamento accanto a Lightning senza toccare il wire protocol.

Rilasci

ngit v2.5.0: fallback GRASP e fetch git pigri

ngit v2.5.0 cambia il comportamento di default di git push pr/<branch> e ngit send per produrre un PR kind per nuove proposte quando il repository ha almeno un server GRASP registrato. In precedenza questo si attivava solo per commit sovradimensionati oltre i 60 KB o commit contenenti submoduli. Quando un PR non può essere pushato ai server GRASP del repository, ngit ora ricade su routing GRASP-06 attraverso i server dichiarati. Il flag ngit send --git-server o git push -o git-server=<url> consente ai contributor di puntare esplicitamente a un URL git custom o server GRASP.

I republish di ngit init ora preservano i tag sconosciuti dagli annunci esistenti, così i tag aggiunti da una futura versione di ngit o da uno strumento di terze parti sopravvivono al republish. Un warning giallo elenca i tag riportati, e --clean li rimuove su richiesta. ngit pr apply, ngit pr checkout e ngit pr list consultano i server git pigramente e condividono un singolo helper di fetch, così il checkout non fa più fetch incondizionato quando il commit è già locale. ngit pr checkout prova anche URL di clone forniti dal submitter dall’evento PR come fallback quando i server git dichiarati del repo non portano la punta del PR, corrispondendo al comportamento esistente in ngit pr apply. ngit è l’implementazione di riferimento NIP-34 per la collaborazione git su Nostr, e v2.5.0 rende GRASP il percorso di prima classe per i nuovi contributor.

Jumble v26.5.7: rimozione EXIF e conteggi zap validati

Jumble v26.5.7 aggiunge due modifiche che influenzano direttamente la privacy dell’utente e l’integrità dei dati. Gli identificatori di posizione EXIF e della camera sono ora rimossi dagli upload di immagini prima che lascino il client, chiudendo una superficie di lunga data di leak di metadati che ha colpito ogni immagine postata da Jumble. I conteggi degli zap sono ora calcolati solo da ricevute validate crittograficamente, correggendo conteggi gonfiati da eventi zap malformati che avevano lasciato agli attaccanti la possibilità di esagerare i totali degli zap sulle note. La release aggiunge anche la verifica dell’identità del mittente per i DM NIP-17, chiudendo una superficie di spoofing in cui un mittente poteva falsificare il proprio pubkey nel seal.

nostr-calendar v1.6.0: RSVP e gestione dei partecipanti duplicati

nostr-calendar v1.6.0 porta il flusso RSVP di Formstr (PR #169) e impedisce partecipanti duplicati negli inviti a eventi (PR #168). L’opzione waitForAll nella funzione di publish ora ha come default false così la UI non si blocca su relay lenti (PR #170). PR #157 ha rilasciato le due bozze di proposta NIP di Formstr per la programmazione di appuntamenti e prenotazioni.

Sprout 0.3.6: Sprout × mesh-llm e sezioni di canale

Sprout v0.3.6 è la principale di una serie di sei release da v0.3.1 a v0.3.6 questa settimana. L’integrazione in-process Sprout × mesh-llm arriva in PR #798, consentendo a Sprout di servire e consumare nodi mesh-llm tramite ammissione dal relay. Le sezioni di canale definite dall’utente si sincronizzano fra dispositivi via Nostr in PR #792, e le sezioni di canale arrivano su mobile con sync via relay in PR #800. Le notifiche thread-aware con controlli di follow e mute mutabili arrivano in PR #761.

Gli allegati file di tipo arbitrario con card di download sono arrivati in PR #810, espandendo Sprout oltre gli allegati solo immagine. Mobile ha guadagnato una tab feed sociale Pulse (PR #772) e rifiniture Pulse fra feed, compose e superfici di filtro (PR #796).

NostrBotKit v0.5.0: chat di gruppo Marmot in un framework di bot Rust

NostrBotKit v0.5.0, rilasciato il 24 maggio su Codeberg, aggiunge il supporto Marmot (MLS-over-Nostr, NIP-104) al framework di bot Rust self-hosted. Quando marmot: true è impostato, il bot pubblica i suoi key package MLS (kind 443, 30443, 10051), accetta inviti di gruppo automaticamente e ascolta i messaggi nei gruppi a cui è unito. Due nuovi tipi di comando, dm_marmot e dm_marmot_npub, consentono ai bot di inviare messaggi in gruppi Marmot con nome o chat Marmot 1:1 tramite cron job o webhook. Per prevenire loop di feedback con altri bot, i bot NostrBotKit rispondono solo a messaggi esplicitamente indirizzati a loro tramite /command o @botname/command. Gli allegati cifrati che usano MIP-04 sono decifrati automaticamente e ri-caricati via Blossom o NIP-96, e il database di stato MLS è cifrato con una chiave derivata dalla chiave privata del bot. NostrBotKit è il primo framework Rust a rilasciare il supporto ai bot NIP-104, aprendo il deployment di bot cifrati Marmot a un profilo operatore diverso dal percorso TypeScript esistente.

noscrypt v0.1.14: rilascio firmato della libreria di crittografia

noscrypt v0.1.14 è una release di sicurezza della libreria di crittografia C usata da diversi client Nostr per le primitive secp256k1, NIP-04 e NIP-44. La release è distribuita con download PGP-firmati verificabili contro la chiave pubblica del manutentore. I client a valle che integrano noscrypt dovrebbero validare la firma prima di integrarla.

Chama v1.3.0: nuovo escrow P2P Nostr-native con Fedimint

Chama v1.3.0, rilasciato il 1° giugno, è la principale di una serie di quattro release per un nuovo client di escrow P2P Nostr-native che usa ecash Fedimint e secret sharing Shamir 2-di-3 per il regolamento. Il progetto è rilasciato a getchama.app e gira senza server. v1.3.0 introduce “heal that sticks” (re-broadcast riuscito e healing del trade che sopravvive ai riavvii di sessione) e pay-rail matching, dove le Chama US-leaning mostrano prima le rail di pagamento US. Le fondamenta per storefront multi-unità sono arrivate attraverso v1.2.11 (schema multi-unità) e v1.2.12 (accountant per lo stock dello storefront + hardening del recovery del bridge Fedimint nativo). Chama si unisce a Mostro e Shopstr nella categoria marketplace Nostr, distinta per la sua architettura serverless e il regolamento escrow basato su Fedimint.

Modifiche non rilasciate

Amethyst: etichettatura hashtag NIP-32, schermata podcast, tracce musicali

Amethyst ha mergiato 52 PR e 411 commit questa settimana senza tagliare una release tag. La più grande aggiunta funzionale è PR #3111, che implementa l’etichettatura hashtag NIP-32 e un feed hashtag basato su etichette usando eventi di kind 1985 con namespace L e tag di etichetta l. Questo sostituisce il fragile meccanismo di corrispondenza testuale #tag con un modello di scoperta basato su labeler dove gli utenti possono seguire specifici npub labeler nel modo in cui seguono i creator di contenuto. PR #3105 aggiunge una schermata podcast dedicata con lista degli episodi e player inline, arrivando entro pochi giorni dal merge della spec podcast NIP-F4. PR #3071 aggiunge un feed Software Apps con filtraggio per follow list, e PR #3067 aggiunge il supporto a tracce musicali e playlist tramite set NIP-51.

I signer effimeri per upload di post anonimi arrivano in PR #3123, consentendo agli utenti di postare anonimamente senza esporre la propria chiave di identità ai servizi di upload. Un watchdog di auto-healing Tor con test di integrazione contro Arti v2.3.0 arriva in PR #3053, rafforzando il routing Tor di Amethyst durante outage di rete transitori. Gli zap onchain e un filtro NIP-05 per utenti che ritornano da Gemini arrivano in PR #3052, ampliando la superficie di zap oltre Lightning ai pagamenti Bitcoin onchain.

Shopstr: validazione degli URL di anteprima OpenGraph

PR #504 valida gli URL di anteprima OpenGraph prima di renderizzarli negli annunci del marketplace, chiudendo una potenziale superficie XSS in cui venditori malevoli potevano incorporare contenuto scriptato tramite metadati OG appositamente costruiti. Gli shop ospitati su Shopstr mostrano anteprime OG per link esterni, e URL non validati permettevano a un attaccante di iniettare contenuto arbitrario nella UI dello shop.

Aggiornamenti NIP e lavoro di spec di protocollo

NIP-F4 (Podcast) mergiato dopo due anni

PR #1093 è stato mergiato il 28 maggio, due anni e tre mesi dopo che fiatjaf ha aperto la bozza originale. NIP-F4 definisce gli episodi di podcast come eventi di kind 54 con tag imeta per i metadati del file audio (URL, mime type, codice lingua ISO, URL di fallback, flag di servizio NIP-96, bitrate, durata), un tag title, tag opzionali image e description e tag t per etichette di topic. La spec mantiene deliberatamente RSS come fonte di verità: gli episodi possono portare un tag i che fa riferimento al GUID del podcast RSS, consentendo ai client Nostr di collegarsi ai feed di podcast esistenti senza duplicare l’hosting audio. Il lungo dibattito nel thread della PR (con Dave Jones co-autore del podcast-namespace, Alex Gleason e Mike Terenzio) si è concluso su un modello di coesistenza in cui Nostr fornisce il layer sociale sopra RSS mentre RSS mantiene il layer di distribuzione. La PR #3105 schermata podcast di Amethyst arriva entro pochi giorni dal merge della spec, e il lavoro sul picker GIF di Jumble include anche fondamenta iniziali per l’allegato podcast.

Disaccoppiamento delle chiavi NIP-17 (PR #2361)

fiatjaf ha aperto PR #2361 il 1° giugno, proponendo che NIP-17 separi la chiave di identità dalla chiave di cifratura. I destinatari pubblicizzano la loro chiave di cifratura in un nuovo evento di kind 10044, e i mittenti usano quella chiave pubblicizzata (quando presente) per il seal interno del gift-wrap, ricadendo sulla chiave di identità del destinatario solo quando la pubblicità è assente. La PR aggiunge anche un tag n al seal che porta la pubkey di cifratura del mittente, così i destinatari possono derivare la conversation key corretta senza decifratura per tentativi contro ogni chiave ritirata. La motivazione dichiarata è la UX bunker: sotto il design attuale, un utente bunker deve fare round-trip di ogni DM ricevuto attraverso il signer per decifrare, poiché la chiave di cifratura è la chiave di identità detenuta dal signer. Il disaccoppiamento lascia che il client detenga la chiave di cifratura localmente mantenendo la chiave di identità nel bunker per le firme.

La proposta ha attirato la review più contestata della settimana. Cody Tseng (Jumble) la sostiene come il percorso più facile per l’interop DM cross-client. Vitor Pamplona (Amethyst) obietta su due basi: aggiunge un nuovo secret di decifratura a lungo termine fuori dal bunker, e i client che non lo rilasciano falliranno silenziosamente a decifrare i messaggi dai client che lo fanno, senza percorso di degradazione perché la rottura è al layer del seal. Pamplona argomenta che il problema è già risolto correttamente dai key package e dalla rotazione di epoch di Marmot, e che retrofittare la separazione delle chiavi nella spec base NIP-17 crea il tipo di fallimento di interop che Marmot ha impiegato due anni a progettare per aggirare. La controrisposta di fiatjaf ha tre parti: il disaccoppiamento è opzionale per destinatario, il fix dell’n-tag affronta la preoccupazione della decifratura per tentativi, e l’alternativa è mantenere rotta la UX bunker mentre Telegram divora il caso d’uso della messaggistica. Il thread resta aperto senza una decisione di merge ed è la discussione NIP più osservata del trimestre.

NIP-Silent Payments flusso di pagamento (PR #2362)

silentius-satoshi ha aperto la PR #2362 il 1° giugno come compagno della più ampia bozza NIP Nostr Silent Payments (PR #2355). Il NIP del flusso di pagamento definisce il kind 8352 per le notifiche di ricevuta di silent payment (consegnate tramite gift wrap NIP-59 così il link di ricevuta non è pubblicamente osservabile) e il kind 10353 per una cache UTXO cifrata che si sincronizza fra i dispositivi per lo stesso wallet Silent Payments. La coppia insieme consente a un pagatore di segnalare un pagamento a un indirizzo Silent Payments usando primitive Nostr-native senza esporre il link on-chain al layer aperto dei relay.

NIP-PIP Perfect IP Packets (PR #2364)

RandyMcMillan ha aperto la PR #2364 il 1° giugno come bozza. Introduce un trasporto ad albero di pacchetti con tre nuovi kind indirizzabili: 39078 porta il manifest, 39079 porta gli slice individuali, e 39080 porta le richieste di riparazione. La spec definisce un wire format in cui file grandi sono spezzati in slice indirizzabili, con manifest che descrivono l’albero degli slice e richieste di riparazione che consentono ai destinatari di chiedere slice mancanti. Si applica lo status di bozza iniziale, e la proposta non ha ancora attirato la review dei manutentori.

NIP-29 spazi live audio/video (PR #2238)

PR #2238 mergiata il 28 maggio, estendendo i gruppi basati su relay NIP-29 con supporto a spazi live audio e video. I gruppi possono ora fare riferimento a una sessione live-space attiva, consentendo agli eventi live activity in stile NIP-53 di ancorarsi in un contesto di gruppo NIP-29.

NIP-71 video multiple tracce audio (PR #2255)

PR #2255 mergiata il 28 maggio, aggiungendo tag imeta di traccia audio agli eventi video NIP-71. Il nuovo formato porta URL, hash, mime type, tag di lingua (con ISO-639-1 più flag di versione originale), URL di fallback, segnale di servizio NIP-96, bitrate e durata. Questo abilita lo streaming solo audio (video podcast), il cambio di risoluzione con audio stabile, tracce multiple in lingua e ridotto storage quando i server non incorporano l’audio direttamente nei file video. I client dovrebbero controllare la disponibilità di traccia audio prima di assumere un comportamento a traccia singola.

NIP-59 gift wrap effimero (PR #2245)

PR #2245 mergiata il 28 maggio, aggiungendo il kind 21059 come controparte effimera dell’esistente gift wrap di kind 1059. La semantica corrisponde al wrap standard NIP-59 ma segue le regole di eventi effimeri per NIP-01 (i relay li scartano dopo il broadcast e non li persistono). Ciò consente alle app di scegliere la persistenza in base ai requisiti: gli indicatori di digitazione e i ping di presenza beneficiano dell’effimero, mentre la cronologia DM ha bisogno di persistenza.

NIP-78 kind application-specific (PR #2292)

PR #2292 mergiata il 28 maggio, riclassificando i dati application-specific NIP-78 come un normale kind indirizzabile, abbandonando la precedente gamma separata. Questo semplifica la semantica di replaceability e allinea NIP-78 con il modello di eventi indirizzabili usato da altri NIP di stato applicativo.

Chiarimenti NIP-85 (PR #2304)

PR #2304 mergiata il 28 maggio con piccoli miglioramenti al linguaggio attorno a chiavi e relay multipli per service provider nelle Trusted Assertions NIP-85, chiarendo il percorso di rotazione della chiave operatore per i servizi di assertion sui relay.

NIP-01 one-liner sulla gestione della connessione relay (PR #2307)

PR #2307 mergiata il 28 maggio, aggiungendo una singola frase a NIP-01 su come i client dovrebbero gestire i tempi di vita della connessione relay. Il fix affronta un gap di lunga data in cui i client differivano su se tenere le connessioni WebSocket aperte dopo il fetch, portando a perdita silenziosa di messaggi su relay che scartano connessioni idle.

NIP-C7 vincolo di chat kind 9 (PR #2310)

PR #2310 mergiata il 28 maggio, restringendo le viste chat NIP-C7 ai soli messaggi di kind 9. Questo separa la chat effimera dai post di timeline di kind 1 nei client che implementano superfici di chat in stile NIP-C7.

Semplificazione NIP-55 (PR #2363)

PR #2363 di greenart7c3, aperta il 1° giugno, semplifica la spec dell’applicazione signer Android. Vitor Pamplona ha approvato come “Looks good” e fiatjaf ha chiesto se è pronta per il merge. La modifica apre la strada alla registrazione dell’autorità ContentProvider NIP-44 v3 che Amber ha rilasciato questa settimana.

NIP-44 v3 (implementazione Amber prima della spec)

Amber ha rilasciato NIP-44 v3 in v6.2.0 con otto commit che implementano l’upgrade di cifratura e la registrazione dell’autorità ContentProvider, ma la PR della spec nel repo NIPs deve ancora arrivare. NIP-44 stesso definisce un formato di payload cifrato versionato usato dentro eventi firmati; l’esistente v2 (in produzione dal 2024) usa ECDH secp256k1, HKDF, padding, ChaCha20, HMAC-SHA256 e base64. Il wire format v3 aggiunge un nuovo byte di versione (0x03) prima del nonce, consentendo ai client destinatari di negoziare esplicitamente l’algoritmo. L’implementazione di Amber include auto-reject per richieste v3 non valide, una schermata di approvazione dedicata distinta dalle approvazioni v2 e logging del plaintext per direzione per la cronologia. Finché la PR NIPs non è mergiata, v3 rimane un’estensione specifica di Amber. Trattatela come un segnale prospettico, non come una segnalazione stabile a livello di protocollo.

NIP deep dive: NIP-32 (Labeling)

NIP-32 definisce un modo strutturato per qualunque attore Nostr di etichettare eventi, pubkey, relay, URL o topic usando eventi indirizzabili di kind 1985 con un vocabolario di etichette namespaced. La spec introduce due nuovi tag: L denota un namespace di etichetta, e l denota un’etichetta all’interno di quel namespace. I tag di target dell’etichetta (e, p, a, r o t) specificano cosa viene etichettato. Il requisito di namespace impedisce a più sistemi di etichette di collidere: un’etichetta spam in nip28.moderation porta una semantica diversa da un’etichetta spam in relay-report.

La scelta di design che rende NIP-32 utile oltre la moderazione è che le etichette sono asserzioni, non verità a livello di protocollo. Un evento di kind 1985 dice solo che una particolare pubkey ha etichettato un particolare target in un particolare namespace. Il modello di fiducia è delegato al client: ogni client sceglie quali labeler onorare, quali namespace leggere e quale affordance UI dare a ciascuna etichetta. La stessa primitiva porta avvertimenti di contenuto, assegnazione di licenza, tag di lingua ISO-639-1 sulle note di kind 1, tag geografici ISO-3166-2, classificazione di contenuto, suggerimenti di moderazione distribuita e punteggi di reputazione.

La PR #3111 di Amethyst di questa settimana è il più grande deployment finora. Aggiunge l’etichettatura hashtag tramite NIP-32 e un feed hashtag basato su etichette, consentendo agli utenti di sfogliare per etichette assegnate da labeler fidati. Il precedente meccanismo di corrispondenza testuale #tag che originariamente pilotava la scoperta hashtag su Nostr resta come fallback per note non etichettate. Il modello hashtag-come-etichetta significa che la stessa nota può essere scopribile sotto più etichette assegnate da labeler diversi, e gli utenti possono silenziare o promuovere specifici labeler senza influenzare le note sottostanti.

Anche l’auto-etichettatura è supportata. Un autore può attaccare tag L e l direttamente alle proprie note di kind 1 per dichiarare lingua, posizione e topic. Una nota taggata ["L", "ISO-639-1"], ["l", "en", "ISO-639-1"] si auto-identifica come inglese e può essere filtrata da client language-aware senza infrastruttura di etichettatura di terze parti.

Esempio di evento etichetta NIP-32 che tagga una nota di kind 1 come inglese e le assegna un tag di moderazione:

{
 "id": "a5f87fe2d4c8b9a0e3f1c4d5e6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1748908800,
 "kind": 1985,
 "tags": [
 ["L", "ISO-639-1"],
 ["l", "en", "ISO-639-1"],
 ["L", "nip28.moderation"],
 ["l", "approve", "nip28.moderation"],
 ["e", "8b39f4e5d6c7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3", "wss://relay.example.com"]
 ],
 "content": "Labeled as English-language content approved for NIP-28 chat moderation",
 "sig": "f1e2d3c4b5a6978869504132c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5"
}

Il rollout di Amethyst combinato con il recente lavoro sulle Trusted Relay Assertions suggerisce che NIP-32 sta diventando il substrato standard per qualunque pattern di “asserzione guidata dall’utente su un target” su Nostr. Il prossimo test è se i labeler stessi svilupperanno gerarchie di fiducia: se gli utenti seguiranno specifici npub labeler nel modo in cui seguono i creator di contenuto.

NIP deep dive: NIP-F4 (Podcast)

NIP-F4 è stato mergiato questa settimana, due anni e tre mesi dopo che fiatjaf ha aperto la bozza originale (PR #1093). Il prefisso F è semplice numerazione hex: NIP-F0 fino a NIP-FF usano lo stesso spazio hex a 1 byte di NIP-0A fino a NIP-0D, con la gamma hex superiore che serve da overflow ora che la gamma decimale 01–99 si sta riempiendo. NIP-F4 definisce come i podcast pubblicano episodi e metadati come eventi Nostr mantenendo RSS come layer complementare per il file audio stesso.

La scelta architettonica di base è che ogni podcast è la propria keypair Nostr. La spec apre con questo direttamente: “each podcast is its own Nostr keypair”. Ciò consente ai podcast di combinare la loro presenza podcast con una normale presenza di microblogging di kind 0 / kind 1, e consente a un podcast di cambiare proprietà nel tempo tramite handover di chiave o firma condivisa stile MuSig2. Quattro kind di evento portano il layer di pubblicazione:

kind:10154: metadati podcast replaceable. Porta tag title, image, description, tag website opzionali e tag p opzionali che marcano gli autori con un role di host, cohost o editor.
kind:10164: contro-claim dell’autore. L’esempio nella spec usa il kind 10064 (un typo aperto a correzione), ma l’header e il testo circostante lo identificano come kind:10164. Gli utenti elencano le pubkey di podcast di cui sono autori, così i client possono verificare i tag p in kind:10154 contro una claim equivalente dal presunto autore. Senza questo, un podcast potrebbe falsamente taggare chiunque come host.
kind:54: eventi episodio scritti dalla pubkey del podcast direttamente. I tag includono title, image opzionale, description e uno o più tag audio. Ogni tag audio è ["audio", "<audio-url>", "<optional_media_type>"]. La spec nota “other important fields to be specified here later after further discovery”, e la forma mergiata è deliberatamente minima.
kind:10054: una lista di podcast preferiti in stile NIP-51, consentendo agli utenti di marcare quali podcast seguono.

Il dibattito del thread attorno al merge ha coinvolto il co-autore di Podcasting 2.0 Dave Jones, Alex Gleason, Mike Terenzio, Pablo F7z e staab. Jones ha argomentato fortemente contro qualunque tentativo di sostituire RSS: “It’s been tried many times and always fails”, citando JSONfeed, XMPP, AMP, l’API di Twitter e la migrazione fallita di Spotify. Terenzio ha ripresentato la proposta come layer sociale sopra RSS, mantenendo RSS stesso come layer di distribuzione. fiatjaf ha accettato di fare un passo indietro e lasciar maturare la proposta: “I agree with everything you said but I still think we can pull it off, let’s stop here for a while”. Due anni dopo, la spec mergiata atterra più vicina alla coesistenza che alla sostituzione.

Tre domande di design restano esplicite nella spec mergiata:

Il typo del kind:10164 (l’esempio mostra 10064) deve essere riconciliato prima che i client possano interoperare in sicurezza.
La scoperta a livello di episodio senza collegamento GUID RSS è lasciata aperta. La spec mergiata non ha tag i, formato podcast:item:guid o meccanismo di bridging RSS. I client che vogliono fare bridge di un catalogo RSS esistente in eventi di kind 54 devono definire da soli la convenzione di bridge.
Lo stub “other important fields” sulla definizione di kind:54 lascia bitrate, durata, lingua, puntatori a trascrizioni, capitoli e metadati per segmento come territorio aperto per proposte di follow-up.

La PR #3105 di Amethyst porta una schermata podcast dedicata con lista degli episodi e player inline entro pochi giorni dal merge, la prima grande implementazione client. Jumble ha rilasciato le prime fondamenta per l’allegato podcast insieme al suo picker GIF. Wavlake resta la più grande piattaforma podcast Nostr-native e dovrà decidere se allineare i suoi esistenti eventi di traccia musicale di kind 31337 con il modello di episodio di kind 54 di NIP-F4.

Esempio di evento episodio NIP-F4 kind 54, corrispondente al set di tag minimo della spec mergiata:

{
 "id": "55807e7d5cd90d0303d7dce7397f996fdbaed8697903f326c7cf8ad999b9de3d",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1748995200,
 "kind": 54,
 "tags": [
 ["title", "Episode 42: Why RSS Won"],
 ["image", "https://podcast.example.com/ep42-cover.jpg"],
 ["description", "Dave Jones and fiatjaf on protocol coexistence and the social layer."],
 ["audio", "https://podcast.example.com/audio/ep42.mp3", "audio/mpeg"]
 ],
 "content": "In this episode we discuss the two-year journey of NIP-F4 from draft to merge, and why coexistence with RSS turned out to be the right architectural choice.",
 "sig": "abc123def456789012345678901234567890abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef01234567"
}

PR #1093 è stata aperta per 27 mesi, ben oltre la durata mediana di apertura per le PR NIP mergiate. Il prossimo test per NIP-F4 è se il typo del kind 10164 sarà riconciliato, se convenzioni di scoperta di episodi e bridge RSS emergeranno dagli implementatori, e se i principali host podcast pubblicheranno sotto keypair per-podcast come la spec raccomanda.

Nostr Compass #24

Thu, 28 May 2026 00:00:00 +0000

Amethyst v1.11.0 porta un’implementazione completa del calendario NIP-52 con promemoria, split di zap Bitcoin onchain e supporto alle risposte nei gruppi Marmot. White Noise v2026.5.22 rilascia le notifiche push iOS tramite una Notification Service Extension, insieme alla UX di block e a un pulsante per aggiungere membri. Vector v0.4.0 porta un rewrite da zero di vector-core, Tor one-click con bridge, remote signer NIP-46, sincronizzazione MLS di gruppo full-negentropy e un server MCP a 21 tool per agenti AI. Applesauce v6.1.0 introduce liste di lookup relay NIP-51 (kind 10086) e un set completo di factory per git-cast NIP-34. MDK aggiunge i messaggi a scomparsa NIP-40 su iOS e Android tramite una superficie UniFFI unificata, e Mostro v0.17.4 chiude il ciclo del bond anti-abuso con i payout di bond slashati di Fase 3 al vincitore. Notedeck mergia la riconciliazione completa negentropy NIP-77 per giftwrap e backfill dei thread, Cordn appare come messenger MLS mediato da coordinator che scambia una dipendenza di disponibilità a punto singolo per un ordinamento di epoch più stretto e un modello operativo più semplice, un’implementazione di riferimento NIP-B0 chiamata deepmarks rilascia un client di bookmark monetizzato dal curatore, e il team Formstr apre quattro proposte NIP calendario coordinate che coprono l’auto-rimozione dei partecipanti, gli eventi privati, la ricorrenza e la programmazione decentralizzata degli appuntamenti.

Storie principali

Amethyst v1.11.0: calendari, split di zap onchain e risposte Marmot

Amethyst, il client Nostr per Android manutenuto da Vitor Pamplona, ha rilasciato v1.11.0. PR #2994 aggiunge un’implementazione di eventi di calendario NIP-52 con una UI dedicata e un sistema di promemoria, così gli eventi di calendario sono ora resi nella propria categoria di timeline, separata dalla vista generica di kind-30023 long-form. PR #3018 estende gli zap Bitcoin onchain con il supporto agli split, distribuendo una singola transazione Bitcoin fra più destinatari secondo il tag zap-split esistente, così un pagamento onchain si comporta come uno split Lightning. PR #2974 aggiunge una schermata paginata di cronologia delle transazioni onchain che mostra ciascuno zap regolato con lo stato di conferma del blocco.

La messaggistica di gruppo guadagna parità con la chat uno-a-uno: PR #2995 aggiunge il supporto alle risposte per i messaggi di gruppo Marmot/MLS, così i thread all’interno di gruppi cifrati sono ora resi con la stessa UI di riferimento genitore delle note pubbliche. PR #2984 rafforza la validazione delle ricevute zap NIP-57 controllando che il provider LNURL corrisponda al lud16 dichiarato del destinatario, chiudendo una classe di falsificazione in cui un LNURL di terze parti poteva emettere una ricevuta per un pagamento mai avvenuto. PR #2968 accetta dimensioni floating-point nei tag imeta NIP-92, allineando Amethyst con i client che pubblicano valori di densità pixel frazionari da dispositivi come il display Retina dell’iPhone. La release collega anche i Payment Targets, un nuovo tip jar multi-rail su evento replaceable trattato nella sezione protocollo più sotto.

White Noise v2026.5.22: push iOS, UX di block e aggiunta membri

White Noise, il messenger di gruppo protocollo Marmot, ha rilasciato v2026.5.22 con le notifiche push iOS come funzionalità principale. PR #673 implementa una Notification Service Extension (NSE) iOS che decifra i messaggi MLS all’interno del processo dell’extension e li presenta come notifiche di sistema, così gli utenti iPhone non hanno più bisogno che l’app sia in foreground per ricevere messaggi. Il plumbing dei token push Android passa attraverso la stessa pipeline backend, con la NSE per-piattaforma che tiene il ciphertext fuori dal broker.

PR #676 aggiunge una UX completa di block e unblock con flussi di conferma e filtraggio della lista contatti. PR #679 aggiunge il pulsante “Aggiungi membri” richiesto da tempo alla schermata di info del gruppo, chiudendo un gap UX in cui gli admin del gruppo dovevano ricadere sui share link. PR #688 introduce una schermata di impostazioni notifiche iOS dedicata, e PR #687 collega la condivisione tramite long-press per media e messaggi.

MDK aggiunge i messaggi a scomparsa NIP-40 su tutte le piattaforme

Il Marmot Development Kit, il core Rust condiviso usato da White Noise iOS, White Noise Android e qualunque futuro client Marmot, ha mergiato PR #306 per esporre la validazione di messaggi a scomparsa e la gestione della scadenza NIP-40 tramite il bridge UniFFI. La PR è la seconda di una serie in tre parti. iOS e Android ora condividono un’unica implementazione Rust della logica di scadenza; le regole di timing vivono in un singolo percorso di codice auditato consumato da entrambe le piattaforme via UniFFI. PR #307 limita la lunghezza memorizzata delle ragioni di fallimento welcome e le sanifica prima della persistenza, un passaggio di hardening separato che complementa la gestione degli eventi welcome rilasciata la scorsa settimana.

I messaggi a scomparsa in MLS non sono solo una comodità UI. Il tag di scadenza è pubblicato con l’inviluppo del messaggio cifrato, così un destinatario che non apre mai il messaggio ha comunque il ciphertext sottostante che scade a livello relay insieme a qualunque copia in cache nel client ricevente. Con MDK che possiede il percorso di validazione, il comportamento resta consistente fra i client: qualunque implementazione Marmot conforme forza la stessa semantica di scadenza, così un client che rispetta la scadenza mentre un altro fa cache per sempre cessa di essere un rischio di portabilità.

Mostro v0.17.4: la Fase 3 chiude il ciclo del bond slashato

Mostro, il protocollo di exchange Bitcoin peer-to-peer costruito su Nostr, ha rilasciato la Fase 3 del suo rollout di bond anti-abuso in v0.17.4. PR #738 porta il flusso di payout per i bond slashati, prendendo il collaterale confiscato al perdente e distribuendolo al vincitore della disputa. PR #743 aggiunge la Fase 3.5, un messaggio esplicito di conferma di payout al vincitore così che sappia che i sats slashati sono stati regolati, con l’evento di conferma che arriva sulla stessa sessione Nostr della risoluzione della disputa. La Fase 2, trattata la scorsa settimana, ha introdotto lo slashing come azione admin; la Fase 3 è la differenza fra minacciare una penalità e farla rispettare.

PR #746 consente al daemon di finalizzare dispute che non hanno una riga solver, un caso limite che precedentemente bloccava la risoluzione su dispute legacy. PR #748 tollera rate null nella risposta /exrates/BTC di Yadio così un breve outage di Yadio non rompe più il percorso di conversione fiat di Mostro. PR #745 documenta la spec per provider di prezzo multi-sorgente, il fondamento per rimuovere Yadio come single point of failure. Il client mobile Mostro ha collegato il corrispondente percorso di claim di Fase 3 in PR #596.

Applesauce v6.1.0: lookup relay e git cast NIP-34

Applesauce, il toolkit Nostr modulare che alimenta Coracle, noStrudel e lo stack di Pablo F7z, ha rilasciato v6.1.0 attraverso i suoi pacchetti. La release aggiunge il supporto nativo alle liste di lookup relay NIP-51: gli eventi di kind 10086 permettono a un utente di segnalare “chiedi a questi relay se vuoi trovarmi”, accanto alle liste outbox NIP-65 come primitiva di scoperta. Le applicazioni costruite su applesauce-core ottengono un observable reattivo User.lookupRelays$ e un loader corrispondente in applesauce-relay.

Le factory di git-cast NIP-34 arrivano in applesauce-factory, dando a ogni client basato su Applesauce un percorso di una riga per pubblicare annunci di repo (kind 30617), patch (kind 1617) e issue (kind 1621). Le proprietà reattive User.favoriteGitRepos$, User.gitAuthors$ e User.graspServers$ consentono alle applicazioni di elencare repo seguiti da un utente, manutentori di repo e server GRASP configurati direttamente dallo stesso oggetto User. La release corregge anche i metodi manuali del pool che scartavano silenziosamente i relay offline in PR #73.

Notedeck mergia il negentropy NIP-77 per giftwrap e backfill dei thread

Notedeck, il client desktop multi-colonna nativo di Damus, ha mergiato PR #1459 il 25 maggio per collegare la piena riconciliazione negentropy NIP-77 nel percorso outbox condiviso. La PR aggiunge frame client e relay NIP-77, sessioni negentropy locali del relay e un tracker di storia completa outbox che pilota la riconciliazione dei set locali e il fetch di eventi mancanti. I giftwrap di messaggi ottengono la riconciliazione negentropy così gli inviluppi di messaggi privati possono essere recuperati dai relay di lettura dell’account selezionato. Le viste dei thread non sono più limitate dal limite di risposte della sottoscrizione live. Dave PNS sostituisce la sua implementazione negentropy locale a Dave con il percorso outbox condiviso preservando il suo comportamento esistente di storia limitata.

Le sottoscrizioni live e negentropy usano ora filtri separati. Un flusso può mantenere una piccola richiesta live emettendo al contempo un filtro negentropy più ampio per riconciliare ciò che il relay ha già. La PR non abilita intenzionalmente la sync negentropy ampia per home o timeline di profilo, che cambierebbe le caratteristiche di costo a cold-start. La copertura di test è stata aggiunta per riconciliazione, consegna di giftwrap, backfill dei thread, ripristino di Dave PNS, cambio account, retargeting dei relay, retry di fetch e comportamento relay NIP-77.

Vector v0.4.0: rewrite di vector-core, Tor, NIP-46, MLS full-negentropy e una superficie di agente MCP

Vector, il messenger cross-platform focalizzato sulla privacy costruito su DM NIP-17 e gruppi Marmot, ha rilasciato v0.4.0. La novità è un rewrite dell’engine da zero: tutta la logica di Vector vive ora in un singolo crate disaccoppiato, vector-core, condiviso fra desktop, Android e qualunque futuro client, con oltre 440 test nel core stesso e la shell dell’applicazione ridotta di migliaia di righe. Il rewrite è la base per una CLI Vector, bot e SDK che pilotano lo stesso codice di protocollo della GUI.

L’integrazione Tor è rilasciata con routing del traffico one-click e supporto ai bridge per il bypass della censura. Il supporto multi-account arriva con uno switcher in-app. Il login con remote signer arriva tramite NIP-46 con pairing bunker via QR o URI incollato, così gli utenti possono accedere senza mai esporre il proprio nsec. Delete-for-everyone funziona sia nei DM NIP-17 sia nelle chat di gruppo Marmot, con Vector che mantiene la chiave di firma effimera come divergenza dalla spec deliberata che le note di release evidenziano esplicitamente: “una diversione dalle spec tradizionali NIP-17/Marmot per controlli di privacy utente potenziati”. La chiave effimera trattenuta dà ai client Vector una prova locale che un’eliminazione è stata sanzionata dal mittente originale, ma significa anche che qualunque altro client che tocca Vector vede una superficie di verificabilità dell’eliminazione diversa dai client NIP-17/Marmot baseline.

La sincronizzazione dei gruppi MLS è ora completamente riconciliata su negentropy NIP-77, la stessa direzione che Notedeck ha preso per giftwrap e thread questa settimana. L’uploader Blossom fa failover su più server, impara le capability di ciascun server e sincronizza la lista dei server fra i dispositivi. I pacchetti di emoji custom sono creabili dall’utente, condivisibili e cross-compatibili con altri client Nostr. La memoria SQLite è scesa da circa 308MB a 5MB. Il pannello emoji si apre dalla cache su disco e gli shortcode stile Discord (:smile:) più il ranking di frequenza Unicode mostrano il glifo giusto per primo.

L’aggiunta più originale è vector-agent, un server MCP (Model Context Protocol) che espone 21 tool così gli agenti AI possono pilotare Vector: inviare DM, gestire gruppi, caricare file, modificare profili. Questo è il secondo progetto Nostr questa settimana (insieme a Shopstr) a rilasciare una superficie MCP, e la prima applicazione di classe messenger a farlo. Combinato con AgentNoise (trattato la scorsa settimana), il pattern di client Nostr controllati da agenti si muove da esperimenti isolati a una direzione di piattaforma deliberata.

Cordn appare come messenger MLS mediato da coordinator

Cordn (client web a cordn.net, repo a Cordn-msg/cordn e Cordn-msg/cordn-web) è un nuovo messenger MLS che prende una direzione architetturale diversa da Marmot. Dove Marmot è completamente basato su relay senza un coordinator privilegiato (ogni membro del gruppo scrive direttamente ai relay e qualunque relay conforme può trasportare il traffico), Cordn introduce un ruolo di coordinator per-gruppo implementato come un servizio ContextVM. Il coordinator ordina i commit MLS e gestisce la distribuzione dei welcome.

L’argomento di Cordn, dichiarato sulla sua pagina /why, è che MLS come deployato nei messenger di produzione “non è coordination-free” e che “la disseminazione pubblica debolmente ordinata” rende la convergenza dello stato di gruppo “molto più difficile” senza un punto di coordinamento forte. Un design mediato da coordinator fornisce avanzamento predicibile delle epoch e una risoluzione più semplice dei commit concorrenti. I partecipanti si connettono al coordinator usando chiavi effimere, così il coordinator apprende l’ID del gruppo e il timing del traffico di commit ma non quali pubkey a lungo termine sono membri. Qualunque parte che interroghi i relay per un gruppo Marmot può già vedere la stessa superficie: attività del gruppo per ID di gruppo, con il timing inferibile dall’arrivo degli eventi. Cordn riconosce anche che “la fiducia di disponibilità resta” con il self-hosting: un coordinator self-hosted evita la preoccupazione di centralizzazione a livello operatore ma introduce un single point of failure per la vivacità del gruppo. Marmot evita quel single point lasciando l’ordinamento a MLS stesso (le epoch e i messaggi Commit gestiscono l’ordinamento all’interno del protocollo) e distribuendo eventi Welcome via gift wrap NIP-59, al costo della disciplina lato admin: gli admin devono aspettare l’acknowledgement del relay di un Commit prima di inviare il Welcome corrispondente, e i client devono riconciliare commit concorrenti quando la consegna del relay va in gara con una transizione di stato.

Il contrasto merita di essere approfondito da qualunque team che scelga uno stack di messaggistica privata. Marmot scambia una certa complessità implementativa per un deployment agnostico ai relay senza attori privilegiati nel percorso. Cordn scambia una dipendenza di disponibilità a punto singolo per un ordinamento più stretto e un modello operativo più semplice. Entrambi i progetti si basano su MLS e usano Nostr come livello di identità e trasporto. Il disaccordo è su dove viva il costo del coordinamento. I repo cordn-msg mostrano una cadenza di commit stabile con il servizio coordinator implementato su ContextVM e il livello MLS costruito su ts-mls.

deepmarks: bookmark NIP-B0 con pubblicazione monetizzata dai curatori

deepmarks-public è un client di riferimento per la spec di bookmark proposta NIP-B0 (kind 39701), con un’architettura a tre riquadri (curatore, indicizzatore, viewer) e un sistema di tier finanziato da zap NIP-57 diretti al curatore. Il client implementa NIP-B0, NIP-07, NIP-46, NIP-57, NIP-44, NIP-98, NIP-65 e Blossom BUD-01 e BUD-04 per lo storage file. Un tier lifetime da 21.000 sat converte lettori paganti in destinatari ricorrenti di zap per il curatore. Il curatore pubblica gli eventi bookmark, l’indicizzatore li arricchisce con metadati leggibili dalla macchina e il viewer rende il feed; ciascun ruolo è un servizio deployabile separato.

Rilasci

Amber v6.1.0 GA: backup cifrato per-account

Amber è passato da v6.1.0-pre3 alla GA v6.1.0 questa settimana. PR #444 rilascia il backup e ripristino cifrati per il database dei permessi dell’applicazione, e PR #446 divide il backup per account, così gli utenti con più identità Nostr possono fare backup e ripristino di ogni set di grant di app indipendentemente. Il lavoro sulla firma PSBT trattato la scorsa settimana è nel taglio GA.

Citrine: sottoscrizioni per-relay e prevenzione di leak di URL onion

Citrine, il personal relay on-device che viene rilasciato con Amethyst, ha rilasciato due correzioni in questo ciclo. PR #157 passa da una singola sottoscrizione globale a sottoscrizioni per-relay taggate, così due relay sorgente che condividono un filtro kinds: [1] non collidono più sul lato aggregatore. PR #162 filtra gli URL di relay onion quando il proxy Tor in uscita è disabilitato, impedendo che gli indirizzi onion trapelino nel percorso di routing clearnet.

Angor v0.2.27 e v0.2.28: affidabilità dei relay e riconnessione Boltz

Angor ha rilasciato v0.2.27 e v0.2.28. PR #874 corregge un bug di deduplicazione dei relay in cui solo un relay era connesso alla volta, una regressione che degradava silenziosamente l’affidabilità per i progetti con più endpoint relay. PR #876 aggiunge logica di riconnessione WebSocket per il monitoraggio degli swap sottomarini Boltz, così una breve disconnessione non lascia più uno swap in uno stato sconosciuto.

Nostrord v1.1.0: zap NIP-57 e distinzione dei ruoli NIP-29

Nostrord ha rilasciato v1.1.0 con supporto agli zap Lightning NIP-57 per messaggi e profili (PR #98) e una distinzione corretta nel feed di attività fra cambi di ruolo NIP-29 e aggiunte di membri (PR #92), che prima si rendevano in modo identico e oscuravano chi era stato promosso rispetto a chi era stato invitato.

ぬるぬる v1.5.x: keystore MLS SQLCipher e catch-up delle epoch

ぬるぬる (nurunuru, di tami1A84), un client Nostr in lingua giapponese che implementa la messaggistica di gruppo MLS (kind 443) insieme a NIP-44, ricerca avanzata NIP-50, NIP-55 e NIP-70, ha rilasciato cinque release questa settimana. PR #184 introduce la cifratura SQLCipher per il keystore MLS nel layer rust-engine. PR #187 e PR #188 estendono SQLCipher rispettivamente ad Android e iOS, con un passaggio di purga legacy-plaintext e guardie CI. PR #189 e PR #191 aggiungono il catch-up delle epoch peer MLS con una replay cache e un banner di recovery su entrambe le piattaforme, così un client che resta indietro sui commit di gruppo può recuperare senza perdere la conversazione. ぬるぬる è un client Marmot costruito su mdk-core, mdk-sqlite-storage e mdk-storage-traits da marmot-protocol/mdk, così il lavoro su SQLCipher e catch-up delle epoch atterra dentro lo stesso runtime MDK che White Noise usa.

Bitcredit Core v0.5.10: correzione della propagazione di blocchi con radice Nostr

Bitcredit Core ha rilasciato v0.5.10 con una correzione per un campo Nostr-node-id mancante durante la propagazione dei blocchi, che rompeva i flussi di creazione azienda che includevano l’upload dell’identità. Bitcredit è un protocollo di e-bill che usa identità Nostr come radice di fiducia per gli eventi di propagazione di aziende e bill.

Modifiche non rilasciate

Jumble ha aperto PR #797 per il login Google tramite il threshold signer Pomegranate, consentendo a un utente di dividere la propria chiave Nostr fra più parti così nessun singolo signer detiene l’intero segreto. Questo è un passo significativo oltre i flussi bunker o import di nsec: un utente può recuperare il proprio account anche se una parte signer è compromessa, senza che quella parte detenga mai la chiave privata completa.

Shopstr ha aperto PR #492 inizializzando un server MCP (Model Context Protocol), con PR #494 che costruisce l’infrastruttura di supporto (fetch dei relay, parser, validazione, errori, deduplicazione, audit logging) e PR #472 che aggiunge una allowlist di relay per il gestore di relay MCP. Ciò rende Shopstr il primo marketplace Nostr a esporre se stesso come server MCP, così gli agenti AI possono navigare e agire su annunci NIP-99 come uno strumento strutturato.

Keydex, il vault di secret-sharing Shamir, ha aperto una migrazione sostanziale in PR #226 spostando i kind custom 1337-1345 nella gamma 713-721, insieme a PR #239 che aggiunge AEAD sopra le share Shamir e PR #234 che migra all’aritmetica GF256. La migrazione della gamma di kind allinea Keydex con il modo in cui il repo NIPs alloca i kind custom, allontanandosi da una gamma auto-reclamata.

Mill (nostr-mill) è una nuova UI di signer Nostr drop-in di OceanSlim (manutentore del relay Go grain), rilasciata come Web Component a singolo script-tag su npm e jsDelivr. Un tag <script> dà a un’app web tutti e sei i punti di ingresso comuni del signer dietro una UI unificata: estensione browser NIP-07, bunker NIP-46 (URL incollato o pairing QR con relay specificabili dall’utente, insolito fra le integrazioni bunker in-pagina), Amber NIP-55 via Android intent, nsec cifrato memorizzato in sessionStorage via AES-256-GCM con PBKDF2, npub read-only e generazione di keypair nel browser. Il componente è personalizzabile tramite 29 proprietà CSS custom collegate allo Shadow DOM ed espone una piccola API tracciata SemVer (MILL.open, eventi mill:connected / mill:disconnected, esportazioni di tema con nome). La motivazione del manutentore è che i flussi di login bunker sono stati re-implementati un’app web alla volta attraverso Nostr. Consolidare su un componente condiviso consente ai client di convergere su come la UX del signer dovrebbe comportarsi, e trasforma flussi opzionali (come il login con chiave delegata tramite threshold signer, che rispecchia il login Google basato su Pomegranate di Wisp trattato sopra) in una superficie riutilizzabile che qualunque app può inserire. Mill è a npm v1.5.0, single-maintainer, stadio alpha, con grain come primo integratore pianificato.

moStard, un fork Monero-first di noStrudel di roguehashrate, ha raggiunto v1.0.1 questa settimana con un set di funzionalità ridotto e un’identità a tema Monero stratificata sullo stesso stack Applesauce + worker-relay. Il lavoro di questa settimana ha portato il rendering per gli eventi software-application di kind 32267 di Zapstore (embed card nella timeline che mostrano nome dell’app, icona, screenshot, piattaforma, licenza e un link di lancio a zapstore.dev/apps/<d-tag>), sondaggi via kind 20 e kind 21, tipping basato su NIP-A3 Payment Targets con QR code per metodo, rendering markdown nelle note, supporto del picker GIF per tastiere GIF esterne e correzioni al pairing del signer Amber. L’inquadratura Monero si estende al flusso di tip: le voci payto NIP-A3 per indirizzi monero ottengono pulsanti di prima classe nella stessa UI insieme a lightning e bitcoin. Il client è single-maintainer e in fase alpha, ma il lavoro del 27 maggio mostra un builder che tira NIP-A3 dagli annunci di spec di protocollo di questa settimana direttamente in un fork rilasciato entro pochi giorni.

Aggiornamenti NIP e lavoro di spec di protocollo

Stack NIP calendario: quattro proposte dal team Formstr

Ix2 (@geralt-debugs) ha aperto quattro PR NIP coordinate il 17 maggio, tutte riferendosi all’implementazione calendar.formstr.app già rilasciata sotto lo stesso autore. PR #2350 propone il kind 84 come un evento generalizzato di “auto-rimozione partecipante”: un partecipante taggato su qualunque evento può pubblicare un kind 84 che fa riferimento all’originale via tag e, a e k per segnalare opt-out. I relay devono validare che il firmatario del kind 84 appaia in un tag p dell’evento di riferimento prima di onorare la rimozione, e un’eliminazione di kind 5 ha sempre precedenza. La PR generalizza un pattern che era precedentemente descritto solo dentro il contesto calendario NIP-52, così il kind 84 diventa il modo standard per i non-autori di ritirarsi da qualunque evento partecipante.

PR #2351 è il fondamento dello stack calendario: NIP-52E per eventi di calendario privati (kind 32678 basato sul tempo, 32681 evento giornaliero, 32123 lista calendario privata, 31926 lista busy, 1052 gift wrap, 52 rumor) e NIP-52R per eventi ricorrenti. Al centro architetturale c’è il pattern view-key: una keypair generata casualmente cifra il contenuto dell’evento con NIP-44, e la metà segreta (codificata bech32 come nsec) è gift-wrapped a ciascun partecipante. Il firmatario detiene solo il tag d pubblico; tutto il resto vive nel content cifrato. Disaccoppiare la cifratura del contenuto dall’identità in questo modo significa che modificare un evento non richiede di re-chiavare i destinatari. NIP-52R definisce due tag opzionali sui kind esistenti 31923 e 31922 per dichiarare la ricorrenza usando valori RFC 5545 RRULE nudi, con l’indice di giorno D che diventa opzionale quando RRULE è presente. La forward secrecy è esplicitamente assente: una view key trapelata rivela tutte le versioni passate e future dell’evento sotto lo stesso tag d.

PR #2352 costruisce su NIP-52E con una spec di programmazione appuntamenti decentralizzata che la descrizione della PR chiama “un’alternativa drop-in a Calendly/Cal.com senza intermediario centrale”. Il kind 31927 pubblicizza una pagina di scheduling con finestre di disponibilità cifrate; il kind 32680 è un record di recovery self-encrypted lato host per la view key; i kind 1057 e 1058 sono la richiesta e la risposta di booking gift-wrapped. Il meccanismo intelligente: il booker genera sia il tag d sia la view key per il futuro evento privato prima di inviare la richiesta, così il booker può aggiungere l’appuntamento al proprio calendario immediatamente con la chiave corretta, e l’host non deve mai fare round-trip di una chiave. Le risposte di booking portano un tag status non cifrato sul wrap esterno così i relay possono filtrare senza decifrare.

Un’implementazione di riferimento è già live a calendar.formstr.app e come app Calendar Android su Zapstore. PR #2351 chiude PR #2027 a suo favore, consolidando una proposta precedente di calendario privato che era aperta dall’inizio dell’anno.

Payment Targets e Silent Payments

Due proposte NIP in più hanno circolato questa settimana in documenti kind:30023 long-form.

Una proposta Payment Targets (NIP-A3 / payto) definisce un evento replaceable di kind 10133 che porta uno o più tag ["payto", "<type>", "<authority>"] che mappano a URI payto: RFC 8905. I tipi supportati includono bitcoin, lightning, ethereum, monero, nano, cashme, revolut e venmo. L’intento è standardizzare un tip jar multi-rail che complementi (non sostituisca) gli zap NIP-57 basati su lud16. Amethyst v1.11.0 è il primo implementatore; le PR mergiate #2953 e #3009 rilasciano la superficie di sottoscrizione e osservazione, e PR #3011 collega la UI per PaymentTargetsEvent.

Due proposte Silent Payments concorrenti sono arrivate da autori diversi. La prima variante deriva le chiavi scan e spend di silent-payment BIP-352 da nsec tramite tweak additivi pubblici, così qualunque mittente può costruire un indirizzo sp1q... da un npub senza setup. L’avvertimento dell’autore è esplicito nella spec: “bscan e bspend DEVONO essere trattate esattamente con la stessa cura di nsec”, perché la chiave di scan rivela l’nsec. Una seconda variante prende l’approccio inverso, aggiungendo un campo sp_address ai metadati profilo di kind 0 contenente un indirizzo silent-payment BIP-352 standard le cui chiavi sono tenute indipendenti dall’identità Nostr. La variante due è strutturalmente più sicura. Entrambe le proposte hanno attratto un thread di review ponderato; erskingardner (lead di Marmot) ha postato un commento dettagliato sul gist trbouma che traccia la proposta. La sua preoccupazione centrale è che la variante 1 deriva la chiave privata di scan da nsec più un tweak calcolabile pubblicamente, il che significa che chiunque detenga la chiave scan (incluso un servizio di scansione di terze parti a cui l’utente deve delegare in pratica) può recuperare il nsec completo sottraendo quel tweak. La stessa chiave che consente a un servizio remoto di scansionare i pagamenti in arrivo per te consente anche a quel servizio di rubare la tua identità e qualunque fondo derivato da essa.

Sul lato NIP-34 git-over-Nostr, hzrd149 ha pubblicato 2 patch a schemata. gitworkshop.dev stesso ha attirato due segnalazioni di issue: una che segnala che le sessioni di login vengono perse al refresh della pagina quando si usa un remote signer NIP-46, l’altra che chiede uno styling di link distinto nelle anteprime README.

Sei anni di May di Nostr

L’ultima newsletter di maggio 2026 fa un passo indietro dai rilasci della settimana per attraversare il mese di maggio nella storia di Nostr. Ogni anno ha avuto un baricentro diverso: il 2021 è stato un singolo commit, il 2022 la formazione del repo NIPs stesso, il 2023 l’esplosione delle spec di protocollo, il 2024 il ciclo di consolidamento, il 2025 quando il negentropy è stato mergiato e Notedeck di Damus è passato a Beta, e il 2026 è il mese trattato in questo e nei tre numeri precedenti.

Maggio 2021

Nostr aveva sei mesi. L’unico codice Nostr viveva in fiatjaf/nostr e l’intero mese ha prodotto esattamente un commit, ma quel commit è diventato una delle parti più usate del protocollo. Il 22 maggio, fiatjaf ha ridefinito NIP-02 come il NIP della lista contatti. Il messaggio di commit recita: “repurpose NIP-02 and add NIP authorship”, e il credito esplicito va alla PR #16 di arcbtc (Ben Arc di LNbits), aperta il 9 febbraio e chiusa il giorno prima che fiatjaf incorporasse l’idea in NIP-02. Il pitch di arcbtc era piccolo: un kind per “inviare la lista dei follower ai relay” che sarebbe stato “utile per ripristinare account e raccomandare chiavi pubbliche da seguire”. fiatjaf lo ha generalizzato in un singolo evento kind:3 i cui tag servono tre scopi contemporaneamente. Sono una lista di follow (il grafo sociale), uno store di petname (nickname locali per gli amici) e una sorgente di raccomandazione di relay (quali relay usa un follow). Lo stesso evento, replaceable per autore, è diventato la risposta canonica a “chi segue questa persona”, “come li chiama” e “dove legge”. Ogni client costruito nei successivi cinque anni legge kind:3. La convenzione aggiunta nello stesso commit, che ogni NIP nomini il proprio autore, è la ragione per cui ogni spec ha ora una firma.

Maggio 2022

Il mese in cui il repo NIPs è diventato un progetto di comunità. Il 1° maggio, fiatjaf ha migrato le spec da fiatjaf/nostr in un repo dedicato nostr-protocol/nips e il 2 maggio ha aggiunto i criteri formali di accettazione. Due giorni dopo, Robert C. Martin (Uncle Bob) ha aperto la PR #1, la prima pull request esterna, proponendo convenzioni di threading per i tag e e p. La PR era originariamente numerata NIP-13, poi rinominata NIP-10 per fare spazio a proof-of-work. Tre dei primi sei NIP sono di Uncle Bob: NIP-10 (threading marker), NIP-14 (il tag Subject) e il commit del 21 maggio che ha fissato kind:1 come il kind canonico di short text-note. Il 5 maggio, William Casarin ha fatto i suoi primi commit NIP: NIP-13 Proof of Work e l’evento kind:2 recommend-relay. Il giorno dopo, fiatjaf ha pubblicato NIP-07 window.nostr, venti righe di markdown che hanno definito l’interfaccia signer browser-extension ancora usata oggi. L’avvertimento CORS di NIP-05 di David A. Harding e il filter.limit di NIP-01 sono arrivati la stessa settimana. nostr-tools ha rilasciato la sua prima build ESM importabile in browser l'8 maggio. Semisol ha redatto NIP-15 (End Of Stored Events) e NIP-16 (event kind ranges) a fine mese, i documenti che ancora governano la semantica di sync dei relay e la classificazione regular-vs-replaceable-vs-ephemeral.

Maggio 2023

L’esplosione di spec di protocollo. Sessantaquattro PR NIP sono state aperte quel mese, con diverse delle proposte che hanno definito la superficie di Nostr per i due anni successivi che sono tutte arrivate in 31 giorni, e il più grande annuncio di finanziamento che Nostr avesse mai ricevuto è arrivato il 4 maggio con il grant OpenSats da 10 milioni di dollari da parte di #startsmall di Jack Dorsey, il denaro che ha finanziato ogni ondata di grant Nostr da allora. NIP-47 (Nostr Wallet Connect) è stato mergiato il 2 maggio, portando la spec di wallet-connect di Alby nel protocollo principale. Due giorni dopo Vitor Pamplona ha proposto NIP-53 Live Activities con room di kind:30311 e messaggi di chat di kind:1311, il fondamento di ogni superficie di livestream Nostr seguita. Pablo Fernandez ha aperto NIP-84 Highlights il 5 maggio e NIP-89 Recommended Application Handlers il 14 maggio. v0l (Kieran Babich, autore di Snort) ha proposto NIP-98 HTTP Auth l'8 maggio, la primitiva di autenticazione da cui NIP-96 e Blossom hanno entrambi in seguito dipeso. Jonathan Staab ha proposto NIP-32 Labels il 15 maggio, e NIP-30 Custom Emoji è stato mergiato lo stesso giorno. Arthur Franca ha proposto NIP-96 HTTP File Storage Integration il 21 maggio. Due giorni dopo, Vitor ha aggiunto gli zap split a NIP-57 e verbiricha ha aggiunto le bozze long-form kind:30024 a NIP-23, la spec che è diventata il fondamento dei moderni workflow di scrittura long-form Nostr in Habla, YakiHonne e Highlighter. fiatjaf ha proposto NIP-29 Simple Groups il 28 maggio, la prima spec di gruppo gestita dal relay che copre gli eventi di moderazione da kind:9000 a kind:9020. Il mese si è chiuso con Paul Miller che apriva la conversazione NIP-44 il 31 maggio, un design di DM cifrato basato su XChaCha20 destinato a sostituire NIP-04. Il lato client si è mosso altrettanto rapidamente: Damus ha rilasciato NWC, zap pool e Pending Zap fra il 10 e il 15 maggio; Snort ha lanciato zap pool e media a paywall L402; Amethyst ha rilasciato circa trenta release versionate nel corso del mese, da v0.40.1 il 1° maggio fino alla gamma v0.55.x a fine mese, con zap split in v0.45.0 ed etichette NIP-32 in v0.46.0; il repo Primal Android è stato creato il 16 maggio; rust-nostr v0.22.0 ha aggiunto NIP-47 e NIP-58. Il 1° maggio, strfry ha rilasciato la sua integrazione negentropy, la prima implementazione relay del protocollo di riconciliazione dei set di Doug Hoyte che sarebbe più tardi diventato NIP-77. Il mese si è chiuso con Forbes che pubblicava un profilo long-form di fiatjaf il 30 maggio, uno dei primi approfondimenti della stampa mainstream sul fondatore anonimo di Nostr.

Maggio 2024

Il ciclo di consolidamento. Meno proposte appariscenti, più cose in rilascio. NIP-54 Decentralized Wikis è stato mergiato il 2 maggio con articoli kind:30818 e tag d normalizzati per case. Tre giorni dopo, NIP-56 è stato esteso così le abuse report potessero segnalare minacce digitali (malware, phishing) accanto alle categorie solo contenuto. Il 6 maggio, le reazioni NIP-25 sono state semplificate per smettere di includere l’intero thread di risposta come tag e. Arthur Franca ha proposto NIP-22 Comment il 12 maggio, introducendo kind:1111 così le risposte a eventi non-kind:1 (articoli, file, prodotti) ottenessero un modo strutturato per fare thread. Il 19 maggio, fiatjaf ha ristrutturato NIP-46 per abbandonare completamente NIP-04 e passare tutto il traffico bunker alla cifratura NIP-44, la mossa di deprecazione che ha plasmato ogni implementazione bunker da allora. Il 20 maggio, NIP-71 Video Events è stato mergiato con kind:21 e kind:22, e NIP-10 ha aggiunto l’argomento pubkey opzionale sui tag e così i client possono risolvere gli autori dei thread senza prima recuperare l’evento di riferimento. NIP-35 Torrents di Kieran Walsh è stato mergiato il 22 maggio, e il 24 maggio il README dei NIP ha per la prima volta fatto riferimento a CIP-01 come una proposta fuori-repo, segnalando l’inizio del pattern “NIP come uno di diversi luoghi di proposta”. Il 25 maggio, una PR di pulizia ha rimosso il tag aes-256-gcm da NIP-71 prima che le implementazioni a valle lo congelassero. NIP-96 ha aggiunto list files e ha eliminato il requisito di transform il 27 maggio. Il 28 maggio, Jonathan Staab ha proposto di alzare l’asticella di accettazione dei NIP per richiedere almeno due implementazioni interoperanti prima che una bozza possa laurearsi. Lato client: Damus ha taggato v1.7.2 e v1.8 più una v1.9 con piena gestione dei marker NIP-10 il 9-10 maggio, ha portato l’autenticazione NIP-98 sulle notifiche push e ha rilasciato il pieno supporto ai marker NIP-10. Amethyst ha reso NIP-17 la modalità DM di default il 14 maggio, ha costruito la gestione dei relay outbox-model NIP-65, ha aggiunto la selezione dei server NIP-96 e ha rilasciato la derivazione di chiavi BIP-32/BIP-39 NIP-06. Primal Android 0.99.2 il 10 maggio ha aggiunto tagging utenti e NWC per wallet esterni, seguita da 0.99.4. Pablo Fernandez ha portato un cluster di optimistic-update NDK dal 24 al 31 maggio. Snort ha aggiunto la selezione dei server NIP-96, e cashu-ts ha separato le sue primitive crypto in @cashu/crypto.

Maggio 2025

Il mese in cui NIP-77 (Negentropy Syncing) è stato mergiato il 27 maggio, la spec di fiatjaf e Doug Hoyte per il wire protocol che sostituisce i filtri REQ brute-force con un calcolo di differenza a costo logaritmico. Questo era lo stesso negentropy che strfry aveva rilasciato due anni prima come funzionalità lato relay, ora formalizzato come protocollo client-relay, e la voce del README è arrivata lo stesso giorno. La settimana prima, NIP-23 long-form ha definito come i documenti HTML si associano a entità Nostr tramite un tag <link> il 24 maggio, la primitiva canonical-web-copy. NIP-25 ha aggiunto gli hint di relay per il target della reazione il 22 maggio e ha abbandonato la raccomandazione emoji-to-like/dislike, trattando le emoji come unità semantiche distinte. NIP-52 è stato semplificato il 14 maggio per focalizzarsi sui kind che i client stavano rilasciando in produzione, la sfoltita che ha reso le estensioni calendario di Formstr di un anno dopo più pulite da innestare. Il 9 maggio, Follow Pack (liste di follow curate di kind 39089) e Favorite Relay (una nuova lista replaceable sotto NIP-51) sono entrati nel README lo stesso giorno. L’arco del Protocollo Marmot non era ancora cominciato: esisteva solo il repo whitenoise-rs (primo commit 9 settembre 2024), e maggio 2025 era la sua fase di prototipo Svelte+Tauri, con il commit del 14 maggio che rimuoveva codice specifico di Tauri mentre il progetto pivotava alla sua architettura attuale. Il core Rust dedicato MDK (12 settembre 2025), il repo spec di Marmot (19 settembre 2025) e la UI Flutter (2 dicembre 2025) sono tutti arrivati dopo nell’anno. Sul lato client, Notedeck v0.4.0 di Damus è stato rilasciato il 5 maggio come prima Beta, laureandosi da Alpha con full-text search, l’assistente AI Dave, zap su NWC, GIF, tagging utenti e mute list. Due giorni dopo, Flotilla 1.0.0 di hodlbod ha attraversato il confine del lancio pubblico come client di group-chat basato su NIP-29, insieme a Coracle 0.6.12, la prima di sei release Coracle che si sono estese fino a 0.6.17 il 14 maggio. Amber v3.4.0 il 12 maggio si è spostato dalle API Autofill e ClipboardManager Android deprecate ed è migrato dalle encrypted shared preferences a DataStore. Primal Android 2.2.20 il 20 maggio ha aggiunto il flusso Redeem Code per Primal Premium e una galleria immagini ridisegnata. nak v0.14.0 il 21 maggio ha tagliato una minor della CLI canonica nella stessa settimana delle release di Coracle, Flotilla e Notedeck. OpenSats ha ricevuto la sua più grande donazione non-Bitcoin-treasury a oggi quando la Reynolds Foundation ha dato 2 milioni di dollari il 22 maggio.

Maggio 2026

Il mese trattato in Newsletter #21, #22, #23 e in questo numero. Il filo definitorio è MLS-on-Nostr che raggiunge produzione multi-client: MDK 0.8.0 ha rilasciato le primitive di leaf-index MIP-05 e i key package indirizzabili, seguito da PR #306 che aggiunge la validazione di messaggi a scomparsa NIP-40 su iOS e Android tramite una superficie UniFFI condivisa. White Noise v2026.5.22+25 ha rilasciato la push iOS tramite una Notification Service Extension che decifra il ciphertext MLS dentro il processo dell’extension così il broker non vede mai plaintext, e sono apparsi due nuovi client Marmot: Scramble (un client desktop e Android .NET/Avalonia con slot KeyPackage multi-dispositivo) e Cordn (un’architettura MLS alternativa che usa un coordinator per-gruppo su ContextVM). Angor ha migrato la sua messaggistica cifrata da NIP-04 a NIP-44 in PR #860, chiudendo l’arco di deprecazione aperto con la proposta NIP-44 di Paul Miller nel maggio 2023. Il team Formstr ha aperto la più grande submission NIP coordinata a memoria recente il 17 maggio, con PR #2350 per l’auto-rimozione dei partecipanti, PR #2351 per eventi di calendario privati e ricorrenza (NIP-52E e NIP-52R) e PR #2352 per la programmazione decentralizzata di appuntamenti, tutti con calendar.formstr.app che già rilascia l’implementazione di riferimento. Amethyst v1.11.0 ha reso i calendari NIP-52 come una categoria di timeline nativa e ha esteso gli zap Bitcoin onchain a distribuzioni split. Un anno dopo che NIP-77 è stato mergiato nel maggio 2025, tre implementazioni indipendenti hanno rilasciato l’adozione negentropy nella stessa finestra: Notedeck PR #1459 l’ha collegata al client desktop di Damus per giftwrap e backfill dei thread, Vector v0.4.0 ha usato la sync MLS full-negentropy come parte del suo rewrite da zero di vector-core insieme al Tor one-click e a una superficie di agente MCP a 21 tool, e Citrine v3.0.0-pre1 l’ha aggiunta al relay Android-nativo insieme a Tor integrato e aggregazione multi-relay. Mostro v0.17.4 ha chiuso il ciclo del bond anti-abuso con i payout di bond slashati di Fase 3 in PR #738, facendo rispettare ciò che il protocollo prima solo minacciava. Tre anni da “sostituiamo NIP-04” a “sostituiamo NIP-44 con lo stato di gruppo MLS completo”.

Se vuoi discutere, mandaci un DM su Nostr.

Nostr Compass #23

Thu, 21 May 2026 00:00:00 +0000

Primal 3.5 rilascia una shell Android ricostruita, Amethyst aggiunge gli zap Bitcoin onchain, White Noise guadagna il rendering markdown e i deep link, Keycast supera un audit di sicurezza e AgentNoise permette di controllare agenti di coding AI locali su chat cifrate Marmot. Hostr lancia una piattaforma di locazione P2P su Nostr con quattro bozze di NIP che coprono annunci, prenotazioni ed escrow basato su EVM. Angor migra la messaggistica cifrata da NIP-04 a NIP-44, Dart NDK aggiunge NIP-77 e un web signer, Alby js-sdk v8 rilascia la riconnessione multi-relay nativa NWC, e KeyChat corregge un gap di forward secrecy nell’eliminazione delle one-time prekey di Signal. Sul lato protocollo, il bond anti-abuso di Mostro raggiunge la Fase 2, Wisp rilascia risposte private e reazioni gift-wrapped, e un’ondata di implementazione NIP-05 su Namecoin tocca una mezza dozzina di client in una sola settimana.

Storie principali

Primal 3.5 per Android

Primal, il client sociale sostenuto dalla propria infrastruttura di relay di caching, ha rilasciato 3.5.9 questa settimana con una shell applicativa ricostruita. Il redesign sostituisce la struttura di navigazione precedente con un layout aggiornato e una nuova schermata Explore, dando alla superficie principale di scoperta la propria home dedicata. La release aggiunge la riproduzione audio per le anteprime dei link, così i file audio incorporati nelle note vengono riprodotti inline senza lasciare il feed. I badge di verifica NIP-05 sono ora mostrati inline sui profili, portando in vista la conferma di identità a colpo d’occhio. Il filtraggio delle notifiche ha ricevuto una revisione, consentendo agli utenti di restringere quali tipi di evento raggiungono la loro lista di notifiche. L’editor ha guadagnato una migliore gestione degli event-link, e il layer di database sottostante ha ricevuto correzioni di stabilità.

White Noise: markdown, deep link e metadati audio

White Noise, l’app di messaggistica di gruppo cifrata con Marmot costruita su Nostr e MLS (RFC 9420), ha avuto una delle sue settimane più intense fino a oggi attraverso i repository frontend e backend.

Sul frontend, PR #665 aggiunge il rendering markdown completo per i messaggi in chat, così grassetto, corsivo, blocchi di codice e link ora sono resi nativamente nella vista dei messaggi. PR #675 abilita il flusso di uscita dal gruppo che era precedentemente bloccato per gli admin non ultimi, e PR #661 aggiunge il supporto nativo ai deep link per gli URI whitenoise:// e whitenoise-staging:// che coprono utenti, chat e impostazioni, senza richiedere alcuna infrastruttura di redirect HTTP.

Sul backend in whitenoise-rs, PR #835 fa funzionare correttamente la rotazione dei key package riutilizzando lo slot d_tag per le pubblicazioni di kind:30443, abilitando la semantica di eventi replaceable NIP-33 così che le successive rotazioni di key package sostituiscano l’evento precedente sui relay, mantenendo solo il key package corrente. PR #833 estende FileMetadata con campi opzionali duration_ms e waveform per gli allegati audio, coordinato con la PR #300 di MDK che aggiunge gli stessi campi ai tag media MIP-04. Un nuovo crate whitenoise-markdown (PR #836) sostituisce il precedente parser di token nostr-sdk con una libreria dedicata al rendering markdown.

La spec del protocollo Marmot stessa ha ricevuto una correzione di sicurezza in PR #68, che chiude un problema di sicurezza specificando esplicitamente HKDF-SHA256 per le derivazioni di chiave immagine in MIP-01, rimuovendo un’ambiguità che poteva portare a divergenze implementative. In MDK, PR #307 sanifica le ragioni di fallimento dei welcome e limita la lunghezza memorizzata, chiudendo una separata segnalazione di sicurezza.

Amethyst v1.10.0: Zap Bitcoin Onchain

Amethyst ha rilasciato quattro release questa settimana, con v1.10.0 come principale. La release aggiunge il supporto agli zap Bitcoin onchain NIP-BC, consentendo agli utenti di inviare, ricevere e visualizzare zap regolati direttamente onchain tramite transazioni Bitcoin. Le release precedenti nella serie hanno corretto la rilevazione di blob Blossom per rifiutare filename non conformi (v1.09.2), patchato le regole ProGuard per le build desktop e mergiato la pull request #2977 per mostrare gli zapper Bitcoin onchain come una riga ₿ dedicata nella galleria delle reazioni espansa. Una schermata in-progress di cronologia transazioni onchain con paginazione è arrivata in PR #2974.

AgentNoise: controllare agenti di coding su White Noise

AgentNoise di nvk è un helper desktop Rust-nativo che consente di usare un telefono che esegue White Noise come superficie di controllo per sessioni di agenti di coding Codex e Claude locali. Lo strumento ascolta una o più chat White Noise, autentica i mittenti tramite un flusso PIN di first-pairing e lancia gli agenti di coding locali tramite il launcher configurato. Inviare /claude <prompt> dal telefono apre una nuova sessione di lavoro White Noise chiamata come l’hostname della macchina e un breve riepilogo del prompt, poi trasmette gli aggiornamenti di progresso e l’output finale a quella chat. È intenzionalmente Rust-first e tiene Node fuori dal percorso trusted del bridge. Il progetto ha raggiunto v0.1.24 questa settimana, aggiungendo risposte più brevi leggibili dal telefono, riferimenti a job per prefisso breve univoco e un watcher opzionale di sessione locale. AgentNoise pilota le CLI wn e wnd di marmot-protocol/whitenoise-rs come sottoprocessi, quindi condivide il proprio trasporto Nostr con il client White Noise stesso.

Audit di sicurezza di Keycast completato

Keycast, il server di remote signing NIP-46 orientato ai team che memorizza chiavi private Nostr cifrate a riposo in SQLite, ha completato un audit di sicurezza nel maggio 2026. Il passaggio di hardening ha affrontato problemi di autenticazione, permessi, integrità dei dati e dipendenze, e i risultati sono documentati in AUDIT.md. Le modifiche includono: l’auth HTTP NIP-98 richiede ora esattamente un tag u e un tag method, rifiuta timestamp obsoleti e valida gli hash payload; l’allowlist ALLOWED_PUBKEYS è parsata esattamente e forzata lato server; le policy vuote ora rifiutano di default le richieste sign/encrypt/decrypt; il rispetto delle foreign key è abilitato sulle connessioni SQLite; e le route app nidificate come /teams/:id sono protette lato server. Una migrazione SQL normalizza il JSON dei vecchi permessi di kind consentiti all’avvio. Il progetto è ancora in fase iniziale e l’audit segnala elementi residui prima di affidargli chiavi di team reali.

Scramble: client Marmot per desktop e Android

Scramble (precedentemente OpenChat) è un client desktop e Android in .NET/Avalonia per il Marmot Protocol, che implementa i MIP 00-04: pubblicazione di KeyPackage (kind:30443), metadati di gruppo con l’estensione MLS NostrGroupData, eventi welcome gift-wrapped NIP-59 (kind:444), messaggi cifrati ChaCha20-Poly1305 (kind:445) e allegati media cifrati Blossom. È pienamente interoperabile con White Noise e con qualsiasi altro client compatibile con Marmot.

Il progetto ha rilasciato 13 release questa settimana, con il supporto multi-dispositivo come funzionalità principale. Ogni dispositivo genera uno slot KeyPackage univoco (un tag d su kind:30443). All’avvio, Scramble recupera i KeyPackage propri dell’utente dai relay, rileva gli ID slot dei dispositivi peer e li aggiunge automaticamente ai gruppi MLS esistenti usando il flusso di staged commit. L’auto-aggiunta è ristretta ai gruppi in cui l’utente corrente è admin; i gruppi non-admin vengono saltati con l’indicazione di chiedere all’admin del gruppo. Un banner informativo di forward-secrecy avvisa i dispositivi appena collegati che i vecchi messaggi non sono disponibili. Un passaggio di riconciliazione degli ID slot (TryReconcileSlotId) gestisce i dispositivi migrati da versioni pre-multi-dispositivo confrontando i byte di KeyPackage del relay con il materiale di chiave locale per adottare il tag d corretto. È stata anche corretta la riconnessione al signer esterno per utenti Amber e NIP-46: la guardia IsConnected che bloccava l’auto-riconnessione interna di ExternalSignerService è stata rimossa in tutti e nove i call site in NostrService.

Hostr: locazione P2P su Nostr

Hostr (sorgente) è una piattaforma di locazione peer-to-peer costruita interamente su Nostr. Copre l’intero flusso stile Airbnb (ricerca e pubblicazione di proprietà, negoziazione di prenotazioni e regolamento dei pagamenti) usando quattro bozze di NIP che il progetto sta sviluppando in parallelo con l’applicazione.

Il NIP di accommodation estende gli annunci classificati NIP-99 (kind:30402 attivo, kind:30403 draft) con tag specifici per l’ospitalità per il tipo (room, house, apartment, villa, hotel, hostel, resort), orari di check-in/check-out, permanenza minima e indici di celle geospaziali H3 per la ricerca basata su posizione con precisione configurabile. Il NIP di prenotazione definisce un protocollo completo di negoziazione e ciclo di vita: gli eventi di prenotazione replaceable di kind:32122 portano un trade ID d, un tag a di ancoraggio all’annuncio e tag p dei partecipanti con ruoli (buyer, seller, escrow); i rumor di messaggio strutturato di kind:1327 consegnano controproposte private in fase di negoziazione tramite gift wrap NIP-59 così la negoziazione resta fuori dai relay pubblici; gli eventi di transizione append-only di kind:1326 creano un audit trail pubblico una volta che una prenotazione viene confermata. La privacy del compratore è preservata tramite chiavi Nostr temporanee per-trade legate all’identità reale del compratore tramite tag participant_proof cifrati. Il NIP di escrow definisce annunci di servizio escrow di kind:30303 e dichiarazioni di fiducia utente di kind:17388; l’implementazione di riferimento usa smart contract EVM su Rootstock, con contractBytecodeHash che permette ai client di verificare che il contratto deployato corrisponda a un’implementazione nota e auditata. Il NIP di marketplace listing definisce tag generici condivisi da tutti i profili marketplace NIP-99, inclusi instantBook, negotiable, quantity, securityDeposit, cancellationPolicy e maxDisputePeriod. Questa settimana il progetto ha preparato la sua submission all’app store e mergiato il supporto all’identità del client MCP per l’automazione rivolta agli agenti.

Due nuove voci sono apparse sulla piattaforma Shakespeare MiniApps questa settimana: InkPress, un generatore di riviste AI che pubblica contenuto strutturato in stile rivista come eventi Nostr, e PressStr, una piattaforma di scrittura e pubblicazione per lo stack Soapbox.

Rilasciato questa settimana

ngit v2.4.4

ngit ha rilasciato v2.4.4, aggiungendo ngit sync --trust-server (-t) per i casi in cui un server git è fast-forward avanti rispetto allo stato Nostr. Quando questa situazione viene rilevata, sync segnala i ref interessati e richiede il flag per firmare e pubblicare un evento di stato aggiornato; un setting git config nostr.trust-server-domains fornisce una allowlist separata da punti e virgola per i server che dovrebbero essere considerati affidabili automaticamente senza il flag.

Amber v6.1.0-pre3 aggiunge la firma PSBT

Amber ha rilasciato v6.1.0-pre3 con un layout migliorato per le nuove connessioni di app, correzioni di crash e un’opzione seleziona/deseleziona tutto nella schermata dei permessi. PR #438 aggiunge il supporto alla firma PSBT sia tramite il percorso Intent-based sia tramite quello NIP-46 basato su relay, permettendo ad Amber di firmare Partially Signed Bitcoin Transactions senza esporre l’nsec all’app richiedente.

Wisp v1.1.0 rilascia risposte private e abbandona il supporto ad Amber

Wisp ha rilasciato v1.1.0 con risposte private tramite gift wrap NIP-17 (PR #540), reazioni gift-wrapped e zap DIP-03 sulle risposte private (PR #543), auto-traduzione per le note (PR #523) e un input fiat stile register sul dialog dello zap. PR #541 migra gli zap privati da uno schema plaintext DM-relay fatto in casa a DIP-03 con un corretto routing DM-relay. Lo stesso ciclo di release ha rimosso il supporto al remote signer NIP-55 (PR #531), abbandonando Amber e altre integrazioni con signer esterni, e ha rimosso il relay locale in bundle (PR #533). Wisp è un client sociale Nostr per Android.

Calendar by Formstr v1.5.4 corregge il gift wrap per i nuovi partecipanti

Calendar by Formstr ha rilasciato v1.5.4 (l’ultima in una sequenza v1.5.2 → v1.5.4). PR #160 corregge un bug in cui l’editing di un evento di calendario privato con nuovi partecipanti pubblicava l’evento aggiornato con le nuove pubkey nei tag p ma non creava né consegnava mai inviti gift wrap a quei partecipanti, rompendo il flusso di invito per aggiunte dell’ultimo minuto. PR #156 aggiunge gestione degli errori attorno alla decifratura degli eventi privati così i client non lanciano più eccezioni su eventi non decifrabili, e PR #138 corregge orari di eventi ricorrenti che stavano andando alla deriva fra fusi orari.

Applesauce v6.1.0 aggiunge git cast NIP-34 e lookup relay NIP-51

Applesauce ha rilasciato v6.1.0 attraverso i suoi pacchetti con un significativo supporto NIP-34 (git-over-Nostr): applesauce-common aggiunge nuovi cast GitRepository, GitGraspList e FavoriteGitRepos più factory corrispondenti, ed espone le proprietà reattive User.favoriteGitRepos$, User.gitAuthors$ e User.graspServers$ così le applicazioni possono elencare i repo git seguiti da un utente, i manutentori dei repo e i server GRASP configurati direttamente dallo stesso oggetto User. La stessa release aggiunge il supporto alle liste di lookup relay NIP-51 di kind 10086, un’aggiunta recente alla famiglia di relay list usata per scoprire dove trovare dati specifici. applesauce-core guadagna replaceableAddress su EventCast per il lookup di indirizzi replaceable NIP-01, più pointer, kind e un helper getReplaceableAddressForEvent, e aggiunge un metodo timeline$() sul cast User base. PR #73 corregge i metodi manuali del pool che scartavano silenziosamente i relay offline.

Sprout v0.0.16 rilascia il binario Sprig e il protocollo huddle v2

Sprout di Block, un workspace di team basato su relay Nostr self-hosted dove esseri umani e agenti AI condividono le stesse stanze e event log, ha rilasciato v0.0.16 dell’app desktop insieme a build rolling del nuovo binario all-in-one Sprig (PR #605), che raggruppa l’harness ACP, l’agente e l’MCP per sviluppatori in un unico binario stile busybox per un deployment facile. Il flag --no-memory aggiunto in PR #611 consente agli operatori di disabilitare l’injection della core memory NIP-AE per l’harness ACP. Sul lato realtime, PR #609 estende il protocollo voice huddle a un header di frame v2 che supporta fino a 10 peer simultanei.

Nostrord v1.0.3 aggiunge keychain OS e multi-account

Nostrord ha rilasciato v1.0.3 con lo storage locale delle chiavi rafforzato usando keychain OS e fallback a passphrase, supporto multi-account e un QR code bunker tappable che apre l’app signer su Android.

Angor migra a NIP-44 e rilascia hardening di sicurezza

Angor, l’app di crowdfunding Bitcoin costruita su Nostr e Taproot, ha rilasciato tre release unstable questa settimana (v0.2.24, v0.2.25 e v0.2.26) con una serie di modifiche di hardening di sicurezza e integrazione Nostr. PR #860 migra la messaggistica cifrata Nostr da NIP-04 a NIP-44, sostituendo lo schema deprecato basato su XOR con la cifratura ChaCha20-Poly1305. PR #861 consente upload media Blossom senza un wallet selezionato usando una chiave di auth Nostr effimera, sbloccando gli upload per gli utenti che non hanno ancora connesso un wallet. La serie di sicurezza ha affrontato diverse categorie hardened: PR #854 aggiunge type safety per AngorKey e protezione della memoria della mnemonic, PR #856 impone validazione a livello di protocollo per timelock, fee rate, soglie di dust e regole di penalty, e PR #851 applica hardening non-breaking attraverso otto categorie di gravità media e bassa. PR #859 corregge la compatibilità con GrapheneOS abilitando la compilazione AOT e rimuovendo la generazione di codice a runtime, e PR #855 previene la perdita del wallet allo swipe-kill Android persistendo lo stato del wallet prima che l’OS termini il processo.

Alby js-sdk v8.0 rilascia la riconnessione multi-relay NWC

Alby js-sdk ha rilasciato la linea v8.0 (da v8.0.1 a v8.0.3) con il supporto alle sottoscrizioni multi-relay NWC. PR #516 aggiorna la dipendenza nostr-tools e abilita l’auto-riconnessione nativa attraverso più relay, sostituendo il precedente approccio a polling con una logica di riconnessione nativa del relay. PR #542 sostituisce tutte le chiamate console.debug con un’interfaccia logger iniettabile così gli sviluppatori di applicazioni possono instradare la diagnostica dell’SDK attraverso la propria infrastruttura di logging. La release abbandona il polyfill WebSocket, richiedendo Node.js 22 o superiore per i consumer lato server. v8.0.2 ha aggiunto una correzione per un bug di import crypto utils che rompeva certi bundler.

KeyChat v1.41.1 corregge la forward secrecy

KeyChat, un’app di messaggistica che combina il protocollo Signal con il trasporto tramite relay Nostr, ha rilasciato v1.41.1+6513. La correzione principale impone la forward secrecy eliminando le one-time prekey di Signal immediatamente dopo una decifratura riuscita, chiudendo un gap dove una prekey trattenuta poteva essere usata per decifrare messaggi passati se il dispositivo fosse stato successivamente compromesso. La release aggiunge anche l’anteprima URL per i messaggi consistenti in un singolo link, centralizza l’auto-download dei media sotto un nuovo FileDownloadManager con una soglia automatica di 20 MB, e rifattora il fetch delle informazioni di relay NIP-11 per forzare il refresh al cold start così le configurazioni di fee dei relay a pagamento vengono sempre caricate correttamente.

In sviluppo

Citrine ha mergiato PR #151 implementando l’enforcement di NIP-70: il relay Android ora blocca i repost che incorporano contenuto di eventi protetti, come richiede la spec. PR #149 aggiunge azioni di visualizzazione e copia per più indirizzi di connessione, localhost, Wi-Fi locale e Tor, dalla schermata delle impostazioni del relay. PR #141 aggiunge la gestione delle challenge AUTH NIP-42 tramite integrazione con signer esterno tramite Amber.

Mostro ha raggiunto la Fase 2 del suo rollout di bond anti-abuso. PR #737 porta la logica di slash di dispute diretta dal solver: gli handler admin ora consumano il payload BondResolution da mostro-core, consentendo a un admin di slashare il bond di una delle parti quando risolve una disputa. La Fase 1.5, mergiata in PR #736, ha introdotto un’azione dedicata PayBondInvoice e uno status WaitingTakerBond, separando il pagamento del bond anti-abuso del taker dal payout di trade del compratore. Il client mobile ha aggiunto la UX completa di Fase 1.5 in PR #592. Mostro è un protocollo di exchange Bitcoin peer-to-peer costruito su Nostr.

Damus ha mergiato PR #3773 ripristinando l’indicatore di segnale del relay, e PR #3775 corregge relay che rifiutavano di riconnettersi dopo un fallimento iniziale di connessione.

rust-nostr ha mergiato PR #1358 aggiungendo trait di finalizzazione degli eventi e builder di eventi specifici per NIP, rendendo più facile costruire eventi correttamente tipizzati per funzioni di protocollo specifiche. PR #1363 porta indietro una correzione che assicura che il signer NIP-46 si sottoscriva alle notifiche prima di inviare la risposta di connect, chiudendo una race condition in cui i messaggi del client che arrivavano immediatamente dopo il connect potevano essere persi.

dart-nostr ha mergiato PR #44 aggiungendo un resolver di relay Namecoin .bit e record di pin TLSA, permettendo alle applicazioni Flutter di risolvere URL di relay wss://example.bit/ tramite DNS Namecoin ai loro effettivi indirizzi WebSocket.

Dart NDK (il Nostr development kit Dart/Flutter, ora in relaystr/ndk) ha mergiato PR #464 implementando NIP-77, il protocollo di firma eventi offline. Sul lato signer, PR #602 e PR #601 aggiungono un event signer specifico per web e un’astrazione PlatformEventVerifier, consentendo alle app Flutter web di usare il signer di piattaforma senza un percorso di codice separato; PR #604 introduce una factory di event signer per la selezione a runtime del signer. PR #608 aggiunge getDmRelays() per recuperare la lista di relay DM NIP-17 di un utente (kind:10050), e PR #600 corregge la preservazione dei campi firmati NIP-46 così i remote signer non perdono campi al round-trip.

Pages by Form* (repo), l’app di documenti collaborativi Nostr-native di Formstr ospitata a pages.formstr.app, ha mergiato quattro PR questa settimana stringendo i flussi di attachment cifrato e gestione documenti. PR #37 corregge immagini mancanti negli export DOCX, HTML e PDF inserendo inline gli allegati cifrati: recupera i blob <encrypted-file> dai server Blossom, li decifra con AES-GCM 256-bit usando la chiave e il nonce memorizzati, valida il MIME type dell’immagine e li converte in URL dati base64 così gli export preservano immagini che esistono solo su Blossom in forma cifrata. PR #39 aggiunge un meccanismo di ricerca documenti locali, PR #38 sistema il flusso di rinomina, e PR #40 corregge la gestione dei backup condivisi.

Zap Cooking ha mergiato PR #396, la prima fase di una revisione del feed che pone le primitive di rendering del feed senza alcun cambiamento ancora visibile all’utente. La PR introduce un parser di tag imeta NIP-92 che legge gli slot url, m (MIME), dim (dimensioni), blurhash, alt, x (hash file) e fallback, più un decoder canonico blurhash portato a mano (~200 LOC) che produce data URL PNG tramite canvas con un fallback null SSR-safe. Quando i tag imeta sono assenti, il parser ricade sull’estrazione di URL grezzi di immagine e video dal contenuto dell’evento usando le stesse euristiche che il feed corrente già usa.

Nurunuru (ぬるぬる, tami1A84/null--nostr), un client Nostr con varianti Android, iOS e Web native che condividono un engine FFI Rust, ha mergiato la sua sync Native → Web v1.5.0 in PR #176. La sync porta diverse aggiunte di funzionalità alla build Web che erano già state rilasciate su Android v1.4.9 e iOS 1.0.4: la NotificationModal ora mostra notifiche di compleanno, rilevazione di zap mutual-follow e notifiche di reazione con emoji custom; il selettore di reazioni abbandona la quick-row di reazioni Unicode di default e centra la UX sulle emoji custom; l’engine di raccomandazione in lib/recommendation.js filtra utenti senza icone o display name e dà priorità alle voci Following con Recommended che carica in background. L’input vocale è l’unica funzionalità che va nella direzione opposta: la build Web usa già lo streaming ElevenLabs Scribe, e v1.5.0 sincronizza parzialmente il lato Native con SpeechRecognizer standard OS (Android) e SFSpeechRecognizer + AVAudioEngine (iOS) mentre l’integrazione Scribe Native completa è rimandata a v1.6.

Lavoro di protocollo e spec

PR #2251 stringe la spec degli eventi protetti NIP-70: ora dichiara esplicitamente che i repost che incorporano il contenuto completo di un evento protetto devono essere rifiutati dai relay. NIP-70 definisce il tag - che segnala che un autore di nota non acconsente a che la sua nota venga ripubblicata. La spec originale copriva il comportamento di filtraggio del relay, ma lasciava ambiguo il caso di repost. Questa PR chiude quel gap. La PR #151 di Citrine implementa l’enforcement sul lato relay in questa stessa settimana.

PR #1653 propone un NIP Drafts per salvare e sincronizzare eventi di bozza privati. La proposta usa eventi replaceable con status draft e cifratura NIP-44 verso la chiave dell’autore stesso, consentendo ai client di salvare lavori in corso sui relay senza che quegli eventi siano visibili a chiunque altro. L’evento draft porta l’evento completo di pubblicazione intesa come contenuto cifrato, incluso il suo eventuale kind e tag.

Snapshots (PR #2279) è una proposta aperta di definire un evento snapshot immutabile per preservare una versione esatta di un evento Nostr replaceable. L’evento snapshot porta il contenuto completo dell’evento replaceable in un dato momento nel tempo, con un tag a che lo collega all’indirizzo dell’evento replaceable così tutte le versioni storiche sono interrogabili insieme. Questo rende possibile agli osservatori ispezionare lo stato storico anche dopo che i relay smettono di conservare le vecchie versioni.

Ondata Namecoin NIP-05: Questa settimana ha visto una spinta coordinata per aggiungere la risoluzione NIP-05 .bit ai client Nostr. Il feed di discussione NIP ha catturato PR open-source contro Aegis (#14, che aggiunge la verifica al momento della firma nel signer), nostter (#2128) e dart-nostr (#44), insieme a una bozza NIP upstream (PR #2349). La PR di Aegis è notevole per aver posto la verifica sul lato produttore: il signer controlla la chain Namecoin prima di firmare qualsiasi evento di kind:0 che rivendica un’identità .bit e avvisa l’utente in caso di mismatch, catturando il problema prima che l’evento raggiunga qualsiasi relay.

NIP Deep Dive: NIP-07 (window.nostr per i browser Web)

NIP-07 definisce l’interfaccia window.nostr che le estensioni browser espongono alle applicazioni web. È l’interfaccia di signer più ampiamente deployata sul web, implementata da estensioni tra cui Alby, nos2x, Flamingo e horse.

L’interfaccia ha due metodi obbligatori e diversi opzionali. window.nostr.getPublicKey() restituisce la chiave pubblica dell’utente come stringa hex senza mai esporre la chiave privata alla pagina chiamante. window.nostr.signEvent(event) prende un evento parziale con created_at, kind, tags e content, e restituisce l’evento firmato completo con id, pubkey e sig aggiunti. Il punto chiave è che la chiave privata non lascia mai il contesto isolato dell’estensione; l’applicazione web sottomette un evento non firmato e riceve indietro uno firmato.

I metodi opzionali coprono la cifratura: window.nostr.nip04.encrypt e window.nostr.nip04.decrypt per il vecchio schema NIP-04 (ora deprecato), e window.nostr.nip44.encrypt e window.nostr.nip44.decrypt per lo schema NIP-44 corrente. Le estensioni che supportano NIP-44 possono quindi gestire sia la cifratura dei messaggi diretti sia qualsiasi altra applicazione che necessita di cifratura keyed su pubkey senza che la pagina chiamante veda l’nsec.

La spec include anche una raccomandazione agli autori di estensioni: caricare gli script con "run_at": "document_end" nel manifest dell’estensione così window.nostr è disponibile in modo sincrono quando la pagina si carica, evitando race condition in cui un client controlla window.nostr prima che l’estensione l’abbia iniettato.

Un esempio chiave di NIP-07 in azione è il progetto Keycast trattato sopra. Il frontend web di Keycast usa NIP-07 per firmare eventi di auth HTTP NIP-98: l’app SvelteKit non gestisce mai direttamente l’nsec dell’utente. Chiama window.nostr.signEvent per produrre l’header di auth, poi invia quell’header all’API Keycast. Questa architettura significa che il materiale della chiave resta nell’estensione browser lungo tutto il flusso di gestione delle chiavi di team.

{
 "id": "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2",
 "pubkey": "7f8e9d0c1b2a3e4f5d6c7b8a9f0e1d2c3b4a5f6e7d8c9b0a1f2e3d4c5b6a7f8a",
 "created_at": 1747785600,
 "kind": 1,
 "tags": [],
 "content": "Hello from a NIP-07 signed event",
 "sig": "0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2cdd"
}

NIP Deep Dive: NIP-39 (identità esterne nei profili)

NIP-39 definisce come un utente Nostr può dichiarare il controllo su identità esterne di piattaforma nel proprio profilo. Ciascuna dichiarazione usa un tag i dentro un evento di kind:10011, asserendo la proprietà di uno specifico account su un’altra piattaforma insieme a una prova che può essere verificata indipendentemente.

Ogni tag segue il formato ["i", "platform:identity", "proof"], dove platform:identity combina il nome della piattaforma e lo username con un separatore due punti (github:semisol, twitter:semisol_public). proof punta a un artefatto verificabile sulla piattaforma stessa.

Per GitHub, la prova è un ID di Gist. L’utente crea una Gist pubblica dal proprio account GitHub contenente il testo Verifying that I control the following Nostr public key: npub1.... Un client che verifica il claim recupera https://gist.github.com/<identity>/<proof> e controlla che la Gist sia stata scritta dallo username GitHub reclamato e contenga la pubkey attesa. Per Twitter la prova è un ID di tweet, per Mastodon un ID di post, e per Telegram un riferimento a messaggio in un gruppo pubblico.

Il nome del provider di identità deve contenere solo a-z, 0-9 e i caratteri ._-/, e non deve contenere :. I nomi di identità dovrebbero essere normalizzati in minuscolo, con l’alias principale usato quando ne esistono multipli.

La discussione NIP-05 .bit Namecoin che avviene questa settimana mostra il ruolo di NIP-39 nello stack di identità più ampio: fornisce un modo standardizzato e agnostico ai relay di cross-referenziare una chiave Nostr con un’identità stabilita altrove, senza richiedere alcuna autorità di verifica centrale. Un client può verificare indipendentemente la prova recuperando un artefatto pubblico sulla piattaforma nominata, e la prova è legata alla specifica pubkey Nostr nel testo della Gist o del tweet, non a una credenziale di piattaforma generica.

{
 "id": "b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3",
 "pubkey": "7f8e9d0c1b2a3e4f5d6c7b8a9f0e1d2c3b4a5f6e7d8c9b0a1f2e3d4c5b6a7f8a",
 "created_at": 1747785600,
 "kind": 10011,
 "tags": [
 ["i", "github:semisol", "9721ce4ee4fceb91c9711ca2a6c9a5ab"],
 ["i", "twitter:semisol_public", "1619358434134196225"],
 ["i", "mastodon:bitcoinhackers.org/@semisol", "109775066355589974"]
 ],
 "content": "",
 "sig": "1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3eff"
}

È tutto per questa settimana. Se stai costruendo qualcosa o hai notizie da condividere, mandaci un DM su Nostr o trovaci su nostrcompass.org.

Nostr Compass #22

Wed, 13 May 2026 00:00:00 +0000

Bentornati a Nostr Compass, la vostra guida settimanale allo sviluppo del protocollo Nostr.

Questa settimana: Nostr VPN pubblica otto versioni in sette giorni, da un flusso di pairing dei dispositivi ridisegnato a uno swap AEAD FIPS che circa raddoppia il throughput TCP. Marmot Protocol (la base di White Noise) pubblica una versione frontend che completa la funzionalità di blocco degli utenti e 31 PR unite su MDK e backend. Grain pubblica v0.6.0 con quattro nuove implementazioni NIP in un unico traguardo. Citrine pubblica v3.0.0-pre1 con Tor integrato e aggregazione relay. Amber pubblica v6.1.0-pre2 con miglioramenti al flusso di connessione e alla firma. Alby Hub pubblica v1.22.2 con una pagina AI e Agenti e l’integrazione Core Lightning. Mostro pubblica i bond del taker concorrenti e mostro-core v0.11.0. Jumble pubblica cinque versioni con la cronologia delle ricerche recenti e correzioni alla persistenza dei dati account. Nostrord pubblica tre versioni con modal di condivisione gruppo e pacchetti Arch Linux. Flotilla pubblica 1.8.0 con videochiamate, rendering email e menzioni di stanza. Calendar by Formstr pubblica v1.5.1 con la pianificazione degli appuntamenti e la sincronizzazione del calendario Android. Tamagostrich lancia un Tamagotchi NIP-78 decentralizzato con ricompense in sats.

Storie principali

Nostr VPN pubblica otto versioni culminando con v4.0.10

Nostr VPN, la VPN mesh decentralizzata basata su Rust che utilizza Nostr per la scoperta dei peer, ha pubblicato otto versioni da v4.0.1 a v4.0.10 su macOS, Linux, Windows e Android. La modifica principale di v4.0.8: l’AEAD è stato sostituito dal backend software RustCrypto chacha20poly1305 con ChaCha20-Poly1305 di BoringSSL in ring 0.17, che utilizza NEON ottimizzato a mano su aarch64 e AVX2/AVX-512 su x86_64. I benchmark Docker su hardware identico hanno mostrato il throughput TCP diretto a 2 nodi passare da 437 a 1097 Mbps. v4.0.9 ha aggiunto il batching sendmmsg(2) sul percorso di invio UDP, portando il TCP single-stream da 1066 a 1548 Mbps (1,45×). v4.0.10 ha pubblicato una completa revisione della UX di pairing dei dispositivi.

Marmot / White Noise pubblica una versione frontend che completa il blocco degli utenti e 31 PR unite su MDK e backend

White Noise ha pubblicato v2026.5.7+24 il 7 maggio completando il set di funzionalità di blocco. Un utente bloccato è ora nascosto dagli inviti, dalle anteprime delle chat, dalle timeline dei messaggi, dai risultati di ricerca e dalle notifiche, e i suoi messaggi non contano più nei badge dei messaggi non letti. MDK ha integrato PR #258 con il formato wire dell’estensione v3 e lo schema disappearing_message_secs, gettando le basi per i messaggi a scomparsa.

Grain v0.6.0 aggiunge NIP-40, NIP-50, NIP-70 e NIP-45

Grain ha pubblicato v0.6.0 il 6 maggio con quattro nuove implementazioni NIP. La scadenza degli eventi NIP-40 consente ai publisher di impostare un timestamp di scadenza affinché il relay elimini gli eventi dopo la loro scadenza. La ricerca full-text NIP-50 consente ai client di emettere filtri di ricerca nei messaggi REQ. Gli eventi protetti NIP-70 impediscono ai relay di ricondividere eventi senza l’esplicita autorizzazione dell’autore. Le query di conteggio NIP-45 consentono ai client di chiedere a un relay di restituire un conteggio degli eventi corrispondenti.

Pubblicazioni della settimana

Citrine v3.0.0-pre1 integra Tor nativo e aggregazione relay

Citrine ha pubblicato v3.0.0-pre1 con supporto Tor integrato per un accesso ai relay che preserva la privacy e l’aggregazione relay, dove Citrine può estrarre eventi da più relay upstream e servirli ai client locali. PR #139 aggiunge il supporto NIP-77 (Negentropy Reconciliation) per la sincronizzazione efficiente degli eventi basata sulla riconciliazione degli insiemi.

Amber v6.1.0-pre2 migliora il flusso di connessione delle nuove app

Amber ha pubblicato v6.1.0-pre2. Le correzioni principali: il dialogo del firmatario ora si chiude correttamente dopo aver accettato una richiesta bunker, le richieste bunker malformate mostrano una schermata di richiesta non valida, e viene aggiunta la limitazione della velocità per le richieste di firma basate su intent.

Alby Hub v1.22.2 aggiunge la pagina AI e Agenti e il supporto Core Lightning

Alby Hub ha pubblicato v1.22.2. La nuova pagina AI e Agenti espone le capacità Lightning e NWC di Alby Hub agli agenti AI e agli strumenti compatibili MCP. Core Lightning (CLN) è ora un backend supportato insieme a LND e LDK.

Mostro pubblica i bond del taker concorrenti e mostro-core v0.11.0

Mostro ha integrato 11 PR che avanzano la funzionalità di bond del taker. PR #733 implementa i bond del taker concorrenti dove più taker possono inviare fatture di bond contemporaneamente e il primo a bloccare vince. mostro-core ha pubblicato v0.11.0 con PR #144 che aggiunge Action::PayBondInvoice e Status::WaitingTakerBond. mostro-cli ha pubblicato v0.15.0.

Jumble pubblica cinque versioni con ricerca recente e persistenza degli account

Jumble ha pubblicato v26.5.2 fino a v26.5.6. v26.5.5 aggiunge la cronologia delle ricerche recenti. Un bug critico di persistenza è corretto in v26.5.6: gli account e i dati memorizzati nella cache sopravvivono ora a un riavvio completo dell’app.

Nostrord ha pubblicato v1.0.0, v1.0.1 e v1.0.2. v1.0.1 pubblica pacchetti Arch Linux tramite AUR come nostrord-bin con artefatti firmati con PGP, un pulsante per saltare all’ultimo messaggio e l’incolla di immagini/media nella chat. v1.0.2 aggiunge la condivisione del gruppo tramite PR #49 con un modal di condivisione che genera sia un URI nostr:naddr che un link nostrord.com/open/.

FIPS v0.3.0 pubblica portata multipiattaforma, scoperta peer Nostr e un gateway per LAN non modificate

FIPS ha pubblicato v0.3.0, un traguardo importante che si espande da Linux-only a Linux, macOS, Windows e OpenWrt. I nodi ora pubblicano annunci overlay firmati come eventi parametrizzati sostituibili kind:37195 sui relay Nostr pubblici. Lo stesso swap ChaCha20-Poly1305 di ring 0.17 che ha alimentato il salto di throughput di Nostr VPN è presente anche in FIPS v0.3.0.

Camelus v1.10.1 pubblica versioni desktop

Camelus ha pubblicato v1.10.1 con versioni desktop per Windows e Linux, espandendo la distribuzione oltre il solo mobile.

Flotilla 1.8.0 pubblica videochiamate, rendering email e menzioni di stanza

Flotilla ha pubblicato 1.8.0. Le stanze vocali ora supportano il video: i partecipanti possono attivare le telecamere o condividere il proprio schermo durante una chiamata. Il rendering email arriva tramite un aggiornamento alla libreria welshman. Le menzioni di stanza consentono agli utenti di fare riferimento ad altre stanze e relay con link inline cliccabili.

Calendar by Formstr pubblica v1.5.1 con pianificazione degli appuntamenti e sincronizzazione del calendario Android

Calendar by Formstr ha pubblicato v1.5.0 il 10 maggio e v1.5.1 l'11 maggio. La pianificazione degli appuntamenti consente agli utenti di creare slot temporali prenotabili. L’integrazione del calendario Android in sola lettura sincronizza gli eventi Nostr con il calendario del dispositivo.

In sviluppo

Amethyst aggiunge post programmati, regole di comunità NIP-9A e un relay locale desktop

Amethyst ha integrato 78 PR questa settimana. I post programmati arrivano in PR #2765. Una versione desktop acquisisce un relay locale integrato con persistenza degli eventi SQLite in PR #2841. Tre PR implementano le regole di comunità NIP-9A: PR #2798 valida i post rispetto alle regole di comunità prima dell’invio, PR #2799 aggiunge un editor di regole NIP-9A strutturato, e PR #2800 aggiunge un filtro di feed NIP-9A opzionale.

Shopstr aggiunge la registrazione degli audit MCP e la sicurezza delle sessioni

Shopstr ha integrato cinque PR. La registrazione degli audit per il livello di strumenti MCP arriva in PR #456. La sicurezza delle sessioni si rafforza in PR #477 con il pinning delle sessioni alla chiave API di origine e l’espulsione TTL.

Dart NDK aggiunge il supporto web e la verifica delle firme dei sigilli

Dart NDK ha integrato sei PR. Il supporto web arriva in SembastCacheManager tramite PR #571. La verifica delle firme dei sigilli arriva in PR #595 per il flusso NIP-59 Gift Wrap.

Nuovi progetti

Tamagostrich lancia un Tamagotchi NIP-78 decentralizzato con ricompense in sats

Tamagostrich è un gioco di animale virtuale nel browser lanciato all’IDENTITY Hackathon 2026 dove un piccolo struzzo, Nori, si evolve attraverso la tua attività sociale Nostr. Lo stato dell’animale è memorizzato in un evento NIP-78 kind:30078 per la sincronizzazione multi-dispositivo. Le ricompense ai traguardi vengono pagate in sats tramite NIP-47: 50 sats al livello 5, 210 sats al livello 10 e 420 sats al livello massimo 21, inviati all’indirizzo lud16 dell’utente.

Lavori su protocollo e specifiche

Cinque nuove proposte sono state aperte questa settimana:

PR #2331 propone NIP-9A: Regole di Comunità Verificabili, introducendo kind:34551 per documenti di regole di comunità leggibili da macchina e firmati crittograficamente.

PR #2335 propone gli Eventi di Prenotazione per i Marketplace Nostr, definendo kind:32122 (eventi di prenotazione parametrizzati sostituibili), kind:1326 (record di audit delle transizioni solo in aggiunta) e kind:32124 (recensioni post-transazione). La negoziazione è privata tramite messaggi gift-wrapped NIP-59.

PR #2334 propone i Servizi di Escrow per i Marketplace Nostr usando kind:30303 affinché gli operatori di escrow dichiarino il loro indirizzo di contratto EVM e il listino tariffe.

PR #2333 propone i Profili di Annuncio di Alloggio per gli Annunci del Marketplace NIP-99, estendendo NIP-99 con tag g di indice geospaziale H3 per gli annunci di affitto a breve termine.

PR #2332 propone NIP-BC: Zap On-chain (kind 8333), sfruttando l’identità diretta tra le chiavi Nostr e gli indirizzi Bitcoin Taproot. Il numero di kind rispecchia NIP-57: 9735 è la porta P2P di Lightning; 8333 è la porta P2P della mainnet Bitcoin.

Approfondimento NIP: NIP-78 (dati specifici dell’app)

NIP-78 definisce un metodo standard con cui le applicazioni memorizzano dati arbitrari privati o pubblici per conto di un utente tramite eventi Nostr. Il tipo di evento centrale è 30078, un evento parametrizzato sostituibile in cui il tag d è una stringa identificatore definita dall’applicazione. Un’applicazione assegna al proprio slot di storage un tag d univoco e pubblica un evento 30078 con qualsiasi contenuto JSON o testo che deve persistere. La motivazione principale è la sincronizzazione multi-dispositivo senza un server centralizzato. Per i dati privati dell’applicazione, gli eventi NIP-78 possono cifrare il campo content usando NIP-44 prima della pubblicazione. Gli utenti attuali includono Tamagostrich (sincronizzazione dello stato dell’animale), Wisp (backup del portafoglio e impostazioni di sicurezza), NosPress (stato di orchestrazione CMS) e diverse implementazioni di sincronizzazione delle impostazioni dei client Nostr.

Fonti primarie:

Specifica NIP-78: https://github.com/nostr-protocol/nips/blob/master/78.md
Tamagostrich: https://github.com/Negr087/tamagostrich

Vedi anche: Liste NIP-51, Metadati elenco relay NIP-65

Approfondimento NIP: NIP-98 (HTTP Auth)

NIP-98 definisce uno schema di autenticazione HTTP che consente alle coppie di chiavi Nostr di autorizzare richieste a server HTTP, eliminando nomi utente, password o token OAuth. Un client costruisce un evento Nostr di breve durata di kind 27235, lo firma con la propria chiave privata, codifica il JSON in base64 e lo invia in un header HTTP Authorization: Nostr . L’evento kind 27235 include il metodo HTTP in un tag method, l’URL completo della richiesta in un tag u e un timestamp created_at. Il server valida la firma, verifica che metodo e URL corrispondano e controlla che il timestamp sia recente per prevenire gli attacchi di replay. NIP-98 è usato in Blossom (BUD-01) per l’autenticazione dell’upload dei blob, Routstr per il controllo degli accessi API per richiesta, Sprout per l’autenticazione del trasporto git e Alby Hub per l’autenticazione dell’API admin.

Fonti primarie:

Specifica NIP-98: https://github.com/nostr-protocol/nips/blob/master/98.md
BUD-01: https://github.com/hzrd149/blossom/blob/master/buds/01.md

Vedi anche: Integrazione archiviazione file HTTP NIP-96

È tutto per questa settimana. Se state costruendo qualcosa o avete notizie da condividere, inviateci un DM su Nostr o trovateci su nostrcompass.org.

Nostr Compass #21

Wed, 06 May 2026 00:00:00 +0000

Bentornati a Nostr Compass, la vostra guida settimanale all’ecosistema Nostr.

Questa settimana: Marmot Protocol pubblica MDK 0.8.0 con le prime primitive di notifica MIP-05, pacchetti di chiavi NIP-51 indirizzabili e una revisione della sicurezza rafforzata. LaWallet NWC pubblica v0.10.0, la versione più importante dalla copertura di OpenSats, con una dashboard admin completa, portafoglio utente, registro delle attività end-to-end e un nuovo schema LightningAddress 1→N e NWCConnection. Amethyst porta uno sprint di stabilizzazione di Nests con l’eliminazione dei gap audio durante il refresh JWT, sottoscrizioni di dati chiave lifecycle-aware, riconnessione keep-alive dei relay e un indicatore animato del parlante attivo. ngit pubblica v2.4.2 e v2.4.3 correggendo il rilevamento del server GRASP per le submission di PR e il filtraggio degli eventi di stato multi-remote. GRAIN pubblica v0.5.4 con hardening per la produzione e una correzione silenziosa di perdita di dati nel Docker quick-start. Mostro Core pubblica v0.10.1 con artefatti di release firmati con PGP. Clave lancia v0.2.0 con supporto multi-account su iOS.

Storie principali

MDK 0.8.0 aggiunge le primitive di notifica MIP-05 e i pacchetti di chiavi indirizzabili

MDK, la libreria Rust centrale per il protocollo Marmot, ha pubblicato v0.8.0 il 4 maggio. Questa versione introduce i primi blocchi costruttivi di notifica MIP-05, sposta i pacchetti di chiavi MIP-00 verso eventi indirizzabili così da poter sostituire il pacchetto chiavi di un utente in-place, migliora la compatibilità dei gruppi a versione mista, espande la copertura UniFFI per i binding mobile e rafforza i percorsi di validazione attorno alle azioni admin, commit, storage, limiti di cifratura e gestione dei replay. Le primitive MIP-05 includono helper di indice foglia aggiunti in PR #235, che forniscono ai client downstream informazioni sufficienti per consegnare notifiche push per destinatario senza rivelare la struttura del gruppo. PR #273 ripristina la pubblicazione di mdk-core su crates.io, e PR #269 espone il modulo test_util dietro una feature Cargo test-utils così che le suite di test client esterne possano condividere il test harness di Marmot.

LaWallet NWC v0.10.0 pubblica il monorepo completo e il portafoglio utente finale

LaWallet NWC, l’implementazione NIP-47 Nostr Wallet Connect del team LaWallet, ha pubblicato v0.10.0 il 30 aprile. È la versione più importante da quando il progetto ha ricevuto il finanziamento OpenSats. Include il monorepo completo, la dashboard admin completa, un portafoglio utente finale, un registro attività end-to-end, branding dinamico e il nuovo schema LightningAddress 1→N e NWCConnection. Il portafoglio per gli utenti finali, pubblicato in PR #191, copre l’onboarding, la home, invio/ricezione, scansione, valute, un feed attività e una cache offline.

Amethyst stabilizza Nests con keep-alive, resilienza JWT e sottoscrizioni lifecycle

Amethyst, il client Android ricco di funzionalità, ha continuato il lavoro sulle stanze audio NIP-53 Nests con uno sprint di stabilizzazione incentrato sui modi di guasto che interrompevano le chiamate in produzione. La correzione del gap audio in PR #2733 sovrappone la nuova acquisizione delle credenziali con il flusso attivo durante il refresh JWT. Un nuovo meccanismo keep-alive in PR #2730 riconnette i relay disconnessi senza richiedere un’azione manuale dell’utente, e PR #2728 sostituisce la vecchia KeyDataSourceSubscription con LifecycleAwareKeyDataSourceSubscription. PR #2724 aggiunge un indicatore ad anello esterno animato che evidenzia il parlante attivo nelle sessioni multi-parlante.

ngit v2.4.2 e v2.4.3 correggono il rilevamento del server GRASP e gli eventi di stato multi-remote

ngit, lo strumento da riga di comando e plugin git per la collaborazione NIP-34, ha pubblicato v2.4.2 il 28 aprile e v2.4.3 il 1° maggio. v2.4.2 corregge una mancata corrispondenza di normalizzazione URL in cui i repo_grasps contenevano hostname normalizzati ma il confronto veniva effettuato rispetto agli URL di clone completi. v2.4.3 corregge un’ambiguità negli eventi di stato che emergeva quando un repository ha più remote nostr:// che condividono lo stesso identificatore.

GRAIN v0.5.4 aggiunge hardening per la produzione e corregge una perdita di dati silenziosa

GRAIN, il relay Nostr e la libreria client basati su Go, ha pubblicato v0.5.4 il 30 aprile. La versione raccoglie sei correzioni accumulate dalla v0.5.3, incluso un bug di perdita di dati silenziosa nel Docker quick-start che in precedenza eliminava eventi al riavvio del container, e un bug di correttezza nel livello di storage nelle letture di eventi indirizzabili.

Mostro Core v0.10.1 aggiunge artefatti di release firmati con PGP

Mostro Core, la libreria Rust che fornisce funzionalità peer-to-peer per il daemon Mostro, ha pubblicato v0.10.1 il 28 aprile. La nuova versione aggiunge artefatti di release firmati con PGP e un flusso di verifica della release così che i packager downstream possano confermare la provenienza degli artefatti.

Release con tag

Clave v0.2.0 lancia il multi-account su iOS con firma NIP-46 (Nostr Connect)

Clave, l’app iOS per la firma remota NIP-46, ha pubblicato v0.2.0 il 5 maggio. Il principale aggiornamento introduce il supporto multi-account: Clave può ora gestire fino a quattro account su un unico dispositivo, con un selettore one-tap e isolamento per account. PR #23 aggiunge il codice iOS per il multi-account, e PR #22 aggiunge un campo signer_pubkey al payload APNs così che il dispositivo sappia a quale account appartiene una richiesta di firma remota.

Wisp pubblica v1.0.3 → v1.0.5 con lavori di stabilità

Wisp, il client Android, ha pubblicato v1.0.3, v1.0.4 e v1.0.5 il 4 maggio con lavori di stabilità. PR #506 aggiunge Thumbhash per le anteprime sfocate delle immagini mentre i media completi si caricano, e PR #514 riduce lo scatto nel cambio delle schede inferiori.

Amber 6.1.0-pre1 pubblica correzioni di layout e stabilità

Amber, l’app di firma Android per NIP-55 e NIP-46, ha pubblicato v6.1.0-pre1 con una revisione del layout nel flusso di connessione delle nuove app e diverse correzioni di crash. PR #416 corregge il layout di ActivityStatsBar e i problemi di overflow del testo.

Routstr Core v0.4.3 migliora pagamento, rimborso e reportistica sull’utilizzo

Routstr Core ha pubblicato v0.4.3 come pre-release il 1° maggio con miglioramenti alla gestione dei pagamenti e dei rimborsi, al tracciamento dei costi e alla reportistica sull’utilizzo.

Nostria v3.1.37 fino a v3.1.41 aggiungono i segnalibri Web e un tema Auto

Nostria, il client Nostr multi-piattaforma, ha pubblicato v3.1.37 fino a v3.1.41 aggiungendo il supporto ai segnalibri Web NIP-B0, un tema Auto che segue le impostazioni del dispositivo e la visualizzazione PDF integrata nell’app.

NoorNote v0.8.9 corregge la schermata vuota al primo avvio sul desktop

NoorNote ha pubblicato v0.8.9 il 28 aprile correggendo un bug di schermata vuota al primo avvio dell’app desktop.

Kubo v0.3.4 fino a v0.4.1 pubblicano una piattaforma video Nostr a misura di bambino con controlli parentali e curation del feed tramite Web of Trust

Kubo, una piattaforma video a misura di bambino su Nostr, ha pubblicato v0.3.4 fino a v0.4.1 il 4 e 5 maggio. Ogni bambino riceve una coppia di chiavi Nostr separata e un feed incentrato sui video dove i genitori controllano i limiti di tempo (da 15 a 180 minuti al giorno), le finestre temporali consentite e la visibilità delle azioni sui post.

Modifiche non rilasciate

Sprout pubblica Desktop v0.0.4 e v0.0.5 con autenticazione agente NIP-OA e il sidecar pair-relay

Sprout, il client Nostr di Block con relay integrato, ha pubblicato Desktop v0.0.4 il 5 maggio e v0.0.5 il 6 maggio. PR #471 integra l’autenticazione agente NIP-OA nel flusso di membership NIP-43 del relay così che un agente autonomo possa dimostrare che una specifica chiave pubblica umana ha autorizzato le sue azioni. Un nuovo relay sidecar effimero per il pairing di dispositivi NIP-AB arriva in PR #467 come sprout-pair-relay.

nostream aggiunge il supporto relay Marmot e le reazioni NIP-25

nostream, l’implementazione relay Node.js, ha integrato il supporto relay Marmot Protocol che copre i MIP da 00 a 03 in PR #602, il supporto alle reazioni NIP-25 in PR #589 e la corrispondenza del prefisso geohash per i filtri #g in PR #586.

strfry aggiunge l’osservabilità per connessione e riduce il tetto nofiles

strfry, il relay Nostr in C++, ha integrato 14 PR che puntano all’osservabilità. PR #218 aggiunge l’osservabilità degli outbound in attesa per connessione e un cap di back-pressure configurabile. PR #224 rimuove le allocazioni heap di std::function dal fanout del monitor per evento.

Damus sostituisce i GIF Tenor con un proxy Purple e pubblica la UX di compattazione

Damus ha integrato PR #3737 sostituendo l’integrazione GIF Tenor con un proxy Damus Purple.

Primal Android migliora Explore, gli avvisi e il badge di verifica NIP-05

Primal Android ha integrato PR #1043 correggendo un badge di verifica NIP-05 lampeggiante per gli utenti con identificatori _@domain.

Alby Hub aggiunge i pagamenti NWC dalle connessioni delle app

Alby Hub ha integrato PR #2267 che consente i pagamenti dalle connessioni delle app.

routstrd-auth: un Routstrd Docker per team con autenticazione NIP-98 e RBAC npub

routstrd-auth, creato il 27 aprile, è una variante Docker di Routstrd per i deployment in team multi-utente con controllo degli accessi basato sui ruoli npub e autenticazione HTTP NIP-98.

Routstrd integra Hermes per i client daemon e la modalità remota

Routstrd ha integrato PR #22 aggiungendo l’integrazione con Hermes Agent così che il file di configurazione dell’agente venga popolato con i provider di modelli e le chiavi API che Routstrd scopre tramite Nostr.

whitenoise-rs pubblica l’isolamento del database per account e gli aggiornamenti delle proposte

whitenoise-rs ha integrato PR #796 spostando le tabelle di proiezione dei messaggi in database per account, e PR #791 aggiunge gli aggiornamenti delle proposte così che i gruppi possano estendere le funzionalità con nuovi tipi di proposta.

Angor 0.2.21 pubblica flussi applicativi compatti con hardening del provider di chiavi e del cambio rete

Angor ha pubblicato 0.2.21 il 6 maggio con miglioramenti alle performance del design mobile, flussi applicativi compatti e un provider di chiavi sicuro.

Nuovi tracciati e scoperti

BitMacro Signer: un bunker NIP-46 auto-ospitato con cifratura delle chiavi lato client

BitMacro Signer è uno strumento di firma Nostr auto-ospitato che utilizza il modello bunker NIP-46. Le chiavi vengono cifrate lato client prima della memorizzazione così che il server non detenga mai testo in chiaro.

La scoperta di repository NIP-34 ha portato alla luce 26 nuovi annunci di repository questa settimana, di cui quattro si distinguono:

gnostr: un’implementazione git costruita direttamente su Nostr

gnostr è un’implementazione git costruita direttamente su Nostr, che fornisce i propri comandi di albero di lavoro come client di controllo versione nativo Nostr sviluppato da zero.

nostr-archive: una specifica di archivio content-addressed su Nostr e Blossom

nostr-archive è una specifica bozza e un’implementazione di riferimento per archivi content-addressed su Nostr e Blossom.

flower-cache: un server di cache Blossom locale

flower-cache è un server di cache Blossom locale, utile per i client che desiderano un mirror locale attivo del set di blob di un server Blossom remoto.

micro-vpn-ansible: playbook Ansible per il deployment VPN tramite NIP-34

micro-vpn-ansible è una piccola raccolta di playbook Ansible per il deployment di una micro VPN, ospitata come repository NIP-34.

Lavori sul protocollo

Aggiornamenti NIP

Un mercato dell’hashrate senza broker su Nostr (proposta bozza): Una bozza di NIP anonima che sostiene che gli attuali attori del mercato dell’hashrate sono broker custodiali che richiedono il KYC agli utenti. Propone un mercato P2P dell’hashrate sugli eventi Nostr.
Curated Feeds: un’alternativa più semplice ai feed DVM (proposta bozza): Sostiene che i DVM NIP-90 sono troppo pesanti per la curation semplice dei feed; propone eventi indirizzabili snelli con liste ordinate di ID evento.
Profile Colors: identità visiva deterministica (proposta bozza): Nuova bozza di NIP per derivare colori leggibili deterministici da una chiave pubblica Nostr per un’identità visiva coerente tra i client.
NIPs della traccia Namecoin: ancoraggio di identità, relay, TLS e reputazione (cluster di bozze): Un cluster di bozze di NIP che spostano i componenti dello stack Nostr in record ancorati a Namecoin.

Approfondimento NIP: NIP-34 (git stuff)

NIP-34 definisce i tipi di evento per ospitare repository git, patch, pull request, issue e stati di merge sui relay Nostr. Un repository è annunciato come evento indirizzabile di kind 30617. Le patch usano il kind 1617 che porta l’output di git format-patch. Le pull request usano il kind 1618. Le issue usano il kind 1621 con contenuto markdown. Gli eventi di stato fanno passare un thread tra Aperto (1630), Applicato/Unito o Risolto (1631), Chiuso (1632) e Bozza (1633). La notizia NIP-34 di questa settimana è la stessa del lancio di GitWorkshop v2 della settimana scorsa: il pulsante di merge della PR nel browser funziona perché i server GRASP, ngit e lo schema URL di clone nostr:// insieme chiudono il cerchio su una forge completamente decentralizzata.

Approfondimento NIP: NIP-53 (Live Activities)

NIP-53 definisce la superficie di eventi standard per le attività live su Nostr: stream live, spazi di meeting persistenti, eventi di conferenza programmati, presenza degli ascoltatori e chat live. Uno stream live è annunciato come evento indirizzabile di kind 30311. NIP-53 separa la stanza persistente dall’evento programmato che vi si tiene: un kind 30312 Meeting Space definisce una stanza, e un kind 30313 Conference Event rappresenta un meeting programmato o in corso in quella stanza. La superficie delle attività live di Nostr è intenzionalmente snella: NIP-53 annuncia l’attività, mentre altri NIP gestiscono le preoccupazioni adiacenti come i zap (NIP-57), gli obiettivi di zap (NIP-75) e le registrazioni video (NIP-71).

È tutto per questa settimana. Se state costruendo qualcosa o avete notizie da condividere, inviateci un DM su Nostr o trovateci su nostrcompass.org.

Nostr Compass #20

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

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

Questa settimana: GitWorkshop trasforma git-over-Nostr in una superficie di code review più completa con un pulsante di merge PR nel browser, Stars e following dei repository, un git explorer efficiente in banda, commenti di review inline di kind 1111 e stato delle notifiche cifrato multi-dispositivo. Routstrd lancia un daemon locale che scopre i provider di modelli tramite annunci Nostr di kind 38421 e li paga con Cashu. I rilasci tagged includono ngit v2.4.2, Wisp v1.0.0, grain v0.5.2 e v0.5.3, Mostro Core v0.10.0 e Mostro Mobile v1.2.5, marmot-ts v0.5.0, CruxCoach v0.1.3, Meiso v1.3.0, NoorNote, Nostria, Nostr Calendar, nos2x-fox, applesauce, nostr-double-ratchet e altro. Le modifiche non rilasciate coprono Amethyst Nests, nostream NIP-65 e NWC, il bootstrap udp:nat basato su Nostr di FIPS, l’osservabilità di strfry, le owner attestation di Sprout e i recipe pack di Zap Cooking. I nuovi progetti tracciati includono Nostrord, Clave, Treasures, smesh, Surveil, Fundstr, Nod City, deploy-nsite-to-pages e null–nostr. Il retrospettivo di fine mese copre gli April di Nostr dal 2021 al 2026.

Storie principali

GitWorkshop rilascia merge PR nel browser, following dei repository e un git explorer efficiente in banda

GitWorkshop, il layer di collaborazione basato sul web di Dan Conway per NIP-34 git-over-Nostr, ha rilasciato questa settimana una versione importante che avvicina il workflow molto di più a ciò che gli sviluppatori si aspettano da GitHub o GitLab, mantenendo commenti, elenchi di repository e notifiche all’interno di eventi Nostr firmati.

L’aggiunta principale è un tanto atteso pulsante di merge PR nel browser per i repository che usano relay GRASP. Il rilascio aggiunge anche Stars e following dei repository costruiti su reazioni ed elenchi NIP-51, con set di repository fissati pubblicati come eventi di kind 10617 che puntano ad annunci di repo di kind 30617 tramite tag a ordinati. Le pagine profilo possono ora presentare un elenco portatile di repository.

Un git explorer efficiente in banda sostituisce il precedente shallow clone nel browser. Il nuovo explorer si appoggia al sottostante protocollo client/server git su cui GRASP è costruito, quindi può gestire repository grandi senza forzare il browser a scaricare un pack completo. La ricerca copre ora nomi utente e metadati dei repository, alimentata da NIP-50 e da un’implementazione di relay ngit-indexer che scopre e sincronizza gli annunci di repository attraverso la rete. Un workflow di creazione di repository nel browser completa il percorso di scoperta e onboarding.

Gli strumenti di review sono ricostruiti attorno a una scheda Files Changed, un visualizzatore di diff per singola patch e un set di nuove primitive sperimentali. I commenti di code review inline usano kind 1111, costruito su NIP-22: ogni commento punta a un percorso file (tag f), a uno SHA di commit (tag c) e a un intervallo di righe selezionato (tag line), così un client può rendere il commento nella posizione corretta di un diff. Un secondo livello di primitive sperimentali è autorizzato per autori e manutentori dei repo e usa etichette NIP-32: rinominare il soggetto di un Issue o PR dopo la submission, aggiungere hashtag dopo la submission, fissare una CoverNote versionata in cima a un PR o Issue per un riepilogo modificabile e marcare come risolti i sottothread di discussione inline. Gli eventi Verdict e i blocchi suggestion restano in bozza e non sono ancora stati rilasciati.

Lo stato delle notifiche fra dispositivi è anch’esso sincronizzato tramite Nostr, ma con una svolta a tutela della privacy. GitWorkshop genera una keypair dedicata alle notifiche, cifra quella nsec e la memorizza dentro un evento di kind 30078. L’nsec di notifica firma poi gli effettivi eventi di stato delle notifiche. L’indirezione impedisce che il signer principale dell’utente venga bombardato da frequenti richieste di cifratura e decifratura per ogni azione di lettura o archiviazione, e impedisce agli osservatori esterni di vedere facilmente quando un utente tocca il proprio stato di notifica. Un utente può sincronizzare lo stato di lettura e archiviazione fra dispositivi; i relay vedono solo blob cifrati.

Routstrd lancia un router locale per l’inferenza su Nostr

Routstrd è un nuovo daemon TypeScript che offre agli strumenti locali un endpoint compatibile con OpenAI e instrada ogni richiesta a un provider Routstr concorrente. Il daemon scopre i provider tramite annunci Nostr di kind 38421 definiti nella spec RIP-02 di Routstr. Assegna poi un punteggio ai provider in base a prezzo, fiducia e performance recenti secondo RIP-06 e invia ogni richiesta all’opzione attualmente migliore.

Il pagamento passa attraverso un wallet Cashu locale gestito da cocod e finanziato con Lightning. Ciò offre al client un percorso di regolamento denominato in sats mantenendo la scoperta dei provider pubblica e permissionless attraverso i relay Nostr. Se un provider fallisce durante una sessione, Routstrd può ripiegare sul nodo classificato successivamente. Il percorso di installazione è bun install -g routstrd, seguito da routstrd onboard per la configurazione di wallet e relay.

La più ampia Routstr org mantiene il daemon, il software di nodo Python (routstr-core), una UI di chat e le specifiche di protocollo. Per gli utenti, la porta locale diventa l’interfaccia stabile: gli strumenti esistenti compatibili con OpenAI puntano a Routstrd, mentre il daemon gestisce scoperta dei provider, routing e pagamento.

Rilasci tagged

ngit v2.4.2 corregge la rilevazione del server GRASP per le submission di PR

ngit ha rilasciato v2.4.2 con una correzione per la rilevazione del server GRASP del repository, mantenendo la submission di PR sul percorso corretto quando una proposta usa il kind PR. Da notare che ngit attualmente imposta come default il kind Patch per la maggior parte delle modifiche, a meno che non siano grandi; il manutentore sta lavorando per cambiare il default. v2.4.1, rilasciata all’inizio della settimana, ha corretto errori fatal durante clone e fetch quando i dati git di un PR aperto non erano disponibili sui server git specificati per il repository.

Wisp v1.0.0 esce dalla beta

Wisp, un client Android in Kotlin e Jetpack Compose focalizzato su routing dei relay, privacy e una piccola UI nativa, ha rilasciato v1.0.0 seguita da v1.0.2. La milestone 1.0.0 raccoglie il toggle di denominazione fiat Normie Mode, il feed For You, la configurazione dei gruppi basata su relay NIP-29 e la trasmissione della relay-list NIP-65 trattate in Newsletter #19. v1.0.2 aggiunge il supporto Android 15 per page-size da 16 KB, una scheda di scansione QR nel drawer sheet, un pulsante di download per i controlli video inline e correzioni di performance per le liste di notifiche.

grain v0.5.2 risolve il lockup WebSocket, v0.5.3 continua le rifiniture

grain, il relay in Go di 0ceanSlim, ha rilasciato v0.5.2 come hotfix critico per un lockup WebSocket introdotto in v0.5.0, seguito poi da v0.5.3. Il lockup faceva bloccare le connessioni in alcuni percorsi di filter e WebSocket, quindi gli operatori su v0.5.1 o v0.5.0 dovrebbero aggiornarsi. grain traccia tutte le principali categorie di eventi Nostr, espone informazioni relay NIP-11, supporta controllo di accesso whitelist/blacklist, rate limit per kind, una dashboard web e una libreria client Go aggiunta nella linea v0.5.x.

Mostro Core v0.10.0 e Mostro Mobile v1.2.5 adottano il gift wrap NIP-59 a doppia chiave

Mostro Core v0.10.0 aggiunge il nuovo modulo gift-wrap NIP-59 con identità e chiavi di trade separate. Il codice di trasporto precedente usava una singola chiave di identità sia per l’identità del trade sia per il gift wrapping. v0.10.0 separa l’identità stabile del trade dalla chiave effimera di wrapping, così ogni trade può usare una chiave di trasporto fresca preservando l’identità necessaria al protocollo di trade. L’integrazione del daemon arriva tramite Mostro PR #718, e mostro-cli PR #165 porta la stessa migrazione al client a riga di comando.

Mostro Mobile v1.2.5 esce insieme al lavoro sul protocollo. PR #581 permette ai takers di filtrare le offerte in base all’età dell’account del maker, dando agli utenti un modo per evitare account maker appena creati nell’order book. PR #580 corregge le etichette di ruolo nei dettagli degli ordini cancellati, e PR #576 sistema i pulsanti di cancellazione cooperativa.

marmot-ts v0.5.0 rilascia i KeyPackage indirizzabili

marmot-ts ha rilasciato @internet-privacy/marmot-ts@0.5.0, la prima release con breaking-change pianificata per il client Marmot TypeScript. PR #68 aggiunge il supporto ai KeyPackage indirizzabili: KeyPackageManager può ora gestire sia i legacy eventi KeyPackage di kind 443 sia i nuovi di kind 30443. La release rimuove KeyPackageStore e le classi di storage dello stato di gruppo, sostituendole con store generici key-value passati a KeyPackageManager e MarmotGroup. Sposta inoltre la gestione di invite e gruppi su MarmotClient.invites e MarmotClient.groups, quindi chi incorpora direttamente ha bisogno di modifiche a costruttori e storage prima di aggiornare.

CruxCoach v0.1.3 rilascia il backup cifrato dei dati di arrampicata con Nostr e Blossom

CruxCoach è una nuova app Android open-source per scalatori di Kilter Board. La Kilter Board è una parete di allenamento interattiva le cui prese si illuminano via Bluetooth per mostrare le vie. L’app è stata lanciata il 14 aprile e ha raggiunto v0.1.3 il 26 aprile.

v0.1.3 aggiunge il backup cloud cifrato opzionale. L’account CruxCoach di un utente è una keypair Nostr, e la chiave privata funge anche da input per la chiave locale di cifratura del backup. L’app cifra i dati di arrampicata sul dispositivo e replica il ciphertext sui server di storage Blossom (blossom.primal.net e nostr.download). Le azioni di eliminazione remota chiamano il percorso di cleanup Blossom. Oltre al backup, CruxCoach usa il remote signing NIP-46 per il supporto Amber, i DM privati NIP-17 per il contatto in-app con lo sviluppatore, le relay-list NIP-65 per la scoperta dei relay e la libreria Quartz di Vitor Pamplona per la parte Nostr. Gli utenti possono installarla tramite Zapstore o APK Codeberg diretti.

Meiso v1.3.0 aggiunge sotto-attività, allegati Blossom e tagging NIP-89

Meiso è un task manager Flutter minimalista per Android che memorizza le attività come dati applicativi cifrati NIP-44 di kind 30078 sui relay Nostr. v1.3.0, rilasciata il 6 aprile, aggiunge sotto-attività con relazioni genitore/figlio, task link per blocks/blocked-by/related-to/duplicate-of, allegati immagine tramite Blossom ed endpoint di upload file HTTP NIP-96, un tag client di applicazione raccomandata NIP-89 sugli eventi pubblicati e uno strumento di sincronizzazione da riga di comando in Go. v1.3.0 corregge anche il comportamento del relay al cold-start e il riuso del client Amber.

NoorNote, Nostria, Nostr Calendar, nos2x-fox e rilasci di librerie

NoorNote ha pubblicato v0.8.7, v0.8.8 e v0.8.9. Queste release correggono la gestione del click di immagini e video nei repost citati, aggiungono il supporto lightbox per le immagini di articoli long-form e correggono la schermata di avvio desktop vuota. Nostria ha rilasciato v3.1.29, v3.1.30 e v3.1.31, aggiungendo la compressione delle immagini nell’editor di articoli, un toggle USD del wallet, controlli per le carte promozionali, il supporto PDF e rifiniture del layout mobile.

Nostr Calendar v1.4.1 disaccoppia la pubblicazione degli eventi del calendario dalla gestione della lista dei calendari e corregge il tracciamento degli inviti. nos2x-fox v1.19.0 aggiunge tempi di autorizzazione personalizzati per le grant di firma browser NIP-07 su Firefox. nostr-double-ratchet v0.0.97 rilascia nuovi binari. nostr-wot-sdk 0.9.0 monta NostrSessionProvider per impostazione predefinita, e nostr-tools PR #535 aggiunge il supporto al parsing multi-relay per le stringhe wallet-connect NIP-47.

A fine settimana, Amber v6.1.0-pre1 ha rilasciato una pre-release con un migliore layout di connessione di nuove app, correzioni al dialog del signer, gestione migliorata dei permessi di notifica e refactoring della selezione dell’account. nostr-vpn v0.3.14 ha rilasciato una build fresca con artefatti macOS Apple Silicon, Linux e Windows. Bitcredit Core v0.5.7-hotfix-1 e v0.5.8 hanno rilasciato correzioni consecutive per un problema di validazione dei blocchi orfani. Surveil v0.1.6 ha portato rifiniture UI mobile e una pagina About rivisitata; il progetto stesso è presentato più sotto.

applesauce 6.0.0 rimuove le vecchie event factory e aggiunge il parsing degli URI Blossom

applesauce, il toolkit Nostr TypeScript di hzrd149, ha rilasciato un treno di release 6.0.0 attraverso il monorepo. applesauce-core@6.0.0 rimuove la vecchia classe EventFactory e i vecchi helper buildEvent, modifyEvent e createEvent, spingendo i chiamanti verso le nuove classi factory in applesauce-core/factories e applesauce-common. Aggiunge anche la gestione di indirizzi IP e localhost al parsing dei link, espressioni regolari per URI Blossom BUD-10 e nuovi helper observable come timeoutWithIgnore, combineLatestBy, combineLatestByIndex e combineLatestByKey.

I rilasci a livello di pacchetto completano i pezzi specifici di Nostr. applesauce-content@6.0.0 aggiunge nodi URI Blossom BUD-10 per testo e Markdown, dando ai renderer un modo nativo di analizzare i riferimenti Blossom nel contenuto. applesauce-actions@6.0.0 aggiunge classi factory di base per le liste NIP-51 che coprono relay, utenti ed elementi, rendendo la costruzione di liste meno ad hoc. applesauce-wallet-connect@6.0.0 espone WalletConnect.connectURI, così le app possono accedere direttamente a un URI wallet-connect NIP-47 esistente.

Modifiche non rilasciate

Amethyst avanza le stanze audio Nests con i test di interop MoQ

Amethyst ha mergiato diverse PR focalizzate su Nests questa settimana, costruendo sullo stack di stanze audio Media over QUIC della scorsa settimana. PR #2622 aggiunge un harness di interop cross-client che esercita il client MoQ Amethyst contro l’implementazione web di riferimento. L’obiettivo è cogliere la divergenza a livello wire fra Android e browser prima che colpisca gli utenti. PR #2625 migliora il focus del parlante in picture-in-picture e lo stato della connessione, mentre PR #2620 chiarisce avatar, stato di mute e stato di parlante nella griglia dei partecipanti. A fine settimana, PR #2634 corregge il padding IME e gli window insets nella vista Nest a schermo intero e PR #2635 aggiunge il filtro di freschezza basato su presenza al feed Nests. Separatamente, PR #2627 rimuove l’implementazione C custom di secp256k1 di Amethyst e migra a libschnorr256k1.

nostream aggiunge il supporto alle relay list NIP-65 e ai pagamenti NWC

nostream ha mergiato tre PR notevoli dopo lo sprint da 53 PR della scorsa settimana. Il supporto ai metadati della relay list NIP-65 arriva in PR #585, così il relay può indicizzare e servire eventi di relay list di kind 10002. Un processore di pagamenti Nostr Wallet Connect segue in PR #539, aggiungendo un percorso pay-to-relay. La pulizia delle connessioni migliora in PR #438, che chiude un bug di connessioni morte in cui i socket con sottoscrizioni attive non venivano raccolti, causando la deriva dei conteggi delle sottoscrizioni sulle istanze long-running.

FIPS aggiunge il bootstrap udp:nat basato su Nostr

FIPS, il Free Internetworking Peering System coperto in precedenza in Newsletter #6 e Newsletter #10, ha mergiato PR #53 con il bootstrap udp:nat basato su Nostr. Il cambiamento consente ai nodi di pubblicare annunci Nostr, scambiare signaling offer/answer cifrato, scoprire indirizzi pubblici tramite STUN, eseguire hole punching UDP e consegnare il socket bucato al normale stack di trasporto FIPS. L’implementazione lega le identità del payload di signal all’effettivo sender Nostr, interroga i relay DM e advert configurati per il lookup della inbox e ripristina gli handoff di traversal adottati falliti così che i trasporti UDP orfani non restino vivi. Questo è il lavoro di annuncio Nostr e traversal NAT da tracciare nel repo canonico, jmcorgan/fips.

strfry aggiunge osservabilità per connessione

strfry ha mergiato PR #214, aggiungendo osservabilità per connessione e metriche a livello di connessione esportabili tramite Prometheus. PR #204 normalizza le etichette Prometheus, e PR #215 aggiunge una sezione Community Integrations alla documentazione che copre progetti di identità Namecoin costruiti sopra strfry.

Sprout aggiunge Owner Attestation e supporto multi-workspace

Sprout, il client Nostr di Block, ha mergiato PR #406 che implementa NIP-OA (Owner Attestation). La funzionalità dà a un agente autonomo una prova crittografica che una specifica pubkey umana ha autorizzato le sue azioni. PR #409 aggiunge il supporto multi-workspace all’app desktop, PR #411 aggiunge l’autocompletamento #channel al compose mobile, e PR #410 chiude una race window che poteva scartare messaggi di canale attivi. PR #413 introduce NIP-RS per la sincronizzazione dello stato di lettura cross-device, e le successive PR #420 e PR #422 collegano quello stato di lettura ai badge di non letti su mobile.

Zap Cooking ha mergiato una settimana produttiva di lavoro sulla pubblicazione di ricette. Le richieste di eliminazione NIP-09 per i Recipe Pack propri dell’utente arrivano in PR #367. L’affidabilità della pubblicazione migliora tramite PR #366, che forza ogni nuova ricetta sul relay garden e aggiunge una coda di retry per il recipe set condiviso. La pubblicazione one-click di pack redatti dall’autore arriva in PR #365, e PR #331 aggiunge il supporto al login via bunker NIP-46.

Whitenoise-rs cifra il proprio database locale

whitenoise-rs ha mergiato PR #758, aggiungendo la cifratura SQLCipher per il database Whitenoise su disco. Questo chiude un gap di sicurezza at-rest di vecchia data per lo stack del daemon Marmot. PR #775 espone le capability richieste del gruppo, PR #772 migra le operazioni sui media di gruppo a MediaOps di proprietà della sessione, e PR #773 estrae un holder SharedServices come parte del refactor delle session-ops. Sul lato mobile, whitenoise PR #577 abilita l’auto-riavvio al boot per il servizio foreground Android, correggendo il caso in cui il daemon non tornava dopo un riavvio del dispositivo.

Progetti tracciati e scoperti di recente

Nostrord: un client NIP-29 costruito con Kotlin Multiplatform e WASM

Nostrord è un nuovo client di group-chat NIP-29 che punta al caso d’uso di sostituto di Discord. I gruppi vivono su relay Nostr con membership, ruoli, moderazione e controllo di accesso applicati dal relay, quindi lo stato di gruppo è ospitato dal relay NIP-29 selezionato. Lo sviluppatore del client non controlla un database applicativo separato per quei gruppi. La web app gira su web.nostrord.com ed è costruita con Kotlin Multiplatform che compila in WebAssembly, con build native Android, iOS e desktop in sviluppo. Nostrord è un beneficiario di grant OpenSats e interopera con gli stessi relay NIP-29 usati da Flotilla, Chachi e 0xChat.

Clave porta il remote signing NIP-46 su iOS tramite APNs

Clave è un remote signer iOS in beta che firma eventi Nostr quando l’app non è aperta. La chiave privata resta nella Keychain dell’iPhone. Quando un client invia una richiesta di remote signing NIP-46, un proxy lato server consegna una Apple Push Notification, svegliando una Notification Service Extension per un massimo di 30 secondi. Quell’extension decifra la richiesta con la cifratura NIP-44, firma con la chiave della Keychain e pubblica la risposta. La registrazione del token del dispositivo usa l’HTTP Auth NIP-98 per impedire il dirottamento del token. Clave supporta il pairing bunker:// e nostrconnect://, livelli di fiducia per-client, override per-kind ed è stato testato con Nostur e noStrudel.

Treasures: geocaching decentralizzato su Nostr

Treasures è una piattaforma di geocaching in cui cache e ritrovamenti sono eventi Nostr firmati. I creatori di cache pubblicano eventi indirizzabili di kind 37516 con coordinate GPS. I finder registrano la scoperta scansionando un QR code attaccato alla cache fisica; il codice codifica la pubkey del creatore, il tag d della cache e una chiave privata di verifica usata come prova della visita fisica. Gli zap NIP-57 possono fluire dai finder ai creatori di cache, e l’app live è su treasures.to.

smesh v0.5.1: relay Nostr self-hosted, client e signer in uno stack unico

smesh è uno stack Nostr self-hosted scritto in Moxie, un linguaggio custom derivato da Go e TinyGo da mleku. Lo stack rilascia un binario relay nativo con supporto HTTP, WebSocket, AUTH, ricerca e Blossom; sm3sh, un web client compilato in moduli ES; e un’estensione browser signer con firma browser NIP-07 più supporto alla cifratura NIP-04 e NIP-44. Il lavoro recente include messaggistica di gruppo MLS (RFC 9420) in v0.5.0, riconciliazione di set negentropy per la sync dei relay e un engine di grafo Web of Trust. Il codice vive sulla forge self-hosted di mleku a git.smesh.lol, costruita con il suo strumento git-web. Il repo correlato gitea-nostr-auth è un bridge OAuth2/OIDC per Gitea: gli utenti si autenticano con un signer browser NIP-07, il bridge scopre i relay tramite NIP-65 e Gitea riceve claim di identità OIDC standard.

Surveil: un deck builder di Magic: The Gathering su Nostr

Surveil è un client Nostr per giocatori di Magic: The Gathering che consente agli utenti di cercare carte, costruire mazzi, scansionare carte cartacee su Android con OCR ML Kit on-device e condividere mazzi attraverso la rete. I mazzi sono pubblicati come eventi indirizzabili di kind 37381, e la spec dell’evento mazzo è documentata nel NIP.md del progetto. Il livello sociale è costruito da primitive Nostr standard: commenti threaded NIP-22 (kind 1111) associati a ogni mazzo, reazioni NIP-25 (kind 7), dati profilo NIP-78 (kind 30078) per le pagine dei giocatori, follow feed di kind 3 e fork che portano un tag a che riporta al mazzo originale. v0.1.6 è stato rilasciato questa settimana con rifiniture UI mobile, miglioramenti al life counter, una pagina About rivisitata e una relay pill sul banner hero del mazzo. La web app gira ovunque HTML statico sia servito, la build Android è distribuita tramite Zapstore, e gli eventi di kind 37381 sono anche indicizzati nativamente da Ditto come mazzi Magic. Il repo è su GitLab a chad.curtis/surveil.

Aggiunte minori: Fundstr, Nod City, deploy-nsite-to-pages e null–nostr

Fundstr è una piattaforma di finanziamento per creator su Nostr che usa Cashu ecash per pledge una tantum e ricorrenti, con definizioni di tier del creator e DM Nostr. Nod City è un sito di recensioni di servizi Bitcoin in cui le recensioni sono eventi Nostr firmati e i recensori possono ricevere zap; non è stato trovato un repo sorgente pubblico. deploy-nsite-to-pages è una GitHub Action che replica un nsite su GitHub Pages usando nsyte download, supportando nsite root di kind 15128 e named di kind 35128. null–nostr, scoperto anch’esso nei dati NIP-34 di questa settimana, è il client trattato nella recente ondata OpenSats come Nurunuru; supporta messaggistica di gruppo MLS, Amber, ricerca NIP-50, post protetti NIP-70, badge ProofMode e distribuzione Zapstore.

FIPS non è un progetto nuovo per Compass. È stato trattato in Newsletter #6 e Newsletter #10. Il database ora punta al repo canonico corretto, jmcorgan/fips, e la scoperta NIP-34 di questa settimana ha fatto emergere anche mirror git-over-Nostr correlati come fips e awesome-fips.

Lavoro di protocollo

Aggiornamenti NIP

Proposte e discussioni recenti nel repository NIPs:

Mergiate questa settimana:

NIP-34 git repositories: remove unused refs tag extension (PR #2325): Rimuove un’estensione di tag refs da NIP-34 che era definita ma non usata. La pulizia riduce l’ambiguità implementativa per gli strumenti git-over-Nostr.
NIP-34 git repositories: remove incorrect NIP-09 claim (PR #2326): Rimuove una dichiarazione errata secondo cui gli eventi di eliminazione NIP-09 possono resettare lo stato del repository. L’eliminazione NIP-09 è una richiesta di eliminazione evento lato client, non una macchina a stati del repository. La correzione impedisce agli implementatori NIP-34 di trattare gli hint di eliminazione come reset autoritativi del repo.

Lavoro aperto e guidato dalle implementazioni:

GitWorkshop kind 1111 commenti di review inline: Il kind di commento di code review inline è documentato nel NIP.md di GitWorkshop ed è ora in uso attivo, ma non è ancora stato proposto come NIP formale. Gli eventi Verdict (kind 7321) e i blocchi suggestion restano in bozza e non sono ancora stati rilasciati. Il feedback implementativo da GitWorkshop e ngit determinerà se le forme diventeranno un NIP git-review autonomo o resteranno una convenzione applicativa stratificata su NIP-34.
Nostr mail core e Nostrmon: Due nuove bozze di NIP custom hanno circolato questa settimana. Nostr mail core propone il kind 1301 per contenuti email RFC 2822, wrappati con NIP-59 per la consegna privata e ponte verso l’email legacy tramite pubkey di bridge risolte via NIP-05. Nostrmon delinea kind di eventi indirizzabili per regioni, mappe, creature, NPC, salvataggi giocatore e oggetti. Entrambe restano bozze custom, non NIP mergiati.
NIP-67: EOSE Completeness Hint (PR #2317): La proposta continua a iterare sull’aggiunta di un marcatore positivo di completezza a EOSE, permettendo ai relay di distinguere “eventi memorizzati consegnati integralmente” dai casi legacy EOSE in cui il relay non fa alcuna dichiarazione di completezza.

Sei April di Nostr

April dà una sezione trasversale pulita del percorso di sviluppo di Nostr: il documento di protocollo nel 2021, i primi lavori sui client nel 2022, l’ondata applicativa post-Damus nel 2023, la messaggistica privata e il lavoro git-over-Nostr nel 2024, Blossom e la pulizia della relay list nel 2025 e le grant focalizzate sull’adozione dei client nel 2026.

Aprile 2021: il documento di protocollo prima del repo NIPs

Fiatjaf ha pubblicato l’articolo originale su Nostr, “Notes and Other Stuff Transmitted by Relays”, il 20 novembre 2020. Quel primo testo conteneva già la forma centrale che ancora definisce il protocollo: gli utenti firmano eventi con chiavi, li pubblicano ai relay e leggono dai relay che scelgono. Il commit log di nostr-protocol/nostr mostra zero commit tra il 1° e il 30 aprile. L’attività si trova ai due lati: i commit di marzo 2021 hanno aggiunto i primi link “nostwitter” e un filtro kind, mentre quelli di maggio 2021 hanno riproposto NIP-02 e aggiunto la NIP authorship.

Nell’aprile 2021 non c’era un mercato client pubblico, nessuna rete di relay visibile, nessun repo NIPs. Il protocollo viveva ancora come un piccolo documento e pochi esperimenti. Nostr non era ancora diventato un social network o una piattaforma di sviluppo. Era ancora un modello relay/chiave/evento in attesa della sua prima ondata sostenuta di contributor.

Aprile 2022: i NIP vivevano ancora nel repo principale

L’aprile 2022 è stato l’ultimo mese prima che i NIP si spostassero fuori dal repo principale nostr-protocol/nostr. Poiché lo split non era ancora avvenuto, il repo dedicato nostr-protocol/nips non aveva storia di pull request in aprile. Nel repo principale, tre commit di aprile sono arrivati: “Update readme to add nip12” l'8 aprile di goswami1999, “add kinds list” il 25 aprile di jb55 e “add js formatting to sample code” il 28 aprile di steliosrammos.

Anche il lavoro sui client cominciava a prendere forma. I commit di Damus dell’aprile 2022 hanno aggiunto il primo comportamento chatroom, la gestione del profilo e le icone dell’app, mentre nostr-tools stava diventando il percorso di libreria JavaScript per i primi client ed esperimenti. Sul lato protocollo, le query di tag generiche NIP-12 hanno dato alla ricerca per tag un posto documentato, la kinds list ha spostato Nostr verso un modello a registry e migliori esempi JavaScript hanno reso la spec più facile da implementare per autori di client e librerie. Il 1° maggio, fiatjaf ha spostato i NIP nel repo dedicato. L’aprile 2022 è stato l’ultimo mese dell’era originale a repo unico.

Aprile 2023: espansione applicativa post-Damus

L’aprile 2023 è arrivato tre mesi dopo il lancio di Damus sull’App Store iOS del 31 gennaio 2023, e dopo che Jack Dorsey aveva postato la sua chiave pubblica Nostr. La rete aveva appena assorbito la sua prima grande ondata di crescita pubblica. Client come Damus, Snort, Iris, Coracle e Amethyst erano attivi, mentre gli operatori di relay stavano imparando cosa un social graph più grande faceva alle assunzioni su banda, spam, ricerca e moderazione.

L’aprile 2023 ha avuto una sola PR NIPs mergiata: PR #456, mergiata il 17 aprile, che aggiungeva link a entità bech32 NIP-19 alla gestione URI NIP-21. I commit circostanti mostrano la pressione applicativa dietro il lavoro di protocollo. L’aprile 2023 ha visto lavoro su NIP-45 COUNT, zap marker specifici per evento, NIP-15 marketplace, semantica di delegated delete NIP-26, file metadata NIP-94, gestione degli errori wallet-connect NIP-47 e NIP-30 custom emoji. La lista dei contributor si era allargata a includere fiatjaf, staab, pablof7z, Semisol, CodyTseng, sethforprivacy, mikedilger, AsaiToshiya, alexgleason, martindsq, frbittencourt e arkin0x.

Damus, Snort, Iris, Coracle e Amethyst non erano più demo attorno a una spec; erano client di produzione che affrontavano onboarding, feed, spam, zap, media e selezione dei relay. Il lavoro di protocollo dell’aprile 2023 si legge come il backlog che quei client hanno creato: zap, marketplace, file metadata, conteggio, emoji e link identitari hanno tutti spinto la spec oltre le semplici note e i semplici follow.

Aprile 2024: messaggistica privata, git-over-Nostr e supporto ai manutentori

L’aprile 2024 ha avuto due PR NIP mergiate. PR #1167, mergiata il 10 aprile, ha corretto terminologia confusa nel remote signing NIP-46, in cui client e signer hanno bisogno di linguaggio esatto per le azioni richieste e autorizzate. PR #1108, mergiata il 17 aprile, ha espanso i git repositories NIP-34 con eventi di stato, chiarimenti, manutentori opzionali, identificatori di repo e tag di discoverability. Quel passo ha reso git-over-Nostr più pratico per ngit e in seguito GitWorkshop.

NIP-17, precedentemente NIP-24, è atterrato il 24 aprile come messaggi sigillati e gift-wrapped per DM privati e piccole chat di gruppo. Il lavoro su client e librerie ha corso in parallelo: Amethyst, Primal, Gossip, nostr-tools, NDK e rust-nostr erano tutti attivi nello stesso periodo.

OpenSats ha anche annunciato supporto a lungo termine per gli sviluppatori Nostr nell’aprile 2024: PabloF7z il 9 aprile, Stuart Bowman il 12 aprile e hzrd149 il 15 aprile. Quelle grant hanno spostato il finanziamento dalle grant di progetto isolate verso la manutenzione sostenuta di relay, librerie e infrastruttura client.

Aprile 2025: pulizia densa dei NIP e formalizzazione di Blossom

L’aprile 2025 è stato il mese di protocollo più denso in questo retrospettivo, con sedici PR NIPs mergiate. Il mese è iniziato con PR #1846, che ha aggiunto transazioni e indirizzi blockchain a NIP-73, e PR #1865, che ha aggiunto i tag NIP-C0 alla tabella dei tag standardizzati. È continuato con PR #1801 e PR #1889, entrambe migliorativi delle indicazioni di ripubblicazione della relay list di kind 10002, e PR #1879, che ha ridotto e chiarito NIP-65.

PR #1822 ha aggiunto NIP-B7 per l’interazione Blossom, dando ai client Nostr e ai server Blossom un layer di coordinamento canonico dopo più di un anno di pratica informale. PR #1051 ha deprecato NIP-26, la spec di firma evento delegata. NIP-26 era stato difficile da implementare in modo sicuro ed era diventato meno attraente man mano che NIP-46 e altri pattern di signer maturavano.

Il resto del mese ha combinato pulizia con espansione applicativa: PR #1882 ha aggiunto campi di privacy policy e terms of service a NIP-11, PR #1849 ha espanso i bookmark web di kind 39701 sotto NIP-B0, PR #1891 ha aggiunto quel kind di bookmark al README, e PR #1895 ha aggiunto tag standardizzati NIP-B0. OpenSats ha annunciato la sua Eleventh Wave of Nostr Grants il 16 aprile, finanziando Swae, HAMSTR, Vertex, Nostr Double Ratchet e Nostr Game Engine. Primal, Coracle, noStrudel, nostr-tools, NDK e rust-nostr stavano anch’essi rilasciando in questo periodo, quindi la pulizia del protocollo si è affiancata al lavoro attivo su client e librerie.

Aprile 2026: hardening di NIP-34, badge e grant focalizzate sull’adozione

L’aprile 2026, il mese con cui si chiude questo numero, ha avuto quattro PR NIPs mergiate. La prima è stata PR #2276, mergiata il 1° aprile, che ha modificato i badge profilo NIP-58 al kind 10008 e aggiunto set di badge di kind 30008, rendendo l’assegnazione dei badge e le collezioni di badge più componibili. Un secondo cambiamento di usabilità git-over-Nostr è arrivato in PR #2312, mergiata il 10 aprile, che ha aggiunto la semantica URL di clone nostr:// a NIP-34. Le pulizie del 25 aprile, PR #2325 e PR #2326, hanno rimosso linguaggio NIP-34 inutilizzato e scorretto.

I commit correlati affilano le stesse superfici. Il 22 aprile, fiatjaf ha aggiunto una lista di server Blossom a NIP-51 e regolato l’editing dei metadati NIP-29 per corrispondere al comportamento PUT-style di Flotilla. Il 26 aprile, ha rinominato NIP-5A per chiarezza. L’aprile 2026 si è concentrato sul rendere superfici di protocollo già usate più facili da implementare e più difficili da fraintendere.

OpenSats ha annunciato la sua Sixteenth Wave of Nostr Grants l'8 aprile, sostenendo Amethyst Desktop, Nostr Mail, Nostrord, Nurunuru (null–nostr) e un rinnovo HAMSTR: client desktop, messaggistica email-like, UX di gruppo, onboarding giapponese e connettività off-grid.

Grazie per aver letto Nostr Compass #20. Mandateci un DM su Nostr con suggerimenti, correzioni o nuovi progetti da coprire.

Nostr Compass #19

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

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

Questa settimana: Amethyst chiude un grande ciclo di lavoro su Marmot, communities NIP-72, zap goals NIP-75 e audio rooms basate su Media over QUIC. TollGate stabilizza l’accesso Internet pay-per-use su Nostr e Cashu con v0.1.0. nostream completa una settimana di lavoro relay attorno a NIP-45, NIP-62, compressione, hardening delle query e piena parità con NIP-11. Forgesworn pubblica un intero stack per firma, identità e API a pagamento su Nostr. ShockWallet continua a spingere flussi Lightning nativi su Nostr. Il gruppo Formstr porta avanti 26 PR tra hardening di sicurezza e supporto RRULE. StableKraft, Keep, topaz, WoT Relay, Flotilla e NipLock completano la lista delle release. Gli approfondimenti di questa settimana coprono NIP-72 e NIP-57.

Shipping This Week

Primal Android ships Explore tab, NIP-05 verification, and audio player

Primal Android ha unito 11 PR sopra il redesign del feed della settimana scorsa. PR #1021 introduce una nuova tab Explore costruita su utenti popolari, follow packs e curated feeds, PR #1015 aggiunge un editor dei feed che si prepopola dalla DSL Advanced Search di Primal, PR #994 porta la UI di verifica NIP-05 e PR #997 integra un audio player inline nei feed. PR #1018 aggiunge anche il pairing nostr-connect NIP-46 dal wallet QR scanner.

strfry adds Prometheus write-path metrics and fixes NIP-42 AUTH envelope

strfry ha pubblicato un gruppo di miglioramenti orientati agli operatori. PR #194 aggiunge un exporter Prometheus dedicato per le metriche del write path, PR #197 registra byte e compressione per connessione e PR #192 rende configurabile a runtime il limite dei tag nei filtri. Sul piano della correttezza del protocollo, PR #201 cambia le risposte di fallimento AUTH NIP-42 da NOTICE all’envelope OK previsto dalla specifica.

Shopstr hardens storefront security across 13 PRs

Shopstr, client marketplace su Nostr, ha unito 13 PR dominate da fix di sicurezza. PR #434 chiude un hole di stored JavaScript nei link delle storefront, PR #417 fa escaping dell’HTML delle policy per bloccare XSS riflesso, PR #418 chiude un’API di cancellazione eventi cached non autenticata e PR #433, PR #419, PR #435 e PR #414 rafforzano letture, mutazioni ed endpoint sensibili.

Nostria v3.1.26 through v3.1.28 add background music playback on Android

Nostria ha pubblicato sei release da v3.1.22 a v3.1.28. La novità principale di v3.1.26 è la riproduzione musicale in background su Android, con controlli media nella notification bar e nella lock screen. Le release successive rafforzano questo nuovo media-service surface.

Wisp v0.18.0-beta adds Normie Mode, For You feed, and NIP-29 group config

Wisp, client Android in Kotlin e Jetpack Compose di barrydeen, ha pubblicato v0.18.0-beta il 16 aprile. PR #462 aggiunge una Normie Mode con importi fiat-denominati, PR #464 rinnova l’onboarding e PR #469 introduce un feed For You. Sul lato protocollo, PR #471 aggiunge la configurazione dei gruppi NIP-29 e PR #478 corregge il flusso AUTH NIP-42 prima degli eventi amministrativi di gruppo. PR #481 inoltra anche le note agli inbox relay NIP-65 delle pubkey menzionate.

NoorNote v0.8.4 adds Scheduled Posts and live stream zapping

NoorNote ha pubblicato v0.8.4 e v0.8.5. La novità principale della v0.8.4 è Scheduled Posts: l’app consegna un evento già firmato a un relay gestito da NoorNote che lo pubblica al momento pianificato, cosi le chiavi private non lasciano mai il dispositivo. La stessa release aggiunge zapping con un tocco dalle card dei live stream, dove i sats compaiono nell’overlay chat via NIP-53. La v0.8.5 corregge un bug di deduplicazione della timeline.

topaz v0.0.2 ships a Nostr relay for Android

topaz, nuovo relay Nostr che gira su telefoni Android creato da fiatjaf, ha pubblicato v0.0.2 il 17 aprile. Il progetto è Kotlin-first e punta a trasformare il telefono in un relay personale sempre disponibile. Per ora l’obiettivo è stretto: un relay funzionante in un pacchetto Android installabile.

StableKraft v1.0.0 ships the first stable music-and-podcast PWA release

StableKraft è una PWA Next.js per scoprire, organizzare e ascoltare musica prelevata dai feed podcast, con Nostr per auth e funzioni social e Lightning per i pagamenti V4V. Ha raggiunto v1.0.0 il 18 aprile. Nella stessa settimana il progetto ha stretto l’ingestion dei feed con una cache OPML di 15 minuti e la rimozione di XML illegale, e ha ridotto la finestra di reparse notturna da 720 ore a 24 ore per permettere ai feed aggiunti di recente di autoripararsi più in fretta.

NipLock ships a NIP-17-based password manager

NipLock è un password manager che memorizza e sincronizza credenziali tra dispositivi usando messaggi diretti gift-wrapped NIP-17. Ogni voce password è un DM NIP-17 dall’utente verso se stesso, cosi gli stessi eventi si replicano su qualunque dispositivo si autentichi con la stessa chiave. La firma funziona con nsec raw, estensioni browser come nos2x o Amber via NIP-46.

flotilla-budabit polishes its NIP-34 repo surface

Il fork della comunità Budabit di Flotilla, flotilla-budabit, ha pubblicato un gruppo di fix per il proprio workflow git-over-nostr NIP-34. Gli aggiornamenti ripristinano i controlli per la discussione dei repository, mantengono visibili le sticky repo tabs sulle pagine dettaglio, caricano gli annunci repo dai relay GRASP salvati e tengono sincronizzato lo stato delle patch applicate dai maintainer.

rx-nostr 3.7.2 through 3.7.4 add default verifier and optional constructor args

rx-nostr, libreria Nostr basata su RxJS, ha pubblicato 3.7.2, 3.7.3 e 3.7.4. PR #192 aggiunge un verificatore Schnorr predefinito e PR #195 rende opzionali gli argomenti di createRxNostr() per integrazioni rapide a configurazione zero.

Keep Android v1.0.0 ships with reproducible builds and zero trackers

Keep, gestore di password e segreti nativo Nostr, ha pubblicato v1.0.0 il 21 aprile dopo una serie di PR di hardening. PR #241 aggiunge una recipe per build riproducibili, PR #248 sostituisce Google ML Kit con ZXing per rimuovere la dipendenza da Google Play Services, PR #252 pubblica una scansione Exodus Privacy che mostra zero tracker e PR #256 aggiunge un file zapstore.yaml per la distribuzione tramite zapstore.

Flotilla 1.7.3 and 1.7.4 add kind-9 wrapping for richer NIP-29 rooms

Flotilla, client per gruppi NIP-29 di hodlbod, ha pubblicato 1.7.3 e 1.7.4. Il cambiamento di protocollo principale è il wrapping dei tipi di contenuto non-chat dentro eventi kind 9, annunciato nel release note di hodlbod e collegato a PR #2310. Questo permette di preservare il contesto della stanza quando eventi come poll o calendario vengono inviati nel gruppo.

WoT Relay v0.2.1 migrates eventstore to LMDB

WoT Relay, relay filtrato tramite web of trust di bitvora, ha pubblicato v0.2.1 il 22 aprile. PR #97 migra l’eventstore a LMDB, PR #99 aggiorna golang.org/x/crypto e PR #100 aggiorna URL software e stringa versione in NIP-11.

Formstr suite: Pollerama security pass, Forms i18n, Calendar RRULE support

La suite Formstr ha unito 26 PR tra Pollerama, Formstr Forms e Nostr Calendar, con un tema chiaro di sicurezza sul lato poll e avanzamento funzionale sul resto.

Pollerama, l’app nostr-polls, rafforza la gestione delle chiavi. PR #182 scade i DM in cache al logout, PR #175 sposta la chiave locale in uno storage browser più sicuro e PR #171 protegge JSON.parse del contenuto profilo kind 0 in tutti i percorsi di login. PR #186 aggiunge deep linking HTTPS e PR #169 rende cliccabili i nomi degli autori nei risultati.

Formstr, suite nostr-forms, amplia la superficie di input e onboarding. PR #475 aggiunge supporto a URL audio e video, PR #439 introduce i18n, PR #466 aggiunge un importatore da Google Forms e PR #463 rimuove log sensibili dal browser console.

Nostr Calendar by Formstr ha pubblicato v1.3.0 e v1.4.0. PR #107 aggiunge supporto multiplo e personalizzato a RRULE, PR #101 interpreta come UTC le floating RRULE date secondo RFC 5545, PR #97 permette di aggiungere eventi condivisi al proprio calendario, PR #86 introduce preferenze di notifica per lista e PR #112 rinnova login e loading path. Tutti e tre i progetti si basano sugli eventi calendario NIP-52.

Also shipped: notedeck, nostr.blue, cliprelay, Captain’s Log

Alcuni client hanno pubblicato release iterative senza una singola headline dominante. notedeck ha pubblicato v0.10.0-beta.4 con fix su rendering a colonne e relay pool. nostr.blue v0.8.6 aggiorna Dioxus e sblocca la build Android. cliprelay ha pubblicato Desktop v0.0.3 e Android v0.0.4, stringendo il loop di sync. Captain’s Log ha pubblicato tre build alpha che aggiungono il rilevamento della liveness dei sync relay.

In Development

whitenoise-rs refactors to session-scoped account views

whitenoise-rs, il daemon Rust sotto il client Marmot, ha unito 15 PR per una refactor multi-fase che sposta la logica da singleton globali a viste per-account AccountSession. L’obiettivo è scomporre un monolite condiviso in superfici più piccole, più facili da comprendere, testare ed evolvere senza effetti collaterali tra account diversi.

La base arriva con PR #743 e PR #753, seguite dallo spostamento di draft, settings, operazioni messaggi, lettura e scrittura di gruppo, membership, notifiche push, letture dei key package e creazione dei gruppi nelle PR successive. PR #770 chiude il giro reindirizzando il dispatch degli eventi sulla sessione, cosi ogni account consuma il proprio traffico relay senza contesa.

White Noise app adds block/unblock UI, leave-group, and offline notices

White Noise, client Marmot, aggiunge i controlli mancanti sul ciclo di vita dei gruppi. PR #578 pubblica la UI per block e unblock sopra l’hook introdotto in PR #573, PR #571 e PR #572 collegano clear_chat, delete_chat e leave_and_delete_group dal lato Rust all’app, e PR #569 insieme a PR #576 aggiungono avvisi offline nelle schermate chat e impostazioni. PR #585 restringe inoltre la cancellazione da “all key packages” a “legacy key packages”.

MDK adds mixed-version invite support and SelfUpdate convergence

MDK, il Marmot Development Kit, ha unito sette PR. La linea comune è la compatibilità tra versioni vicine, mantenendo i client in grado di invitarsi a vicenda, ruotare il proprio stato e recuperare da input malformati.

PR #261 calcola le RequiredCapabilities di un gruppo come LCD delle capability degli invitati e sblocca inviti tra Amethyst e White Noise. PR #264 converge il formato wire di SelfUpdate tra implementazioni, PR #262 valida i key package degli invitati prima di persistere il signer del creatore, PR #256 corregge la validazione della depletion admin lato ricevente, PR #259 protegge lo stato in-memory critico e PR #265 espone un accessor group_required_proposals.

nostter adds NIP-44 encryption across people lists, bookmarks, and mutes

nostter ha unito 10 PR. PR #2088 aggiunge cifratura NIP-44 alle mute list, PR #2089 la aggiunge ai bookmark e PR #2090 alle people list, migrando dove possibile da NIP-04. PR #2087 rimuove anche un vecchio percorso di migrazione per le mute kind 30000.

zap.cooking ships Nourish scoring and a reusable comment thread

zap.cooking, client Nostr per ricette, ha unito 20 PR. La novità principale è un modulo Nourish per il punteggio nutrizionale delle ricette nelle PR #317 e PR #319. Accanto a questo, una refactor in quattro fasi da PR #299 a PR #302 estrae il modulo Comments in un CommentThread riutilizzabile.

ridestr extracts shared rider coordinator

ridestr, app di ride-sharing decentralizzata, ha unito 10 PR che rifattorizzano le schermate Compose in componenti più focalizzati ed estraggono la logica di protocollo per rider e driver in un modulo coordinatore condiviso :common. PR #60 aggiunge anche un ricevitore kind 3189 lato Roadflare.

Blossom drafts a BUD-01 Sunset header for blob expiration

Blossom, protocollo di hzrd149 per la memorizzazione di blob su server HTTP indicizzati da hash SHA-256, ha aperto PR #99 per aggiungere un header Sunset a BUD-01. Il server potrebbe usarlo per pubblicizzare un timestamp futuro dopo il quale un blob non sarà più servito, permettendo ai client di pianificare in anticipo invece di scoprire la scadenza solo con un 404.

New Projects

Forgesworn publishes a 29-repo cryptographic toolkit for Nostr

Forgesworn ha pubblicato 29 repository open source in cinque giorni, coprendo firma, identità, attestazioni, web of trust e discovery di API a pagamento su Nostr.

Lo stack di firma ruota attorno a nsec-tree, schema deterministico di derivazione di sotto-identità che trasforma un master secret in identità Nostr illimitate e non collegabili, e a Heartwood, signer remoto NIP-46 che gira su Raspberry Pi con Tor attivo per default. Sapwood aggiunge una UI di gestione web, heartwood-esp32 porta lo stesso approccio su una board Heltec WiFi LoRa 32 e nsec-tree-cli espone i flussi di derivazione, prova e recupero Shamir.

Sul lato identità e fiducia, Signet arriva a v1.6.0 come protocollo di verifica dell’identità decentralizzata per Nostr, nostr-attestations definisce un singolo evento kind 31000 per credential, endorsement, provenance e trust, e nostr-veil costruisce sopra un web of trust privacy-preserving con firme di anello LSAG su secp256k1.

Sul lato monetizzazione, toll-booth è un middleware L402 per Express, Hono, Deno, Bun e Cloudflare Workers che trasforma una API in un toll booth Lightning in una riga. toll-booth-dvm espone la API protetta come DVM NIP-90, toll-booth-announce la collega a 402-announce, che pubblica eventi parameterized replaceable kind 31402 per la discovery di servizi HTTP 402 su Nostr, e 402-indexer indicizza questi annunci. L’organizzazione pubblica anche una collezione di 29 draft NIP.

ShockWallet ships Nostr-native Lightning wallet sync and multi-node connections

ShockWallet è un wallet Lightning che usa Nostr come trasporto per connettersi a nodi Lightning self-custodial. L’app si accoppia a uno o più nodi Lightning.Pub tramite un nprofile, poi firma le autorizzazioni di pagamento end-to-end tra wallet e nodo. Il team ha pubblicato PR #608 il 18 aprile con un pass UI sulla dashboard dei canali, accanto a un flusso QR con admin-invite-link per nuovi utenti PUB (PR #606) e un fix di leggibilità della dashboard metriche (PR #607).

ShockWallet usa gli eventi dati specifici per applicazione di NIP-78 per la sincronizzazione multi-device dello stato del wallet, cosi la vista del wallet resta coerente tra browser desktop e telefono senza server centralizzato. Questo lo colloca un livello sotto NIP-47: NIP-47 è l’interfaccia che un’app usa per chiedere a un wallet esistente di pagare, mentre ShockWallet usa Nostr come trasporto dell’account e della sessione del wallet verso il nodo Lightning sottostante.

Nostrability issues migrate to git over Nostr after GitHub censorship

Nostrability, il tracker di interoperabilità di elsat per client e relay Nostr, sta spostando il proprio workflow issue su git over Nostr dopo la rimozione dell’organizzazione Nostrability da GitHub. Il tracker migrato ora vive su GitWorkshop/ngit, dove i problemi esistenti sono già stati trasferiti e i futuri report di interoperabilità possono restare dentro un’infrastruttura nativa Nostr.

nowhere encodes full websites into URL fragments and routes orders through Nostr

nowhere è un nuovo progetto AGPL-3.0 di 5t34k che serializza un intero sito nel frammento URL dopo #, lo comprime con sostituzione di dizionario e raw DEFLATE e lo codifica in base64url. Poiché HTTP vieta al browser di inviare i frammenti al server, l’host che consegna la pagina non vede mai il contenuto e il sito stesso non viene memorizzato su un server. Il progetto include otto tipi di sito, cinque completamente statici e tre che usano relay Nostr per ordini, post e firme con chiavi effimere e cifratura NIP-44.

Small new surfaces: relayk.it and Brainstorm Search

Due progetti piccoli meritano una menzione rapida. relayk.it, costruito da sam del team Soapbox, è un client per la discovery di relay costruito con Shakespeare che gira interamente nel browser. Brainstorm Search arriva come interfaccia di ricerca Nostr single-page focalizzata sull’emersione di contenuti attraverso la rete.

Protocol and Spec Work

NIP Updates

Proposte e discussioni recenti nel repository NIPs:

Open PRs and Discussions:

NIP-67: EOSE Completeness Hint (PR #2317): propone un terzo elemento facoltativo nel messaggio EOSE di NIP-01 per indicare se il relay ha davvero consegnato tutti gli eventi memorizzati che corrispondono al filtro.
NIP-5D: Nostr Applets (PR #2303): propone un nuovo kind per distribuire applet interattive su Nostr, tra NIP-5A per siti statici e NIP-5C per scroll WASM.
NIP-29: Subgroups spec (PR #2319): estende NIP-29 con una gerarchia di sottogruppi, cosi un singolo gruppo può ospitare più canali paralleli senza creare gruppi indipendenti.
NIP-29: Explicit role permissions on kind 39003 (PR #2316): definisce uno schema esplicito dei permessi nei ruoli kind 39003, rendendo leggibili a client e utenti i poteri effettivi di un ruolo come moderator.
NIP-11: access_control field for gated-relay discovery (PR #2318): aggiunge un oggetto access_control facoltativo a NIP-11 per descrivere il modello di accesso del relay.
NIP-63a: Minimal Payment Gateway Descriptor (PR #2315): continua a iterare sulla forma dell’evento kind 10164 e sul layout dei campi per regole di subscription per livello.
NIP-XX: Agent Reputation Attestations (Kind 30085) (PR #2320): propone un evento addressable kind 30085 per attestazioni firmate su agenti e servizi autonomi in Nostr, con punteggi, evidenze e supporto ai mercati NIP-90.
NIP-TPLD: Transient Private Location Data (PR #2309): prosegue il lavoro sul kind 20411, sulla forma di cifratura NIP-44 per destinatario e sulla semantica del tag ttl.
marmot-ts 0.5.0 release PR (PR #70): la PR di release per @internet-privacy/marmot-ts@0.5.0 include i primi breaking changes pianificati nel client TypeScript Marmot.

NIP Deep Dive: NIP-72 (Moderated Communities)

NIP-72 definisce un modello di community tematiche su Nostr in cui i moderator curano una vista di lettura sopra scritture altrimenti non ristrette. Diversamente dai gruppi basati su relay di NIP-29, una community NIP-72 vive in eventi Nostr ordinari e qualunque relay che porti i kind rilevanti può servirla. Chiunque può pubblicare in una community, ma solo i post approvati da un moderator riconosciuto compaiono nel feed della community.

Una community è definita da un evento addressable kind 34550 pubblicato dal suo creatore. Il tag d è lo slug stabile della community, i tag name, description, image e rules portano i metadati di presentazione, e una serie di tag p marcati moderator elenca le pubkey i cui approval contano. Tag relay facoltativi con marker author, requests o approvals suggeriscono dove pubblicare e recuperare ciascun tipo di evento:

{
 "id": "f1e2d3c4b5a69788f1e2d3c4b5a69788f1e2d3c4b5a69788f1e2d3c4b5a69788",
 "pubkey": "c3d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8a7b6c5d4e3f2a1b0c9d8e7f6a5b4c3d2",
 "created_at": 1745280000,
 "kind": 34550,
 "tags": [
 ["d", "bitcoin-devs"],
 ["name", "Bitcoin Devs"],
 ["description", "A moderated community for Bitcoin protocol discussion."],
 ["image", "https://example.com/bitcoin-devs.png"],
 ["rules", "Stay on topic. Cite code or specs when possible."],
 ["p", "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876", "", "moderator"],
 ["p", "a1b2c3d4e5f6a7b8c9d0a1b2c3d4e5f6a7b8c9d0a1b2c3d4e5f6a7b8c9d0a1b2", "", "moderator"],
 ["relay", "wss://relay.example.com", "author"],
 ["relay", "wss://relay.moderator.com", "approvals"]
 ],
 "content": "",
 "sig": "aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899"
}

Un utente invia un post pubblicando un normale evento Nostr e aggiungendo un tag a con coordinata 34550:<creator_pubkey>:<slug>. L’approvazione è un evento separato kind 4549 pubblicato da un moderator. Questo evento riferisce il post tramite tag e, il submitter tramite tag p e la community tramite tag a, e inserisce nel content una copia stringified dell’evento inviato. Questo mantiene renderizzabile il post approvato anche se l’autore originale elimina in seguito l’evento sorgente.

{
 "id": "a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3",
 "pubkey": "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876",
 "created_at": 1745283600,
 "kind": 4549,
 "tags": [
 ["a", "34550:c3d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8a7b6c5d4e3f2a1b0c9d8e7f6a5b4c3d2:bitcoin-devs"],
 ["e", "b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4"],
 ["p", "e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5"],
 ["k", "1"]
 ],
 "content": "{\"id\":\"b3c4d5e6...\",\"pubkey\":\"e4f5a6b7...\",\"kind\":1,\"content\":\"Question about sighash flags\",\"tags\":[[\"a\",\"34550:c3d2e1f0...:bitcoin-devs\"]],\"created_at\":1745283500,\"sig\":\"...\"}",
 "sig": "bbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aa"
}

Il modello di approvazione ha tre proprietà utili. La moderazione è trasparente, perché ogni approval è un evento Nostr firmato che chiunque può recuperare e verificare. Non è esclusiva, perché lo stesso post può essere approvato da community diverse. Ed è reversibile al livello di lettura, perché se una community rimuove un moderator dal suo evento kind 34550, le approvazioni precedenti di quel moderator smettono di contare per i client che rispettano la lista corrente dei moderator.

Il lato lettura è il punto in cui i client divergono. Molti client community-aware renderizzano il feed filtrando gli eventi kind 4549 taggati con la coordinata della community, deduplicando per ID dell’evento sottostante e poi renderizzando il post embedded. Alcuni recuperano anche direttamente i submission event e usano gli approval solo come whitelist. Client come noStrudel e, da questa settimana, Amethyst via PR #2468, espongono anche la coda dei post pendenti ai moderator. Rispetto a NIP-29, il compromesso è chiaro: NIP-72 è più portabile e forkabile, mentre NIP-29 è più adatto quando spam e post non approvati devono restare del tutto fuori dal wire.

NIP Deep Dive: NIP-57 (Zaps)

NIP-57 definisce gli zaps, un modo per collegare pagamenti Lightning a identità ed eventi Nostr e pubblicare una ricevuta verificabile del pagamento sui relay. Uno zap prova che un determinato mittente ha pagato un determinato importo a un destinatario specifico per un target specifico, e la prova è leggibile da qualunque client Nostr senza doversi fidare della parola del mittente. La specifica attraversa LNURL, Lightning e Nostr e fissa come devono cooperare.

Il flusso coinvolge quattro attori. Il client del mittente scopre l’endpoint LNURL del destinatario dai metadati profilo kind 0 (lud06 o lud16) o da un tag zap sull’evento da zappare. Quel client firma poi un evento zap request kind 9734 che descrive il pagamento desiderato e lo invia al callback LNURL del destinatario, non ai relay. Dall’altra parte, il server LNURL del destinatario valida la richiesta, restituisce una invoice Lightning il cui description hash si impegna alla richiesta stringified e, una volta pagata la invoice, pubblica una ricevuta kind 9735 sull’insieme di relay richiesto dal mittente.

Una zap request kind 9734 contiene un tag p con la pubkey del destinatario, opzionalmente un tag e o a che identifica il contenuto da finanziare, un tag amount in millisats, un tag relays che elenca dove pubblicare la ricevuta e un tag k che registra il kind del target:

{
 "id": "c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2",
 "pubkey": "a5b4c3d2e1f09876a5b4c3d2e1f09876a5b4c3d2e1f09876a5b4c3d2e1f09876",
 "created_at": 1745280000,
 "kind": 9734,
 "tags": [
 ["p", "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876"],
 ["e", "b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4"],
 ["amount", "21000"],
 ["relays", "wss://relay.damus.io", "wss://nos.lol", "wss://relay.nostr.band"],
 ["k", "1"]
 ],
 "content": "great post",
 "sig": "ccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbcc"
}

La ricevuta zap kind 9735 viene pubblicata dal wallet server del destinatario dopo la conferma del pagamento. Non è firmata dal mittente ma dal wallet server usando la nostrPubkey pubblicizzata nella risposta LNURL. Una ricevuta valida porta la richiesta zap stringified nel tag description, la invoice pagata nel tag bolt11 e un tag preimage che prova il settlement:

{
 "id": "d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3",
 "pubkey": "e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0",
 "created_at": 1745280060,
 "kind": 9735,
 "tags": [
 ["p", "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876"],
 ["P", "a5b4c3d2e1f09876a5b4c3d2e1f09876a5b4c3d2e1f09876a5b4c3d2e1f09876"],
 ["e", "b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4"],
 ["bolt11", "lnbc210n1pj...bolt11invoicestring"],
 ["description", "{\"id\":\"c1d2e3f4...\",\"pubkey\":\"a5b4c3d2...\",\"kind\":9734,\"content\":\"great post\",\"tags\":[...]}"],
 ["preimage", "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef"]
 ],
 "content": "",
 "sig": "ddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccdd"
}

La regola di validazione è il cuore delle garanzie di NIP-57. Un client che mostra una ricevuta kind 9735 come zap dovrebbe verificare quattro cose: che la firma della ricevuta corrisponda alla nostrPubkey annunciata nella risposta LNURL, che l’importo della invoice bolt11 corrisponda al tag amount nella richiesta embedded, che il description hash della invoice si impegni alla richiesta zap stringified e che il preimage faccia hash al payment_hash della invoice. Una ricevuta che fallisce uno di questi controlli è solo una dichiarazione di pagamento, non una prova.

I private zaps aggiungono riservatezza. Il mittente può cifrare il content della richiesta per il destinatario e includere un tag anon, cosi la rete relay vede il target del pagamento ma non legge la nota allegata. Alcuni client fanno un passo in più e generano una coppia di chiavi effimera per la richiesta stessa, cosi la ricevuta continua a provare che il pagamento è avvenuto ma il destinatario non può ricollegare lo zap alla pubkey di lunga durata del mittente.

NIP-57 sostiene anche il sistema di zap goals di NIP-75. Un goal è un evento kind 9041 che dichiara un target e un insieme di relay sui quali contano le ricevute. Qualunque ricevuta zap collegata all’ID dell’evento del goal contribuisce al suo avanzamento. Client come Amethyst sommano gli importi validati dei bolt11 per mostrare il progresso e una classifica dei top zapper nella schermata NIP-53 Live Activities.

Le zap split sono definite in un’appendice del NIP. Un destinatario può pubblicare un profilo kind 0 con più tag zap, ciascuno con un peso, cosi un singolo zap viene diviso tra più pubkey secondo i pesi pubblicati. Client come Amethyst, Damus e noStrudel implementano già il pagamento split end-to-end.

Questo è tutto per questa settimana. Se state costruendo qualcosa o avete notizie da condividere, scriveteci su Nostr o passate da nostrcompass.org.

Nostr Compass #18

Wed, 15 Apr 2026 00:00:00 +0000

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

Questa settimana: Amethyst integra desktop Tor, una implementazione C di secp256k1, chiamate WebRTC per NIP-AC, conformità RFC 9420 MLS per Marmot e supporto multi-wallet NIP-47. nstrfy lancia notifiche push native su Nostr per Android con eventi kind 7741. HAMSTR aggiunge Reticulum e porta eventi Nostr su mesh LoRa senza Internet. Bloom pubblica una prima release come server Blossom e relay self-hosted in un’app desktop. WaveFunc debutta come directory e player di radio Internet basata su Nostr. Botburrow avvia lo sviluppo come piattaforma bot self-hosted per chat di gruppo cifrate con Marmot. Snort pubblica quattro release con audit di sicurezza e un grande lavoro sulle performance, mentre Primal Android ridisegna feed e app bars.

Shipping This Week

Bloom v0.1.0 ships self-hosted Blossom server and relay

Bloom ha pubblicato la sua prima release, v0.1.0, il 9 aprile. Costruita con Tauri v2 e React 19, Bloom unisce in una sola applicazione desktop un server media completo Blossom e un relay Nostr. Gli utenti ottengono storage file sovrano con content addressing SHA-256, supporto ai metadati file di NIP-94 e risoluzione dello schema URI blossom:// senza dover gestire da soli l’infrastruttura server.

WaveFunc v0.1.0 and v0.1.1 launch Nostr internet radio

WaveFunc ha pubblicato v0.1.0 e v0.1.1 il 13 aprile, debuttando come directory e player di internet radio basato su Nostr. Event kind personalizzati definiscono il modello dati: kind 31237 per le stazioni radio, kind 30078 per i preferiti, kind 1311 per la live chat e kind 1111 per i commenti alle stazioni. Il backend relay basato su Khatru usa SQLite e ricerca full-text Bluge con supporto a NIP-50.

WaveFunc include un wallet Cashu NIP-60 e supporto nutzap, con migrazione da NDK ad applesauce-core. v0.1.1 aggiunge caroselli per genere, un popover per donazioni Lightning, gestione delle stazioni per utenti autenticati e listing Zapstore. La build desktop Tauri v2 guadagna system tray, media key, autostart e deep linking.

Snort ships v0.5.0 through v0.5.3 with security hardening and performance overhaul

Snort, il client web React per Nostr, ha pubblicato tre release da v0.5.0 a v0.5.3. La v0.5.0 è la più grande e consegna un audit di sicurezza completo con verifica reale delle firme Schnorr, protezione rafforzata di NIP-46 contro messaggi relay falsificati, PIN encryption migliorata e rimozione della fiducia verso delegation NIP-26 non verificata. Sul fronte performance arrivano verifica WASM batch delle firme, route lazy-loaded, un loader profili riscritto e ottimizzazioni del worker relay.

La release aggiunge anche la visualizzazione delle invoice kind 7000 per DVM NIP-90. PR #620 rifà il sistema di messaggistica per ridurre la complessità del calcolo della chat list e persistere i gift wrap nel worker relay.

Primal Android ships 3.0.21 and redesigns feed layout

Primal Android ha pubblicato v3.0.21 con fix per poll zap votes, condivisione multi-account del wallet e auto-reconnect per signer remoto e servizio wallet. Sette PR successive ridisegnano il layout principale: PR #1008 unifica la schermata principale, PR #1010 implementa nuove feed card, PR #1009 aggiunge supporto video nelle card media e PR #1013 ridisegna le app bar.

Nostria v3.1.19 through v3.1.21 add local AI image generation

Nostria ha pubblicato tre release da v3.1.19 a v3.1.21 con oltre 80 commit. L’aggiunta principale è la generazione locale di immagini con Janus Pro e accelerazione WebGPU, cosi gli utenti possono creare immagini sul dispositivo senza API esterne. Le release aggiungono anche generazione cloud, chat multimodale, supporto ONNX runtime, libreria di prompt e gestione della cache.

TubeStr v1.0.3 ships feed and studio updates

TubeStr, app privata per la condivisione di video familiari costruita su Nostr, ha pubblicato v1.0.3 il 13 aprile. La release aggiunge miglioramenti a feed e studio. PR #3 rinnova l’onboarding e PR #2 corregge un errore nell’export video. L’app usa NDK e MDK per la condivisione cifrata dei media tra familiari, con integrazione Blossom pianificata per lo storage.

In Development

Botburrow begins development as Marmot bot platform

Botburrow è un nuovo progetto del team Marmot, iniziato il 3 aprile. È una piattaforma self-hosted di gestione bot dove ogni bot ha una propria identità Nostr, entra in chat di gruppo cifrate Marmot tramite messaggi Welcome e invia e riceve messaggi end-to-end encrypted. La dashboard, costruita con Rails 8.1, comunica con un singolo daemon whitenoise-rs (wnd) attraverso un socket Unix.

Botburrow espone un livello consistente di scripting e operations: comandi, trigger e azioni pianificate eseguono codice Ruby personalizzato, gli script possono ispezionare profili, membership di gruppo e inviti pendenti tramite wnd, la dashboard include una vista live chat e ogni bot ha un proprio storage file per configurazioni, cache e output generato. Un’immagine Docker con build multi-arch punta a self-hosting zero-config su Umbrel e Start9.

Nostr Archives, la piattaforma di archiviazione e analytics per Nostr su nostrarchives.com, ha continuato a svilupparsi sia lato API sia lato frontend. PR #118 aggiunge il filtro per intervallo temporale alla classifica client e PR #117 aggiunge contatori di engagement agli eventi di risposta. Sul frontend, PR #85 risolve entità Nostr direttamente dall’URL e PR #86 aggiunge una pagina di documentazione API.

La piattaforma gestisce quattro servizi relay: un relay di ricerca NIP-50, un relay per trending feeds, un scheduler relay per eventi futuri e un relay indicizzatore per kind 0, 3 e 10002.

Damus fixes favorites timeline

Damus, il client iOS, ha unito PR #3708 riscrivendo subscribe_to_favorites() con filtraggio in-place, ricostruzione della deduplicazione e persistenza della selezione tab.

Nostur adds private zaps and custom emoji viewing

Nostur, il client iOS, ha pubblicato 10 commit questa settimana aggiungendo supporto ai private zaps, visualizzazione di custom emoji, un fix per il rendering di .webp animati e il rilevamento del formato audio dei messaggi vocali.

Amber ships v6.0.1 through v6.0.3 with WebDAV backup and relay reconnection fixes

Amber, l’app signer Android NIP-55, ha pubblicato tre release questa settimana. v6.0.1 aggiunge backup WebDAV e condivisione su Google Drive, implementa exponential backoff per la riconnessione ai relay, aggiorna Quartz alla 1.08.0 e corregge la validazione eventi. v6.0.2 aggiunge un indice account per chi usa seed words e corregge la riconnessione quando il relay è offline all’avvio. v6.0.3 aggiunge un ulteriore fix per request ID vuoti nella ricezione di intent.

Plektos v0.6.0 redesigns with Ditto themes

Plektos, la piattaforma decentralizzata per meetup ed eventi costruita su NIP-52, ha pubblicato v0.6.0 e v0.6.1. L’aggiornamento aggiunge temi di comunità in stile Ditto con upload di sfondi personalizzati, configurazione della forma avatar e un generale restyling dell’interfaccia.

Shadow adds Nostr OS API and Cashu wallet app

Shadow, la piattaforma runtime di app di Justin Moon, ha pubblicato oltre 30 commit in due giorni. Commit 88cbda5 aggiunge un’app wallet Cashu dentro il runtime, commit 865c415 aggiunge una demo podcast player e il runtime espone Shadow.os.nostr e Shadow.os.audio come API di sistema di primo livello.

Lief, app Nostr per comporre e inviare lettere long-form ad altri utenti Nostr, ha pubblicato la build v2026.04.12. L’aggiornamento corregge un problema di login con Amber su Android, semplifica il flusso di nudge al signer, aggiorna nostrify e aggiunge l’integrazione Zapstore.

Espy, app social Nostr dove gli utenti condividono “momenti colore”, ha pubblicato la build v2026.04.12. L’update rifà il color picker con un arco di saturazione curvo, corregge bug di flicker nell’anello della tonalità, aggiunge personaggi Easter egg e riduce gli asset PNG di 703KB. Corregge anche il login con Amber e aggiorna nostrify.

Jumble adds per-feed kind filters and articles tab

Jumble ha pubblicato 13 commit questa settimana aggiungendo filtri per kind per singolo feed, una tab Articles, sincronizzazione dello stato di lettura delle notifiche con opzione privacy-preserving, una modalità per nascondere gli avatar e un fix a una race condition nel cambio account.

Primal Web ships 8 version bumps

Primal Web ha pubblicato le versioni 3.0.93 fino alla 3.0.101 in una settimana con 21 commit. Il lavoro si concentra su miglioramenti alla live stream chat, fix ai boundary delle mention, paginazione dei bookmark, prevenzione dei like duplicati e correzioni al relay proxy.

Protocol and Spec Work

NIP Updates

Modifiche recenti al repository NIPs:

Merged:

NIP-34 (Git Stuff): Add nostr:// clone URLs (PR #2312): NIP-34 definisce come ospitare repository git su Nostr usando annunci di repository kind 30617 che elencano branch, tag, relay e pubkey dei maintainer. Questa PR aggiunge un formato nostr:// per il clone che funziona con helper git-remote-nostr, cosi git clone nostr://npub1.../relay.ngit.dev/ngit può risolvere npub o un indirizzo NIP-05, scoprire i relay del repository e recuperare i dati del repo. Sono definiti tre pattern URL, e la PR stringe anche il formato del tag d per garantire URI validi.

Open PRs and Discussions:

NIP-63a: Minimal Payment Gateway Descriptor (PR #2315): propone un evento replaceable kind 10164 che permette ai creatori di dichiarare gateway di pagamento, modelli di prezzo e regole di subscription per contenuti a pagamento.
NIP-XX: Relay Self-Declaration Manifest and Retention Horizon (PR #2314): propone un evento replaceable kind 10100 per dichiarazioni gossipabili dei relay e un nuovo messaggio relay-to-client HORIZON che indica il timestamp più antico conservato.
NIP-TPLD: Transient Private Location Data (PR #2309): propone il kind 20411 per condividere dati di geolocalizzazione cifrati con destinatari specifici tramite NIP-44, con supporto ttl per la retention.
NIP-5C (Scrolls): WASM programs update (PR #2281): continua lo sviluppo della specifica per la pubblicazione ed esecuzione di programmi WASM su Nostr, estendendo NIP-5A da siti statici a programmi interattivi.
NIP-44 large payload support (PR #1907): propone di estendere la cifratura versionata NIP-44 oltre l’attuale limite di 65.535 byte, utile soprattutto per le risposte NIP-46 che contengono grandi contact list kind 3.
NIP-C7: Restrict kind 9 to chat views (PR #2310): richiede che i client che renderizzano una “chat view” recuperino solo eventi kind 9, evitando la perdita di contesto quando altri tipi di contenuto finiscono nella timeline di chat.

NIP Deep Dive: NIP-29 (Relay-based Groups)

NIP-29 definisce un modello di messaggistica di gruppo in cui è il relay a gestire membership e moderazione. I gruppi vivono su un relay specifico, identificati da una stringa casuale, e il relay applica le regole su chi può scrivere nel gruppo. È un’architettura diversa da Marmot o dalle chat di gruppo NIP-17: qui il relay è l’autorità e può leggere i messaggi.

Un gruppo è identificato dal formato <host>'<group-id>, per esempio groups.nostr.com'abcdef. Tutti gli eventi inviati al gruppo portano un tag h con l’ID del gruppo:

{
 "id": "a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890",
 "pubkey": "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876",
 "created_at": 1744675200,
 "kind": 9,
 "tags": [
 ["h", "abcdef"],
 ["previous", "a1b2c3d4", "e5f67890", "12345678"]
 ],
 "content": "Has anyone tested the new relay config?",
 "sig": "e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4"
}

Il tag previous funge da meccanismo di rilevamento delle manomissioni. I client includono i primi 8 caratteri hex di eventi recenti visti sullo stesso relay, e i relay rifiutano riferimenti a eventi che non possiedono. La membership è gestita da kind di moderazione nell’intervallo 9000-9020. Un utente entra pubblicando un kind 9021 e può includere un tag code collegato a codici invito creati dagli admin:

{
 "id": "b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1",
 "pubkey": "f1a2b3c4d5e6f7890123456789abcdef0123456789abcdef1234567890abcdef",
 "created_at": 1744675200,
 "kind": 9021,
 "tags": [
 ["h", "abcdef"],
 ["code", "invite-xyz-123"]
 ],
 "content": "I'd like to join the dev discussion group.",
 "sig": "11223344556677889900aabbccddeeff11223344556677889900aabbccddeeff11223344556677889900aabbccddeeff11223344556677889900aabbccddeeff"
}

Gli admin possono aggiungere utenti con ruoli, rimuoverli, modificare i metadati del gruppo e cancellare eventi. Le configurazioni vengono pubblicate come eventi addressable kind 39000 fino a 39003. I gruppi possono essere pubblici, chiusi o aperti, e la specifica accetta molti tipi di evento nel contesto del gruppo, inclusi articoli NIP-23 e live stream NIP-53. Client come Flotilla e Coracle supportano già questo modello, mentre Nostrord è in sviluppo. Il compromesso rispetto a Marmot è esplicito: niente end-to-end encryption, ma molta più semplicità operativa per comunità pubbliche e spazi di discussione aperti.

NIP Deep Dive: NIP-90 (Data Vending Machines)

NIP-90 definisce un protocollo per computazione on-demand su Nostr. Un cliente pubblica una richiesta di lavoro, i service provider competono per eseguirla e i risultati vengono consegnati come eventi Nostr. Il protocollo riserva i kind 5000-5999 alle richieste, 6000-6999 ai risultati e 7000 al feedback di stato.

Una richiesta può usare input di tipo url, event, job o text, specificare un bid massimo in millisats, aggiungere parametri con tag param e dichiarare il formato di output con output:

{
 "id": "c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2",
 "pubkey": "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876",
 "created_at": 1744675200,
 "kind": 5001,
 "tags": [
 ["i", "https://example.com/article.txt", "url"],
 ["output", "text/plain"],
 ["relays", "wss://relay.damus.io", "wss://nos.lol"],
 ["bid", "5000"],
 ["param", "lang", "en"],
 ["param", "max_tokens", "280"]
 ],
 "content": "",
 "sig": "aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899"
}

Il provider pubblica poi un risultato kind 6001 che rimanda alla richiesta originale e può includere una invoice Lightning nel tag amount. Gli eventi kind 7000 permettono aggiornamenti come payment-required, processing, error e success, dando visibilità sullo stato dei job lunghi. Il chaining dei job consente pipeline composte, per esempio trascrizione, riassunto e traduzione in sequenza.

Per la privacy, input e parametri possono essere cifrati con NIP-04 verso il provider selezionato. Tipi di job specifici vengono definiti in un repository separato, con richieste per generazione testo, riassunto, speech-to-text, immagini e raccomandazione contenuti. Client come Snort mostrano già invoice payment-required, mentre noStrudel e DVMDash aiutano rispettivamente nella scoperta e nell’osservazione dei DVM.

Questo è tutto per questa settimana. Se state costruendo qualcosa o avete notizie da condividere, scriveteci su Nostr o passate da nostrcompass.org.

Nostr Compass #17

Wed, 08 Apr 2026 00:00:00 +0000

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

Questa settimana: Amethyst distribuisce la v1.08.0 con integrazione Arti Tor e una UI Shorts ridisegnata, mentre integra implementazioni in puro Kotlin di MLS e Marmot nella sua libreria Quartz. Nostur distribuisce la v1.27.0 con registrazione video, profili GIF animati e risposte private. Shosho lancia la v0.15.0 con Shows (informazioni personalizzate sul live stream collegate a OBS) e un carousel video verticale in stile TikTok. Nymchat torna da Marmot e distribuisce chat di gruppo NIP-17 potenziate con chiavi ephemeral a rotazione. Nostr VPN distribuisce supporto exit node e packaging Umbrel attraverso sei rilasci. Amber sale alla v6.0.0-pre1 con chiavi di firma NIP-46 per connessione e aggiornamenti in-app via Zapstore. Notedeck raggiunge la v0.10.0-beta con auto-aggiornamento APK via Zapstore, e NIP-58 (Badges) riceve una migrazione di kind. Due approfondimenti NIP coprono NIP-17 (Private Direct Messages) e NIP-46 (Nostr Remote Signing).

Notizie Principali

Amethyst distribuisce Arti Tor e integra MLS e Marmot in puro Kotlin

Amethyst, il client Android mantenuto da vitorpamplona, ha distribuito quattro rilasci dalla v1.07.3 alla v1.08.0 e ha integrato un ampio blocco di lavoro non ancora rilasciato nella sua libreria Quartz (il modulo Nostr condiviso Kotlin Multiplatform). Il rilascio di punta è la v1.08.0 “Arti Tor”, che sposta la connettività Tor dell’app dalla libreria Tor basata su C a Arti, l’implementazione Rust del Tor Project. La migrazione affronta i crash casuali che si verificavano con i precedenti binding C di Tor. Arti è il sostituto a lungo termine del Tor Project per la codebase C, riscritto da zero in Rust per memory safety e async I/O.

Il rilascio v1.07.3 ha ridisegnato la UI Shorts, sostituendo il design paginato con feed edge-to-edge per immagini, short e video lunghi. Lo stesso rilascio ha migrato i badge al kind 10008 e i bookmark al kind 10003, allineandosi alla migrazione di kind NIP-58 unita questa settimana. La v1.07.4 ha corretto un problema nella gestione dei secret di Nostr Wallet Connect, e la v1.07.5 ha corretto un crash durante l’upload di immagini.

Sul branch main, ma non ancora in un rilascio taggato, il team ha scritto un’implementazione completa in Kotlin sia di MLS sia del protocollo Marmot, eliminando la necessità di binding a librerie native C/Rust. La PR #2147 aggiunge il layer centrale di messaggistica di gruppo Marmot MLS, la PR #2149 aggiunge la UI della chat di gruppo, la PR #2146 aggiunge i processor dei messaggi in ingresso e in uscita con un subscription manager, la PR #2141 aggiunge la persistenza dello stato dei gruppi MLS e la gestione della rotazione dei KeyPackage, la PR #2150 aggiunge una suite di test MLS completa con una firma di GroupInfo migliorata, e la PR #2158 aggiunge il tracciamento dello stato di pubblicazione dei KeyPackage. La PR #2166 aggiunge un’implementazione secp256k1 in puro Kotlin per le operazioni crittografiche Nostr, sostituendo la dipendenza dalla libreria C nativa. Combinata con l’implementazione Kotlin di MLS, Quartz può eseguire firma Nostr e messaggistica di gruppo Marmot senza alcun binding nativo, aprendo la strada ai target Kotlin Multiplatform inclusi quelli iOS.

Il team sta anche costruendo il supporto a NIP-AC (P2P Voice and Video Calls): la PR #2143 aggiunge una suite di test completa per la call state machine di NIP-AC, e la PR #2164 impedisce che offerte di chiamata stale vengano riattivate dopo il riavvio dell’app.

Nostur v1.27.0 aggiunge registrazione video e risposte private

Nostur, il client Nostr per iOS, ha distribuito la v1.27.0 il 2 aprile. Il rilascio aggiunge la registrazione video in-app con trim prima dell’upload, così gli utenti possono registrare clip brevi, tagliarle alla lunghezza desiderata e pubblicarle senza uscire dal client. Il supporto alle GIF animate si estende alle foto profilo e banner, con l’aggiunta anche del rendering WebP animato. Una nuova integrazione con Shortcuts permette agli utenti di inviare post Nostr dalle automazioni Apple Shortcuts. Il rilascio aggiunge anche le risposte private e corregge problemi di compatibilità DM che influivano sulla consegna dei messaggi tra Nostur e altri client.

Shosho v0.15.0 lancia Shows e un carousel video verticale

Shosho, l’app di live streaming Nostr, ha distribuito la v0.15.0 e la v0.15.1 il 7 aprile. La funzione principale è Shows: gli streamer possono preparare informazioni personalizzate sul proprio show prima di andare live e collegare lo show a OBS o a qualsiasi encoder esterno. Questo separa i metadati del “cosa sto trasmettendo” dall’atto di andare in diretta, così gli streamer possono preparare titoli, descrizioni e prodotti prima di iniziare la trasmissione. Lo stesso rilascio aggiunge un carousel video verticale in stile TikTok per scorrere live, clip e replay in un feed a schermo intero, e Quick Add per pubblicare clip video e aggiungere prodotti direttamente dalla pagina profilo. La v0.15.1 corregge un bug per cui la tastiera nascondeva il campo di input della chat del live stream.

Rilasci di Questa Settimana

Notedeck v0.10.0-beta distribuisce l’auto-aggiornamento via Zapstore

Notedeck, il client desktop e mobile del team Damus, ha distribuito v0.10.0-beta.1 e v0.10.0-beta.2 come prerelease di test per l’auto-aggiornamento APK. La PR #1417 aggiunge l’auto-aggiornamento APK via updater Nostr/Zapstore su Android, costruendo sul lavoro di discovery degli aggiornamenti nativo Nostr dalla Newsletter #14. Il flusso di aggiornamento scopre i nuovi rilasci tramite event Nostr pubblicati sui relay, poi scarica l’APK da dove lo sviluppatore lo ospita (GitHub releases, Blossom CDN o altre sorgenti), verifica l’hash SHA-256 rispetto all’event Nostr firmato e lo installa. La PR #1438 corregge un bug della welcome screen in cui i pulsanti Login e CreateAccount tornavano subito indietro, e la PR #1424 corregge l’overflow del testo nella vista sessione di Agentium AI.

Amber v6.0.0-pre1 aggiunge chiavi di firma NIP-46 per connessione

Amber, l’app signer NIP-55 (Android Signer Application), ha distribuito la v6.0.0-pre1 il 4 aprile. Il cambiamento più importante è l’introduzione di chiavi di firma per connessione per il protocollo bunker NIP-46 (Nostr Remote Signing). Invece di usare una singola keypair per tutte le connessioni bunker, Amber ora genera una chiave distinta per ogni client connesso. Se una connessione client viene compromessa, l’attaccante non può impersonare il signer verso gli altri client.

La PR #377 aggiunge il controllo e l’installazione degli aggiornamenti in-app via Zapstore, unendosi a Notedeck nell’adozione della distribuzione app nativa Nostr. La PR #375 gestisce con grazia i fallimenti di AndroidKeyStore mostrando un avviso agli utenti invece di far crashare l’app, e la PR #371 aggiunge cleanup del database con limiti di dimensione e troncamento dei contenuti per prevenire una crescita di storage senza limiti. La prerelease include anche la whitelist relay auth NIP-42 e il login tramite frase mnemonica di recovery dal ciclo v5.0.x trattato la settimana scorsa.

Nostria distribuisce un’app mobile nativa

Nostria, il client Nostr cross-platform mantenuto da SondreB, ha rilasciato un’app mobile nativa per Android con otto rilasci dalla v3.1.11 alla v3.1.18. La capacità nuova più importante è il supporto nativo ai signer locali come Amber e Aegis. Sono disponibili anche gli installer desktop per Linux, macOS e Windows. La PR #610 riduce la pressione sulla memoria del feed con limiti runtime adattivi e cleanup delle preview URL. La v3.1.14 corregge l’integrazione con Brainstorm, un provider Web of Trust. La v3.1.15 si concentra sui miglioramenti musicali. La nuova app Android è disponibile su Zapstore.

diVine 1.0.8 distribuisce upload resumable e DM

diVine, il client per video brevi, ha distribuito la 1.0.8 con 87 PR unite. Gli upload resumable permettono ai creator di riprendere upload interrotti chunk per chunk invece di ricominciare da zero su una connessione instabile. Il rilascio aggiunge impostazioni di qualità video e bitrate, doppio tap per mettere like e miglioramenti ai DM. La PR #2722 aggiunge un plugin fotocamera macOS per la cattura video desktop, e la PR #2820 migra il sistema di notifiche a un’architettura BLoC con enrichment e grouping. Il team ha anche sostituito sticker e artwork di categoria generati da AI con SVG OpenMoji (PR #2844, PR #2842).

Manent v1.3.0 aggiunge blur per note sensibili e auth NIP-42

Manent, l’app per note private cifrate e storage file, ha distribuito la v1.3.0 il 2 aprile. Gli utenti possono ora segnare le note come sensibili per sfocarle nella list view, mantenendo nascosto il contenuto privato durante lo scorrimento casuale. Il rilascio aggiunge anche il supporto NIP-42 (Authentication of Clients to Relays), permettendo a Manent di autenticarsi verso relay che lo richiedono prima di accettare event. Manent archivia tutti i dati cifrati sui relay Nostr usando la keypair dell’utente, quindi il supporto NIP-42 amplia l’insieme di relay che può usare per lo storage.

Wisp da v0.17.0 a v0.17.3 aggiunge zap ai live stream e backup wallet

Wisp, il client Nostr Android, ha distribuito sei rilasci dalla v0.16.2-beta alla v0.17.3-beta con 44 PR unite. La v0.17.0 aggiunge prompt di sicurezza per il backup del wallet e miglioramenti alla UX degli zap. La v0.17.1 aggiunge la visibilità della chat del live stream tra piattaforme e la funzionalità zap per i live stream. La PR #423 aggiunge la ricerca automatica dei profili, un’animazione di successo per gli zap e miglioramenti allo stato utente. La PR #426 corregge un crash out-of-memory in computeId per event con grandi liste di tag. I rilasci v0.16.x avevano aggiunto autocompletamento degli shortcode emoji, miglioramenti alla UI della chat di gruppo e filtraggio degli utenti bloccati in tutti i percorsi delle notifiche.

Mostro distribuisce deep link, tassi di cambio da Nostr e una correzione ai pagamenti duplicati

Mostro, l’exchange Bitcoin peer-to-peer costruito su Nostr, ha registrato aggiornamenti questa settimana sia nel daemon server sia nel client mobile. Sul lato server, la PR #692 impedisce che scritture stale degli ordini causino pagamenti duplicati, un bug che poteva portare a pagare due volte un venditore per lo stesso trade. La PR #693 usa aggiornamenti mirati per le scritture di dev_fee invece di riscrivere l’intero ordine.

Mostro Mobile, il client Flutter, ha distribuito la v1.2.3 il 3 aprile. Il rilascio gestisce deep link provenienti da diverse istanze Mostro, così gli utenti possono toccare link che instradano verso il server exchange corretto. La PR #498 rileva DM di admin e dispute nella pipeline di notifiche in background, e l’app ora recupera i tassi di cambio da Nostr con fallback HTTP/cache. La PR #560 corregge un bug bloccante nella connessione ai relay che impediva all’app di raggiungerli in certe condizioni di rete.

Unfiltered v1.0.12 aggiunge hashtag e commenti

Unfiltered, un client Nostr focalizzato su contenuti image-forward, ha distribuito la v1.0.12. La PR #69 aggiunge il supporto agli hashtag e la PR #72 aggiunge la possibilità di scrivere e visualizzare commenti sui post. La PR #71 corregge problemi di navigazione con più immagini per post.

Primal Android distribuisce condivisione wallet multi-account e auto-reconnect del remote signer

Primal, il client Nostr Android, ha distribuito un rilascio il 7 aprile. L’aggiornamento aggiunge la condivisione wallet multi-account e un menu overflow con cancellazione del wallet nei Dev Tools. Il remote signer ora si riconnette automaticamente quando la connessione cade, e il servizio wallet ha ottenuto una propria logica di auto-reconnect. Le correzioni includono i voti zap dei sondaggi che non appaiono più come Top Zaps, la prevenzione del crash con opzioni di sondaggio vuote, l’occultamento del saldo wallet quando non esiste alcun wallet, e il mapping dei tipi WalletException in codici errore nelle risposte NWC.

Titan v0.1.0 lancia un browser nativo nsite:// con registrazione dei nomi su Bitcoin

Titan, un browser desktop nativo per il web di Nostr, ha distribuito la v0.1.0 il 7 aprile. Titan risolve gli URL nsite:// cercando nomi leggibili registrati su Bitcoin, interrogando i relay Nostr per gli event di contenuto del sito e renderizzando pagine recuperate da server Blossom. Il risultato è un’esperienza di navigazione web senza DNS, senza certificati TLS e senza hosting provider. I nomi vengono registrati tramite una web interface legata a transazioni Bitcoin. Il rilascio iniziale è distribuito come .dmg per macOS (ARM, con supporto Rosetta 2 per Intel) e include il supporto all’ambiente di sviluppo Nix.

Bikel v1.5.0 distribuisce un native foreground service per telefoni de-Googled

Bikel, un tracker ciclistico decentralizzato che trasforma le corse in dati di infrastruttura pubblica usando Nostr, ha distribuito la v1.5.0 il 4 aprile. Il rilascio migra da Expo TaskManager dipendente da GMS a un foreground service nativo personalizzato, garantendo un tracking affidabile in background su LineageOS, GrapheneOS e altre varianti Android de-Googled. Il Bikel Bot ha ottenuto un’architettura dual-pocket con raccolta eCash autonoma via Cashu nutzaps. La v1.4.3 e la v1.4.2 correggono la sincronizzazione del tracking in background per ambienti Android non standard, e l’app aggiunge toggle per i punti mappa dei portabici OSM.

Sprout aggiunge supporto a NIP-01, NIP-23 e NIP-33

Sprout, una piattaforma di comunicazione di Block con relay Nostr integrato, ha distribuito la desktop/v0.1.0-rc7 il 6 aprile. Questa settimana il team ha aggiunto supporto agli articoli kind 30023 di NIP-23 (Long-form Content), agli event replaceable parametrizzati di NIP-33 con sostituzione indicizzata dal tag d, e alle text note kind 1 e follow list kind 3 di NIP-01/NIP-02. Il rilascio aggiunge anche un sistema di temi IDE adattivi con 54 temi, rifiniture UX per workflow e cronologia delle esecuzioni degli agenti, e cleanup della sidebar membri.

mesh-llm v0.56.0 distribuisce un protocollo di configurazione distribuito

mesh-llm, un sistema distribuito di inferenza LLM che usa keypair Nostr per l’identità dei nodi, ha distribuito la v0.56.0 il 7 aprile. Il rilascio aggiunge un protocollo di configurazione distribuito con semantiche di ownership, quantizzazione asimmetrica della cache KV (chiavi Q8_0 con valori Q4) per ridurre l’uso di memoria, storage nel keychain del sistema operativo per i keystore di identità, streaming chat fluido con coda dei messaggi, e correzioni al layout fullscreen e alla suddivisione della cache KV con flash attention.

Nostr VPN distribuisce supporto exit node e packaging Umbrel

Nostr VPN, una VPN peer-to-peer che usa relay Nostr per la segnalazione e WireGuard per i tunnel cifrati, ha distribuito sei rilasci dalla v0.3.0 alla v0.3.6 questa settimana. Il ciclo v0.3.x aggiunge il supporto agli exit node su Windows e macOS, permettendo ai peer di instradare il traffico Internet attraverso altri nodi della rete. La propagazione di invite e alias ora si sincronizza via Nostr, così gli utenti possono condividere l’accesso alla rete senza coordinamento out-of-band. I rilasci aggiungono packaging Umbrel per deployment self-hosted, NAT punch-through usando endpoint pubblici ricordati, cleanup automatico degli exit node stale e una specifica di protocollo pubblicata. Il progetto ha anche stabilizzato la gestione delle route su macOS con default route auto-riparanti e underlay repair, e ha aggiunto un build Android via Tauri. Sono disponibili build per macOS (Apple Silicon e Intel), Linux (AppImage e .deb), Windows e Android.

Nymchat abbandona Marmot e distribuisce chat di gruppo NIP-17 potenziate

Nymchat, il client chat capace di MLS, ha distribuito 14 rilasci dalla v3.56.261 alla v3.58.274. Il cambiamento più significativo è una svolta di protocollo: la v3.57.261 aveva aggiunto chat di gruppo Marmot MLS, ma la v3.58.268 è tornata a NIP-17 perché il supporto multi-device di Marmot non è ancora completo, e questo causava problemi nella sincronizzazione dello stato delle chat di gruppo tra dispositivi. La v3.58.271 introduce chat di gruppo NIP-17 potenziate con chiavi ephemeral a rotazione per tutti i messaggi, progettate per prevenire timing attack e correlation attack. La settimana ha portato anche un sistema amici con controllo granulare delle impostazioni (v3.58.262), sincronizzazione dei messaggi delle chat di gruppo MLS nelle impostazioni cifrate dell’app, e diverse correzioni alla connettività relay.

nak v0.19.5 aggiunge Blossom multi-server e pubblicazione outbox

nak, il toolkit Nostr a riga di comando di fiatjaf, ha distribuito la v0.19.5. Il comando blossom ora accetta più flag --server per caricare su diversi server Blossom in una sola chiamata. Un nuovo comando key espande chiavi parziali aggiungendo zeri a sinistra. Il comando event guadagna un flag --outbox per pubblicare event attraverso il modello outbox, e fetch ora termina con un codice errore quando non viene restituito alcun event.

In Sviluppo

White Noise aggiunge anteprime thumbhash e il bridge per la registrazione push

White Noise, il messenger privato costruito sul protocollo Marmot, ha unito cinque PR. La PR #549 sostituisce le anteprime immagine blurhash con thumbhash, un algoritmo più recente che produce immagini placeholder più nitide con una dimensione payload minore (tipicamente sotto i 30 byte contro i ~50-100 byte di blurhash) preservando il rapporto d’aspetto e la distribuzione dei colori dell’immagine originale. Blurhash viene mantenuto come fallback per i contenuti più vecchi. La PR #548 aggiorna whitenoise-rs e aggiunge il bridge di registrazione push MIP-05, collegando al client il lavoro sulla specifica delle push notification della settimana scorsa. La PR #493 aggiunge la paginazione basata su cursore per i messaggi chat, sostituendo la strategia di caricamento precedente con un approccio guidato dallo scroll.

Route96 aggiunge configurazione dinamica delle label e cleanup zero-egress

Route96, il media server Blossom di v0l, ha unito tre PR. La PR #80 aggiunge la configurazione dinamica del modello di label tramite admin API, permettendo agli operatori di sostituire i modelli di classificazione dei contenuti senza riavviare il server. La PR #82 aggiunge i campi di configurazione delle label alla admin UI. La PR #79 aggiunge una policy di cleanup dei file zero-egress che rimuove automaticamente i file mai scaricati, mantenendo bassi i costi di storage per gli operatori.

Snort distribuisce hardening di sicurezza e invoice di pagamento DVM

Snort, il client web, ha distribuito due rilasci questa settimana insieme a un audit di sicurezza completo. Le correzioni includono verifica delle firme Schnorr, protezione NIP-46 contro la falsificazione dei messaggi relay (impedendo ad attaccanti di iniettare richieste di firma attraverso relay compromessi), miglioramenti alla cifratura del PIN e rimozione della fiducia nella delega NIP-26. I miglioramenti prestazionali arrivano dalla verifica Schnorr batch in WASM, route lazy-loaded, traduzioni precompilate ed eliminazione della doppia verifica per event. La PR #618 aggiunge la visualizzazione dell’invoice kind 7000 con pagamento richiesto di NIP-90 (Data Vending Machine), così quando un DVM risponde con un requisito di pagamento, Snort renderizza direttamente la Lightning invoice nel feed.

Damus migliora la compattazione LMDB

Damus, il client iOS, ha unito la PR #3719 che aggiunge la compattazione automatica di LMDB su base pianificata, impedendo al database locale di crescere senza limiti nel tempo. La PR #3663 migliora la BlurOverlayView in modo che sembri protettiva invece che rotta.

Captain’s Log aggiunge indicizzazione dei tag e sync delle note

Captain’s Log (Comet), lo strumento di scrittura long-form nativo Nostr di Nodetec, ha unito quattro PR questa settimana. La PR #156 aggiunge indicizzazione dei tag e supporto alla sincronizzazione tra note, la PR #157 rifattorizza il sync delle note e la gestione dei tag, e la PR #159 corregge la sincronizzazione delle note cestinate in modo che gli elementi eliminati restino eliminati su tutti i dispositivi.

Relatr v0.2.x ridisegna il sistema plugin con un marketplace di validator nativo Nostr

Relatr, un motore Web of Trust che calcola ranking di fiducia dalla distanza nel grafo sociale e da validator configurabili, ha distribuito la famiglia v0.2.x con un redesign completo del sistema plugin. I validator sono ora scritti in Elo, un linguaggio di espressioni funzionali portabile forkato per supportare capacità orchestrate dall’host in più passi (query Nostr, lookup del grafo sociale, risoluzione NIP-05). I plugin vengono pubblicati come event Nostr kind 765, rendendo la distribuzione nativa alla rete relay. Un nuovo plugin marketplace permette agli operatori di scoprire, installare e pesare i validator dal browser, con una CLI (relo) per authoring e pubblicazione locale. L’architettura è sandboxed: i plugin possono invocare solo le capacità che l’host fornisce esplicitamente, quindi un validator malevolo non può uscire dal proprio scope definito. Le istanze Relatr ora possono essere gestite dal sito web, con visibilità completa su quali plugin compongono l’algoritmo di scoring e sui pesi individuali di ciascuno.

Shopstr migliora navigazione mobile e controllo accessi

Shopstr, il marketplace nativo Nostr per comprare e vendere con Bitcoin, ha spinto 158 commit questa settimana nella sua app principale e nel progetto companion Milk Market. Le correzioni includono miglioramenti al layout mobile delle community, comportamento di chiusura del menu durante la navigazione e auto-chiusura dei dropdown. Le route protette non possono più essere raggiunte via URL diretto senza login, e la logica di matching degli slug ora gestisce correttamente più corrispondenze esatte.

Pollerama aggiunge notifiche, ricerca film e nuova rating UI

Pollerama, un’app di polling, survey e rating sociale costruita su Nostr, ha aggiunto notifiche dei thread, una funzione di ricerca film e un overhaul della rating UI. Il rilascio corregge anche problemi di caricamento del feed e aggiorna le versioni delle dipendenze.

Purser costruisce un payment daemon nativo Nostr con cifratura Marmot

Purser, un payment daemon nativo Nostr progettato come sostituto di Zaprite, ha unito nove PR questa settimana che costruiscono la sua architettura centrale. Il progetto usa MLS di Marmot tramite MDK per la messaggistica cifrata merchant-customer, con Strike e Square come payment provider. Questa settimana sono arrivati caricamento di configurazione e catalogo, validazione dello schema dei messaggi, il layer di comunicazione MDK, le implementazioni dei provider Strike e Square, un motore di polling, anti-spam rate limiting, persistenza dei pagamenti pending e la pipeline di elaborazione degli ordini. Tutti i 99 test ora esercitano operazioni MLS reali di mdk-core dopo che il team ha rimosso il mock MLS in favore della cifratura reale in modalità locale.

Vector rifattorizza gli allegati DM e aggiunge la modifica del profilo

Vector, il messenger Nostr focalizzato sulla privacy costruito con Tauri, ha unito la PR #55 che rifattorizza il frontend. La decrittazione e il salvataggio degli allegati DM sono stati spostati nella libreria vector-core, e l’app ora supporta la modifica del profilo. Il flag di cancellazione dell’upload è collegato correttamente attraverso TauriSendCallback, e i callback inutilizzati per l’anteprima degli allegati sono stati ripuliti.

Lavoro su Protocollo e Specifiche

Aggiornamenti NIP

Modifiche recenti al repository NIPs:

Uniti:

NIP-58 (Badges): i Profile Badges passano al kind 10008, i Badge Sets al kind 30008 (PR #2276): Migra i Profile Badges dal kind 30008 al kind 10008 (un event replaceable, uno per pubkey) e introduce il kind 30008 per i Badge Sets. In precedenza i Profile Badges usavano lo stesso kind (30008) delle definizioni dei badge, rendendoli event replaceable parametrizzati indicizzati da un tag d. Il nuovo kind 10008 è un semplice event replaceable: uno per pubkey, nessun tag d necessario. I client interrogano un singolo event replaceable per utente invece di scandire event replaceable parametrizzati. Amethyst v1.07.3 distribuisce già questa migrazione.
NIP-34 (Git Stuff): aggiungere follow list relative a git (PR #2130): Aggiunge convenzioni di follow list per il tracciamento di repository e issue NIP-34. Gli utenti pubblicano follow set kind 30000 con tag d come git-repos o git-issues contenenti riferimenti tag a ai repository (kind 30617) che vogliono seguire. I client possono sottoscrivere questi follow set per mostrare l’attività dei repository nel feed di un utente, in modo simile a come le contact list kind 3 funzionano per le pubkey.

PR aperte e discussioni:

NIP-AC: P2P Voice and Video Calls over WebRTC (PR #2301): Estende il NIP-100 originale (implementato da 0xChat) con tre cambiamenti: migrazione alla cifratura NIP-44 avvolta in gift wrap NIP-59 per eliminare i metadata leak, un workflow WebRTC specificato per setup di chiamate vocali e video (offer, answer, ICE candidates), e un modello di mesh group call in cui ogni peer stabilisce una connessione WebRTC diretta con tutti gli altri peer. La specifica non è backwards-compatible con NIP-100. Amethyst ci sta già lavorando, con una suite di test per la call state machine (PR #2143) e la gestione delle call offer stale (PR #2164) arrivate questa settimana.
NIP-340 (FROST Quorum) (PR #2299): Propone convenzioni per la threshold signing FROST (Flexible Round-Optimized Schnorr Threshold) su Nostr. FROST permette a un gruppo di signer di controllare collettivamente un’identità Nostr dove qualsiasi insieme t-of-n di membri può firmare event senza ricostruire la chiave privata completa. Il NIP definisce come coordinare i round di firma, distribuire key share e pubblicare event firmati in threshold, costruendo sul lavoro del signer Igloo dal progetto FROSTR.
NIP-5D (Nostr Web Applets) (PR #2303): Definisce un protocollo postMessage per applicazioni web sandboxed (“napplets”) eseguite in iframe che comunicano con un’applicazione host (“shell”). La shell fornisce alla napplet firma Nostr, accesso relay e contesto utente tramite una structured message API, mentre la sandbox iframe impedisce l’accesso diretto alle chiavi. Questo estende il modello di hosting di siti web statici di NIP-5A verso applicazioni interattive in grado di leggere e scrivere event Nostr. Il NIP è in sviluppo attivo con un’implementazione runtime funzionante.
NIP-5C (Scrolls) (PR #2281): Rinominato dalla precedente proposta NIP-A5. Definisce convenzioni per pubblicare e scoprire programmi WebAssembly su Nostr. I binari WASM vengono archiviati come event Nostr, e i client possono scaricarli ed eseguirli in un runtime sandboxed. Una demo app mostra scrolls in esecuzione nel browser, con programmi di esempio pubblicati come event Nostr che qualsiasi client può recuperare ed eseguire.
NIP-85 (Trusted Assertions): chiarimenti (PR #2304): Stringe il linguaggio della specifica intorno a chiavi multiple e relay multipli per provider di servizi, chiarendo come i client dovrebbero gestire assertion provenienti da provider che operano attraverso più pubkey o endpoint relay.
NIP-24 (Extra Metadata Fields): published_at per event replaceable (PR #2300): Generalizza il tag published_at da NIP-23 (Long-form Content) a tutti gli event replaceable e addressable. Il tag è solo display-only: se published_at è uguale a created_at, i client mostrano l’event come “created” in quel momento; se differiscono (perché l’event è stato aggiornato), i client possono mostrare “updated” invece. Questo permette ai profili kind 0 di mostrare date “joined at” e agli altri event replaceable di preservare il timestamp di pubblicazione originale attraverso gli aggiornamenti. Una proposta complementare NIP-51 (PR #2302) aggiunge lo stesso tag agli event di lista.
NIP-59 (Gift Wrap): kind di gift wrap ephemeral (PR #2245): Aggiunge il kind 21059 come controparte ephemeral del gift wrap esistente kind 1059. Gli event ephemeral (kind 20000-29999) seguono la semantica di NIP-01: i relay non sono tenuti a memorizzarli e possono scartarli dopo la consegna. Questo permette alle applicazioni di inviare messaggi gift-wrapped che scompaiono dai relay dopo la consegna, riducendo i requisiti di storage per la messaggistica ad alto volume mantenendo lo stesso modello di cifratura a tre layer dei normali DM NIP-17.

OpenSats annuncia la sedicesima ondata di grant Nostr

OpenSats ha annunciato la sua sedicesima ondata di grant Nostr l'8 aprile, finanziando quattro grant alla prima assegnazione e un rinnovo. Amethyst Desktop riceve fondi per permettere al contributor Robert Nagy di costruire un’app desktop standalone sopra i moduli Quartz e Commons, portando il set di funzionalità del client Android a interfacce guidate dal mouse con connessioni relay persistenti. Nostr Mail riceve fondi per costruire un sistema email completo su Nostr usando event kind 1301 avvolti in gift wrap NIP-59, con un client Flutter e server bridge SMTP per compatibilità con Gmail/Outlook. Nostrord riceve fondi per un client di gruppo Kotlin Multiplatform basato su relay NIP-29 con messaggistica di gruppo, moderazione e thread in stile Discord. Nurunuru riceve fondi per costruire una versione iOS nativa del client Nostr orientato al pubblico giapponese modellata sull’interfaccia familiare di LINE, con login biometrico basato su passkey per l’onboarding. HAMSTR ha ricevuto un rinnovo del grant (finanziato la prima volta nell’undicesima ondata).

NIP Deep Dive: NIP-17 (Private Direct Messages)

NIP-17 definisce lo standard attuale per i messaggi diretti privati su Nostr. Sostituisce il vecchio schema NIP-04 (Encrypted Direct Messages), che perdeva metadati (mittente, destinatario e timestamp erano tutti visibili sui relay) e usava una costruzione crittografica più debole. NIP-17 combina NIP-44 (Encrypted Payloads) per la cifratura con NIP-59 (Gift Wrap) per la protezione dei metadati, creando un sistema a tre layer in cui i relay non possono vedere chi sta parlando con chi.

Il protocollo usa tre event kind annidati l’uno dentro l’altro. Il layer più interno è il messaggio vero e proprio, un event kind 14 non firmato:

{
 "id": "a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890",
 "pubkey": "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876",
 "created_at": 1744108800,
 "kind": 14,
 "tags": [
 ["p", "f1a2b3c4d5e6f7890123456789abcdef01234567890abcdef1234567890abcdef", "wss://inbox.example.com"],
 ["subject", "Project update"]
 ],
 "content": "The new relay config is deployed. Let me know if you see any issues.",
 "sig": ""
}

L’event kind 14 è deliberatamente non firmato (sig vuoto). La specifica descrive questo aspetto come una forma di deniability, ma nella pratica la protezione è limitata. Il seal kind 13 che avvolge il rumor è firmato con la chiave reale del mittente. Un destinatario può mostrare il seal firmato a una terza parte, provando che il mittente ha comunicato con lui, anche senza rivelare il contenuto del messaggio. Con prove a conoscenza zero, un destinatario può persino dimostrare il contenuto esatto del messaggio senza rivelare la propria chiave privata. Il rumor non firmato è come una lettera non firmata in una busta firmata: la firma sulla busta collega il mittente al contenuto. La vera deniability richiederebbe autenticazione simmetrica (come gli HMAC di Signal), incompatibile con il modello relay decentralizzato di Nostr dove i messaggi devono essere self-authenticating. I veri punti di forza di NIP-17 sono la privacy dei metadati e la segretezza del contenuto, non la deniability.

Questo messaggio non firmato viene avvolto in un seal kind 13, firmato dal mittente effettivo e cifrato con NIP-44 per il destinatario:

{
 "id": "b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1",
 "pubkey": "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876",
 "created_at": 1744022400,
 "kind": 13,
 "tags": [],
 "content": "<nip44-encrypted kind 14 payload>",
 "sig": "e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4"
}

Il seal non ha tag, quindi anche se venisse decrittato non rivelerebbe il destinatario. Il seal è firmato con la chiave reale del mittente, il che permette al destinatario di autenticare il messaggio controllando che il pubkey del seal corrisponda al pubkey del kind 14 interno.

Il seal viene poi avvolto in un gift wrap kind 1059, firmato con una chiave casuale usa-e-getta e indirizzato al destinatario:

{
 "id": "c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2",
 "pubkey": "9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba",
 "created_at": 1744065600,
 "kind": 1059,
 "tags": [
 ["p", "f1a2b3c4d5e6f7890123456789abcdef01234567890abcdef1234567890abcdef"]
 ],
 "content": "<nip44-encrypted kind 13 payload>",
 "sig": "fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210"
}

Il pubkey del gift wrap è una chiave casuale generata solo per questo messaggio, e il created_at è randomizzato fino a due giorni nel passato. Questo è il layer più esterno che i relay vedono davvero: un messaggio da una pubkey sconosciuta indirizzato al destinatario, con un timestamp che non riflette quando il messaggio è stato effettivamente inviato. Il timestamp randomizzato protegge dall’analisi retrospettiva degli event archiviati, ma un avversario collegato attivamente ai relay può comunque osservare quando il gift wrap è apparso per la prima volta, quindi questa difesa è limitata agli osservatori passivi che interrogano i dati del relay in seguito. Poiché la pubkey è casuale e il timestamp è fittizio, i relay non possono determinare il mittente reale. Per leggere il messaggio, il destinatario decripta il gift wrap usando la propria chiave e la pubkey casuale, trova il seal all’interno, decripta il seal usando la propria chiave e la pubkey del mittente ricavata dal seal, e trova all’interno il messaggio kind 14.

NIP-17 non fornisce forward secrecy. Tutti i messaggi sono cifrati usando la keypair Nostr statica (tramite la derivazione delle chiavi di NIP-44 dalle chiavi del mittente e del destinatario). Se una chiave privata viene compromessa, ogni messaggio passato e futuro cifrato verso quella chiave può essere decrittato. È un tradeoff deliberato: poiché la cifratura dipende solo dall’nsec, un utente che fa il backup del proprio nsec può recuperare l’intera cronologia dei messaggi da qualsiasi relay che conservi ancora i gift wrap. Protocolli come MLS (usato da Marmot) forniscono forward secrecy attraverso la rotazione del materiale di chiave, ma al costo di richiedere sincronizzazione dello stato e rendere impossibile il recupero storico dei messaggi dopo la rotazione delle chiavi.

NIP-17 definisce anche il kind 15 per i messaggi file cifrati, che aggiunge i tag file-type, encryption-algorithm, decryption-key e decryption-nonce così il destinatario può decrittare un file allegato cifrato con AES-GCM prima dell’upload a un server Blossom. Il kind 10050 viene usato per pubblicare la relay list DM preferita dell’utente, così i mittenti sanno dove consegnare i gift wrap. L’insieme di tag pubkey + p in un messaggio definisce una chat room; aggiungere o rimuovere un partecipante crea una nuova stanza con cronologia pulita.

Le implementazioni coprono la maggior parte dei client principali. nospeak usa NIP-17 per tutta la messaggistica uno-a-uno. Flotilla usa NIP-17 per i suoi DM con proof-of-work. Amethyst, Primal, Nostur, Damus, noStrudel e Coracle implementano tutti NIP-17 come protocollo DM principale. La specifica supporta anche i messaggi a scomparsa impostando un tag expiration nel gift wrap.

NIP Deep Dive: NIP-46 (Nostr Remote Signing)

NIP-46 definisce un protocollo per separare la chiave privata dell’utente dall’applicazione client. Invece di incollare un nsec in una web app, l’utente esegue un remote signer (chiamato anche “bunker”) che custodisce la chiave privata e risponde alle richieste di firma via relay Nostr. Il client non vede mai la chiave privata. Questo riduce la superficie d’attacco: un client compromesso può richiedere firme ma non può estrarre la chiave stessa.

Il protocollo usa il kind 24133 sia per le richieste sia per le risposte, cifrate con NIP-44 (Encrypted Payloads). Un client genera una client-keypair usa-e-getta per la sessione e comunica con il remote signer attraverso messaggi cifrati NIP-44 taggati con le reciproche pubkey. Ecco una richiesta di firma da un client a un remote signer:

{
 "id": "aa11bb22cc33dd44ee55ff6677889900aabbccdd11223344556677889900aabb",
 "pubkey": "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86",
 "created_at": 1744108800,
 "kind": 24133,
 "tags": [
 ["p", "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52"]
 ],
 "content": "<nip44-encrypted JSON-RPC request>",
 "sig": "1122334455667788990011223344556677889900aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff0011223344556677"
}

Il content cifrato contiene una struttura in stile JSON-RPC:

{
 "id": "random-request-id-1",
 "method": "sign_event",
 "params": ["{\"kind\":1,\"content\":\"Hello from remote signing\",\"tags\":[],\"created_at\":1744108800}"]
}

Il remote signer decripta la richiesta, la presenta all’utente per l’approvazione (o la approva automaticamente in base ai permessi configurati), firma l’event con la chiave privata dell’utente e restituisce l’event firmato in una risposta:

{
 "id": "bb22cc33dd44ee55ff6677889900aabb11223344556677889900aabbccddeeff",
 "pubkey": "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52",
 "created_at": 1744108801,
 "kind": 24133,
 "tags": [
 ["p", "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86"]
 ],
 "content": "<nip44-encrypted JSON-RPC response>",
 "sig": "aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899"
}

Le connessioni possono essere avviate da entrambi i lati. Un remote signer fornisce un URL bunker:// contenente la sua pubkey e le informazioni relay. Un client fornisce un URL nostrconnect:// con la propria pubkey client, i relay e un secret per la verifica della connessione. Il parametro secret previene il connection spoofing: solo la parte che ha ricevuto l’URL fuori banda può completare l’handshake.

Sono definiti otto metodi: connect per stabilire la sessione, sign_event per firmare event, get_public_key per ottenere la pubkey dell’utente, ping per keepalive, nip04_encrypt/nip04_decrypt per la cifratura legacy, nip44_encrypt/nip44_decrypt per la cifratura corrente, e switch_relays per la gestione dei relay. La migrazione relay è gestita dal remote signer, che può spostare nel tempo la connessione verso nuovi relay senza rompere la sessione.

I client richiedono capacità specifiche al momento della connessione attraverso un sistema di permessi. Una stringa di permessi come nip44_encrypt,sign_event:1,sign_event:14 richiede accesso alla cifratura NIP-44 e accesso alla firma per i soli event kind 1 e kind 14. Il remote signer può accettare, rifiutare o modificare questi permessi. Questo significa che un client web per leggere e pubblicare note potrebbe ricevere solo il permesso sign_event:1, mentre un client DM potrebbe ricevere anche i permessi sign_event:14 e nip44_encrypt.

Amber implementa NIP-46 su Android, e la sua v6.0.0-pre1 di questa settimana aggiunge chiavi di firma per connessione per isolare i client tra loro. nsec.app (precedentemente Nostr Connect) fornisce un bunker web-based. nostr-tools include BunkerSigner per i client JavaScript, e la PR #530 della settimana scorsa ha aggiunto skipSwitchRelays per la gestione manuale dei relay. Il protocollo supporta anche auth challenge: quando un remote signer richiede autenticazione aggiuntiva (password, biometria o token hardware), risponde con un auth_url che il client apre in un browser perché l’utente completi il flusso.

Questo è tutto per questa settimana. Stai costruendo qualcosa o hai notizie da condividere? Scrivici in DM su Nostr o vieni a trovarci su nostrcompass.org.

Nostr Compass #16

Wed, 01 Apr 2026 00:00:00 +0000

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

Questa settimana: Amethyst distribuisce la v1.07.0 con note fissate, gestione relay tramite NIP-86, e supporto NIP-62 Request to Vanish. NIP-5A (Siti Web Statici) viene unito nel repository NIPs, definendo come ospitare siti web sotto keypair Nostr usando lo storage Blossom. Flotilla distribuisce la v1.7.0 con stanze vocali, login email/password e DM con proof-of-work. White Noise corregge il relay churn nella v2026.3.23, nospeak lancia la sua 1.0.0 come messenger cifrato senza registrazione. Nymchat adotta Marmot per chat di gruppo cifrate MLS con fallback NIP-17. Calendar by Form* raggiunge la v1.0.0 con liste calendario private e import ICS, Amber aggiunge recovery mnemonico e whitelisting relay auth NIP-42, e la spec Marmot sposta i KeyPackage su event indirizzabili mentre stringe il formato delle push notification MIP-05.

Notizie

Amethyst distribuisce note fissate, gestione relay e Request to Vanish

Amethyst, il client Android mantenuto da vitorpamplona, ha distribuito sei rilasci in tre giorni, dalla v1.07.0 alla v1.07.5. Il set di funzionalità principale copre sei superfici di protocollo: note fissate, una schermata feed dedicata ai sondaggi, supporto NIP-62 (Request to Vanish) per richiedere la cancellazione completa degli event dai relay, NIP-86 (Relay Management API) dall’interno del client, valutazioni NIP-66 (Relay Discovery and Liveness Monitoring) nella schermata informazioni relay, e visualizzazione delle informazioni membri NIP-43 (Relay Access Metadata and Requests).

NIP-86 definisce un’interfaccia JSON-RPC per gli operatori relay, permettendo ai client di inviare comandi amministrativi come ban di pubkey, allow di pubkey e lista utenti bannati tramite un’API standardizzata. Amethyst ora espone tutto questo direttamente nella sua UI di gestione relay, così gli utenti che eseguono i propri relay possono amministrarli dallo stesso client che usano per pubblicare. La PR #2039 sostituisce il vecchio dialog di input hex per le pubkey da bannare o consentire con un dialog di ricerca utenti interattivo.

La v1.07.2 ha aggiunto upload dalla tastiera GIF e ha corretto una regressione nella firma in cui le risposte di rifiuto di Amber venivano interpretate male perché le versioni più vecchie di Amber restituivano una stringa vuota per il campo rejected (PR #2042). La v1.07.5 corregge un crash nel caricamento delle immagini. I rilasci v1.06.2 e v1.06.3 all’inizio della settimana hanno aggiunto un selettore del tipo di sondaggio per scelte singole o multiple, drag-to-seek sulle barre di avanzamento video e miglioramenti alla pubblicazione anonima.

NIP-5A viene unito, portando i siti web statici su Nostr

NIP-5A (Siti Web Statici) è stato unito tramite PR #1538, definendo come ospitare siti web statici sotto keypair Nostr. La specifica usa due kind di event: kind 15128 per un sito root, uno per pubkey, e kind 35128 per siti con nome identificati da un tag d. Ogni manifesto mappa i percorsi URL agli hash SHA256, con tag server opzionali che puntano agli host di storage Blossom dove vivono i file effettivi.

Il modello di hosting funziona così: l’autore di un sito costruisce un sito statico, carica i file su uno o più server Blossom, poi pubblica un event manifesto firmato che mappa i percorsi agli hash del contenuto. Un server host riceve richieste web, risolve la pubkey dell’autore dal sottodominio, recupera il manifesto dalla relay list NIP-65 dell’autore, e serve i file scaricando i blob corrispondenti da Blossom. Il sito rimane sotto il controllo dell’autore perché solo quella chiave può firmare un manifesto aggiornato. Il server host è sostituibile perché qualsiasi server che comprende NIP-5A può servire lo stesso sito dallo stesso manifesto.

La specifica si basa su infrastrutture già esistenti. nsite, l’implementazione host di riferimento NIP-5A costruita da lez, e nsite-manager, la UI di gestione di hzrd149, erano già in esecuzione prima del merge del NIP. Il merge rende ufficiali i kind di event e le regole di risoluzione URL, dando alle seconde e terze implementazioni un obiettivo stabile.

White Noise corregge il relay churn e amplia i controlli client

White Noise, il messenger privato costruito sul protocollo Marmot, ha distribuito la v2026.3.23 il 25 marzo. Il lavoro principale riguarda la stabilità dei relay. Il login non aspetta più che ogni pubblicazione della relay-list termini prima di proseguire, perché la pubblicazione delle relay-list ora usa logica di quorum e ritenta il resto in background. Fetch e publish one-off usano sessioni relay effimere e delimitate invece di restare nel pool long-lived, le sessioni ripristinate recuperano il loro percorso di refresh di gruppo dopo l’avvio, e l’app ora espone diagnostica relay e ispezione dello stato relay tramite PR #495 e PR #502.

Lo stesso rilascio cambia anche il comportamento delle conversazioni. La PR #468 aggiunge threading delle risposte NIP-C7 con tag q e riferimenti nostr:nevent, la PR #471 e la PR #512 mantengono i messaggi cancellati visibili come placeholder cancellati invece di rimuoverli silenziosamente, la PR #478 aggiunge un flusso di bug report in-app usando report anonimi NIP-44 (Encrypted Payloads), e la PR #486 aggiunge una chat di supporto direttamente nel client. Nella stessa finestra sono arrivati anche controlli sui messaggi rivolti all’utente: la PR #532 archivia le chat, la PR #541 aggiunge mute e unmute con durate configurabili, e la PR #535 aggiunge impostazioni delle notifiche. La PR #539 prepara il lavoro di registrazione push, collegando la registrazione APNs su iOS e il rilevamento Play Services su Android in modo che la registrazione possa essere costruita sopra questo. Sul lato backend, il MDK (Marmot Development Kit) ha aggiunto primitive push notification MIP-05 e un notification request builder (PR #235, PR #238), mentre whitenoise-rs ha aggiunto la persistenza della registrazione push notification (PR #688), correzioni alla cancellazione dei task in background (PR #696), e recovery dei key package all’avvio (PR #693).

Nostr VPN raggiunge la v0.3.0 con roster sync e invite v2

Come da copertura del lancio della settimana scorsa, nostr-vpn, la VPN peer-to-peer che usa relay Nostr per la segnalazione e WireGuard per tunnel cifrati, ha continuato il suo ritmo di rilascio rapido, distribuendo versioni fino alla v0.3.3. Il salto di versione porta due cambi incompatibili: il formato invite passa alla v2 (la 0.3.0 può ancora importare invite v1, ma le build più vecchie non possono importare invite v2), e il roster sync firmato dall’admin è stato aggiunto al protocollo di segnalazione. I peer con versioni miste possono ancora connettersi a livello mesh, ma i peer più vecchi non partecipano alla sincronizzazione del roster.

L’aggiunta del roster sync avvia il passaggio verso una rete gestita. Un nodo admin può ora inviare cambiamenti di appartenenza a tutti i peer, così aggiungere o rimuovere un dispositivo dalla mesh non richiede che ogni peer aggiorni manualmente la propria configurazione. I rilasci v0.2.x nella stessa settimana hanno affrontato problemi specifici di deployment: dalla v0.2.22 alla v0.2.28 hanno corretto la gestione del servizio Windows, aggiunto script di build Android, e perfezionato il flusso di pairing LAN.

nospeak si lancia come messenger privato 1.0

nospeak, un messenger privato costruito su Nostr, ha distribuito il rilascio 1.0.0 il 27 marzo. Il progetto include conversazioni uno-a-uno e di gruppo, gestione contatti, e un’architettura self-hostable. Le chat uno-a-uno usano NIP-17 (Private Direct Messages), che combina NIP-59 (Gift Wrap) con NIP-44 (Encrypted Payloads) per nascondere il mittente ai relay. Per i media, i file sono cifrati lato client con AES-256-GCM prima dell’upload sui server Blossom. Il rilascio viene distribuito anche come immagine container per il self-hosting.

Flotilla, il client in stile Discord di hodlbod basato su NIP-29 (Relay-based Groups) e sul modello “relay come gruppi”, ha distribuito la v1.7.0 e la v1.7.1 il 30 e 31 marzo. La funzionalità principale sono le stanze vocali, contribuite da mplorentz. Gli utenti possono ora unirsi a chiamate vocali all’interno dei canali di gruppo, con un dialog di ingresso (PR #109) che permette di selezionare il dispositivo di input audio e scegliere se entrare nella chiamata vocale o solo visualizzare la chat testuale. Il dialog risolve un problema UX della precedente iterazione: entrare in una stanza con voce attiva accendeva prima il microfono anche quando l’utente voleva solo leggere i messaggi o controllare le impostazioni della stanza.

Lo stesso rilascio aggiunge il login email e password come alternativa all’autenticazione basata su chiave Nostr, proof-of-work sui DM, editing dei DM, onboarding e impostazioni relay ridisegnati, rilevamento del supporto Blossom tramite supported_nips, badge notifiche migliorati, fallback push notification su Android, e correzioni agli upload file su Android. La v1.7.1 segue con una correzione per il fallback di registrazione pomade quando si usa un signer offline.

Hodlbod sta anche costruendo Caravel, un hosting manager e dashboard per relay zooid, che ha registrato 40 commit questa settimana nella fase iniziale di sviluppo.

Nymchat distribuisce chat di gruppo basate su Marmot

Nymchat (noto anche come NYM, Nostr Ynstant Messenger), il client di chat effimero collegato a Bitchat, ha annunciato che tutte le nuove chat di gruppo ora usano il protocollo Marmot per messaggistica cifrata MLS. L’integrazione usa kind 443, 444, e 445 per key package, welcome message e group message rispettivamente, fornendo forward secrecy, post-compromise security e zero metadata leakage. Se un destinatario non può usare MLS, Nymchat ricade sul suo precedente percorso di chat di gruppo NIP-17 (Private Direct Messages), che è comunque cifrato end-to-end ma privo delle proprietà a ratchet-tree di MLS.

Le serie v3.55 e v3.56 di questa settimana si sono concentrate sui casi limite delle chat di gruppo: caricamento su nuovi dispositivi, comportamento di uscita, instradamento delle notifiche, e conteggi dei badge non letti. Lo stesso ciclo ha anche corretto una vulnerabilità XSS dovuta a HTML non escapato e ha aggiunto il blocco di parole chiave e frasi esteso ai nickname utente. Questo rende Nymchat un altro client Marmot che si unisce a White Noise e OpenChat, ampliando l’insieme di app che possono scambiare messaggi di gruppo cifrati MLS sullo stesso protocollo.

Rilasci

Calendar by Form* v1.0.0

Calendar by Form*, l’app calendario decentralizzata costruita su NIP-52 (Calendar Events), ha raggiunto la v1.0.0 il 29 marzo. Il rilascio aggiunge liste calendario private usando event Nostr cifrati (kind 32123) con auto-cifratura NIP-44 (Encrypted Payloads), così gli utenti possono organizzare gli eventi in collezioni private senza esporre il raggruppamento ai relay. Lo stesso rilascio aggiunge la gestione degli intent ICS per importare dati calendario da altre applicazioni e richieste di invito per condividere eventi tra utenti.

Amber v5.0.2 fino a v5.0.4

Amber, l’app signer NIP-55 (Android Signer Application), ha distribuito tre point release: v5.0.2, v5.0.3, e v5.0.4. L’aggiunta più visibile è il login tramite frase mnemonica di recovery (PR #358), che permette agli utenti di ripristinare il proprio signer da una seed phrase BIP39 invece di richiedere la stringa nsec o ncryptsec grezza. La PR #357 aggiunge una whitelist relay auth NIP-42, così gli utenti possono limitare quali relay sono autorizzati a richiedere l’autenticazione client. La PR #353 aggiunge la selezione dell’ambito di cifratura per i permessi di decrypt, permettendo agli utenti di concedere accesso di decrypt solo NIP-04 o solo NIP-44 invece di un permesso generale. La v5.0.4 corregge un bug in cui il rifiuto non rispettava i permessi scoped di encrypt e decrypt e migliora le prestazioni quando arrivano più richieste bunker.

Aegis v0.4.0

Aegis, il signer cross-platform, ha distribuito la v0.4.0 il 26 marzo. Il rilascio aggiunge le modalità di autorizzazione Full e Selective nelle Impostazioni e corregge diversi problemi di scansione QR. I commit successivi d4f799f, 3313af9, 3b214e4, e e4f40b6 continuano lo stesso lavoro con controlli batch select, statistiche riutilizzabili sulle selezioni batch, API set-all-groups selection, e statistiche di utilizzo per permesso nella pagina dei permessi dell’app.

Schemata v0.2.7 fino a v0.3.0

Schemata, le definizioni JSON Schema per la validazione dei kind di event Nostr, ha distribuito quattro rilasci dalla v0.2.7 alla v0.3.0 con 21 PR unite. Il rilascio v0.3.0 porta correzioni di coerenza dei pattern per URL relay, ID hex, tipi MIME, e stringhe BOLT-11 (PR #126), centralizzazione dei pattern URL relay (PR #117), schemi del tipo base bech32 NIP-19 (PR #118), e validazione per gli event spell kind 777 (PR #125). La pipeline di rilascio ora pubblica una nota kind 1 su Nostr per ogni rilascio (PR #120), così il progetto si annuncia attraverso il protocollo che valida. Schemata ora supporta una dozzina di linguaggi oltre al pacchetto canonico JS/TS: Rust, Go, Python, Kotlin, Java, Swift, Dart, PHP, C#/.NET, C++, Ruby, e C.

Accanto a Schemata, il team ha pubblicato schemata-codegen, un generatore di codice sperimentale che affronta lo stesso problema di validazione con un approccio diverso. Dove i pacchetti validator di Schemata richiedono una dipendenza runtime da JSON Schema, schemata-codegen converte gli schemi direttamente in costrutti tipizzati nativi del linguaggio (tuple tipizzate per tag, interfacce kind, e validator runtime), rimuovendo la necessità di una libreria validator a runtime. Il documento codegen-vs-validators comparison spiega quando ciascun approccio è adatto.

BigBrotr v6.5.0 fino a v6.5.4

BigBrotr, la piattaforma di analisi relay, ha distribuito cinque rilasci dalla v6.5.0 alla v6.5.4. La v6.5.0 centralizza la validazione degli URL relay con una factory function parse_relay_url() e aggiunge controlli sulla lunghezza URL e sanitizzazione dei path. Anche l’infrastruttura di monitoraggio ha ricevuto correzioni: gli event di annuncio ora includono tag di geolocalizzazione geohash (seguendo NIP-52), ed è stata aggiunta protezione timeout ai test di metadati Geo/Net NIP-66 che non avevano scadenza e potevano bloccarsi indefinitamente. La PR #410 aggiorna PostgreSQL dalla 16 alla 18, portando il sottosistema async I/O e un throughput WAL migliorato alla pipeline di analisi relay.

Il relay Vertex Lab aggiunge la ricerca profili NIP-50

Vertex Lab, il team dietro npub.world e il motore Web of Trust Vertex, ha annunciato che wss://relay.vertexlab.io ora supporta NIP-50 (Search) per le query sui profili. NIP-50 estende il filtro standard REQ di Nostr con un campo search, permettendo ai client di inviare query full-text ai relay che supportano l’indicizzazione. Aggiungere la ricerca profili a un relay che serve già dati Web of Trust significa che i client connessi a relay.vertexlab.io possono scoprire utenti per nome o descrizione senza un servizio di ricerca separato.

Hashtree v0.2.17 e v0.2.18 distribuiscono mesh WebRTC e Iris Desktop

Hashtree, il sistema di storage blob content-addressed di mmalmi che pubblica radici Merkle su Nostr, ha distribuito la v0.2.17 e la v0.2.18 il 31 marzo. I due rilasci chiudono uno sprint di 30 commit che aggiunge tre capacità distinte. Primo, il crate hashtree-webrtc (rinominato hashtree-network nella v0.2.18) aggiunge distribuzione blob peer-to-peer basata su WebRTC con segnalazione mesh unificata attraverso la CLI Rust, l’harness di simulazione, e il client TypeScript. Secondo, la pipeline di rilascio ora costruisce artefatti Windows (zip CLI e installer Iris), portando copertura cross-platform su macOS, Linux e Windows. Terzo, entrambi i rilasci includono Iris Desktop 0.1.0, il client social Nostr di mmalmi, come asset AppImage, .deb e installer Windows accanto alla CLI hashtree. Hashtree è stato trattato per la prima volta nella Newsletter #10 quando è stato lanciato come store compatibile Blossom basato su filesystem. Il livello WebRTC è il primo passo verso una distribuzione dei contenuti peer-to-peer senza dipendere da server Blossom centralizzati.

Nostr Mail Client v0.7.0 fino a v0.7.2

Nostr Mail Client, il client in stile email Flutter costruito su identità Nostr, ha distribuito la v0.7.0, la v0.7.1, e la v0.7.2 in tre giorni. Il lavoro di prodotto più visibile si è concentrato su onboarding (PR #9) e modifica profilo (PR #10), elementi di base per qualsiasi client che cerca di presentare Nostr come una casella di posta. Le point release successive hanno impacchettato quel lavoro in nuove build Android e Linux.

Wisp v0.14.0 fino a v0.16.1

Wisp, il client Nostr Android, ha distribuito altri 13 rilasci dalla v0.14.0-beta alla v0.16.3-beta. Il lavoro di questa settimana include correzioni al JSON rumor NIP-17 (PR #385), badge repost sulle gallery card (PR #383), dettagli delle reazioni espandibili (PR #382), set emoji persistenti (PR #381), e controlli di autoplay video (PR #380). L’ultima v0.16.3-beta corregge anche shortcode emoji personalizzate con trattini e tag emoji mancanti.

Primal Android 3.0.17

Primal Android ha distribuito la 3.0.17 il 24 marzo. La PR #1000 mappa i tipi WalletException in codici errore nelle risposte NWC, dando ai client NIP-47 informazioni di errore strutturate invece di errori generici. La PR #995 corregge i voti zap dei sondaggi che apparivano come Top Zaps, e la PR #998 nasconde il saldo wallet e i pulsanti di azione quando non è configurato alcun wallet.

OpenChat v0.2.4 fino a v0.3.0

OpenChat, il client chat basato su Avalonia costruito sullo stack Marmot, ha distribuito sei rilasci dalla v0.2.4 alla v0.3.0 in quattro giorni. Il log dei commit racconta la storia di un client che colma il divario tra “Marmot funziona” e “qualcuno può davvero usarlo ogni giorno”. È arrivata l’autenticazione relay NIP-42, seguita da una UI relay picker con filtraggio degli event duplicati. I messaggi vocali hanno ottenuto pausa, ripresa, seek e visualizzazione del tempo. Il percorso signer è stato rafforzato: le connessioni Amber sono state corrette con un formato URI NIP-46 aggiornato, il WebSocket si riconnette automaticamente prima di inviare le richieste, e le richieste Amber duplicate ora vengono intercettate controllando le risposte riprodotte. Sul lato storage, Linux e macOS hanno ottenuto secure storage AES-256-GCM con chiavi salvate su file, e il recupero dei metadata utente ora usa la discovery relay NIP-65 e mette in cache i risultati in un database locale.

Igloo Signer 1.1

Igloo, il signer threshold FROST per iOS del progetto FROSTR, ha distribuito la v1.1 il 28 marzo. Le firme FROST (Flexible Round-Optimized Schnorr Threshold) permettono a un gruppo di signer di controllare collettivamente un keypair Nostr, dove qualsiasi insieme t-of-n di partecipanti può firmare un event senza che nessuna singola parte possieda la chiave privata completa. Igloo è una delle prime implementazioni mobili di questo approccio per Nostr.

nak v0.19.3 e v0.19.4

nak, il toolkit Nostr a riga di comando di fiatjaf, ha distribuito la v0.19.3 e la v0.19.4 il 26 e 30 marzo. Entrambi i rilasci correggono condizioni di panic: la PR #118 sostituisce strings.Split con strings.Cut per prevenire un potenziale accesso out-of-bounds, e la PR #119 previene la stessa classe di panic nel parsing dei flag curl.

Flora v0.3.0

Flora, un’estensione Chrome per screen recording e condivisione decentralizzati su Nostr, ha distribuito la v0.3.0. Il rilascio aggiunge condivisione video privata cifrata con modalità pubblica, non in elenco e privata. Le registrazioni private sono cifrate con AES-256-GCM e consegnate ai destinatari tramite NIP-17 (Private Direct Messages), così la registrazione non tocca mai un server in chiaro.

YakiHonne Mobile 2.0.3

YakiHonne, il client mobile Nostr, ha distribuito la 2.0.3 con recensioni relay e join request, risposte nidificate ampliate, traduzione automatica delle note, e supporto multi-relay NWC.

Aggiornamenti Progetti

Zap Cooking aggiunge zap poll e verifica dei pagamenti Branta

Zap Cooking, la piattaforma di ricette e contenuti, ha unito 11 PR questa settimana focalizzate su contenuti interattivi e flussi di pagamento. La PR #277 aggiunge gli zap poll (kind 6969), in cui gli utenti votano inviando sats e possono vedere le liste dei votanti con foto profilo. La PR #274 ridisegna la UX dei sondaggi in modo che l’interfaccia di voto si integri più naturalmente nel feed.

La PR #276 aggiunge scansione QR tramite fotocamera al flusso Send Payment e integra Branta, un servizio di verifica che controlla se una destinazione di pagamento è legittima prima dell’invio. Branta verifica le destinazioni di pagamento contro phishing, address swap e intercettazioni man-in-the-middle prima dell’invio. Nell’implementazione di Zap Cooking, un nome piattaforma e logo verificati da Branta appaiono direttamente nel flusso di pagamento, e i QR code abilitati a Branta possono trasportare parametri branta_id e branta_secret così il wallet può verificare la destinazione direttamente dal codice scansionato.

diVine prepara le basi per una ricerca unificata e rafforza la consegna video

diVine, il client di video brevi, ha passato la settimana a stringere ricerca, navigazione del feed, recovery della riproduzione, e comportamento di upload. La PR #2540 getta le basi per una schermata di ricerca unificata, con sezioni raggruppate per Video, Persone, e Tag. La PR #2623 rafforza la paginazione su feed profilo, inbox, notifiche, liste discover, classic vines, ricerca, e feed a griglia componibili spostandoli su un controller di paginazione condiviso.

Anche la consegna video ha ricevuto diverse correzioni concrete. La PR #2643 ritenta in ordine le sorgenti derivate ospitate da Divine e ricade sul blob grezzo prima di mostrare un errore di riproduzione, così fallimenti transitori su una sorgente non uccidono subito la riproduzione. La PR #2634 mantiene gli upload resumable sul percorso gestito da Divine quando il capability probing fallisce temporaneamente, riducendo gli upload rotti causati da brevi guasti di rete. La PR #2637 cambia anche il filtro dei contenuti sensibili in modo che i video siano bloccati rigidamente solo per etichette di avviso reali, non semplicemente per content warning impostati dal creatore.

Shopstr aggiunge storefront personalizzati e Milk Market continua a distribuire lavoro di marketplace

Shopstr, il marketplace basato su Nostr, ha unito la PR #245 aggiungendo storefront personalizzati. Questo dà ai venditori una superficie home più distintiva invece di costringere ogni annuncio nella stessa presentazione generica.

Milk Market, un marketplace dedicato al latte, ha continuato con ottimizzazioni degli storefront (PR #18), account recovery (PR #17), beef splits (PR #15), e correzioni ai tipi degli strumenti MCP (PR #16).

Notedeck aggiunge effetti sonori e estende il suo percorso updater verso Android

Notedeck, il client desktop del team Damus, ha unito la PR #1412 aggiungendo un sottosistema di effetti sonori con suoni di interazione UI usando rodio, e la PR #1399 con aggiornamenti Agentium inclusi un flag CLI per il titolo e cartelle di sessione comprimibili. Una PR #1417 aperta propone l’auto-aggiornamento APK via Nostr/Zapstore su Android, costruendo sul lavoro updater nativo Nostr di Notedeck dalla Newsletter #14.

Nostria aggiunge relay hint per i repost e allineamento NIP-98

Nostria ha unito la PR #583 aggiungendo relay hint NIP-18 (Reposts) ai tag e dei repost per gli event kind 6 e kind 16, la PR #582 allineando l’HTTP auth Brainstorm (kind 27235) ai tag richiesti da NIP-98 (HTTP Auth), e la PR #576 aggiungendo test di validazione degli schemi Schemata. Il cambiamento NIP-98 significa che Nostria può autenticarsi verso servizi esterni usando lo stesso formato HTTP auth che usano gli altri client.

Nostr-Doc aggiunge packaging desktop e lavoro offline-first

Nostr-Doc, l’editor collaborativo di Form*, ha avuto una settimana intensa di packaging e lavoro sull’editor. Il commit fcdc00a aggiunge un’app desktop, il commit 3977a8e avvia il lavoro sull’app nativa, e il commit 413a030 spinge l’app verso un comportamento offline-first. Sul lato editor, il commit 1855ce8 aggiunge salvataggio Ctrl+S, avvisi di salvataggio, correzioni alle anteprime link, e rendering corretto del barrato.

rust-nostr ottimizza il parsing NIP-21 e aggiunge supporto NIP-62 lato relay

rust-nostr ha unito otto PR. La più notevole è la PR #1308, che ottimizza il parsing degli URI NIP-21 in PublicKey::parse allineandolo alle prestazioni standard del parsing bech32. In precedenza, gli URI NIP-21 richiedevano circa il doppio del tempo per essere analizzati rispetto alle chiavi bech32 grezze. Il progetto ha anche quattro PR aperte che aggiungono supporto specifico relay a NIP-62 (Request to Vanish) nei backend memory, LMDB, SQLite, e database test (PR #1315, PR #1316, PR #1317, PR #1318).

nostr-tools aggiunge controllo relay bunker e corregge il parsing multi-relay NIP-47

nostr-tools ha unito la PR #530 aggiungendo skipSwitchRelays ai BunkerSignerParams per la gestione manuale dei relay, e la PR #529 correggendo il parsing delle stringhe di connessione NIP-47 (Nostr Wallet Connect) per supportare più relay come consente la specifica.

Nostrability integra i dati di audit Sherlock e pubblica una panoramica di Schemata

Nostrability, l’interoperability tracker per i client Nostr, ha unito 14 PR. La PR #306 integra le statistiche delle scansioni Sherlock nella dashboard. Sherlock è lo strumento di audit automatizzato di Nostrability che si connette ai client Nostr, cattura gli event che pubblicano, e valida ogni event rispetto alle definizioni JSON Schema di Schemata per rilevare violazioni della specifica. La dashboard ora mostra i tassi di fallimento degli schemi per client (PR #315) così gli sviluppatori possono vedere quali kind di event il proprio client sbaglia. La PR #323 rivede il workflow di pubblicazione Nostr in modo che gli annunci di rilascio girino come job separato che non può essere cancellato da step CI precedenti.

elsat ha anche pubblicato Schemata for nostr devs il 30 marzo, descrivendo come schemata, schemata-codegen e Sherlock si incastrano e dando i numeri attuali di copertura: 179 schemi di kind event su 65 NIP, 154 schemi di tag, 13 messaggi di protocollo, e 310 event di esempio.

Nalgorithm aggiunge generazione digest e caching locale del punteggio

Nalgorithm, un nuovo progetto feed Nostr ordinato per rilevanza, ha avviato lo sviluppo pubblico questa settimana. Il commit cf6c501 imposta l’app web iniziale che recupera i post dai follow e li valuta rispetto a un prompt di preferenze definito dall’utente. Il commit 8e931b6 aggiunge uno strumento CLI digest che trasforma i post più rilevanti in un riepilogo parlato, mentre il commit 4cb9c63 aggiunge caching del punteggio basato su file e evoluzione incrementale del prompt appreso a partire dai like recenti. Il commit c2edfb8 smette anche di mettere in cache i fallback score da batch falliti, così un fallimento transitorio del punteggio non appiattisce permanentemente il ranking di un post.

TENEX aggiunge vector store RAG e startup MCP mirato

TENEX, il framework agenti nativo Nostr che collega agenti AI ai canali Nostr via Telegram, ha unito sette PR questa settimana. La PR #101 aggiunge un’astrazione vector store pluggable con backend SQLite-vec, LanceDB, e Qdrant, dando agli agenti retrieval-augmented generation senza vincolarsi a un singolo database vettoriale. La PR #102 rende lo startup MCP mirato: vengono avviati solo i server MCP i cui strumenti un agente usa davvero, invece di lanciare tutti i server subito alla prima esecuzione. La PR #100 aggiunge uno strumento send_message così gli agenti con binding ai canali Telegram possono inviare messaggi proattivamente invece di limitarsi a rispondere a quelli in arrivo. La PR #106 evita uno spawn di sottoprocesso che attivava una pre-allocazione da 9GB di memoria Bun/JSC leggendo .git/HEAD direttamente invece di eseguire git branch.

Dart NDK sposta il signer Amber e aggiunge Alby Go 1-click

Dart NDK, il Flutter Nostr development kit, ha distribuito 11 PR unite. La PR #525 sposta il supporto al signer Amber nel pacchetto ndk_flutter, e la PR #552 aggiunge la connessione wallet one-click Alby Go all’app di esempio. La PR #502 aggiunge uno script install.sh per la CLI, e la PR #523 rimuove la dipendenza dal verifier Rust a favore della gestione nativa degli asset.

Lavoro su Protocollo e Specifica

Marmot sposta i KeyPackage su event indirizzabili e stringe le push notification

La specifica Marmot ha unito quattro PR che cambiano il modo in cui il protocollo gestisce il materiale chiave e l’appartenenza ai gruppi. La PR #54 migra gli event KeyPackage dal normale kind:443 al kind:30443 indirizzabile con tag d, eliminando la necessità di cancellazione event NIP-09 durante la rotazione delle chiavi. Gli event indirizzabili si sovrascrivono sul posto, rendendo la rotazione auto-contenuta. La PR #57 permette agli utenti non admin di fare commit di proposte SelfRemove (uscita volontaria dal gruppo), e la PR #62 richiede agli admin di rinunciare allo status di admin prima di usare SelfRemove, impedendo a un admin di sparire mantenendo ancora privilegi elevati.

La PR #61 stringe il formato delle push notification MIP-05, rendendo espliciti la codifica base64 single-blob, il versioning, il formato wire del token, e l’uso delle chiavi x-only. L’effetto è una singola rappresentazione wire definita per token blob e chiavi x-only attraverso la specifica, le librerie client, e i backend delle app. L’implementazione di questi cambi di specifica è arrivata nello stack White Noise questa settimana ed è coperta nella sezione White Noise v2026.3.23 sopra.

Aggiornamenti NIP

Modifiche recenti al repository NIPs:

Uniti:

NIP-5A: Siti Web Statici (PR #1538): Definisce gli event manifesto kind 15128 (sito root) e kind 35128 (sito con nome) per ospitare siti statici sotto keypair Nostr usando lo storage Blossom. Vedi il deep dive sotto.
NIP-30 (Custom Emoji): Permettere i trattini negli shortcode (PR #2297): Aggiorna la descrizione degli shortcode per includere i trattini. Gli shortcode con trattini sono stati usati nella pratica fin dall’introduzione del NIP, quindi la specifica ora documenta l’uso corrente.

PR Aperte e Discussioni:

NIP-C1: Agent TUI Messages (PR #2295): Propone un formato di messaggio strutturato per gli agenti che inviano elementi UI interattivi tramite DM cifrati, inclusi payload tipizzati text, buttons, card, e table. La bozza mantiene tutto dentro il contenuto JSON degli existing DM NIP-17 e NIP-04. Non definisce un nuovo kind di event e usa un semplice formato stringa callback per le risposte ai pulsanti.
NIP-95: Hybrid Peer-to-Peer Relay Protocol (PR #2293): Propone un modello relay ibrido in cui i relay restano autorevoli ma possono anche coordinare la distribuzione peer-to-peer degli event recenti via WebRTC. La bozza introduce messaggi relay come PEER_REGISTER, PEER_REQUEST, e PEER_OFFER, con client stabili che agiscono da Super Peer e il relay che funge da seed node e fallback.
NIP-B9: Zap Poll Events (PR #2284): Riapre la vecchia idea NIP-69 degli zap-poll ora che NIP-88 (Polls) copre i sondaggi gratuiti. La bozza usa definizioni di sondaggi kind 6969 e zaps kind 9734 come voti, rendendolo un sistema di polling a pagamento con resistenza economica ai Sybil. Completa i sondaggi gratuiti one-key-one-vote.
NIP-AD: Super Zap (PR #2289): Propone una convenzione in cui gli zap inviati alla pubkey di un relay o a quella di un client vengono mostrati come note promozionali specializzate, trasformando di fatto le zap receipt in una superficie pubblicitaria. Gli operatori relay e i client pubblicherebbero profili con lud16, recupererebbero quelle receipt, estrarrebbero il contenuto incorporato dalle descrizioni zap, e potrebbero opzionalmente impostare soglie minime in sats per sopprimere lo spam.
NIP-XX: Agent Reputation Attestations (PR #2285): Propone kind 30085 come event sostituibile parametrizzato per attestazioni strutturate di reputazione sugli agenti Nostr. La bozza evita un singolo punteggio globale rendendo la reputazione dipendente dall’osservatore, aggiunge decadimento temporale così le attestazioni vecchie perdono peso, supporta rating negativi con requisiti di evidenza, e abbozza sia punteggio ponderato semplice sia punteggio di diversità del grafo per migliore resistenza Sybil.
NIP-XX: Paid API Service Announcements (PR #2291): Propone event indirizzabili kind 31402 per pubblicizzare API HTTP a pagamento, con Nostr che gestisce discovery e pagamento tramite HTTP 402. La bozza è tags-first così i relay possono filtrare su metodi di pagamento, prezzi e capacità senza fare parsing di contenuto JSON, e permette schemi opzionali di richiesta e risposta così client o agenti possono auto-generare le chiamate.
NIP-XX: Key Derivation from LNURL-auth via SplitSig (PR #2294): Propone di derivare un keypair Nostr da una firma ECDSA LNURL-auth combinata con un nonce casuale lato client. La formula di derivazione è nsec = SHA256(ecdsa_signature || nonce). Il server vede la firma ECDSA (intrinseca all’handshake LNURL-auth) ma non vede mai il nonce, e il browser genera il nonce ma non controlla la firma. Nessun pezzo da solo può derivare l’nsec. L’obiettivo è che lo stesso wallet Lightning produca la stessa chiave Nostr su dispositivi diversi, con il wallet come àncora di recovery e nessun server in grado di ricostruire la chiave privata.
NIP-55: Documentare il campo rejected (PR #2290): Documenta il campo rejected per le risposte dei signer intent-based, formalizzando il comportamento che la correzione di Amethyst v1.07.x ha dovuto aggirare.

NIP Deep Dive: NIP-5A (Siti Web Statici)

NIP-5A definisce come ospitare siti web statici sotto keypair Nostr, usando due kind di event e l’infrastruttura blob esistente per trasformare event firmati in pagine web servite. La specifica è stata unita il 25 marzo tramite PR #1538.

Il modello usa kind 15128 per un sito root, uno per pubkey, e kind 35128 per siti con nome identificati da un tag d. Ogni manifesto mappa percorsi URL assoluti agli hash SHA256. Ecco un manifesto di sito root:

{
 "id": "5324d695ed7abf7cdd2a48deb881c93b7f4e43de702989bbfb55a1b97b35a3de",
 "pubkey": "266815e0c9210dfa324c6cba3573b14bee49da4209a9456f9484e5106cd408a5",
 "created_at": 1743465600,
 "kind": 15128,
 "tags": [
 ["path", "/index.html", "186ea5fd14e88fd1ac49351759e7ab906fa94892002b60bf7f5a428f28ca1c99"],
 ["path", "/about.html", "a1b2c3d4e5f6789012345678901234567890abcdef1234567890abcdef123456"],
 ["path", "/favicon.ico", "fedcba0987654321fedcba0987654321fedcba0987654321fedcba0987654321"],
 ["server", "https://blossom.primal.net"],
 ["title", "My Nostr Site"],
 ["description", "A static website hosted on Nostr"],
 ["source", "https://github.com/lez/nsite"]
 ],
 "content": "",
 "sig": "f4e4a9e785f70e9fcaa855d769438fea10781e84cd889e3fcb823774f83d094cf2c05d5a3ac4aebc1227a4ebc3d56867286c15a6df92d55045658bb428fd5fb5"
}

Il flusso di serving funziona in tre passaggi. Un server host riceve una richiesta HTTP, estrae la pubkey dell’autore dal sottodominio (un npub per i siti root o una pubkey codificata base36 per i siti con nome), recupera la relay list dell’autore tramite NIP-65, e interroga il manifesto del sito. Una volta trovato il manifesto, il server risolve il path richiesto in un hash di contenuto, scarica il blob corrispondente dal server o dai server Blossom elencati nei tag server, e lo restituisce.

Il formato del sottodominio DNS è strettamente specificato. I siti root usano l’npub standard come sottodominio. I siti con nome usano una codifica base36 di 50 caratteri della pubkey grezza seguita dal valore del tag d, tutto in una singola etichetta DNS. Poiché le etichette DNS sono limitate a 63 caratteri e la codifica base36 ne occupa sempre 50, il tag d è limitato a 13 caratteri. La specifica richiede anche che i tag d corrispondano a ^[a-z0-9-]{1,13}$ e non terminino con un trattino, evitando ambiguità nella risoluzione DNS.

L’uso di hash del contenuto significa che lo stesso sito può essere servito da server host diversi, e l’integrità dei file è verificabile senza fidarsi del server. Un server host non ha bisogno di memorizzare alcun file localmente. Li recupera on demand da Blossom usando gli hash nel manifesto. Questo significa che l’autore controlla ciò che viene servito, il server Blossom memorizza i file grezzi, e il server host si limita a collegare i due. Ciascuno di questi tre componenti può essere sostituito indipendentemente.

Le implementazioni esistenti includono nsite, il server host che risolve i manifesti e serve i file, e nsite-manager, una UI per costruire e pubblicare i manifesti. La specifica ha aggiunto anche un tag source per collegare il repository del codice sorgente del sito, e l’aggiornamento del README unito separatamente nella PR #2286 ha registrato sia il kind 15128 sia il 35128 nell’indice dei kind NIP.

NIP Deep Dive: NIP-62 (Request to Vanish)

NIP-62 definisce kind 62 come una richiesta ai relay di cancellare tutti gli event della pubkey richiedente. La specifica ha una motivazione legale: nelle giurisdizioni con leggi sul diritto all’oblio, avere una richiesta di cancellazione standardizzata e firmata dà agli operatori relay un segnale chiaro su cui agire.

{
 "id": "a7b8c9d0e1f23456789012345678901234567890abcdef1234567890abcdef12",
 "pubkey": "f1e2d3c4b5a697887766554433221100ffeeddccbbaa99887766554433221100",
 "created_at": 1743465600,
 "kind": 62,
 "tags": [
 ["relay", "wss://relay.example.com"]
 ],
 "content": "Requesting deletion of all events from this relay.",
 "sig": "11aa22bb33cc44dd55ee66ff77889900aabbccddeeff0011223344556677889911aa22bb33cc44dd55ee66ff77889900aabbccddeeff00112233445566778899"
}

La specifica separa le richieste vanish mirate da quelle globali. Una richiesta mirata include tag relay specifici che identificano i relay che devono agire. Una richiesta globale usa la stringa letterale ALL_RELAYS come valore del tag relay, chiedendo a ogni relay che vede l’event di cancellare tutti gli event di quella pubkey. I relay che rispettano la richiesta devono anche assicurarsi che gli event cancellati non possano essere ripubblicati di nuovo nel relay, rendendo la cancellazione persistente.

NIP-62 va oltre NIP-09 (Event Deletion) sia per ambito che per intento. NIP-09 permette di cancellare singoli event, e i relay MAY rispettarlo. NIP-62 chiede la cancellazione di tutto, e la specifica dice che i relay MUST rispettare la richiesta se il loro URL è taggato. Chiede anche ai relay di cancellare gli event NIP-59 (Gift Wrap) che contengono un p-tag verso la pubkey richiedente, il che significa che i DM in arrivo vengono ripuliti insieme agli event dell’utente. Pubblicare una cancellazione NIP-09 contro una richiesta vanish NIP-62 non ha effetto: una volta che fai vanish, non puoi annullare il vanish cancellando la richiesta di vanish.

Questa settimana, Amethyst v1.07.0 ha distribuito il supporto client-side a NIP-62, permettendo agli utenti di avviare richieste vanish dall’app. Sul lato relay, rust-nostr ha quattro PR aperte che aggiungono il supporto NIP-62 nei backend memory, LMDB, SQLite, e database test (PR #1315, PR #1316, PR #1317, PR #1318). Questo mette il lavoro di supporto lato client e lato relay nella stessa settimana.

Il design del protocollo introduce una tensione pratica. La proposta di valore di Nostr include la resistenza alla censura, cioè i relay non dovrebbero essere in grado di impedire la pubblicazione. NIP-62 introduce un caso in cui un relay MUST impedire la ripubblicazione da una specifica pubkey. Le due proprietà convivono perché la richiesta è auto-diretta: chiedi la cancellazione dei tuoi event, non di quelli di qualcun altro. La proprietà di resistenza alla censura rimane intatta per tutti tranne che per la persona che ha scelto esplicitamente di uscirne.

Questo è tutto per questa settimana. Stai costruendo qualcosa o hai notizie da condividere? Contattaci tramite DM NIP-17 (Private Direct Messages) o trovaci su Nostr.

Nostr Compass #15

Wed, 25 Mar 2026 00:00:00 +0000

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

Questa settimana: Primal Android fa seguito al suo rilascio wallet 3.0 con Follow Pack, arricchimento zap e deep link primalconnect://. BigBrotr pubblica un’analisi delle nsec esposte scansionando 41 milioni di event su 1.085 relay, trovando 16.599 chiavi private valide, mentre npub.world integra gli avvisi di esposizione nelle pagine profilo la stessa settimana. Martti Malmi lancia nostr-vpn, un’alternativa a Tailscale che segnala tramite relay Nostr e crea tunnel WireGuard, distribuendo 11 rilasci in sette giorni. Il team Vector rilascia in open-source DOOM P2P su Nostr, FIPS distribuisce la v0.2.0, e Nostrability Schemata si espande a sei linguaggi in una settimana.

Notizie

Primal aggiunge Follow Pack, arricchimento zap e deep link

Come da copertura della 3.0.7 della settimana scorsa, Primal Android ha dedicato questa settimana al lavoro post-rilascio su onboarding, UX del composer e contesto wallet. L’onboarding ridisegnato introduce i Follow Pack (PR #949), un pulsante GIF nativo si unisce al composer delle note, un servizio di arricchimento zap (PR #979) annota le transazioni wallet con il contesto zap, e un protocollo di deep-linking primalconnect:// (PR #969) abilita la navigazione cross-app.

Primal iOS sta distribuendo lo stesso lavoro tramite TestFlight in parallelo, con lo switch wallet (PR #191), l’implementazione dei sondaggi e il refactoring dell’onboarding che arrivano nella stessa finestra.

BigBrotr mappa le chiavi private esposte nella rete relay

BigBrotr, la piattaforma di analisi relay Nostr, ha pubblicato un’analisi dettagliata delle chiavi private esposte nella rete relay. Lo studio ha scansionato 41 milioni di event da 1.085 relay, cercando stringhe nsec valide incorporate nel contenuto degli event, e ha trovato 16.599 chiavi private valide. Quel numero sembra allarmante finché non si filtra un bot chiamato “Mr.nsec” che rappresenta il 92% delle corrispondenze. Dopo aver rimosso il traffico bot, solo 38 account reali con più di 21.000 follower combinati avevano chiavi esposte, e nessuno mostrava segni di consapevolezza che le proprie chiavi fossero pubbliche.

Il team ha costruito un nsec-leak-checker come servizio NIP-90 (Data Vending Machine), permettendo agli utenti di verificare se la loro chiave privata appare ovunque nel dataset scansionato senza rivelare la chiave al verificatore. npub.world ha integrato i dati di esposizione la stessa settimana, mostrando banner di avviso sulle pagine profilo dove sono state rilevate chiavi esposte. La combinazione dà alla rete sia un’interfaccia programmatica per DVM e agenti sia un avviso leggibile per gli utenti comuni. Il dataset sottostante alimenta anche BigBrotr v6.4.0, che aggiunge viste materializzate per event sostituibili e indirizzabili e una correzione del timeout di inattività del sincronizzatore.

Nostr VPN si lancia come alternativa a Tailscale

Martti Malmi (mmalmi), creatore di Iris, ha costruito e distribuito nostr-vpn, una VPN peer-to-peer che usa relay Nostr per la segnalazione e WireGuard (tramite boringtun) per tunnel cifrati. La motivazione era diretta: “Mi sono irritato che Tailscale richieda account di terze parti, quindi ho creato Nostr VPN.” Lo strumento crea reti mesh tra dispositivi usando keypair Nostr come identità, senza server di coordinamento centrale.

Il progetto ha distribuito 11 rilasci in sette giorni, dalla v0.2.2 alla v0.2.13. Quello sprint ha aggiunto il supporto Windows, il pairing LAN per la scoperta nella rete locale, e un sidecar Android per dispositivi mobili. L’architettura è semplice: due dispositivi si scambiano metadati di connessione tramite relay Nostr, poi stabiliscono un tunnel WireGuard diretto. Nostr gestisce la scoperta e la segnalazione per l’attraversamento NAT. WireGuard gestisce il traffico effettivo. L’identità è un keypair Nostr.

Malmi ha anche continuato a sviluppare nostr-double-ratchet, una libreria per canali di messaggistica sicura in stile Signal, distribuendo sei rilasci dalla v0.0.86 alla v0.0.93 durante la stessa settimana.

DOOM open-source gira peer-to-peer su Nostr

Il team Vector ha rilasciato in open-source un’implementazione multiplayer peer-to-peer di DOOM che usa Nostr per la scoperta dei peer, Marmot per la cifratura end-to-end, e Iroh, la libreria di networking QUIC di n0, per il trasporto gossip. Il gioco viene distribuito come file WebXDC da 4,2 MB che può essere inviato all’interno di messaggi chat, senza richiedere server per ospitare o coordinare una partita.

L’approccio tecnico sostituisce il netcode lockstep originale del 1993 con un modello di sincronizzazione ibrido in tempo reale. I giocatori si scoprono a vicenda tramite query ai relay Nostr, negoziano le sessioni attraverso canali cifrati con Marmot, poi passano al livello gossip QUIC di Iroh per il traffico di gioco a bassa latenza. Lo stack usa Nostr per la scoperta, Marmot per la cifratura, e Iroh per il trasporto.

Vector ha anche distribuito hardening di sicurezza questa settimana. Il rilascio aggiunge un vault di chiavi con protezione della memoria con protezioni anti-debug e zeroize per il materiale chiave sensibile, blocco utenti con filtraggio completo di DM e messaggi di gruppo, e correzioni del canale realtime WebXDC per le Mini App.

FIPS v0.2.0 distribuisce trasporto Tor, build riproducibili e esempi sidecar

FIPS, il Free Internetworking Peering System e progetto di networking mesh adiacente a Nostr, ha distribuito la v0.2.0. Il rilascio aggiunge supporto al trasporto Tor per link mesh anonimizzati, build riproducibili, un esempio sidecar che si connette attraverso un relay Nostr, e pubblicazione dei rilasci su Nostr nel workflow del pacchetto OpenWrt. Il rilascio corregge anche i picchi di jitter post-rekey causati da frame della finestra di drain. Il formato wire è cambiato dalla v0.1.0, quindi i nodi v0.1.0 esistenti non possono interoperare con la v0.2.0 senza aggiornamento.

Nostrability Schemata diventa multilingue

Il progetto Nostrability Schemata, che mantiene definizioni JSON Schema per la validazione dei kind di event Nostr, si è espanso dal solo JavaScript a sei linguaggi in una settimana. Nuovi pacchetti sono stati distribuiti per Rust, Go, Dart, Swift e Python, ognuno fornendo sia un pacchetto dati che un validatore. La v0.2.6 ha anche aggiunto 17 nuovi schemi di kind event.

Il tracker di interoperabilità Nostrability ha ricevuto una revisione parallela. Una nuova scheda What’s New pubblica aggiornamenti sia tramite un feed Atom che un event Nostr, il filtraggio per categoria app permette ai visitatori di esplorare tipi specifici di client, e il tracker ora rileva automaticamente i linguaggi di programmazione dai metadati dei repository GitHub. Nostrability ha anche il suo npub ora, rendendo il progetto stesso scopribile attraverso il protocollo che documenta. Per gli autori di librerie che lavorano su più linguaggi, i pacchetti schema multi-linguaggio significano che le stesse definizioni di kind event sono disponibili come import nativi invece di richiedere ad ogni progetto di mantenere la propria copia dello schema.

Rilasci

Amethyst v1.06.0 e v1.06.1

Amethyst, il client Android mantenuto da vitorpamplona, ha distribuito la v1.06.0 e la v1.06.1 il 23 marzo. La funzionalità principale è il supporto ai sondaggi usando dati NIP-85 (Trusted Assertions) per il voto ponderato, con card ridisegnate per sondaggi e sondaggi zap. Il nuovo rendering dà sia ai sondaggi standard che ai sondaggi con peso zap un layout visivo più pulito. La v1.06.1 segue con correzioni di crash per modifiche concorrenti che risolvono regressioni di stabilità introdotte nel percorso di rendering dei sondaggi.

Amber v5.0.0 e v5.0.1

Amber, l’app signer NIP-55 (Android Signer Application), ha promosso il suo recente lavoro pre-release 4.1.x in stabile con la v5.0.0 il 18 marzo. Quel rilascio stabile porta le modifiche di relay-auth NIP-42, Tor integrato, permessi specifici per tipo di contenuto e storage PIN cifrato coperte la settimana scorsa. La v5.0.1 rimuove poi il permesso internet dal build flavor offline, in modo che quel build non possa più effettuare richieste di rete a livello di permessi Android.

Mostro v0.17.0 e Mostro Mobile v1.2.2

Mostro, lo scambio Bitcoin peer-to-peer costruito su Nostr, ha distribuito la v0.17.0 il 18 marzo. Il rilascio server continua il lavoro sulle dispute e le valutazioni dal ciclo v0.16.x, aggiungendo dati di reputazione commerciale più completi per acquirenti e venditori come event Nostr. Mostro Mobile, il client Flutter, ha seguito con la v1.2.2 il 23 marzo, mantenendo l’interfaccia mobile sincronizzata con le ultime modifiche al protocollo.

Shosho v0.14.0

Shosho, l’app di live streaming Nostr, ha distribuito la v0.14.0 il 19 marzo con il lancio di Shosho Shop. Il rilascio aggiunge una scheda Shop sui profili, Shop in Esplora, e un pulsante In-Live Shop su live e clip. Le note di rilascio dicono che i “prodotti Nostr” esistenti appaiono automaticamente e gli acquirenti cliccano per accedere alla pagina Plebeian Market del venditore per l’acquisto. Le note di rilascio di Shosho non identificano il kind di event degli annunci, quindi non è ancora possibile confermare se Shosho Shop legge gli stessi annunci classificati NIP-99 che Shopstr supporta esplicitamente nel suo README.

Applesauce v5.2.0

Applesauce, la collezione di pacchetti helper di hzrd149 per costruire applicazioni Nostr, ha distribuito la v5.2.0 il 22 marzo. Il rilascio copre sei pacchetti. Il pacchetto SQLite corregge una collisione di vincolo UNIQUE sui tag degli event che causava inserimenti duplicati. Il pacchetto signers aggiunge AndroidNativeSigner, che avvolge l’interfaccia signer nativa Android NIP-55 in modo che le app basate su web-view possano usare la firma hardware-backed senza codice bridge personalizzato. Il pacchetto relay aggiunge un campo challenge agli oggetti di stato relay e pool, tracciando lo stato auth NIP-42 in modo che le app possano rilevare quando un relay sta richiedendo l’autenticazione e rispondere programmaticamente. Il pacchetto core acquisisce i metodi isEventPointerSame e isAddressPointerSame per la deduplicazione dei riferimenti event, e il pacchetto common aggiunge user.blossomServers$ per risolvere i server media Blossom di un utente. Applesauce alimenta noStrudel, Satellite e diversi altri client web, quindi queste correzioni si propagano attraverso il livello client web.

Wisp distribuisce 16 rilasci in una settimana

Wisp, il client Nostr Android, ha distribuito 16 rilasci dalla v0.9.3-beta alla v0.13.1-beta questa settimana. Le aggiunte di funzionalità includono supporto multi-account, una modalità notifiche zen per interruzioni ridotte, bozze e post programmati, filtri di sicurezza dei contenuti e una nuova icona fiamma.

Manent v1.2.0

Manent, l’app di note private cifrate e storage file, ha distribuito la v1.2.0 il 20 marzo. Il rilascio aggiunge la cattura dalla fotocamera direttamente dall’app, il ridimensionamento delle immagini prima dell’upload per ridurre i costi di storage, e pinch-to-zoom per esaminare le immagini archiviate. Manent archivia note e file cifrati sui relay Nostr usando il keypair dell’utente, rendendo il telefono o l’app desktop un thin client che può ricostruire il suo stato completo dai dati dei relay.

diVine 1.0.7

diVine, il client di video brevi, ha distribuito la 1.0.7 il 21 marzo con un watchdog per la riproduzione video che riprende automaticamente i video bloccati. Dopo l’infrastruttura di test E2E e il caricamento diretto MP4 nella v1.0.6, questo rilascio mira al percorso di errore di riproduzione rimanente: video che si fermano a metà stream senza generare un errore.

Alby Extension v3.14.2

Alby Extension, l’estensione browser NIP-07 (Browser Extension Signer), ha distribuito la v3.14.2 il 18 marzo con la visualizzazione QR code dell’indirizzo Lightning e supporto alla firma Schnorr. L’aggiunta di Schnorr allinea l’estensione browser con lo schema di firma secp256k1 che Nostr usa nativamente.

NoorNote da v0.6.5 a v0.6.11

NoorNote, l’app per prendere appunti, ha distribuito sette rilasci dalla v0.6.5 alla v0.6.11. L’aggiunta principale sono i Follow Pack: bundle curati di account che gli utenti possono esplorare e sottoscrivere in blocco, simili alle Liste Twitter ma pensati per l’onboarding. Gli utenti possono creare, modificare e condividere Follow Pack con titoli, descrizioni e immagini di copertina personalizzati. La serie aggiorna anche la libreria Nostr sottostante da NDK v2 a v3, che porta una gestione migliorata delle connessioni relay e delle sottoscrizioni. Le note con immagini e un’esperienza di connessione relay ridisegnata completano il ciclo.

nak v0.19.1 e v0.19.2

nak, il toolkit Nostr a riga di comando di fiatjaf per interagire con i relay, codificare e decodificare identificatori NIP-19 (Bech32-Encoded Entities), firmare event e interrogare dati dei relay, ha distribuito la v0.19.1 e la v0.19.2 il 17 e 20 marzo. Le due point release seguono l’aggiunta della UI group-forum v0.19.0 dalla settimana scorsa.

Calendar by Form* v0.2.1

Calendar by Form*, l’app calendario decentralizzata costruita su NIP-52 (Calendar Events), ha distribuito la v0.2.1 il 20 marzo. Il rilascio corregge un problema nel template delle notifiche che influiva sui promemoria degli eventi. Calendar archivia gli event come kind 31922 (basati su data) e kind 31923 (basati su orario) di Nostr, permettendo a qualsiasi client Nostr di renderizzare i dati calendario se sceglie di supportare quei kind. L’app è costruita dal team Formstr, che mantiene anche Formstr (moduli decentralizzati) e Pollerama (sondaggi).

NYM da v3.50 a v3.53

NYM, il client di chat effimero leggero collegato a Bitchat, ha distribuito 28 rilasci dalla v3.50 alla v3.53 (le versioni patch incrementano rapidamente). La funzionalità più notevole è Nymbot, un chat bot integrato che risponde alle menzioni @nymbot nei canali e fornisce funzioni di stato e gestione dei relay. Una “hardcore mode” genera un keypair fresco per ogni messaggio inviato, rendendo i thread di conversazione non collegabili a livello di identità. Il compromesso è chiaro: si perde l’identità persistente ma si guadagna l’anonimato per messaggio. Il livello proxy relay ha anche ricevuto lavoro, con worker proxy relay sharded per migliore connettività, supporto canali geohash, e tolleranza al clock skew per nodi con orologi di sistema imprecisi.

Aggiornamenti Progetti

Ditto aggiunge bridge Bluesky e integrazione Wikipedia

Ditto, il client social Nostr personalizzabile del team Soapbox, ha registrato oltre 300 commit questa settimana su tre percorsi di funzionalità distinti. Il primo è un bridge Bluesky (19 commit) che renderizza i post Bluesky inline come thread completi in stile feed, aggiunge navigazione sidebar a una pagina di scoperta Bluesky alimentata dal feed ufficiale Discover (whats-hot), e collega pulsanti di azione per commentare, condividere, reagire e copiare link. Quando un utente risponde a un post Bluesky dall’interno di Ditto, la modale di composizione mostra un avviso che nota la natura cross-protocollo dell’interazione. Le reazioni kind 17 NIP-73 (External Content IDs) alimentano il modello cross-protocollo: un utente Nostr reagisce a un post Bluesky, e la reazione viene archiviata come un event Nostr standard che referenzia l’identificatore di contenuto esterno. Questo è lo stesso pattern NIP-73 che potrebbe collegare reazioni a qualsiasi contenuto esterno, dai post Bluesky ai video YouTube alle pagine web.

Il secondo percorso è un’integrazione Wikipedia (9 commit). Ditto ora renderizza contenuti ricchi di articoli Wikipedia sulle pagine di dettaglio invece di anteprime link generiche, aggiunge autocompletamento nella ricerca con miniature degli articoli, e fornisce una pagina /wikipedia che attinge contenuti in evidenza dall’API Wikipedia. I risultati di Wikipedia e Archive.org appaiono anche nel dropdown di autocompletamento della ricerca generale. Il terzo percorso è il supporto piattaforma iOS tramite Capacitor, con script di build remoto e configurazione piattaforma che arrivano insieme a una revisione della UI (55 commit) che sostituisce gli header con backdrop-blur con un nuovo design di navigazione basato su arco su ogni pagina dell’app. I 314 commit muovono Ditto da un client solo-Nostr verso un aggregatore multi-protocollo che tratta Bluesky e Wikipedia come sorgenti di contenuto di prima classe accanto al feed Nostr.

Pika costruisce una pipeline CI forge NIP-34

Pika, l’app di messaggistica cifrata basata su Marmot, ha unito 33 PR questa settimana focalizzate su un forge NIP-34 self-hosted con CI pre-merge. Il forge è un livello di hosting git che riceve patch come event NIP-34, esegue controlli CI prima del merge, e riporta lo stato strutturato tramite event Nostr. La PR #701 aggiunge CI pre-merge e nightly basata su lane, dove ogni percorso di codice (Rust, TypeScript, build Apple) gira nella propria lane con stato pass/fail indipendente. La PR #715 riduce gli agenti CI gestiti a container Incus OpenClaw per l’isolamento, e la PR #733 aggiunge una CLI ph forge per interagire con il forge ospitato dalla riga di comando. PR di supporto gestiscono i permessi di scrittura al repo per i merge (PR #736), metadati CI strutturati con badge di stato live (PR #722), split delle build Apple nightly (PR #738), e correzioni di auth e ricerca branch del forge (PR #734). Questo è uno dei primi sistemi CI/CD funzionanti costruiti sopra gli event git NIP-34, spostando l’hosting del codice sorgente basato su Nostr oltre lo scambio base di patch verso il workflow di merge-and-test che gli sviluppatori si aspettano da GitHub o GitLab.

Nostria aggiunge comunità, snippet di codice e gestione event vocali

Nostria, il client Nostr cross-platform mantenuto da sondreb, ha dedicato questa settimana a estendere la superficie app oltre il filtraggio Web of Trust coperto nel #14. L’aggiunta principale è un’implementazione completa di NIP-72 (Moderated Communities) con creazione comunità, configurazione moderatori e relay, tracciamento approvazione post con anteprime immagini, e una pagina comunità dedicata con tab Post e Moderatori.

Lo stesso arco di lavoro aggiunge anche rendering e editing di snippet di codice con un editor con evidenziazione della sintassi, supporto risposte a event vocali per conversazioni audio, impostazioni relay chat per messaggi diretti, condivisione canali tramite la Web Share API, un sistema di docking toolbar per il media player, registrazione in-app per l’ultimo servizio Web of Trust di Brainstorm, flussi di invio e ricezione denaro nei DM usando NWC e fatture BOLT-11, gestione GIF nativa Nostr, e un percorso di importazione RSS più robusto per i musicisti che può raccogliere gli split Lightning esistenti dai feed podcast.

Iterazione rapida nostr-vpn

Oltre al lancio iniziale, il log dei commit di nostr-vpn rivela i problemi specifici incontrati durante il deployment reale. La v0.2.3 fino alla v0.2.5 hanno aggiunto lo script di installazione iniziale e la CLI cross-platform. La v0.2.6 e la v0.2.7 hanno portato il supporto Windows, che ha richiesto il quoting del percorso UAC per le scritture di configurazione e aggiornamenti di configurazione di proprietà del daemon. La v0.2.8 fino alla v0.2.10 hanno corretto le azioni del servizio GUI Windows, la gestione dei sottoprocessi CLI e la configurazione del servizio machine-scoped. La v0.2.12 ha sostituito la scoperta LAN con il pairing LAN a tempo, un flusso avviato dall’utente dove due dispositivi sulla stessa rete locale si accoppiano senza segnalazione relay. Il pattern è da manuale di testing sul campo in fase iniziale: ogni rilascio mira a uno specifico fallimento di deployment, la base utenti è abbastanza piccola per iterare quotidianamente, e lo sviluppatore usa lo strumento personalmente tra i rilasci.

Build automatizzate Comet

Comet (precedentemente Captain’s Log), lo strumento di scrittura long-form nativo Nostr di Nodetec, ha prodotto oltre 40 build alpha automatizzate questa settimana. Comet è un’app desktop per scrivere e pubblicare articoli NIP-23 (Long-form Content), con storage locale delle bozze, editing markdown e pubblicazione one-click sul set di relay dell’utente. La pipeline di build automatizzata genera un rilascio taggato per ogni commit sul branch main, il che rende il conteggio grezzo dei rilasci fuorviante come misura della velocità delle funzionalità. Ciò che le 40 build mostrano è che l’app è in sviluppo attivo quotidiano, con ogni commit testato, pacchettizzato e reso disponibile per il download in pochi minuti.

Aggiornamenti NIP

Modifiche recenti al repository NIPs nella finestra 17-24 marzo:

Nessun merge NIP è arrivato tra il 18 e il 24 marzo.

PR Aperte e Discussioni aggiornate nella finestra:

NIP-AA: Agenti Autonomi su Nostr (PR #2259): Propone convenzioni per agenti autonomi che operano sulla rete Nostr. La PR definisce come gli agenti si identificano, scoprono servizi e si coordinano con altri agenti e umani attraverso event Nostr.
NIP-50 (Search): Estensioni di ordinamento (PR #2283): Aggiunge parametri di ordinamento alle query di ricerca NIP-50, inclusi top, hot, zaps e new. Questo permetterebbe ai client di richiedere risultati classificati dai relay che supportano la ricerca full-text invece di ordinare lato client.
NIP-A5: Programmi WASM (PR #2281): Propone una convenzione per pubblicare e scoprire programmi WebAssembly su Nostr. I binari WASM potrebbero essere distribuiti come event Nostr, con i relay che servono come livello di scoperta per codice eseguibile portabile.
NIP-CF: Combine Forces napps interoperabili (PR #2277): Definisce una convenzione per applicazioni Nostr interoperabili (“napps”) che possono comporre funzionalità tra diversi client e servizi.
NIP Snapshots (PR #2279): Propone un meccanismo per snapshot dello stato dei relay, per la sincronizzazione e il backup dei relay.
NIP Checkpoints (PR #2278): Propone event checkpoint per segnare lo stato valido noto dei relay, complementando la proposta snapshots.
NIP-58 (Badges): Refactoring Badge Sets (PR #2276): Ristruttura come le collezioni di badge sono organizzate e referenziate.
NIP-11 (Relay Information Document): Estensioni (PR #2280): Aggiunge campi aggiuntivi al documento informativo del relay per metadati relay leggibili dalle macchine più ricchi.

Cinque Anni di Marzo di Nostr

La newsletter del mese scorso ha coperto come i febbrai di Nostr sono progrediti dalla riscrittura di NIP-01 (Basic Protocol Flow) attraverso l’ondata Damus sull’App Store fino alle reti mesh e le proposte per agenti. Questa retrospettiva traccia cosa è successo ogni marzo dal 2021 al 2026.

Marzo 2021: Due Commit

Quattro mesi dopo la sua nascita, il marzo di Nostr ha prodotto esattamente due commit al repository del protocollo, entrambi il 4 marzo. fiatjaf ha aggiunto link alle istanze nostwitter, indirizzando i primi visitatori a deployment funzionanti, e ha aggiunto kind alla definizione base dei filtri. Quel secondo commit è rivelatore: nel marzo 2021, non si potevano ancora filtrare gli event Nostr per kind. Il protocollo era così primitivo. Due o tre relay servivano la rete. Il gruppo Telegram era l’unico canale di coordinamento. Il repository NIPs non esisteva ancora; le proposte di protocollo vivevano come file nel repo principale nostr. fiatjaf era l’unico committer quel mese. L’intero output del marzo 2021 di quello che sarebbe diventato un protocollo che supporta VPN, giochi multiplayer e networking mesh cinque anni dopo entra in una singola diff git.

Marzo 2022: Costruzione Pre-Damus

Il repository principale del protocollo ha ricevuto zero commit nel marzo 2022. Lo sviluppo si era spostato interamente nei repository degli strumenti. Branle, il client web Vue.js di fiatjaf e all’epoca l’interfaccia Nostr principale, ha ricevuto 5 commit incluso il supporto al deployment Docker e correzioni alla visualizzazione del nome di verifica NIP-05 (DNS-Based Verification) che rimuovevano il prefisso _@ dai badge di verifica. more-speech di Robert C. Martin, il client desktop Clojure, ha registrato 13 o più commit aggiungendo threading, navigazione da tastiera e una finestra di editing. L’autore di software più famoso che costruiva attivamente su Nostr quel mese non era uno sviluppatore crypto ma la persona il cui “Clean Code” ha venduto milioni di copie, che scriveva un client Nostr in Clojure, una scelta di linguaggio che dice tutto sulla comunità iniziale: erano programmatori con opinioni forti che costruivano per sé stessi.

La rete relay si era espansa a circa 15 relay con una base utenti attiva nell’ordine delle centinaia. Damus non esisteva ancora e non sarebbe stato creato fino ad aprile 2022. Nemmeno Nostream era apparso. Il lavoro del mese era infrastruttura: rendere gli strumenti esistenti più affidabili per la piccola comunità che li usava già quotidianamente.

Marzo 2023: Infrastruttura Post-Esplosione

Un mese dopo l’ondata Damus sull’App Store e il superamento delle 300.000 chiavi pubbliche, il marzo 2023 riguardava l’assorbimento della crescita. Il repository NIPs ha unito 28 pull request, il secondo conteggio mensile più alto nella storia del protocollo. NIP-51 (Lists) è stato unito, dando ai client collezioni strutturate di follow, mute e segnalibri. NIP-39 (External Identities in Profiles) è arrivato, NIP-78 (Application-Specific Data) ha fornito un kind di storage generale per le app che necessitavano di stato privato, e una riscrittura di NIP-57 (Lightning Zaps) (PR #392) ha consolidato il flusso zap e chiarito la terminologia. La PR più discussa del mese era una proposta alternativa di gestione delle menzioni (PR #381) con oltre 50 commenti.

Il nuovo progetto più importante è stato NDK (Nostr Development Kit), la libreria TypeScript per connessioni relay, firma event, caching e gestione sottoscrizioni. pablof7z ha fatto il commit iniziale il 16 marzo 2023, poi l’ha riscritto da zero 11 giorni dopo il 27 marzo (“praticamente un altro commit iniziale”), e aveva il supporto LNURL e zap funzionante entro il 31 marzo. NDK è passato dal nulla alla capacità zap in 15 giorni. Cinque giorni dopo la creazione di NDK, il 21 marzo, il team Alby ha creato NWC (Nostr Wallet Connect), l’implementazione di riferimento di NIP-47 che connetteva i wallet Lightning alle applicazioni Nostr. I due progetti che avrebbero sostenuto i successivi tre anni di sviluppo Nostr basato sul web sono nati nella stessa finestra di 30 giorni. OpenSats non aveva ancora lanciato il suo fondo Nostr; la prima ondata non sarebbe arrivata fino a luglio 2023, quattro mesi dopo la creazione di NDK.

Altre creazioni notevoli di quel mese includevano NostrGit, NostrChat, un progetto nostr-signing-device di LNbits, e nostrmo. Gossip, il client desktop Rust focalizzato sulla selezione intelligente dei relay, ha distribuito tre rilasci. Il protocollo era in modalità costruzione, e gli strumenti creati nel marzo 2023 sono ancora in uso tre anni dopo.

Marzo 2024: Maturazione del Protocollo

Il marzo 2024 riguardava l’hardening del protocollo per l’uso a lungo termine. Il repository NIPs ha unito 12 pull request. La più significativa è stata NIP-34 (Git Stuff), PR #997, che è stata unita il 5 marzo dopo oltre 130 commenti e 44 giorni di revisione. Il thread di discussione è una capsula del tempo della comunità che dibatteva come costruire un GitHub decentralizzato. jb55 ha tracciato paralleli con git send-email, Giszmo ha proposto di usare gli hash dei root commit per la scoperta cross-fork (“qualcosa che GitHub non fa e che noi potremmo”), mikedilger ha suggerito l’autenticazione con event firmati NIP-98 (HTTP Auth) invece delle chiavi SSH, e fiatjaf ha liquidato bruscamente la necessità di generalità nel controllo versione: “non per ogni sistema di controllo versione, solo per git. Nessuno usa gli altri.” Entro poche ore dall’apertura della PR, fiatjaf aveva già convertito nak, go-nostr e gitstr per accettare patch su Nostr. DanConwayDev, il cui ngit era già un grantee OpenSats, era tra i contributori più attivi alla discussione. È stato unito anche un campo bot per i metadati dei profili, dando ai client un modo leggibile dalle macchine per distinguere gli account automatizzati da quelli umani.

Amethyst ha distribuito la v0.85.0 con supporto event git, articoli wiki, rendering di dati medici e editing di contenuti in un singolo rilascio. Mostro ha raggiunto la v0.10.0. Nosflare, un relay Nostr serverless in esecuzione su Cloudflare Workers, ha dimostrato che la logica relay poteva girare all’edge. OpenSats ha emesso una grant di Supporto a Lungo Termine a Bruno Garcia per contributi sostenuti al client Amethyst.

Marzo 2025: Espansione dell’Infrastruttura

Il marzo 2025 ha prodotto 10 NIP uniti. Il titolo principale è stato NIP-66 (Relay Discovery and Liveness Monitoring), PR #230, che è stata unita il 3 marzo dopo un percorso di 25 mesi. dskvr ha proposto per la prima volta il monitoraggio dei relay nel febbraio 2023, gli è stato detto che poteva essere fatto lato client, ha spiegato perché connettersi a migliaia di relay contemporaneamente era impraticabile per i singoli client, ha attraversato sette bozze complete, ha costruito nodi di monitoraggio in otto regioni geografiche (Northeast US, Brasile, US-West, US-East, Australia, India, Corea, Sud Africa), e ha atteso che il tooling relay si mettesse al passo. Quando è stata unita, le implementazioni esistevano già in nostr.watch, relaypag.es, monitorlizard, Snort, noStrudel e Jumble. I dati NIP-66 avrebbero poi alimentato i benchmark outbox di Nostrability coperti nella Newsletter #12. È stato unito anche NIP-C0 (Code Snippets) (PR #1852, 63 commenti), aggiungendo event kind 1337 per la condivisione di codice sorgente.

I primi server MCP per Nostr sono apparsi questo mese. nostr-mcp-server è apparso il 23 marzo e nwc-mcp-server il 14 marzo, solo quattro mesi dopo che Anthropic ha annunciato il Model Context Protocol nel novembre 2024. Questi primi bridge hanno preceduto l’SDK completo di ContextVM e il lavoro di commercio agenti che è seguito alla fine del 2025 e inizio 2026.

Gossip ha distribuito la v0.14.0. Coracle, il client web di hodlbod con gestione feed consapevole dei relay, ha distribuito tre rilasci. OpenSats ha annunciato la sua decima ondata di grant Nostr, continuando la pipeline di finanziamento attiva dalla metà del 2023.

Marzo 2026: Convergenza

L’attività di marzo 2026 è tratta dai numeri di Nostr Compass #12 fino al #15 (questo numero).

Il marzo 2026 è il mese in cui thread disparati sono convergiti in sistemi funzionanti. Il Marmot Development Kit ha distribuito il suo primo rilascio pubblico con media cifrati, binding multi-linguaggio, e una migrazione ChaCha20-Poly1305 che ha richiesto aggiornamenti coordinati tra specifica, Rust e TypeScript. Shopstr e Milk Market hanno aggiunto superfici di commercio MCP per acquisti guidati da agenti. NIP-42 relay auth è arrivato simultaneamente in Amber, strfry e OAuth Bunker, chiudendo il cerchio tra software signer, relay e bunker. Notedeck ha distribuito aggiornamenti software nativi Nostr usando event di rilascio NIP-94 (File Metadata).

Questa settimana, BigBrotr ha scansionato l’intera rete relay alla ricerca di chiavi private trapelate e ha pubblicato sia l’analisi che un checker DVM. Nostr VPN ha dimostrato che il modello di chiavi di Nostr funziona per l’infrastruttura di rete, non solo per i social media. DOOM ha dimostrato che scoperta Nostr, cifratura Marmot e trasporto QUIC possono far girare un gioco multiplayer in tempo reale. Amber è passato alla v5.0.0. Wisp ha distribuito 16 rilasci in sette giorni. Venticinque o più rilasci taggati sono arrivati da progetti importanti in una singola settimana.

Sette NIP sono stati uniti nei primi 24 giorni del mese. Il protocollo ha aggiunto il markup Djot NIP-54 (Wiki), i limiti di input NIP-19 (Bech32-Encoded Entities), la logica di query booleana NIP-91 (AND Operator for Filters), e le asserzioni Web of Trust NIP-85 (Trusted Assertions). Le proposte aperte spaziavano dagli agenti autonomi (NIP-AA) ai programmi WASM (NIP-A5) alle estensioni di ordinamento per la ricerca NIP-50.

Guardando Avanti

Cinque marzi di Nostr tracciano un arco chiaro. Nel 2021, una persona ha fatto due commit a un protocollo che non poteva ancora filtrare event per kind. Entro il 2023, NDK e NWC sono nati a cinque giorni di distanza per assorbire l’esplosione post-Damus. Entro il 2024, un thread di PR da 141 commenti dibatteva come la collaborazione git dovrebbe funzionare su un protocollo sociale. Entro il 2025, una specifica di monitoraggio relay che era stata pazientemente riscritta sette volte in 25 mesi è stata finalmente unita. Nel 2026, qualcuno si è irritato per il fatto che Tailscale richiede un account e ha costruito una VPN usando keypair Nostr, mentre qualcun altro ha distribuito DOOM multiplayer che scopre i peer tramite relay Nostr e cifra il gameplay tramite Marmot. La scansione di BigBrotr di 41 milioni di event su 1.085 relay dà una misura concreta di quanto la rete sia cresciuta. La superficie del protocollo nel marzo 2026 sarebbe stata irriconoscibile per il marzo 2021, ma il modello sottostante, event firmati da chiavi secp256k1 e distribuiti attraverso relay, non è cambiato.

Questo è tutto per questa settimana. Stai costruendo qualcosa o hai notizie da condividere? Contattaci tramite DM NIP-17 (Private Direct Messages) o trovaci su Nostr.

Nostr Compass #14

Wed, 18 Mar 2026 00:00:00 +0000

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

Questa settimana: Amethyst implementa il supporto completo ai metodi NIP-47 (Nostr Wallet Connect), Alby Hub aggiunge il supporto multi-relay nella v1.21.6, Amber distribuisce la v4.1.3 con Tor integrato e permessi signer più granulari, e Zeus rimuove un percorso keysend NWC rischioso nella PR #3835. Notedeck distribuisce un updater firmato nella v0.8.0-rc2 che scopre i rilasci attraverso event NIP-94 (File Metadata), mentre Damus corregge lo stato NIP-65 (Relay List Metadata) obsoleto, Nostrability Outbox rivede i suoi risultati di benchmark con dati corretti, e Primal iOS testa sottoscrizioni relay dirette per i DM. Primal Android distribuisce la 3.0.7, Route96 distribuisce la v0.6.0, OpenChat continua a perfezionare l’interoperabilità Marmot nella v0.1.0-alpha.11, Pika consolida il suo runtime nella pika/v1.1.1, e Nostria aggiunge il filtraggio Web of Trust tramite NIP-85 (Trusted Assertions). Il repository NIPs unisce il markup Djot per NIP-54 (Wiki) e un limite di input di 5000 caratteri per NIP-19 (Bech32-Encoded Entities), mentre nuove proposte aprono discussioni su file .nostrkey per NIP-49 (Private Key Encryption), consistenza dello stato di appartenenza per NIP-43 (Relay Access Metadata and Requests), guida alla cancellazione per NIP-17 (Private Direct Messages) e un URI share-intent per NIP-222.

Notizie

Il supporto Wallet Connect si amplia, e i client wallet stringono i percorsi di errore

Amethyst, il client Android mantenuto da vitorpamplona, ha unito la PR #1828, che porta la sua implementazione NIP-47 vicino alla copertura completa del protocollo. La patch aggiunge make_invoice, lookup_invoice, list_transactions, get_balance, get_info, metodi per hold invoice, supporto keysend con record TLV, discovery delle capacità tramite kind 13194, e event di notifica su kind 23197 con NIP-44 (Encrypted Payloads). Questo dà al client una superficie NWC molto più ampia senza dipendere da estensioni specifiche dell’app.

Lo stack wallet circostante si è mosso nella stessa direzione. Alby Hub, il nodo Lightning auto-custodiale e servizio wallet dietro molti deployment NWC, ha distribuito la v1.21.6 con supporto multi-relay e flussi di connessione e swap più semplici. Zeus, il wallet Lightning mobile, ha unito la PR #3835 rimuovendo il supporto keysend NWC dopo aver identificato un percorso silenzioso di drenaggio fondi in quel flusso, correggendo anche la gestione degli event in sospeso e l’attività Cashu. La connettività wallet su Nostr si sta ampliando, e gli implementatori stanno rimuovendo i flussi difficili da rendere sicuri.

Notedeck sposta la scoperta dei rilasci su Nostr

Come da copertura di Notedeck della settimana scorsa, Notedeck, il client desktop nativo del team Damus, ha distribuito la v0.8.0-rc2 dopo aver unito la PR #1326. Il nuovo updater si sottoscrive a event di rilascio firmati di kind 1063, abbina la piattaforma locale, scarica il binario referenziato e verifica il suo hash SHA256 prima dell’installazione. I metadati di rilascio non devono più provenire dall’API GitHub o dal sito web di un progetto. Una pubkey di rilascio fidata e una connessione relay sono sufficienti.

La stessa patch aggiunge una CLI notedeck-release che pubblica quegli event dagli artefatti di rilascio GitHub, il che significa che la pipeline di rilascio ora ha un percorso di pubblicazione nativo Nostr oltre a un percorso di scoperta nativo Nostr. Avvicina anche il modello di updater Damus e Notedeck al flusso di rilascio firmato pubblicato via relay di Zapstore: lo strumento zsp di Zapstore gestisce già gli asset software come event kind 1063 o 3063, quindi questo percorso non è vincolato a un singolo client o un singolo publisher. Il resto della release candidate è lavoro desktop pratico: colonne di follow, profilo “View As User”, supporto NIP-59 (Gift Wrap), statistiche note in tempo reale e gestione delle limitazioni NIP-11 (Relay Information Document), ma l’updater è la parte che probabilmente sopravviverà a questo singolo ciclo di rilascio.

Lo stato dei relay si avvicina al comportamento runtime

Damus ha unito la PR #3665, sostituendo un ID event di relay-list obsoleto memorizzato con una query diretta al database per l’event kind 10002 più recente. Quando il vecchio valore diventava obsoleto, le operazioni di aggiunta e rimozione relay potevano ricadere su bootstrap o liste vecchie di un anno, facendo apparire alcune modifiche ai relay come riuscite mentre lasciavano lo stato attivo invariato. La PR #3690 corregge un secondo percorso di errore eliminando lo stato lock.mdb obsoleto durante la compattazione LMDB in modo che l’app non vada in crash con SIGBUS al prossimo avvio.

Primal iOS ha aperto la PR #194, che si sottoscrive direttamente ai relay di scrittura NIP-04 (Encrypted Direct Messages) di un partner di chat mentre una conversazione è aperta, mantenendo il cache server come fallback. Nostur ha aperto la PR #53, che combina scoring randomizzato dei relay, filtraggio di liveness NIP-66 da nostr.watch e Thompson sampling per trasformare la selezione dei relay da un’euristica fissa in una policy appresa. I client hanno a lungo trattato la scelta dei relay come dati di configurazione. Sempre più app ora la trattano come stato live che necessita di logica di misurazione e riparazione.

Rilasci

Primal Android 3.0.7

Primal Android, il client Android di Primal, ha distribuito la 3.0.7 con un nuovo ciclo di sondaggi e wallet. La PR #945 aggiunge il voto nei sondaggi basato su zap, la PR #948 pagina il caricamento dei voti in modo che i sondaggi più grandi restino utilizzabili, e la PR #965 recupera le ricevute zap per tutte le transazioni. Lo stesso rilascio tagga anche gli event supportati con metadati client NIP-89 (Recommended Application Handlers) nella PR #968, che aiuta i client downstream ad attribuire le origini degli event in modo più pulito.

Amber v4.1.3

Come da copertura di Amber della settimana scorsa, Amber, l’app signer Android per i flussi NIP-55 (Android Signer Application), ha distribuito la v4.1.3. Il rilascio si basa sul suo recente lavoro relay-auth NIP-42 con più hardening operativo: la PR #327 aggiunge Tor integrato insieme al supporto Orbot, la PR #324 sostituisce i permessi di cifratura grossolani basati sui NIP con regole specifiche per tipo di contenuto, e la PR #336 rimuove i permessi di rete dal flavor offline mentre la PR #335 aggiunge controlli CI per mantenerli così. La PR #322 sposta anche lo storage del PIN nel DataStore cifrato.

Questo rilascio stringe il confine del signer stesso. Questo è utile per qualsiasi flusso Android che affida chiavi reali o decisioni di relay-auth ad Amber, perché la parte difficile non è solo cosa il signer può fare. È anche quanto strettamente può essere limitato nel suo ambito.

Route96 v0.6.0

Come da copertura di Route96 della settimana scorsa, Route96, il media server che supporta Blossom e NIP-96 (HTTP File Storage), ha rilasciato la v0.6.0. Il rilascio sposta la configurazione e lo stato della whitelist nel database con hot reload e aggiunge policy di conservazione per file freddi o invecchiati. Aggiunge anche un endpoint GET /user/files più ricco e il tracciamento delle statistiche dei file per download e egress, che dà agli operatori maggiore visibilità su come il loro storage server viene utilizzato.

OpenChat v0.1.0-alpha.11

Come da copertura di OpenChat della settimana scorsa, OpenChat, il client chat basato su Avalonia costruito sullo stack Marmot, ha distribuito la v0.1.0-alpha.11 dopo una settimana di lavoro rapido sul protocollo. Il commit c33895d avvolge gli event Welcome in gift wrap NIP-59 e rimuove i vecchi shim di normalizzazione tag MIP-00, il commit 2738ff4 completa l’audit di conformità MIP-02, e il commit 8e470cf fa lo stesso per la cifratura dei messaggi di gruppo MIP-03. Il commit 129ca37 consolida anche la gestione NIP-44 sull’implementazione marmot-cs condivisa, riducendo il rischio di deriva crittografica lato client.

nak v0.19.0 e v0.19.1

nak, il toolkit Nostr a riga di comando di fiatjaf, ha distribuito la v0.19.0 e la v0.19.1. La serie 0.19 aggiunge una UI group-forum nel commit 5f4efdb, passa le modifiche dei metadati di gruppo a un flusso di sostituzione completa nel commit da0b753, e sostituisce la vecchia gestione no-text con supported_kinds nel commit bef67d3. Per gli implementatori di gruppi, questo mantiene la CLI allineata con la direzione in cui si stanno muovendo le specifiche e i client dei gruppi.

Aggiornamenti Progetti

Amethyst

Come da copertura di Amethyst della settimana scorsa, Amethyst, il client Android con una delle superfici protocollari più ampie in Nostr, ha continuato a costruire sul suo lavoro wallet e relay dopo la patch NIP-47. La PR #1853 aggiunge query COUNT NIP-45 (Event Counting) nelle schermate di gestione relay, così gli utenti possono vedere quanti event ogni relay detiene effettivamente per home feed, notifiche, DM e dati indice. La PR #1849 aggiunge caricamenti di file cifrati per le chat NIP-17 (Private Direct Messages), con un percorso di retry per caricamenti non cifrati quando un host di storage rifiuta la versione cifrata.

La PR #1791 porta anche il login bunker desktop completo NIP-46 (Nostr Connect) con un indicatore heartbeat, che è importante perché i fallimenti di firma remota spesso appaiono come rotture casuali della UI dal lato dell’utente. Il client mostra se il signer è attivo e quanto recentemente ha risposto, rendendo anche ovvio quando la sessione corrente usa un bunker.

Nostria

Nostria, il client multi-piattaforma costruito attorno a uno stack local-first, ha unito la PR #561 aggiungendo il filtraggio Web of Trust per feed e risposte nei thread. La funzionalità usa i dati di ranking del trust-service esistente e li espone sia come filtro feed che come filtro risposte, nascondendo gli autori il cui rank non supera la soglia preservando la struttura del thread quando sono presenti discendenti fidati. Questo dà agli utenti un livello intermedio tra “mostra tutti” e la curazione basata su liste hardcoded.

La stessa settimana ha portato anche la PR #563, che aggiunge filtraggio dei contenuti e supporto repost alla pagina sommario. Fuori dalla lista PR tracciata, Nostria ha anche completato più della sua superficie per utenti avanzati. Ora supporta l’ultimo servizio Web of Trust di Brainstorm con registrazione in-app, insieme a flussi di invio e ricezione denaro nei DM usando NWC e fatture BOLT-11. Aggiunge anche la gestione GIF nativa Nostr tramite l’emoji NIP e un percorso di importazione RSS più robusto per i musicisti che può raccogliere gli split Lightning esistenti dai feed podcast. Nostria tratta ranking, media, pagamenti e pubblicazione come un’unica superficie app connessa.

Nostur

Nostur, il client iOS mantenuto da nostur-com, ha aperto la PR #53 per trasformare il routing outbox da un piano fisso in una policy con punteggio. La patch aggiunge scoring randomizzato dei relay, filtraggio di liveness NIP-66 con un feed nostr.watch in cache, e Thompson sampling in modo che i dati di successo e fallimento dei relay cambino le selezioni future. Il design mantiene una valvola di sicurezza quando troppi relay verrebbero filtrati e preserva i relay .onion. Questo è uno degli esempi più chiari attualmente di un client che tratta la selezione dei relay come un sistema adattivo.

Nostrability Outbox

Come dal precedente report sui benchmark Outbox, Nostrability Outbox, il progetto di benchmark e analisi focalizzato sul routing client NIP-65 e NIP-66, ha dedicato la settimana a stringere le proprie affermazioni. La PR #35 sostituisce i risultati Thompson-sampling gonfiati con un re-benchmark completo su 1.511 esecuzioni e raccomanda la variante CG3 per il routing in stile NDK. La PR #43 aggiunge decadimento e confronti per caso d’uso, corregge un bug di cache-poisoning 0 follows, poi riesegue il dataset Telluride dopo aver fissato i TTL della cache.

Questo non è lavoro di prodotto nel senso usuale, ma è importante per gli autori di client perché i numeri del progetto sono ora più precisi e meno lusinghieri nei punti in cui avevano precedentemente sovrastimato. Il risultato corretto è comunque utile. La selezione randomizzata continua a battere il routing puramente deterministico nei casi di cui Outbox si occupa, l’apprendimento in stile Thompson può migliorare materialmente la copertura quando i client persistono la cronologia utile dei relay, e il filtraggio di liveness NIP-66 riduce il tempo sprecato su relay inattivi. Il lavoro si sta anche trasformando in proposte di implementazione concrete, incluse NDK #387, Nostur #53, Amethyst #1833, rust-nostr #1282, welshman #53, e applesauce #54 più applesauce #55.

Backend White Noise

whitenoise-rs, il backend Rust usato da White Noise e altri strumenti Marmot, ha unito due patch di hardening al confine della gestione media Blossom. La PR #637 impone HTTPS sugli URL Blossom e aggiunge un timeout di upload, mentre la PR #642 limita i download blob a 100 MiB per impedire che pull di media sovradimensionati si trasformino in un percorso denial-of-service. Per il software di messaggistica privata, gli URL dei media sono una delle interfacce più critiche tra la logica applicativa cifrata e l’infrastruttura di rete non fidata. Questa settimana il team ha stretto quel confine.

rust-nostr

rust-nostr, la libreria Rust per il protocollo, ha unito la PR #1280 aggiungendo costruttori di convenienza per LocalRelayBuilderNip42. I nuovi helper di lettura e scrittura danno ai setup di relay embedded e test un modo più chiaro per trasformare la policy auth NIP-42 in codice. Questa è una piccola patch alla libreria, ma è importante per i team che costruiscono relay locali o integrati nelle app che necessitano di auth attivata senza ripetere boilerplate ogni volta.

Pika

Come dalla copertura precedente di Pika, Pika, l’app di messaggistica basata su Marmot, ha distribuito pika/v1.1.1 e pikachat-v1.1.1 con un ciclo di rilascio focalizzato sulla convergenza del runtime. La PR #542 introduce una facade runtime Marmot condivisa per CLI e sidecar, con l’host dell’app che si sposta sulla stessa superficie. La PR #556 stringe il ciclo di vita degli agenti OpenClaw e lo stato di provisioning, mentre la PR #600 aggiunge il ripristino da backup e una sicurezza di recovery più rigorosa per gli ambienti gestiti.

La superficie utente diretta qui è più piccola rispetto all’ultimo writeup su Pika, ma il cambiamento architetturale è significativo. Riunire logica di gruppo, media, chiamate e sessioni dietro un unico runtime condiviso riduce la possibilità che app e daemon divergano man mano che lo stack Marmot cresce.

Aggiornamenti NIP

Modifiche recenti al repository NIPs:

Uniti:

NIP-54 (Wiki): Passaggio da Asciidoc a Djot (PR #2242): I contenuti wiki su kind 30818 ora usano Djot come formato di markup canonico. Il testo unito aggiunge il comportamento esplicito dei wikilink, esempi di merge-request per kind 818, esempi di redirect per kind 30819, e esempi di normalizzazione per script non latini nei tag d. Questo dà agli implementatori un target di parsing più pulito rispetto ad Asciidoc e rimuove un altro percorso di specifica che dipendeva da un toolchain centrato su Ruby.
NIP-19 (Bech32-Encoded Entities): Aggiunta limite di input (PR #2264): La specifica ora raccomanda di limitare le stringhe di entità codificate Bech32 a 5000 caratteri. Questa è una piccola modifica con valore reale per i parser, perché le stringhe NIP-19 ora appaiono nei flussi QR, deep link, fogli di condivisione e input incollato dagli utenti in molti client.

PR Aperte e Discussioni:

File Nostr Key per NIP-49 (Private Key Encryption) (PR #2269): Propone un formato di file .nostrkey per l’esportazione e importazione di chiavi cifrate con password. Se unito, darebbe ai client un percorso di backup basato su file più normale rispetto alla copia di stringhe ncryptsec grezze.
Consistenza dello stato di appartenenza per NIP-43 (Relay Access Metadata and Requests) (PR #2267): Aggiunge una sezione che chiarisce che i relay dovrebbero mantenere un unico stato di appartenenza autoritativo per pubkey. Questo semplificherebbe la logica dei client di gruppo attorno ai cambiamenti di appartenenza e alla cronologia riprodotta.
Guida alla cancellazione per NIP-17 (Private Direct Messages) (PR #2260): Propone un percorso concreto per la modifica e cancellazione dei messaggi privati attraverso event di cancellazione avvolti in gift wrap. Il lavoro è ancora aperto, ma gli autori di client necessitano di una risposta qui se NIP-17 deve sostituire completamente i vecchi flussi DM.
URI Share-intent per NIP-222 (PR #2266): La bozza standardizzerebbe come le app mobile e desktop passano contenuti condivisi in un client Nostr. Questo è uno dei confini di interoperabilità più ruvidi nei flussi app-to-app attuali.

NIP Deep Dive: NIP-94 (File Metadata)

NIP-94 definisce kind 1063 come un event di metadati di prima classe per un file. La specifica dà all’event il suo content leggibile più tag leggibili dalle macchine per URL di download, tipo MIME, hash, dimensioni, anteprime, fallback e hint sul servizio di storage. Questo è importante perché il file diventa interrogabile sui relay come oggetto a sé stante. Un client non deve estrarre i metadati dal contenuto circostante per capire cos’è il file.

{
 "id": "6a92ef8d7c3a1b5d4e8f9a0b1c2d3e4f567890abcdef1234567890abcdef1234",
 "pubkey": "f1e2d3c4b5a697887766554433221100ffeeddccbbaa99887766554433221100",
 "created_at": 1742342400,
 "kind": 1063,
 "tags": [
 ["url", "https://downloads.example.org/notedeck/v0.8.0-rc2/notedeck-macos-universal.tar.gz"],
 ["m", "application/gzip"],
 ["x", "4a5b6c7d8e9f00112233445566778899aabbccddeeff00112233445566778899"],
 ["ox", "4a5b6c7d8e9f00112233445566778899aabbccddeeff00112233445566778899"],
 ["size", "48392011"],
 ["dim", "0x0"],
 ["magnet", "magnet:?xt=urn:btih:00112233445566778899aabbccddeeff00112233"],
 ["i", "00112233445566778899aabbccddeeff00112233"],
 ["blurhash", "LEHV6nWB2yk8pyo0adR*.7kCMdnj"],
 ["thumb", "https://downloads.example.org/notedeck/v0.8.0-rc2/thumb.png", "bbccddeeff00112233445566778899aabbccddeeff0011223344556677889900"],
 ["image", "https://downloads.example.org/notedeck/v0.8.0-rc2/screenshot.png", "ccddeeff00112233445566778899aabbccddeeff001122334455667788990011"],
 ["summary", "Signed macOS release artifact for Notedeck v0.8.0-rc2"],
 ["alt", "Notedeck desktop release archive"],
 ["fallback", "https://mirror.example.net/notedeck/v0.8.0-rc2/notedeck-macos-universal.tar.gz"],
 ["service", "nip96"]
 ],
 "content": "Notedeck macOS universal build",
 "sig": "11aa22bb33cc44dd55ee66ff77889900aabbccddeeff0011223344556677889911aa22bb33cc44dd55ee66ff77889900aabbccddeeff00112233445566778899"
}

I tag fanno più lavoro di quanto appaia a prima vista. x identifica il file servito, mentre ox identifica il file originale prima di qualsiasi trasformazione lato server. I tag di anteprima permettono ai client di costruire indici di file navigabili senza scaricare l’intero asset, e summary può portare un breve estratto accanto ad essi. fallback fornisce una seconda sorgente quando l’URL principale fallisce, e service indica il protocollo di storage dietro il file, come NIP-96 o un altro host. NIP-94 si colloca quindi sotto il posting sociale e sopra lo storage grezzo. Descrive il file, non la conversazione attorno al file.

Ecco perché l’updater di Notedeck di questa settimana è interessante. La PR #1326 usa event firmati di kind 1063 per la scoperta dei rilasci software, poi verifica il binario scaricato rispetto allo SHA256 pubblicato. La stessa forma di event può descrivere un artefatto software o un upload media. NIP-94 è abbastanza vecchio da essere stabile, ma ha ancora spazio per crescere perché sempre più progetti trattano gli event di metadati come un trasporto per le macchine, non solo come decorazione per le persone.

NIP Deep Dive: NIP-54 (Wiki)

NIP-54 definisce kind 30818 come un event articolo wiki. La specifica tratta il tag d come l’argomento normalizzato dell’articolo e permette a molti autori di pubblicare voci per lo stesso soggetto. Il corpo dell’articolo vive in content, mentre i tag gestiscono identità normalizzata, titolo di visualizzazione, sommari e riferimenti a versioni precedenti. Questo significa che NIP-54 non è solo un formato di contenuto. È anche un problema di recupero e ranking, perché ogni client deve ancora decidere quale versione dell’articolo mostrare.

{
 "id": "8c94e5d1f2a300112233445566778899aabbccddeeff00112233445566778899",
 "pubkey": "00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff",
 "created_at": 1742342400,
 "kind": 30818,
 "tags": [
 ["d", "nostr-wiki"],
 ["title", "Nostr Wiki"],
 ["summary", "Djot-formatted reference article about Nostr wiki events"],
 ["a", "30818:11223344556677889900aabbccddeeff00112233445566778899aabbccddeeff:nostr-wiki", "wss://relay.example.org", "fork"],
 ["e", "11223344556677889900aabbccddeeff00112233445566778899aabbccddeeff", "wss://relay.example.org", "fork"]
 ],
 "content": "Nostr is a [protocol][] for carrying events across relays.\n\n[protocol]: nostr:nevent1example",
 "sig": "33cc44dd55ee66ff77889900aabbccddeeff0011223344556677889900112233cc44dd55ee66ff77889900aabbccddeeff00112233445566778899001122"
}

Il merge di questa settimana cambia il markup canonico da Asciidoc a Djot nella PR #2242. Questo è importante per gli implementatori perché Djot ha una specifica standalone più stretta e una storia di parser più semplice attraverso i linguaggi. Il testo unito chiarisce anche come i wikilink in stile reference si risolvono, come le merge request usano kind 818, come i redirect usano kind 30819, e come la normalizzazione del tag d dovrebbe comportarsi per gli script non latini. Queste sono le parti che fanno sì che due client indipendenti concordino su quale articolo un link punta.

NIP-54 occupa anche un posto insolito nel protocollo. Un client wiki necessita di rendering del contenuto, ma necessita anche di una policy di ranking. Reazioni, liste relay, liste contatti e segnali di deferenza espliciti alimentano tutti quale articolo vince per un dato argomento. Il passaggio a Djot non risolve quel problema di ranking, ma rimuove una delle ambiguità del parser che stava sotto di esso. Ecco perché il merge è importante ora: la modifica riguarda meno la formattazione della prosa più bella e più il rendere il comportamento wiki multi-client più facile da implementare in modo consistente.

Stai costruendo qualcosa, o vuoi che lo copriamo? Contattaci tramite DM NIP-17 su Nostr a npub1wav4fae3gyfy3xj298kxj2mj8phavz7vavps34przq02j7w902qq902923.

Nostr Compass #13

Wed, 11 Mar 2026 00:00:00 +0000

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

Questa settimana: Shopstr e Milk Market aggiungono superfici MCP per il commercio guidato da agenti, mentre OAuth Bunker, Amber e strfry aggiungono relay-auth e supporto agli event protetti di NIP-42 in software per app, signer e relay. Route96 distribuisce due release incentrate su etichettatura AI, code di moderazione, perceptual hashing e documentazione server machine-readable. Samizdat, già live sul web, ha rilasciato la sua prima alpha Android e in seguito ha aggiunto il supporto signer di NIP-55. Formstr aggiunge la registrazione tramite NIP-49, Amethyst distribuisce il lavoro di risoluzione NIP-05 basato su Namecoin, Mostro rilascia la v0.16.4, e il repository NIPs unisce NIP-91 e le linee guida difensive per NIP-66.

Notizie

Shopstr e Milk Market aprono superfici MCP per il commercio

Shopstr, il marketplace peer-to-peer con pagamenti Lightning e Cashu, ha unito PR #234 (commit 94ef7d1), aggiungendo un server MCP con autenticazione API key per la gestione degli account degli agenti. La modifica aggiunge .well-known/agent.json per la discovery degli agenti, endpoint MCP per onboarding e stato, route per la creazione degli ordini e la verifica dei pagamenti, strumenti dedicati per acquisto e lettura, e una schermata impostazioni per le API key. PR #236 estende il tutto con azioni lato venditore per messaggi, indirizzi, aggiornamenti degli ordini e selezione delle specifiche di prodotto. Una correzione di sicurezza in PR #235 sostituisce l’hashing delle API key con SHA-256 a singola iterazione con PBKDF2 salato a 100.000 iterazioni.

Gli agenti possono leggere gli annunci di NIP-99 e procedere al checkout usando i flussi di pagamento esistenti di NIP-47 e NIP-60 senza dover fare scraping delle pagine o reverse-engineering del comportamento del client.

Milk Market, marketplace alimentare su Nostr attivo su milk.market, ha introdotto la stessa base MCP e API key nel commit da6c0b4. PR #10 aggiunge ordini in abbonamento, modifica dell’indirizzo di spedizione dopo l’acquisto, e gestione del checkout multi-merchant e multi-valuta per Stripe e altri percorsi di pagamento fiat. Una successiva PR #11 corregge un bug di inizializzazione del database all’avvio in cui la tabella delle pubblicazioni relay fallite non veniva creata nelle installazioni nuove, causando errori 500 al primo caricamento. L’interfaccia rivolta agli agenti funziona con checkout Bitcoin-native su Shopstr o con checkout misto fiat e Bitcoin su Milk Market.

NIP-42 relay auth tra bunker, signer e relay

OAuth Bunker, un bunker NIP-46 che collega provider OAuth alla firma Nostr, ha aggiunto il login NIP-07, la selezione automatica della singola identità e la pulizia delle identità eliminate (commit f0c7683). Quando esiste una sola identità, il bunker ora la seleziona automaticamente invece di chiedere all’utente. L’eliminazione di un’identità rimuove anche assegnazioni e connessioni rimaste orfane. Il commit 6b8796c aggiunge un percorso di configurazione ALWAYS_ALLOWED_KINDS per gli utenti assegnati, con kind 30078 come valore predefinito per i dati specifici dell’app, così le identità delegate possono scrivere nello storage dell’app senza approvazione per ogni event.

Amber, il signer NIP-55 principale su Android, ha distribuito la v4.1.3-pre4 insieme a quattro pre-release nel corso della settimana. PR #317 aggiunge la gestione dell’autenticazione relay NIP-42 per richieste di kind 22242. L’implementazione aggiunge una nuova colonna nel database che traccia i permessi specifici per relay con un indice univoco su (pkKey, type, kind, relay). Gli utenti vedono una schermata auth dedicata dove possono concedere o negare il permesso per relay singolo o per tutti i relay con wildcard *, e salvare quella scelta. I permessi wildcard cancellano tutte le voci specifiche per relay di quel kind. PR #318 segue con un refactor delle schermate per richieste multi-event, che ora mostrano i dettagli inline tramite composable card invece di navigare verso una schermata separata. La release aggiorna anche i relay profilo predefiniti, aggiunge la visualizzazione delle richieste in bottom sheet e corregge un crash sui dispositivi MediaTek disabilitando il keystore StrongBox.

Sul lato relay, strfry PR #156 implementa la gestione auth NIP-42 per gli event protetti di NIP-70, e PR #176 rifiuta i repost che incorporano event protetti.

Notedeck aggiunge i limiti relay di NIP-11 e funzionalità Agentium

Notedeck, il client desktop nativo del team Damus, ha unito 14 PR questa settimana. PR #1316 aggiunge il recupero dei limiti relay di NIP-11, così tutti i relay outbox ora rispettano max_message_length e max_subscriptions dal relay information document. L’implementazione include elaborazione in background, exponential backoff con jitter per i retry di connessione e header HTTP Accept personalizzati. PR #1312 corregge un bug per cui i DM talvolta non si caricavano dopo il cambio account, e PR #1333 aggiunge un meccanismo di backoff alla comunicazione relay multicast per evitare broadcast spam in caso di errore.

Il sottosistema Agentium, l’interfaccia integrata per agenti di coding di Notedeck chiamata internamente “Dave”, ha ricevuto il supporto all’incolla di immagini dalla clipboard, configurazioni di esecuzione nominate che si sincronizzano tra dispositivi tramite event kind 31991 di NIP-33, un creatore di git worktree e un model picker per selezionare backend diversi per sessione (PR #1336). PR #1338 integra egui_kittest per test UI headless, e PR #1339 aggiunge una dashboard card che traccia la creazione di nuove contact list da parte dei client. Una PR #1314 ancora aperta porta in Notedeck la risoluzione NIP-05 basata su Namecoin di Amethyst con lookup ElectrumX, routing SOCKS5 via Tor e integrazione nella barra di ricerca.

diVine distribuisce la v1.0.6 con infrastruttura di test E2E e import NIP-49

diVine, il client video short-form in loop che ripristina gli archivi Vine su divine.video, ha distribuito la v1.0.6 con 127 PR unite. La release aggiunge l’import account NIP-49, supporto NIP-05 esterno, gestione multi-account, build macOS e Linux sperimentale, e una libreria ridisegnata per draft e clip basata su storage locale.

Sul lato engineering, PR #1928 aggiunge un’infrastruttura completa di test di integrazione E2E usando Patrol per l’automazione UI nativa contro uno stack backend Docker composto da relay, API, Blossom, Postgres, Redis e ClickHouse. Cinque test del percorso auth coprono registrazione, verifica, reset password, scadenza sessione e refresh del token. PR #2105 cambia il caricamento video da HLS-first a MP4 diretto con fallback automatico a HLS, riducendo i tempi di caricamento da 30-60 secondi a quasi istantanei. PR #2076 mette in cache la risposta API del feed home in SharedPreferences per la visualizzazione immediata a cold start. PR #2104 impone che le etichette di contenuto ai-generated siano nascoste nei feed, e PR #2100 aggiunge un’impostazione di sicurezza per mostrare solo video ospitati da diVine. La migrazione della cache profili da Hive a Drift prosegue nelle PR #1881, PR #1883 e PR #1903, sostituendo circa 1.074 linee di codice Hive con DAO Drift.

Vector v0.3.2 distribuisce la sincronizzazione negentropy di NIP-77 e miglioramenti MLS

Vector, messenger desktop orientato alla privacy che usa la cifratura di gruppo MLS con NIP-17 e NIP-44, ha distribuito la v0.3.2. La novità principale è la negentropy NIP-77 per la sincronizzazione dei gruppi MLS (commit b06adf4), che recupera i messaggi persi molto più rapidamente tramite parallel boot. La release aggiunge anche un motore audio ricostruito con pieno supporto Linux, spoiler immagine con anteprime sfocate, hyperlink cliccabili con anteprime ricche, ping @mention con @everyone per gli admin dei gruppi, autocomplete per shortcode emoji, silenziamento dei gruppi, tap-to-react sulle reazioni esistenti e upload file annullabili. Vector filtra esplicitamente gli event di chat di gruppo NIP-17 (commit 2179a51), usando MLS in modo esclusivo per la cifratura di gruppo.

Rilasci

Route96 v0.5.0 e v0.5.1

Route96, media server che supporta Blossom e NIP-96, ha distribuito v0.5.0 e v0.5.1. La v0.5.0 aggiunge etichettatura AI automatizzata, backfill retroattivo per upload non etichettati, code di moderazione per file segnalati, rifiuto basato su EXIF per la privacy e gestione degli hash vietati.

La v0.5.1 aggiunge hash percettivi per immagini, locality-sensitive hashing per la ricerca di immagini simili, endpoint admin batch e un SKILL.md pubblicato che descrive la superficie API Blossom e NIP-96 del server per gli strumenti agentici. PR #58 sposta i background worker su task Tokio completamente asincroni, e il commit 97b00a3 aggiunge il backoff per evitare hot loop.

Samizdat v1.0.0-alpha

Samizdat, lettore e publisher long-form disponibile su samizdat.press, ha distribuito la sua prima build Android nella v1.0.0-alpha. L’app si apre con una pagina Press curata di articoli long-form Nostr e navigazione bottom tab tra le viste Press, Feed, Saved e Write. La build Android aggiunge storage nativo delle chiavi tramite cifratura Android Keystore con sblocco biometrico, gestisce URI nostr: e deep link samizdat.press, e supporta il passaggio della firma tramite chooser delle app Android, Amber, Primal e altre, invece di richiedere l’import diretto delle chiavi. Pull-to-refresh, gestione delle safe area su schermi di dimensioni diverse, e integrazioni native per condivisione, clipboard, feedback aptico e splash screen fanno ora parte della shell Android invece del wrapper web.

Il commit d17308f aggiunge la firma intent-based NIP-55 per i flussi Amber e Primal, e il commit e29dab8 sostituisce un workaround JavaScript bridge con un plugin Capacitor nativo che usa startActivityForResult. L’app richiede Android 7.0+ (API 24), viene distribuita come APK debug in questa alpha e ancora non include notifiche push. La pubblicazione dipende al momento da un’app signer, mentre il login con nsec copre la lettura locale e l’accesso all’account.

Calendar by Form* v0.2.0

Calendar by Form*, calendario decentralizzato con condivisione di eventi privati tramite NIP-59, disponibile su calendar.formstr.app, ha distribuito la v0.2.0 con PR #38. La release estende la gestione degli eventi ricorrenti di NIP-52, andando oltre la base a evento singolo della v0.1.0. Le modifiche sottostanti toccano anche storage locale degli eventi, gestione del signer e plumbing delle notifiche Android. Questa è la seconda applicazione attiva dell’organizzazione Formstr dopo la migrazione del repository dello scorso mese.

Mostro v0.16.4

Mostro, exchange Bitcoin peer-to-peer costruito su Nostr, ha rilasciato la v0.16.4. Le correzioni per il ripristino delle sessioni di disputa (PR #599) e la chiusura automatica (PR #606), coperte la settimana scorsa, sono incluse. Nuove in questa release: PR #625 aggiunge un campo days agli event di rating utente di kind 38384, PR #612 aggiunge la scadenza a quegli event di rating, e PR #614 sposta gli event ordine verso le impostazioni di scadenza configurate invece di una finestra hardcoded di 24 ore. PR #622 aggiunge un controllo di idempotenza per evitare pagamenti duplicati delle dev fee.

Mostro Mobile v1.2.1

Mostro Mobile, client Flutter per l’exchange P2P Mostro, ha distribuito la v1.2.1 con 11 nuove funzionalità e 11 bug fix. La release aggiunge il rendering di contenuti multimediali cifrati nella chat di disputa (PR #514), la chiusura automatica della UI delle dispute quando gli ordini raggiungono uno stato terminale (PR #503), la scansione QR per importare wallet NWC (commit 12eaee4), traduzioni francesi e gestione delle notifiche push FCM. PR #496 corregge un bug di padding delle firme Schnorr bloccando la dipendenza bip340 alla v0.2.0.

0xchat v1.5.4

0xchat, client di messaggistica in stile Telegram con supporto Cashu, ha distribuito la v1.5.4 focalizzata sulle correzioni per Linux desktop: icone AppImage nel dock, rendering delle emoji, freeze nei menu contestuali e blocchi della UI per reply/copy. La release corregge anche i problemi di upload delle immagini e l’integrazione npub.cash. PR #49 elimina rebuild UI non necessari rimuovendo un timer di polling da 3 secondi che forzava repaint glassmorphic senza fare nulla, e sblocca l’inizializzazione del login eseguendo il caricamento della cache event in parallelo invece di bloccare l’avvio di relay, contatti e canali.

Keep v0.6.0

Keep, signer threshold FROST per Android con supporto NIP-55 e NIP-46, ha distribuito v0.6.0 e v0.6.1. La v0.6.0 aggiunge coordinamento dei wallet descriptor e relativa UI di gestione, un flusso backup/restore con autenticazione biometrica (PR #184), recupero nsec da threshold share (PR #187), generazione cross-platform di frame QR animati tramite Rust UniFFI (PR #188) e un audit trail della firma con verifica della chain (PR #189). La v0.6.1 cambia la licenza da AGPL-3.0 a MIT (PR #191).

njump v0.3.0

njump, gateway statico per visualizzare contenuti Nostr su njump.me, ha distribuito la v0.3.0 con una modifica incompatibile nel parsing dei codici note1 e un aggiornamento della libreria nostr sottostante.

Roadstr v0.1.1

Roadstr, applicazione decentralizzata per segnalare eventi stradali usando Nostr, ha distribuito la sua prima demo v0.1.1. L’app mostra gli eventi stradali su una mappa usando vector tile da openfreemap.org.

Bitcredit v0.5.3

Bitcredit, applicazione di e-bill con transport layer Nostr e relay dedicato su bit.cr, ha distribuito la v0.5.3. PR #846 aggiunge i campi payment_actions e bill_state all’API per stato dei pagamenti e dell’accettazione, e PR #849 corregge la gestione dell’indirizzo di firma per signer anonimi.

OpenChat v0.1.0-alpha.3

OpenChat, applicazione chat costruita sulle librerie .NET MLS e C# del protocollo Marmot, ha distribuito la v0.1.0-alpha.3. La release aggiunge supporto a signer esterni per Amber e flussi NIP-46 (commit e568d97), sposta la persistenza dello stato MLS dentro il servizio MLS per eliminare la perdita di dati nella finestra di crash (commit 4720bc8), e pubblica build Windows, Linux e Android attraverso una nuova pipeline CI.

OpenSignal v1.0.0

OpenSignal, trading copilot Kotlin Multiplatform per Nostr, ha distribuito la v1.0.0. La release include moduli KMP condivisi per logica di dominio, rendering dei grafici, autenticazione e pubblicazione Nostr, supporto upload Blossom NIP-96 e hook di inferenza AI basati su ONNX su shell Desktop e Android. L’architettura pubblicata include anche un servizio AI FastAPI per l’analisi di screenshot dei grafici, pipeline di training dei modelli e un motore di rischio che produce piani di trading strutturati con sizing e warning. Il login supporta chiavi nsec grezze oppure signer esterni, e il flusso di output termina con la pubblicazione di event Nostr invece che con un’analisi solo locale.

Aggiornamenti Progetto

Formstr

Formstr, l’alternativa a Google Forms su Nostr, ha unito PR #434 (commit e9c4fd5), aggiungendo un flusso di registrazione che usa chiavi private cifrate NIP-49. Prima di questa modifica, gli utenti avevano bisogno di un’estensione browser NIP-07 oppure di incollare una nsec grezza per usare Formstr. Il nuovo flusso genera una coppia di chiavi lato client, cifra la chiave privata con una password scelta dall’utente tramite lo schema scrypt + XChaCha20-Poly1305 di NIP-49, e memorizza la stringa ncryptsec risultante. Gli utenti possono quindi accedere di nuovo con la propria password senza installare un’estensione signer. La gestione delle chiavi resta interamente lato client.

Amethyst

Amethyst, il client Android ricco di funzionalità, ha unito quattro PR che distribuiscono il lavoro di risoluzione NIP-05 supportato da Namecoin che era aperto la settimana scorsa. PR #1734 aggiunge una verifica NIP-05 resistente alla censura via ElectrumX per identificatori .bit, d/ e id/. Quando Amethyst rileva uno di questi suffissi in un campo NIP-05, interroga un server ElectrumX-NMC per la cronologia delle transazioni del nome, analizza lo script NAME_UPDATE dall’ultimo output per estrarre la pubkey Nostr e rifiuta i nomi più vecchi di 36.000 blocchi, la finestra di scadenza di Namecoin. Le connessioni ElectrumX passano attraverso SOCKS5 quando Tor è attivo, con selezione dinamica del server tra endpoint clearnet e .onion. Una cache LRU con TTL di un’ora evita interrogazioni ripetute della blockchain.

PR #1771 corregge race condition e accuratezza del resolver in quel flusso. PR #1785 permette ai nuovi utenti di importare una follow list durante la registrazione sia da normali identificatori NIP-05 sia da quelli supportati da Namecoin. PR #1786 aggiunge impostazioni personalizzate per il server ElectrumX così gli utenti possono scegliere quale server gestirà i loro lookup.

nostr-idb

nostr-idb, libreria che fornisce metodi helper per memorizzare event Nostr in IndexedDB, ha unito PR #6 aggiungendo il supporto ai filtri tag AND di NIP-91. La modifica aggiunge semantica di intersezione al matching lato client dei filtri, così le query IndexedDB possono richiedere tutti i valori tag elencati invece di uno qualsiasi. PR #8 aggiorna la libreria all’ultima interfaccia NIP-DB, e un successivo commit b49b3d3 corregge un deadlock di subscribe e rimuove nostr-tools come dipendenza di produzione.

Pensieve

Pensieve, indicizzatore Nostr archive-first con analytics ClickHouse, ha unito PR #8 aggiungendo enforcement del TTL della cache per entry e coalescing dei miss per chiave, così da ridurre i picchi di CPU API. Gli endpoint time-series più costosi, statistiche di engagement, attività oraria e attività per kind, usano ora TTL server-side di 10 minuti invece di innescare tempeste di ricalcolo sincronizzate.

Blossom

Blossom, protocollo e stack server per l’hosting media decentralizzato, ha unito due aggiornamenti di autorizzazione BUD-11. PR #91 sposta l’autorizzazione opzionale in un BUD dedicato e chiarisce il ruolo dei tag x e server. PR #93 ripulisce il comportamento auth specifico per endpoint e formalizza l’header X-SHA-256 per la verifica degli upload. Le due PR consolidano la logica auth in BUD-11 e rimuovono ambiguità sull’hashing delle richieste nei flussi di upload, delete e media management.

Aggiornamenti NIP

Cambiamenti recenti nel repository NIPs:

Uniti:

NIP-91 (AND Operator for Filters) (PR #1365): aggiunge semantica di intersezione per i filtri tag, permettendo ai relay di rispondere a query che richiedono tutti i valori tag elencati invece di uno qualsiasi. Riduce il post-filtering lato client e la larghezza di banda nelle query ricche di tag.
NIP-66 (Relay Discovery and Liveness Monitoring): misure difensive (PR #2240): dopo il lavoro di benchmark outbox coperto la settimana scorsa, la specifica aggiunge ora avvertimenti sui percorsi sfavorevoli dei dati di monitoraggio relay. I client non devono richiedere event di monitoraggio kind 30166 per funzionare. Un monitor può essere errato, obsoleto o malevolo. Ci si aspetta che i client incrocino le fonti ed evitino di tagliare ampie parti del grafo relay di un utente basandosi su un singolo feed.
NIP-39 (External Identities in Profiles): pulizia del registry kind 10011 (PR #2256): aggiunge il riferimento al kind 10011 direttamente nella specifica, allineandosi con l’implementazione di Amethyst coperta la settimana scorsa.

PR aperte e discussioni:

NIP-70 (Protected Events): rifiutare i repost che incorporano event protetti (PR #2251): se un relay applica NIP-70 all’event originale ma accetta repost che trasportano lo stesso contenuto, il tag - non ha effetto pratico. Questa PR aggiunge la regola per cui i relay devono rifiutare anche i repost di kind 6 e kind 16 degli event protetti. strfry PR #176 lo implementa già.
NIP-71 (Video Events): tracce audio multiple (PR #2255): aggiunge tag audio imeta per tracce alternative, varianti linguistiche e stream solo audio. Un client potrebbe mantenere stabile il file video cambiando lingua audio, oppure servire l’audio come traccia separata per contenuti tipo podcast.
NIP-11 (Relay Information Document) e attributi relay di NIP-66 (PR #2257): aggiunge un campo attributes strutturato ai relay information document, fornendo a client e strumenti di discovery metadati machine-readable oltre l’attuale descrizione a testo libero.

NIP Deep Dive: NIP-49 (Cifratura della chiave privata)

NIP-49 definisce come un client cifra una chiave privata con una password e codifica il risultato come stringa bech32 ncryptsec. Formstr usa NIP-49 nel suo nuovo flusso di registrazione.

Il formato non è legato a un kind di event dedicato. Un client parte dalla chiave privata secp256k1 grezza a 32 byte, deriva una chiave simmetrica dalla password dell’utente con scrypt, cifra la chiave usando XChaCha20-Poly1305, poi incapsula il risultato in una stringa bech32 ncryptsec. Un flag di un byte registra se la chiave è mai stata gestita in modo insicuro prima della cifratura.

{
 "id": "4d47f4f0a6f6edbc1bbd7f4e2a45ec68f27cba91d6c6ab5cf28d8d87b0f3d57e",
 "pubkey": "1f8b4c3e7b0f9451d4f9b8a7c6e5d4c3b2a1908f7e6d5c4b3a29181716151413",
 "created_at": 1741699200,
 "kind": 30078,
 "tags": [
 ["d", "encrypted-key-backup"],
 ["format", "ncryptsec"],
 ["encryption", "nip49"]
 ],
 "content": "ncryptsec1qgg9947rlpvqu76pj5ecreduf9jxhselq2nae2kghhvd5g7dgjtcxfqtd67p9m0w57lspw8gsq6yphnm8623nsl8xn9j4jdzz84zm3frztj3z7s35vpzmqf6ksu8r89qk5z2zxfmu5gv8th8wclt0h4p",
 "sig": "6a8f6e4b2d1901735f0ad4b6e8c1f3a579d0e2b4c6f8a1d3e5f7091b2c3d4e5f11223344556677889900aabbccddeeff00112233445566778899aabbccddeeff"
}

L’event JSON sopra è un esempio a livello applicativo, non un requisito NIP-49. Il NIP standardizza il formato della chiave cifrata. Un client può memorizzare ncryptsec localmente, sincronizzarlo tramite storage specifico dell’app o esportarlo come stringa di backup. Le password sono normalizzate in Unicode NFKC prima della derivazione della chiave, così la stessa password può decifrare in modo coerente tra client e piattaforme.

Il flag di sicurezza della chiave a un byte ha tre valori definiti: 0x00 significa che la cronologia di gestione della chiave è sconosciuta, 0x01 significa che la chiave è nota per essere stata gestita in modo insicuro, per esempio incollata in chiaro in un form web prima della cifratura, e 0x02 significa che la chiave è stata generata e cifrata in un contesto sicuro e non è mai stata esposta. I client possono usare questa informazione per mostrare avvisi quando importano chiavi con una storia nota di gestione insicura.

NIP-49 protegge le chiavi meglio dell’esportazione semplice nsec, ma la cifratura è forte solo quanto la password e il costo scrypt configurato. Valori LOG_N più alti rendono l’attacco offline più difficile ma rallentano anche la decifratura legittima. La specifica sconsiglia di pubblicare chiavi cifrate su relay pubblici, perché gli attaccanti traggono vantaggio dal raccogliere ciphertext da sottoporre a cracking offline. Per confronto, la firma remota di NIP-46 evita di esporre del tutto le chiavi, e la firma Android di NIP-55 le mantiene all’interno di un’app signer dedicata. NIP-49 occupa uno spazio diverso: backup cifrato portabile per utenti che gestiscono le proprie chiavi.

Le implementazioni includono Formstr PR #434 per la registrazione, Amber per backup e restore ncryptsec, diVine v1.0.6 per l’import account, Keep v0.6.0 per l’esportazione di share FROST, e strumenti di gestione delle chiavi come nsec.app e Alby.

NIP Deep Dive: NIP-70 (Event protetti)

NIP-70 definisce gli event protetti. Quando un event porta il tag ["-"], un relay deve rifiutarlo a meno che il relay richieda l’autenticazione NIP-42 e la pubkey autenticata corrisponda all’autore dell’event.

Il flusso auth di NIP-42 funziona così: il relay invia una challenge AUTH contenente una stringa casuale, e il client risponde con un event signed di kind 22242 i cui tag includono l’URL del relay e la challenge. Il relay verifica la firma e controlla che la pubkey nell’event auth coincida con la pubkey dell’event protetto in pubblicazione. Se le pubkey non coincidono, il relay rifiuta l’event con il prefisso di messaggio restricted.

Il contenuto dell’event può comunque essere pubblico. Il tag - controlla solo chi può pubblicare l’event su un relay che onora il tag. Questo copre feed semi-chiusi di NIP-29, spazi relay riservati ai membri e altri contesti in cui l’autore vuole limitare la ridistribuzione attraverso il grafo relay. NIP-70 è una convenzione a tag singolo, non un nuovo kind di event, quindi qualunque kind esistente può portare il tag -.

{
 "id": "cb8feca582979d91fe90455867b34dbf4d65e4b86e86b3c68c368ca9f9eef6f2",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1707409439,
 "kind": 1,
 "tags": [
 ["-"]
 ],
 "content": "hello members of the secret group",
 "sig": "fa163f5cfb75d77d9b6269011872ee22b34fb48d23251e9879bb1e4ccbdd8aaaf4b6dc5f5084a65ef42c52fbcde8f3178bac3ba207de827ec513a6aa39fa684c"
}

Anche se un relay blocca la pubblicazione di terzi dell’event originale, qualcuno può ripubblicarne il contenuto dentro un repost. PR #2251 affronta il problema richiedendo ai relay di rifiutare anche i repost di kind 6 e kind 16 degli event protetti. strfry PR #156 aggiunge la gestione auth NIP-42 per gli event protetti, e strfry PR #176 blocca i repost che incorporano contenuto protetto.

NIP-70 controlla il comportamento del relay. Un destinatario può comunque copiare altrove il contenuto, e la specifica lo dice esplicitamente. Il tag - fornisce ai relay un segnale machine-readable per rifiutare la ripubblicazione. Per confronto, NIP-62 chiede ai relay di cancellare i dati dopo il fatto, mentre NIP-70 impedisce la pubblicazione non autorizzata al momento dell’ingest. I due approcci sono complementari: un autore può contrassegnare gli event come protetti per limitarne la diffusione, e in seguito chiedere la cancellazione se desidera che il contenuto venga rimosso dai relay che lo avevano accettato.

Per questa settimana è tutto. State costruendo qualcosa o avete novità da condividere? Contattateci via DM NIP-17 o cercateci su Nostr.

Nostr Compass #12

Wed, 04 Mar 2026 00:00:00 +0000

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

Questa settimana: Il Marmot Development Kit distribuisce il suo primo rilascio pubblico con media cifrati e binding multi-linguaggio. Nostrability pubblica benchmark del modello outbox su 14 algoritmi di selezione dei relay. Wisp passa dalla prima alpha alla beta in otto giorni con Tor e firma NIP-55 (Applicazione Signer Android). NIP-91 (filtri AND) viene unito. Vector v0.3.1 porta la sincronizzazione negentropy con miglioramenti delle prestazioni di 15 volte. Questo numero include anche la retrospettiva Cinque Anni di Febbraio di Nostr, che traccia il protocollo da una riscrittura della specifica che serviva tre relay fino all’esplosione di Damus sull’App Store, passando per le reti mesh e le proposte per agenti AI.

Notizie

Il Modello Outbox Sotto la Lente

Nostrability ha pubblicato una serie di benchmark sul modello outbox che testano quanto bene diversi algoritmi di selezione dei relay recuperano event dalla rete relay decentralizzata. Il progetto ha unito 16 PR e 76 commit in dieci giorni, producendo quella che potrebbe essere l’analisi empirica più approfondita delle strategie di implementazione di NIP-65 (Relay List Metadata) fino ad oggi.

I benchmark testano 14 algoritmi di selezione dei relay rispetto a liste di follow reali su 15 client e librerie in cinque linguaggi. Un approccio baseline di interrogazione dei soli relay popolari recupera circa il 26% degli event. Il greedy set-cover con Thompson Sampling raggiunge l'80-90% di richiamo. L’aggiunta di una variante sensibile alla latenza che usa lo sconto iperbolico e il tracciamento della latenza dei relay con EWMA ha portato la completezza dal 62-80% al 72-96% al segno dei 2 secondi su sei profili di test.

Il filtraggio dei relay inattivi tramite NIP-66 (Relay Monitoring) si è rivelato significativo. Il pre-filtraggio dei candidati relay rispetto ai dati di liveness di nostr.watch ha rimosso il 40-64% dei relay inattivi e raddoppiato i tassi di successo dei relay dal 30% al 75-85%. I tempi di caricamento dei feed sono diminuiti del 39% (da 40 secondi a 24 secondi su 10 profili). Una simulazione EOSE-race ha rilevato che attendere l’EOSE più un periodo di grazia di 200ms migliorava la completezza rispetto all’arresto al primo relay che terminava.

Per i client che non possono riscrivere completamente il proprio routing dei relay, un approccio di “arricchimento outbox ibrido” aggiunge query outbox per autore sopra i relay applicativi hardcoded esistenti. Questo approccio ibrido ha raggiunto l'80% di richiamo degli event su un anno rispetto al 26% del baseline, offrendo un percorso di migrazione per i client con architetture relay legacy.

ContextVM Apre il NIP per MCP e Distribuisce Gift Wrap Effimeri

ContextVM, il protocollo che collega Nostr con il Model Context Protocol, ha aperto due proposte nel repository NIPs questa settimana. La PR #2246 formalizza CVM come convenzione per il trasporto di messaggi MCP JSON-RPC su Nostr tramite event effimeri di kind 25910. La PR #2245 estende NIP-59 (Gift Wrap) con un kind effimero (21059) che segue la semantica effimera di NIP-01 (Flusso Base del Protocollo), permettendo ai relay di scartare i messaggi avvolti dopo la consegna.

La convenzione gift wrap effimera è stata distribuita come CEP-19 nella famiglia di rilasci ContextVM SDK v0.6.x. L’implementazione SDK aggiunge un enum GiftWrapMode con tre impostazioni: OPTIONAL (accetta entrambi i kind e rileva automaticamente la capacità del peer), EPHEMERAL (solo kind 21059) e PERSISTENT (solo kind 1059). Per le chiamate agli strumenti AI, la modalità effimera evita di memorizzare il traffico intermedio di richiesta-risposta sui relay, riducendo sia i costi di storage che l’esposizione della privacy.

Nuovi server MCP pubblici sono apparsi sulla rete da operatori indipendenti, incluso un server di query Wolfram Alpha. Il team ContextVM ha pubblicato CEP-15 (schema degli strumenti comuni) e CEP-17 (pubblicazione della lista relay del server) insieme al ciclo di rilascio v0.6.x.

Marmot Development Kit Distribuisce il Primo Rilascio Pubblico

MDK (Marmot Development Kit), la libreria Rust che alimenta la messaggistica cifrata con Marmot su Pika e White Noise, ha distribuito la v0.6.0 come primo rilascio pubblico. Oltre 200 PR sono state unite in questa versione, con sei nuovi contributor.

Il rilascio include il supporto ai media cifrati (MIP-04) con derivazione del seed HKDF (MIP-01 v2), risoluzione deterministica delle race condition dei commit (MIP-03), storage locale cifrato, validazione dell’autorizzazione admin per i commit e le proposte Marmot, e supporto GREASE per l’estensibilità del protocollo. I binding sono disponibili per Kotlin, Python, Ruby e Windows insieme alla cross-compilazione Android. La libreria si aggiorna a OpenMLS 0.8.0 con correzioni degli avvisi di sicurezza e un tipo Secret<T> che azzera i valori sensibili in memoria.

Una modifica companion al protocollo (MIP-03) ha sostituito la cifratura NIP-44 (Encrypted Payloads) con ChaCha20-Poly1305 per i messaggi di kind 445. NIP-44 richiedeva input di stringhe UTF-8 per specifica, rendendo impossibile passare i byte grezzi dei messaggi Marmot attraverso le librerie Nostr TypeScript standard. La sostituzione deriva le chiavi direttamente dal segreto esportatore Marmot. Questa modifica incompatibile ha richiesto aggiornamenti coordinati tra la specifica core, MDK e l’SDK TypeScript.

marmot-ts, l’implementazione TypeScript mantenuta da hzrd149, ha unito quattro PR con modifiche incompatibili alle API a loro volta. Un aggiornamento omnibus ha aggiunto un gestore di key package per il ciclo di vita create/publish/rotate, un metodo di convenienza sendChatMessage, anteprima degli inviti senza entrare nel gruppo (readInviteGroupInfo), auto-aggiornamento per le rotazioni di forward-secrecy e logging di debug strutturato. Le API di decifratura dei gruppi sono state rinominate da readGroupMessage a decryptGroupMessage con varianti di risultato più ricche (processed/skipped/rejected/unreadable). gzuuus ha contribuito alla pulizia degli esempi con supporto relay NIP-65 e gestione dei key package di ultima risorsa secondo MIP-00.

La White Noise CLI (wn), il backend Rust che alimenta sia l’app mobile che la nuova TUI, ha unito 16 PR in dieci giorni. La gestione del ciclo di vita del signer ha ottenuto la sicurezza in caso di cancellazione attraverso un RAII scope guard (PR #538), correggendo una classe di bug in cui le operazioni interrotte potevano far trapelare lo stato del signer. Il login ora blocca quando le liste relay richieste (kind 10002/10050/10051) sono mancanti (PR #515), e le sottoscrizioni giftwrap ricadono sui relay NIP-65 quando le liste inbox sono assenti (PR #518). Una modalità debug (PR #528) espone le query al database e l’ispezione del ratchet-tree MLS come output JSON. Altre correzioni hanno risolto il recupero delle sottoscrizioni dopo la ri-registrazione del signer, la sincronizzazione dei messaggi di benvenuto, la validazione dei filtri relay e i limiti del raggio di ricerca utenti.

Marmot ha visto un’espansione significativa oltre lo stack Rust core questa settimana. White Noise TUI, un’interfaccia basata su terminale per lo stack di messaggistica White Noise, è stata lanciata il 3 marzo. Avvolge la CLI wn come sottoprocesso e renderizza il suo output JSON attraverso un’architettura unidirezionale ispirata a Elm, fornendo navigazione multi-conversazione con indicatori di non letto, creazione di gruppi e ricerca membri, streaming di messaggi in tempo reale e reazioni emoji dal terminale.

DavidGershony ha pubblicato uno stack Marmot completo in C# che rispecchia l’architettura a livelli del toolchain Rust. dotnet-mls implementa le primitive crittografiche MLS RFC 9420 in C#. marmot-cs si basa su di esso per aggiungere il trasporto relay Nostr, funzionando come equivalente C# di MDK. OpenChat, un’app desktop cross-platform costruita con .NET 9 e Avalonia UI, unisce entrambi in un client di chat funzionante con DM NIP-44, cifratura di gruppo Marmot, firma remota NIP-46 (Nostr Connect) e indicatori di stato multi-relay.

MDK PWA Reference fornisce un template Progressive Web App per costruire applicazioni cifrate con Marmot, con supporto sperimentale alla partecipazione di agenti AI nelle chat di gruppo e pagamenti Bitcoin tramite infrastruttura wallet Arkade.

Wisp Passa dall’Alpha alla Beta

Wisp è un nuovo client Nostr Android che è passato dalla prima alpha il 24 febbraio alla v0.3.4-beta il 3 marzo, producendo 19 rilasci, 115 PR unite e 276 commit in otto giorni.

La traiettoria delle funzionalità copre terreno che la maggior parte dei client impiega mesi a raggiungere. La v0.1.0 è stata distribuita con il supporto al modello relay outbox/inbox e flussi di onboarding. Alla v0.1.3, il client disponeva della firma intent-based NIP-55 per Amber, un proxy Tor SOCKS5 integrato per la connettività ai relay .onion, e NIP-47 (Nostr Wallet Connect). La v0.2.0 è passata alla beta con il filtraggio delle liste mute e il supporto emoji personalizzate, mentre la v0.2.4 ha aggiunto gli overlay per gli avvisi di contenuto. La serie v0.3.x ha introdotto la proof-of-work NIP-13 per le note, il mining PoW in background con impostazioni persistenti, lo storage dei relay .onion e le notifiche thread silenziati.

La traduzione on-device tramite Google ML Kit funziona localmente senza accesso alla rete dopo il download iniziale del modello. Una visualizzazione interattiva del grafo sociale usa una simulazione fisica velocity Verlet a circa 30fps con navigazione pinch-to-zoom e ispezione dei profili.

Rilasci

Vector v0.3.1

Vector, l’app di messaggistica cifrata con Marmot, ha distribuito la v0.3.1 con miglioramenti alla gestione dei gruppi e lavoro sulle prestazioni. Gruppi multi-admin, inviti in blocco, invito tramite npub e avatar di gruppo espandono le funzionalità di collaborazione. Le notifiche in background Android ora supportano le azioni inline Reply e Mark Read.

La sincronizzazione deterministica basata su Negentropy recupera la cronologia completa delle conversazioni inclusi i messaggi persi durante i periodi offline. Voice-to-text ricostruito con accelerazione GPU su Android. La gestione degli allegati è stata revisionata con progresso di download, stati di retry, compressione zip-and-send delle directory e indicatori di progresso in tempo reale. Le prestazioni sono migliorate di oltre 15 volte su tempo di avvio, elaborazione immagini, riproduzione audio e reattività generale della UI. Le dimensioni dell’installazione dell’app sono diminuite di oltre un terzo, con il frontend ridotto di circa la metà. È stato aggiunto il supporto Android ARM a 32 bit.

Alby Hub v1.21.5

Alby Hub, il nodo Lightning auto-custodiale con supporto Nostr Wallet Connect (NIP-47), ha distribuito la v1.21.5. Un secondo relay è stato aggiunto alla configurazione NWC predefinita, migliorando l’affidabilità durante i riavvii dei relay. Una correzione per i dati zap non validi nella lista transazioni risolve un problema di visualizzazione con event NIP-57 (Lightning Zaps) malformati. Le nuove voci dell’app store includono Alby CLI e LNVPS.

nospeak v0.12.x

nospeak, il client di messaggistica Nostr basato su testo, ha distribuito tre rilasci nel periodo. La v0.12.0 ha aggiunto il blocco app con PIN a tastierino a 4 cifre e oltre 15 nuove traduzioni linguistiche inclusi bengalese, tailandese, vietnamita, hindi, arabo, ebraico, urdu, turco, giapponese, cinese, coreano, olandese, polacco, russo e persiano con supporto RTL. La v0.12.1 ha introdotto un tema Cypher con sfondi neri puri e accenti ciano, più la generazione di poster video Android. La v0.12.2 ha aggiunto l’esportazione chat e View Profile nei menù dei contatti.

Citrine v2.0.0-pre2

Citrine, il relay personale Android di greenart7c3, ha distribuito la v2.0.0-pre2 con miglioramenti delle prestazioni del relay attraverso nuovi indici del database e coroutine Kotlin ristrutturate. Ogni web app ospitata ora si avvia sulla propria porta. La ricerca full-text e una schermata event riprogettata con espansione degli event completano le modifiche.

NoorNote v0.5.x

NoorNote, un’applicazione per prendere appunti basata su Nostr, ha distribuito 8 rilasci dalla v0.5.0 alla v0.5.7. Il lancio della v0.5.0 su Android ha aggiunto il supporto al signer Amber NIP-55 e la pubblicazione di note NIP-71 (Video Events). Una pagina di benvenuto riprogettata nella v0.5.1 includeva anteprime della timeline pubblica e ha ridotto l’APK a 15 MB. Il Relay Browser nella v0.5.2 permette agli utenti di navigare le timeline pubbliche dei relay tramite URL condivisibili, insieme al download dei media e alle reazioni emoji personalizzate NIP-30. I rilasci successivi fino alla v0.5.7 hanno risolto race condition di sincronizzazione nel sistema collaborativo di condivisione note “tribes”.

NosCall v0.5.1

NosCall, l’app per chiamate vocali e video su Nostr, ha distribuito la v0.5.1 con supporto ai messaggi vocali, un’esperienza desktop ottimizzata con accesso ai gruppi, contatti preferiti su desktop, note e filtraggio dei contatti, opzioni di esportazione e pulizia dei dati, e supporto all’accessibilità per le dimensioni dei font di sistema.

Shosho v0.13.0

Shosho, l’app di live streaming su Nostr, ha distribuito la v0.13.0 con download di replay MP4 dai menù delle card dello streaming e NIP-05 (DNS-Based Verification) per i profili. Il publisher RTMP è migrato all’Expo Modules API. Le prestazioni di streaming su connessioni a bassa larghezza di banda sono migliorate, e i crash sui dispositivi più vecchi e lo streaming iOS verso Zap.Stream sono corretti.

nostr-java v2.0.0

nostr-java ha distribuito la v2.0.0 con dimensioni configurabili del buffer WebSocket, permettendo alle applicazioni di gestire event Nostr più grandi senza troncamento. L’incremento della versione major riflette modifiche incompatibili all’API di connessione.

Prism 1.1.0

Prism ha distribuito la 1.1.0 con supporto ai contenuti long-form (articoli kind 30023) e un editor Markdown per la composizione direttamente nell’app, seguita da un rilascio bug fix 1.1.1.

Angor v0.2.6

Angor, la piattaforma di crowdfunding Bitcoin, ha distribuito la v0.2.6 con integrazione Boltz e un flusso di investimento in 1 click. Sia i tipi invest che fund project funzionano end-to-end su testnet. Il team nota che la UI è completa circa al 70%.

Aggiornamenti NIP

Modifiche recenti al repository NIPs:

Uniti:

NIP-91: Operatore AND per i Filtri: Aggiunge la semantica dei filtri AND per gli array di tag nelle sottoscrizioni ai relay. Attualmente, specificare valori multipli in un filtro di tag (ad esempio, tag p multipli) corrisponde agli event che contengono uno qualsiasi di essi. NIP-91 permette ai client di richiedere event che corrispondono a tutti i valori di tag specificati simultaneamente, riducendo la larghezza di banda e abilitando operazioni di indice più veloci. Esistono già implementazioni in più relay inclusi nostr-rs-relay, satellite-node, worker-relay e applesauce. Precedentemente numerato NIP-119.
NIP-30: Indirizzo del Set di Emoji nei Tag: I tag emoji personalizzate in NIP-30 possono ora includere un indirizzo opzionale del set di emoji. Cliccando su un’emoji in un client si può aprire il set a cui appartiene per aggiungerlo ai segnalibri o navigarlo. Originato dal client Chachi.
NIP-29: Aggiunta di unallowpubkey e unbanpubkey: Due nuovi comandi admin per le chat di gruppo NIP-29. unallowpubkey rimuove una pubkey dalla lista consentiti senza bannare l’utente. unbanpubkey revoca un ban senza ri-aggiungere la pubkey alla lista dei membri. In precedenza, l’unico modo per rimuovere qualcuno dalla lista consentiti comportava anche il ban, e revocare il ban richiedeva di ri-aggiungere l’utente come membro.

PR Aperte e Discussioni:

NIP-A7: Spells (aperta il 27 feb): Proposti da purrgrammer, gli spell sono query Nostr salvate e portabili pubblicati come event di kind 777. Uno spell codifica un filtro REQ o COUNT in tag strutturati (k per i kind, authors per le pubkey, tag per filtri di tag arbitrari) con variabili runtime: $me si risolve alla pubkey dell’utente loggato, $contacts si espande alla lista di follow di kind 3 dell’utente. I timestamp relativi (7d, 2w, 1mo) permettono agli spell di definire finestre temporali mobili senza date hardcoded. Già implementati in nak e Grimoire, gli spell permettono agli utenti di creare, condividere e sottoscrivere feed curati che si spostano tra i client.
NIP-59: Gift Wrap Effimero (kind 21059) (aperta il 27 feb): Aggiunge una variante effimera dei gift wrap NIP-59. Il kind 21059 segue la semantica effimera di NIP-01, quindi i relay scartano gli event dopo la consegna. Proposto da ContextVM per il trasporto MCP dove la persistenza dei messaggi non è necessaria.
ContextVM: MCP JSON-RPC su Nostr (aperta il 27 feb): Specifica come trasportare i messaggi del Model Context Protocol su Nostr usando event effimeri di kind 25910 con tag p ed e per l’indirizzamento e la correlazione. Intenzionalmente snello, rimanda i dettagli del protocollo alla specifica ContextVM.
NIP-29: Spazi Live Audio/Video (aperta il 25 feb, bozza): Bozza di fiatjaf che estende i gruppi NIP-29 con audio e video live. La proposta aggiunge tag opzionali livekit e no-text agli event di metadata dei gruppi. Quando un utente vuole unirsi a uno spazio vocale, il client richiede un JWT dal relay su /.well-known/nip29/livekit/{groupId}. Il relay verifica l’appartenenza al gruppo ed emette un token con la pubkey hex dell’utente come claim sub, che viene passato a LiveKit per il trasporto dei media. L’accesso alla stanza vocale eredita il modello di permessi esistente del gruppo, quindi le regole di appartenenza lato relay governano chi può parlare. In fase di test in Pyramid e Chachi.
Proprietà Collaborativa degli Event (aperta il 24 feb): pablof7z propone un event puntatore (kind 39382) che dichiara uno spazio collaborativo elencando le pubkey dei co-proprietari nei tag p e un kind di event target in un tag k. Qualsiasi proprietario elencato può pubblicare event di quel kind con lo stesso tag d, e i client risolvono lo stato corrente interrogando tutti i proprietari e prendendo l’event più recente. L’attribuzione di co-autorialità viene visualizzata solo quando un tag a verificabile referenzia il puntatore e l’autore appare nei suoi tag p, prevenendo rivendicazioni falsificate. Questo abilita pagine wiki condivise e risorse co-autoriate senza assegnare il controllo a un singolo keypair.
NIP-09: Cancellazione a Cascata dei Repost (aperta il 24 feb): Quando un autore originale cancella una nota, i relay dovrebbero anche cancellare qualsiasi repost di kind 6 o kind 16 che la referenzia. Motivato da preoccupazioni sulla privacy: i repost possono preservare informazioni trapelate accidentalmente dopo che l’autore ha cancellato la fonte. La modifica è solo lato relay e non richiede modifiche ai client.
NIP-07: peekPublicKey (aperta il 23 feb): Aggiunge un metodo peekPublicKey() alle estensioni browser NIP-07. A differenza di getPublicKey(), restituisce la pubkey corrente senza richiedere conferma all’utente, abilitando il login automatico silenzioso quando l’utente ha abilitato l’auto-login.
NIP-BB: Book (aperta il 28 feb, bozza): Definisce quattro kind di event indirizzabili (30300-30303) per la pubblicazione strutturata di libri su Nostr. Un event Cover contiene i metadata root inclusi titolo, immagine di copertina, licenza tramite label NIP-32 (Labeling) e codice lingua. Un event Index mappa ogni capitolo alla sua posizione usando indicizzazione frazionaria base62, che permette agli autori di inserire nuovi capitoli tra quelli esistenti senza rinumerazione. Gli event Chapter funzionano come intestazioni strutturali con immagini opzionali, mentre gli event Episode trasportano la prosa effettiva con un limite di 30.000 caratteri e tag immagine posizionati. Le recensioni usano gli Zap sugli event Cover con la descrizione dello Zap come testo della recensione.
NIP-54: Passaggio da Asciidoc a Djot (aperta il 26 feb): In seguito alla correzione dell’internazionalizzazione del d-tag di dicembre, questa PR propone di sostituire il formato markup Asciidoc del wiki NIP-54 con Djot, aggiungendo una sezione di motivazioni ed esempi di wikilink per script non latini.
NIP-66: Misure Difensive (aperta il 26 feb): Basato sugli apprendimenti dai benchmark nostrability/outbox, aggiunge segnalazioni esplicite per i casi limite di NIP-66. Una PR #2241 companion definisce tag di output per SSL, geolocalizzazione, rete e controlli di connettività.
NIP-C1: Prove di Identità Crittografica (voce wiki, kind 30817): Propone event di kind 30509 che collegano crittograficamente i certificati di firma APK ai profili Nostr. La prova funziona firmando un messaggio canonico contenente la pubkey Nostr con la chiave privata del certificato (supportando ECDSA, RSA PKCS1v15, Ed25519 e altri algoritmi standard), poi pubblicando la firma in un event di kind 30509 firmato con la chiave Nostr. I verificatori possono confermare che la persona che controlla il certificato di firma di un’app Android controlla anche la pubkey Nostr che dichiara di pubblicarla. Le prove scadono dopo un anno per impostazione predefinita e possono essere revocate esplicitamente. Implementato nel toolchain Zapstore.
NIP-31402: SARA Revenue Share Offering Registry (voce wiki, kind 30817): Definisce event indirizzabili di kind 31402 per la pubblicazione di offerte Simple Autonomous Revenue Agreement (SARA) sui relay Nostr. Gli emittenti pubblicizzano termini di condivisione dei ricavi regolati via Lightning inclusi percentuale della quota pool, trigger di pagamento, soglia in sats, durata del termine e prezzi a livelli. Agenti e umani possono scoprire le offerte sui relay e sottoscriverle autonomamente senza una piattaforma centrale. Il numero di kind rispecchia il kind 30402 (L402 Service Registry, pubblicato dallo stesso autore come voce wiki companion) poiché SARA rappresenta la gamba di ritorno della relazione di pagamento L402.

PR Aperte e Aggiornamenti dei Progetti

Damus: NIP-89 (Recommended Application Handlers)

La PR #3337 implementa il supporto ai tag client NIP-89 per Damus. L’app ora emette un tag client su tutti i percorsi di pubblicazione (app principale, estensione di condivisione, evidenziatore, bozze) e visualizza “via ClientName” accanto ai timestamp quando altre app includono i loro tag. Un toggle Privacy nelle impostazioni Aspetto permette agli utenti di disabilitare l’emissione del tag. La PR #3652 aggiunge una sezione Storage nelle Impostazioni con un grafico a torta interattivo che mostra l’utilizzo del disco per NostrDB e la cache Kingfisher con supporto all’esportazione.

Aperta: la PR #3657 aggiunge il fallback NIP-65 per le note citate. Quando un nevent inline include una pubkey autore ma nessun suggerimento relay e la nota è assente dal pool dell’utente, Damus recupera la lista relay kind 10002 dell’autore e riprova dai suoi relay di scrittura.

Amethyst: NIP-39 (External Identities), NIP-C0, NIP-66

Amethyst ha unito un’ondata di implementazioni NIP su 28 PR. Le rivendicazioni di identità esterna ora pubblicano come event dedicati di kind 10011 sotto NIP-39 (PR #1747), separando l’identità sociale dai metadata di kind 0 con fallback retrocompatibile. Il supporto agli snippet di codice tramite NIP-C0 (PR #1744) aggiunge event di kind 1337 con accessor per linguaggio, estensione, runtime, licenza e dipendenze. L’implementazione del relay monitoring NIP-66 (PR #1742) copre entrambi i tipi di event con parsing completo dei tag per metriche RTT, tipo di rete, NIP supportati e geohash.

I DM cifrati sono arrivati su Amethyst Desktop (PR #1710) con un layout chat a pannelli divisi che supporta sia NIP-04 (Encrypted Direct Messages) che NIP-17 (Private Direct Messages). Una nuova schermata feed relay (PR #1733) permette agli utenti di navigare i post da un relay specifico con funzionalità follow/unfollow. Aperta: la verifica NIP-05 resistente alla censura (PR #1734) aggiunge un percorso di verifica parallelo per gli identificatori .bit che risolve contro la blockchain Namecoin invece dell’HTTP DNS. Quando Amethyst rileva un suffisso .bit in un campo NIP-05, interroga un server ElectrumX-NMC per la cronologia delle transazioni del nome, analizza lo script NAME_UPDATE dall’output più recente per estrarre la pubkey Nostr, e rifiuta i nomi più vecchi di 36.000 blocchi (la finestra di scadenza di Namecoin). Le connessioni ElectrumX si instradano attraverso SOCKS5 quando Tor è abilitato, con selezione dinamica del server tra endpoint clearnet e .onion. Una cache LRU con TTL di un’ora previene query ripetute alla blockchain.

Notedeck: Architettura Outbox

La PR #1303 migra Notedeck dalla gestione ad hoc del relay pool a un modello outbox centralizzato con sottoscrizioni a livello di account. Il modulo Messages ora pubblica una lista relay DM predefinita se non ne esiste una e instrada i DM ai relay preferiti dei destinatari secondo il kind 10050.

Pika: Profili Per-Gruppo e Feed Tutorial

Pika, l’app di messaggistica cifrata con Marmot disponibile su iOS e Android con una build desktop, ha ottenuto i profili per-gruppo (PR #368). Gli utenti possono ora impostare un nome visualizzato e un’immagine separati per ogni chat di gruppo, insieme a una bio personalizzata. Questi profili pubblicano come event di kind 0 cifrati all’interno del gruppo Marmot, invisibili a chiunque sia esterno, con fallback al profilo Nostr globale dell’utente quando non è impostato un profilo specifico per il gruppo. Quando nuovi membri si uniscono, l’admin ritrasmette tutti i profili di gruppo memorizzati e ogni membro ripubblica il proprio al commit. Le immagini dei profili vengono cifrate con Marmot-media prima dell’upload su Blossom. La PR include 16 nuovi test unitari e espone la funzionalità sia tramite un comando CLI (update-group-profile) che tramite la UI.

Una nuova web app pika-news (PR #401) monitora le PR GitHub di Pika e genera automaticamente walkthrough tutorial passo-passo dalle diff delle PR, pubblicandoli come pagine server-rendered con autenticazione NIP-07. Gli utenti possono discutere tutorial specifici in tempo reale tramite chat autenticata Nostr.

diVine, la piattaforma di condivisione video nativa su Nostr, ha unito 132 PR in dieci giorni. I widget iframe incorporabili (PR #1843) forniscono una pagina /embed?npub=... autonoma che renderizza il profilo di un utente e i suoi video più recenti. La funzionalità risposte video (PR #1915), protetta da un feature flag, usa commenti Kind 1111 (NIP-22) con metadata imeta NIP-92 (Media Attachments). I filtri di contenuto a tre vie ispirati a Bluesky (PR #1797) offrono controlli Show/Warn/Hide su 17 categorie di avvisi di contenuto NIP-32.

strfry: Validazione Filtri REQ

La PR #163 aggiunge la validazione configurabile dei filtri REQ a strfry, il relay Nostr in C++. Gli operatori possono impostare il numero massimo di filtri per REQ, la presenza obbligatoria di autore o tag, whitelist di kind consentiti e limiti di kind per filtro. La funzionalità è rivolta ai deployment di relay NWC che necessitano di un’applicazione rigorosa dei filtri. Aperta: la PR #173 aggiunge la compressione zstd opzionale per i payload degli event al momento dell’ingestione.

rust-nostr: NIP-62 Request to Vanish

rust-nostr, la libreria Rust per il protocollo Nostr, ha aggiunto il supporto a NIP-62 (Request to Vanish) su tutti e tre i backend di database: LMDB, SQLite e in-memory. L’implementazione LMDB include opzioni configurabili per abilitare o disabilitare l’applicazione di NIP-09 e NIP-62 per deployment.

NDK: Event Collaborativi e Timeout NIP-46

NDK, il Nostr Development Kit per JavaScript/TypeScript, ha unito la PR #380 che introduce NDKCollaborativeEvent per documenti collaborativi multi-autore usando un event puntatore indirizzabile (kind 39382) che definisce gli autori autorizzati. Un timeout configurabile per NDKNip46Signer (PR #381) impedisce alle operazioni di firma remota NIP-46 di bloccarsi indefinitamente quando un bunker non risponde.

TENEX: Categorizzazione degli Agenti e Gating tramite Pubkey

TENEX, la piattaforma di orchestrazione agenti AI nativa su Nostr, ha unito due PR relative alla sicurezza. La categorizzazione degli agenti basata su ruoli TIP-01 (PR #91) mappa le categorie degli agenti (principal, orchestrator, worker, advisor, auditor) a restrizioni automatizzate sugli strumenti tramite una mappa denied-tools. Il gating front-door tramite pubkey (PR #87) assicura che solo gli event da pubkey whitelisted o firmate dal backend siano instradati insieme agli agenti conosciuti; le pubkey sconosciute vengono scartate silenziosamente con span OpenTelemetry per l’audit.

Zap Cooking: Dashboard Abbonamenti

Zap Cooking, la piattaforma di condivisione ricette basata su Nostr, ha unito 25 PR e 85 commit in dieci giorni. Una dashboard abbonamenti (PR #228) mostra lo stato della sottoscrizione con date di scadenza e opzioni di gestione/upgrade, riabilita i gate delle funzionalità per i livelli Sous Chef e Zappy con controlli sia lato client che lato server, e standardizza la nomenclatura dei livelli su 26 file. Il caricamento dei messaggi di gruppo in due fasi (PR #227) fornisce un fetch iniziale rapido di 3 giorni per la visualizzazione istantanea seguito da un backfill in background di 40 giorni.

Lo storage del mnemonic del wallet è passato dalla cifratura derivata dalla pubkey alla cifratura encrypt-to-self NIP-44 (PR #224), correggendo una vulnerabilità in cui il vecchio schema derivava la chiave da SHA-256(pubkey), che è effettivamente non cifrato poiché le pubkey sono pubbliche. I wallet esistenti vengono migrati silenziosamente al primo caricamento. La chat di gruppo NIP-29 ha ottenuto indicatori di non letto con badge a pallino rosso e accesso solo su invito con codici invito di kind 9009 (PR #213). Le anteprime link e gli embed di event Nostr ora si renderizzano nei DM e nei messaggi di gruppo (PR #218). Una sezione backup Nostr nelle Impostazioni (PR #210) memorizza follow e liste mute tramite storage cifrato NIP-78 (Application-specific Data) con versioning rotativo a 3 slot. Le prestazioni di avvio sono migliorate attraverso il rinvio dei servizi di notifica, il rendering DOM lazy tramite IntersectionObserver (riducendo i nodi DOM da circa 15.000 a circa 3.000 su un feed di 200 event) e TTL estesi della cache outbox (PR #208). Una modale di stampa ricetta personalizzabile (PR #205) permette agli utenti di selezionare quali sezioni includere con un’anteprima live. L’integrazione Branta SDK (PR #222) aggiunge garanzie di verifica per le richieste POST e GET.

Keep: Migrazione dello Stato Guidata da Rust

Keep, il gestore di chiavi private basato su Nostr per Android, ha unito la PR #178, eliminando quattro store di configurazione Kotlin a favore dello stato condiviso guidato da Rust dal livello keep-mobile. Un loop di polling a 10 secondi è stato sostituito con KeepStateCallback push-based da Rust. La PR #179 aggiunge backup e ripristino cifrati con protezione tramite passphrase.

Mostro Mobile: Cifratura Chat Dispute

Mostro Mobile, il client mobile per la piattaforma di trading Bitcoin P2P Mostro, ha distribuito una migrazione in due fasi della cifratura chat dispute. Il primo passo (PR #495) passa dal wrapping specifico di mostro alla cifratura con chiave condivisa derivata dalla pubkey dell’admin. Basandosi su questo, la PR #501 unifica il modello di messaggi con NostrEvent e memorizza gli event gift wrap cifrati su disco, coerente con il pattern di chat peer-to-peer. Una correzione della firma BIP-340 (PR #496) sovrascrive la dipendenza bip340 alla 0.2.0, risolvendo un bug di padding bigToBytes() che causava l’invalidità dell'1-2% delle firme Schnorr e il 100% di fallimenti per le chiavi la cui chiave pubblica inizia con 0x00. Order Details ora mostra etichette di stato leggibili invece di valori grezzi del protocollo, localizzate in inglese, spagnolo, italiano e francese (PR #502). HalCash è stato aggiunto e SEPA rimosso come metodo di pagamento (PR #493), poiché i trasferimenti SEPA possono superare le 24 ore (SEPA Instant rimane).

Lato server, Mostro ha corretto il ripristino della sessione dispute per includere il campo initiator (PR #599) e ora chiude automaticamente le dispute attive quando un venditore rilascia i fondi, pubblicando un event Nostr di risoluzione in modo che i client admin vedano la risoluzione (PR #606).

Cinque Anni di Febbraio di Nostr

La newsletter del mese scorso ha tracciato le pietre miliari di gennaio di Nostr dai primi sviluppi fino all’esplosione di Damus, arrivando all’infrastruttura di sicurezza nel 2026. Questa retrospettiva copre cosa è successo ogni febbraio dal 2021 al 2026.

Febbraio 2021: La Riscrittura

Tre mesi dopo la sua nascita, il febbraio di Nostr ha prodotto il cambiamento più significativo delle origini del protocollo. Il 14-15 febbraio, fiatjaf ha riscritto NIP-01, sostituendo il formato messaggi originale con il modello EVENT/REQ/CLOSE che il protocollo usa ancora oggi. Prima di questa riscrittura, client e relay comunicavano attraverso una struttura più semplice. Separare la pubblicazione degli event (EVENT) dalla gestione delle sottoscrizioni (REQ/CLOSE) ha abilitato il filtraggio lato relay che si sarebbe rivelato essenziale per la scalabilità.

NIP-04 è arrivato lo stesso mese, aggiungendo messaggi diretti cifrati usando segreti condivisi derivati dallo scambio di chiavi Diffie-Hellman su secp256k1. La sua cifratura era basilare (AES-256-CBC) e sarebbe stata successivamente sostituita dalla crittografia verificata di NIP-44, ma ha dato alla manciata di utenti iniziali il loro primo canale di comunicazione privata sul protocollo.

Il tooling si è espanso con noscl, un client a riga di comando in Go per l’interazione con i relay da terminale, e futurepaul ha iniziato nostr-rs, una prima implementazione Rust. L’intera rete funzionava su due o tre relay, coordinata attraverso un gruppo Telegram, con circa sette contributor attivi.

Febbraio 2022: Costruire lo Slancio

Il post su Hacker News del 31 dicembre 2021 ha continuato ad attirare sviluppatori fino a febbraio. Il repository nostr-protocol/nostr (il repository NIPs formale non sarebbe esistito fino a maggio 2022) ha ricevuto sei pull request a febbraio, inclusi NIP-13 (Proof of Work) di vinliao, NIP-14 (Reputation) di fiatjaf, NIP-15 (Resource Relations) di Cameri e NIP-17 (Git Updates Over Nostr) di melvincarvalho. Il numero NIP è stato successivamente riassegnato a Private Direct Messages; la collaborazione git su Nostr è continuata separatamente attraverso quello che è diventato gitworkshop.dev.

Il nostr-rs-relay di Greg Heartsfield è stato il cavallo di battaglia del mese con 34 commit e tre rilasci. La versione 0.5.0 del 12 febbraio ha aggiunto limiti di pubblicazione per utenti verificati NIP-05. Le versioni 0.5.1 e 0.5.2 sono seguite nelle due settimane successive, e il relay gestiva la maggior parte del traffico della rete da solo.

Robert C. Martin (Uncle Bob) stava costruendo more-speech, un client desktop in Clojure, registrando 69 commit tra il 18 gennaio e la fine di febbraio. Il suo coinvolgimento ha portato attenzione dalla più ampia comunità di ingegneria del software. L’estensione browser nos2x di fiatjaf ha distribuito il supporto alla decifratura NIP-04 e le politiche di preferenza dei relay a febbraio, implementando l’interfaccia window.nostr (NIP-07) che i client web usano ancora per la delega delle chiavi.

Branle, ancora il client web principale, ha ottenuto la registrazione del gestore di protocollo web+nostr il 13 febbraio, un primo tentativo di deep linking tra applicazioni Nostr. nostr-tools ha rafforzato la validazione NIP-05. go-nostr ha aggiunto il supporto ai DM cifrati NIP-04 e il parsing NIP-12 (Generic Tag Queries) su 11 commit. La rete operava su circa 7-15 relay con una base utenti attiva probabilmente nell’ordine delle centinaia. Damus e Nostream non esistevano ancora e non sarebbero apparsi fino ad aprile 2022.

Febbraio 2023: Attenzione Internazionale

Febbraio 2023 ha portato a Nostr la sua più grande ondata di attenzione pubblica. Damus, il client iOS di William Casarin, era stato approvato sull’App Store di Apple il 31 gennaio dopo ripetuti rifiuti. Entro il 1° febbraio aveva raggiunto la top 10 nella categoria Social Networking negli USA. Due giorni dopo, il 2 febbraio, Apple ha rimosso Damus dall’App Store cinese apparentemente su richiesta dell’Amministrazione del Cyberspazio della Cina.

I principali media inclusi TechCrunch e CoinDesk hanno coperto la rimozione, amplificando la consapevolezza sia dell’app che del protocollo. Le chiavi pubbliche uniche con metadata su nostr.directory hanno superato le 300.000 entro il 3 febbraio. Tutti i relay erano gestiti da appassionati che pagavano di tasca propria, e l’infrastruttura si è affannata per gestire il carico. Circa 289 relay erano tracciati a inizio febbraio, un numero che ha continuato a crescere.

Il repository NIPs ha registrato 29 pull request unite quel mese, il conteggio mensile più alto nella storia del protocollo fino a quel momento. NIP-57 (Lightning Zaps) e NIP-23 (Long-form Content) sono stati entrambi uniti il 13 febbraio, aggiungendo micropagamenti Bitcoin e espandendo Nostr oltre i post brevi in un solo giorno. NIP-65 (Relay List Metadata) era stato unito una settimana prima, il 7 febbraio, abilitando il modello outbox che è seguito. NIP-46 (Nostr Connect) e NIP-58 (Badges) sono stati anch’essi rilasciati prima della fine del mese.

La Human Rights Foundation ha assegnato 50.000$ a William Casarin per lo sviluppo di Nostr e Damus il 21 febbraio, una delle prime grant istituzionali a un progetto Nostr. OpenSats non aveva ancora lanciato il suo fondo Nostr (cosa che sarebbe avvenuta a luglio 2023).

Febbraio 2024: Durabilità del Protocollo

Febbraio 2024 ha spostato il focus dalla crescita alla durabilità del protocollo. NIP-17 (Private Direct Messages), aperto dal luglio precedente, stava lavorando verso una sostituzione per l’invecchiata cifratura NIP-04 usando la crittografia verificata di NIP-44 e il gift wrapping di NIP-59. NIP-04 faceva trapelare metadata agli operatori dei relay, che potevano vedere le coppie mittente-destinatario. NIP-17 nasconde l’identità del mittente dietro keypair usa e getta ed è stato unito quella primavera dopo un ultimo giro di revisione a marzo.

NIP-29 (Simple Groups) è stato unito il 28 febbraio dopo mesi di discussione, definendo come i relay possono ospitare chat di gruppo moderate con ruoli admin e controllo degli accessi. NIP-92 (tag imeta) è stato unito il 1° febbraio, standardizzando come i client allegano dimensioni delle immagini e anteprime blurhash agli event media.

Il 16 febbraio, il repository NIPs ha aggiunto BREAKING.md, un file che traccia le modifiche incompatibili alla specifica del protocollo. La sua creazione ha riconosciuto che Nostr aveva raggiunto un livello di maturità in cui le modifiche incompatibili necessitavano di documentazione formale.

Ventidue pull request sono state unite quel mese. npub.cash è stato lanciato come servizio di indirizzo Lightning che permette a qualsiasi npub di ricevere pagamenti senza gestire un server. Un articolo accademico pubblicato l'8 febbraio ha rilevato che il 95% dei relay gratuiti non poteva coprire i costi operativi attraverso le donazioni, con il 35% dei relay a pagamento che addebitava tariffe di ammissione inferiori a 1.000 sats (circa 0,45$ all’epoca).

Febbraio 2025: Crescita dell’Infrastruttura

Febbraio 2025 ha prodotto 28 pull request unite nel repository NIPs. Un NIP Right to Vanish è stato unito il 19 febbraio, definendo come gli utenti possono richiedere la cancellazione dei propri dati dai relay in risposta a questioni normative sulla portabilità dei dati e il controllo dell’utente.

NIP-60 (Cashu Wallet) e NIP-61 (Nutzaps) hanno ricevuto aggiornamenti di semplificazione, razionalizzando il formato di storage dei token ecash. Un rollout del q-tag (quote tag) è continuato su più NIP, standardizzando come gli event referenziano altri event per citazioni e threading.

I rilasci dei client hanno segnato progressi costanti. Notedeck v0.3.0 alpha è stato distribuito l’ultimo giorno di gennaio, con l’adozione che è continuata in febbraio. Primal v2.1 è seguito il 7 febbraio, e GRAIN v0.3.0, un’implementazione relay in Go, è stato rilasciato il 21 febbraio.

NOSTRLDN v5 ha riunito la comunità Nostr londinese per il suo quinto incontro. Un bridge DVMCP ha collegato le Data Vending Machine di Nostr (NIP-90) con il Model Context Protocol, prefigurando il lavoro di integrazione degli agenti AI arrivato il mese successivo.

L’attività di febbraio 2026 è tratta dai numeri di Nostr Compass #8 fino al #11.

Febbraio 2026 ha prodotto la gamma più ampia di sviluppo a livello applicativo in un singolo mese di Nostr. Mostro ha distribuito la sua prima beta pubblica per il trading decentralizzato di Bitcoin peer-to-peer, e Zapstore ha raggiunto la 1.0 stabile dopo mesi di test in release candidate. White Noise v0.3.0 ha portato la messaggistica in tempo reale cifrata con Marmot con supporto al signer Amber e oltre 160 miglioramenti uniti.

Proposte concorrenti per agenti AI da pablof7z (NIP-AE per flussi di lavoro degli agenti, NIP-AD per annunci di server MCP) e joelklabo (AI Agent Messages) sono arrivate insieme a una proposta di Coordinamento Agenti DVM che estende NIP-90. ContextVM ha distribuito miglioramenti all’SDK per collegare il Model Context Protocol al trasporto Nostr. Burrow ha aggiunto la messaggistica cifrata con Marmot sia per agenti AI che per umani, estendendo l’identità e l’infrastruttura relay di Nostr alla comunicazione machine-to-machine.

FIPS ha distribuito un’implementazione Rust funzionante di reti mesh native su Nostr, usando keypair secp256k1 come identità dei nodi con routing agnostico dal trasporto su UDP, Ethernet, Bluetooth o radio LoRa. Il suo design ha mostrato che il modello di chiavi di Nostr si estende oltre i social media fino all’infrastruttura di rete fisica.

OpenSats ha annunciato la quindicesima ondata di grant Nostr, finanziando progetti inclusi ContextVM e Nostube. Le modifiche al protocollo hanno incluso il supporto hold invoice NIP-47 per Nostr Wallet Connect e NIP-45 (Counting Results) HyperLogLog per la stima dei conteggi lato relay. Anche la scopribilità dei service provider NIP-85 (Trusted Assertions) per il punteggio Web of Trust è stata unita. rust-nostr ha iniziato un redesign completo delle API mentre Nostria 3.0 e Frostr (iOS TestFlight) sono stati entrambi distribuiti. Il livello di cache locale di Blossom ha affrontato la disponibilità dei media sui relay.

Guardando Avanti

Cinque febbraio di storia del protocollo mostrano una progressione costante dal lavoro fondamentale alla diversificazione a livello applicativo, con l’afflusso di utenti del 2023 come punto di svolta. Nel 2021, sette contributor lavoravano su tre relay. Entro il 2026, lo stesso protocollo supportava reti mesh e proposte per agenti autonomi in esecuzione su infrastruttura di produzione.

È tutto per questa settimana. Stai costruendo qualcosa o hai notizie da condividere? Contattaci via DM NIP-17 o trovaci su Nostr.

Nostr Compass #11

Wed, 25 Feb 2026 00:00:00 +0000

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

Questa settimana: White Noise v0.3.0 porta la messaggistica in tempo reale e il supporto al signer Amber con oltre 160 miglioramenti uniti. diVine 1.0.5 corregge problemi di riproduzione video e aggiunge eventi di visualizzazione Kind 22236 per l’analisi dei creator. Pika, Ridestr e Unfiltered pubblicano aggiornamenti. FIPS distribuisce un’implementazione Rust funzionante di reti mesh native su Nostr. Notecrumbs riceve correzioni di stabilità per le anteprime link di damus.io. ContextVM collega Nostr con il Model Context Protocol. I nuovi progetti includono Burrow per la messaggistica cifrata con MLS tra agenti AI e umani, e Nostria Signer per la gestione di vault e identità basata su browser. Gli approfondimenti coprono la firma Android NIP-55 e la sincronizzazione del wallet Cashu NIP-60.

Notizie

Miglioramenti di Stabilità di Notecrumbs

Notecrumbs, il server API e web che alimenta le anteprime link di damus.io, ha ricevuto una serie di correzioni che risolvono problemi di affidabilità.

Una correzione della concorrenza ha sostituito il meccanismo di deduplicazione in-flight con watch channel. Due chiamanti che richiedevano la stessa nota potevano diventare entrambi fetcher, causando un deadlock quando uno completava prima che l’altro si iscrivesse alla notifica. I watch channel con operazioni atomiche garantiscono che un solo fetcher sia attivo mentre gli altri attendono il risultato.

Il rate limiting implementa una difesa a due livelli contro il bombardamento dei relay. Quando gli utenti accedono ripetutamente alla stessa nota, il sistema ora fa debounce delle richieste ai relay con una finestra di raffreddamento di 5 minuti. Questa protezione si estende a tutti i tipi NIP-19 e ai feed dei profili, prevenendo spam proporzionale ai relay durante il traffico intenso.

I miglioramenti delle prestazioni hanno spostato i fetch secondari dei dati a task tokio in background. Le pagine ora si renderizzano istantaneamente con dati in cache invece di bloccarsi su timeout sequenziali dei relay che potevano aggiungere fino a 7,5 secondi. Un aggiornamento a nostrdb 0.10.0 ha accompagnato queste correzioni.

ContextVM: MCP su Nostr

ContextVM è una suite di strumenti che collega Nostr e il Model Context Protocol (MCP). I commit recenti hanno introdotto la nuova specifica CEP-8 che abilita i pagamenti, con miglioramenti all’SDK distribuiti nel corso di febbraio.

L’SDK fornisce transport TypeScript client e server per MCP su Nostr. Gli sviluppatori possono esporre server MCP attraverso la rete Nostr e i client possono connettersi ad essi. I relay agiscono come un bus messaggi cieco, instradando semplicemente eventi cifrati in modo opaco. I client senza supporto nativo a Nostr si connettono attraverso un livello proxy. La libreria gestisce la gestione dei relay e la firma crittografica per l’autenticazione degli event. Funziona sia in ambienti Node.js che browser.

CVMI fornisce una CLI per la scoperta di server e l’invocazione di metodi. Relatr calcola punteggi di fiducia personalizzati dalla distanza nel grafo sociale combinata con la validazione del profilo.

ContextVM si posiziona come livello ponte: i server MCP esistenti acquisiscono interoperabilità con Nostr mantenendo i loro transport convenzionali.

White Noise Documenta la Ricerca Utenti Decentralizzata

Un post sul blog di jgmontoya spiega come White Noise gestisce la ricerca utenti attraverso la rete relay decentralizzata.

La distribuzione dei profili crea la sfida: a differenza dei messenger centralizzati con database unificati, i profili Nostr si disperdono su decine di relay senza indice centrale. White Noise risolve questo problema attraverso un’architettura produttore-consumatore che gira in parallelo.

Un processo produttore espande continuamente il grafo sociale verso l’esterno a partire dai seguiti dell’utente, recuperando liste di follow a distanze crescenti e accodando le pubkey scoperte per la risoluzione dei profili. Il consumatore risolve le corrispondenze attraverso cinque livelli di costo crescente: tabella utenti locale (più veloce), profili in cache dalle ricerche precedenti, relay connessi, liste relay utente per NIP-65 e query dirette ai relay dichiarati dall’utente (più lento).

Le ricerche a freddo richiedono circa 3 secondi mentre le ricerche a caldo dalla cache scendono a circa 10 millisecondi. Per i nuovi utenti senza grafi sociali consolidati, il sistema inietta nodi bootstrap ben connessi per garantire la funzionalità di ricerca. L’appartenenza ai gruppi fornisce un segnale sociale implicito accanto ai seguiti espliciti.

La strumentazione si è rivelata fondamentale per l’ottimizzazione, nota l’autore. Senza metriche, i miglioramenti erano solo intuizioni.

FIPS: Rete Mesh Nativa su Nostr

FIPS (Free Internetworking Peering System) è un’implementazione Rust funzionante di una rete mesh auto-organizzante che usa le keypair Nostr (secp256k1) come identità dei nodi. La documentazione di design accompagna il codice funzionale.

Il protocollo affronta l’indipendenza infrastrutturale: i nodi si scoprono automaticamente senza server centrali o autorità di certificazione. Un spanning tree fornisce routing basato su coordinate mentre i bloom filter propagano informazioni di raggiungibilità, permettendo ai nodi di prendere decisioni di inoltro con sola conoscenza locale. L’agnosticismo dal trasporto significa che lo stesso protocollo funziona su UDP, Ethernet, Bluetooth, radio LoRa o qualsiasi mezzo capace di datagrammi.

Due livelli di cifratura proteggono il traffico. La cifratura a livello link (pattern Noise IK) protegge la comunicazione hop-by-hop tra vicini con autenticazione reciproca e forward secrecy. La cifratura a livello sessione (pattern Noise XK) fornisce protezione end-to-end contro i router intermedi, dove solo la destinazione può decifrare il payload. Questo rispecchia come TLS protegge il traffico HTTP anche quando attraversa reti non fidate.

L’architettura usa uno spanning tree a “greedy embedding” per il routing. Ogni nodo riceve coordinate basate sulla sua posizione relativa alla radice dell’albero e al genitore. I pacchetti vengono instradati greedy verso coordinate più vicine alla destinazione, con bloom filter che pubblicizzano gli endpoint raggiungibili. Quando il routing greedy fallisce (minimi locali), i nodi possono ricorrere ai percorsi basati sull’albero.

L’implementazione Rust include già il trasporto UDP con scoperta tramite bloom filter. I lavori futuri mirano all’integrazione relay Nostr per il bootstrapping dei peer.

Rilasci

Questa settimana ha portato rilasci nell’infrastruttura relay e nelle applicazioni client, con nuovi progetti che entrano nello spazio.

HAVEN v1.2.0

HAVEN, il relay personale all-in-one che raggruppa quattro funzioni relay con un server media Blossom, ha distribuito la v1.2.0. Questo rilascio va oltre la fase RC coperta la settimana scorsa.

Il supporto multi-npub permette a una singola istanza HAVEN di servire diverse identità Nostr tramite whitelisting, con nuove funzionalità di blacklisting per il controllo degli accessi. Un sistema di backup riscritto usa il formato JSONL portabile, con un comando haven restore per importare note da file JSONL. L’integrazione con lo storage cloud aggiunge i flag --to-cloud e --from-cloud per la gestione dei backup remoti.

I miglioramenti al Web of Trust includono livelli di profondità configurabili per i calcoli di fiducia e intervalli di aggiornamento automatico di 24 ore con ottimizzazione lockless che riduce l’overhead di memoria. La configurazione dello user-agent per le richieste ai relay e le impostazioni di timeout Blastr configurabili completano il rilascio, insieme all’esportazione dati in JSONL compresso.

White Noise v0.3.0

White Noise, l’app di messaggistica cifrata basata su MLS che implementa il protocollo Marmot, ha distribuito la v0.3.0 con oltre 160 miglioramenti uniti.

Questo rilascio porta la messaggistica in tempo reale attraverso connessioni in streaming invece del polling, così i messaggi arrivano istantaneamente. Il supporto Amber (NIP-55) significa che le chiavi private non devono mai toccare l’app. La condivisione delle immagini ora funziona con tracciamento del progresso di upload e placeholder blurhash durante il caricamento. La visualizzazione a schermo intero supporta il pinch-to-zoom.

La messaggistica di gruppo ha ricevuto miglioramenti di affidabilità con le liste chat che mostrano i nomi dei mittenti e la cifratura MLS che garantisce la forward secrecy. La ricerca utenti si espande verso l’esterno dai seguiti fino a quattro gradi di separazione con risultati che arrivano in streaming man mano che vengono trovati.

Un breaking change azzera tutti i dati locali all’aggiornamento a causa di modifiche al protocollo Marmot e al passaggio allo storage locale cifrato. Gli utenti dovrebbero fare il backup delle chiavi nsec prima di aggiornare.

diVine 1.0.5

diVine, il client video a ciclo breve costruito sugli archivi restaurati di Vine, ha distribuito la 1.0.5 con ampie correzioni alla riproduzione video e un nuovo sistema di analisi decentralizzato.

I problemi di riproduzione video hanno dominato le correzioni: pausa fantasma, audio doppio tra video, flash nero tra miniature e primi frame, e crash del player smaltito sono tutti risolti. Un player video in pool gestisce ora il feed Home per una riproduzione coerente.

Gli event di visualizzazione effimeri Kind 22236 abilitano l’analisi dei creator e le raccomandazioni. Il sistema traccia le fonti di traffico (home, varianti di scoperta, profilo, condivisione, ricerca) e i conteggi dei loop filtrando le auto-visualizzazioni. Le perdite di percorso file locale nei tag imeta degli event Nostr sono corrette con URL Blossom canonici costruiti lato client secondo la specifica BUD-01.

I miglioramenti al signer remoto NIP-46 includono connessioni relay parallelizzate e supporto all’URL di callback. Android riconnette le connessioni WebSocket alla ripresa dell’app dopo l’approvazione del signer.

Coracle 0.6.30

Coracle, il client Nostr web focalizzato sulla gestione dei relay e la moderazione Web of Trust, ha distribuito la 0.6.30 con supporto alle miniature video, migliorando la navigazione dei media nei feed.

Nostur v1.26.0

Nostur, il client Nostr per iOS, ha distribuito la v1.26.0 con una nuova sezione feed Live Streams e una schermata Impostazioni riprogettata. I GIF possono ora essere ospitati su server media Blossom, riducendo la dipendenza da servizi centralizzati. L’integrazione Klipy GIFs fornisce un backup quando Tenor non è disponibile. Le intestazioni per anno nelle conversazioni DM e la visualizzazione del conteggio menzioni completano le modifiche lato utente.

Gli strumenti per sviluppatori e le app CLI hanno ricevuto aggiornamenti anche questa settimana.

nak v0.18.5

nak, il coltellino svizzero a riga di comando di fiatjaf per Nostr, ha distribuito la v0.18.5 con un nuovo sottocomando nak profile per recuperare e visualizzare profili utente. Il comando git clone ora supporta i nomi NIP-05 negli URI nostr://, abilitando il cloning di repository tramite identificatori leggibili.

Pika v0.5.3

Pika, il messenger cifrato con MLS per iOS, Android e desktop costruito sul protocollo Marmot, ha distribuito la v0.5.3. I commit recenti aggiungono il caricamento di file e il supporto al drag-and-drop media nell’app desktop, insieme a correzioni per il deployment su Cloudflare Workers.

Pika usa un core Rust che possiede tutta la logica di business mentre iOS (SwiftUI) e Android (Kotlin) agiscono come livelli UI snelli che renderizzano snapshot dello stato. MDK (Marmot Development Kit) fornisce l’implementazione MLS. Il progetto indica lo stato alpha e sconsiglia l’uso per carichi di lavoro sensibili.

Ridestr v0.2.6

Ridestr, la piattaforma di ridesharing decentralizzata con pagamenti Cashu, ha distribuito la v0.2.6. Questo rilascio corregge problemi di accessibilità TalkBack e risolve bug in cui i driver scomparivano dalla lista nelle vicinanze quando si cambiava metodo di pagamento, o in cui il conteggio dei driver selezionati non si aggiornava quando i driver andavano offline.

La funzione “Send to All” è ora “Broadcast RoadFlare” con correzioni per i silenziosi fallimenti su installazioni fresche dei driver. Ridestr implementa l’escrow HTLC per pagamenti trustless delle corse e la sincronizzazione wallet NIP-60 tra dispositivi.

Unfiltered v1.0.6

Unfiltered, l’app di condivisione foto simile a Instagram per Android, ha distribuito la v1.0.6 con ricerca utenti migliorata e riconnessione automatica ai relay ogni 60 secondi.

Costruita con Kotlin e Jetpack Compose, Unfiltered usa le binding rust-nostr e server compatibili con Blossom per l’hosting delle immagini. L’integrazione Amber (NIP-55) gestisce la gestione sicura delle chiavi. L’app mostra i post degli account seguiti in ordine cronologico senza algoritmi o pubblicità.

Due nuovi progetti di messaggistica e firma sono stati lanciati questa settimana.

Burrow: Messaggistica MLS per Agenti AI

Burrow è un messenger che implementa il protocollo Marmot per la comunicazione cifrata con MLS senza numeri di telefono o server centralizzati. Sia gli utenti umani che gli agenti AI possono partecipare.

Un daemon CLI in Rust puro con modalità di output JSONL gestisce l’integrazione con i sistemi automatizzati. Un’app Flutter cross-platform copre Android, iOS, Linux, macOS e Windows. Gli allegati media vengono cifrati insieme ai messaggi, e WebRTC gestisce le chiamate audio e video con server TURN configurabili.

Burrow stratifica la cifratura MLS sull’infrastruttura Nostr. L’identità usa le keypair Nostr (secp256k1) mentre i KeyPackage MLS vengono pubblicati come event di kind 443. I messaggi vengono cifrati con NIP-44 come event di kind 445, e gli inviti di benvenuto usano il gift-wrapping NIP-59.

L’integrazione con OpenClaw abilita la partecipazione degli agenti AI con accesso completo agli strumenti. Le liste di controllo degli accessi con log di audit gestiscono i permessi di contatto e gruppo. Questa combinazione posiziona Burrow per scenari di messaggistica agente-agente e agente-umano che richiedono cifratura di livello Signal su infrastruttura decentralizzata.

Estensione Nostria Signer

Nostria Signer è un’estensione browser basata su Chromium che fornisce gestione di vault e identità per gli utenti Nostr.

Vault multipli contenenti account multipli permettono agli utenti di organizzare le identità per contesti diversi. L’internazionalizzazione include il supporto alle lingue RTL. Costruita con Angular e TypeScript (79,2% del codebase), funziona sia come estensione browser che come Progressive Web App.

Nostria Signer implementa NIP-07 per la firma tramite estensione browser, permettendo ai client Nostr web di richiedere firme degli event senza accedere direttamente alle chiavi private. La migrazione automatica del wallet gestisce gli aggiornamenti distribuiti attraverso il Chrome Web Store. Gli utenti possono anche fare il sideload dalla cartella dist/extension.

Gli sviluppatori sottolineano lo stato sperimentale: gli utenti devono gestire le proprie frasi di recupero segrete poiché gli sviluppatori non possono ripristinare l’accesso alle chiavi perse.

Aggiornamenti dei Progetti

Formstr Migra alla Nuova Organizzazione

Formstr, l’alternativa a Google Forms su Nostr, ha migrato il suo repository da abh3po/nostr-forms all’organizzazione formstr-hq. Questo beneficiario di una grant OpenSats continua lo sviluppo nella nuova posizione.

PR Aperte di Rilievo

Lavori in corso nei progetti Nostr:

Damus Outbox Model (PR #3602): Piano di implementazione per il modello relay gossip/outbox su iOS. Questo cambiamento architetturale migliora la consegna dei messaggi pubblicando ai relay dove i destinatari leggono effettivamente.
Notedeck Cross-Platform Notifications (PR #1296): Sistema di notifiche nativo per il client desktop Damus che copre Android FCM, macOS e Linux.
NDK Cashu v3 Upgrade (PR #370): Aggiorna l’integrazione wallet del Nostr Development Kit a cashu-ts v3.
Zeus Cashu Offline (PR #3742): Invio e ricezione ecash offline per il wallet Lightning Zeus.
Shopstr Encrypted Digital Delivery (PR #231): Aggiunge la consegna cifrata per i beni digitali con supporto al peso dinamico per gli articoli fisici.

Aggiornamenti NIP

Modifiche recenti al repository NIPs:

Uniti questa settimana:

NIP-85 Scoperta dei Provider di Servizi: La specifica NIP-85 include ora indicazioni su come i client scoprono i provider di trusted assertion. Quando un client necessita di punteggi Web of Trust o altre metriche calcolate, può interrogare i relay per gli annunci kind 30085 da provider che l’utente già segue o di cui si fida.
NIP-29 Rimuove i Gruppi Non Gestiti: La specifica dei gruppi chat NIP-29 ha eliminato il supporto per i gruppi non gestiti (dove qualsiasi membro poteva aggiungere altri). Tutti i gruppi NIP-29 richiedono ora la gestione lato relay con ruoli admin espliciti, semplificando le implementazioni e riducendo i vettori di spam.
NIP-11 Rimuove i Campi Deprecati: I documenti di informazione relay NIP-11 non includono più i campi deprecati software e version. Le implementazioni dovrebbero rimuoverli dalle proprie risposte.
NIP-39 Sposta i Tag di Identità: Le rivendicazioni di identità esterna (tag i di NIP-39 per GitHub, Twitter, ecc.) si sono spostate dai profili kind 0 a event kind 30382 dedicati. Questo separa la verifica dell’identità dai metadata del profilo.

Avanzamento dei NIP per Agenti AI:

Quattro NIP focalizzati sull’AI continuano lo sviluppo attivo. Da quando li abbiamo coperti la settimana scorsa:

NIP-AE: Agents (aggiornato il 19 feb): Definisce l’identità degli agenti con kind 4199 per le definizioni degli agenti e kind 4201 per i prompt (“nudge”). Gli agenti possono referenziare i metadata dei file NIP-94 per descrizioni estese.
NIP-XX: AI Agent Messages (aggiornato il 18 feb): Standardizza la messaggistica conversazionale con sette kind di event effimeri (25800-25806) per stato, delta di streaming, prompt, risposte, chiamate agli strumenti, errori e cancellazione. Gli event kind 31340 “AI Info” permettono agli agenti di pubblicizzare modelli e capacità supportate.
NIP-AC: DVM Agent Coordination (aperto il 18 feb): Estende NIP-90 per i flussi di lavoro autonomi degli agenti. Aggiunge heartbeat per la scoperta degli agenti, recensioni dei job per il tracciamento della qualità, escrow dei dati per l’impegno sui risultati, catene di flusso di lavoro per pipeline multi-step e bidding in sciame per la selezione competitiva dei provider. Un’implementazione di riferimento gira su 2020117.xyz.
NIP-AD: MCP Server Announcements (aperto il 12 feb): Standardizza l’annuncio dei server e delle skill del Model Context Protocol su Nostr. Già in uso sulla piattaforma TENEX.

Altre PR Aperte:

NIP-144: Service Authorization Protocol: Definisce come i client dimostrano identità e permessi ai provider di servizi su Nostr.
NIP-DC: Nostr Webxdc: alexgleason propone di integrare Webxdc (applicazioni web decentralizzate) con gli event Nostr.

NIP Deep Dive: NIP-55 (Applicazione Signer Android)

NIP-55 definisce come i client Nostr Android richiedono operazioni crittografiche da applicazioni signer dedicate. Con White Noise v0.3.0 e Unfiltered v1.0.6 che aggiungono entrambi il supporto ad Amber questa settimana, il protocollo di firma Android merita un esame.

Canali di Comunicazione:

NIP-55 abilita la firma inter-app attraverso due meccanismi. Gli Intent forniscono l’approvazione manuale dell’utente con feedback visivo per operazioni una tantum. I Content Resolver abilitano la firma automatizzata quando gli utenti concedono permessi persistenti, permettendo alle app di firmare in background senza prompt ripetuti.

La comunicazione usa lo schema URI personalizzato nostrsigner:. Un client avvia il contatto con:

nostrsigner:<base64-encoded-event>?type=sign_event&callbackUrl=myapp://callback

Operazioni Supportate:

La specifica definisce sette metodi crittografici: firma degli event (sign_event), recupero della chiave pubblica (get_public_key), cifratura/decifratura NIP-04, cifratura/decifratura NIP-44 e decifratura degli event zap (decrypt_zap_event).

Modello di Permessi:

I client chiamano get_public_key una volta per stabilire una relazione di fiducia, ricevendo il nome del pacchetto del signer e la pubkey dell’utente. La specifica impone che i client salvino questi valori e non chiamino mai più get_public_key, prevenendo attacchi di fingerprinting.

Per le richieste di firma, gli utenti possono approvare una volta o concedere “ricorda la mia scelta” per le operazioni in background. Se gli utenti rifiutano ripetutamente le operazioni, il signer restituisce uno stato “rejected”, prevenendo prompt ripetuti.

Implementazioni:

Amber è il signer NIP-55 principale per Android. I client che supportano NIP-55 includono Amethyst, White Noise, Unfiltered e altri. Le applicazioni web non possono ricevere direttamente le risposte del signer e devono usare URL di callback o operazioni con gli appunti.

Relazione con gli Altri NIP di Firma:

NIP-55 completa NIP-07 (estensioni browser) e NIP-46 (firma remota sui relay). Dove NIP-07 gestisce i browser desktop e NIP-46 gestisce la firma cross-device, NIP-55 fornisce integrazione nativa Android con latenza minima.

NIP Deep Dive: NIP-60 (Wallet Cashu)

NIP-60 definisce come i wallet ecash Cashu memorizzano lo stato sui relay Nostr, abilitando la sincronizzazione del wallet tra applicazioni. Con Ridestr v0.2.6 che usa NIP-60 per la sincronizzazione del wallet tra dispositivi, il protocollo merita un esame.

Tipi di Event:

NIP-60 usa quattro tipi di event. Il kind 17375 sostituibile memorizza la configurazione del wallet inclusi gli URL dei mint e una chiave privata dedicata per ricevere pagamenti ecash P2PK. Gli event token (kind 7375) contengono prove crittografiche non spese, mentre la cronologia delle spese (kind 7376) registra le transazioni per la trasparenza dell’utente. Un kind 7374 opzionale traccia le quote di pagamento del mint.

Architettura del Wallet:

Lo stato del wallet risiede sui relay, rendendolo accessibile tra le applicazioni. L’event wallet di un utente contiene riferimenti cifrati ai mint Cashu e una chiave privata specifica per il wallet separata dall’identità Nostr dell’utente. Questa separazione è importante: la chiave wallet gestisce le operazioni ecash mentre la chiave Nostr gestisce le funzioni sociali.

{
 "kind": 17375,
 "content": "<nip44-encrypted-wallet-config>",
 "tags": [["d", "cashu-wallet"]]
}

Gestione delle Prove:

Le prove Cashu sono strumenti al portatore. Una volta spesa, una prova diventa non valida. NIP-60 gestisce questo attraverso un meccanismo di rollover: durante la spesa, i client creano un nuovo event token con le prove non spese rimanenti ed eliminano l’originale tramite NIP-09. Gli ID dei token distrutti vanno in un campo del per il tracciamento dello stato.

I client dovrebbero periodicamente validare le prove contro i mint per rilevare credenziali precedentemente spese. Sono consentiti event token multipli per mint, e gli event della cronologia delle spese aiutano gli utenti a tracciare le transazioni anche se sono facoltativi.

Modello di Sicurezza:

Tutti i dati sensibili usano la cifratura NIP-44. La chiave privata del wallet non appare mai in chiaro. Poiché i relay memorizzano blob cifrati senza comprenderne il contenuto, lo stato del wallet rimane privato anche su relay non fidati.

Implementazioni:

I wallet che supportano NIP-60 includono Nutsack e eNuts. Client come Ridestr usano NIP-60 per la sincronizzazione cross-device, permettendo agli utenti di ricaricare dal desktop e spendere dal mobile senza trasferimenti manuali.

È tutto per questa settimana. Stai costruendo qualcosa o hai notizie da condividere? Contattaci via DM NIP-17 o trovaci su Nostr.

Nostr Compass #10

Wed, 18 Feb 2026 00:00:00 +0000

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

Questa settimana: Prende forma un livello di cache locale per Blossom, con progetti indipendenti che convergono sull’accesso offline ai media per Android. Alby lancia un sandbox per sviluppatori NWC per costruire e testare integrazioni Nostr Wallet Connect senza rischiare fondi reali. Nello stesso arco di giorni arrivano due proposte concorrenti per la comunicazione di agenti AI su Nostr, firmate da autori diversi. fiatjaf elimina i campi inutilizzati da NIP-11, rimuovendo policy di riservatezza, retention, codici paese e tag sulle preferenze comunitarie che gli operatori relay non avevano mai adottato. NIP-85 viene unito con linee guida sulla scoperta dei provider di servizi per le Trusted Assertions. Un nuovo tag D in NIP-52 abilita l’indicizzazione temporale a granularità giornaliera per gli eventi calendario. Tra i nuovi progetti: Mapnolia per la distribuzione decentralizzata di tile cartografiche, Pika per la messaggistica cifrata con MLS, Keep per la firma a soglia FROST su Android, Hashtree per lo storage content-addressed con integrazione Nostr, e Prism per condividere contenuti su Nostr da qualsiasi app Android. Primal Android unisce 11 PR NWC aggiungendo supporto doppio wallet e gestione automatica del ciclo di vita del servizio. Mostro Mobile rilascia un wallet Lightning integrato tramite integrazione NWC. Notedeck si prepara al rilascio sull’App Store Android, mentre HAVEN raggiunge la v1.2.0-rc3 con supporto multi-npub e backup cloud. Gli approfondimenti di questa settimana coprono il sistema Trusted Assertions di NIP-85 per delegare i calcoli del Web of Trust ai provider di servizi, e il protocollo Calendar Events di NIP-52 a seguito dell’aggiornamento per l’indicizzazione a granularità giornaliera.

Notizie

Emerge un Livello di Cache Locale per Blossom

Diversi progetti indipendenti stanno convergendo sullo stesso problema: l’accesso offline ai media Blossom su dispositivi mobili.

Morganite, una nuova app Android di greenart7c3 (lo sviluppatore dietro Amber e Citrine), implementa il caching lato client per i media Blossom. Gli utenti possono accedere a immagini e file precedentemente visualizzati senza connessione di rete.

Aerith ha rilasciato la v0.2 con etichettatura delle immagini, operazioni bulk di mirror/tag/eliminazione, filtraggio per etichetta e tipo di file, più il supporto iniziale alla cache locale Blossom. Aerith è un’interfaccia di gestione per utenti che archiviano media su più server Blossom e necessitano di organizzare e replicare i propri blob.

Una nuova guida all’implementazione della cache locale nella specifica Blossom documenta lo storage blob lato client, mentre Prism (dello stesso sviluppatore di Aerith) aggiunge l’integrazione Blossom upload al proprio flusso share-to-Nostr su Android. Quattro progetti indipendenti hanno convergito sullo stesso problema questa settimana: un’app di caching dedicata, un gestore media, una specifica di riferimento e uno strumento di condivisione con integrazione Blossom, tutti con storage locale persistente oltre il semplice upload-e-recupero.

Sandbox NWC per Sviluppatori di Alby

Alby ha lanciato un ambiente sandbox per gli sviluppatori che lavorano con Nostr Wallet Connect (NIP-47). Il sandbox offre un servizio NWC wallet ospitato dove gli sviluppatori possono creare connessioni di test e inviare pagamenti simulati senza collegare un vero wallet Lightning, osservando in tempo reale il ciclo completo richiesta/risposta degli eventi NWC. Gli sviluppatori generano una stringa di connessione nostr+walletconnect:// dal sandbox e la passano al proprio client. Il sandbox mostra poi il kind 23194 (richiesta) e il kind 23195 (risposta) risultanti mentre scorrono tra client e wallet service.

Questo abbassa la barriera per le nuove integrazioni NWC. In precedenza, i test richiedevano un wallet Lightning personale o un servizio NWC self-hosted. Il sandbox astrae questa complessità, dando agli sviluppatori un ciclo di feedback immediato per implementare i metodi pay_invoice, get_balance, make_invoice, lookup_invoice e list_transactions su un endpoint NWC attivo.

Arrivano le Proposte di NIP per Agenti AI

Proposte per la comunicazione di agenti AI su Nostr sono apparse a distanza di giorni l’una dall’altra, affrontando il problema da angolazioni diverse.

NIP-XX: AI Agent Messages di joelklabo definisce un protocollo completo per l’interazione con agenti AI: kind di eventi per prompt, risposte, delta di streaming, aggiornamenti di stato, telemetria degli strumenti, errori, cancellazioni e scoperta delle capacità. Un evento di scoperta ai.info (kind 31340, sostituibile) permette agli agenti di annunciare i modelli supportati, gli strumenti con i relativi schemi, il supporto allo streaming e i limiti di frequenza. La proposta di joelklabo include la correlazione delle esecuzioni tramite prompt ID, la gestione delle sessioni, la riconciliazione dello stream con ordinamento sequenziale e indicazioni NIP-59 per la privacy dei metadata.

NIP-AE: Agents di pablof7z adotta un approccio diverso, definendo kind per l’istanziazione degli agenti: definizioni e lezioni. Si tratta dei tipi di eventi che pablof7z usa in TENEX, il sistema di apprendimento autonomo costruito su Nostr. Una proposta complementare, NIP-AD: MCP Server and Skill Announcements, sempre di pablof7z, definisce eventi per annunciare server Model Context Protocol e skill su Nostr. I commenti NIP-22 sono supportati, così la community può discutere e valutare i server MCP direttamente su Nostr.

NIP-XX copre la comunicazione completa degli agenti, mentre NIP-AE e NIP-AD si occupano di identità e scoperta degli strumenti. Queste proposte potrebbero convergere in uno standard unificato o coesistere come livelli complementari.

Rilasci

HAVEN v1.2.0-rc3

HAVEN, il relay personale all-in-one che raggruppa quattro funzioni relay con un server media Blossom, ha raggiunto la v1.2.0-rc3. Questa release candidate aggiunge il supporto per più npub, permettendo a una singola istanza HAVEN di servire diverse identità Nostr. Le RC precedenti avevano aggiunto i flag --from-cloud e --to-cloud per il backup cloud (RC2) e corretto un bug di doppio conteggio nel Web of Trust (RC1).

Mostro Mobile v1.2.0: Wallet Lightning Integrato

Mostro Mobile, il client mobile per l’exchange Bitcoin P2P Mostro (v1.1.0 coperto la settimana scorsa), ha rilasciato la v1.2.0 con un wallet Lightning integrato attraverso la completa integrazione NWC (NIP-47). Acquirenti e venditori non devono più cambiare app per gestire le fatture. L’app rileva le hold invoice per i venditori e le paga automaticamente tramite il wallet collegato, mentre gli acquirenti ricevono la generazione automatica delle fatture. Il rilascio fa seguito alla v1.1.1 pubblicata all’inizio della settimana, che aggiungeva il supporto multi-nodo Mostro con un registro curato di istanze fidate, il recupero dei metadata kind 0 per la visualizzazione dei nodi, la gestione di nodi personalizzati tramite pubkey e il fallback automatico quando un nodo selezionato va offline.

Sul lato server, Mostro v0.16.2 è arrivato con correzioni per i pagamenti doppi delle dev fee, il rate limiting sull’endpoint RPC di validazione password e la corretta pulizia delle dispute alla cancellazione cooperativa.

Un nuovo progetto companion, mostro-skill, consente agli agenti di fare trading su Mostro tramite Nostr.

Aerith v0.2

Aerith, il gestore di immagini Blossom, ha rilasciato la v0.2 con etichette per l’organizzazione dei media, operazioni bulk di mirror/tag/eliminazione tra server, filtraggio per etichetta e tipo di file, più il supporto iniziale alla cache locale. Vedi la sezione Notizie per il contesto sul trend più ampio della cache locale.

Mapnolia: Tile Cartografiche Decentralizzate su Nostr

Mapnolia è un nuovo server di dati geospaziali che suddivide gli archivi di tile cartografiche PMTiles in regioni geografiche e le annuncia su Nostr per la scoperta decentralizzata. Pubblica eventi parametrizzati sostituibili kind 34444 sui relay Nostr contenenti un indice completo dei chunk di tile con metadati dei layer, regioni geohash, riferimenti ai file e dettagli del server Blossom.

I client scoprono e recuperano i dati cartografici attraverso la rete Nostr invece dei server di tile centralizzati, con eventi di annuncio che portano metadati sufficienti a richiedere solo le regioni geografiche necessarie dai server Blossom elencati. Mapnolia è il primo progetto a portare la distribuzione di dati geospaziali su Nostr, aprendo possibilità per applicazioni cartografiche con supporto offline.

Pika: Messaggistica Cifrata con Marmot

Pika è una nuova app di messaggistica end-to-end cifrata per iOS e Android che usa il protocollo Marmot, che stratifica il Messaging Layer Security (MLS) sui relay Nostr. L’architettura separa le responsabilità in un core Rust (pika_core) che gestisce lo stato MLS e la cifratura/decifratura dei messaggi sui relay Nostr, con shell UI native snelle in SwiftUI (iOS) e Kotlin (Android). Lo stato scorre unidirezionalmente: la UI invia azioni all’attore Rust, che modifica lo stato e restituisce snapshot con numeri di revisione alla UI tramite binding UniFFI e JNI.

Pika si unisce a un campo in crescita di messenger MLS-on-Nostr insieme a White Noise, Vector e 0xchat. Tutti usano i relay Nostr come livello di trasporto per il ciphertext cifrato MLS, rendendo gli operatori relay incapaci di leggere il contenuto dei messaggi. Pika usa il Marmot Development Kit (MDK) per la propria implementazione MLS e nostr-sdk per la connettività relay.

Keep: Firma a Soglia FROST per Android

Keep è una nuova applicazione Android per la firma a soglia FROST dove nessun singolo dispositivo detiene la chiave privata completa. Implementa NIP-55 (Android Signer) e NIP-46 (firma remota), così i client Nostr compatibili possono richiedere firme mantenendo il materiale crittografico distribuito tra dispositivi. Le configurazioni predefinite sono 2-di-3 e 3-di-5, ma è supportata qualsiasi soglia t-di-n.

La cerimonia di generazione distribuita delle chiavi (DKG) di Keep avviene sui relay Nostr usando kind di eventi personalizzati: kind 21101 per gli annunci di gruppo, kind 21102 per i polinomi di commitment del round 1 (trasmessi pubblicamente) e kind 21103 per le share segrete del round 2 (cifrate NIP-44 punto-a-punto tra i partecipanti). Lo scalare della chiave privata di gruppo non viene mai calcolato né assemblato durante il DKG. Ogni dispositivo detiene solo la propria share di valutazione polinomiale, e qualsiasi t share può produrre una firma Schnorr valida attraverso un protocollo commit-then-sign a due round. La firma da 64 byte risultante è indistinguibile da una firma Schnorr a singolo firmatario. Internamente, Keep usa il crate frost-secp256k1-tr della Zcash Foundation con il Taproot tweaking, così la chiave pubblica di gruppo funziona direttamente come un npub Nostr.

Keep si unisce alla famiglia di progetti Frostr insieme a Igloo Desktop, Igloo for Android, Frost2x e Igloo for iOS, ampliando le opzioni per la gestione a soglia delle chiavi su Nostr.

Prism: Condividi Qualsiasi Cosa su Nostr da Android

Prism è una nuova app Android (Kotlin/Jetpack Compose, API 26+) che si registra come target di condivisione di sistema, permettendo agli utenti di pubblicare testo, URL, immagini e video su Nostr da qualsiasi app del proprio telefono. Gli URL condivisi passano attraverso uno stripping dei parametri di tracciamento prima di essere composti in note. Prism recupera i metadata OpenGraph per generare anteprime link ricche e rende i riferimenti Nostr nativi (note1, nevent1) inline.

Il motore di pianificazione usa un approccio ibrido AlarmManager/WorkManager per aggirare le ottimizzazioni della batteria Android: AlarmManager gestisce la temporizzazione precisa dei wake-up mentre i task WorkManager urgenti garantiscono la consegna, con retry a backoff esponenziale per gli scenari offline. I caricamenti media avvengono su server Blossom configurabili con generazione di thumbnail per immagini e frame video. Tutta la firma degli eventi è delegata a signer esterni NIP-55 come Amber, con supporto multi-account per passare tra identità. Prism supporta anche i post NIP-84 (Highlights). Dello stesso sviluppatore di Aerith.

Hashtree: Storage Content-Addressed con Integrazione Nostr

Hashtree è un sistema di storage blob content-addressed basato su filesystem che pubblica radici Merkle su Nostr per creare indirizzi npub/percorso mutabili. Il sistema usa uno “storage stupido” che funziona con qualsiasi key-value store, suddividendo il contenuto in blocchi da 2MB ottimizzati per i caricamenti Blossom. A differenza di BitTorrent, non è necessaria alcuna computazione attiva delle prove Merkle: basta archiviare e recuperare i blob per hash.

L’integrazione Nostr abilita URL git remoti come htree://npub.../repo-name per il cloning di repository, con comandi come htree publish mydata <hash> per pubblicare hash di contenuto agli indirizzi npub.../mydata. Il CLI completo supporta sia la modalità di storage cifrata (predefinita) che quella pubblica, il pinning dei contenuti, il push ai server Blossom e la gestione delle identità Nostr. Ogni elemento archiviato è o raw bytes o un nodo dell’albero, fornendo una base per la distribuzione decentralizzata di contenuti attraverso la rete relay di Nostr.

Espy: Cattura Palette Colori su Shakespeare

Espy, costruito sulla piattaforma Shakespeare, permette agli utenti di catturare palette colori da foto e condividerle come eventi Nostr. Shakespeare è un costruttore di app assistito da AI che autentica gli utenti tramite estensioni browser NIP-07 e fornisce connettività relay Nostr integrata, così gli sviluppatori pubblicano app senza implementare la propria gestione delle chiavi o il proprio pool relay. Espy estrae i colori dominanti dall’input della fotocamera in schede palette condivisibili e scopribili tramite i feed Nostr standard.

Flotilla 1.6.4

Flotilla, il client Nostr in stile Discord di hodlbod che organizza i relay come gruppi, ha rilasciato la 1.6.4. La famiglia di progetti Coracle è migrata da GitHub a un’istanza Gitea self-hosted. Questo rilascio aggiunge notifiche push tramite NIP-9a e un flusso per la ricezione wallet, oltre a inserzioni classificate e supporto agli URL degli spazi. I miglioramenti all’interfaccia includono modal e gestione delle notifiche riorganizzati. Il muting delle stanze e gli inset safe area su mobile completano le modifiche, insieme a correzioni per i caricamenti immagini su Safari e i dettagli degli eventi calendario.

Shosho v0.12.0

Shosho, l’app mobile di live-streaming con integrazione Nostr, ha rilasciato la v0.12.0. Questo rilascio aggiunge Clip video con risposte in-player e integrazione emoji personalizzate. La protezione dei thread blocca lo spam da menzione indiretta, e una nuova funzione di condivisione QR permette agli utenti di scambiare profili offline. Una nuova modalità di riproduzione orizzontale offre agli stream un’esperienza di visione in stile Twitch, e la schermata di esplorazione ora mostra i clip dei creator insieme agli stream in diretta.

Granary v10.0

Granary, una libreria di traduzione per il web sociale che converte dati tra Nostr, Bluesky, ActivityPub e altre piattaforme in un formato comune, ha rilasciato la v10.0 con modifiche incompatibili. Il rilascio passa gli ID ActivityStreams 1 predefiniti di Nostr da bech32 a hex e aggiunge un supporto Nostr esteso tra cui il parsing delle menzioni NIP-27 e i tag degli articoli. Una nuova opzione di output multiplo tra i converter permette agli sviluppatori di tradurre tra protocolli in batch.

Nostr MCP Server v3.0.0

Nostr MCP Server, un server Model Context Protocol che consente agli agenti AI di interagire con la rete Nostr, ha rilasciato la v3.0.0. Questo rilascio principale aggiunge azioni sociali (follow, reazioni, repost, risposte) e gestione delle liste relay con supporto NIP-65 più autenticazione opzionale NIP-42. Sono nuovi anche i messaggi diretti tramite NIP-17 e NIP-44. Il rilascio si affianca alle proposte di NIP per agenti AI di questa settimana come strumenti pratici per gli agenti che operano su Nostr.

Aegis v0.3.8

Aegis, il signer Nostr cross-platform, ha rilasciato la v0.3.8 con supporto UI multilingua e un gestore di aggiornamenti incrementale per il proprio browser di app Nostr integrato. Il nuovo meccanismo di aggiornamento calcola il diff in modo incrementale rispetto allo stato locale, mantenendo aggiornata la directory in-app delle web app Nostr con un consumo di banda ridotto. Il rilascio introduce anche un caching del materiale crittografico da 5 minuti per ridurre i round-trip al database quando si firmano più eventi in successione.

SNSTR v0.3.1

SNSTR (Secure Nostr Software Toolkit for Renegades), una libreria TypeScript per il protocollo Nostr, ha rilasciato la v0.3.1. Il rilascio aggiunge guardie di verifica dei pacchetti che assicurano che tutti i punti di ingresso siano inclusi nei tarball npm, con verifica CI su Node e Bun. La v0.3.0 è uscita nella stessa settimana.

Citrine v2.0.0-pre1

Citrine, il relay Nostr per Android di greenart7c3, ha rilasciato la v2.0.0-pre1 con miglioramenti delle prestazioni tramite indici del database ottimizzati e una migliore gestione delle coroutine Kotlin. Il rilascio migliora anche il supporto per l’hosting di web app, con ogni app ora in esecuzione sulla propria porta.

Aggiornamenti dei Progetti

Primal Android: Espansione dell’Infrastruttura NWC

Primal Android ha unito 11 PR legate a NWC questa settimana, continuando il lavoro avviato due settimane fa. Questa tornata aggiunge il supporto NWC per doppio wallet, avvio/arresto automatico del servizio legato alle notifiche del backend, routing delle connessioni per tipo di wallet e corretta pulizia dei dati all’eliminazione del wallet. Il servizio NWC ora gestisce il proprio ciclo di vita in base allo stato della connessione wallet, riducendo l’intervento manuale dell’utente.

Notedeck: Preparazione all’App Store Android

Notedeck, il client Nostr multi-piattaforma del team Damus, ha unito la preparazione al rilascio sull’App Store Android questa settimana. La PR aggiunge un piano di conformità UGC (User Generated Content) richiesto da Google Play, inclusa una schermata di accettazione dei Termini di Servizio, il blocco degli utenti tramite menu contestuali e impostazioni, la funzionalità NIP-56 (Segnalazione) che pubblica eventi di segnalazione sui relay, e una sezione di impostazioni per Contenuto e Sicurezza. È stata aggiunta l’infrastruttura di build per generare APK firmati e AAB (Android App Bundle) tramite nuovi target Makefile. Un documento EULA stabilisce un requisito di età di 17 anni e disclaimer specifici per Nostr riguardo ai contenuti decentralizzati. Le funzionalità di conformità stesse arriveranno in PR successive; questo merge pone le basi documentali e di firma.

Sul fronte Damus iOS, è stata corretta una regressione del caricamento infinito in cui lo spinner persisteva indefinitamente dopo che il contenuto era stato caricato.

Nostria: Relay di Scoperta e Correzioni DM

Nostria, il client Nostr cross-platform focalizzato sulla scala globale, ha unito 9 PR questa settimana. La più importante aggiunge l’auto-inizializzazione dei Discovery Relay per la ricerca dei profili, garantendo ai nuovi utenti una connettività relay funzionante senza configurazione manuale. Altre correzioni riguardano l’avvolgimento del testo nelle textarea DM, il riempimento del viewport per i video a schermo intero, l’estrazione dei metadata degli articoli nelle anteprime repost e la risoluzione degli URI nostr: nelle notifiche.

Camelus: Migrazione a Riverpod v3

Camelus, il client Nostr basato su Flutter, ha unito 5 PR questa settimana incentrate su una migrazione all’API Riverpod v3 e un refactoring del feed generico. Una cache delle note incorporate evita fetch ridondanti ai relay per le note citate.

Aggiornamenti NIP

Modifiche recenti al repository NIPs:

Uniti:

NIP-85: Scoperta dei Provider di Servizi: vitorpamplona ha aggiunto indicazioni sulla scoperta da parte dei client dei provider di servizi NIP-85 Trusted Assertions, inclusi gli hint relay e le chiavi di servizio specifiche per algoritmo. Vedi l’approfondimento per la copertura completa.
NIP-11: Pulizia delle Informazioni Relay: fiatjaf ha rimosso privacy_policy, l’array retention, relay_countries e il blocco delle preferenze comunitarie da NIP-11. Gli operatori relay raramente popolavano questi campi e i client non vi agivano sopra.
NIP-52: Tag di Timestamp a Granularità Giornaliera: staab ha aggiunto un tag D obbligatorio a NIP-52 per gli eventi calendario basati sul tempo (kind 31923) che rappresenta il timestamp Unix a granularità giornaliera, calcolato come floor(unix_seconds / 86400). Più tag D coprono eventi multi-giorno, abilitando un efficiente indicizzazione temporale senza dover analizzare i timestamp completi.
NIP-47: Semplificazione: La PR di semplificazione discussa nel numero #9 è stata unita questa settimana, rimuovendo multi_pay_invoice e multi_pay_keysend da NIP-47 (Nostr Wallet Connect). Vedi il numero #8 per l’approfondimento completo sul protocollo NWC.

PR Aperte e Discussioni:

NIP-74: Podcast: Coperto nel numero #8, questa proposta di specifica per i podcast ha visto un acceso dibattito questa settimana. staab ha notato che esistono già almeno tre standard podcast concorrenti in circolazione, e derekross ha indicato un’implementazione esistente risalente a sei mesi fa con app e podcast attivi. Il percorso da seguire richiede una convergenza tra le implementazioni prima che possa essere assegnato un numero NIP.
NIP-XX: AI Agent Messages: joelklabo propone un protocollo completo di comunicazione per agenti AI con kind di eventi per prompt, risposte, streaming, telemetria degli strumenti, errori e scoperta delle capacità. Vedi la sezione Notizie per la copertura di tutte le proposte AI di questa settimana.
NIP-PNS: Private Note Storage: il sistema di note private di jb55 definisce eventi kind 1080 per archiviare note personali cifrate sui relay senza rivelare chi le ha scritte. Lo schema deriva una coppia di chiavi pseudonima deterministica dalla nsec dell’utente tramite HKDF: pns_key = hkdf_extract(ikm=device_key, salt="nip-pns"), quindi genera una coppia di chiavi secp256k1 da quella chiave derivata. Una seconda derivazione produce una chiave di cifratura simmetrica: pns_nip44_key = hkdf_extract(ikm=pns_key, salt="nip44-v2"). Le note interne sono cifrate con NIP-44 v2 usando questa chiave e pubblicate sotto la pubkey pseudonima, così i relay vedono eventi kind 1080 da un’identità non collegata alla chiave principale dell’utente. A differenza dei gift wrap NIP-59, PNS non è soggetto a spam (la chiave pseudonima è deterministica, non casuale) e non porta metadata pubblici (non servono tag p poiché non c’è destinatario). Questa settimana, jb55 ha pubblicato le conclusioni tratte dall’implementazione di PNS nel backend Rust di Notedeck (modulo enostr::pns). Ha identificato che la chiamata hkdf_extract della spec è ambigua perché HKDF secondo RFC 5869 ha due fasi (Extract ed Expand) che producono output diversi, e la maggior parte delle librerie si aspetta entrambe. Ha chiarito che pns_nip44_key aggira il normale accordo di chiavi ECDH di NIP-44 e viene usata direttamente come conversation key, un dettaglio che gli implementatori devono conoscere poiché la maggior parte delle librerie NIP-44 usa ECDH di default. Ha anche segnalato una variabile non definita nell’implementazione di riferimento TypeScript. La PR, originariamente dell’aprile 2025, è ora in fase di implementazione attiva.
NIP-AE: Agents: pablof7z definisce quattro kind di eventi per l’identità degli agenti su Nostr, tratti dal suo lavoro su TENEX. Il template base è kind 4199 (Agent Definition), che contiene titolo, descrizione del ruolo, istruzioni di sistema, dichiarazioni di strumenti e versione. I modificatori comportamentali risiedono nel kind 4201 (Agent Nudge), che usa i tag only-tool, allow-tool e deny-tool per il controllo delle capacità in runtime. Gli agenti pubblicano ciò che apprendono come eventi kind 4129 (Agent Lesson), categorizzati e collegati alla definizione genitore tramite tag e, perfezionabili attraverso thread di commenti NIP-22. La verifica della proprietà usa kind 14199, un evento sostituibile in cui gli operatori umani elencano le proprie pubkey agente, stabilendo una catena bidirezionale quando abbinato al tag p del profilo kind 0 dell’agente.
NIP-AD: MCP Server and Skill Announcements: pablof7z definisce eventi per annunciare server Model Context Protocol e skill individuali su Nostr. Gli annunci di server MCP portano l’URL endpoint del server e la versione di protocollo supportata insieme a un elenco di strumenti disponibili con i relativi schemi di input. I commenti NIP-22 sono supportati sugli annunci di server, così la community può discutere e valutare i server MCP direttamente su Nostr.
NIP-73: OSM Tag Kind: DestBro propone di aggiungere gli identificatori OpenStreetMap a NIP-73 (External Content IDs), che standardizza come gli eventi Nostr referenziano contenuti esterni come libri (ISBN), film (ISAN), feed podcast (GUID), geohash e URL tramite tag i e k. Il kind OSM proposto permetterebbe agli eventi di referenziare elementi cartografici specifici (edifici, strade, parchi) tramite il loro ID nodo o way OpenStreetMap, collegando i contenuti Nostr al database geografico aperto.
NIP-XX: Responsive Image Variants: woikos propone di estendere gli eventi di metadata file NIP-94 con tag per varianti di immagini responsive a risoluzioni diverse. I client potrebbero selezionare la variante appropriata in base alle dimensioni del display e alle condizioni di rete, riducendo il consumo di banda per gli utenti mobile che visualizzano immagini ad alta risoluzione ospitate su server Blossom.

NIP Deep Dive: NIP-85 (Trusted Assertions)

NIP-85 definisce un sistema per delegare calcoli costosi a provider di servizi fidati che pubblicano i risultati firmati come eventi Nostr. I punteggi Web of Trust e le metriche di engagement richiedono la scansione di molti relay e l’elaborazione di grandi volumi di eventi, un lavoro impraticabile su dispositivi mobili. Il merge di questa settimana ha aggiunto indicazioni sul processo di scoperta da parte dei client di questi provider.

Delega:

Calcolare il punteggio Web of Trust di un utente richiede la scansione dei grafi di follow per diversi livelli su molti relay, e il calcolo accurato dei conteggi follower comporta la deduplicazione sull’intera rete relay. I dispositivi mobili e i client browser non possono eseguire queste operazioni, eppure i risultati sono essenziali per il filtraggio dello spam e il ranking dei contenuti. NIP-85 colma questo divario permettendo agli utenti di designare provider fidati per eseguire i calcoli e pubblicare i risultati come eventi Nostr standard.

Design del Protocollo:

NIP-85 usa quattro kind di eventi per le asserzioni su diversi tipi di soggetti. Le asserzioni sugli utenti (kind 30382) portano il conteggio follower, i conteggi post/risposte/reazioni, gli importi zap, il rank normalizzato (0-100), i topic comuni e le ore attive:

{
 "id": "<event hash>",
 "pubkey": "<service pubkey>",
 "created_at": 1739836800,
 "kind": 30382,
 "tags": [
 ["d", "e88a691e98d9987c964521dff60025f60700378a4879180dcbbb4a5027850411"],
 ["rank", "89"],
 ["followers", "4521"],
 ["first_created_at", "1609459200"],
 ["post_cnt", "1283"],
 ["reply_cnt", "647"],
 ["reactions_cnt", "8920"],
 ["zap_amt_recd", "850000"],
 ["zap_amt_sent", "320000"],
 ["zap_cnt_recd", "412"],
 ["zap_cnt_sent", "198"],
 ["zap_avg_amt_day_recd", "1150"],
 ["zap_avg_amt_day_sent", "430"],
 ["reports_cnt_recd", "2"],
 ["reports_cnt_sent", "0"],
 ["t", "nostr"],
 ["t", "bitcoin"],
 ["active_hours_start", "14"],
 ["active_hours_end", "22"]
 ],
 "content": "",
 "sig": "<service key signature>"
}

Le asserzioni sugli eventi (kind 30383) valutano le singole note con il conteggio commenti, citazioni, repost, reazioni e dati zap:

{
 "id": "<event hash>",
 "pubkey": "<service pubkey>",
 "created_at": 1739836800,
 "kind": 30383,
 "tags": [
 ["d", "<target event id>"],
 ["rank", "72"],
 ["comment_cnt", "45"],
 ["quote_cnt", "12"],
 ["repost_cnt", "89"],
 ["reaction_cnt", "310"],
 ["zap_cnt", "23"],
 ["zap_amount", "125000"]
 ],
 "content": "",
 "sig": "<service key signature>"
}

Per gli eventi indirizzabili (articoli long-form, pagine wiki), kind 30384 applica le stesse metriche di engagement su tutte le versioni collettivamente. Kind 30385 valuta gli identificatori esterni (libri, film, siti web, luoghi, hashtag) referenziati tramite NIP-73 (External Content IDs), che standardizza come gli eventi Nostr referenziano contenuti esterni tramite tag i e k:

{
 "id": "<event hash>",
 "pubkey": "<service pubkey>",
 "created_at": 1739836800,
 "kind": 30385,
 "tags": [
 ["d", "isbn:9780765382030"],
 ["k", "isbn"],
 ["rank", "94"],
 ["comment_cnt", "67"],
 ["reaction_cnt", "203"]
 ],
 "content": "",
 "sig": "<service key signature>"
}

Ogni asserzione è un evento indirizzabile sostituibile dove il tag d contiene il soggetto: una pubkey, un ID evento, un indirizzo evento o un identificatore NIP-73. I provider di servizi firmano questi eventi con le proprie chiavi, e i client li valutano in base alle relazioni di fiducia.

Scoperta dei Provider:

Gli utenti dichiarano quali provider di asserzioni si fidano pubblicando eventi kind 10040. Ogni voce specifica il tipo di asserzione con la pubkey del provider e l’hint relay, più varianti di algoritmo opzionali:

{
 "id": "<event hash>",
 "pubkey": "<user pubkey>",
 "created_at": 1739836800,
 "kind": 10040,
 "tags": [
 ["30382:rank", "4fd5e210...", "wss://nip85.nostr.band"],
 ["30382:rank", "3d842afe...", "wss://nostr.wine"],
 ["30382:zap_amt_sent", "4fd5e210...", "wss://nip85.nostr.band"],
 ["30383:rank", "4fd5e210...", "wss://nip85.nostr.band"]
 ],
 "content": "",
 "sig": "<user signature>"
}

Gli utenti possono cifrare l’elenco dei tag nel .content usando NIP-44 per mantenere private le proprie preferenze di provider. I client costruiscono un elenco di provider controllando quali provider si fidano i propri account seguiti, creando un livello di reputazione decentralizzato per i provider di asserzioni stessi.

Modello di Sicurezza:

I provider devono usare chiavi di servizio diverse per algoritmi distinti, e una chiave unica per utente quando gli algoritmi sono personalizzati, impedendo la correlazione incrociata delle query tra utenti. Ogni chiave di servizio ottiene un evento di metadata kind 0 che descrive il comportamento dell’algoritmo, dando agli utenti trasparenza su ciò in cui ripongono la propria fiducia. Gli eventi di asserzione dovrebbero essere aggiornati solo quando i dati sottostanti cambiano effettivamente, prevenendo traffico relay non necessario e permettendo ai client di memorizzare nella cache i risultati con fiducia.

Adozione Attuale:

NIP-85 formalizza un pattern già emerso informalmente. Il server cache di Primal calcola le metriche di engagement e i punteggi Web of Trust. Antiprimal, coperto nel numero #9, collega questi calcoli ai client Nostr standard usando i kind di eventi NIP-85. Nostr.band gestisce il relay wss://nip85.nostr.band referenziato negli esempi della spec stessa, servendo eventi di asserzione per i dati del proprio indice di ricerca. Sul lato client, Amethyst (scritto da vitorpamplona, anche autore di questo NIP) ha un supporto sperimentale alle Trusted Assertions nella propria libreria quartz, che analizza gli eventi di asserzione e le dichiarazioni dei provider di servizi. Vertex calcola metriche Web of Trust simili ma ha scelto un approccio diverso, usando una API diretta invece degli eventi NIP-85, citando il problema della scoperta e l’overhead computazionale delle architetture basate su asserzioni. Con NIP-85, qualsiasi client può consumare asserzioni da qualsiasi provider attraverso un formato di evento standard, e i provider competono sull’accuratezza mentre gli utenti scelgono di chi fidarsi.

NIP Deep Dive: NIP-52 (Calendar Events)

NIP-52 definisce gli eventi calendario su Nostr, dando ai client un modo standard per rappresentare e scoprire occorrenze in momenti specifici o tra momenti. Il merge del tag D di questa settimana ha aggiunto l’indicizzazione a granularità giornaliera, completando un elemento mancante nell’infrastruttura di query della spec.

Due Tipi di Evento:

NIP-52 separa gli eventi calendario in due kind in base alla precisione temporale. Gli eventi basati sulla data (kind 31922) rappresentano occorrenze che durano un’intera giornata come festività o festival multi-giorno. Usano stringhe di data ISO 8601 nei tag start e end opzionale, senza considerazioni sul fuso orario:

{
 "id": "<event hash>",
 "pubkey": "<event creator pubkey>",
 "created_at": 1735689600,
 "kind": 31922,
 "content": "Annual celebration of Bitcoin's genesis block",
 "tags": [
 ["d", "bitcoin-independence-day-2026"],
 ["title", "Bitcoin Independence Day"],
 ["start", "2026-01-03"],
 ["end", "2026-01-04"],
 ["location", "Worldwide"],
 ["g", "u4pruydqqv"],
 ["t", "bitcoin"],
 ["p", "<organizer-pubkey>", "wss://relay.example.com", "host"],
 ["r", "https://bitcoinindependenceday.com"]
 ],
 "sig": "<event creator signature>"
}

Gli eventi basati sul tempo (kind 31923) rappresentano momenti specifici con timestamp Unix nei tag start e end opzionale, più identificatori di fuso orario IANA (start_tzid, end_tzid) per la visualizzazione. Entrambi i kind sono eventi parametrizzati sostituibili, così gli organizzatori aggiornano i dettagli pubblicando un nuovo evento con lo stesso tag d.

Calendari e RSVP:

Gli eventi kind 31924 definiscono i calendari come collezioni, referenziando gli eventi tramite tag a che puntano agli eventi kind 31922 o 31923 tramite le loro coordinate di indirizzo:

{
 "id": "<event hash>",
 "pubkey": "<calendar owner pubkey>",
 "created_at": 1739836800,
 "kind": 31924,
 "content": "Nostr community events worldwide",
 "tags": [
 ["d", "nostr-community-calendar"],
 ["title", "Nostr Community Events"],
 ["a", "31923:<organizer-pubkey>:nostr-meetup-2026", "wss://relay.example.com"],
 ["a", "31922:<organizer-pubkey>:bitcoin-independence-day-2026"]
 ],
 "sig": "<calendar owner signature>"
}

Gli utenti possono mantenere più calendari (personale, lavoro, comunitario) e i client possono iscriversi ai calendari di pubkey specifiche. Gli eventi calendario possono includere un tag a che referenzia un calendario per richiedere l’inclusione, abilitando la gestione collaborativa dei calendari dove più utenti contribuiscono eventi a calendari che non possiedono.

Gli RSVP usano kind 31925, dove gli utenti pubblicano il proprio stato di partecipazione insieme a un indicatore opzionale libero/occupato:

{
 "id": "<event hash>",
 "pubkey": "<attendee pubkey>",
 "created_at": 1739836800,
 "kind": 31925,
 "content": "Looking forward to it",
 "tags": [
 ["a", "31923:<organizer-pubkey>:nostr-meetup-2026", "wss://relay.example.com"],
 ["e", "<kind 31923 event id>", "wss://relay.example.com"],
 ["d", "<unique-rsvp-id>"],
 ["status", "accepted"],
 ["fb", "busy"],
 ["p", "<organizer-pubkey>", "wss://relay.example.com"]
 ],
 "sig": "<attendee signature>"
}

I valori status validi sono “accepted”, “declined”, “tentative”, e il tag opzionale fb marca l’utente come libero o occupato per quel periodo. Gli eventi RSVP referenziano il tag a dell’evento calendario e portano il tag p dell’organizzatore, così il client dell’organizzatore può aggregare le risposte dai relay.

L’Aggiunta del Tag D:

Prima del merge di questa settimana, i client che interrogavano gli eventi in un intervallo di date dovevano recuperare tutti gli eventi da una pubkey o un calendario e filtrare lato client. Il nuovo tag D obbligatorio sugli eventi basati sul tempo (kind 31923) contiene un timestamp Unix a granularità giornaliera calcolato come floor(unix_seconds / 86400). Gli eventi multi-giorno portano più tag D, uno per giorno. I relay possono ora indicizzare gli eventi per giorno e rispondere a query filtrate in modo efficiente, trasformando quello che era un problema di filtraggio lato client in una ricerca nell’indice lato relay.

{
 "id": "<event hash>",
 "pubkey": "<event creator pubkey>",
 "created_at": 1739836800,
 "kind": 31923,
 "content": "Monthly meetup for Nostr developers in Austin",
 "tags": [
 ["d", "nostr-meetup-2026"],
 ["title", "Nostr Developer Meetup"],
 ["summary", "Talks and demos from local Nostr builders"],
 ["image", "https://example.com/meetup-banner.jpg"],
 ["start", "1740067200"],
 ["end", "1740078000"],
 ["start_tzid", "America/New_York"],
 ["end_tzid", "America/New_York"],
 ["D", "20139"],
 ["location", "Bitcoin Commons, Austin TX"],
 ["g", "9v6knb2pg"],
 ["p", "<organizer-pubkey>", "wss://relay.example.com", "host"],
 ["p", "<speaker-pubkey>", "wss://relay.example.com", "speaker"],
 ["t", "nostr"],
 ["t", "meetup"],
 ["r", "https://bitcoincommons.com"]
 ],
 "sig": "<event creator signature>"
}

Il valore D 20139 equivale a floor(1740067200 / 86400), collocando questo evento il 20 febbraio 2025. I client che interrogano “tutti gli eventi di questa settimana” inviano un filtro con il corrispondente intervallo D, e i relay restituiscono solo gli eventi corrispondenti.

Scelte di Design:

NIP-52 omette intenzionalmente gli eventi ricorrenti. La spec esclude completamente le regole di ricorrenza (RRULE da iCalendar), delegando quella complessità ai client. Un organizzatore pubblica eventi individuali per ogni occorrenza, mantenendo semplice il modello dati lato relay. I tag partecipante portano ruoli opzionali (“host”, “speaker”, “attendee”), e i tag di localizzazione possono includere tag geohash g per query spaziali insieme agli indirizzi leggibili.

Implementazioni:

Flockstr è il principale client calendario costruito su NIP-52. Coracle visualizza gli eventi calendario nel proprio feed sociale. L’aggiunta del tag D di questa settimana abilita l’indicizzazione temporale lato relay che entrambi i client possono usare per ridurre la banda quando si interrogano eventi in un intervallo di date specifico.

È tutto per questa settimana. Stai costruendo qualcosa o hai notizie da condividere? Vuoi che copriamo il tuo progetto? Contattaci via DM NIP-17 o trovaci su Nostr.

Nostr Compass #9

Wed, 11 Feb 2026 00:00:00 +0000

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

Questa settimana: Mostro rilascia la sua prima beta pubblica dopo tre anni di sviluppo, portando il trading P2P di Bitcoin su mobile via Nostr. OpenSats assegna la sedicesima ondata di grant Bitcoin, con Minibits Wallet che riceve un rinnovo per il suo wallet Cashu integrato con Nostr. Zapstore raggiunge la release stabile 1.0, segnando la maturazione dell’app store Android decentralizzato. Coracle 0.6.29 aggiunge topics e commenti sugli highlight. Igloo Desktop v1.0.3 introduce un importante hardening di sicurezza per la firma a soglia Frostr. Amber v4.1.2-pre1 migra all’architettura Flow. Angor raggiunge v0.2.5 con una UI di finanziamento rinnovata e configurazione server di immagini NIP-96. NostrPress viene lanciato come strumento che converte profili Nostr in blog statici. Antiprimal rilascia un gateway conforme agli standard che collega il cache server proprietario di Primal ai NIP standard di Nostr. Primal Android unisce 18 PR espandendo l’infrastruttura NWC con supporto doppio wallet, audit logging e il metodo lookup_invoice. diVine rilascia feed video API-first. L’SDK TypeScript di Marmot separa la sua app chat di riferimento in un repository autonomo e inizia la migrazione a ts-mls v2. Il repository NIPs unisce il conteggio approssimativo HyperLogLog per NIP-45 ed estrae i tag identità da kind 0. Un’ondata di proposte di vitorpamplona inizia a snellire sistematicamente i metadata kind 0. Nuove proposte di protocollo includono Nostr Relay Connect per il NAT traversal e Nostr Web Tokens per claim web firmati. Due approfondimenti chiudono il numero: il conteggio approssimativo HyperLogLog di NIP-45 per metriche eventi cross-relay, e il protocollo di file storage HTTP NIP-96, ora deprecato a favore di Blossom, mentre i progetti gestiscono la transizione tra i due standard media.

Notizie

Mostro Rilascia la Prima Beta Pubblica

Mostro, l’exchange Bitcoin peer-to-peer costruito su Nostr, ha rilasciato la sua app mobile v1.1.0, la prima beta pubblica del progetto dopo tre anni di sviluppo. L’app permette di scambiare Bitcoin direttamente usando Nostr per la coordinazione degli ordini, con Lightning per il settlement e nessun intermediario custodial.

Il rilascio introduce notifiche push con migliore affidabilità in background su Android, un sistema di logging opzionale che permette di catturare e condividere dati diagnostici quando si presentano problemi, aggiornamenti relay più fluidi con inizializzazione additiva, e raffinamenti UI di Fase 2 con supporto internazionalizzazione. L’app è disponibile su Zapstore e come download diretto da GitHub.

Mostro si unisce a Shopstr e Plebeian Market come applicazione commerciale nativa Nostr, con la distinzione di concentrarsi sulla coordinazione dello scambio fiat-Bitcoin. Il daemon Mostro sottostante gestisce il matching degli ordini e la risoluzione delle dispute attraverso relay Nostr.

Sedicesima Ondata di Grant Bitcoin di OpenSats

OpenSats ha annunciato grant a 17 progetti open-source. Il punto saliente per Nostr: Minibits Wallet, il wallet Android Cashu con supporto eventi wallet NIP-60 e integrazione nutzap, ha ricevuto un grant di rinnovo. Minibits usa eventi Nostr per memorizzare lo stato dei token ecash, rendendo i backup del wallet portabili tra dispositivi tramite sincronizzazione relay.

NostrPress: Dal Profilo Nostr al Blog Statico

NostrPress (blog.besoeasy.com) è un nuovo strumento che converte un profilo Nostr in un blog completamente statico deployabile ovunque. Chi pubblica articoli su Nostr tramite qualsiasi client può generare con NostrPress un sito web autonomo da quegli eventi, completo di hosting media locale e feed RSS.

Costruito con templating Nunjucks e JavaScript, NostrPress produce siti privi di lock-in di piattaforma. L’output generato è semplice HTML/CSS ospitabile su qualsiasi server di file statici, GitHub Pages, Netlify o un VPS personale. Lo strumento si unisce a Npub.pro e Servus come opzione per trasformare contenuti Nostr in siti web tradizionali.

Antiprimal: Gateway Conforme per il Cache di Primal

antiprimal (antiprimal.net), un nuovo progetto di Alex Gleason e del team Soapbox, è un gateway WebSocket che collega il cache server proprietario di Primal ai messaggi standard del protocollo Nostr. Primal offre funzionalità come statistiche eventi, ricerca contenuti e calcoli Web of Trust tramite wss://cache.primal.net/v1, ma accedervi richiede un formato messaggi proprietario con un campo cache non standard che i client Nostr ordinari non possono usare. Antiprimal traduce le richieste NIP standard nel formato di Primal e converte le risposte indietro.

Il gateway supporta query COUNT NIP-45 (reazioni, risposte, repost, conteggi zap, conteggi follower), ricerca NIP-50, informazioni relay NIP-11 e NIP-85 Trusted Assertions per i dati Web of Trust precalcolati di Primal. Un bot companion pubblica eventi NIP-85 kind 30382 (statistiche utente) e kind 30383 (engagement eventi) su relay configurabili. Il progetto è costruito con TypeScript su Bun e usa la libreria Nostrify. Creato il 6 febbraio, ha 53 commit nei suoi primi tre giorni di sviluppo ed è live su antiprimal.net.

Ikaros: Gateway di Messaggistica per Agenti AI su Signal e Nostr

Ikaros, un nuovo progetto del team Soapbox, è un gateway di messaggistica che permette ad agenti AI di comunicare attraverso DM crittografati sia su Signal che su Nostr. Il bridge usa l’Agent Client Protocol (ACP) per connettere qualsiasi assistente AI di coding compatibile ACP a reti di messaggistica reali. Tre pull request costituiscono la build iniziale del progetto.

La PR #1 implementa un adattatore completo per DM crittografati NIP-04 con supporto invio/ricezione, buffering delle risposte con flush esplicito al completamento, formati chiave privata nsec e hex, pubblicazione multi-relay con riconnessione automatica e un wizard di setup interattivo. L’adattatore usa nostr-tools v2.23.0 e aggiorna l’ACP SDK a v0.14.1.

La PR #2 corregge un drop silenzioso di messaggi causato da una race condition nell’aggiornamento della sessione: le notifiche in arrivo prima che la sessione fosse registrata nella mappa venivano perse, e il fix mette in buffer quelle notifiche per il replay al completamento della registrazione. La PR #3 aggiunge metadati di nome utente/UUID e gruppo Signal alle interazioni con l’agente, così l’agente AI sa con chi sta parlando e in quale gruppo. Il progetto apre un nuovo spazio di design: agenti AI raggiungibili via DM Nostr che possono anche essere contattati da Signal, o viceversa.

Campagna di Snellimento Kind 0

vitorpamplona ha aperto una serie di PR proponendo l’estrazione sistematica di dati dagli eventi kind 0 (metadata utente) in kind di eventi dedicati. La campagna affronta un problema crescente: col passare del tempo kind 0 ha accumulato campi che la maggior parte dei client non usa, gonfiando la dimensione di ogni fetch di profilo.

La PR #2216 (unita) sposta i tag identità (tag i) da kind 0 a un nuovo kind 10011, dato che l’adozione di questi tag è stata minima. La PR #2213 propone di spostare la verifica NIP-05 a kind 10008, il che permetterebbe di avere più identificatori NIP-05 per utente e di filtrare eventi per indirizzo NIP-05. La PR #2217 propone di estrarre i campi Lightning (lud06/lud16) in un nuovo kind, evitando che tutti i profili kind 0 portino campi relativi allo zap che interessano solo ai client con integrazione Lightning.

Le proposte hanno riacceso la discussione sulla questione più ampia della struttura di kind 0, inclusa la PR #1770, la proposta di lunga data per sostituire il JSON stringificato nel contenuto kind 0 con tag strutturati.

Il Supporto Relay NIP-70 è Critico per la Sicurezza della Messaggistica Crittografata

L’implementazione White Noise del protocollo Marmot ha identificato una lacuna critica nel supporto relay per NIP-70 (Protected Events) e NIP-42 (Authentication). I test hanno rivelato che i principali relay pubblici inclusi Damus, Primal e nos.lol rifiutano i protected event con errori blocked: event marked as protected invece di avviare la challenge di autenticazione richiesta.

Questa lacuna rompe la funzionalità di sicurezza chiave: NIP-70 abilita la cancellazione sicura dei KeyPackages MLS spesi, prevenendo attacchi “harvest now, decrypt later”. In assenza di supporto relay, i protocolli di messaggistica crittografata non possono proteggere dal futuro compromesso delle chiavi. White Noise ha disabilitato NIP-70 di default in risposta, mantenendo un flag opzionale per chi usa relay compatibili.

Invito all’azione per operatori relay: Implementate il flusso di autenticazione NIP-42 completo. Quando ricevete protected event, effettuate la challenge ai client per dimostrare la proprietà, poi accettate le scritture validate. Rifiutare protected event in assenza di autenticazione rompe le garanzie di sicurezza del protocollo da cui dipendono le applicazioni di messaggistica crittografata.

Rilasci

Coracle 0.6.29

Coracle (coracle.social), il client web di hodlbod, ha rilasciato 0.6.29. Il rilascio aggiunge la visualizzazione di topics e commenti sugli highlight kind 9802. Un nuovo elemento di navigazione liste fornisce accesso rapido alle liste curate dall’utente dalla UI principale. Sotto il cofano, Coracle è stato aggiornato a una nuova versione di Welshman, la libreria Nostr condivisa che alimenta la gestione relay e la gestione eventi di Coracle. La lista relay di default è stata aggiornata, e il tracking errori Glitchtip è stato rimosso dal codebase.

Igloo Desktop v1.0.3

Igloo Desktop, l’applicazione di firma a soglia FROST e gestione chiavi, ha rilasciato v1.0.3 con esteso hardening di sicurezza. Il rilascio introduce validazione IPC, isolamento Electron e controlli relay consapevoli di SSRF per la difesa contro server-side request forgery. Un nuovo flusso di onboarding e importazione share semplifica la distribuzione delle chiavi, la pianificazione relay ora include normalizzazione e merging prioritario, e l’architettura API Electron basata su preload migliora il confine di sicurezza tra renderer e processo principale. Un sistema keep-alive per il signer mantiene la stabilità delle sessioni di firma a soglia, e i miglioramenti UX di recovery riducono l’attrito del ripristino delle chiavi.

Amber v4.1.2-pre1

Amber, il signer di eventi Android, ha rilasciato v4.1.2-pre1 correggendo la visualizzazione mancante del punteggio di fiducia relay introdotta in v4.1.1, risolvendo problemi di parsing JSON per richieste encrypt/decrypt non-Nostr, e migrando il modello account da LiveData a Flow per una gestione dello stato più prevedibile. Il rilascio passa i segreti bunker a UUID completi e aggiorna a Gradle plugin 9.

Mostro Mobile v1.1.0 e Daemon v0.16.1

Vedi la sezione Notizie sopra per la copertura completa del rilascio mobile. Sul lato server, il daemon Mostro ha rilasciato v0.16.1, aggiungendo la pubblicazione automatica dei metadata NIP-01 kind 0 all’avvio (PR #575), così il daemon annuncia la propria identità alla rete quando va online. Il rilascio corregge anche la documentazione del calcolo delle dev fee (PR #571).

Angor v0.2.5

Angor (angor.io), il protocollo di finanziamento P2P decentralizzato costruito su Bitcoin e Nostr, ha rilasciato v0.2.5 con tre PR unite. La PR #649 riprogetta la sezione gestione Fondi (V2), sostituendo il layout precedente con un’interfaccia nuova per il tracking di singoli UTXO e posizioni di investimento. La PR #651 rinnova la InvoiceView con stili pulsanti aggiornati, dialog chiudibili, un nuovo comando “Copia Indirizzo”, supporto cancellazione per il monitoraggio indirizzi, e gestione migliorata del flusso investimenti. La PR #652 aggiunge server immagini NIP-96 (spec) configurabili nelle impostazioni, permettendo di scegliere quale endpoint di upload media gestisce le immagini e la documentazione dei progetti. La v0.2.4 era stata rilasciata la settimana precedente.

Ridestr v0.2.2 e v0.2.3

Ridestr, la piattaforma di rideshare decentralizzata coperta la settimana scorsa, ha continuato l’iterazione rapida con v0.2.2 (Bridge Payment Hotfix) e v0.2.3 dopo la v0.2.0 “RoadFlare Release”. L’hotfix v0.2.2 affronta un bug dove i pagamenti bridge Cashu cross-mint cancellavano automaticamente le corse mentre il pagamento era ancora in elaborazione o sarebbe eventualmente riuscito, prevenendo la cancellazione prematura delle corse su settlement più lenti. Il rilascio corregge anche lo sfarfallio della UI e le hitbox touch rotte sul pulsante “la mia posizione”. La v0.2.3 include ulteriori bug fix. Entrambi i rilasci includono APK separati per Ridestr (app passeggero) e Drivestr (app autista).

Nostr PHP 1.9.4

Nostr PHP (nostr-php.dev), la libreria helper PHP per il protocollo Nostr, ha rilasciato 1.9.4 aggiungendo una proprietà timeout configurabile alla classe request (PR #106). La novità permette di impostare durate di timeout personalizzate per le connessioni relay e le richieste messaggi, prevenendo blocchi indefiniti quando un relay non risponde o è lento a rispondere.

Zapstore v1.0.0

Zapstore (zapstore.dev), l’app store Android permissionless costruito su Nostr, ha raggiunto la milestone della release stabile 1.0 dopo mesi di release candidate.

Il rilascio 1.0 include miglioramenti di stabilità critici: gestione dello stato del pulsante install che assicura che Delete appaia immediatamente dopo il completamento dell’installazione, messaggi di errore user-friendly con dettagli tecnici espandibili, e un pulsante “Segnala problema” che invia DM crittografati via Nostr usando chiavi effimere. Tra le novità anche un nuovo schermo aggiornamenti con polling e tracking batch, un migliore watchdog per i download bloccati, limiti di download concorrenti dinamici basati sulle prestazioni del dispositivo, sincronizzazione più frequente dei pacchetti installati e logica di confronto versioni migliorata. Il team ha corretto un problema critico con flutter_secure_storage e migliorato la gestione dei casi limite del package manager.

La milestone rappresenta la maturazione della prima piattaforma dedicata di distribuzione app di Nostr, permettendo agli sviluppatori di pubblicare applicazioni Android direttamente verso i propri utenti, aggirando il gatekeeping degli app store centralizzati.

ZSP v0.3.1

ZSP, lo strumento CLI Go del team Zapstore che sostituisce il tooling di pubblicazione precedente di Zapstore per la firma e l’upload di app Android su relay Nostr, ha rilasciato v0.3.1. ZSP gestisce l’acquisizione APK da GitHub, GitLab, Codeberg, F-Droid o file locali, poi analizza i metadata, firma eventi Nostr (tramite chiave privata, bunker NIP-46 o estensione browser NIP-07), e carica i manufatti su server Blossom. Tra le novità: modalità offline completa per il linking del keystore anche in assenza di rete, header Content-Digest sugli upload Blossom per la conformità al protocollo, rilevamento corretto degli APK arm64-v8a dai repository F-Droid, fix dei parametri query trailing di GitLab e supporto completo file .env per la configurazione.

Damus iOS 1.17

Damus, il client Nostr per iOS, è passato alla versione 1.17 (PR #3606). Il rilascio corregge un problema RelayPool dove le connessioni si chiudevano dopo il rilascio del lease effimero (PR #3605), che poteva causare il drop inatteso delle sottoscrizioni. Risolve anche un bug dove la timeline dei preferiti non mostrava eventi nel passaggio tra tab (PR #3603).

nak v0.18.3

nak, il Nostr army knife CLI, ha rilasciato v0.18.3 con tre fix di stabilità: prevenzione di un panic quando i tag AUTH challenge sono nil o troppo corti, controllo degli errori del dateparser prima di usare il valore analizzato, e gestione degli URL mint Cashu che mancano del separatore ://.

Mi: Relay Locale Basato su Browser

Mi (mi.shakespeare.wtf), la nuova MiniApp Shakespeare, è un relay locale basato su browser che archivia in IndexedDB gli eventi Nostr dell’utente. Mi recupera profili (kind 0), liste contatti (kind 3), liste relay (kind 10002) e eventi wallet dai relay connessi e li memorizza localmente, dando accesso offline ai propri dati. Costruito con React e nostr-tools 2.15.0.

Agora v1.0.2

Agora (agora.spot), piattaforma decentralizzata di attivismo e raccolta fondi del team Soapbox, ha rilasciato v1.0.2 con un APK Android disponibile per installazione diretta. Si tratta della prima menzione di Agora su Compass; la piattaforma è stata lanciata il 17 gennaio con la dichiarazione di missione: “Unisciti al movimento globale per la libertà. Invia supporto agli attivisti sul campo a livello internazionale e partecipa alle azioni locali.”

La piattaforma si centra su una mappa mondiale dove chi la usa naviga per paese, crea “azioni” geolocalizzate (proteste, campagne, organizzazione comunitaria) e le discute tramite commenti threaded. Tutti i contenuti si propagano tramite relay Nostr, quindi nessun server centrale può essere messo offline per silenziare la coordinazione. Agora supporta più lingue con parità di traduzione imposta da CI, integra server media Blossom per gli upload, e include ricerca, navigazione hashtag con toggle globale/regionale, profili utente e sistemi di reazione. Il rilascio v1.0.2 è la build Android corrente, disponibile come download APK diretto.

xonos v0.1.6

xonos, il client Nostr 3D sperimentale costruito con il motore di gioco Bevy, ha rilasciato v0.1.6. xonos renderizza eventi Nostr in un ambiente spaziale 3D con capacità text-to-speech, esplorando come i dati del protocollo sociale potrebbero funzionare al di fuori delle interfacce 2D convenzionali.

Aggiornamenti dei Progetti

Primal Android Espande l’Infrastruttura NWC

Primal Android ha unito 18 PR in settimana, continuando il lavoro NWC iniziato la settimana scorsa. La PR #883 aggiunge supporto per connessioni NWC attraverso entrambi i wallet (Spark ed esterno), e la PR #879 implementa il metodo NWC lookup_invoice per controllare lo stato dei pagamenti.

La PR #880 aggiunge audit logging request-response NWC per il debugging delle interazioni wallet. La PR #877 introduce il supporto multi-account a PrimalNwcService, permettendo a chi ha più profili di mantenere connessioni wallet separate. La PR #882 implementa la pulizia periodica dei budget hold scaduti, prevenendo che prenotazioni di pagamento stale blocchino le operazioni wallet.

Il lavoro UI include ridisegno della schermata upgrade wallet (PR #889), FAQ sull’upgrade wallet (PR #885), impostazione indirizzo Lightning durante l’onboarding (PR #888) e un fix per le transazioni zap che apparivano come pagamenti regolari per i tipi non-Lightning (PR #887).

diVine Rilascia Feed Video API-First

diVine, il client video short-form, ha unito 19 PR in settimana, spostandosi verso l’architettura API-first. La PR #1468 introduce feed video API-first, e la PR #1466 aggiunge endpoint API trending, recent e home. La PR #1433 indicizza controller video specifici per un rendering efficiente dei feed.

La gestione profili è migliorata con la PR #1440 che implementa un pattern cache-plus-fresh per la visualizzazione di altri profili, riducendo i tempi di caricamento garantendo al contempo la freschezza dei dati. Il team ha anche rilasciato fix per le notifiche (PR #1437), refactoring del flusso commenti (PR #1431) e tab swiping sulla schermata Notifiche (PR #1388).

White Noise: Unificazione Keyring e Ricerca Utenti

Il backend White Noise per il protocollo Marmot ha unito 4 PR in settimana. Due PR hanno migliorato la gestione del keyring: la PR #468 rende l’identificatore del servizio keyring configurabile tramite WhitenoiseConfig, e la PR #475 unifica l’implementazione su un singolo crate keyring-core con store nativi per piattaforma, sostituendo codice frammentato specifico per piattaforma. Separatamente, la PR #470 aggiunge funzionalità di ricerca utenti.

Marmot TS Estrae l’App Chat di Riferimento

L’SDK TypeScript di Marmot (marmot-ts) ha unito la PR #40, rimuovendo l’applicazione chat di riferimento integrata e separandola in un repository autonomo: marmots-web-chat. Il nuovo repo, creato il 6 febbraio, è un’implementazione di riferimento dell’SDK TypeScript Marmot con la propria pipeline CI, vista chat a tab e sistema di build indipendente. La separazione permette all’SDK di concentrarsi sulle funzioni di libreria mentre l’app chat itera sulla UX in modo indipendente.

Una PR aperta (#41) migra marmot-ts a ts-mls v2.0.0, portando un’API ridisegnata con oggetti contesto unificati, nuove utility di gestione messaggi (creazione eventi, lettura, deserializzazione), helper per i metadata dei key package, e supporto eventi di cancellazione.

Aggiornamenti Alby Hub

Alby Hub ha unito 5 PR in settimana. La PR #2049 aggiunge un Alby CLI all’interfaccia dell’app store. La PR #2033 corregge la gestione di dati zap invalidi nella lista transazioni, e la PR #2046 rimuove il metodo ListTransactions non utilizzato dall’interfaccia LNClient.

Notedeck Rilascia Dashboard e Agentium

Notedeck, il client Nostr cross-platform di Damus, ha unito 6 PR in settimana. La PR #1247 aggiunge un’app dashboard iniziale. La PR #1293 introduce Agentium, un ambiente di sviluppo multi-agente che trasforma l’assistente AI Dave in un sistema con due modalità AI e gestione agenti basata su scene. La PR #1276 aggiunge un compositore messaggi multilinea con keybinding stile Signal, e la PR #1278 fornisce miglioramenti delle prestazioni media. PR aperte degne di nota includono infrastruttura outbox e pianificazione Git App NIP-34.

Agora Rilascia un Importante Rinnovo della UI

Agora ha unito 7 PR in settimana insieme al rilascio v1.0.2. La PR #106 è la più grande, chiudendo 11 task UI attraverso impostazioni, modifica profilo, interazioni mappa, risultati ricerca, filtraggio commenti e gestione server Blossom. Il merge ha disabilitato i pulsanti reazione per chi non è autenticato (che prima riceveva errori silenziosi cercando di reagire ai post sulla mappa), corretto il panning della mappa sulla linea di cambio data, e aggiunto testo corrispondente in grassetto nei risultati di ricerca.

La PR #108 aggiunge conteggi commenti sotto i post del feed e nelle pagine thread. La PR #107 aggiunge retry automatico sui fallimenti di caricamento eventi con un pulsante di reload esplicito quando i tentativi si esauriscono. La PR #104 cambia la navigazione hashtag per default allo scope globale, dato che il default precedente limitato per paese spesso restituiva zero risultati.

La PR #109 aggiunge un passaggio CI che verifica la parità di traduzione tra tutte le lingue, facendo fallire la build se a qualche chiave manca un valore. La PR #110 taglia le note lunghe nei feed per preservare il ritmo di scroll, e la PR #111 corregge un problema di zoom iOS mobile quando si commentano azioni causato da font di dimensioni ridotte.

Clawstr Rilascia CLI e Pulsanti Zap Lightning

Clawstr, la piattaforma ispirata a Reddit dove agenti AI creano e gestiscono community su Nostr, ha unito 3 PR in settimana. La PR #11 sostituisce tutti i comandi manuali nak nelle definizioni skill dell’agente AI con il nuovo pacchetto @clawstr/cli (npx -y @clawstr/cli@latest), rimuovendo la costruzione manuale di eventi JSON a favore di comandi CLI e aggiungendo operazioni wallet (init, balance, zap, npc) e ricerca full-text NIP-50.

La PR #13 aggiunge la pagina di documentazione “For Humans” e un componente ProfileZapDialog. Il pulsante zap appare sulle pagine profilo quando l’utente ha un indirizzo Lightning configurato e funziona anche non autenticati, usando LNURL-pay direttamente con importi sats preimpostati e visualizzazione codice QR. La PR #12 documenta il comando wallet sync, spiegando come i pagamenti verso indirizzi Lightning vengono trattenuti da NPC fino a che i rispettivi agenti sincronizzano esplicitamente i wallet.

Aggiornamenti NIP

Modifiche recenti al repository NIPs:

Uniti:

NIP-45: Risposta Relay HyperLogLog - NIP-45 (Event Counting) ora supporta il conteggio approssimativo HyperLogLog (HLL). I relay possono restituire valori registro HLL da 256 byte insieme alle risposte COUNT. I client uniscono questi registri da più relay per calcolare la cardinalità approssimativa evitando di scaricare set completi di eventi. Il caso d’uso principale: conteggi follower e reazioni indipendenti da un singolo relay come fonte autoritativa. Anche solo due eventi reazione consumano più banda del payload HLL da 256 byte. I client possono applicare le correzioni HyperLogLog++ per migliorare l’accuratezza su cardinalità ridotte.
NIP-39: Tag Identità Spostati da Kind 0 - I tag di claim identità NIP-39 (tag i) sono stati estratti dagli eventi metadata kind 0 a un nuovo kind dedicato 10011. La motivazione: quasi nessun client supporta questi tag, quindi aggiungono dimensione a ogni fetch kind 0 senza valore reale. Si tratta della prima di un ciclo di PR di estrazione kind 0 di vitorpamplona (vedi sezione Notizie).

PR Aperte e Discussioni:

NIP-XX: Nostr Relay Connect (NRC) - woikos propone un protocollo per accedere ai relay Nostr attraverso tunneling crittografato tramite un relay rendezvous pubblico. Il meccanismo abilita l’accesso a relay dietro NAT o firewall, inclusi relay personali in esecuzione su home server o dispositivi mobili. Il tunneling usa eventi kind 24891/24892 con crittografia NIP-44 attraverso un relay rendezvous che non può decrittare il traffico. Applicazione pratica: qualsiasi client Nostr può esporre lo storage locale (IndexedDB, SQLite) come endpoint relay per la sincronizzazione cross-device. La semantica standard NIP-01 (REQ, EVENT, CLOSE, COUNT) passa attraverso il tunnel in modo trasparente. Implementazioni di riferimento esistono in Go (ORLY Relay) e TypeScript (Smesh).
Nostr Web Tokens (NWT) - pippellia-btc propone Nostr Web Tokens, un formato evento Nostr per trasmettere claim firmati tra parti web, ispirato ai JSON Web Tokens (JWT). NWT può rappresentare sia NIP-98 (HTTP Auth) che eventi di autorizzazione Blossom, dando ai client flessibilità su come e quanto a lungo i token rimangono validi. Sono disponibili la libreria Go di riferimento, la spiegazione video e il confronto dettagliato con NIP-98 e Blossom Auth.
Semplificazione NIP-47 - rolznz propone di rimuovere i metodi multi_ da NIP-47 (Nostr Wallet Connect), complessi da implementare e privi di adozione. La PR riduce anche la duplicazione nella gestione crittografia e retrocompatibilità, ripulendo la spec dopo l’aggiunta hold invoice della settimana scorsa.
NIP-05: Spostamento in un Kind Evento Proprio - vitorpamplona propone di spostare la verifica NIP-05 da kind 0 a un nuovo kind 10008, abilitando più identificatori NIP-05 per utente e il filtraggio per indirizzo NIP-05. Parte della campagna di snellimento kind 0.
NIP-57: Indirizzi Lightning da Kind 0 - vitorpamplona propone di estrarre lud06/lud16 (indirizzi Lightning) da kind 0 a un kind evento dedicato per NIP-57, continuando lo sforzo di snellimento kind 0.
Iperpersonalizzazione Profilo - fiatjaf propone capacità estese di personalizzazione profilo oltre a quanto kind 0 supporta attualmente.

NIP Deep Dive: NIP-45 (Event Counting) e HyperLogLog

NIP-45 (spec) definisce come i client possono chiedere ai relay di contare eventi corrispondenti a un filtro evitando di trasferire gli eventi stessi. Il merge del supporto HyperLogLog aggiunge una struttura dati probabilistica che risolve un problema fondamentale: come contare cose attraverso più relay indipendenti.

Il Problema:

Contare eventi su un singolo relay è semplice: invia una richiesta COUNT, ottieni un numero indietro. Contare attraverso la rete è più difficile. Se il relay A riporta 50 reazioni e il relay B ne riporta 40, il totale non è 90 perché molti eventi esistono su entrambi i relay. Non è possibile calcolare il conteggio reale in assenza del download completo per deduplicare.

HyperLogLog:

HyperLogLog (HLL) è un algoritmo probabilistico che stima il numero di elementi distinti in un insieme usando un quantitativo fisso di memoria. L’implementazione NIP-45 usa 256 registri di un byte ciascuno, consumando esattamente 256 byte indipendentemente dal numero di eventi contati. L’algoritmo funziona esaminando la rappresentazione binaria di ciascun ID evento e tracciando la posizione degli zeri iniziali. ID evento che iniziano con molti zeri sono statisticamente rari, e la loro occorrenza indica un insieme grande.

Come Funziona in NIP-45:

Un relay che risponde a una richiesta COUNT può includere un campo hll contenente valori registro codificati in base64:

["COUNT", "<subscription_id>", {"count": 4527, "hll": "<base64 encoded 256 bytes>"}]

Il client raccoglie i valori HLL da più relay e li unisce prendendo il valore massimo a ciascuna posizione registro. L’HLL unito rappresenta l’unione di tutti gli insiemi di eventi attraverso i relay, gestendo automaticamente la deduplicazione. La stima finale di cardinalità viene calcolata dai registri uniti.

Accuratezza:

Con 256 registri, l’errore standard è di circa il 5,2%. Per un conteggio reale di 1.000, la stima cadrà tipicamente tra 948 e 1.052. Per conteggi più grandi, l’errore relativo rimane costante: un conteggio reale di 100.000 verrà stimato in circa 94.800-105.200. Le correzioni HyperLogLog++ migliorano l’accuratezza per cardinalità ridotte (sotto ~200), dove l’algoritmo base tende a sovrastimare.

Perché è Importante:

Le metriche social (conteggi follower, conteggi reazioni, conteggi repost) sono tra le funzionalità core dei client social media. In assenza di HLL, i client devono interrogare un singolo relay “fidato” (centralizzando il conteggio) o scaricare tutti gli eventi da tutti i relay (sprecando banda). HLL permette ai client di ottenere un buon conteggio approssimativo da più relay con un overhead totale di 256 byte per relay, indipendentemente dal conteggio effettivo. Anche solo due eventi reazione consumano più banda di un payload HLL completo.

La spec fissa il numero di registri a 256 per l’interoperabilità. Tutti i relay producono valori HLL che i client possono unire, indipendentemente da quale implementazione relay usano. I client possono implementare il supporto HLL una volta e beneficiare di ogni relay che lo supporta.

Stato Attuale:

La PR è stata aperta da fiatjaf ed era in discussione da diversi mesi prima del merge avvenuto in settimana. Le implementazioni relay dovranno aggiungere il calcolo HLL ai loro handler COUNT. Le implementazioni client dovranno aggiungere il merging HLL alla propria logica di aggregazione conteggi.

NIP Deep Dive: NIP-96 (HTTP File Storage) e la Transizione a Blossom

NIP-96 (spec) definiva come i client Nostr caricavano, scaricavano e gestivano file su server media HTTP. Ora contrassegnato come “non raccomandato” a favore di Blossom (hosting media basato su BUD), NIP-96 resta rilevante in settimana perché Angor v0.2.5 ha aggiunto la configurazione server NIP-96 e ZSP v0.3.1 carica su server Blossom, illustrando la transizione di protocollo in corso.

Come Funziona NIP-96:

Un client scopre le capacità di un file server recuperando /.well-known/nostr/nip96.json, che restituisce l’URL API, i tipi di contenuto supportati, i limiti di dimensione e le trasformazioni media disponibili:

{
 "api_url": "https://file-server.example/api",
 "download_url": "https://cdn.example/files",
 "content_types": ["image/jpeg", "video/webm", "audio/*"],
 "plans": {
 "free": {
 "is_nip98_required": true,
 "max_byte_size": 10485760,
 "media_transformations": {
 "image": ["resizing"]
 }
 }
 }
}

Per caricare, il client invia un POST multipart/form-data all’URL API con un header di autorizzazione NIP-98 (un evento Nostr firmato che prova l’identità di chi carica). Il server restituisce una struttura metadata file NIP-94 contenente l’URL del file, i hash SHA-256 originali e trasformati, il tipo MIME e le dimensioni:

{
 "status": "success",
 "nip94_event": {
 "tags": [
 ["url", "https://cdn.example/files/<hash>.png"],
 ["ox", "<original-file-hash>"],
 ["x", "<transformed-file-hash>"],
 ["m", "image/png"],
 ["dim", "800x600"]
 ]
 }
}

I download usano richieste GET a <api_url>/<sha256-hash>, con parametri query opzionali per trasformazioni server-side come il ridimensionamento immagini (?w=320). La cancellazione usa DELETE con auth NIP-98, e solo chi ha caricato il file originale può cancellare i propri file. Un endpoint di elenco file restituisce risultati paginati dei caricamenti di un utente.

Chi pubblica eventi kind 10096 dichiara i propri server di upload preferiti, permettendo ai client di selezionare automaticamente il server giusto in assenza di configurazione manuale.

Perché È Stato Deprecato:

NIP-96 legava gli URL dei file a server specifici. Se files.example.com andava giù, ogni nota Nostr che referenziava quegli URL perdeva i suoi media. Il server era l’indirizzo, e l’indirizzo era fragile.

Blossom (Blobs Stored Simply on Mediaservers) inverte il modello rendendo l’hash SHA-256 del contenuto del file l’identificatore canonico. Un URL Blossom ha la forma https://blossom.example/<sha256>.png, ma qualsiasi server Blossom che ospita lo stesso file lo serve allo stesso percorso hash. Se un server scompare, i client interrogano un altro server per lo stesso hash. L’indirizzamento basato sul contenuto rende i dati portabili tra server di default.

Blossom semplifica anche l’API. NIP-96 usava upload multipart form con risposte JSON, policy di trasformazione e un endpoint di discovery. Blossom usa semplice PUT per gli upload, GET per i download, ed eventi Nostr firmati (non header HTTP) per l’autorizzazione. La specifica Blossom è divisa in documenti modulari: BUD-01 copre il protocollo server, l’autorizzazione e il recupero, BUD-02 copre l’upload blob, BUD-03 copre i server utente, e BUD-04 copre il mirroring tra server.

La deprecazione è avvenuta a settembre 2025 tramite PR #2047, che ha contrassegnato NIP-96 come “non raccomandato” nell’indice NIPs.

La Transizione in Pratica:

Server come nostr.build e void.cat supportavano NIP-96 e hanno aggiunto o migrato a endpoint Blossom. I client sono a vari stadi: il rilascio v0.2.5 di Angor in settimana ha aggiunto la configurazione server NIP-96 per le immagini dei progetti, mentre il rilascio v0.3.1 di ZSP carica artefatti esclusivamente su server Blossom con header Content-Digest per la conformità al protocollo. Amethyst e Primal supportano gli upload Blossom. La coesistenza probabilmente continuerà fino a quando le rimanenti implementazioni NIP-96 completeranno la propria migrazione.

Cosa Viene Preservato:

I preference event kind 10096 rimangono utili per la selezione server Blossom. I metadata file NIP-94 (eventi kind 1063) descrivono ancora le proprietà dei file indipendentemente da quale protocollo di upload li ha creati. L’hashing SHA-256 che NIP-96 usava per gli URL di download è diventato la base dell’indirizzamento basato sul contenuto di Blossom. Il design di NIP-96 ha informato ciò che Blossom ha semplificato: la lezione è stata che l’hosting media su rete decentralizzata richiede storage indirizzato per contenuto per corrispondere alla resistenza alla censura del livello relay.

È tutto per questa settimana. Stai costruendo qualcosa? Hai notizie da condividere? Vuoi che copriamo il tuo progetto? Contattaci via DM NIP-17 o trovaci su Nostr.

Nostr Compass #8

Wed, 04 Feb 2026 00:00:00 +0000

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

Questa settimana: rust-nostr rilascia una importante riprogettazione dell’API con 21 PR che rivedono l’architettura dell’SDK. Nostria 3.0 viene lanciato con navigazione a doppio pannello, gestione liste e una completa revisione dell’UI. Vector aggiunge accelerazione SIMD raggiungendo speedup di 65x-184x e rilascia supporto per il protocollo Marmot per la messaggistica di gruppo crittografata. Frostr porta la firma a soglia su iOS tramite TestFlight. Damus implementa i suggerimenti relay NIP-19 (Entità Codificate Bech32) per la scoperta di contenuti cross-relay. Primal Android aggiunge crittografia NWC e esportazione transazioni wallet. nostr-tools e NDK ricevono miglioramenti di affidabilità. NIP-82 (Applicazioni Software) si espande per coprire il 98% delle piattaforme dispositivo. Il repository NIPs unisce il supporto hold invoice per NIP-47 (Nostr Wallet Connect). Nuove proposte di protocollo includono NIP-74 per il podcasting, NIP-DB per database eventi nel browser e una suite TRUSTed Filters per la curation decentralizzata dei contenuti. Nuovi progetti includono Instagram to Nostr v2 per la migrazione dei contenuti, Pod21 che lancia un marketplace decentralizzato di stampa 3D, Clawstr che introduce community gestite da agenti AI, e Shosho e NosCall che espandono le capacità di live streaming e videochiamate.

Notizie

rust-nostr Rilascia una Importante Riprogettazione dell’API

L’SDK rust-nostr ha subito una significativa revisione dell’architettura questa settimana con 21 PR unite che introducono breaking changes attraverso la libreria. La riprogettazione riguarda le API core su cui la maggior parte degli sviluppatori Rust fa affidamento.

PR #1245 riprogetta le API di notifica, mentre PR #1244 sostituisce RelayNotification::Shutdown con RelayStatus::Shutdown per una gestione dello stato più pulita. Le API del signer ora si allineano con altri pattern dell’SDK tramite PR #1243. I metodi Client e Relay hanno ricevuto una pulizia in PR #1242, e le opzioni client ora usano un builder pattern (PR #1241).

Le API di invio messaggi sono state riprogettate in PR #1240, l’unsubscription REQ in PR #1239, e la rimozione relay in PR #1229. Una PR aperta #1246 aggiunge supporto per le API bloccanti per completare la riprogettazione.

Le modifiche portano consistenza all’SDK ma richiederanno sforzo di migrazione dai progetti esistenti. Gli sviluppatori che costruiscono su rust-nostr dovrebbero rivedere attentamente il changelog prima di aggiornare.

Instagram to Nostr v2 Abilita la Migrazione dei Contenuti

Un nuovo strumento permette ai creatori di migrare i loro contenuti esistenti dalle piattaforme centralizzate a Nostr. Instagram to Nostr v2 supporta l’importazione da Instagram, TikTok, Twitter e Substack senza richiedere accesso alle chiavi private dell’utente.

Lo strumento affronta una barriera comune all’onboarding: gli utenti esitanti a ricominciare da zero su una nuova piattaforma possono ora preservare la loro cronologia di contenuti. Supporta anche il regalare account Nostr a nuovi utenti o proporre contenuti ad account esistenti, rendendolo utile per aiutare altri nella transizione al protocollo.

Pod21: Rete di Stampa 3D Decentralizzata

Pod21 (pod21.com) connette operatori di stampanti 3D con acquirenti usando Nostr per la coordinazione del marketplace. La piattaforma include un bot DM compatibile NIP-17 (Messaggi Diretti Privati) che gestisce le interazioni del marketplace, permettendo agli acquirenti di richiedere stampe e negoziare con i maker attraverso messaggi diretti crittografati.

I maker elencano la loro capacità e competenze di stampa; gli acquirenti sfogliano le inserzioni e avviano ordini tramite il bot. L’architettura segue un pattern simile ad altre applicazioni commerciali Nostr: scoperta basata su relay, messaggistica crittografata per la coordinazione degli ordini, e Lightning per il settlement. Pod21 si unisce a Ridestr e Shopstr come applicazioni Nostr che coordinano transazioni nel mondo reale attraverso il protocollo.

Clawstr si lancia come piattaforma ispirata a Reddit dove agenti AI creano e gestiscono community su Nostr. La piattaforma permette ad agenti autonomi di stabilire community tematiche, curare contenuti e interagire con gli utenti. Le community funzionano come subreddit ma con moderatori e curatori AI che guidano le discussioni. L’architettura usa il protocollo aperto di Nostr per interazioni agente-agente e agente-umano, stabilendo un nuovo modello per la formazione di community sui social media decentralizzati.

Rilasci

Ridestr v0.2.0: RoadFlare Release

Ridestr ha rilasciato v0.2.0, denominato “RoadFlare Release”, introducendo reti personali di rideshare. La funzionalità permette ai passeggeri di aggiungere autisti preferiti a una rete fidata. Gli autisti approvano i follower e condividono posizioni crittografate, permettendo ai passeggeri di vedere quando autisti fidati sono online e nelle vicinanze. Le richieste di corsa vanno direttamente agli autisti conosciuti.

L’affidabilità dei pagamenti è migliorata con recupero automatico dell’escrow, migliore sincronizzazione wallet tra dispositivi e elaborazione pagamenti più veloce tramite polling progressivo. PR #37 aggiunge l’infrastruttura Fase 5-6 che supporta queste funzionalità. v0.2.1 ha seguito con hotfix per bug della dialog di pagamento e il flusso “Aggiungi ai Preferiti” post-corsa.

Nostria 3.0

Nostria, il client cross-platform di sondreb costruito per scala globale, ha rilasciato la versione 3.0 con una completa revisione dell’UI, nuovo logo e centinaia di fix. Il rilascio rappresenta un intensivo ciclo di sviluppo di sei settimane.

La navigazione a doppio pannello è il cambiamento UX più grande, permettendo agli utenti desktop di ridurre il cambio di contesto quando si spostano tra liste, dettagli e thread. Una nuova sezione Home fornisce una panoramica di tutte le funzionalità disponibili, e tutti gli schermi condividono toolbar, layout e funzionalità unificati.

La gestione delle liste è l’aggiornamento funzionale più significativo, integrato in tutta l’applicazione. Gli utenti possono gestire liste di profili e filtrare contenuti in qualsiasi funzionalità: Stream, Musica o Feed. Stanchi dello spam nei thread? Filtra per preferiti per vedere solo le loro risposte. Quick Zaps aggiunge zapping con un tap con valori configurabili. Copia/Screenshot genera screenshot per la clipboard per condividere eventi ovunque. Parole Silenziate ora filtra sui campi del profilo (name, display_name, NIP-05), permettendo agli utenti di bloccare tutti i profili bridged con una singola parola bannata. Le Impostazioni sono diventate ricercabili per modifiche di configurazione più veloci.

Il rilascio aggiunge rendering delle richieste di pagamento BOLT11 e BOLT12, selezione dimensione testo e font, e messaggistica “Nota-a-Te-Stesso” nella sezione Messaggi con rendering di contenuti referenziati come articoli ed eventi. La nuova dialog Condividi permette condivisione rapida via email, siti web o messaggi diretti a più destinatari. Funzionalità aggiuntive includono set di emoji personalizzati, Interessi (liste hashtag come feed dinamici), Segnalibri, Feed Relay Pubblici e personalizzazione completa del menu inclusa quale opzione apre l’icona Nostria.

Disponibile su Android, iOS, Windows e web su nostria.app.

Applesauce v5.1.0

La suite di librerie Applesauce di hzrd149 ha rilasciato v5.1.0 su tutti i pacchetti. applesauce-signers aggiunge supporto per i metodi switch_relays e ping sui signer remoti Nostr Connect, utili per gestire le connessioni signer programmaticamente. applesauce-loaders introduce loadAsyncMap per caricamento asincrono parallelo. applesauce-react aggiunge argomenti padding a useAction().run(). applesauce-core aggiorna il mapping event-to-store per gestire stringhe direttamente senza richiedere onlyEvents.

nak v0.18.3

Il nak (Nostr Army Knife) di fiatjaf ha raggiunto v0.18.3 con fix di stabilità da mattn. Il rilascio previene panic quando gli URL mint mancano del separatore ://, valida gli errori del dateparser prima di usare i valori data e gestisce casi limite nel parsing dei tag AUTH challenge. Questi fix difensivi rendono la CLI più resiliente quando elabora input malformati.

Aegis v0.3.7

Aegis, il signer desktop cross-platform, ha rilasciato v0.3.7 aggiungendo supporto Nostr App Browser con firma NIP-07 (Interfaccia Estensione Browser). Il rilascio registra eventi di crittografia NIP-04 (Messaggi Diretti Crittografati) e NIP-44 (Crittografia Versionata), permettendo agli utenti di tracciare quali applicazioni richiedono operazioni di crittografia. Il segmento browser ora filtra per piattaforma per mostrare solo app web.

Bitchat v1.5.1 (iOS)

Bitchat, l’app di messaggistica offline-capable che usa Nostr e mesh Bluetooth, ha rilasciato v1.5.1 con hardening di sicurezza iOS. PR #1012 valida le firme degli eventi Nostr prima dell’elaborazione, rifiuta giftwrap e pacchetti embedded invalidi, limita i payload sovradimensionati e blocca gli ID mittente BLE announce spoofati. PR #998 corregge l’autenticazione mesh BLE iOS legando gli ID mittente agli UUID di connessione, prevenendo lo spoofing di identità nella rete mesh. PR #972 aggiunge rate limiting delle notifiche per prevenire flood di peer discovery quando più dispositivi mesh sono nelle vicinanze.

KeyChat v1.39.2

KeyChat ha rilasciato v1.39.2 aggiungendo supporto NIP-47 Nostr Wallet Connect tramite PR #148. Gli utenti possono ora connettere wallet Lightning esterni per i pagamenti all’interno dell’app di messaggistica. Il rilascio aggiunge anche notifiche desktop macOS.

Nostrmo v3.5.0

Nostrmo, il client Flutter cross-platform, ha rilasciato v3.5.0 rivedendo il suo sistema di feed. L’aggiornamento sostituisce i feed fissi con alternative personalizzabili: Feed Generale, Feed Menzioni e Feed Relay, ciascuno configurabile attraverso nuove pagine di modifica. Il rilascio implementa supporto per il modello outbox per un migliore routing degli eventi ed espande la funzionalità relay locale con limiti di dimensione configurabili e supporto sottoscrizioni.

Shosho v0.11.1

Shosho, l’app di live streaming per Nostr, ha rilasciato v0.11.1 con capacità di registrazione e VOD. L’aggiornamento aggiunge indicatori di presenza nella stanza che mostrano chi sta guardando gli stream, conversazioni chat threaded per una migliore organizzazione delle discussioni e supporto Nostr Connect su iOS tramite NIP-46. Gli streamer possono ora salvare le loro trasmissioni per la visione successiva mantenendo interazioni chat in tempo reale con il loro pubblico.

NosCall v0.5.0

NosCall, l’app per chiamate audio e video per Nostr, ha rilasciato v0.5.0 con gruppi di contatti per organizzare le chiamate per categoria, gestione relay per l’ottimizzazione delle connessioni e impostazioni server ICE configurabili per una migliore traversal NAT. Il rilascio aggiunge anche supporto per la modalità scura. NosCall usa Nostr per il signaling e la coordinazione delle chiamate, abilitando chiamate peer-to-peer senza server centralizzati.

diVine 1.0.4

diVine, il client video short-form looping di rabble, ha rilasciato 1.0.4 come pre-release alpha Android prima della sua sottomissione a Zapstore. Il rilascio si concentra sul test della gestione delle chiavi Nostr, incluso import nsec, firma remota NIP-46 (Nostr Connect) con nsecBunker e Amber, e gestione URL nostrconnect://. Il team sta sollecitando feedback sulla compatibilità relay e l’interoperabilità video con altri client. PR #1265 corregge la gestione dei percorsi file iOS che causava l’inutilizzabilità dei clip video dopo gli aggiornamenti dell’app memorizzando percorsi relativi invece di percorsi container assoluti. PR #1251 corregge problemi di navigazione quando si visualizzano profili dai commenti.

Zeus v0.12.2

Zeus ha rilasciato v0.12.2 come rilascio stabile, consolidando i fix NWC coperti nelle edizioni precedenti.

Frostr Igloo iOS TestFlight

Frostr (frostr.org) ha lanciato Igloo per iOS su TestFlight, espandendo la firma a soglia ai dispositivi Apple. Frostr usa firme FROST (Flexible Round-Optimized Schnorr Threshold) per dividere le chiavi nsec in quote distribuite tra dispositivi, abilitando firma k-di-n con tolleranza ai guasti. Gli utenti che si uniscono in “demo mode” partecipano a un esperimento live di firma a soglia 2-di-2, dimostrando le capacità di coordinazione in tempo reale del protocollo. Il rilascio iOS si unisce a Igloo per Android (v0.1.2), rilasciato a dicembre con supporto NIP-55 (Android Signer) per richieste di firma cross-app. Entrambi i client mobile complementano Igloo desktop e l’estensione browser Frost2x.

Aggiornamenti dei Progetti

Damus Implementa Suggerimenti Relay NIP-19

Damus ha unito PR #3477, implementando il consumo di suggerimenti relay NIP-19 per il recupero degli eventi. La funzionalità permette di visualizzare note su relay non nel pool configurato dell’utente estraendo suggerimenti da riferimenti NIP-10 (Thread di Risposta), NIP-18 (Repost) e NIP-19. L’implementazione usa connessioni relay effimere con cleanup reference-counted, evitando l’espansione permanente del pool di relay.

Fix aggiuntivi includono parsing di Lightning invoice (PR #3566), caricamento vista wallet (PR #3554), timing lista relay (PR #3553) e precaricamento profili per ridurre il “popping” visivo (PR #3550). Una bozza PR #3590 mostra il supporto DM privati NIP-17 in corso.

Primal Android Rilascia Crittografia NWC

Primal Android ha avuto una settimana molto attiva con 18 PR unite focalizzate sull’infrastruttura wallet. L’app ora si integra con Spark, il protocollo Lightning self-custodial di Lightspark. PR #874 aggiunge supporto crittografia NWC, mentre PR #872 invia eventi info NWC quando le connessioni si stabiliscono.

PR #870 abilita l’export CSV per le transazioni wallet, utile per contabilità e fini fiscali. PR #716 aggiunge uno switcher account locale nell’Editor Note. Molteplici fix di ripristino wallet (PR #876, PR #875, PR #873) affrontano casi limite per utenti con configurazioni wallet non-Spark.

Marmot TypeScript SDK Aggiunge Cronologia Messaggi

L’implementazione TypeScript del protocollo Marmot continua lo sviluppo. PR #38 di hzrd149 implementa la persistenza della cronologia messaggi con paginazione per l’applicazione chat di riferimento, mentre PR #39 migliora l’ergonomia della libreria.

Sul lato Rust, PR #161 implementa gestione dello stato riprovabile per preservare il contesto dei messaggi in caso di fallimento, e PR #164 passa a std::sync::Mutex per evitare panic tokio con SQLite. Il backend whitenoise-rs aggiunge integrazione Amber (PR #418), upgrade a MDK e nostr-sdk 0.44 (PR #467), e introduce streaming notifiche in tempo reale tramite PR #460 con tipi evento NewMessage e GroupInvite.

HAVEN Aggiunge Refresh Periodico WoT

HAVEN, il relay personale, ha unito PR #108 aggiungendo refresh periodico Web of Trust. La funzionalità assicura che i punteggi di fiducia rimangano aggiornati mentre i grafi sociali degli utenti evolvono, migliorando l’accuratezza del filtraggio spam nel tempo.

nostr-tools

nostr-tools, la libreria JavaScript core, ha ricevuto molteplici miglioramenti questa settimana. I commit includono un fix per il parsing degli hashtag dopo le newline nelle menzioni NIP-27 (Riferimenti nelle Note di Testo), pruning automatico di oggetti relay rotti con tracking idle per cleanup delle connessioni, rimozione della coda messaggi per ottimizzazione delle prestazioni single-threaded, e export dei file sorgente per migliori import TypeScript.

NDK

NDK ha rilasciato beta.71 con un fix per la riconnessione dopo cicli sleep/wake del dispositivo e gestione connessioni stale, affrontando problemi di affidabilità per le applicazioni mobile.

Notedeck

Notedeck, il client desktop del team Damus, ha una PR aperta #1279 che aggiunge un visualizzatore NIP-34 (Collaborazione Git). Questo permetterebbe di sfogliare repository git, patch e issue pubblicati sui relay Nostr direttamente nel client, rendendo Notedeck un potenziale front-end per workflow basati su ngit.

njump

njump, il gateway web Nostr, ha aggiunto supporto per due tipi di evento NIP-51 (Liste) tramite PR #152. Il gateway ora renderizza Follow Sets kind:30000, che sono raggruppamenti categorizzati di utenti che i client possono visualizzare in contesti diversi, e Starter Packs kind:39089, che sono collezioni di profili curate progettate per la condivisione e il following di gruppo. Queste aggiunte permettono a njump di visualizzare liste curate dalla community quando gli utenti condividono link nevent.

Amethyst

Amethyst, il client Android, ha corretto un bug che impediva la condivisione video dalla vista player (PR #1695). L’opzione “Condividi video” non appariva perché il parametro content non veniva passato al componente pulsanti di controllo. Gli utenti possono ora condividere contenuti video Nostr ad altre app direttamente dal player. PR #1693 corregge crash di deserializzazione Jackson JSON che si verificavano durante il parsing di certi eventi malformati.

Jumble

Jumble, il client web focalizzato sul browsing dei feed relay, ha aggiunto upload di file audio tramite clipboard in PR #743. Gli utenti possono ora incollare file audio direttamente nell’editor post, che li carica sui media server configurati e incorpora l’URL nella nota. La funzionalità rispecchia la funzionalità esistente di incolla immagini.

Flotilla

Flotilla, il client community NIP-29 (Gruppi Basati su Relay) di hodlbod, ha rilasciato notifiche tramite PR #270. L’aggiornamento rifà il sistema di alert da polling basato su anchor a notifiche pull locali per web e notifiche push per mobile. L’architettura implementa lo standard proposto NIP-9a (vedi PR #2194 sotto), dove gli utenti registrano callback webhook con i relay e ricevono payload evento crittografati quando i filtri corrispondono.

Formstr

Formstr, l’applicazione form nativa Nostr, ha aggiunto import form e supporto form crittografati in PR #422. Gli utenti possono ora importare form esistenti tramite un link di risposta o altre istanze Formstr. La funzionalità di crittografia permette ai creatori di form di restringere le risposte in modo che solo i destinatari designati possano leggere le sottomissioni, utile per sondaggi che raccolgono informazioni sensibili.

Pollerama

Pollerama (pollerama.fun), costruito su nostr-tools, ha aggiunto condivisione DM NIP-17 per i sondaggi tramite PR #141 e PR #142. Gli utenti possono ora condividere sondaggi direttamente ai contatti attraverso messaggi diretti crittografati.

Nostrability Schemata

Nostrability schemata, la collezione di schema di verifica JSON per eventi Nostr, ha aggiunto copertura NIP-59 (Gift Wrap) tramite PR #59. L’aggiornamento include schema per eventi kind 13 (seal) e kind 1059 (gift wrap), complementando la copertura schema NIP-17 esistente.

Vector

Vector, il messenger desktop privacy-focused che usa NIP-17, NIP-44 e NIP-59 per crittografia zero-metadata, ha unito PR #39 introducendo ottimizzazioni di prestazioni accelerate SIMD. La codifica hex gira 65x più veloce, la generazione preview immagini fino a 38x più veloce, e le ricerche messaggi 184x più veloci tramite indicizzazione binary search. La PR aggiunge intrinsics ARM64 NEON per Apple Silicon e x86_64 AVX2/SSE2 con rilevamento runtime per Windows e Linux. L’uso di memoria è calato con struct messaggi ridotte da 472 a 128 byte e storage npub tagliato del 99.6% attraverso interning.

Vector v0.3.0 (Dicembre 2025) ha integrato MDK (Marmot Development Kit) per messaggistica di gruppo basata su protocollo MLS, portando gruppi crittografati end-to-end con forward secrecy al client. La condivisione file MIP-04 ora gestisce attachment imeta per gruppi MLS, progettata per interoperabilità con White Noise. Il rilascio ha anche introdotto una piattaforma Mini Apps con giochi multiplayer P2P basati su WebXDC, un app store decentralizzato chiamato The Nexus, integrazione wallet PIVX per pagamenti in-app, editing messaggi con tracking completo della cronologia e riduzione memoria 4x durante gli upload di immagini.

Aggiornamenti NIP

Modifiche recenti al repository NIPs:

Uniti:

NIP-47: Supporto Hold Invoice - NIP-47 (Nostr Wallet Connect) ora supporta hold invoice, abilitando workflow di pagamento avanzati dove i riceventi devono esplicitamente settlare o cancellare i pagamenti. La PR aggiunge tre nuovi metodi RPC: make_hold_invoice crea un hold invoice usando preimage e payment hash pre-generati, settle_hold_invoice reclama il pagamento fornendo la preimage originale, e cancel_hold_invoice rifiuta il pagamento usando il suo payment hash. Una nuova notifica hold_invoice_accepted scatta quando un pagante blocca il pagamento. Questo abilita casi d’uso come pay-to-unlock content, sistemi escrow marketplace e payment gating. Le implementazioni sono già in corso in Alby Hub, Alby JS-SDK e dart NDK.
NIP-05: Requisito Minuscole - NIP-05 (Verifica del Dominio) ora richiede esplicitamente minuscole sia per le chiavi pubbliche esadecimali che per i nomi locali nel file nostr.json. Questo era implicito nella spec ma non dichiarato, causando problemi di interoperabilità quando alcune implementazioni usavano case misto mentre altre normalizzavano a minuscole. I client che validano identificatori NIP-05 dovrebbero ora rifiutare qualsiasi risposta nostr.json contenente caratteri maiuscoli in chiavi o nomi.
NIP-73: Codici Paese - NIP-73 (Geotag) ora supporta codici paese ISO 3166 come alternativa ai geohash. Gli eventi possono includere tag ["g", "US", "countryCode"] per indicare posizione a livello paese senza richiedere coordinate precise. Questo abilita filtraggio e scoperta contenuti basati sul paese per applicazioni dove la posizione esatta è non necessaria o indesiderata. La PR ha anche aggiunto un esempio geohash mancante alla documentazione spec.

PR Aperte e Discussioni:

NIP-82: Applicazioni Software - franzap ha annunciato un importante aggiornamento a questa specifica bozza, che definisce come le applicazioni software vengono distribuite via Nostr usando eventi release kind 30063. L’aggiornamento ora copre approssimativamente il 98% delle piattaforme dispositivo globalmente, incluso macOS, Linux, Windows, FreeBSD, ambienti WASM, estensioni VS Code, estensioni Chrome e Web Bundles/PWA. Il team si sta concentrando poi su Android, PWA e supporto iOS, invitando gli sviluppatori a convergere su questo standard condiviso. Zapstore pianifica di migrare al nuovo formato nelle prossime settimane.
NIP-74: Podcast - Definisce eventi addressable per show podcast (kind 30074) ed episodi (kind 30075). Gli show includono metadati come titolo, descrizione, categorie e immagini copertina. Gli episodi referenziano il loro show genitore e includono URL enclosure, durate e marcatori capitoli. La spec si integra con gli standard metadati Podcasting 2.0 e include tag value per monetizzazione V4V (value-for-value) via Lightning. Piattaforme come transmit.fm, una piattaforma di pubblicazione podcast nativa Nostr, possono pubblicare direttamente sui relay usando questo formato, permettendo ai podcaster di distribuire contenuti senza intermediari.
NIP-FR: Note Solo-Amici - Propone un meccanismo per pubblicare note visibili solo a una lista di amici definita dall’utente usando una chiave simmetrica condivisa chiamata ViewKey. L’autore crittografa le note (kind 2044) con il ViewKey usando NIP-44. Il ViewKey stesso viene distribuito a ciascun amico una sola volta tramite NIP-59 (Gift Wrap). Gli amici che possiedono il ViewKey possono decifrare e leggere le note; tutti gli altri vedono solo testo cifrato. Quando l’autore rimuove un amico, il ViewKey viene ruotato: una nuova chiave viene generata e ridistribuita a tutti gli amici rimanenti tramite gift wrap, assicurando che l’amico rimosso perda l’accesso ai post futuri. Questo approccio separa la crittografia del contenuto (simmetrica, efficiente) dalla distribuzione delle chiavi (asimmetrica, per-amico), mantenendo il protocollo leggero abilitando una funzionalità privacy frequentemente richiesta.
NIP-DB: Interfaccia Database Eventi Nostr nel Browser (spec) - Propone un’interfaccia standard window.nostrdb per estensioni browser che forniscono storage eventi Nostr locale. L’API include metodi per aggiungere eventi, query per ID o filtro, conteggio match e sottoscrizione agli aggiornamenti. Le applicazioni web possono usare questa interfaccia per leggere da eventi cached localmente senza fare richieste relay, riducendo banda e latenza. L’estensione browser nostr-bucket di hzrd149 fornisce un’implementazione di riferimento, iniettando l’interfaccia in tutti i tab del browser. Una libreria polyfill complementare implementa la stessa API usando IndexedDB per ambienti senza l’estensione.
TRUSTed Filters - Una suite di cinque proposte correlate per la curation decentralizzata dei contenuti, costruendo sulla PR #1534 Trusted Assertions unita di vitorpamplona. La specifica core introduce eventi kind 17570 per dichiarare Trust Provider Preferences, permettendo agli utenti di specificare quali servizi fidano per filtraggio e ranking degli eventi. I trust provider pubblicano assertions (kind 37571), statistiche (kind 37572) e rankings (kind 37573) a cui i client possono sottoscriversi. Il sistema usa un’architettura plugin con tag W/w per specificare tipi di filtro e trasformazioni. Questo permette a operazioni computazionalmente costose come spam detection, reputation scoring e content ranking di girare su infrastruttura dedicata mentre gli utenti mantengono controllo su quali provider fidano. La suite include spec separate per filter presets, user rankings, trusted events e definizioni plugin.
NIP-9a: Notifiche Push - hodlbod propone uno standard per notifiche push basate su relay usando eventi registrazione kind 30390. Gli utenti creano una registrazione contenente filtri per eventi che vogliono ricevere e un URL callback webhook. La registrazione è crittografata alla pubkey del relay (dal suo campo self NIP-11). Quando si verificano eventi corrispondenti, i relay POSTano al callback con l’ID evento (plaintext per deduplicazione) e l’evento stesso (crittografato NIP-44 all’utente). Questa architettura permette ai relay di pushare notifiche proteggendo il contenuto degli eventi dai server push intermediari. La PR #270 di Flotilla implementa questo standard.
Catallax - Propone un protocollo decentralizzato per lavoro a contratto con escrow usando eventi kind 33400. Il sistema definisce tre ruoli: gli arbiter annunciano disponibilità e termini, i patron creano task finanziati con Bitcoin in escrow, e i free agent completano lavoro per reclamare il pagamento. Gli arbiter risolvono le dispute quando necessario. Il protocollo abilita coordinazione di lavoro freelance trustless dove i fondi sono bloccati fino a che i deliverable sono accettati o l’arbitrato conclude.

NIP Deep Dive: NIP-47 (Nostr Wallet Connect)

NIP-47 definisce Nostr Wallet Connect (NWC), un protocollo per il controllo remoto di wallet Lightning usando Nostr come layer di comunicazione. Con l’aggiunta del supporto hold invoice di questa settimana, NWC ora copre l’intera gamma di operazioni Lightning.

Il protocollo funziona attraverso uno scambio semplice. Un’applicazione wallet pubblica un evento “wallet info” (kind 13194) che descrive le sue capacità. Le applicazioni client inviano richieste crittografate (kind 23194) chiedendo al wallet di eseguire operazioni come pagare invoice, creare invoice o controllare saldi. Il wallet risponde con risultati crittografati (kind 23195).

NWC usa crittografia NIP-44 tra client e wallet, con una keypair dedicata per le operazioni wallet, mantenendola separata dall’identità principale dell’utente. Questa separazione significa che compromettere una connessione NWC non espone l’identità Nostr dell’utente.

Metodi Supportati:

La spec definisce metodi per operazioni Lightning core: pay_invoice invia pagamenti, make_invoice genera invoice per ricevere, lookup_invoice controlla lo stato del pagamento, get_balance restituisce il saldo wallet, e list_transactions fornisce la cronologia pagamenti. I nuovi pay_keysend appena uniti abilitano pagamenti senza invoice, e hold_invoice supporta pagamenti condizionali.

Eventi di Esempio:

Il servizio wallet pubblica un evento info (kind 13194) pubblicizzando le sue capacità:

{
 "kind": 13194,
 "pubkey": "<pubkey servizio wallet>",
 "content": "pay_invoice get_balance make_invoice lookup_invoice list_transactions notifications",
 "tags": [
 ["encryption", "nip44_v2"],
 ["notifications", "payment_received payment_sent"]
 ],
 "created_at": "<timestamp unix>",
 "id": "<hash evento>",
 "sig": "<firma servizio wallet>"
}

Un client invia una richiesta crittografata (kind 23194) per pagare un invoice:

{
 "kind": 23194,
 "pubkey": "<pubkey effimera client dall'URI connection secret>",
 "content": "<NIP-44 crittografato: {\"method\": \"pay_invoice\", \"params\": {\"invoice\": \"lnbc50n1...\"}}>",
 "tags": [
 ["p", "<pubkey servizio wallet>"],
 ["encryption", "nip44_v2"]
 ],
 "created_at": "<timestamp unix>",
 "id": "<hash evento>",
 "sig": "<firma chiave effimera client>"
}

Il servizio wallet risponde (kind 23195) con il risultato del pagamento:

{
 "kind": 23195,
 "pubkey": "<pubkey servizio wallet>",
 "content": "<NIP-44 crittografato: {\"result_type\": \"pay_invoice\", \"result\": {\"preimage\": \"...\"}, \"error\": null}>",
 "tags": [
 ["p", "<pubkey effimera client>"],
 ["e", "<id evento richiesta>"]
 ],
 "created_at": "<timestamp unix>",
 "id": "<hash evento>",
 "sig": "<firma servizio wallet>"
}

Il tag e nella risposta referenzia la richiesta originale, permettendo ai client di abbinare le risposte alle loro richieste.

Hold Invoice:

La PR #1913 di questa settimana ha aggiunto supporto hold invoice, abilitando pagamenti stile escrow. A differenza degli invoice standard dove il ricevente reclama immediatamente il pagamento rilasciando la preimage, gli hold invoice permettono al ricevente di differire questa decisione. Quando un pagante invia a un hold invoice, i fondi si bloccano lungo il percorso di pagamento. Il ricevente poi sceglie se settlare (rilasciare la preimage e reclamare i fondi) o cancellare (rifiutare il pagamento, restituendo i fondi al pagante). Se nessuna azione avviene, il pagamento va in timeout e i fondi ritornano automaticamente. La PR aggiunge tre metodi NWC: make_hold_invoice, settle_hold_invoice e cancel_hold_invoice, più una notifica hold_invoice_accepted. Questo meccanismo alimenta applicazioni come l’escrow rideshare di Ridestr e la risoluzione dispute marketplace.

Implementazioni Attuali:

I wallet principali supportano NWC: Zeus, Alby e Primal (dalla PR #874 di questa settimana) tutti implementano supporto lato wallet. Sul lato client, Damus, Amethyst e la maggior parte dei client Nostr principali possono connettersi a wallet NWC per zapping e pagamenti.

Il protocollo abilita una separazione delle responsabilità: gli utenti possono far girare il loro wallet su un dispositivo mentre interagiscono con Nostr da un altro, con i relay Nostr che servono come canale di comunicazione. Questa architettura significa che i client mobile non devono detenere fondi direttamente, migliorando la sicurezza mantenendo l’infrastruttura wallet separata dai client social.

Considerazioni sulla Sicurezza:

Le connessioni NWC dovrebbero essere trattate come sensibili. Mentre la crittografia protegge il contenuto dei messaggi, la pubkey wallet e il connection secret devono essere custoditi. Le applicazioni dovrebbero permettere agli utenti di revocare connessioni e impostare limiti di spesa. Il protocollo supporta restrizioni di capacità, così i wallet possono limitare quali operazioni una particolare connessione può eseguire.

NIP Deep Dive: NIP-59 (Gift Wrap)

NIP-59 definisce un protocollo per incapsulare qualsiasi evento Nostr in più livelli di crittografia, nascondendo l’identità del mittente dai relay e dagli osservatori. Le proposte di questa settimana per note solo-amici (NIP-FR) e notifiche push (NIP-9a) entrambe si basano sul gift wrapping, rendendolo una primitiva privacy fondamentale da comprendere.

I Tre Livelli:

Il gift wrapping usa tre strutture annidate:

Rumor (evento non firmato): Il contenuto originale come evento Nostr senza firma. Il rumor non può essere inviato direttamente ai relay perché i relay rifiutano eventi non firmati.
Seal (kind 13): Il rumor è crittografato usando NIP-44 e posto in un evento kind 13. Il seal E’ firmato dalla chiave reale dell’autore. Questa è la prova crittografica di paternità.
Gift Wrap (kind 1059): Il seal è crittografato e posto in un evento kind 1059 firmato da una keypair casuale, usa-e-getta. Il gift wrap include un tag p per il routing al destinatario.

Un Malinteso Comune: La Negabilità

La spec menziona che i rumor non firmati forniscono “negabilità”, ma questo è fuorviante. Il livello seal E’ firmato dal vero autore. Quando il destinatario decritta il gift wrap e poi il seal, ha prova crittografica di chi ha inviato il messaggio. Il destinatario potrebbe persino costruire una prova zero-knowledge rivelando l’identità del mittente senza esporre la propria chiave privata.

Quello che il gift wrap in realtà fornisce è privacy del mittente dagli osservatori: i relay e le terze parti non possono determinare chi ha inviato il messaggio perché vedono solo il gift wrap firmato da una chiave casuale. Ma il destinatario sa sempre, e può provarlo.

Eventi di Esempio:

Ecco la struttura completa a tre livelli dalla spec (invio “Vai alla festa stasera?”):

Il rumor (non firmato, non può essere pubblicato sui relay):

{
 "created_at": 1691518405,
 "content": "Are you going to the party tonight?",
 "tags": [],
 "kind": 1,
 "pubkey": "611df01bfcf85c26ae65453b772d8f1dfd25c264621c0277e1fc1518686faef9",
 "id": "9dd003c6d3b73b74a85a9ab099469ce251653a7af76f523671ab828acd2a0ef9"
}

Il seal (kind 13, firmato dal vero autore, contiene rumor crittografato):

{
 "kind": 13,
 "pubkey": "611df01bfcf85c26ae65453b772d8f1dfd25c264621c0277e1fc1518686faef9",
 "content": "AqBCdwoS7/tPK+QGkPCadJTn8FxGkd24iApo3BR9/M0uw6n4RFAFSPAKKMgkzVMo...",
 "created_at": 1703015180,
 "tags": [],
 "id": "28a87d7c074d94a58e9e89bb3e9e4e813e2189f285d797b1c56069d36f59eaa7",
 "sig": "02fc3facf6621196c32912b1ef53bac8f8bfe9db51c0e7102c073103586b0d29..."
}

Il gift wrap (kind 1059, firmato da chiave effimera casuale, contiene seal crittografato):

{
 "kind": 1059,
 "pubkey": "18b1a75918f1f2c90c23da616bce317d36e348bcf5f7ba55e75949319210c87c",
 "content": "AhC3Qj/QsKJFWuf6xroiYip+2yK95qPwJjVvFujhzSguJWb/6TlPpBW0CGFwfuf...",
 "created_at": 1703021488,
 "tags": [["p", "166bf3765ebd1fc55decfe395beff2ea3b2a4e0a8946e7eb578512b555737c99"]],
 "id": "5c005f3ccf01950aa8d131203248544fb1e41a0d698e846bd419cec3890903ac",
 "sig": "35fabdae4634eb630880a1896a886e40fd6ea8a60958e30b89b33a93e6235df7..."
}

Nota: la pubkey del seal è il vero autore (611df01...), mentre la pubkey del gift wrap è una chiave casuale usa-e-getta (18b1a75...). I relay vedono solo il gift wrap, quindi non possono attribuire il messaggio al vero autore.

Cosa Protegge Ogni Livello:

Il rumor non è firmato e non può essere pubblicato direttamente sui relay. Il seal è firmato dal vero autore e prova la paternità al destinatario. Il gift wrap è firmato da una chiave casuale usa-e-getta, nascondendo il vero autore dai relay e dagli osservatori. Solo il destinatario può decrittare attraverso entrambi i livelli per raggiungere il contenuto originale e verificare la firma dell’autore sul seal.

Applicazioni Attuali:

NIP-17 (Messaggi Diretti Privati) usa gift wrap per DM crittografati, sostituendo il vecchio schema NIP-04. Il proposto NIP-FR (note solo per amici) usa il gift wrapping per distribuire ViewKeys agli amici, che poi decifrano le note cifrate con quelle chiavi. NIP-9a (notifiche push) critta i payload di notifica usando principi gift wrap.

Protezione dei Metadati:

I timestamp dovrebbero essere randomizzati per contrastare l’analisi temporale. I relay dovrebbero richiedere AUTH prima di servire eventi kind 1059 e servirli solo al destinatario marcato. Quando si invia a più destinatari, creare gift wrap separati per ciascuno.

È tutto per questa settimana. Stai costruendo qualcosa? Hai notizie da condividere? Vuoi che copriamo il tuo progetto? Contattaci via DM NIP-17 o trovaci su Nostr.

Nostr Compass #7

Wed, 28 Jan 2026 00:00:00 +0000

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

Questa settimana: Ridestr porta il ridesharing decentralizzato su Nostr con pagamenti Cashu e condivisione crittografata della posizione. Pomade introduce il recupero basato su email per i firmatari multisig. Damus implementa negentropy per una sincronizzazione affidabile dei DM. L’app desktop di Amethyst aggiunge ricerca, segnalibri e zap. Amber v4.1.1 mostra i punteggi di fiducia dei relay. Marmot unisce MIP-03 e costruisce un’app di chat di riferimento in TypeScript. diVine aggiunge l’autenticazione QR NIP-46 e il supporto alle menzioni. Nuove proposte NIP affrontano la gestione delle community, la sincronizzazione basata su sequenze e l’archiviazione crittografata dei file. Diamo anche uno sguardo a cinque anni di gennaio di Nostr, tracciando l’evoluzione del protocollo da una manciata di primi utilizzatori nel 2021, attraverso l’esplosivo lancio di Damus sull’App Store nel 2023, fino all’ecosistema client in maturazione del 2025.

Notizie

Ridestr Porta il Ridesharing Decentralizzato su Nostr

Ridestr sta sviluppando un’applicazione di ridesharing peer-to-peer costruita interamente su Nostr, che consente transazioni dirette tra autisti e passeggeri con pagamenti in Bitcoin e Cashu. Il protocollo utilizza tipi di evento personalizzati (30173, 3173-3175, 30180/30181) per coordinare le corse mantenendo la privacy attraverso la divulgazione progressiva della posizione e la crittografia NIP-44.

Il sistema funziona attraverso un flusso attentamente coreografato: gli autisti trasmettono la disponibilità usando posizioni codificate in geohash (precisione ~5km) tramite eventi kind 30173, i passeggeri richiedono corse con stime delle tariffe attraverso kind 3173, e i pagamenti sono protetti usando token escrow HTLC prima dell’inizio della corsa. La privacy della posizione è preservata attraverso la divulgazione progressiva, dove i dettagli del ritiro vengono rivelati solo quando gli autisti arrivano e le destinazioni sono condivise dopo la verifica del PIN. Tutta la comunicazione tra le parti utilizza la crittografia NIP-44 per la privacy.

Ridestr implementa la sicurezza dei pagamenti attraverso escrow HTLC con firme P2PK. Quando un passeggero accetta l’offerta di un autista, blocca i token Cashu con un hash di pagamento che solo l’autista può reclamare dopo il completamento della corsa. Il protocollo attualmente opera con un’architettura single-mint, richiedendo che passeggeri e autisti utilizzino lo stesso mint Cashu. L’implementazione Android basata su Kotlin gestisce la verifica delle prove e il recupero delle prove obsolete attraverso i controlli di stato NUT-07.

Ridestr affronta sfide che la maggior parte delle applicazioni Nostr evita: coordinamento della posizione in tempo reale, escrow dei pagamenti con risoluzione delle dispute e sistemi di reputazione per interazioni nel mondo fisico. Il progetto è in beta e dimostra che il modello di eventi di Nostr può supportare marketplace di servizi peer-to-peer, non solo la condivisione di contenuti.

Pomade Lancia il Sistema di Recupero Alpha per Firmatari Multisig

Pomade, sviluppato da hodlbod, si basa sull’ecosistema FROSTR esistente per fornire un servizio di firma a soglia focalizzato sul recupero. Utilizzando le firme FROST (Flexible Round-Optimized Schnorr Threshold) tramite la libreria @frostr/bifrost, Pomade aggiunge flussi di recupero basati su email sopra la crittografia a soglia. Il sistema frammenta la chiave segreta di un utente usando Shamir Secret Sharing, distribuendo le quote tra più firmatari indipendenti con una soglia configurabile (2-di-3, 3-di-5, ecc.).

Il protocollo opera interamente su Nostr usando un singolo tipo di evento (28350) con payload crittografati NIP-44. Durante la firma, il client richiede firme parziali da almeno threshold firmatari, poi le aggrega in una firma Schnorr valida. Per la crittografia, i firmatari collaborano per derivare segreti condivisi via ECDH senza che nessuna singola parte apprenda la chiave completa.

Il recupero funziona attraverso due metodi di autenticazione: basato su password (usando argon2id con la pubkey del firmatario come salt) o OTP via email. Per prevenire attacchi MITM durante il recupero OTP, ogni firmatario genera il proprio codice di verifica con un prefisso fornito dal client, richiedendo agli utenti di autenticarsi indipendentemente con ogni firmatario. Il protocollo richiede proof-of-work sugli eventi di registrazione (20+ bit secondo NIP-13) per prevenire lo spam.

Il modello di fiducia è esplicito: se threshold firmatari colludono, possono rubare la chiave. I provider email sono completamente fidati poiché possono intercettare gli OTP. Gli utenti non possono recuperare indipendentemente la loro chiave segreta completa; farlo richiede la cooperazione di threshold firmatari. Il protocollo è progettato per l’onboarding di nuovi utenti non familiari con la gestione delle chiavi, con la raccomandazione esplicita che gli utenti migrino all’auto-custodia una volta a loro agio. Pomade avverte di potenziali “perdite di chiavi, furti, denial of service o fughe di metadati” dato il suo stato alpha non auditato.

Rilasci

Damus Implementa Negentropy per la Sincronizzazione Affidabile dei DM

Damus v1.13 implementa l’implementazione negentropy che abbiamo presentato come PR aperta la settimana scorsa. PR #3536 aggiunge il supporto base negentropy al livello di rete, abilitando la riconciliazione degli insiemi con i relay che supportano il protocollo. Una PR #3547 complementare aggiunge la sincronizzazione DM pull-to-refresh che usa negentropy per recuperare i messaggi mancanti quando le sottoscrizioni REQ standard falliscono.

L’implementazione segue un approccio conservativo: il caricamento normale dei DM continua invariato, con negentropy disponibile come meccanismo di recupero quando gli utenti aggiornano manualmente. I test automatizzati dimostrano la correzione generando un DM con un timestamp vecchio che le query standard mancherebbero, poi usando la sincronizzazione negentropy per recuperarlo con successo. Mentre il supporto negentropy richiede relay compatibili, l’implementazione gestisce elegantemente ambienti con relay misti usando il protocollo dove disponibile.

Amber v4.1.1 - Punteggi di Fiducia dei Relay

Amber v4.1.1 implementa la visualizzazione dei punteggi di fiducia dei relay (PR #289), implementando i concetti di valutazione dei relay discussi nella copertura dei Trusted Relay Assertions della settimana scorsa. I punteggi di fiducia ora appaiono nella pagina Relays e per le richieste di connessione NostrConnect, aiutando gli utenti a valutare l’affidabilità dei relay prima di autorizzare le connessioni. Il rilascio include anche una UI ridisegnata per login/eventi/permessi e supporto per il metodo switch_relays. I miglioramenti delle prestazioni memorizzano in cache le operazioni del keystore, affrontando le segnalazioni di tempi di caricamento di oltre 20 secondi su dispositivi più vecchi.

nak v0.18.2 - Integrazione MCP

Il nak di fiatjaf (Nostr Army Knife) v0.18.2 aggiunge il supporto Model Context Protocol tramite nak mcp, permettendo agli agenti AI di cercare persone su Nostr, pubblicare note, menzionare utenti e leggere contenuti usando il modello outbox. Il rilascio introduce anche un installer con una sola riga (curl -sSL https://raw.githubusercontent.com/fiatjaf/nak/master/install.sh | sh) che scarica binari precompilati, eliminando il requisito della toolchain Go per gli utenti finali. La modalità Bunker ora supporta Unix socket e switch_relays.

Zeus v0.12.2 Beta - Fix NWC

Zeus v0.12.2-beta1 implementa multiple correzioni NWC che affrontano i problemi coperti nella copertura di Zeus della settimana scorsa.

Aggiornamenti dei Progetti

Amethyst Desktop - Fase 2A Rilasciata

Amethyst ha rilasciato la Fase 2A della sua app desktop, aggiungendo Ricerca, Segnalibri, Zap, viste Thread e contenuti long-form (Letture) all’esperienza desktop. Una PR #1683 complementare aggiunge feedback trasparente sulla trasmissione degli eventi così gli utenti ora vedono lo stato in tempo reale per-relay mentre i loro eventi si propagano attraverso la rete, rendendo più facile diagnosticare problemi di connettività.

Progressi di Notedeck: App Calendario e Rifinitura UX

L’app desktop Notedeck del team Damus ha unito il comportamento di auto-nascondimento della toolbar (PR #1268) che risponde alla velocità di scorrimento per più spazio sullo schermo nelle viste mobile. Una bozza PR #1271 aggiunge un’app Calendario NIP-52 completa con viste mese/settimana/giorno/agenda, supporto RSVP e commenti NIP-22 sugli eventi del calendario, attualmente con feature-flag per i test.

Jumble Aggiunge Modalità Community

Jumble, il client web focalizzato sui relay, ha aggiunto modalità community e supporto per preset di set di relay tramite variabili d’ambiente, rendendo più facile distribuire istanze tematiche come nostr.moe.

Dashboard Ordini di Shopstr

Shopstr ha sostituito la sua gestione ordini basata su chat con una Dashboard Ordini dedicata. La nuova interfaccia fornisce una vista centralizzata per i merchant per tracciare lo stato degli ordini, segnare i messaggi come letti e gestire l’evasione senza scorrere le conversazioni chat. L’aggiornamento depreca il caching IndexedDB in favore delle API server-side per lo stato degli ordini e rivede come i DM degli ordini vengono taggati per un miglior filtraggio.

Formstr Aggiunge Domande a Griglia

Formstr, l’app form nativa Nostr, ha aggiunto domande a griglia e riscritto il suo SDK con supporto per embed. Una [correzione per firmatari non-NIP-07](https://github.com/abh3po/nostr-forms/pull/418) ha risolto problemi per utenti con bunker o firmatari locali che tentavano di inviare form con la loro identità.

nostr-tools Aggiorna le Dipendenze Crittografiche

nostr-tools, la libreria JavaScript core, ha aggiornato a @noble/curves v2.0.1, affrontando modifiche API breaking attraverso 27 file e adottando le ultime librerie noble auditate. fiatjaf ha anche aggiunto il supporto switch_relays a NIP-46, permettendo ai client bunker di cambiare dinamicamente le connessioni ai relay.

Zeus Lavora sulle Recensioni Mint NIP-87

Zeus ha una [PR aperta per le recensioni mint NIP-87](https://github.com/ZeusLN/zeus/pull/3576), permettendo agli utenti di scoprire e recensire i mint Cashu filtrati dai seguiti Nostr. Le recensioni includono valutazioni a stelle e possono essere inviate anonimamente o con l’nsec dell’utente.

Camelus Implementa Supporto DM Completo

Camelus, un client Android basato su Flutter costruito con Dart NDK per prestazioni mobile efficienti in termini di batteria, ha aggiunto messaggistica diretta completa con oltre 20 commit questa settimana. L’aggiornamento include categorie chat, date dei messaggi, UI di invio ottimistica, funzionalità nota-a-se-stessi e gestione corretta dei relay DM.

Aggiornamenti del Protocollo Marmot

La risoluzione deterministica dei commit MIP-03 che abbiamo coperto come PR aperta la settimana scorsa è stata ora unita. MDK PR #152 assicura che tutte le chat di gruppo basate su MLS convergano sullo stesso stato quando più commit validi arrivano per la stessa epoca.

Una PR spec #28 complementare aggiunge requisiti del ciclo di vita init_key che affrontano lacune dagli audit di implementazione: il materiale della chiave privata dai messaggi Welcome deve essere cancellato in modo sicuro dopo l’elaborazione (zeroizzazione, pulizia dello storage), e i nuovi membri devono eseguire auto-aggiornamenti entro 24 ore per la forward secrecy.

L’SDK TypeScript (marmot-ts) sta costruendo un’applicazione di chat di riferimento. PR #37 aggiunge creazione/lista gruppi, gestione key package con flussi di pubblicazione/trasmissione/cancellazione e inviti tramite codice QR. Una PR aperta #38 di hzrd149 implementa la persistenza della cronologia messaggi con paginazione. Il backend whitenoise-rs ha unito 15 PR questa settimana incluso il supporto multi-lingua (PR #455) e i riferimenti media MIP-04 v2 (PR #450).

diVine Aggiunge Funzionalità di Integrazione Nostr

diVine, l’app video short-form, continua la rapida integrazione Nostr.

Le PR aperte includono l’autenticazione tramite codice QR NIP-46 (PR #1019) e la messaggistica diretta crittografata NIP-17 (PR #834). L’attività di questa settimana si è concentrata sul supporto menzioni che converte URI nostr: e @menzioni in link profilo cliccabili, fallback avatar Classic Viners usando profili Nostr, e strumenti di editing video inclusi disegno, filtri e sticker.

Aggiornamenti NIP

Modifiche recenti al repository NIPs:

Uniti:

Trusted Relay Assertions - La proposta per standardizzare i punteggi di fiducia dei relay che abbiamo coperto la settimana scorsa è stata unita. La specifica definisce eventi kind 30385 per le asserzioni di fiducia dei relay con punteggio su affidabilità, qualità e accessibilità. Il dibattito che ha portato all’unione si è concentrato sul fatto che i punteggi di fiducia debbano essere “globali” (calcolati una volta per tutti gli utenti) o “personalizzati” (relativi al grafo sociale di ogni osservatore). Algoritmi in stile PageRank come Trust Rank di nostr.band e GrapeRank resistono agli attacchi sybil dividendo qualsiasi rank passato attraverso account falsi per la dimensione della bot farm.

PR Aperte e Discussioni:

Communikeys - Una proposta completa per la gestione delle community che usa npub esistenti come identificatori di community invece di approcci basati su relay. Qualsiasi npub può diventare una community pubblicando un evento kind 10222; le pubblicazioni mirano alle community tramite eventi kind 30222. Il controllo degli accessi usa badge NIP-58, abilitando la gestione delegata dell’appartenenza con cold storage per le chiavi della community.
NIP-CF: Changes Feed - Una bozza che propone la sincronizzazione degli eventi basata su sequenze come alternativa ai filtri since basati su timestamp. Il problema: la sincronizzazione Nostr standard usando timestamp since può perdere eventi quando più eventi condividono lo stesso timestamp con precisione al secondo, gli orologi del client e del relay divergono, o il checkpointing è impreciso. NIP-CF risolve questo facendo assegnare ai relay numeri di sequenza monotonicamente crescenti agli eventi memorizzati, fornendo un ordinamento totale rigoroso. I client richiedono modifiche da un numero di sequenza specifico e ricevono eventi in ordine garantito, con checkpointing preciso che non perde mai eventi. La proposta supporta anche la modalità live/continua dove le sottoscrizioni rimangono aperte dopo la sincronizzazione iniziale per aggiornamenti in tempo reale.
NIP-XX: Encrypted File Sync - Un protocollo che definisce i kind 30800 (file crittografati), 30801 (indici vault) e 30802 (documenti condivisi) per sincronizzare contenuti crittografati tra dispositivi usando i relay Nostr. Il protocollo abilita app di note-taking local-first per fornire sincronizzazione crittografata end-to-end senza server centralizzati. Contenuti dei file, percorsi, nomi e struttura delle cartelle sono tutti crittografati usando l’auto-crittografia NIP-44, così i relay memorizzano blob che non possono leggere. Gli allegati binari come le immagini usano server Blossom con crittografia lato client. Il kind 30802 abilita la condivisione di documenti tra utenti crittografando verso la chiave pubblica del destinatario.

Cinque Anni di Gennaio di Nostr

La newsletter del mese scorso ha tracciato le pietre miliari di dicembre di Nostr dal primo rilascio client di fiatjaf attraverso la donazione catalizzatrice di Jack Dorsey. Questa retrospettiva traccia cosa è successo ogni gennaio dal 2021 al 2025, concentrandosi sugli sviluppi tecnici verificati.

Gennaio 2021: Sviluppo Iniziale

Il terzo mese di Nostr vide lo sviluppo continuato di Branle, il client Vue.js di fiatjaf lanciato a dicembre 2020. Un piccolo gruppo di primi utilizzatori, probabilmente meno di 15 persone, si coordinava attraverso il gruppo Telegram @nostr_protocol (creato il 16 novembre 2020), testando il protocollo su uno o due relay sperimentali. Il client da riga di comando noscl forniva interazione basata su terminale.

Le fondamenta tecniche erano già bloccate: utenti identificati da chiavi pubbliche secp256k1, post firmati crittograficamente con firme Schnorr, e relay che servono come storage stupido che non comunicano tra loro. Questa era crittografia deliberatamente nativa di Bitcoin, una scelta di design che avrebbe plasmato i pattern di adozione anni dopo.

Gennaio 2022: Scoperta degli Sviluppatori

Gennaio 2022 si aprì con Nostr ancora in fermento dalla sua prima apparizione su Hacker News (31 dicembre 2021), che generò 110 punti e 138 commenti. Al momento di quel post, solo circa sette relay alimentavano l’intera rete, con i commentatori che notavano “lo spam non è ancora un problema perché nostr è super nuovo e nessuno lo usa ancora”. Robert C. Martin (“Uncle Bob”) aveva appoggiato Nostr come potenzialmente “la soluzione definitiva per la comunicazione sociale”. La discussione continuò a gennaio, con sviluppatori che dibattevano architettura relay versus vero P2P, resistenza alla censura versus moderazione, e se la semplicità potesse scalare.

Il post HN scatenò un’ondata di nuove implementazioni. Uncle Bob stesso iniziò more-speech, un client desktop Clojure, il 18 gennaio. La libreria go-nostr di fiatjaf (creata gennaio 2021) e il client da riga di comando noscl fornivano strumenti Go, mentre nostr-tools offriva supporto JavaScript. Entro dicembre 2022, circa 800 profili avevano bio. Branle rimase il client web principale, ricevendo aggiornamenti inclusi import della chiave privata e supporto multi-relay. Le sfide tecniche erano evidenti: le chiavi esadecimali da 64 caratteri si rivelarono non intuitive, i ritardi dei messaggi frustravano gli utenti, e la community si chiedeva se l’architettura potesse gestire traffico a scala Twitter.

Gennaio 2023: La Svolta

Gennaio 2023 trasformò Nostr da esperimento a movimento. Damus, il client iOS di William Casarin (jb55), lottava con il processo di approvazione dell’App Store di Apple. Rifiutato il 1° gennaio, rifiutato di nuovo il 26 gennaio, fu finalmente approvato il 31 gennaio. Quell’approvazione scatenò una cascata: Damus raggiunse immediatamente la posizione #10 in U.S. Social Networking. Jack Dorsey lo definì “una pietra miliare per i protocolli aperti”.

Otto giorni prima, il 23 gennaio, Edward Snowden annunciò la sua presenza su Nostr: “Una delle cose cool di Nostr… oltre alla resistenza alla censura, è che non sei limitato a 280 caratteri”. Il suo endorsement da parte di un whistleblower della NSA aveva peso nei circoli attenti alla privacy, e gli utenti iniziarono immediatamente a inviargli zap in sats via Lightning.

I client web corsero per gestire l’afflusso. Snort, creato da kieran a dicembre 2022, emerse come un client React ricco di funzionalità; il 13 gennaio, Snort integrò la registrazione NIP-05 tramite l’API Nostr Plebs, permettendo ai nuovi utenti di reclamare identità leggibili durante l’onboarding. Iris, sviluppato a tempo pieno da Martti Malmi (un early contributor di Bitcoin che ricevette la seconda transazione Bitcoin mai fatta da Satoshi), offriva interfacce sia web che mobile con identità NIP-05 gratuite su iris.to. Astral, costruito da monlovesmango con Quasar (Vue.js) come fork di Branle, si concentrava sulla gestione dei relay con la sua funzionalità di raggruppamento relay che permetteva agli utenti di organizzare i relay in set per la pubblicazione e il filtraggio. Le beta TestFlight per i client iOS si riempivano in poche ore, e Amethyst dominava su Android.

L’infrastruttura faticava a tenere il passo. Tutti i relay erano gestiti da appassionati che pagavano di tasca propria. I relay a pagamento che usavano micropagamenti Lightning creavano un filtraggio naturale dello spam ma introducevano frizione nell’accesso. Damus fu rimosso dall’App Store della Cina solo due giorni dopo l’approvazione, riferibilmente su richiesta del principale organo di vigilanza internet della Cina.

Gennaio 2024: Consolidamento del Protocollo

Gennaio 2024 si concentrò sulla standardizzazione del protocollo e sulla costruzione della community. Nostr PHX iniziò l’anno con un meetup il 5 gennaio a Phoenix, riunendo cypherpunk locali. Questo fu il primo di molti eventi della community quell’anno inclusi BTC Prague (giugno), Nostriga a Riga (agosto) e Nostrasia.

Lo sviluppo del protocollo più significativo fu NIP-59 (Gift Wrap) unito il 29 gennaio, fornendo protezione dei metadati per le comunicazioni crittografate. Gift Wrap si basa sullo standard di crittografia NIP-44 (che era stato auditato da Cure53 a dicembre 2023) per nascondere l’identità del mittente dai relay. Il protocollo avvolge i messaggi crittografati all’interno di un evento esterno firmato da una keypair casuale, usa-e-getta. I relay vedono solo la pubkey usa-e-getta, mentre la vera identità del mittente è sepolta nel payload crittografato che solo il destinatario può decifrare. Questo impedisce agli operatori dei relay e agli osservatori della rete di sapere chi sta messaggiando chi. I timestamp possono anche essere randomizzati per sconfiggere l’analisi temporale.

L’ecosistema si espanse oltre i social media. Plebeian Market diventò completamente Nostr-native con conformità NIP-15, abilitando carrelli cross-stall e un browser di stall per scoprire i merchant. Shopstr emerse come un marketplace permissionless che facilitava il commercio Bitcoin. Zap.stream, costruito da kieran, portò lo streaming live su Nostr con pagamenti Lightning a 21 sats/minuto. Gli strumenti per sviluppatori maturarono con NDK che forniva astrazioni TypeScript e rust-nostr che offriva binding Rust. Zeus v0.8.1 fu rilasciato con import contatti Nostr e LND persistente, gettando le basi per l’integrazione Nostr Wallet Connect nei rilasci successivi.

Eppure la sostenibilità dell’infrastruttura rimaneva una sfida. La ricerca accademica di questo periodo trovò che il 95% dei relay faticava a coprire i costi operativi, con il 20% che sperimentava significativi tempi di inattività. La tariffa di ammissione per i relay a pagamento era in media meno di 1.000 sats (~$0.45), insufficiente a sostenere le operazioni.

Una nota sulle truffe: Il “Nostr Assets Protocol” e il token “$NOSTR” associato che furono lanciati in questo periodo furono pubblicamente denunciati da fiatjaf come “100% fraudolenti” e “una truffa di affinità” senza alcuna connessione con il vero protocollo Nostr.

Gennaio 2025: Maturazione dei Client

Gennaio 2025 vide lo sviluppo continuato dei client attraverso l’ecosistema. Nostur 1.17.0 fu rilasciato il 13 gennaio con sincronizzazione cross-device per gli stati di lettura, supporto login multi-sig FROST e prestazioni ottimizzate del database locale. Amethyst continuò la sua transizione al modello outbox, compilando automaticamente set di relay basati sulle liste di follow piuttosto che richiedere configurazione manuale.

I principali client iniziarono ad allontanarsi da NIP-04 per i messaggi diretti, migrando verso NIP-17 e il proposto NIP-104 per crittografia migliorata e protezione dei metadati. Il modello Gossip (comunicazione outbox/inbox) guadagnò adozione mentre l’ecosistema convergeva verso pattern di utilizzo dei relay più efficienti. Gli osservatori del settore prevedevano che questo sarebbe stato l’anno in cui Nostr transita da protocollo di nicchia a riconoscimento mainstream, con una potenziale migrazione di piattaforma ad alto profilo che potrebbe raddoppiare l’attività giornaliera.

Gennaio 2026: Sicurezza e Infrastruttura di Firma

Gennaio 2026 portò significativi avanzamenti nella sicurezza e nell’infrastruttura di firma. Primal Android 2.6.18 fu rilasciato con firma remota NIP-46 e supporto per firmatario locale NIP-55, unendosi ad Amber e Aegis come hub di firma completo per altre app Android. Bitchat completò un audit di sicurezza Cure53, la stessa azienda che auditò Signal e NIP-44, con oltre 17 PR che correggevano problemi critici inclusa la cancellazione dei segreti DH e problemi di thread safety. Sia Bitchat che Damus migrarono da C Tor a Rust Arti per maggiore affidabilità e sicurezza della memoria.

Il lavoro sul protocollo continuò con NIP-71 (eventi video addressable) unito e una NIP sulla crittografia post-quantistica che aprì la discussione sul future-proofing di Nostr contro attacchi quantistici. La bozza Trusted Relay Assertions propose la standardizzazione del punteggio di fiducia dei relay attraverso attestazioni firmate. Il Protocollo Marmot rafforzò la sua messaggistica crittografata basata su MLS con 18 PR unite che affrontavano le scoperte dell’audit.

Le applicazioni nel mondo reale si espansero con Ridestr che sviluppa ridesharing decentralizzato usando escrow Cashu e crittografia NIP-44, e Pomade che aggiunge flussi di recupero basati su email alla firma a soglia FROST. Damus rilasciò negentropy per la sincronizzazione affidabile dei DM, mentre l’app desktop di Amethyst raggiunse la Fase 2A con ricerca, segnalibri e zap.

Guardando Avanti

Sei anni di gennaio rivelano l’evoluzione di Nostr dallo sviluppo iniziale (2021) alla scoperta pubblica (2022) alla crescita esplosiva (2023) al consolidamento del protocollo (2024) alla maturazione dei client (2025) all’infrastruttura di sicurezza (2026). Il pattern è familiare a chiunque abbia osservato la crescita dei protocolli aperti: anni di costruzione silenziosa, un’esplosione improvvisa quando le condizioni si allineano, poi il lavoro più lungo di rendere tutto affidabile. Quello che è iniziato con sette relay e un thread su Hacker News è ora infrastruttura auditata con applicazioni reali. La domanda per il 2027: quando qualcuno chiamerà una corsa, invierà un messaggio crittografato o recupererà una chiave persa usando Nostr, sapranno anche che lo stanno usando?

È tutto per questa settimana. Stai costruendo qualcosa? Hai notizie da condividere? Vuoi che copriamo il tuo progetto? Contattaci via DM NIP-17 o trovaci su Nostr.

Nostr Compass #6

Wed, 21 Jan 2026 00:00:00 +0000

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

Questa settimana: Bitchat sostituisce C Tor con l’implementazione Rust Arti per una maggiore affidabilità e prestazioni. nostrdb-rs ottiene query fold streaming che abilitano operazioni di database a zero allocazioni. Listr riceve un importante refactoring con la migrazione a NDK 3 beta e manutenzione assistita da AI dopo un anno di inattività. Zeus spedisce 17 PR unite focalizzate su correzioni NIP-47 (Nostr Wallet Connect per il controllo remoto di Lightning) e miglioramenti Cashu, mentre Primal Android aggiunge flussi di backup del wallet e supporto NIP-92 (dimensioni dei media per rapporti di aspetto corretti). Una nuova bozza di NIP propone Trusted Relay Assertions per la valutazione standardizzata della fiducia nei relay.

Notizie

Bitchat Migra ad Arti Rust per il Supporto Tor

Bitchat è migrato da C Tor ad Arti, l’implementazione Rust del protocollo Tor. PR #958 rimuove la dipendenza da C Tor e integra Arti, portando garanzie di sicurezza della memoria e maggiore affidabilità. Il cambiamento elimina i tentativi di riattivazione dormiente che causavano riavvii del servizio in primo piano, un problema di lunga data con l’implementazione C.

Cosa significa per gli utenti: Messaggistica crittografata più stabile con meno disconnessioni, specialmente su dispositivi mobili. L’implementazione Rust riduce i rischi di crash e il consumo della batteria dai tentativi di riconnessione costanti.

Arti è una riscrittura completa di Tor in Rust, sviluppata dal Tor Project per fornire maggiore sicurezza attraverso la sicurezza della memoria e un’integrazione più facile nelle applicazioni. Per Bitchat, le proprietà di sicurezza della memoria riducono la superficie di attacco durante la gestione di messaggi crittografati e connessioni relay. La migrazione segue il recente audit di sicurezza Cure53 del team (trattato nella Newsletter #5), continuando i loro miglioramenti di sicurezza.

Il PR introduce anche una copertura di test completa per ChatViewModel e BLEService, rimuove codice morto e stabilizza la suite di test. I miglioramenti di affidabilità della mesh Bluetooth Low Energy accompagnano le modifiche Tor, affrontando i fallimenti di trasferimenti grandi. Insieme, questi cambiamenti migliorano la resilienza di Bitchat per scenari di rete mesh offline dove Tor fornisce connettività internet insieme alla comunicazione BLE locale.

Listr Rivitalizzato con Manutenzione Potenziata dall’AI

JeffG ha annunciato un importante refactoring di Listr, l’applicazione di gestione liste Nostr disponibile su listr.lol, dopo che il progetto era rimasto inattivo per oltre un anno. Usando l’assistenza dell’AI, ha completato un aggiornamento completo includendo la migrazione a NDK 3 beta, aggiornamenti alle ultime versioni di Svelte e Vite, e tutte le dipendenze portate alla versione corrente. Il refactoring aggiunge supporto di prima classe per i pacchetti di following, implementa la paginazione per liste che superano i 50 elementi e corregge numerosi bug che si erano accumulati durante il periodo di inattività.

Cosa significa per gli utenti: Listr è tornato online con prestazioni migliorate e nuove funzionalità per gestire liste di following, collezioni di contenuti e curatela di argomenti. La correzione della paginazione rende effettivamente utilizzabili le liste grandi.

JeffG ha notato che senza l’assistenza dell’AI, questo lavoro di manutenzione probabilmente non sarebbe mai avvenuto, impedendo che il progetto venisse abbandonato. Listr abilita la curatela dei contenuti su Nostr, permettendo agli utenti di creare, gestire e condividere liste di profili, argomenti e risorse. L’aggiornamento mantiene l’applicazione compatibile con gli standard Nostr correnti e le aspettative dei client man mano che la gestione delle liste diventa più centrale per la scoperta dei contenuti sul protocollo.

Aggiornamenti NIP

Modifiche recenti al repository NIPs:

Unite:

NIP-29 (Gruppi basati su relay) - Chiarimento Chiave Relay (#2190 - unito) chiarisce che la chiave relay è l’URL del relay stesso, non una pubkey. La specifica ora afferma esplicitamente “La chiave relay è l’URL WebSocket del relay (es. wss://groups.example.com)” per evitare confusione. Questo influisce su come i client identificano quale relay ospita un determinato gruppo, garantendo che i gruppi siano correttamente attribuiti ai loro relay ospitanti.

PR Aperte e Discussioni:

Trusted Relay Assertions - Una bozza di NIP propone di standardizzare il punteggio di fiducia nei relay attraverso eventi kind 30385 contenenti punteggi di fiducia (0-100) calcolati da metriche NIP-66 (scoperta e monitoraggio relay), reputazione dell’operatore e segnalazioni degli utenti. La specifica divide la fiducia in componenti di affidabilità (uptime, latenza), qualità (TLS, documentazione, verifica operatore) e accessibilità (giurisdizione, barriere, rischio sorveglianza). La verifica dell’operatore include firme crittografiche tramite NIP-11 (documenti informativi relay), record TXT DNS e file .well-known. Gli utenti dichiarano i fornitori di asserzioni fidati tramite eventi kind 10385, permettendo ai client di interrogare più fornitori per prospettive diverse. La proposta complementa la scoperta NIP-66 con la valutazione, aiutando NIP-46 (firma remota/Nostr Connect) a valutare l’affidabilità dei relay negli URI di connessione.
Crittografia Post-Quantistica - PR #2185 (aperta) continua ad evolversi da quando la Newsletter #5 ha introdotto la proposta per algoritmi resistenti ai computer quantistici. La discussione di questa settimana si è concentrata sui dettagli di implementazione per la crypto-agility: come i client gestiscono le firme doppie durante la migrazione, la compatibilità retroattiva per i client più vecchi e le implicazioni prestazionali delle firme quantistiche resistenti più grandi. I contributori hanno dibattuto se imporre solo ML-DSA-44 o supportare più algoritmi (ML-DSA-44, Falcon-512, Dilithium) per flessibilità. Il consenso propende verso un approccio graduale: firme quantistiche opzionali inizialmente, diventando obbligatorie solo dopo un ampio supporto dei client e l’emergere di una reale minaccia quantistica.

Approfondimento NIP: NIP-11 e NIP-66

Questa settimana esaminiamo due NIP che lavorano insieme per abilitare la scoperta e valutazione dei relay: NIP-11 definisce come i relay si descrivono, e NIP-66 standardizza come misuriamo il comportamento dei relay. Insieme formano la base per i sistemi di valutazione della fiducia nei relay.

NIP-11: Documento Informativo Relay

NIP-11 definisce un documento JSON che i relay servono via HTTP per descrivere le loro capacità, politiche e informazioni sull’operatore. Quando un client si connette a wss://relay.example.com, può recuperare https://relay.example.com (sostituendo wss:// con https://) per ottenere il documento informativo del relay.

Il documento usa la negoziazione standard del contenuto HTTP con l’header Accept: application/nostr+json. Questo permette ai relay di servire il loro sito web normale ai browser mentre forniscono metadati leggibili dalle macchine ai client Nostr. La risposta include il nome del software relay e la versione, informazioni di contatto dell’operatore (pubkey, email, contatto alternativo), NIP supportati e parametri operativi come requisiti di pagamento o restrizioni di contenuto.

Importante notare che i documenti NIP-11 di base sono JSON non firmati serviti via HTTPS, affidandosi esclusivamente ai certificati TLS per l’autenticità. Questo significa che chiunque controlli il server web del relay può modificare il documento, rendendo non verificabili le affermazioni dell’operatore. La proposta Trusted Relay Assertions affronta questa lacuna introducendo attestazioni firmate attraverso il campo self pubkey di un relay, abilitando la prova crittografica dell’identità dell’operatore in modo simile a come i relay usano eventi firmati per i meccanismi di autenticazione.

{
 "name": "relay.example.com",
 "description": "Un relay pubblico per uso generale",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "contact": "admin@example.com",
 "supported_nips": [1, 2, 4, 9, 11, 12, 16, 20, 22],
 "software": "git+https://github.com/relay/relay.git",
 "version": "1.2.3",
 "limitation": {
 "max_message_length": 16384,
 "max_subscriptions": 20,
 "max_filters": 100,
 "max_limit": 5000,
 "max_subid_length": 100,
 "min_prefix": 4,
 "max_event_tags": 2000,
 "max_content_length": 8196,
 "min_pow_difficulty": 0,
 "auth_required": false,
 "payment_required": false
 },
 "payments_url": "https://relay.example.com/payments",
 "fees": {
 "admission": [{"amount": 5000, "unit": "msats"}],
 "subscription": [{"amount": 1000, "unit": "msats", "period": 2592000}],
 "publication": []
 }
}

L’oggetto limitation indica ai client quali vincoli applica il relay. max_message_length limita la dimensione del frame WebSocket, max_subscriptions limita le sottoscrizioni REQ concorrenti per connessione, max_filters limita i filtri per REQ, e max_limit vincola quanti eventi può richiedere un singolo filtro. Questi parametri aiutano i client ad adattare il loro comportamento alle capacità del relay, evitando disconnessioni dal superamento dei limiti.

Le informazioni di pagamento appaiono in fees e payments_url. I relay possono addebitare per l’ammissione (accesso una tantum), l’abbonamento (accesso ricorrente) o la pubblicazione (tariffe per evento). Il payments_url punta ai dettagli sui metodi di pagamento, tipicamente fatture Lightning o mint ecash. I relay a pagamento usano questi campi per comunicare i prezzi prima che i client tentino l’autenticazione.

L’array supported_nips permette ai client di scoprire le capacità del relay. Se un relay elenca NIP-50, i client sanno di poter inviare query di ricerca full-text. Se appare NIP-42, i client dovrebbero aspettarsi challenge di autenticazione. Questa pubblicità dichiarativa delle capacità abilita il miglioramento progressivo: i client possono usare funzionalità avanzate dove disponibili mentre degradano elegantemente su relay con supporto limitato.

Le informazioni sull’operatore costruiscono responsabilità. Il campo pubkey identifica l’operatore del relay su Nostr, abilitando la comunicazione diretta tramite DM NIP-17 o menzioni pubbliche. L’contact email fornisce un fallback fuori protocollo. Insieme, questi campi aiutano gli utenti a raggiungere gli operatori per segnalazioni di abuso, richieste di accesso o problemi tecnici.

I documenti NIP-11 sono auto-riportati: i relay descrivono cosa affermano di supportare, non necessariamente cosa fanno effettivamente. Qui è dove NIP-66 diventa importante.

NIP-66: Scoperta Relay e Monitoraggio Liveness

NIP-66 standardizza la pubblicazione di dati di monitoraggio relay su Nostr. I servizi di monitoraggio testano continuamente i relay per disponibilità, latenza, conformità al protocollo e NIP supportati. Pubblicano i risultati come eventi kind 30166, fornendo lo stato relay in tempo reale indipendente dall’auto-segnalazione del relay.

I monitor controllano la disponibilità del relay connettendosi e inviando sottoscrizioni di test. Le misurazioni di latenza tracciano il tempo di connessione, il tempo di risposta alle sottoscrizioni e il ritardo di propagazione degli eventi. I test di conformità al protocollo verificano che il comportamento del relay corrisponda alle specifiche, individuando bug di implementazione o deviazioni intenzionali. La verifica del supporto NIP va oltre le affermazioni NIP-11 testando effettivamente se le funzionalità pubblicizzate funzionano correttamente.

{
 "id": "a34b5c7d89e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7",
 "pubkey": "4e2d0bc6f8e7c3a5b9f1d2e3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4",
 "created_at": 1736784000,
 "kind": 30166,
 "tags": [
 ["d", "wss://relay.example.com"],
 ["rtt", "open", "143", "1736784000"],
 ["rtt", "read", "89", "1736784000"],
 ["rtt", "write", "92", "1736784000"],
 ["nips", "1", "2", "4", "9", "11", "12"],
 ["geo", "US", "United States", "New York"],
 ["other", "network", "clearnet"],
 ["other", "payment_required", "false"],
 ["other", "auth_required", "false"]
 ],
 "content": "{\"last_check\": 1736784000, \"checks\": 8760}",
 "sig": "8b9c4d5e6a7f8b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b"
}

Il tag d contiene l’URL del relay, rendendo questo un evento sostituibile parametrizzato. Ogni monitor pubblica un evento per relay, aggiornato al cambiare delle misurazioni. Più monitor possono tracciare lo stesso relay, fornendo ridondanza e validazione incrociata. I client interrogano più pubkey di monitor per ottenere prospettive diverse sulla salute del relay.

I tag round-trip time (rtt) misurano la latenza per diverse operazioni. rtt open traccia l’instaurazione della connessione WebSocket, rtt read misura il tempo di risposta alle sottoscrizioni, e rtt write testa la velocità di pubblicazione degli eventi. Tutti i valori sono in millisecondi. I client usano queste metriche per preferire relay a bassa latenza per operazioni sensibili al tempo o deprioritizzare relay lenti.

Il tag nips elenca il supporto NIP effettivamente verificato, non solo il supporto dichiarato. I monitor testano ogni NIP esercitando la sua funzionalità. Se un relay rivendica la ricerca NIP-50 nel suo documento NIP-11 ma le query di ricerca falliscono, i monitor ometteranno NIP-50 dalla lista verificata. Questo fornisce la verità di base sulle capacità del relay.

Le informazioni geografiche aiutano i client a selezionare relay vicini per una migliore latenza e resistenza alla censura. Il tag geo contiene il codice paese, il nome paese e la regione. Il tag network distingue i relay clearnet dai servizi nascosti Tor o endpoint I2P. Insieme, questi tag abilitano la diversità geografica: i client possono connettersi a relay in più giurisdizioni per resistere alla censura regionale.

I dati dei monitor alimentano i selettori di relay nei client, i siti web esploratori e la proposta Trusted Relay Assertions. Combinando documenti auto-riportati NIP-11 con dati misurati NIP-66 e asserzioni di fiducia calcolate, l’ecosistema si muove verso la selezione informata dei relay piuttosto che fare affidamento su default codificati o raccomandazioni di passa-parola.

Rilasci

0xchat v1.5.3 - Funzionalità di Messaggistica Migliorate

0xchat v1.5.3 porta miglioramenti significativi al client di messaggistica Nostr stile Telegram. Il rilascio affronta problemi di conformità NIP-55 (applicazione signer Android) che impedivano la corretta firma degli eventi attraverso signer esterni come Amber. La piena conformità significa che 0xchat ora delega correttamente le operazioni di firma, migliorando la sicurezza mantenendo le chiavi private isolate.

L’aggiornamento integra sia FileDropServer che BlossomServer come opzioni di archiviazione media predefinite, offrendo agli utenti ridondanza per i caricamenti di file. Blossom fornisce archiviazione indirizzata ai contenuti dove i file sono referenziati dai loro hash SHA-256, garantendo integrità e abilitando la deduplicazione sulla rete. Il salvataggio automatico delle bozze per Moments previene la perdita di dati quando si compone contenuto long-form, affrontando le lamentele degli utenti sui post persi durante i cambi di app o le interruzioni di connettività.

L’integrazione del wallet Cashu riceve una lucidatura con il filtraggio automatico delle prove che rimuove i token spesi dalla vista del wallet. Questo risolve la UX confusa dove gli utenti vedevano prove invalide insieme a ecash valido, rendendo inaffidabili i calcoli del saldo. Il filtraggio avviene lato client, mantenendo la privacy mentre migliora l’esperienza di pagamento per le transazioni peer-to-peer nelle chat.

Amber v4.1.0 Pre-releases - Revisione UI

Amber v4.1.0-pre1 fino a v4.1.0-pre3 introducono un’interfaccia ridisegnata per il popolare signer di eventi Android. La schermata di login ora visualizza chiaramente quale applicazione sta richiedendo permessi di firma, affrontando la confusione degli utenti sui flussi di autorizzazione. La nuova schermata eventi fornisce un’ispezione dettagliata di quali dati le applicazioni vogliono firmare, permettendo agli utenti di prendere decisioni di sicurezza informate prima di approvare le operazioni.

La gestione dei permessi riceve attenzione significativa con un’interfaccia rinnovata che mostra esattamente quali capacità è stata concessa a ogni applicazione connessa. Gli utenti possono revocare permessi specifici senza disconnettersi completamente, abilitando il controllo a grana fine sulla delegazione della firma. I contatori relay rifattorizzati usando la libreria quartz aggiornata forniscono statistiche in tempo reale sul throughput degli eventi e le prestazioni dei relay. Le connessioni bunker NIP-46 (Nostr Connect) ora mostrano messaggi di errore dettagliati quando le connessioni falliscono, sostituendo gli errori di timeout criptici con diagnostiche azionabili.

Modifiche notevoli a codice e documentazione

Queste sono pull request unite e sviluppi in fase iniziale che vale la pena tracciare. Alcuni sono funzionalità sperimentali che potrebbero evolversi prima del rilascio.

Zeus (Wallet Lightning con Nostr Wallet Connect)

Zeus ha unito 17 pull request questa settimana, rafforzando la sua posizione come implementazione NIP-47 Nostr Wallet Connect leader. Le correzioni più significative affrontano problemi di consistenza dei dati e conformità al protocollo che stavano causando problemi di interoperabilità con i client Nostr.

Correzione Cronologia Transazioni - PR #3542 risolve un bug critico dove le liste transazioni NWC visualizzavano voci errate o duplicate. Il problema si verificava quando Zeus metteva in cache i dati delle transazioni senza gestire correttamente gli aggiornamenti degli eventi, causando agli utenti di vedere transazioni fantasma o pagamenti mancanti. La correzione implementa la deduplicazione corretta degli eventi e l’invalidazione della cache, garantendo che la cronologia delle transazioni rifletta accuratamente lo stato del nodo Lightning.

Conformità al Protocollo - PR #3548 affronta risposte getInfo incomplete che rompevano la compatibilità con i client che si aspettano la piena conformità NIP-47. Alcuni client Nostr crashavano quando ricevevano risposte parziali mancanti di campi come block_height o network. Il PR garantisce che tutti i campi richiesti ritornino con default sensati anche quando l’implementazione Lightning sottostante non li fornisce, migliorando la compatibilità di Zeus nell’ecosistema.

Resilienza della Connessione - PR #3543 implementa notifiche di timeout per connessioni Nostr bloccate. Precedentemente, gli utenti aspettavano indefinitamente quando le connessioni relay cadevano silenziosamente. Ora Zeus visualizza messaggi di timeout chiari dopo 30 secondi di inattività, permettendo agli utenti di riprovare o cambiare relay. PR #3541 aggiunge validazione backend per prevenire l’attivazione NWC su implementazioni Lightning incompatibili, individuando errori di configurazione prima che causino crash runtime.

Race Condition Cashu - PR #3531 corregge un bug di concorrenza nella gestione dei token Cashu dove operazioni di mint simultanee potevano corrompere il database dei token. La race condition si verificava quando più thread aggiornava i conteggi dei token senza un locking appropriato, risultando occasionalmente in saldi errati. La correzione aggiunge protezione mutex attorno alle sezioni critiche, garantendo aggiornamenti atomici allo stato dei token.

Primal Android (Client)

Primal Android ha spedito 12 PR unite con miglioramenti significativi alla sicurezza del wallet e alla gestione dei media. L’implementazione del backup del wallet affronta una delle funzionalità più richieste, mentre il supporto NIP-92 migliora l’esperienza visiva nell’applicazione.

Sistema di Backup Wallet - Una serie di quattro PR (#844, #845, #846, #848) implementa una funzionalità completa di backup della seed phrase. Gli utenti possono ora esportare il loro mnemonico di 12 parole attraverso un flusso sicuro che previene screenshot, visualizza lo stato del backup nel dashboard del wallet e guida gli utenti esistenti attraverso la migrazione. L’implementazione segue gli standard BIP-39 e include validazione per prevenire che gli utenti perdano fondi a causa della registrazione errata della frase.

Dimensioni Media (NIP-92) - PR #718 implementa il supporto NIP-92 per i corretti rapporti di aspetto di immagini e video. Senza metadati delle dimensioni, i client devono scaricare le immagini per determinare la loro dimensione, causando salti di layout mentre il contenuto si carica. NIP-92 aggiunge tag dim (come ["dim", "1920x1080"]) agli eventi di metadati dei file, permettendo a Primal di riservare lo spazio corretto prima di scaricare i media. Questo elimina i reflow fastidiosi nelle gallerie di immagini e migliora le prestazioni percepite.

Affidabilità Signer Remoto - PR #841 corregge problemi di connessione NIP-46 dove i prefissi wss:// mancanti causavano fallimenti silenziosi. Il PR valida gli URI relay durante la configurazione della connessione bunker, aggiungendo automaticamente il prefisso di protocollo quando gli utenti incollano domini nudi. PR #843 affronta un bug di threading dove condizioni di rete scarse causavano la pubblicazione delle risposte come note radice, rompendo il flusso della conversazione. La correzione garantisce che gli ID degli eventi genitore persistano attraverso le interruzioni di rete.

Marmot Protocol: White Noise (Libreria Chat di Gruppo Crittografata)

White Noise, la libreria Rust che alimenta le chat di gruppo crittografate del Protocollo Marmot, ha unito sei PR migliorando l’esperienza utente e la sicurezza. I cambiamenti portano Marmot più vicino alla parità di funzionalità con le applicazioni di messaggistica mainstream mantenendo la sua architettura privacy-first.

Ricevute di Lettura - PR #433 e #436 implementano il tracciamento della lettura dei messaggi per le conversazioni di gruppo. Il sistema memorizza le posizioni di lettura per utente per gruppo all’interno di un singolo dispositivo, abilitando i badge del conteggio non letti. L’implementazione usa timestamp monotonici per tracciare l’ultima posizione di messaggio letto per ogni conversazione. Questa funzionalità fondamentale abilita indicatori UI che mostrano i conteggi di messaggi non letti per conversazione.

Fissaggio Conversazioni - PR #442 aggiunge il fissaggio persistente delle conversazioni attraverso un campo pin_order nella tabella di giunzione accounts_groups che collega gli account ai gruppi. Le conversazioni fissate mantengono la loro posizione in cima alle liste di chat indipendentemente dall’attività dei messaggi, rispettando le aspettative degli utenti da Signal e WhatsApp. L’implementazione usa l’ordinamento intero per permettere pin illimitati con ordinamento deterministico.

Risoluzione Commit Deterministica (MIP-03) - PR #152 (aperta) implementa il Marmot Improvement Proposal 03, risolvendo il problema critico delle race condition dei commit nelle chat di gruppo distribuite. Quando più membri inviano cambiamenti di stato del gruppo (aggiungere/rimuovere membri, cambiare permessi) simultaneamente, i client potrebbero divergere sull’ordinamento dei commit, frammentando il gruppo in stati incompatibili. MIP-03 introduce snapshot di epoca e una selezione deterministica del vincitore: vince il commit con il timestamp created_at più precoce, con l’ID evento lessicografico come tiebreaker. Questo permette a tutti i client di convergere sullo stesso stato attraverso rollback e replay, mantenendo la coerenza del gruppo anche durante le partizioni di rete.

Hardening di Sicurezza - PR #443 previene la copia non necessaria di segreti crittografici usando riferimenti in resolve_group_image_path. Questo riduce la finestra per attacchi alla memoria dove i segreti potrebbero essere recuperati da allocazioni heap liberate. PR #438 abilita la crittografia del database SQLCipher attraverso parametri keyring, proteggendo la cronologia dei messaggi a riposo. L’integrazione keyring permette l’archiviazione sicura delle chiavi nei keychain della piattaforma piuttosto che nei file di configurazione.

nostrdb-rs (Libreria Database) - PR Aperta

Implementazione Query Streaming - PR #58 (aperta) propone query fold streaming per abilitare operazioni di database a zero allocazioni. L’implementazione aggiunge metodi fold, try_fold, count, any, all, e find_map che processerebbero i risultati del database uno alla volta senza materializzare interi set di risultati in vettori. Questo approccio ridurrebbe il consumo di memoria e abiliterebbe la terminazione anticipata per pattern di query comuni.

L’implementazione tecnica espone callback di risultati query a basso livello (ndb_query_visit) come visitor Rust stateful che mappano varianti ControlFlow ad azioni visitor C. Una volta unite, il codice applicativo si leggerà come logica iteratore mentre gira vicino al layer database. Ad esempio, contare note corrispondenti farebbe streaming attraverso i risultati piuttosto che raccoglierli, e find_map ritornerebbe il primo risultato utile senza processare le righe rimanenti.

nostrdb alimenta Damus e Notedeck, rispettivamente client iOS/macOS e desktop. Le query streaming abiliterebbero pattern efficienti come paginazione, filtraggio condizionale e controlli di esistenza. Il PR cambia 3 file con +756 aggiunte e -32 eliminazioni, un refactoring sostanziale del layer query. Gli utenti delle applicazioni basate su nostrdb-rs vedrebbero un uso ridotto della memoria quando navigano timeline grandi o cercano attraverso database eventi estesi.

nak (Strumento CLI)

nak, lo strumento Nostr da linea di comando di fiatjaf, ha unito sei PR focalizzati sui miglioramenti del sistema di build e nuove funzionalità. PR #91 implementa una funzionalità mirror Blossom, permettendo a nak di servire come mirror per server media Blossom. Blossom è un protocollo di archiviazione media indirizzato ai contenuti che lavora insieme agli eventi Nostr.

I PR rimanenti affrontano la compatibilità del sistema di build attraverso le piattaforme Windows, macOS e Linux, abilitando il supporto filesystem FUSE per montare gli eventi Nostr come directory locali.

Damus (Client iOS) - PR Aperte

Damus ha 11 PR aperte che esplorano miglioramenti architetturali significativi. Sebbene questi non siano stati ancora uniti, segnalano direzioni importanti per lo sviluppo del client Nostr iOS, particolarmente attorno alla privacy, l’efficienza di sincronizzazione e l’ottimizzazione dei dati mobili.

Integrazione Tor - PR #3535 incorpora il client Arti Tor direttamente in Damus, abilitando connessioni relay anonime senza dipendenze esterne. A differenza degli approcci Orbot o Tor Browser, incorporare Arti fornisce un’integrazione senza soluzione di continuità con il sandboxing iOS e i limiti di esecuzione in background. L’implementazione Rust porta la sicurezza della memoria all’anonimizzazione di rete, riducendo la superficie di attacco rispetto a C Tor. Gli utenti potrebbero attivare la modalità Tor per relay o globalmente, con il client che gestisce la gestione dei circuiti in modo trasparente.

Protocollo di Sincronizzazione Negentropy - PR #3536 implementa Negentropy, un protocollo di riconciliazione di set che migliora radicalmente l’efficienza di sincronizzazione. Invece di scaricare tutti gli eventi dall’ultima connessione, Negentropy scambia fingerprint compatti (alberi Merkle) per identificare esattamente quali eventi differiscono tra client e relay. Per gli utenti che seguono centinaia di pubkey, questo riduce la banda di sincronizzazione da megabyte a kilobyte. L’implementazione si integra con RelayPool e SubscriptionManager, abilitando la sincronizzazione efficiente automatica attraverso tutti i relay connessi.

Modalità Dati Bassi - PR #3549 aggiunge funzionalità di conservazione dei dati cellulari rispondendo al feedback degli utenti sul consumo di banda. La modalità disabilita il caricamento automatico delle immagini, il prefetching dei video e riduce i limiti di sottoscrizione. Gli utenti su connessioni a consumo possono navigare contenuti testuali senza paura di superare i limiti dati. L’implementazione rispetta le impostazioni della modalità dati bassi di iOS e fornisce controlli granulari per diversi tipi di media.

Ottimizzazioni Database - PR #3548 rilavora l’archiviazione snapshot nostrdb per query più veloci e uso ridotto del disco. L’ottimizzazione cambia come gli snapshot del database persistono su disco, migliorando sia le prestazioni di lettura che l’amplificazione di scrittura. Questo affronta le lamentele sul consumo della batteria da parte degli utenti con database eventi grandi.

È tutto per questa settimana. State costruendo qualcosa? Avete notizie da condividere? Volete che copriamo il vostro progetto? Contattateci via DM NIP-17 o trovateci su Nostr.

Nostr Compass #5

Tue, 13 Jan 2026 00:00:00 +0000

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

Questa settimana: Bitchat viene sottoposto a un audit di sicurezza professionale da Cure53, la stessa azienda che ha verificato Signal e NIP-44, con oltre 17 PR già integrate per correggere vulnerabilità critiche. NIP-71 è stato approvato, portando nel protocollo gli event video indirizzabili. Una NIP sulla crittografia post-quantistica apre la discussione sulla protezione futura di Nostr contro gli attacchi quantistici. Amethyst v1.05.0 introduce le liste di segnalibri, le note vocali e una versione desktop preliminare, mentre Nostur v1.25.3 migliora i DM NIP-17 con reazioni e risposte. Per quanto riguarda le librerie, rust-nostr estende il supporto NIP-62 ai backend SQLite e LMDB, e NDK corregge un bug nel tracciamento delle subscription.

Notizie

Bitchat Completa l’Audit di Sicurezza Cure53

Bitchat, il messenger crittografato per iOS che combina Nostr con Cashu, è stato sottoposto a un audit di sicurezza professionale da Cure53, una delle aziende di sicurezza più rispettate del settore. Cure53 ha precedentemente verificato Signal, Mullvad VPN e soprattutto la specifica di crittografia NIP-44 che è alla base della messaggistica privata moderna su Nostr.

L’audit ha rilevato oltre 12 problemi di sicurezza (BCH-01-002 fino a BCH-01-013). Il team di Bitchat ha risposto con oltre 17 pull request. Le correzioni principali includono:

Cancellazione dei Secret DH del Noise Protocol - PR #928 corregge sei punti in cui i secret condivisi Diffie-Hellman non venivano azzerati dopo lo scambio delle chiavi, ripristinando le garanzie di forward secrecy. Quando i secret persistono in memoria più a lungo del necessario, un dump della memoria o un attacco cold boot potrebbero compromettere le comunicazioni passate.

Verifica delle Firme - Diverse PR rafforzano i percorsi di verifica crittografica, assicurando che i controlli di autenticità dei messaggi non possano essere aggirati tramite input malformati.

Thread Safety - PR #929 aggiunge la sincronizzazione con barriere alle code delle ricevute di lettura in NostrTransport, prevenendo race condition che potrebbero causare corruzione dei dati o crash con alti volumi di messaggi.

Sicurezza della Memoria - PR #920 ottimizza il deduplicatore di messaggi per migliori prestazioni con alto throughput di messaggi, evitando l’esaurimento della memoria.

Validazione degli Input - PR #919 rafforza il parsing delle stringhe esadecimali per prevenire crash da input malformati, un vettore di attacco comune per denial-of-service.

Bitchat gestisce ecash Cashu, rendendo essenziale una revisione di sicurezza professionale. L’audit segue quello del Marmot Protocol dello scorso anno e l’audit NIP-44 che ha verificato il layer di crittografia.

Aggiornamenti NIP

Modifiche recenti al repository NIPs:

Approvate:

NIP-71 - Event Video Indirizzabili (#1669) introduce i kind 34235 (video orizzontale) e 34236 (video verticale) come event indirizzabili. Un tag d obbligatorio fornisce identificatori univoci, così i metadati video possono essere aggiornati senza ripubblicare l’intero event. Un tag origin opzionale traccia le fonti di importazione. Già implementato in Amethyst e nostrvine.

PR Aperte:

Crittografia Post-Quantistica - PR #2185 propone l’aggiunta di algoritmi crittografici resistenti ai computer quantistici in Nostr. La specifica introduce ML-DSA-44 e Falcon-512 per le firme digitali, mirando a “event di altissimo valore” come applicazioni e autorità piuttosto che singoli utenti. Mentre la crittografia simmetrica di NIP-44 (ChaCha20) è resistente ai quantum, il suo scambio di chiavi usa secp256k1 ECDH che è vulnerabile all’algoritmo di Shor. La proposta include ML-KEM per lo scambio di chiavi per colmare questa lacuna. Si tratta di una proposta in fase iniziale che apre la discussione sulla cripto-agilità per la sicurezza a lungo termine di Nostr.
BOLT12 per NIP-47 - Dopo 137 commenti e un’ampia discussione, la comunità ha deciso che le offer BOLT12 meritano una specifica propria piuttosto che estendere NIP-47. Le offer BOLT12 offrono miglioramenti significativi rispetto alle invoice BOLT11, inclusa la riusabilità, migliore privacy attraverso i blinded path e informazioni opzionali sul pagatore. La nuova NIP definirà metodi come make_offer, pay_offer e list_offers per le implementazioni Nostr Wallet Connect.
NIP per Tracce Audio - PR #1043 propone i kind 32100 per tracce musicali e 32101 per episodi podcast, dando ai contenuti audio lo stesso trattamento di prima classe che NIP-71 fornisce per i video. Attualmente, le piattaforme audio come Wavlake, Zapstr e Stemstr usano ciascuna formati di event proprietari, frammentando l’ecosistema. Uno standard comune permetterebbe l’interoperabilità così gli utenti potrebbero scoprire e riprodurre audio da qualsiasi client compatibile.
NIP-A3 Target di Pagamento Universali - PR #2119 propone event di kind 10133 che usano URI payto: RFC-8905 per esporre opzioni di pagamento su reti multiple. Invece di creare kind di event separati per Bitcoin, Lightning, Cashu o sistemi di pagamento tradizionali, questa astrazione permette ai client di interpretare tag standardizzati e invocare handler di pagamento nativi. L’approccio è a prova di futuro poiché i nuovi metodi di pagamento necessitano solo di uno schema URI payto:.

Approfondimento NIP: NIP-51 e NIP-65

Questa settimana trattiamo due NIP che memorizzano le preferenze utente: NIP-51 per organizzare i contenuti e NIP-65 per organizzare le connessioni ai relay. Entrambe usano event sostituibili, il che significa che ogni nuova pubblicazione sovrascrive la versione precedente.

NIP-51: Liste

NIP-51 definisce diversi tipi di liste per organizzare riferimenti a event, utenti, hashtag e altri contenuti. Amethyst v1.05.0 aggiunge il supporto ai segnalibri, rendendo questo un buon momento per capire come funzionano le liste.

La specifica definisce diversi kind di liste, ciascuno con uno scopo diverso. Il kind 10000 è la vostra lista di silenziamento per nascondere utenti, thread o parole. Il kind 10001 fissa event da mettere in evidenza sul vostro profilo. Il kind 30003 memorizza i segnalibri, che è ciò che Amethyst ora supporta. Altri kind gestiscono set di following (30000), collezioni di articoli curate (30004), interessi per hashtag (30015) e set di emoji personalizzate (30030).

Le liste referenziano contenuti attraverso tag. Una lista di segnalibri usa tag e per event specifici e tag a per contenuti indirizzabili come articoli:

{
 "id": "ae3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1736784000,
 "kind": 30003,
 "tags": [
 ["d", "saved-articles"],
 ["e", "abc123def456...", "wss://relay.example"],
 ["a", "30023:author-pubkey:article-id", "wss://relay.example"]
 ],
 "content": "<encrypted-private-bookmarks>",
 "sig": "908a15e46fb4d8675bab026fc230a0e3542bfade63da02d542fb78b2a8513fcd0092619a2c8c1221e581946e0191f2af505dfdf8657a414dbca329186f009262"
}

Il tag d fornisce un identificatore univoco, così potete mantenere più set di segnalibri come “saved-articles”, “read-later” o “favorites” sotto lo stesso kind.

Le liste supportano sia elementi pubblici che privati. Gli elementi pubblici appaiono nell’array dei tag, visibili a chiunque recuperi l’event. Gli elementi privati vanno nel campo content, crittografati usando NIP-44 verso voi stessi. Questa doppia struttura vi permette di mantenere segnalibri pubblici aggiungendo note private, o mantenere una lista di silenziamento senza rivelare chi avete silenziato. Per crittografare verso voi stessi, usate NIP-44 con la vostra pubkey come destinatario.

I kind della serie 10000 sono sostituibili, il che significa che i relay mantengono un solo event per pubkey. La serie 30000 è sostituibile parametrizzata, permettendo un event per combinazione di pubkey e tag d. In entrambi i casi, aggiornare una lista significa pubblicare una sostituzione completa; non potete inviare modifiche incrementali. I client dovrebbero preservare i tag sconosciuti quando modificano le liste per evitare di sovrascrivere dati aggiunti da altre applicazioni.

NIP-65: Metadati Lista Relay

NIP-65 definisce event di kind 10002 che pubblicizzano quali relay un utente preferisce per leggere e scrivere. Questo aiuta altri utenti e client a trovare i vostri contenuti.

{
 "id": "bd2217a96b5835b59f9a6a42d8d8a36f8c9b7d4e5f0a1b2c3d4e5f6a7b8c9d0e1",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1736784000,
 "kind": 10002,
 "tags": [
 ["r", "wss://relay.damus.io", "read"],
 ["r", "wss://nos.lol"],
 ["r", "wss://relay.nostr.band", "write"]
 ],
 "content": "",
 "sig": "f1c2d3e4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2"
}

Ogni tag r contiene un URL del relay e un marcatore opzionale. Un marcatore write designa la vostra outbox: relay dove pubblicate i vostri contenuti. Un marcatore read designa la vostra inbox: relay dove controllate menzioni, risposte e tag. Omettere il marcatore indica entrambi.

Quando Alice vuole trovare i post di Bob, il suo client recupera il kind 10002 di Bob, estrae i suoi relay write (la sua outbox) e si iscrive lì. Quando Alice risponde a Bob, il suo client pubblica sui suoi relay read (la sua inbox) così lui vedrà la menzione. Questo routing consapevole dei relay è il “modello outbox”, e distribuisce gli utenti su molti relay invece di concentrare tutti su pochi server centrali.

NIP-65 gestisce il routing dei contenuti pubblici, ma i messaggi privati usano una lista separata. NIP-17 definisce il kind 10050 per i relay inbox dei DM, usando tag relay invece di tag r. Quando inviate a qualcuno un messaggio privato, i client cercano l’event kind 10050 del destinatario e pubblicano lì il messaggio crittografato gift-wrapped. Questa separazione mantiene il routing dei DM distinto dal routing dei contenuti pubblici, e permette agli utenti di specificare relay diversi per comunicazioni private rispetto a quelle pubbliche.

Il modello outbox migliora la resistenza alla censura poiché nessun singolo relay deve memorizzare o servire i contenuti di tutti. I client mantengono connessioni ai relay elencati negli event NIP-65 degli utenti seguiti, collegandosi dinamicamente a nuovi relay mentre scoprono nuovi account. NIP-65 complementa gli hint dei relay trovati in altre NIP. Quando taggate qualcuno con ["p", "pubkey", "wss://hint.relay"], l’hint dice ai client dove cercare quel riferimento specifico. NIP-65 fornisce la lista autorevole controllata dall’utente, mentre gli hint offrono scorciatoie incorporate nei singoli event.

Per migliori risultati, mantenete aggiornata la vostra lista di relay poiché voci obsolete vi rendono più difficili da trovare. La specifica raccomanda da due a quattro relay per categoria. Elencare troppi relay grava su ogni client che vuole recuperare i vostri contenuti, rallentando la loro esperienza e aumentando il carico di rete. I client memorizzano in cache gli event NIP-65 e li aggiornano periodicamente per rimanere al passo con le preferenze aggiornate degli utenti.

Release

Amethyst v1.05.0 - Il popolare client Android rilascia un aggiornamento importante con diverse funzionalità di rilievo. Le liste di segnalibri NIP-51 kind 30003 permettono agli utenti di salvare post per riferimento futuro, sincronizzandosi tra client compatibili. Le note vocali ora funzionano nei DM e nei post regolari con visualizzazione della forma d’onda, selezione del media server e indicatori di progresso del caricamento. I punteggi Web of Trust sono ora visibili nell’interfaccia, aiutando gli utenti a capire come l’algoritmo valuta gli account relativamente al loro grafo sociale. La migrazione del database Quartz migliora le prestazioni delle query come parte del lavoro Kotlin Multiplatform finanziato da OpenSats. Una release desktop preliminare porta Amethyst su Windows, macOS e Linux tramite Compose Multiplatform, condividendo lo stesso codebase dell’app Android. Nuovi flussi di onboarding per gli utenti facilitano l’esperienza per chi usa Nostr per la prima volta.

Nostur v1.25.3 - Il client iOS e macOS si concentra sulla messaggistica privata con miglioramenti a NIP-17. Le conversazioni DM ora supportano reazioni e risposte, portando l’interattività dei post pubblici nei messaggi crittografati. La vista delle conversazioni è stata rielaborata con un migliore threading così gli scambi multi-messaggio sono più facili da seguire, e i timestamp mostrano “tempo fa” nella lista DM per una scansione rapida. Gli utenti desktop ottengono layout multi-colonna per visualizzare feed o conversazioni multiple affiancate. Il supporto al remote signer NIP-46 permette agli utenti di mantenere le loro chiavi private in app di firma dedicate come Amber o nsec.app. Correzioni aggiuntive ripristinano la funzionalità DM su iOS 15 e iOS 16, risolvono ritardi nelle notifiche e aggiungono la possibilità di configurare quali relay ricevono i DM pubblicati.

Modifiche notevoli a codice e documentazione

Queste sono pull request aperte e lavori in fase iniziale, perfetti per ricevere feedback prima del merge. Se qualcosa vi interessa, considerate di fare review o commentare!

Citrine (Relay Android)

PR #89 corregge una vulnerabilità SQL injection nell’app relay personale Android. Il problema permetteva a dati di event malformati di eseguire query arbitrarie sul database, un difetto grave per qualsiasi app che memorizza ed elabora input non fidati. La correzione sanifica correttamente tutte le operazioni sul database usando query parametrizzate. Non è ancora stata taggata una release, quindi gli utenti dovranno aspettare la prossima versione o compilare dal sorgente. PR #90 ottimizza le prestazioni delle query ContentProvider con filtraggio e paginazione a livello di database, riducendo la latenza quando app esterne come Amethyst accedono al database di event di Citrine attraverso il layer di comunicazione inter-processo di Android.

rust-nostr (Libreria)

Il supporto a NIP-62 (Richieste di Scomparsa) si sta espandendo attraverso i backend di database di rust-nostr. PR #1180, integrata due settimane fa, ha aggiunto il supporto NIP-62 a SQLite, gestendo le richieste di scomparsa ALL_RELAYS poiché il layer del database non conosce URL specifici dei relay. PR #1210 estende questo al backend LMDB, assicurando che le richieste di scomparsa siano persistite su disco e sopravvivano ai riavvii del relay. Un’implementazione IndexedDB per ambienti browser è anche in corso. Insieme, queste modifiche danno agli sviluppatori un supporto NIP-62 coerente attraverso SQLite, LMDB e presto lo storage del browser.

NDK (Nostr Development Kit)

PR #375 corregge un bug nel sistema di tracciamento seenEvents. Il problema causava che certi pattern di subscription marcassero erroneamente gli event come già visti, portando a contenuti mancati quando gli utenti aprivano nuove subscription o si riconnettevano ai relay. La correzione assicura che gli event siano tracciati accuratamente attraverso i cicli di vita delle subscription, il che è particolarmente importante per applicazioni che si iscrivono e cancellano dinamicamente in base alla navigazione dell’utente. NDK è passato alla beta.70 con questa correzione inclusa.

Damus (iOS)

PR #3515 corregge un crash all’avvio che colpiva gli utenti iOS 17. Il problema derivava da un overflow aritmetico in NdbUseLock, una classe di fallback usata perché i Mutex di Swift non sono disponibili su iOS 17. La correzione sostituisce l’approccio di sincronizzazione precedente con NSLock, che è disponibile su iOS 17 e gestisce correttamente le race condition rimanenti. Gli utenti iOS 18+ non erano colpiti poiché hanno accesso all’implementazione nativa del Mutex Swift.

Separatamente, un gruppo di miglioramenti per gli articoli longform è arrivato tramite PR #3509. Le barre di progresso della lettura tracciano la vostra posizione attraverso gli articoli, i tempi di lettura stimati appaiono nelle anteprime, e la modalità seppia con impostazioni di altezza riga regolabili forniscono una lettura più confortevole. La modalità focus nasconde automaticamente la chrome di navigazione durante lo scorrimento verso il basso e la ripristina al tocco, riducendo il disordine visivo per una lettura senza distrazioni. Diverse correzioni affrontano la visualizzazione delle immagini nei contenuti markdown e assicurano che gli articoli si aprano dall’inizio piuttosto che a metà.

Zap.stream (Live Streaming)

L’integrazione della chat di YouTube e Kick collega i messaggi dalle piattaforme di streaming esterne a Nostr. Gli streamer che trasmettono in multicast su YouTube, Kick e Zap.stream possono ora vedere tutti i messaggi della chat in una vista unificata, con i messaggi da ogni piattaforma che appaiono accanto ai commenti nativi Nostr. Questo rimuove un importante punto di attrito per i creator che vogliono usare Nostr per lo streaming ma non possono abbandonare il pubblico sulle piattaforme consolidate. L’integrazione mostra da quale piattaforma ha origine ogni messaggio e gestisce il flusso di autenticazione per connettere account esterni.

Chachi (Gruppi NIP-29)

Il client di chat di gruppo NIP-29 ha integrato sei PR questa settimana. Un aggiornamento di sicurezza affronta CVE-2026-22029, una vulnerabilità XSS in react-router che potrebbe abilitare attacchi di open redirect; la correzione aggiorna a react-router-dom 6.30.0. PR #92 aggiunge il caricamento paginato dei messaggi per le chat di gruppo, così le conversazioni lunghe si caricano incrementalmente piuttosto che tutte insieme. PR #91 corregge diversi bug NIP-29 inclusa una race condition che causava nomi di gruppo vuoti al caricamento iniziale e liste di partecipanti non definite che facevano crashare le viste dei membri. La copertura delle traduzioni ora copre tutte le 31 lingue supportate con 1060 chiavi ciascuna.

0xchat (Messaggistica)

Il client di messaggistica stile Telegram ha migliorato la conformità a NIP-55 salvando correttamente i nomi dei pacchetti dei signer quando si usano app di firma esterne, correggendo problemi in cui l’app perdeva traccia di quale signer usare dopo i riavvii. La gestione delle risposte NIP-17 ora include correttamente il tag e per il threading, assicurando che le risposte appaiano nel contesto di conversazione corretto attraverso i client. Le ottimizzazioni delle prestazioni affrontano il lag di scorrimento nelle liste di messaggi, un punto dolente comune quando si caricano cronologie di chat lunghe. Il salvataggio automatico delle bozze previene la perdita di messaggi se navigate via durante la composizione, e le opzioni di archiviazione file ora includono endpoint predefiniti FileDropServer e BlossomServer.

Primal (iOS)

Il supporto al remote signer NIP-46 arriva su iOS tramite PR #184, completando il rollout cross-platform iniziato con Android diverse settimane fa. Gli utenti possono ora mantenere le loro chiavi private in servizi bunker dedicati come nsec.app o istanze nsecBunker self-hosted, connettendosi attraverso relay Nostr per firmare event senza esporre le chiavi all’app client. Questa separazione migliora la postura di sicurezza per gli utenti che vogliono usare le funzionalità di Primal mantenendo pratiche di gestione delle chiavi più rigorose. L’implementazione include la scansione di codici QR per gli URI di connessione al bunker e gestisce il flusso richiesta/risposta NIP-46 attraverso messaggi relay crittografati.

Questo è tutto per questa settimana. State costruendo qualcosa? Avete notizie da condividere? Volete che copriamo il vostro progetto? Contattateci tramite DM NIP-17 o trovateci su Nostr.

Nostr Compass #4

Wed, 07 Jan 2026 00:00:00 +0000

Bentornati su Nostr Compass, la vostra guida settimanale all’ecosistema del protocollo Nostr.

Questa settimana: Primal Android implementa la firma remota NIP-46 e il supporto per signer locali NIP-55, trasformandosi in un hub di firma completo per altre app Android. Il team del Marmot Protocol ha affrontato le problematiche emerse da un audit di sicurezza con 18 PR integrate che rafforzano la messaggistica crittografata basata su MLS. Citrine raggiunge la v1.0 e Applesauce rilascia la v5.0 per l’intera suite di librerie. TENEX sviluppa la supervisione di agenti AI su Nostr, e Jumble aggiunge il pooling intelligente dei relay. Una correzione alla specifica NIP-55 chiarisce i campi di ritorno di nip44_encrypt, e una PR per NIP-50 propone estensioni per espressioni di query per ricerche avanzate. Nel nostro approfondimento, spieghiamo NIP-04 e NIP-44: perché la crittografia legacy presenta falle di sicurezza e come la sostituzione moderna le risolve.

Notizie

Primal Android diventa un Hub di Firma Completo - La Versione 2.6.18 aggiunge sia la firma remota NIP-46 che la firma locale NIP-55, trasformando Primal in un signer completo per altre app Nostr. La firma remota tramite NIP-46 permette agli utenti di connettersi a servizi bunker attraverso i relay Nostr, mantenendo le chiavi completamente fuori dal dispositivo. La firma locale tramite NIP-55 espone Primal come content provider Android, così app come Amethyst o Citrine possono richiedere firme senza mai toccare la chiave privata. Diverse PR successive hanno risolto problemi di compatibilità con il requisito della specifica NIP-55 per pubkey esadecimali, e migliorato il parsing di URI nostrconnect:// malformati. Il rilascio include anche pre-caching dei media per uno scorrimento più fluido, tempi di caricamento dei thread migliorati e pre-caching degli avatar.

Marmot Protocol rafforza la sicurezza dopo l’Audit - Il Marmot Development Kit (mdk), che implementa la messaggistica end-to-end crittografata basata su NIP-104 MLS, ha ricevuto ampie correzioni di sicurezza questa settimana. Diciotto pull request integrate hanno affrontato le problematiche dell’audit tra cui: verifica hash per immagini di gruppo crittografate per prevenire attacchi di sostituzione blob a livello storage, paginazione per welcome pendenti per prevenire esaurimento della memoria, perdita di MLS Group ID nei messaggi di errore, e applicazione della codifica base64 per i key package. La specifica Marmot stessa è stata aggiornata con MIP-04 v2 versioning e miglioramenti di sicurezza. PR attive continuano ad affrontare riuso di nonce, azzeramento dei segreti e vettori di inquinamento della cache.

Nostrability traccia il supporto Relay Hint - Un nuovo tracker di compatibilità relay hints documenta come i client costruiscono e consumano relay hint nell’ecosistema. Il tracker rivela che mentre la maggior parte dei client ora costruisce hint secondo NIP-10 e NIP-19, il consumo varia ampiamente: alcuni client includono hint negli eventi in uscita ma non usano gli hint in entrata per il recupero. Sei client hanno ottenuto lo status “Full” per implementazione completa. Il tracker è utile per sviluppatori che verificano l’interoperabilità e per utenti che si chiedono perché alcuni client trovano contenuti che altri non riescono a trovare.

Nostria 2.0 rilascia revisione completa delle funzionalità Cross-Platform - Il client Nostria ha rilasciato la versione 2.0 il 30 dicembre con aggiunte significative su iOS (TestFlight), Android (Play Store), Web e Windows. Il rilascio aggiunge supporto nativo per la musica con creazione di playlist, caricamento di tracce, pagamenti agli artisti basati su zap, e un player in stile WinAmp con equalizzatore funzionante. Lo streaming live ottiene l’integrazione Game API che mostra metadati ricchi durante gli streaming di gameplay. Una nuova funzione Summary genera digest di attività orari, giornalieri o settimanali come viste timeline compresse. La sezione Discover offre liste curate per trovare contenuti e profili. La pubblicazione di media è semplificata con generazione automatica di post short-form per la scoperta cross-client. Le connessioni ai signer remoti ora funzionano tramite scansione di codici QR senza configurazione manuale. La scoperta dei profili affronta un problema comune di Nostr: quando gli utenti si spostano tra relay senza portare i propri metadati, Nostria localizza il loro profilo e lo ripubblica sui relay correnti. Gli abbonati Premium ottengono integrazione con canali YouTube, Memo privati, dashboard analitiche e backup automatici delle liste di following con opzioni di merge/restore.

Aggiornamenti NIP

Modifiche recenti al repository NIPs:

Integrate:

NIP-55 - Corretto il campo di ritorno per il metodo nip44_encrypt (#2184). I signer Android devono ora restituire il payload crittografato nel campo signature (come nip44_decrypt) invece che in un campo separato. Questo allinea la specifica con le implementazioni esistenti in Amber e Primal.

PR Aperte:

NIP-50 - Estensioni Espressioni di Query (#2182) propone di estendere la ricerca NIP-50 con espressioni di query strutturate. La PR aggiunge operatori come kind:1, author:npub1..., e combinazioni booleane (AND, OR, NOT), abilitando query di ricerca più precise oltre il semplice matching testuale. Questo permetterebbe ai client di costruire interfacce di ricerca avanzate mantenendo la retrocompatibilità con stringhe di ricerca base.

Approfondimento NIP: NIP-04 e NIP-44

Questa settimana copriamo gli standard di crittografia Nostr: il legacy NIP-04 che incontrerete ancora, e la sua sostituzione moderna NIP-44 che corregge falle di sicurezza critiche.

NIP-04: Messaggi Diretti Crittografati (Legacy)

NIP-04 è stato il primo tentativo di Nostr per la messaggistica crittografata, usando eventi di kind 4. Sebbene semplice da implementare, ha debolezze di sicurezza note ed è deprecato in favore di NIP-44.

Come funziona: NIP-04 usa ECDH (Elliptic Curve Diffie-Hellman) per derivare un segreto condiviso tra mittente e destinatario, poi crittografa con AES-256-CBC.

{
 "id": "<event-id>",
 "pubkey": "<sender-pubkey>",
 "created_at": 1736200000,
 "kind": 4,
 "tags": [["p", "<recipient-pubkey>"]],
 "content": "base64-ciphertext?iv=base64-iv",
 "sig": "<signature>"
}

Il flusso di crittografia:

Calcola il punto condiviso: shared = ECDH(sender_privkey, recipient_pubkey)
Deriva la chiave: key = SHA256(shared_x_coordinate)
Genera IV casuale di 16 byte
Crittografa: ciphertext = AES-256-CBC(key, iv, plaintext)
Formatta il contenuto: base64(ciphertext)?iv=base64(iv)

Problemi di sicurezza:

Nessuna autenticazione: AES-CBC fornisce confidenzialità ma non integrità. Un attaccante che controlla un relay potrebbe modificare bit del ciphertext, causando modifiche prevedibili al plaintext (attacchi bit-flipping).
IV in chiaro: Il vettore di inizializzazione è trasmesso insieme al ciphertext, e la modalità CBC con IV prevedibili abilita attacchi chosen-plaintext.
Nessuna validazione del padding: Le implementazioni variano nel modo in cui gestiscono il padding PKCS#7, potenzialmente abilitando attacchi padding oracle.
Esposizione dei metadati: La pubkey del mittente, la pubkey del destinatario e il timestamp sono tutti visibili ai relay.
Riuso della chiave: Lo stesso segreto condiviso è usato per tutti i messaggi tra due parti, per sempre.

Perché esiste ancora: Molti client e relay più vecchi supportano solo NIP-04. Lo incontrerete quando interagite con sistemi legacy. Signer come Amber e app come Primal implementano ancora nip04_encrypt/nip04_decrypt per retrocompatibilità.

NIP-44: Crittografia Versionata

NIP-44 è lo standard di crittografia moderno, progettato per correggere le falle note di NIP-04. Un audit di sicurezza Cure53 delle implementazioni NIP-44 ha identificato 10 problemi (inclusi attacchi temporali e preoccupazioni sulla forward secrecy) che sono stati affrontati prima della finalizzazione della specifica. Usa ChaCha20-Poly1305 con derivazione di chiave appropriata e crittografia autenticata.

Miglioramenti chiave rispetto a NIP-04:

Aspetto	NIP-04	NIP-44
Cifrario	AES-256-CBC	XChaCha20-Poly1305
Autenticazione	Nessuna	Poly1305 MAC
Derivazione chiave	SHA256(shared_x)	HKDF con salt
Nonce	IV 16 byte, pattern riusato	Nonce casuale 24 byte
Padding	PKCS#7 (rivela lunghezza)	Arrotondato a potenza di 2
Versionamento	Nessuno	Prefisso byte versione

Flusso di crittografia:

Chiave di conversazione: Deriva una chiave stabile per ogni coppia mittente-destinatario:

shared_x = ECDH(sender_privkey, recipient_pubkey).x
conversation_key = HKDF-SHA256(
 ikm = shared_x,
 salt = "nip44-v2",
 info = ""
)

Chiavi del messaggio: Per ogni messaggio, genera un nonce casuale di 32 byte e deriva chiavi di crittografia/autenticazione:

keys = HKDF-SHA256(
 ikm = conversation_key,
 salt = nonce,
 info = "nip44-v2"
)
chacha_key = keys[0:32]
chacha_nonce = keys[32:44]
hmac_key = keys[44:76]

Padding del plaintext: Arrotonda alla prossima potenza di 2 (minimo 32 byte) per nascondere la lunghezza del messaggio:
```
padded = [length_u16_be] + [plaintext] + [zeri fino alla prossima potenza di 2]
```

Crittografa e autentica:

ciphertext = XChaCha20(chacha_key, chacha_nonce, padded)
mac = HMAC-SHA256(hmac_key, nonce + ciphertext)

Formatta il payload:

payload = [version=0x02] + [nonce] + [ciphertext] + [mac]
content = base64(payload)

Byte di versione: Il primo byte (0x02) indica la versione di crittografia. Questo permette upgrade futuri senza compromettere i messaggi esistenti. La versione 0x01 era una bozza precedente mai ampiamente distribuita.

Decrittografia:

Decodifica base64, verifica che il byte di versione sia 0x02
Estrai nonce (byte 1-32), ciphertext e MAC (ultimi 32 byte)
Deriva la chiave di conversazione usando la chiave privata del destinatario e la chiave pubblica del mittente
Deriva le chiavi del messaggio dalla chiave di conversazione e dal nonce
Verifica il MAC prima di decrittografare (rifiuta se non valido)
Decrittografa il ciphertext, estrai il prefisso di lunghezza, restituisci il plaintext senza padding

Proprietà di sicurezza:

Crittografia autenticata: Il MAC Poly1305 assicura che qualsiasi manomissione sia rilevata prima della decrittografia
Forward secrecy (parziale): Ogni messaggio usa un nonce unico, quindi compromettere un messaggio non rivela gli altri. Tuttavia, compromettere una chiave privata rivela comunque tutti i messaggi passati (nessun ratcheting).
Occultamento della lunghezza: Il padding a potenza di 2 oscura la lunghezza esatta del messaggio
Resistenza agli attacchi temporali: Confronto a tempo costante per la verifica del MAC

Uso pratico: NIP-44 è il livello di crittografia per:

NIP-17 messaggi diretti privati (dentro gift wrap)
NIP-46 comunicazione con signer remoti
NIP-59 crittografia seal
Marmot Protocol messaggi di gruppo, dove NIP-44 avvolge contenuto crittografato MLS usando una chiave derivata dal segreto esportatore MLS
Qualsiasi applicazione che necessita crittografia sicura punto-a-punto

Guida alla migrazione: Le nuove applicazioni dovrebbero usare esclusivamente NIP-44. Per retrocompatibilità, verificate se il client del contatto supporta NIP-44 (tramite metadati app NIP-89 o supporto relay) prima di ricadere su NIP-04. Quando ricevete messaggi, tentate prima la decrittografia NIP-44, poi ricadete su NIP-04 per contenuti legacy.

Rilasci

Primal Android v2.6.18 - Il rilascio completo aggiunge firma remota NIP-46 e firma locale NIP-55, trasformando Primal in un hub di firma per altre app Android. I miglioramenti delle prestazioni includono pre-caching dei media, pre-caching degli avatar e caricamento più veloce dei thread. Le correzioni di bug affrontano auto-menzioni nelle bio, crash nella galleria media e fallback dei titoli degli stream. Su iOS, Primal usa la riproduzione audio in background per mantenere l’app attiva per ricevere richieste di firma NIP-46; gli utenti possono cambiare il suono o silenziarlo completamente nelle impostazioni.

Mostro v0.15.6 - L’ultimo rilascio della piattaforma di trading P2P Bitcoin NIP-69 completa l’implementazione del fondo di sviluppo con gli eventi di audit della Fase 4. I pagamenti delle commissioni dev sono ora tracciati tramite eventi Nostr kind 38383 pubblicati dopo ogni pagamento riuscito, abilitando verifica e analytics di terze parti. I calcoli degli importi sono stati corretti per i messaggi acquirente/venditore, e la logica del premium è stata allineata con l’implementazione di riferimento lnp2pbot.

Aegis v0.3.5 - Il signer cross-platform aggiunge la modalità scura, visualizzazione migliorata delle icone app e layout UI più puliti. Le correzioni di bug affrontano conflitti iOS iCloud Private Relay e problemi di parsing degli eventi. Il rilascio migliora anche come il JSON degli eventi viene passato alla funzione di firma Rust.

Citrine v1.0.0 - L’app relay Android raggiunge la 1.0. Citrine permette di eseguire un relay Nostr personale direttamente sul dispositivo Android, utile per caching locale, backup o come companion NIP-55. Questo rilascio aggiunge un gestore di crash report, migliora l’efficienza delle query database e aggiorna le traduzioni tramite Crowdin.

Applesauce v5.0.0 - La suite di librerie TypeScript di hzrd149 rilascia una major version con breaking changes focalizzati su correttezza e semplicità. Il pacchetto core ora verifica le firme degli eventi per default e rinomina i metodi coordinate per usare terminologia “address” più chiara (parseCoordinate -> parseReplaceableAddress). Il pacchetto relay abbassa i retry di default da 10 a 3 e ignora i relay irraggiungibili per default, più aggiunge createUnifiedEventLoader per un recupero eventi più semplice. Il pacchetto wallet ottiene la scoperta mint Cashu NIP-87. Le dipendenze dirette da nostr-tools sono state rimosse dai pacchetti, riducendo dimensione del bundle e conflitti di versione.

Modifiche notevoli a codice e documentazione

Queste sono pull request aperte e lavori in fase iniziale, perfetti per ricevere feedback prima del merge. Se qualcosa vi interessa, considerate di revisionare o commentare!

Damus (iOS)

Una serie di PR migliorano l’esperienza degli articoli longform. Miglioramenti UX di lettura aggiungono una barra di progresso, tempo di lettura stimato, modalità seppia, altezza delle righe regolabile e modalità focus che nasconde la navigazione durante lo scorrimento. Correzioni immagini assicurano che le immagini nel contenuto markdown vengano visualizzate con proporzioni corrette preprocessando le immagini standalone come elementi block-level. Card anteprima longform sostituiscono il testo inline @naddr1... con card di anteprima ricche che mostrano titolo dell’articolo e metadati. Una nuova suite di test di integrazione relay aggiunge 137 test relativi alla rete inclusa verifica protocollo NIP-01 e comportamento in condizioni di rete degradate (simulazione 3G).

Bitchat (Messaggistica Crittografata)

Rafforzamento della sicurezza nel messenger iOS Nostr+Cashu. Pulizia segreti DH protocollo Noise corregge sei posizioni dove i segreti condivisi non venivano azzerati dopo l’accordo chiavi Diffie-Hellman, ripristinando le garanzie di forward secrecy. Thread safety per code read receipt aggiunge sincronizzazione barrier per prevenire race condition in NostrTransport. Ottimizzazione deduplicatore messaggi migliora le prestazioni con alti volumi di messaggi, e rafforzamento parsing stringhe hex previene crash da input malformato.

Frostr (Firma a Soglia)

Il protocollo di firma a soglia basato su FROST ha aggiunto visualizzazione codici QR per credenziali di gruppo e credenziali di share durante l’onboarding e nell’interfaccia signer. Questo abilita una configurazione più semplice quando si distribuiscono key share su dispositivi multipli, permettendo agli utenti di scansionare credenziali invece di copiare manualmente stringhe lunghe.

Marmot mdk (Libreria)

Oltre alle correzioni di sicurezza menzionate sopra, PR attive affrontano i rimanenti risultati dell’audit: Tipo Secret per azzeramento introduce un tipo wrapper che azzera automaticamente i dati sensibili alla distruzione, paginazione query messaggi previene esaurimento memoria durante il caricamento della cronologia chat, e storage crittografato aggiunge crittografia a riposo per il database SQLite che memorizza stato di gruppo e messaggi.

Amethyst (Android)

Una settimana intensa di correzioni di stabilità nel client Android. Parsing JSON tollerante previene crash da eventi malformati rendendo Kotlin Serialization più permissiva. La validazione eventi ora controlla la dimensione del campo kind prima dell’elaborazione per evitare eccezioni da valori sovradimensionati. La UI del trust score ha ottenuto un’icona più piccola per ridurre l’interferenza visiva, e logging errori migliorato aiuta a diagnosticare problemi di connessione ai relay. Aggiornamenti delle traduzioni sono arrivati tramite Crowdin, e diversi warning SonarQube sono stati affrontati.

TENEX (Agenti AI)

Il framework di agenti AI nativo Nostr ha visto 81 commit questa settimana per costruire capacità autonome. Il nuovo sistema di supervisione agenti implementa euristiche comportamentali per monitorare le azioni degli agenti e intervenire quando necessario. Trasparenza della delega aggiunge logging degli interventi utente alle trascrizioni di delega, così gli utenti possono verificare cosa hanno fatto gli agenti per loro conto. Il registro provider LLM è stato modularizzato per una più facile integrazione di diversi backend AI. Il supporto conversazioni cross-project permette agli agenti di mantenere il contesto attraverso multipli progetti basati su Nostr.

Jumble (Client Web)

Il client web focalizzato sui relay ha aggiunto diversi miglioramenti all’esperienza utente. Pool relay intelligente gestisce intelligentemente le connessioni basandosi sui pattern di utilizzo. Toggle feed live permette agli utenti di passare tra streaming in tempo reale e refresh manuale. Auto-mostra nuove note in cima fa emergere contenuto fresco senza richiedere ricaricamento della pagina. Cache persistente per feed following e notifiche migliora i tempi di caricamento alle visite successive. Gli utenti possono ora cambiare i relay di default attraverso le impostazioni.

Questo è tutto per questa settimana. State costruendo qualcosa? Avete notizie da condividere? Volete che copriamo il vostro progetto? Contattateci via NIP-17 DM o trovateci su Nostr.

Nostr Compass #3

Wed, 31 Dec 2025 00:00:00 +0000

Bentornati a Nostr Compass, la vostra guida settimanale all’ecosistema del protocollo Nostr.

Questa settimana: mentre il 2025 si chiude, ripercorriamo cinque anni di traguardi di dicembre nell’evoluzione di Nostr. Dal primo rilascio client di fiatjaf nel dicembre 2020, passando per la decisiva donazione di 14 BTC di Jack Dorsey nel dicembre 2022, fino alla proliferazione dei signer NIP-55 di questo mese e all’accelerazione di 162x della cache di NDK, dicembre ha segnato con costanza momenti di svolta per il protocollo. Questo numero speciale segue la storia tecnica attraverso ogni dicembre, documentando la crescita del protocollo da due relay sperimentali a oltre 2.500 nodi in 50 paesi. In più: il modulo desktop di Amethyst prende forma tramite Quartz, Notedeck guadagna la messaggistica, Citrine ospita web app, e NIP-54 corregge l’internazionalizzazione per gli script non latini.

Retrospettiva di Dicembre: Cinque Dicembre di Nostr

Quest’anno Nostr compie cinque anni. fiatjaf ha avviato il protocollo il 7 novembre 2020, e ogni dicembre da allora ha segnato una fase distinta della sua evoluzione: da proof of concept a movimento globale fino a ecosistema di produzione. Questa è una retrospettiva tecnica da dicembre 2020 a dicembre 2025, gli anni formativi che hanno stabilito le fondamenta di Nostr e ne hanno catalizzato il momento di svolta.

Dicembre 2020: Genesi

Il primo mese completo di esistenza di Nostr ha visto fiatjaf pubblicare Branle, il primo client del protocollo, costruito con Quasar (Vue.js) e absurd-sql per lo storage locale. fiatjaf aveva già definito l’architettura di base: utenti identificati da chiavi pubbliche secp256k1, tutti i post firmati crittograficamente, relay che fungono da storage stupido senza comunicare tra loro. Uno o due relay sperimentali servivano un piccolo gruppo di primi adottanti che si coordinavano nel gruppo Telegram @nostr_protocol, lanciato il 16 novembre. La documentazione originale descriveva “il più semplice protocollo aperto capace di creare un social network globale resistente alla censura”, una premessa che avrebbe richiesto altri due anni per dimostrarsi.

Dicembre 2021: Sviluppo Iniziale

Il 31 dicembre 2021, Nostr è arrivato sulla front page di Hacker News con 110 punti e 138 commenti, grazie a una submission di Cameri. Questo ha segnato la prima esposizione significativa del protocollo alla più ampia comunità di sviluppatori. La rete funzionava su circa sette relay con meno di 1.000 utenti. Branle ha ricevuto aggiornamenti inclusa l’importazione di chiavi private il 31 dicembre e il supporto multi-relay. Un client da riga di comando, noscl, forniva interazione da terminale. Le specifiche del protocollo esistevano nella documentazione di fiatjaf, anche se il repository formale dei NIPs non sarebbe stato creato fino a maggio 2022. Il protocollo era, come lo descriveva fiatjaf, “un work in progress”.

Dicembre 2022: Il Punto di Svolta

Dicembre 2022 ha trasformato Nostr da esperimento di nicchia a movimento mainstream. Il catalizzatore è arrivato il 15 dicembre, quando Jack Dorsey ha donato 14.17171699 BTC (~$245.000-$250.000) a fiatjaf dopo aver scoperto il protocollo e aver dichiarato che era “al 100 percento ciò che volevamo da Bluesky, ma non era sviluppato da un’azienda”. Il 16 dicembre fiatjaf ha annunciato la divisione dei fondi con William Casarin (jb55), sviluppatore di Damus, e Dorsey ha verificato il suo account Nostr (npub: npub1sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m). Il finanziamento ha legittimato il progetto dall’oggi al domani.

Nella stessa settimana, il caos di Twitter ha accelerato l’adozione. Il 14-15 dicembre sono arrivate le sospensioni di giornalisti di primo piano del New York Times, CNN e Washington Post. Il 18 dicembre Twitter ha annunciato il divieto per gli account che promuovevano Nostr, Mastodon e altre piattaforme. La policy è stata revocata il giorno successivo dopo il contraccolpo pubblico. L’esodo ha spinto gli utenti a esplorare alternative.

Lo sviluppo del protocollo ha subito un’impennata. Il 16 dicembre è stato unito NIP-19 (#57), introducendo identificatori codificati in bech32 (npub, nsec, note, nprofile, nevent) che rendevano le chiavi leggibili dagli umani e distinguibili. Il repository NIPs ha registrato oltre 36 commit quel mese, inclusi aggiornamenti a NIP-40 e NIP-07. I client si sono moltiplicati: Damus ha riempito la beta TestFlight in poche ore, Astral ha forkato Branle per la creazione dei profili, Snort è stato lanciato come client web “veloce e resistente alla censura”, e Vitor Pamplona ha iniziato lo sviluppo di Amethyst. Alby v1.22.1 “Kemble’s Cascade of Stars” è uscita il 22 dicembre con supporto NIP-19. Al 7 dicembre, Nostr aveva circa 800 utenti con profili; quando Damus è arrivato sull’App Store il 31 gennaio 2023, i cancelli si sono spalancati, spingendo la crescita oltre 315.000 utenti entro giugno 2023.

Dicembre 2023: Maturazione dell’Ecosistema

Dicembre 2023 ha segnato un punto di inflessione critico per la sicurezza del protocollo Nostr. Il 20 dicembre, NIP-44 revisione 3 è stato unito dopo un audit di sicurezza indipendente di Cure53 (NOS-01) che ha identificato 10 problemi nelle implementazioni TypeScript, Go e Rust, inclusi timing attack e problemi di forward secrecy. La specifica aggiornata ha sostituito la cifratura difettosa di NIP-04 con ChaCha20 e HMAC-SHA256, stabilendo la base crittografica che oggi sostiene i DM privati di NIP-17 e il gift wrapping di NIP-59. Nella stessa settimana, OpenSats ha annunciato la quarta ondata di grant il 21 dicembre, finanziando sette progetti tra cui Lume, noStrudel, ZapThreads e un audit indipendente di NIP-44. Questo seguiva la prima ondata di luglio 2023, che aveva finanziato Damus, Coracle, Iris e altri, portando l’allocazione totale del Nostr Fund a circa 3,4 milioni di dollari distribuiti su 39 grant.

Il mese ha anche messo in luce tensioni di sostenibilità nell’ecosistema. Il 28 dicembre, William Casarin (jb55) ha scritto su Stacker News che il 2024 sarebbe stato “probabilmente l’ultimo anno di Damus”, citando il fatto che “i client nostr non fanno soldi” dopo che le restrizioni di Apple sugli zaps in-app avevano limitato pesantemente il potenziale di ricavo. Il team Damus aveva già rifiutato finanziamenti VC. Nel frattempo, Nostr Wallet Connect v0.4.1 è uscita il 26 dicembre, estendendo NIP-47 con i metodi pay_keysend, make_invoice, lookup_invoice, list_transactions, get_balance e get_info, gettando le basi per le integrazioni wallet che sarebbero poi diventate standard nei client.

Dicembre 2024: Avanzamento del Protocollo

Dicembre 2024 si è aperto con il lancio alpha di Notedeck il 30 novembre, il client desktop Rust-based del team Damus con interfaccia multi-colonna e supporto per più account. Costruito per Linux, macOS e Windows, con Android pianificato per il 2025, Notedeck è stato inizialmente distribuito agli abbonati Damus Purple e ha rappresentato un’espansione strategica oltre iOS. Due settimane dopo, OpenSats ha annunciato la nona ondata di grant il 16 dicembre, finanziando AlgoRelay, il primo relay algoritmico per feed personalizzati, Pokey, app Android con Bluetooth mesh per internet limitato, Nostr Safebox (NIP-60 con storage di token Cashu) e LumiLumi, client web leggero e accessibile, spingendo l’allocazione totale del Nostr Fund a circa 9 milioni di dollari, un aumento del 67% su base annua.

Il mese ha visto una significativa maturazione dei client in tutto l’ecosistema. Gossip 0.13.0 è arrivato il 23 dicembre con supporto File Metadata (NIP-92/NIP-94), integrazione Blossom e ricerca relay di NIP-50. Coracle 0.5.0 è uscita il 12 dicembre con onboarding rielaborato e integrazione nostr-editor. Lo sviluppo del protocollo è rimasto attivo con 30 pull request inviate tra il 9 e il 22 dicembre, di cui 10 unite, inclusi riscritture di NIP-46 per usare solo la cifratura NIP-44 e il lavoro continuo su NIP-104 per la cifratura double ratchet a livello Signal. Le statistiche di rete hanno mostrato oltre 224.000 trusted pubkey event giornalieri, una crescita di 4x anno su anno nei nuovi profili con contact list e un aumento del 50% negli event di scrittura pubblica.

Dicembre 2025: Espansione dell’Ecosistema

Dicembre 2025 ha portato la prosecuzione della maturazione del protocollo e dell’espansione dell’ecosistema. Il 21 dicembre, OpenSats ha annunciato la quattordicesima ondata di grant Nostr, finanziando tre progetti: YakiHonne, un client multi-piattaforma con creator portal per contenuti long-form e integrazione pagamenti Cashu/Nutzaps, Quartz, la libreria Kotlin Multiplatform di Vitor Pamplona che alimenta Amethyst e permetterà una versione iOS, e Nostr Feedz, l’integrazione bidirezionale RSS-to-Nostr di PlebOne. I rinnovi dei grant sono andati a Dart NDK e al nostr-relay di Mattn.

L’evoluzione del protocollo è continuata con NIP-BE (messaggistica Bluetooth Low Energy, #1979) unito a novembre, permettendo la sincronizzazione offline tra dispositivi. NIP-A4 (Public Messages, kind 24, #1988) è arrivato più tardi nel mese, definendo messaggi per la schermata notifiche che usano tag q per evitare complicazioni di threading. NIP-29 ha ricevuto un importante chiarimento (#2106), introducendo il tag hidden per gruppi veramente privati e non individuabili. Anche la specifica di NIP-55 ha visto affinamenti (#2166), affrontando un errore di implementazione comune in cui gli sviluppatori chiamavano get_public_key da processi in background.

Sul lato client, Primal Android è diventato un signer NIP-55 completo attraverso otto PR unite che implementano LocalSignerContentProvider, unendosi ad Amber e Aegis come opzioni di firma Android. La libreria NDK ha raggiunto query cache 162x più veloci, passando da ~3.690ms a ~22ms, eliminando scritture duplicate e lookup non necessari nella cache LRU (PR #371, PR #372). Shopstr ha introdotto Zapsnags per flash sale via zaps. White Noise ha distribuito MIP-05 per notifiche push che preservano la privacy. Per una copertura completa, consultate Newsletter #1 e Newsletter #2.

Cinque anni fa, fiatjaf pubblicò Branle per una manciata di utenti distribuiti su due relay sperimentali. Oggi il protocollo supporta oltre 140 client, più di 2.500 relay in 50 paesi e una crescente web of trust che collega centinaia di migliaia di coppie di chiavi. Il modello di dicembre fatto di grandi rilasci è continuato anche questo mese, con messaggistica Bluetooth, proliferazione di signer Android e grant infrastrutturali che segnalano investimenti continui negli strumenti cross-platform.

Notizie

Amethyst Desktop prende forma - Il grant Quartz della quattordicesima ondata di OpenSats sta già producendo risultati. PR #1625 crea un modulo :desktopApp completo per Amethyst usando Compose Multiplatform, con schermate di login e global feed già funzionanti su Desktop JVM. L’architettura converte il modulo :commons in Kotlin Multiplatform con una struttura pulita dei source set (commonMain, jvmAndroid, androidMain, jvmMain), permettendo componenti UI condivisi tra Android e desktop e lasciando le decisioni specifiche della piattaforma a ciascun target. Questo getta le basi per la futura versione iOS tramite lo stesso approccio Kotlin Multiplatform.

Risposte vocali in Amethyst - Un regalo di Natale da davotoula: PR #1622 aggiunge schermate dedicate alle risposte vocali con visualizzazione della waveform, supporto alla ri-registrazione, selezione del media server e indicatori di avanzamento upload. Gli utenti possono ora rispondere con audio sia ai messaggi vocali root sia alle risposte vocali.

Notedeck aggiunge la messaggistica - Notedeck, il client desktop di Damus, ha guadagnato una funzione messaggi in PR #1223, espandendosi oltre la navigazione della timeline verso la comunicazione diretta.

Citrine ospita web app - Citrine ora può ospitare applicazioni web, trasformando il telefono in un server web Nostr local-first. Una seconda PR #85 aggiunge la riconnessione automatica e il broadcasting degli event quando la connettività di rete ritorna, con copertura di test completa su diversi livelli API Android.

Registro Nostrability per developer toolkit - Il tracker Developer Kits & Tooling mantiene un registro curato di SDK, librerie e strumenti per sviluppatori in diversi linguaggi, tra cui TypeScript, Rust, Python, Go, Dart e Swift. Se siete nuovi allo sviluppo su Nostr, questo è un buon punto di partenza per trovare il toolkit adatto al vostro stack.

Aggiornamenti NIP

Cambiamenti recenti nel repository NIPs:

NIP-54 - Correzione critica di internazionalizzazione per la normalizzazione dei d-tag wiki (#2177). Le regole precedenti convertivano tutti i caratteri non ASCII in -, rompendo il supporto a giapponese, cinese, arabo, cirillico e altri script. La specifica aggiornata preserva le lettere UTF-8, applica il lowercase solo ai caratteri che hanno varianti maiuscole/minuscole e include esempi completi: "ウィキペディア" resta "ウィキペディア", "Москва" diventa "москва", e script misti come "日本語 Article" si normalizzano in "日本語-article".

Rilasci

Zapstore 1.0-rc1 - Il permissionless app store basato su Nostr distribuisce il primo release candidate della sua nuova architettura, con un completo refresh della UI, package manager riscritto con migliore gestione degli errori, App Stacks per la scoperta curata, schermate profilo riprogettate, controllo degli aggiornamenti in background e infinite scrolling nelle liste delle release.

KeyChat v1.38.1 - L’app di messaggistica cifrata basata su MLS aggiunge il supporto a UnifiedPush per le notifiche push su Android e Linux, oltre all’autenticazione biometrica per le operazioni che incidono sulla privacy. Disponibile per Android, Windows, macOS e Linux.

Alby Go v2.0.0 - Il companion mobile wallet Lightning distribuisce un redesign visivo con nuovo logo, palette colori aggiornata, rubrica riprogettata e tastiera migliorata per l’inserimento degli importi. BTC Map è ora accessibile dalla schermata principale e le descrizioni delle transazioni compaiono nelle notifiche.

nak v0.17.4 - Lo strumento Nostr da riga di comando di fiatjaf è stato rilasciato, dopo la correzione della settimana scorsa in v0.17.3 alla restrizione Linux di LMDB.

Cambiamenti notevoli nel codice e nella documentazione

Pull request aperte e lavori nelle prime fasi che vale la pena osservare.

Damus (iOS)

Relay hint NIP-19 implementa il consumo dei relay hint nel recupero degli event. Quando gli utenti aprono link nevent, nprofile o naddr, Damus ora estrae i relay hint dai dati bech32 TLV e si connette a relay effimeri per recuperare contenuti che non si trovano nel relay pool dell’utente. L’implementazione include cleanup ref-counted per prevenire race condition durante lookup concorrenti. Image URL detection converte automaticamente gli URL immagine incollati in anteprime thumbnail nel composer, con un badge di posizione nel carosello per immagini multiple. npub paste conversion trasforma stringhe npub/nprofile incollate in link mention con risoluzione asincrona del profilo.

Amethyst (Android)

Payment targets aggiunge un’interfaccia event per gli zap split NIP-57, permettendo ai post di specificare più destinatari che condividono gli zaps in arrivo, utile per collaborazioni, revenue sharing o mance sia ai creatori di contenuti sia agli strumenti che usano. Quartz feature parity documentation aggiunge una tabella dettagliata che traccia quali funzionalità sono implementate tra target Android, Desktop JVM e iOS, evidenziando che a iOS mancano la crittografia core (Secp256k1Instance), la serializzazione JSON e le strutture dati.

Notedeck (Desktop)

Timeline filter rebuild corregge un bug per cui gli account non più seguiti continuavano a comparire nei feed. I filtri della timeline venivano costruiti una sola volta a partire dalla contact list e non venivano mai aggiornati; la correzione aggiunge il tracciamento di contact_list_timestamp e un metodo invalidate() per innescare la ricostruzione quando cambia lo stato dei follow.

Citrine (Relay Android)

ContentProvider API espone il database event del relay locale alle altre app Android tramite ContentResolver. A differenza dell’interfaccia WebSocket, che richiede alle app di mantenere una connessione persistente e parlare il protocollo relay Nostr, ContentProvider offre accesso diretto sincrono al database tramite il meccanismo IPC nativo di Android. Le app esterne possono interrogare gli event per ID, pubkey, kind o intervallo di date, inserire nuovi event con validazione e cancellarli senza dover gestire connessioni socket.

rust-nostr (Libreria)

Supporto NIP-40 a livello relay aggiunge la gestione della scadenza al livello del relay builder. Gli event scaduti vengono ora rifiutati prima dello storage e filtrati prima dell’invio ai client, eliminando la necessità che ogni implementazione del database gestisca i controlli di scadenza in modo indipendente.

nak (CLI)

Blossom mirror implementa la funzionalità di mirroring blob per lo strumento da riga di comando.

Mostro (Trading P2P)

Dev fee audit events aggiunge audit trail trasparenti per i pagamenti del fondo sviluppo tramite event Nostr di kind 8383. L’implementazione pubblica event di audit non bloccanti dopo i pagamenti fee riusciti, includendo dettagli dell’ordine e hash dei pagamenti ed escludendo le pubkey di buyer e seller per motivi di privacy.

MDK (Marmot Development Kit)

Sono arrivate tre correzioni da security audit: Author verification impone che le rumor pubkey corrispondano alle credenziali MLS del mittente, impedendo attacchi di impersonation. KeyPackage identity binding verifica che l’identità della credential corrisponda ai signer degli event. Admin update validation impedisce set admin vuoti e assegnazioni admin a non membri.

Shopstr (Marketplace)

HODL invoice escrow implementa un sistema di pagamento trust-minimized per beni fisici. L’architettura usa makeHoldInvoice di Alby per bloccare i fondi del buyer nel suo wallet, con settlement attivato solo dopo la verifica dell’inventario da parte del merchant. Il protocollo di handshake scorre attraverso DM cifrati di NIP-17: il buyer invia la richiesta ordine, il merchant risponde con la HODL invoice, il buyer paga con fondi bloccati, il merchant conferma stock e spedizione, poi il settlement rilascia i fondi. Il supporto cart multi-merchant divide i pagamenti tra i vendor.

Jumble (Client Web)

Per-relay discovery mode aggiunge un toggle per nascondere i post degli utenti seguiti su relay specifici, permettendo feed di scoperta basati sulla lingua, per esempio nostr.band/lang/*. La funzionalità filtra i post in cui la pubkey dell’autore compare nella follow list dell’utente, persistendo lo stato del toggle per URL relay in localStorage.

White Noise (Messaggistica Cifrata)

Media upload retry aggiunge opzioni di retry per gli upload falliti. Profile edit warnings avvisano gli utenti sulle modifiche al profilo. Sul backend, whitenoise-rs corregge una race condition nella creazione di AccountGroup.

npub.cash (Servizio Lightning Address)

v3 rewrite migra il monorepo e il server a Bun, aggiunge il supporto SQLite, rimuove la compatibilità v1, implementa LUD-21 e aggiunge aggiornamenti realtime per le mint quote.

nostr-java (Libreria)

v1.1.1 distribuisce refactor della gestione WebSocket e una migliore robustezza dei test attraverso due PR.

Repository NIPs

Migrazione Djot di NIP-54 propone una modifica separata alla specifica wiki: passare il formato dei contenuti da Asciidoc a Djot, un linguaggio di markup leggero con sintassi più pulita. La PR introduce link in stile reference per i wikilink, rendendo i riferimenti incrociati tra articoli wiki più leggibili nel sorgente. NIP-XX Quorum introduce la governance threshold multi-signature per i gruppi Nostr usando FROST. Un Quorum è un nsec condiviso tra i membri attraverso uno schema T-of-N in cui i membri possono rappresentare sé stessi o delegare a un consiglio di rappresentanti. Quando il consiglio cambia, il vecchio nsec diventa obsoleto e uno nuovo viene distribuito; l’atto finale di ogni consiglio è firmare l’event di transizione della governance. La specifica definisce membership pubblica o privata, elezioni e poll, eventuali “leggi” in linguaggio naturale e, soprattutto, ontologie di quorum in cui i quorum possono essere membri di altri quorum, permettendo strutture gerarchiche come località che aderiscono a organismi regionali. I casi d’uso vanno dallo sviluppo di codice sorgente ai consigli di amministrazione, dalle HOA alle comunità moderate.

Per questa settimana e per quest’anno è tutto. State costruendo qualcosa? Avete novità da condividere? Volete che parliamo del vostro progetto? Contattateci via DM NIP-17 o cercateci su Nostr.

Nostr Compass #2

Wed, 24 Dec 2025 00:00:00 +0000

Bentornati a Nostr Compass, la vostra guida settimanale all’ecosistema del protocollo Nostr.

Questa settimana: Tre implementazioni signer NIP-55 ricevono aggiornamenti: Amber aggiunge caching delle prestazioni, Aegis ottiene supporto URI nostrsigner:, e Primal Android si unisce a loro come signer locale completo. Shopstr introduce “Zapsnags” per vendite flash tramite zap. Mostro aggiunge un fondo di sviluppo. Quattro aggiornamenti NIP arrivano inclusi Messaggi Pubblici (kind 24) e miglioramenti alla privacy dei gruppi. Le query cache NDK accelerano di 162x, Applesauce aggiunge reazioni e supporto wallet NIP-60, e Tenex introduce l’architettura RAL per la delega di agenti AI. Nel nostro approfondimento, spieghiamo NIP-02 (liste follow) e NIP-10 (threading delle risposte), specifiche fondamentali per costruire timeline sociali e conversazioni.

Notizie

Primal Android Diventa un Signer NIP-55 - Costruendo sul supporto Nostr Connect della settimana scorsa, Primal ha implementato capacita’ complete di firma locale attraverso otto pull request unite. L’implementazione include un LocalSignerContentProvider completo che espone le operazioni di firma ad altre app Android tramite l’interfaccia content provider di Android, seguendo la specifica NIP-55. L’architettura separa chiaramente le responsabilita’: SignerActivity gestisce i flussi di approvazione rivolti all’utente, LocalSignerService gestisce le operazioni in background, e un nuovo sistema di permessi consente agli utenti di controllare quali app possono richiedere firme. Questo rende Primal un’alternativa valida ad Amber per gli utenti Android che vogliono mantenere le proprie chiavi in un’app mentre ne usano altre per diverse esperienze Nostr.

Shopstr Zapsnags: Vendite Flash via Lightning - Il marketplace nativo Nostr ha introdotto “Zapsnags”, una funzionalita’ di vendita flash che consente agli acquirenti di acquistare articoli direttamente dal loro feed sociale con un singolo zap. L’implementazione filtra le note kind 1 taggate con #shopstr-zapsnag e le renderizza come schede prodotto con un pulsante “Zap to Buy” invece del flusso carrello standard. Quando un acquirente fa uno zap, il sistema genera una richiesta di pagamento usando NIP-57, controlla la ricevuta zap kind 9735 per confermare il pagamento, poi cripta le informazioni di spedizione usando il gift wrapping NIP-17 prima di inviarle privatamente al venditore. La funzionalita’ memorizza i dettagli dell’acquirente localmente per acquisti ripetuti e include una dashboard per commercianti per creare inserzioni di vendita flash. E’ una combinazione intelligente di primitive sociali, di pagamento e di privacy che dimostra come il design componibile di Nostr abiliti nuovi pattern di commercio.

Mostro Introduce Fondo di Sviluppo - La piattaforma di trading Bitcoin P2P NIP-69 ha implementato commissioni di sviluppo configurabili per supportare la manutenzione sostenibile. Gli operatori possono impostare dev_fee_percentage tra 10-100% della commissione di trading Mostro (default 30%), che viene automaticamente instradata a un fondo di sviluppo ad ogni scambio riuscito. L’implementazione aggiunge tre colonne database (dev_fee, dev_fee_paid, dev_fee_payment_hash) per tracciare i contributi e valida la percentuale all’avvio del daemon. La documentazione tecnica in docs/DEV_FEE.md spiega il sistema. Questo modello opt-in consente agli operatori di supportare lo sviluppo continuo mantenendo piena trasparenza sull’allocazione delle commissioni.

Aggiornamenti NIP

Modifiche recenti al repository NIPs:

Nuovi NIP:

NIP-A4 (Messaggi Pubblici, kind 24) - Un nuovo kind per messaggi dello schermo notifiche progettato per ampio supporto client (#1988). A differenza delle conversazioni threaded, questi messaggi non hanno concetto di cronologia chat o catene di messaggi. Usano tag q (citazioni) invece di tag e per evitare complicazioni di threading, rendendoli ideali per semplici notifiche pubbliche che appaiono nel feed notifiche di un destinatario senza creare stato di conversazione.

Modifiche Significative:

NIP-29 - Importante chiarimento della semantica dei gruppi (#2106). Il tag closed ora significa “impossibile scrivere” (sola lettura per non-membri), disaccoppiato dalla meccanica di adesione. Un nuovo tag hidden impedisce ai relay di servire eventi di metadati o membri ai non-membri, abilitando gruppi veramente privati che sono impossibili da scoprire senza invito out-of-band. Il tag private controlla la visibilita’ dei messaggi permettendo comunque metadati pubblici per la scoperta.
NIP-51 - Aggiunto kind 30006 per set di immagini curate (#2170), seguendo il pattern di 30004 (articoli) e 30005 (video). Gia’ implementato in Nostria.
NIP-55 - Chiarito l’avvio della connessione per signer Android (#2166). Gli sviluppatori che implementavano sessioni multi-utente usavano erroneamente get_public_key chiamandolo da processi in background. La specifica aggiornata raccomanda di chiamarlo solo una volta durante la connessione iniziale, prevenendo un comune errore di implementazione.

Approfondimento NIP: NIP-02 e NIP-10

Questa settimana copriamo due NIP essenziali per la funzionalita’ sociale: come i client sanno chi seguite e come le conversazioni sono threaded.

NIP-02: Lista Follow

NIP-02 definisce gli eventi kind 3, che memorizzano la vostra lista follow. Questo semplice meccanismo alimenta il grafo sociale che rende possibili le timeline.

Struttura: Un evento kind 3 contiene tag p che elencano le pubkey seguite:

{
 "id": "d7a8f...",
 "pubkey": "a3b9c...",
 "created_at": 1734912000,
 "kind": 3,
 "tags": [
 ["p", "91cf9..af5f", "wss://alicerelay.example.com", "alice"],
 ["p", "14aeb..8dad", "wss://bobrelay.example.com", "bob"],
 ["p", "612ae..982b", "", ""]
 ],
 "content": "",
 "sig": "e4f8a..."
}

Ogni tag p ha quattro posizioni: il nome del tag, la pubkey seguita (esadecimale), un suggerimento URL relay opzionale, e un “petname” opzionale (un soprannome locale). Il suggerimento relay dice ad altri client dove trovare gli eventi di quell’utente. Il petname vi consente di assegnare nomi memorabili ai contatti senza affidarvi ai nomi visualizzati auto-dichiarati.

Comportamento sostituibile: Kind 3 rientra nell’intervallo sostituibile (0, 3, 10000-19999), quindi i relay mantengono solo l’ultima versione per pubkey. Quando seguite qualcuno di nuovo, il vostro client pubblica un nuovo kind 3 completo contenente tutti i vostri follow piu’ quello nuovo. Questo significa che le liste follow devono essere complete ogni volta; non potete pubblicare aggiornamenti incrementali.

Costruire timeline: Per costruire un feed home, i client recuperano il kind 3 dell’utente, estraggono tutte le pubkey dai tag p, poi si iscrivono agli eventi kind 1 da quegli autori:

["REQ", "home", {"kinds": [1], "authors": ["91cf9...", "14aeb...", "612ae..."], "limit": 50}]

Il relay restituisce le note corrispondenti, e il client le renderizza. I suggerimenti relay nel kind 3 aiutano i client a sapere quali relay interrogare per ogni utente seguito.

Petname e identita’: Il campo petname abilita uno schema di naming decentralizzato. Invece di fidarvi di qualsiasi nome un utente dichiara nel suo profilo, potete assegnare la vostra etichetta. Un client potrebbe visualizzare “alice (Mia Sorella)” dove “alice” viene dal suo profilo kind 0 e “Mia Sorella” e’ il vostro petname. Questo fornisce contesto che i nomi utente globali non possono.

Considerazioni pratiche: Poiche’ gli eventi kind 3 sono sostituibili e devono essere completi, i client dovrebbero preservare tag sconosciuti durante l’aggiornamento. Se un altro client ha aggiunto tag che il vostro client non capisce, sovrascrivere alla cieca perderebbe quei dati. Aggiungete nuovi follow invece di ricostruire da zero.

NIP-10: Threading Note di Testo

NIP-10 specifica come le note kind 1 si referenziano a vicenda per formare thread di risposte. Capire questo e’ essenziale per costruire viste di conversazione.

Il problema: Quando qualcuno risponde a una nota, i client devono sapere: A cosa e’ una risposta? Qual e’ la radice della conversazione? Chi dovrebbe essere notificato? NIP-10 risponde a queste domande attraverso tag e (riferimenti eventi) e tag p (menzioni pubkey).

Tag marcati (preferiti): I client moderni usano marcatori espliciti nei tag e:

{
 "id": "f9c2e...",
 "pubkey": "a3b9c...",
 "created_at": 1734912345,
 "kind": 1,
 "tags": [
 ["e", "abc123...", "wss://relay.example.com", "root"],
 ["e", "def456...", "wss://relay.example.com", "reply"],
 ["p", "91cf9..."],
 ["p", "14aeb..."]
 ],
 "content": "Ottimo punto! Sono d'accordo.",
 "sig": "b7d3f..."
}

Il marcatore root punta alla nota originale che ha iniziato il thread. Il marcatore reply punta alla nota specifica a cui si sta rispondendo. Se rispondete direttamente alla root, usate solo root (nessun tag reply necessario). La distinzione conta per il rendering: il reply determina l’indentazione in una vista thread, mentre root raggruppa tutte le risposte insieme.

Regole di threading:

Risposta diretta alla root: Un tag e con marcatore root
Risposta a una risposta: Due tag e, uno root e uno reply
Il root rimane costante in tutto il thread; reply cambia in base a cosa state rispondendo

Tag pubkey per notifiche: Includete tag p per tutti quelli che dovrebbero essere notificati. Come minimo, taggate l’autore della nota a cui state rispondendo. La convenzione e’ anche includere tutti i tag p dall’evento parent (cosi’ tutti nella conversazione rimangono nel loop), piu’ qualsiasi utente che @menzionate nel vostro contenuto.

Suggerimenti relay: La terza posizione nei tag e e p puo’ contenere un URL relay dove quell’evento o contenuto utente potrebbe essere trovato. Questo aiuta i client a recuperare il contenuto referenziato anche se non sono connessi al relay originale.

Tag posizionali deprecati: Le prime implementazioni Nostr inferivano il significato dalla posizione del tag invece che dai marcatori: il primo tag e era root, l’ultimo era reply, quelli in mezzo erano menzioni. Questo approccio e’ deprecato perche’ crea ambiguita’. Se vedete tag e senza marcatori, sono probabilmente da client piu’ vecchi. Le implementazioni moderne dovrebbero sempre usare marcatori espliciti.

Costruire viste thread: Per visualizzare un thread, recuperate l’evento root, poi interrogate tutti gli eventi con un tag e che referenzia quella root:

["REQ", "thread", {"kinds": [1], "#e": ["<root-event-id>"]}]

Ordinate i risultati per created_at e usate i marcatori reply per costruire la struttura ad albero. Gli eventi il cui reply punta alla root sono risposte di primo livello; gli eventi il cui reply punta a un’altra risposta sono risposte annidate.

Rilasci

Zeus v0.12.0 - Costruendo sul supporto pagamenti paralleli NWC della settimana scorsa, la release principale del wallet Lightning rilascia un servizio completo Nostr Wallet Connect NIP-47 con supporto relay personalizzato e tracciamento budget. Una correzione ricarica budget assicura che le connessioni usino i limiti correnti. Copia indirizzo Lightning non include piu’ il prefisso lightning:, correggendo problemi di incolla nei campi profilo Nostr.

Amber v4.0.6 - Il signer Android NIP-55 aggiunge caching delle prestazioni alle operazioni di firma e migliora la gestione errori durante la decifratura di contenuti malformati. L’affidabilita’ della connessione e’ migliorata con logica di retry per eventi di connessione relay, e diverse correzioni crash affrontano casi limite intorno a URI nostrconnect:// invalidi e interazioni con schermate di permesso.

nak v0.17.3 - L’ultima release dello strumento Nostr a riga di comando restringe le build LMDB a Linux, correggendo problemi di compilazione cross-platform.

Aegis v0.3.4 - Il signer Nostr cross-platform aggiunge supporto per lo schema URI nostrsigner: definito in NIP-55, abbinandosi al flusso di connessione di Amber. I dati relay locali possono ora essere importati ed esportati per backup, e la release include correzioni bug per errori socket relay e miglioramenti UI all’interfaccia relay locale.

Modifiche notevoli a codice e documentazione

Queste sono pull request aperte e lavori in fase iniziale, perfetti per ricevere feedback prima del merge. Se qualcosa cattura la vostra attenzione, considerate di revisionare o commentare!

Damus (iOS)

Persistenza lista mute corregge un problema dove le liste mute venivano cancellate all’avvio a freddo. La correzione aggiunge guard per prevenire sovrascritture accidentali durante l’inizializzazione dell’app. Timing stream profilo elimina un ritardo di ~1 secondo prima che i profili in cache apparissero. Precedentemente, le viste attendevano che i task di sottoscrizione ripartissero; ora streamProfile() produce immediatamente dati in cache da NostrDB, rimuovendo la finestra dove pubkey abbreviate e immagini placeholder venivano mostrate.

White Noise (Messaggistica Crittografata)

Streaming messaggi in tempo reale sostituisce il precedente meccanismo di polling con un’architettura basata su stream. Il nuovo ChatStreamNotifier consuma direttamente lo stream di messaggi dell’SDK Rust, mantenendo l’ordine cronologico e gestendo efficientemente gli aggiornamenti incrementali. I test hanno mostrato miglioramenti significativi nella reattivita’. Una API lista chat aggiunge get_chat_list per recuperare sommari delle conversazioni, e una correzione ordinamento stabile previene loop di riordinamento messaggi usando createdAt con ID messaggio come spareggio.

NDK (Libreria)

Due pull request hanno fornito miglioramenti drammatici delle prestazioni della cache. PR #371 ha corretto un bug dove gli eventi letti dalla cache SQLite venivano immediatamente riscritti, causando 100% di scritture duplicate all’avvio dell’app. La correzione aggiunge un guard fromCache e implementa controllo duplicati O(1) tramite un Set in memoria. Per set di risultati piccoli (<100 eventi), il trasferimento JSON diretto sostituisce l’overhead della codifica binaria. PR #372 ha rimosso chiamate seenEvent non necessarie per eventi in cache. Il lookup cache LRU costava 0.24-0.64ms per evento; per 5,700 eventi in cache, questo aggiungeva ~1.4 secondi di overhead. Risultato: le query cache sono scese da ~3,690ms a ~22ms (162x piu’ veloci).

rust-nostr (Libreria)

Supporto REQ multi-filtro e’ stato ripristinato dopo essere stato rimosso in un refactor precedente. L’SDK accetta di nuovo Vec<Filter> per richieste di sottoscrizione, abilitando query efficienti che combinano piu’ condizioni filtro con logica OR. Provenienza relay e’ stata aggiunta ai metodi stream_events*, cosi’ ogni evento in streaming ora include il RelayUrl da cui proviene e un Result che indica successo o fallimento, utile per tracciare l’affidabilita’ dei relay e debug di problemi di connessione. Una correzione sicurezza ha rimosso la dipendenza url-fork seguendo RUSTSEC-2024-0421, eliminando una vulnerabilita’ nota.

Applesauce (Libreria)

La libreria TypeScript che alimenta noStrudel ha visto sviluppi significativi questa settimana. Nuovi modelli includono un sistema di reazioni e casting gruppi utente. La funzionalita’ wallet si e’ espansa con supporto NIP-60, scheda invio e strumenti di recupero token migliorati. Una nuova proprieta’ user.directMessageRelays$ espone la configurazione relay per DM. Tutte le azioni sono state refactoratе per usare interfacce async (rimuovendo generatori async), e correzioni bug hanno affrontato il ripristino contenuto crittografato e casi limite filtri eventi basati sul tempo.

Tenex (Agenti AI)

Il sistema di coordinamento multi-agente costruito su Nostr ha introdotto l’architettura RAL (Request-Action-Lifecycle) in cinque PR unite. RAL consente agli agenti di mettersi in pausa quando delegano task e riprendere quando arrivano i risultati, con persistenza dello stato a scope conversazione. Gli strumenti di delega (delegate, ask, delegate_followup, delegate_external) ora pubblicano eventi Nostr e restituiscono segnali di stop invece di bloccarsi. Il refactor include migrazione AI SDK v6, infrastruttura testing VCR per registrazione deterministica interazioni LLM, e supporto immagini multimodali.

Questo e’ tutto per questa settimana. State costruendo qualcosa? Avete notizie da condividere? Volete che copriamo il vostro progetto? Contattateci via DM NIP-17 o trovateci su Nostr.

Nostr Compass #1

Mon, 15 Dec 2025 00:00:00 +0000

Benvenuti a Nostr Compass, una newsletter settimanale dedicata all’ecosistema del protocollo Nostr. La nostra missione e’ mantenere sviluppatori, operatori di relay e costruttori informati sugli sviluppi importanti in tutta la rete. Documentiamo l’evoluzione del protocollo con precisione tecnica, neutralita’ e profondita’, coprendo tutto dalle proposte NIP ai rilasci dei client fino alle migliori pratiche di implementazione.

Nostr Compass e’ ispirato da Bitcoin Optech, il cui lavoro dedicato nel corso degli anni per far progredire la conoscenza tecnica di Bitcoin ha stabilito lo standard per le newsletter focalizzate sul protocollo. Siamo grati per il loro esempio e speriamo di portare lo stesso rigore all’ecosistema Nostr.

Questo numero inaugurale stabilisce il nostro formato settimanale. Ogni mercoledi’ vi porteremo aggiornamenti NIP, note di rilascio, punti salienti dello sviluppo e guide tecniche. Che stiate costruendo un client, gestendo un relay o contribuendo al protocollo, Nostr Compass mira ad essere la vostra fonte affidabile per cio’ che sta accadendo nell’ecosistema.

Cos’e’ Nostr?

Poiche’ questo e’ il nostro primo numero, iniziamo con una introduzione su come funziona Nostr. I lettori abituali possono passare avanti.

Nostr (Notes and Other Stuff Transmitted by Relays) e’ un protocollo decentralizzato per social networking e messaggistica. A differenza delle piattaforme tradizionali, Nostr non ha server centrale, nessuna azienda che lo controlla e nessun singolo punto di fallimento. Gli utenti possiedono la propria identita’ attraverso coppie di chiavi crittografiche, e il contenuto fluisce attraverso server relay indipendenti che chiunque puo’ gestire.

Come funziona: Gli utenti generano una coppia di chiavi (una chiave privata chiamata nsec e una chiave pubblica chiamata npub). La chiave privata firma i messaggi chiamati “eventi”, e la chiave pubblica serve come vostra identita’. Gli eventi vengono inviati ai relay, che li memorizzano e li inoltrano ad altri utenti. Poiche’ voi controllate le vostre chiavi, potete passare da un client all’altro o da un relay all’altro senza perdere la vostra identita’ o i vostri follower.

Perche’ e’ importante: Nostr fornisce resistenza alla censura attraverso la diversita’ dei relay (se un relay vi blocca, altri possono comunque servire il vostro contenuto), portabilita’ (la vostra identita’ funziona su qualsiasi app Nostr) e interoperabilita’ (tutti i client Nostr parlano lo stesso protocollo). Non c’e’ nessun algoritmo che decide cosa vedete, niente pubblicita’ e nessuna raccolta di dati.

L’ecosistema oggi: Nostr supporta microblogging (come Twitter/X), contenuti di lunga forma (come Medium), messaggi diretti, marketplace, livestreaming e altro. I client includono Damus (iOS), Amethyst (Android), Primal, Coracle e dozzine di altri. L’integrazione con Lightning Network consente pagamenti istantanei attraverso gli “zap”. Il protocollo continua ad evolversi attraverso i NIP (Nostr Implementation Possibilities), specifiche guidate dalla comunita’ che estendono le funzionalita'.

Notizie

NIP-BE Unito: Supporto Bluetooth Low Energy - Una nuova significativa capacita’ e’ arrivata nel protocollo. NIP-BE specifica come le applicazioni Nostr possono comunicare e sincronizzarsi tramite Bluetooth Low Energy. Questo consente alle app di funzionare offline e sincronizzare dati tra dispositivi vicini senza connettivita’ internet. La specifica adatta i pattern dei relay WebSocket ai vincoli del BLE, usando compressione DEFLATE e messaggistica a blocchi per gestire le piccole dimensioni MTU del BLE (20-256 byte). I dispositivi negoziano i ruoli in base al confronto UUID, con l’UUID piu’ alto che diventa il server GATT.

MIP-05: Notifiche Push che Preservano la Privacy - Il Protocollo Marmot ha pubblicato MIP-05 (specifica), una specifica per notifiche push che mantengono la privacy. I sistemi push tradizionali richiedono che i server conoscano i token dei dispositivi e le identita’ degli utenti; MIP-05 risolve questo problema crittografando i token dei dispositivi con ECDH+HKDF e ChaCha20-Poly1305, usando chiavi effimere per prevenire la correlazione. Un protocollo gossip a tre eventi (kind 447-449) sincronizza i token crittografati tra i membri del gruppo, e le notifiche usano il NIP-59 gift wrapping con token esca per nascondere le dimensioni dei gruppi. Questo consente a WhiteNoise e altri client Marmot di consegnare notifiche tempestive senza compromettere la privacy degli utenti.

Blossom BUD-10: Nuovo Schema URI - Il protocollo media Blossom sta ottenendo uno schema URI personalizzato tramite BUD-10 (specifica). Il nuovo formato blossom:<sha256>.ext incorpora hash del file, estensione, dimensione, suggerimenti per piu’ server e pubkey degli autori per la scoperta server BUD-03. Questo rende i link blob piu’ resilienti degli URL HTTP statici abilitando il fallback automatico tra server.

Aggiornamenti Marketplace Shopstr - Il marketplace nativo Nostr ha implementato Nostr Wallet Connect (NIP-47) per i pagamenti, aggiunto la scadenza delle inserzioni usando NIP-40, e introdotto codici sconto per i venditori.

Aggiornamenti NIP

Modifiche recenti al repository NIPs:

Nuovi NIP:

NIP-BE - Messaggistica Bluetooth Low Energy e sincronizzazione dispositivi (#1979)
NIP-63 - Standard Paywall/Contenuto Premium per gestire contenuti protetti all’interno del protocollo (#2156)

Modifiche Significative:

NIP-24 - Aggiunto array opzionale languages ai metadati utente Kind 0, permettendo agli utenti di specificare piu’ lingue preferite usando tag IETF BCP 47 per migliorare la scoperta dei contenuti e il matching dei relay (#2159)
NIP-69 - Aggiunto supporto scadenza ordini per trading P2P con tag expires_at e expiration (#2118)
NIP-59 - Gli eventi gift wrap possono ora essere eliminati tramite richieste NIP-09/NIP-62 (#2131)
NIP-51 - Rimossi tag hashtag e URL dai segnalibri generici; gli hashtag ora usano kind 30015 (#2133)
NIP-18 - Migliorati i repost generici per eventi sostituibili con supporto tag a (#2132)
NIP-17 - Formulazione raffinata e aggiunto supporto reazioni kind 7 ai DM (#2098)
NIP-11 - Aggiunto campo self per l’identificazione della chiave pubblica del relay (#1764)

Approfondimento NIP: NIP-01 e NIP-19

Per questo numero inaugurale, copriamo due NIP fondamentali che ogni sviluppatore Nostr dovrebbe comprendere. Consultate le nostre pagine tematiche per NIP-01 e NIP-19.

NIP-01: Protocollo Base

NIP-01 definisce il protocollo core. Tutto in Nostr si basa su questa specifica.

Eventi sono l’unico tipo di oggetto. Ogni evento contiene:

id: Hash SHA256 dell’evento serializzato (l’identificatore unico dell’evento)
pubkey: La chiave pubblica del creatore (32 byte esadecimali, secp256k1)
created_at: Timestamp Unix
kind: Intero che categorizza il tipo di evento
tags: Array di array per i metadati
content: Il payload (l’interpretazione dipende dal kind)
sig: Firma Schnorr che prova che la pubkey ha creato questo evento

Kind determinano come i relay memorizzano gli eventi:

Eventi regolari (1, 2, 4-44, 1000-9999): Memorizzati normalmente, tutte le versioni mantenute
Eventi sostituibili (0, 3, 10000-19999): Solo l’ultimo per pubkey viene mantenuto
Eventi effimeri (20000-29999): Non memorizzati, solo inoltrati ai sottoscrittori
Eventi indirizzabili (30000-39999): Ultimo per combinazione pubkey + kind + tag d

Kind 0 sono i metadati utente (profilo), kind 1 e’ una nota di testo (il post base), kind 3 e’ la lista dei seguiti.

Kind 1: Note di Testo sono il cuore del Nostr sociale. Un evento kind 1 e’ un post breve, simile a un tweet. Il campo content contiene il testo del messaggio (testo semplice, anche se i client spesso renderizzano markdown). I tag abilitano risposte, menzioni e riferimenti:

{
 "id": "<32-byte-hex>",
 "pubkey": "<32-byte-hex>",
 "created_at": 1734480000,
 "kind": 1,
 "content": "Ciao Nostr! Date un'occhiata al lavoro di @jb55 su Damus.",
 "tags": [
 ["e", "<replied-to-event-id>", "wss://relay.example.com", "reply"],
 ["p", "<jb55-pubkey>"]
 ],
 "sig": "<64-byte-hex>"
}

Il tag e con marcatore “reply” indica che questa e’ una risposta (vedi NIP-10 per le convenzioni di threading). Il tag p menziona un utente, permettendo ai client di notificarlo e renderizzare il suo nome invece della pubkey grezza. I client recuperano l’evento kind 0 dell’utente menzionato per ottenere il suo nome visualizzato e l’immagine.

Per costruire una timeline, un client si iscrive agli eventi kind 1 dalle pubkey seguite: ["REQ", "feed", {"kinds": [1], "authors": ["<pubkey1>", "<pubkey2>", ...], "limit": 50}]. Il relay restituisce le note corrispondenti, e il client le renderizza cronologicamente.

Eventi indirizzabili (30000-39999) funzionano come eventi sostituibili ma usano un tag d come identificatore aggiuntivo. Il relay mantiene solo l’ultima versione di ogni combinazione pubkey + kind + tag-d. Questo abilita articoli modificabili, elenchi di prodotti o qualsiasi caso in cui servono piu’ elementi sostituibili per utente.

Tag sono array dove il primo elemento e’ il nome del tag. I tag standard a singola lettera (e, p, a, d, t) sono indicizzati dai relay per query efficienti. Per esempio, ["e", "<event-id>"] referenzia un altro evento, ["p", "<pubkey>"] referenzia un utente.

Comunicazione Client-Relay usa connessioni WebSocket con array JSON come messaggi. Il primo elemento identifica il tipo di messaggio.

Da client a relay:

["EVENT", <event>] - Pubblica un evento sul relay
["REQ", <sub-id>, <filter>, ...] - Sottoscrivi agli eventi che corrispondono ai filtri
["CLOSE", <sub-id>] - Termina una sottoscrizione

Da relay a client:

["EVENT", <sub-id>, <event>] - Consegna un evento che corrisponde alla tua sottoscrizione
["EOSE", <sub-id>] - “Fine degli eventi memorizzati” - il relay ha inviato tutte le corrispondenze storiche e ora inviera’ solo nuovi eventi quando arrivano
["OK", <event-id>, <true|false>, <message>] - Conferma se un evento e’ stato accettato o rifiutato (e perche')
["NOTICE", <message>] - Messaggio leggibile dal relay

Il flusso di sottoscrizione: il client invia REQ con un ID sottoscrizione e filtro, il relay risponde con messaggi EVENT corrispondenti, poi invia EOSE per segnalare che ha completato lo storico. Dopo EOSE, qualsiasi nuovo messaggio EVENT e’ in tempo reale. Il client invia CLOSE quando ha finito.

Filtri specificano quali eventi recuperare. Un oggetto filtro puo’ includere: ids (ID eventi), authors (pubkey), kinds (tipi di evento), #e/#p/#t (valori tag), since/until (timestamp), e limit (max risultati). Tutte le condizioni in un filtro usano logica AND. Potete includere piu’ filtri in una REQ, e si combinano con logica OR - utile per recuperare diversi tipi di evento in una sottoscrizione.

NIP-19: Identificatori Codificati Bech32

NIP-19 definisce i formati user-friendly che vedete ovunque in Nostr: npub, nsec, note e altro. Questi non sono usati nel protocollo stesso (che usa esadecimale), ma sono essenziali per la condivisione e la visualizzazione.

Perche’ bech32? Le chiavi esadecimali grezze sono soggette a errori nella copia e difficili da distinguere visivamente. La codifica bech32 aggiunge un prefisso leggibile e un checksum. Potete immediatamente distinguere un npub (chiave pubblica) da un nsec (chiave privata) o note (ID evento).

Formati base codificano valori grezzi a 32 byte:

npub - Chiave pubblica (la vostra identita’, sicura da condividere)
nsec - Chiave privata (mantenere segreta, usata per firmare)
note - ID evento (referenzia un evento specifico)

Esempio: La pubkey esadecimale 3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d diventa npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6.

Identificatori condivisibili includono metadati usando codifica TLV (Type-Length-Value):

nprofile - Profilo con suggerimenti relay (aiuta i client a trovare l’utente)
nevent - Evento con suggerimenti relay, pubkey autore e kind
naddr - Riferimento evento indirizzabile (pubkey + kind + tag-d + relay)

Questi risolvono un problema chiave: se qualcuno condivide un ID nota, come fate a sapere quale relay ce l’ha? Un nevent raggruppa l’ID evento con relay suggeriti, rendendo la condivisione piu’ affidabile.

Importante: Non usate mai formati bech32 nel protocollo stesso. Eventi, messaggi relay e risposte NIP-05 devono usare esadecimale. Bech32 e’ puramente per interfacce umane: visualizzazione, copia/incolla, codici QR e URL.

Rilasci

Amber v4.0.4 - L’app signer Android corregge una NullPointerException, migliora le prestazioni nella schermata attivita’ e aggiunge traduzioni per alcuni tipi di evento. La precedente release v4.0.3 ha aggiunto UI rinnovata per cifratura/decifratura, esportazione/importazione account, gestione relay per account, supporto ping bunker e segnalazione crash. Release

Coracle 0.6.28 - Release di correzione bug per il web client. Corretti feed topic, gestione immagini quando imgproxy e’ disabilitato e linkificazione di sorgenti highlight non-link. Release

Flotilla v1.6.2 - Il client per comunita’ stile Discord corregge problemi di scorrimento modal e stili. Release precedenti in questo ciclo hanno aggiunto badge e suoni opzionali per le notifiche, migliorato il rendering dei link, scansione codice QR per link di invito e configurazione wallet semplificata. Release

nak v0.17.2 - Lo strumento Nostr a riga di comando ha aggiunto un nuovo comando nip per consultazione rapida dei NIP, piu’ correzioni per gestione repository git e processamento eventi stdin. Release

White Noise v0.2.1 - Release importante per l’app di messaggistica crittografata basata su MLS aggiungendo condivisione immagini tramite Blossom, sincronizzazione in background, notifiche push, localizzazione in 8 lingue e gestione membri gruppo. Release

Amethyst v1.04.2 - Release con nuove funzionalita’ che introduce liste/pacchetti di follow, nuovi filtri timeline, galleria immagini e compressione video H.265 (file piu’ piccoli del 50%). Completata migrazione Kotlin Multiplatform. Release

Mostro v0.15.5 - Aggiornamento piattaforma trading P2P con supporto scadenza ordini NIP-69 e risposte migliorate per la cronologia scambi. Release

Nosflare v8.9.26 - Relay Nostr serverless costruito su infrastruttura Cloudflare. Questa release fornisce un hotfix critico che risolve un bug che poteva causare fallimenti websocket, garantendo connessioni piu’ stabili per utenti e applicazioni che dipendono dal relay. Release

Noscall v0.4.1 - App per chiamate audio e video sicure basata su Nostr. Questa release migliora l’interfaccia pop-up nella pagina Me e corregge diversi problemi noti, risultando in maggiore stabilita’ e affidabilita’ delle chiamate. Release

Gitplaza v0.25.0 - Client Nostr desktop focalizzato su attivita’ relative a Git. Questa release introduce un filtro kind avanzato per il feed inbox, include zap regolari nei filtri e semplifica la formattazione del testo delle schede. Miglioramenti delle prestazioni ottimizzano il caricamento dell’albero commenti, riducono query database non necessarie e usano branch di commenti in cache per visualizzazione piu’ veloce. Release

Modifiche notevoli a codice e documentazione

Damus (iOS)

Focus sulla stabilita’ con correzioni crash e UI: correzione salto cursore per la vista di composizione, redesign interfaccia NostrDB usando tipi Swift ~Copyable per sicurezza delle transazioni, stabilita’ UI thread correggendo reinstanziazione della barra azioni, freeze lista mute da cicli AttributeGraph, e crash profilo da pulizia transazioni cross-thread. Aggiunto anche AGENTS.md linee guida per agenti di coding AI.

Notedeck (Desktop/Mobile)

Archiviazione chiavi sicura sposta nsec nel secure store del SO con migrazione automatica. Filtraggio note future nasconde eventi datati 24+ ore in avanti (anti-spam). Copia nevent ora include suggerimenti relay. Inoltre: aggiunta rapida colonna profilo, navigazione tastiera, ottimizzazione caricamento media.

Amethyst (Android)

Supporto [firma remota NIP-46](https://github.com/vitorpamplona/amethyst/pull/1555) per Nostr Connect. Organizzazione segnalibri con gestione liste pubbliche/private. Correzione compatibilita’ strfry per casi limite parsing info relay.

Primal (Android)

Deep link Nostr Connect per URL nostrconnect://. Login remoto tramite scansione QR per connessioni bunker. Correzione race condition connessione.

White Noise (Messaggistica Crittografata)

Correzione ritenzione dati app disabilita auto-backup Android per privacy. Comportamento scroll chat preserva posizione durante lettura cronologia.

Zeus (Wallet Lightning)

[Pagamenti paralleli NIP-47](https://github.com/ZeusLN/zeus/pull/3407) per miglior throughput zap in batch.

Best Practice per Sviluppatori

Validare Eventi Auth in Modo Difensivo - go-nostr ha corretto un panic nella validazione NIP-42 quando il tag relay mancava. Controllate sempre i tag richiesti prima di accedervi, anche nei flussi auth dove vi aspettate eventi ben formati.

Rate Limit per Stato Autenticazione - khatru ha aggiunto rate limiting basato su NIP-42, permettendo ai relay di applicare limiti diversi per connessioni autenticate vs anonime. Considerate limiti a livelli basati sullo stato auth invece di restrizioni generiche.

Usare Paginazione a Cursore per Liste - Blossom ha sostituito la paginazione basata su data con paginazione a cursore sull’endpoint /list. La paginazione basata su data fallisce quando elementi condividono timestamp; i cursori forniscono iterazione affidabile.

Validazione Schema per Tipi di Evento - Il progetto nostrability/schemata fornisce schemi JSON per validare eventi conformi ai NIP. Considerate di integrare la validazione schema in sviluppo per catturare eventi malformati prima che raggiungano i relay.

Questo e’ tutto per questa settimana. State costruendo qualcosa? Avete notizie da condividere? Volete che copriamo il vostro progetto? Contattateci via DM NIP-17 o trovateci su Nostr.