Trasferimento dati: il bundle lolly-backup

Lolly conserva la tua libreria personale sul dispositivo. Un bundle di backup è il modo in cui quella libreria si sposta: esportalo su un'installazione, porta il file come preferisci (USB, AirDrop, email a te stesso o una condivisione di rete) e importalo su un'altra. Esportare e importare non richiedono alcun server, e la destinazione può essere offline.

Questa pagina è la specifica del formato, per chi costruisce shell, strumenti o script attorno ai backup: cosa c'è nello zip, come vengono controllate le versioni, come si fonde un'importazione e cosa viene verificato. La guida per chi sposta il proprio lavoro è Move your work to another device.

signed by Lolly2026-10-21vector SVG9 paths~4.9k nodes11 groups56 KBCheck it yourselfScarica il file firmato signed by Lolly2026-10-21vector SVG9 paths~4.9k nodes11 groups56 KBCheck it yourselfScarica il file firmato

Ambito. Un bundle porta dati dell'utente, non strumenti del catalogo. Gli strumenti e le risorse del catalogo vengono sincronizzati separatamente e si presume siano già presenti sulla destinazione, al limite a una versione più alta. Gli strumenti che un utente ha creato da sé viaggiano dentro profile.json. L'importazione non installa né aggiorna mai uno strumento del catalogo.

Obiettivi

• Un formato, ogni shell. L'app web, le app desktop e mobile e le shell future condividono lo stesso envelope e gli stessi schemi delle parti. Le parti facoltative dipendono dalle capacità di ciascuna shell, e le parti non supportate vengono segnalate. Ogni bridge di capacità fornisce il proprio adattatore di archiviazione.
• Sopravvive al viaggio. Un bundle danneggiato o troncato durante il trasferimento fallisce in modo evidente all'importazione e non si ripristina mai a metà.
• Sopravvive a questa versione. Un'app più vecchia può comunque importare le parti riconosciute di un bundle più recente. Un formato davvero incompatibile viene rifiutato in modo netto.
• Sicuro da unire. Importare su un'installazione già in uso non cancella mai nulla che non fosse nel bundle.

La busta

Un bundle è un normale .zip, quindi sopravvive intatto a qualsiasi trasporto e qualsiasi strumento di decompressione può ispezionarne il contenuto.

Il download prende il nome della persona a cui appartiene: LollyTools-<First>-<Last>-<YYYY-MM-DD>-<n>.zip, per esempio LollyTools-Ada-Lovelace-2026-06-26-1.zip, così una cartella Download di backup resta leggibile. Nome e cognome vengono dal profilo e sono omessi se non impostati: nessun profilo dà LollyTools-2026-06-26-1.zip, e il solo nome dà LollyTools-Ada-2026-06-26-1.zip. Ogni nome viene ridotto a un token sicuro per i nomi di file (lettere e cifre Unicode mantenute, spazi e punteggiatura eliminati, al massimo 32 caratteri). <n> è una sequenza per giorno e per dispositivo, quindi esportazioni ripetute nello stesso giorno non collidono e restano in ordine. backupFilename() in data-transfer.ts costruisce il nome, e il contenuto dello zip è lo stesso qualunque sia il suo nome.

manifest.json

{
  "format": "lolly-backup",
  "formatVersion": 3,
  "minReader": 1,
  "app": "lolly",
  "exportedAt": "2026-06-22T09:30:00.000Z",
  "counts": { "profile": true, "sessions": 2, "userAssets": 4, "prefs": 3, "assetVersions": 1, "fileOperations": 1 },
  "integrity": {
    "profile.json": "sha256-…",
    "sessions.json": "sha256-…",
    "assets.json": "sha256-…",
    "assets/blobs/0.bin": "sha256-…",
    "file-history.json": "sha256-…",
    "file-history/versions/0.bin": "sha256-…",
    "file-history/results/0.bin": "sha256-…",
    "prefs.json": "sha256-…"
  }
}

Politica delle versioni

Due numeri di versione permettono al formato di crescere senza lasciare indietro le installazioni più vecchie.

Open this in Diagram Builder

• Un lettore importa un bundle quando manifest.minReader non supera la sua versione di lettore. Rifiuta, con "needs a newer version of the app", solo quando il bundle richiede un lettore più recente.
• Una modifica additiva, come una nuova parte facoltativa o un nuovo campo facoltativo del manifest, incrementa formatVersion e lascia stare minReader. Le app più vecchie importano comunque ogni parte che riconoscono, e le parti che non riconoscono vengono segnalate come saltate, non scartate in silenzio.
• Una modifica incompatibile, in cui l'importazione errata di una parte corrompe i dati o una parte facoltativa diventa obbligatoria, alza minReader. Le app più vecchie rifiutano allora in modo netto invece di importare qualcosa che non sanno gestire.
• Se un bundle futuro imposta formatVersion ma omette minReader, i lettori ripiegano sul controllo di formatVersion e trattano la modifica come incompatibile.

