Le prove di CardanoWall funzionano offline?

Sì — per tutto ciò che è già sul tuo dispositivo. Una volta sincronizzati un record Label 309, il suo contenuto o testo cifrato e le chiavi per aprirlo, CardanoWall Desktop può sfogliarli, cercarli, decifrarli e verificarli senza alcuna connessione di rete. Quello che non può fare è inventare dati che non ha mai visto: una transazione che non ha mai sincronizzato, o un testo cifrato che non ha mai scaricato.

CardanoWall Desktop è offline-first. Il suo database locale è la fonte di verità per la schermata che hai davanti; la rete è un sincronizzatore in background che riempie quel database. Così l'«offline» è una modalità normale, non un errore — la macchina locale diventa una copia di lavoro della porzione di mondo delle prove che hai già scaricato.

È proprio quella copia di lavoro a rendere le prove utili sul campo: in viaggio, durante un audit, in una revisione legale, nella gestione di un incidente, o ovunque la connessione sia inaffidabile. Una prova non dovrebbe diventare illeggibile solo perché una scheda del browser non riesce a raggiungere un server. CardanoWall Desktop è open source — costruito in Rust con Tauri sopra l'SDK Rust open source, con il codice su github.com/cardanowall — così puoi leggere esattamente come si comporta, invece di prenderlo per fede.

Cosa puoi fare offline con le prove sincronizzate?

Molto, finché i dati sono già in locale. In quel caso, CardanoWall Desktop ti permette di:

sfogliare i record pubblici Label 309 sincronizzati;
cercare nel mirror locale dei record, anche per hash del contenuto;
consultare i record della Inbox già scoperti tramite decifratura a tentativi;
aprire il testo cifrato in cache;
decifrare i file sigillati con le tue chiavi locali;
verificare gli hash a fronte di file locali;
controllare la struttura dei record in cache;
rivedere la cronologia dei record inviati;
preparare bozze da pubblicare in seguito.

Sono vere operazioni crittografiche, non screenshot in cache. Il controllo dell'hash, la verifica della firma, la decifratura a tentativi — tutto gira in locale nel core Rust dell'app, su byte che sono già su disco.

Cosa non puoi fare offline?

La modalità offline ha un confine netto, ed è onesta su dove quel confine si trovi. L'app non può fabbricare dati che non ha mai avuto.

Se una transazione non è mai stata sincronizzata, l'app non può sapere che esiste senza la rete o senza qualche altra copia locale dei suoi metadati.
Se un testo cifrato non è mai stato scaricato, l'app non può decifrarlo offline.
Se un record punta a uno storage URI e quei byte non sono stati messi in cache, l'app non può recuperarli senza una connessione.
Se vuoi pubblicare una nuova prova, all'app servono un gateway e una rete: deve calcolare il preventivo della pubblicazione, caricare, inviare la transazione Cardano e confermarla. (La pubblicazione passa sempre per un gateway — vedi perché pubblicare ha un prezzo.)

Offline-first non è la pretesa che l'app possa colmare i dati mancanti. È la promessa che, una volta che i dati sono in locale, l'app li tratta a pieno titolo.

Cosa mette in cache l'app, e quanto è sensibile ciascun livello?

Ci sono quattro livelli, in ordine crescente di sensibilità.

Metadati dei record pubblici. Il desktop mantiene un mirror locale completo dei record Label 309 — sigillati e pubblici — provenienti dal gateway che hai configurato. Ogni record è piccolo (i metadati di una singola transazione, ben al di sotto del limite di metadati di Cardano, circa 16 KB), quindi l'intero insieme globale resta nell'ordine di poche centinaia di megabyte anche dopo anni di uso intenso. Questo mirror è la base per la ricerca, la scoperta nella Inbox, il tracciamento dei record inviati e l'ispezione offline. Contiene solo ciò che è già pubblico on-chain, quindi è conservato non cifrato per scelta progettuale — cifrare una copia di dati pubblici non porta alcun vantaggio.

