Come ricevere un record sigillato

Per ricevere un record sigillato condividi un indirizzo di ricezione e lasci che il tuo software trovi i record che le tue chiavi possono aprire. Non c'è nessuna casella che il server riempie al posto tuo. Il tuo client scorre il feed pubblico Label 309, prova le tue chiavi di ricezione su ogni record sigillato e ti mostra quelli che riesce a decifrare.

È proprio in questo ribaltamento che sta tutta l'idea: la tua Inbox è scoperta tramite decifratura, non assegnata da un server. La catena non porta mai un campo destinatario leggibile e il gateway non ha mai bisogno di sapere quali record sono tuoi.

Cos'è un record sigillato?

Un record sigillato è una Proof of Existence con il contenuto cifrato.

Il record pubblico si impegna comunque sull'hash del testo in chiaro, così la prova potrà mostrare in seguito che quel contenuto esatto esisteva entro un block time pubblico. Il file vero e proprio è cifrato e il testo cifrato risiede in una posizione indirizzata per contenuto come Arweave o IPFS — mai on-chain. (Per i meccanismi della prova pubblica, vedi come funziona Label 309.)

Chiunque possieda una chiave corrispondente può decifrare il testo cifrato, recuperare i byte originali, ricalcolare l'hash del testo in chiaro e confermare che il file decifrato corrisponde all'impegno on-chain. Chi non ha una chiave vede che esiste un record sigillato — ma non dovrebbe poterne leggere il contenuto.

Cosa devo dare al mittente?

Dai al mittente un indirizzo di ricezione. Nient'altro.

Per i record sigillati Label 309, gli indirizzi di ricezione si presentano in due forme:

• age1… — il percorso di ricezione classico X25519.
• age1pqc1… — un percorso di ricezione ibrido post-quantum (X25519 combinato con ML-KEM-768, nella costruzione X-Wing).

Un indirizzo di ricezione è pubblico e si può condividere senza rischi. Permette a qualcuno di cifrarti un record e nient'altro. Deriva dalla tua identità, ma non la rivela.

Non dare al mittente il tuo Identity Seed. Il seed è la radice privata della tua identità — i 32 byte da cui derivano in modo deterministico la tua chiave di firma e le tue chiavi di ricezione. Chiunque lo possieda può firmare e decifrare al posto tuo. (Per capire perché il seed è il vero backup: la tua identità è un seed.)

Come crea il record il mittente?

Il software del mittente esegue la sigillatura in locale. A grandi linee:

1. Il mittente sceglie un file o un messaggio.
2. Il software calcola l'hash del testo in chiaro.
3. Il software genera una chiave di contenuto monouso e cifra il contenuto.
4. Per ogni destinatario, avvolge quella chiave di contenuto con la chiave di ricezione del destinatario, producendo uno slot per ciascun destinatario.
5. Il testo cifrato viene caricato su uno storage indirizzato per contenuto (come ar://).
6. Un record Label 309 viene pubblicato su Cardano, portando l'hash del testo in chiaro e la busta sigillata.

Il record on-chain dimostra il momento e porta gli slot di chiave avvolti. Il testo cifrato conservato contiene il file cifrato. La tua chiave privata è ciò che apre il tuo slot. La stessa sequenza — calcola l'hash, firma, sigilla, condividi — è percorsa passo passo in calcola l'hash, firma, sigilla, condividi.

Come fa il mio client a trovare un record destinato a me?

Il tuo client scorre i record pubblici e prova ad aprirli.

È la parte che risulta poco familiare se ti aspetti una normale casella di posta. In una Inbox ospitata, il server sa a quale account appartiene un messaggio e lo instrada. Un record sigillato Label 309 non porta nessun instradamento del genere. La busta elenca gli slot di chiave avvolti, ma nessuna chiave pubblica del destinatario compare da nessuna parte nei dati trasmessi — non c'è alcun campo destinatario da leggere.

Quindi il tuo client sincronizza il feed pubblico dei record Label 309 e, per ciascun record sigillato, verifica se qualche slot si apre con le chiavi di ricezione della tua identità. È la decifratura a tentativi in locale: un tentativo di sbloccare ogni slot, eseguito interamente sul tuo dispositivo. Se uno slot si apre, il record è tuo e il tuo client lo aggiunge alla tua Inbox. Se nessuno si apre, il tuo client lo ignora.

Una conseguenza sottile ma importante: nemmeno l'ordine degli slot rivela qualcosa. Un mittente mescola gli slot prima di pubblicare, quindi persino la posizione del «destinatario principale» non porta alcun segnale.

La decifratura a tentativi deve scaricare ogni file?

No. La decifratura a tentativi lavora sulla busta portata nel record on-chain, non sul file conservato.

Gli slot avvolti e un piccolo tag di autenticazione risiedono nei metadati stessi del record. Il tuo client può stabilire che un record è indirizzato a te — e recuperare la chiave di contenuto — partendo da quei soli byte on-chain, prima di scaricare qualsiasi testo cifrato. Questo conta perché il testo cifrato può essere grande: un client desktop può prima scoprire quali record sono tuoi, poi scaricare i file cifrati in modo pigro quando li apri, oppure precaricarli secondo le tue impostazioni.

Per un client offline-first, questa separazione è la base:

• sincronizza il feed pubblico dei record;
• decifra a tentativi in locale sulle buste;
• metti in cache il testo cifrato corrispondente, se lo vuoi;
• decifra su richiesta quando apri un file;
• mantieni utilizzabile senza rete tutto ciò che è già sincronizzato.

Cosa sa davvero il gateway?

Un gateway sa quello che sa qualunque osservatore pubblico, più i dettagli operativi del servizio che gestisce.

Per un gateway ospitato, ciò può includere l'attività dell'account, l'uso delle API, il tuo flusso di preventivo-e-pubblicazione, l'attività di upload, lo stato del saldo, i dati infrastrutturali a livello di rete e i metadati pubblici dei record che tutti possono vedere. (Per il quadro completo del confine, vedi cosa può vedere CardanoWall.)

Ciò di cui non ha bisogno è il tuo Identity Seed, le tue chiavi private di ricezione o una qualsiasi capacità di decifrare il contenuto sigillato per te. La proprietà di privacy qui non è «il server non impara nulla su niente» — sarebbe disonesto. È più ristretta e più utile: l'abbinamento del destinatario e la decifratura avvengono in locale, quindi non viene pubblicato alcun campo destinatario leggibile e nessuna chiave privata viene mai inviata al gateway. Il gateway è cieco rispetto al destinatario per progettazione; qualsiasi tentativo di filtrare i record per destinatario viene semplicemente ignorato, perché non esiste una colonna destinatario su cui filtrare.

Perché non c'è un campo destinatario pubblico?

Perché un campo destinatario pubblico rivelerebbe il grafo sociale.

Se ogni record sigillato indicasse esattamente per chi è, un osservatore potrebbe mappare le relazioni tra mittenti e destinatari senza leggere un solo byte di testo in chiaro. Per i flussi di lavoro riservati — una fonte che contatta una redazione, un'offerta sigillata, prove in deposito fiduciario — questa esposizione può essere tutto il rischio.

Label 309 usa invece gli slot di chiave avvolti. Il record porta materiale cifrato che solo i titolari delle chiavi previste possono aprire. Un osservatore può vedere che un record è sigillato e quanti slot ha, ma non un elenco leggibile di destinatari.

Questo non è anonimato perfetto, e non va venduto come tale. Il numero di slot, il momento della pubblicazione e i metadati esterni possono comunque rivelare qualcosa, e un mittente che deve sconfiggere la correlazione temporale deve pubblicare fuori dalla timeline sensibile. Ciò che il progetto elimina è la fuga più ovvia: una colonna destinatario pubblica su un registro permanente.

E se ho più identità?

Il tuo client prova ogni identità sbloccata.

Potresti tenere un'identità per i record personali, una per un'azienda, una per la ricezione legale e una per un canale riservato ad alto rischio. Ognuna ha il proprio seed e le proprie chiavi di ricezione, quindi un record sigillato per una è invisibile alle altre finché non vengono provate le chiavi di quell'identità.

Un client offline-first tiene traccia, in modo indipendente, di quanto ciascuna identità ha già percorso del feed dei record. Quell'indipendenza è ciò che ti permette di importare in seguito un vecchio seed e far riscorrere al client l'intero feed per quell'identità — invece di partire da oggi e perdere in silenzio tutto ciò che è stato inviato prima dell'importazione.

Cosa succede quando ripristino un vecchio Identity Seed?

Un software compatibile rideriva le stesse chiavi di ricezione dal seed, in modo deterministico.

Significa che un vecchio seed può trovare vecchi record sigillati, a patto che i record siano ancora sulla catena da scorrere e che il testo cifrato sia ancora recuperabile o in cache. Il client riscorre il feed pubblico, decifra a tentativi le buste sigillate e ricostruisce la vista della Inbox per quell'identità. Ripristinare il seed ripristina la capacità di riconoscere i record destinati a esso — il gateway non conserva alcuna casella privata da restituire.

È una delle ragioni più chiare per cui il seed conta così tanto, e per cui l'Identity Seed merita ancora la tua attenzione. Se perdi il seed di un'identità destinataria, i record sigillati indirizzati a essa possono diventare illeggibili — anche se le prove pubbliche restano sulla catena e continuano a risultare valide. La cifratura non ha alcuna backdoor di recupero, per progettazione; il seed è il percorso di recupero.

Un client desktop può ricevere record offline?

Può lavorare con tutto ciò che ha già sincronizzato.

CardanoWall Desktop — un'applicazione open-source in Rust costruita con Tauri sull'SDK Rust open-source (github.com/cardanowall) — è pensato esattamente attorno a questo. Una volta sincronizzati i record e messo in cache il testo cifrato, elenca, cerca, verifica e decifra quei dati locali senza alcuna connessione di rete. Se un record non è ancora stato sincronizzato, o un testo cifrato non è stato scaricato, gli serve la rete per recuperarli — e lo dice chiaramente invece di fallire in silenzio.

Rispecchia il comportamento di un client di posta serio: offline non significa che il mondo si ferma. Il tuo mirror locale, la cache e il vault diventano la fonte di verità finché la rete non ritorna. (Per saperne di più sul modello offline: prove offline e CardanoWall Desktop.)

Come dovrei verificare chi ha inviato un record?

Ricevere un record sigillato dimostra soltanto che la tua chiave può aprirlo. Non dimostra chi l'ha inviato.

In Label 309 l'attribuzione di autore è facoltativa. Se un record porta una firma, quella firma mostra che una particolare chiave ha garantito per il record — ma ti serve comunque il contesto per decidere di chi sia quella chiave. Se un record non è firmato, il mittente può aver volutamente evitato di vincolare qualsiasi identità, che è esattamente ciò che alcuni flussi di lavoro riservati richiedono.

Per materiale sensibile, conferma le chiavi del mittente e gli indirizzi di ricezione tramite un canale separato: tieni una rubrica, confronta i fingerprint delle chiavi e usa una directory o una conferma diretta di cui ti fidi già. La cifratura protegge il contenuto; decidere con la chiave di chi stai parlando è una decisione di fiducia separata e umana. I meccanismi della rubrica sono trattati in come funziona la rubrica.

Cosa può andare storto?

Il fallimento più grave è perdere il seed. Perdi l'Identity Seed di un'identità destinataria e potresti perdere la capacità di decifrare i record indirizzati a essa — in modo permanente, per quell'identità.

Il resto è operativo, e un buon software dovrebbe mostrarlo onestamente invece di nasconderlo:

• il testo cifrato non è mai stato caricato con successo;
• la posizione di storage è temporaneamente non disponibile;
• il mittente ha usato l'indirizzo di ricezione sbagliato;
• hai importato l'identità sbagliata;
• il dispositivo locale è compromesso (un programma malevolo su una macchina sbloccata può leggere i segreti in memoria — vedi modalità computer pubblico);
• il record è troppo recente e non ha raggiunto la profondità di conferma che richiedi;
• il record è valido ma non firmato, quindi non è stabilita alcuna identità del mittente.

Un sistema di prove conquista fiducia mostrando l'incertezza, non nascondendola.

In breve

Per ricevere record sigillati:

1. Condividi un indirizzo di ricezione.
2. Tieni il tuo Identity Seed al sicuro e con un backup.
3. Lascia che il tuo client scorra il feed pubblico Label 309.
4. Lascia che decifri a tentativi in locale.
5. Apri e verifica i record che le tue chiavi possono decifrare.

La tua Inbox non è una lista lato server di messaggi indirizzati al tuo account. È una vista locale dei record sigillati che la tua identità può aprire — ed è precisamente ciò che tiene il gateway fuori dalla tua corrispondenza privata.

Un'ultima nota onesta sui limiti: un record sigillato mantiene il testo in chiaro cifrato per i titolari delle sue chiavi, ma non garantisce l'anonimato, e chiunque lo decifri può poi scegliere di divulgare il testo in chiaro. La prova mostra che byte specifici esistevano entro un momento pubblico. Non dimostra verità, proprietà o autore — vedi cosa non dimostra una prova.

Approfondimenti

• Cos'è un indirizzo di ricezione?
• Verifica un destinatario prima di sigillare un file
• Divulgazione riservata senza file pubblici
• Lo standard aperto e il suo codice di riferimento: label309.org e github.com/cardanowall. Label 309 è sottoposto al processo CIP di Cardano e in revisione.