Regola pratica per gli autori: se ogni lettore esistente farebbe comunque la cosa giusta ignorando la tua aggiunta, la modifica è additiva: incrementa formatVersion e lascia minReader. Altrimenti alza minReader.

Integrità

Quando manifest.integrity è presente, un lettore controlla lo SHA-256 di ogni parte elencata prima di scrivere qualsiasi cosa. Una discrepanza ("failed its integrity check") o una parte mancante ("incomplete") ferma l'intera importazione, quindi non esiste un ripristino parziale. Questo intercetta il danno che un trasporto di file può causare: un AirDrop troncato, un gateway email che ha ricodificato l'allegato, un settore USB difettoso.

L'integrità è un controllo al meglio possibile. Viene scritta solo dove Web Crypto è disponibile (ogni contesto browser sicuro e Node moderno), e controllata solo quando sono presenti sia la mappa sia Web Crypto. Un bundle senza la mappa, come uno precedente all'esistenza dell'integrità, si importa senza modifiche: "cannot verify" non conta mai come "corrupt".

Il manifest non elenca né sé stesso né il lolly.txt rigenerato. I digest coprono le parti di cui il manifest risponde.

Regole di importazione

Un'importazione viene eseguita in una di due modalità.

• Merge è ciò che fa Import data…, e ciò che fa il primo collegamento di sync, Bring it to this device. I dati sulla destinazione restano, e nulla che non fosse nel bundle viene toccato: una sessione che la destinazione aveva e il bundle no sopravvive all'importazione.
• Replace è ciò che il sync dei dispositivi usa per tenerli allineati: prende il record del profilo, le preferenze, le sessioni, le immagini e la scelta del design system attivo della copia sincronizzata, e rimuove solo gli elementi che un altro dispositivo ha eliminato dall'ultimo sync. Ripristinare una copia precedente va oltre e fa sì che il dispositivo corrisponda a quella copia, rimuovendo tutto ciò che la copia non contiene, dopo aver salvato prima il dispositivo. Sync your devices tratta ciò che vede una persona.

In un merge, tutto ciò che è solo sulla destinazione viene mantenuto, e ogni tipo di dato nel bundle incontra la destinazione così:

Le sessioni salvate si ricollegano automaticamente alle loro immagini. I riferimenti alle risorse sono mantenuti per id, e il bridge li risolve di nuovo dopo il ripristino delle immagini, cosa che deve comunque fare perché gli URL blob: non sopravvivono a un ricaricamento.

I record della cronologia non cambiano mai dopo essere stati scritti. Una nuova importazione di versioni di risorse e ID di operazioni non aggiunge nulla, e un ID che nomina già byte o una cronologia diversi viene rifiutato, non sovrascritto. Reimportare una risorsa corrente identica ne mantiene la versione, e una risorsa corrente modificata deve portare una versione diversa.

La cronologia delle creazioni ha qualche regola in più. Una creazione il cui slot la destinazione usa per un'altra creazione viene aggiunta come creazione separata, e una creazione nel Cestino della destinazione vi resta. Un id di checkpoint che nomina contenuto diverso sulla destinazione mantiene quello della destinazione. Un archivio che non supera i propri controlli ferma l'importazione prima che cambi qualsiasi profilo, sessione, risorsa o preferenza, e una nuova importazione identica non aggiunge archiviazione.

Il riepilogo riporta cosa è successo. Ogni importazione restituisce profile, sessions, userAssets, prefs, skipped e failedAssets.

• failedAssets conta le risorse caricate che non è stato possibile ripristinare, per esempio perché l'archiviazione del dispositivo è piena.
• skipped conta le parti di un writer più recente che questa build non ha riconosciuto. L'app lo mostra ("… · N newer items skipped"), così un ripristino dichiara ciò che ha lasciato indietro.
• Con la cronologia dei file, il riepilogo aggiunge assetVersions, fileOperations, fileBatches e failedHistory. L'esaurimento dell'archiviazione o un conflitto di ID immutabile può causare un ripristino parziale, e l'app dice allora alla persona di conservare il backup sorgente.
• Con la cronologia delle creazioni, aggiunge revisions e recoveryDrafts, che contano solo ciò che questa importazione ha aggiunto, e added, kept, replaced, copies e hidden per come ogni creazione è stata unita. skippedCheckpoints conta i checkpoint il cui id nomina contenuto diverso sulla destinazione, e historyLeftOut conta i checkpoint e le bozze più vecchi che non entravano nello spazio di cronologia del dispositivo.
• Un'importazione replace aggiunge removed e failedRemovals.

Il ripristino non è un'unica transazione attraverso gli archivi di profilo, sessioni, risorse e cronologia. Il sync cloud non fa avanzare la sua revisione applicata dopo un ripristino parziale o non supportato, quindi la copia resta disponibile per riprovare.

Cosa non viaggia