Testo cifrato. I record sigillati fanno riferimento a payload cifrati tramite storage indirizzato per contenuto (ar:// o ipfs://). Mettere in cache quel testo cifrato è sicuro perché è già cifrato; può essere aperto solo da chi possiede una chiave corrispondente. Il desktop lo mette in cache, così riaprire un file ricevuto è istantaneo e funziona offline.

Contenuto decifrato. È questo il livello sensibile, e l'app lo tratta con cura. Per impostazione predefinita decifra su richiesta in memoria e non scrive mai testo in chiaro su disco. Esiste una cache opzionale, cifrata separatamente, per i file decifrati, pensata per chi vuole anteprime istantanee senza ripetere la procedura di apertura, ma è disattivata di default, e il testo in chiaro finisce in una posizione normale solo quando scegli esplicitamente Salva. Dovresti sempre sapere quando i file decifrati vengono conservati, dove e come sono protetti.

Materiale dell'identità. Gli Identity Seed risiedono in un vault cifrato e vengono sbloccati in locale. Senza la relativa identità sbloccata, un record sigillato può comunque comparire nel mirror come record pubblico — semplicemente non puoi aprirne il contenuto. Il seed stesso non lascia mai il dispositivo e non raggiunge mai alcun gateway. (Sul perché quel confine sia importante, vedi perché le chiavi non lasciano mai il dispositivo.)

Puoi verificare una prova offline?

Sì — una volta che hai gli input richiesti dal controllo. La verifica Label 309 è progettata per funzionare a partire dai soli dati pubblici, quindi i controlli crittografici non dipendono dai server di CardanoWall. Ecco cosa serve a ciascun controllo:

Una prova hash richiede il record e i byte originali. Il verificatore ricalcola l'hash dai byte e lo confronta con l'hash su cui il record si è impegnato. Tutto offline.
Una prova firmata richiede il record e la firma in esso integrata. La chiave di firma è contenuta nella struttura di firma del record o se ne ricava, quindi la verifica della firma gira offline una volta che il record è in locale.
Una prova sigillata richiede il record, il testo cifrato e la chiave del destinatario (o la passphrase) che lo apre. Con questi elementi in locale, l'app decifra, ricalcola l'hash del testo in chiaro e lo confronta con l'impegno del record — il passaggio che lega i byte cifrati all'affermazione con timestamp.
Una prova Merkle richiede la root presa dal record più la inclusion proof (o la lista delle foglie per ricostruirla). Poi il controllo di inclusione gira offline, senza alcun gateway nel ciclo. Costruire un Merkle tree e verificare l'inclusione sono pura computazione — vedi un record per migliaia di file.

L'unica cosa che normalmente richiede la rete è ottenere dati che non hai ancora, oltre a confermare lo stato attuale della catena. La matematica vera e propria gira in locale. (Per il modello di verifica completo, vedi come verificare un record Label 309.)

E la conferma sulla blockchain quando sei offline?

Il timestamp di una prova e il suo stato di conferma provengono da Cardano, e sono fatti che l'app legge dalla catena — non se li inventa mai.

Se l'app ha già sincronizzato una transazione e la sua profondità di conferma, può mostrare quello stato in cache anche offline. Quello che non può fare offline è venire a conoscenza di nuove conferme, di una riorganizzazione della catena o di qualsiasi contesto aggiornato, perché questo richiede di interrogare un explorer Cardano.

Per questo un client attento mantiene distinti questi stati:

i dati dei record in cache, verificati in locale;
l'ultima sincronizzazione di ciascun elemento;
la profondità di conferma all'ultima sincronizzazione;
i record ancora in sospeso o sotto la soglia di conferma;
i record che necessitano di un nuovo controllo online.

La visualizzazione offline dovrebbe essere onesta sulla freschezza dei dati. Non dovrebbe mai presentare la profondità di conferma della settimana scorsa come se fosse attuale.

Come funziona la scoperta della Inbox offline?

La tua Inbox viene calcolata in locale a partire da due cose: il mirror dei record e le tue identità sbloccate. Il gateway è volutamente cieco rispetto al destinatario — non ha idea di quali record sigillati siano «tuoi» — quindi trovare la tua posta è, per scelta progettuale, un lavoro locale.

Se l'app ha sincronizzato dei record sigillati, prova a decifrarli a tentativi a fronte delle tue identità direttamente sul dispositivo. Per ogni slot sigillato tenta una decifratura; quelli che le tue chiavi riescono ad aprire sono i tuoi messaggi. A nessun server viene chiesto chi sei.

È anche per questo che importare un vecchio Identity Seed funziona senza intoppi offline. Poiché solo la chiave del destinatario decide una corrispondenza, l'app riesamina il mirror locale già presente per quell'identità e fa emergere i record sigillati più vecchi a essa indirizzati — una passata locale, nessun nuovo download. (La tua identità è esattamente quel seed; vedi la tua identità è un seed.)

Se il mirror è incompleto, la Inbox può essere incompleta. Quando la rete torna, l'app sincronizza i record mancanti e prosegue la scoperta.

Perché non tenere tutto solo nel cloud?

Perché il cloud non dovrebbe essere la radice della fiducia. Un servizio ospitato è comodo — può pubblicare record, servire il feed, gestire i prezzi e rendere semplice l'interfaccia. Ma una prova dovrebbe sopravvivere a qualsiasi singolo account di servizio, e tutto il senso di Label 309 è che la verifica richiede solo infrastruttura pubblica: i metadati della transazione, facoltativamente i byte del contenuto e un explorer Cardano pubblico. Una copia di lavoro locale dei record che ti interessano è l'espressione concreta di quell'indipendenza.

Quella copia locale si rende utile esattamente nelle situazioni in cui una singola sessione web è troppo fragile: audit, gestione di incidenti, vincoli di conservazione legale, revisione delle prove, giornalismo, archivi di ricerca, flussi di lavoro regolamentati e conservazione a lungo termine.

Come dovrebbe usare le prove offline un team?

Decidi in anticipo cosa potresti dover dimostrare senza rete — poi sincronizza e metti in cache il materiale di verifica prima che la rete sparisca.

La forma di «cosa mettere in cache» segue il lavoro:

Un team legale potrebbe volere pacchetti di prove cifrati messi in cache su una macchina approvata.
Un team di compliance potrebbe volere i record di prova di ogni giornata e le inclusion proof disponibili durante un audit.
Un team di rilascio o DevSecOps potrebbe volere le prove di build e i manifest di rilascio in cache insieme all'archivio del rilascio.
Un team di AI potrebbe volere i manifest dei dataset e gli impegni sugli output dei modelli replicati in locale.

La regola è semplice: se potresti aver bisogno di dimostrarlo offline, sincronizzalo e metti in cache il materiale che lo prova prima che la connessione sparisca. Per il contenuto sigillato, verifica anche che il relativo Identity Seed sia salvato e disponibile alle persone o ai dispositivi giusti, secondo la tua policy — senza di esso, il testo cifrato resta chiuso.

Quali sono i rischi di tenere le prove in locale?

L'accesso offline sposta una parte della responsabilità sul dispositivo, ed è bene essere chiari su questo.

C'è il rischio legato allo storage locale. Se un dispositivo viene rubato, le sue cache contano. Il testo cifrato in cache è cifrato e non può essere aperto senza una chiave, ma qualsiasi file decifrato tu abbia scelto di conservare è sensibile, e il vault dell'identità va protetto. Il sistema operativo, la cifratura del disco, l'account utente, la passphrase e la sicurezza generale del dispositivo diventano tutti parte del modello di fiducia. CardanoWall Desktop riduce l'esposizione con un vault cifrato, il blocco automatico e un azzeramento best-effort delle chiavi in memoria, ma non può difendere una macchina del tutto compromessa e sbloccata — e lo dice chiaramente.

C'è anche il rischio legato alla freschezza dei dati. Una prova in cache è valida alla data dell'ultima sincronizzazione, ma l'app non può conoscere lo stato attuale della catena finché non si riconnette.

Un buon software rende visibili questi confini: mostra l'ora dell'ultima sincronizzazione, distingue la verifica in cache da un controllo online aggiornato ed evita di scrivere silenziosamente testo in chiaro decifrato in posizioni non sicure.

Cosa dovresti conservare per una prova di lungo termine?

Per le prove che contano per anni, conserva più del semplice hash della transazione. A seconda del tipo di prova, questo significa:

il riferimento della transazione;
i byte del record Label 309 (o un export verificato);
il file originale o il testo in chiaro;
il testo cifrato, per i record sigillati;
l'Identity Seed o il segreto del destinatario necessario a decifrare;
la lista delle foglie Merkle o le inclusion proof;
eventuali firme o chiavi pubbliche necessarie per l'attribuzione;
una breve nota su come è stata creata la prova e a quale processo appartiene.

La blockchain fornisce l'àncora pubblica — il fatto che questi byte esatti esistevano entro un orario di blocco pubblico. Il tuo archivio locale conserva il contesto che rende quell'àncora utile in seguito. (E ricorda cosa l'àncora afferma e cosa no: vedi cosa una prova non dimostra.)

In breve

La prova offline non è magia; è preparazione. Se il record, il contenuto, il testo cifrato, le chiavi e le eventuali inclusion proof sono in locale, i controlli crittografici girano tutti in locale. Se qualcosa non è mai stato sincronizzato o messo in cache, all'app serve la rete per recuperarlo — e te lo dice, invece di far finta di niente.

CardanoWall Desktop rende normale quella copia di lavoro locale: sincronizza i record, scopre gli elementi sigillati della Inbox sul dispositivo, mette in cache i file cifrati, verifica le prove e mantiene utili le prove già sincronizzate anche quando la rete non c'è.

Approfondimenti

CardanoWall Desktop — il client desktop open source descritto in questo articolo.
Come verificare un record Label 309 — il modello di verifica per intero.
Un record per migliaia di file — il Merkle batching, tutto offline tranne la pubblicazione.
Cosa una prova non dimostra — i limiti di una prova di esistenza con timestamp.
Il codice open source, la CLI e gli SDK: github.com/cardanowall.