• Cache del catalogo (metadati e blob delle risorse scaricati, l'indice degli strumenti), che la destinazione risincronizza gratis.
• Strumenti e risorse del catalogo, che sono fuori ambito e si presumono presenti sulla destinazione. I token del brand, i font e i loghi aggiunti dall'utente sono risorse dell'utente, quindi viaggiano.
• URL blob: e di oggetto, che il bridge rigenera al caricamento.
• Originali di conversione, lease di esecuzione attivi e segreti di accesso o firma locali alla macchina. Non sono cronologia portabile. Un risultato salvato è una copia, non una promessa che la sorgente originale sia stata salvata nel backup.
• Il contatore di sequenza delle esportazioni, il contatore giornaliero per i nomi dei download in localStorage (lolly-export-seq). È tenuto fuori da PREF_KEYS, quindi non viaggia mai in un bundle.

Il misuratore dell'archiviazione mostra la stessa suddivisione. Saved sessions, My images e File results & versions vanno in un bundle. La cache delle risorse, le anteprime degli strumenti e gli elementi fissati per l'uso offline sotto di esse si possono ricostruire, quindi restano indietro.

signed by Lolly2026-10-21vector SVG37 paths~4.9k nodes85 groups65 KBCheck it yourselfScarica il file firmato signed by Lolly2026-10-21vector SVG37 paths~4.9k nodes85 groups65 KBCheck it yourselfScarica il file firmato

Dati dell'organizzazione con Lolly Work

Questo bundle esegue il backup della libreria personale del dispositivo. Non è un backup di un'istanza Lolly Work: account dell'organizzazione, policy di accesso, progetti condivisi, versioni del catalogo, approvazioni, lavori di rendering e record di audit sono conservati da quel servizio. Ricollegati e accedi per riottenere l'accesso al lavoro condiviso; importare un bundle personale non concede quell'accesso.

Gli operatori eseguono backup, conservazione e cancellazione dei dati del server con le guide di Lolly Work: Backup and restore e Work storage and data lifecycle. Cancellare o esportare un dispositivo non esegue nessuna di quelle operazioni sul server.

Tra le shell

data-transfer.ts legge e scrive solo attraverso il bridge di capacità (host.profile, host.state, host.assets) e le preferenze localStorage condivise. Lo stesso modulo legge e scrive l'envelope comune sul web e nelle app desktop e mobile, su archiviazione IndexedDB o filesystem. Le parti facoltative della cronologia compaiono solo dove è disponibile il loro adattatore, e una parte non supportata viene segnalata come saltata all'importazione. La suite headless esercita le parti comuni su un bridge in memoria, e le transazioni della cronologia hanno anche test su browser reale.

Due shell restano fuori da questa garanzia, per motivi diversi:

• La CLI one-shot non ha nulla da trasportare: il suo stato è in memoria e dura una sola invocazione.
• La TUI conserva lo stato in ~/.lolly (sessioni, cartelle, profilo), e la sua vista Profile può eseguirne il backup, ma scrive un archivio più semplice tutto suo: saved-state/<slot>.json per sessione più profile.json e folders.json, senza manifest, senza formatVersion né minReader e senza mappa di integrità. Questo formato non può importarlo (un lettore lo rifiuta come "not a Lolly backup"), e il suo nome è confusamente simile (lolly-backup-<stamp>.zip). Unificare i due è una lacuna nota.

Non ancora portabile

L'envelope è un manifest più parti con nome, quindi nuovi tipi di dati portabili possono aggiungersi in seguito come parti additive (un nuovo formatVersion, lo stesso minReader), e i lettori di oggi saltano ciò che non riconoscono. I design system viaggiano già così, come design-systems.json più le loro risorse dell'utente.

Due nomi sono riservati a dati che non viaggiano ancora:

• tokens.json porterebbe un intero documento di design token W3C DTCG con i suoi gruppi, set e temi, il formato che Penpot importa ed esporta. I token del brand di un utente viaggiano già come risorsa user/tokens/brand in assets.json, e i token di un design system viaggiano con il suo record.
• penpot/ è riservato a un file Penpot acquisito, o al suo sottoinsieme rilevante per Lolly, presentato come strumento.

I lettori di oggi non conoscono ancora nessuno dei due nomi. Come qualsiasi altra cosa fuori dalle parti sopra, ciascuno è per loro una parte sconosciuta: lasciata intatta e conteggiata in skipped.

Parti della cronologia

Le due parti della cronologia sono facoltative e hanno versioni proprie. La maggior parte dei lettori può saltare questa sezione.

Riferimento

• Modulo: shells/web/src/data-transfer.ts (exportBackup, importBackup, BACKUP_FORMAT, BACKUP_FORMAT_VERSION, BACKUP_READER_VERSION; il generatore di nomi backupFilename() è interno).
• Test di contratto: tests/data-transfer.test.ts, che copre round trip, merge, integrità, compatibilità in avanti e il controllo del lettore.
• Test di contratto della cronologia: tests/file-history-backup.test.ts, tests/file-batch-history.test.ts e tests/file-result-library.test.ts. Accettazione su browser: tests/file-history.browser.test.ts, tests/file-batch-history.browser.test.ts e tests/file-result-reuse.browser.test.ts.
• Superficie del bridge usata: host.profile, host.state e host.assets; vedi Host API.