Cross-platform backup fails both directions: Chrome export writes no file, Android export rejected by web restore
Summary
Two independent defects in the backup system. Neither is user error — the export files are valid and restore fine within their own platform. Cross-platform portability, documented as supported, does not work.
Environment
Dell Vostro 15 5501 / Windows 11,
Chrome 155.0.8059.86 (Official Build, 64-bit)
Firefox 143.0 (64-bit) — used for comparison
Samsung Galaxy Tab S7 FE 5G, Venice app v1.17.15
Web app on Windows 11
Bug 1 — Chrome export silently produces nothing. Windows 11 + Chrome 155.0.8059.86 on a desktop, exporting from a Samsung Galaxy Tab S7 FE 5G backup workflow.
Steps:
Web app → chat drawer → profile → Backup Chat History
Choose zip export, select Downloads as destination
Wait for "backup completed successfully"
Actual: no file appears in C:\Users\<user>\Downloads. No entry in chrome://downloads, so the download manager is never invoked. No blocked-download icon. No exception in console.
Expected: a .zip file lands in the chosen folder.
Notes:
Same flow in Firefox 143.0 works — the file downloads normally. Chrome 155 has full File System Access API support; Firefox 143's is partial, so Firefox likely falls back to a blob download while Chrome takes the FS Access path and fails silently. The version gap is consistent with that hypothesis.
Console shows a
setIntervalviolation and Clerk preload warnings only.
Bug 2 — Android export cannot be restored in the web app
Steps:
Android app → Settings → Backup & Restore Chats → Backup, with passphrase
Transfer
.venicebackupto WindowsWeb app → restore → browse for zip → select file → Merge
Actual:
Worker message: Starting restore worker
Worker message: Opening zip
Worker message: error: End of central directory not found
UI: "Backup Restoration Failed — An unexpected error occurred. Please try again."
Expected: restore succeeds. The Android app restores the same file without issue.
Ruled out:
Transfer corruption — file sizes verified identical, transfer repeated
Picker filter — file selectable via "All Files"
Extension — renaming
.venicebackup→.zipmakes no differenceFile size — fails identically on a 12.7 MB and a 171 MB export
Browser — fails in both Chrome 155 and Firefox 143
Evidence — the two formats
Android .venicebackup is a JSON header followed by raw ciphertext. Header:
{"magic":"venice-backup","formatVersion":2,"frameCount":0,
"kdf":{"dkLen":32,"N":131072,"p":1,"r":8,"id":"scrypt","saltB64":"..."},
"cipher":{"id":"xchacha20poly1305"},
"compression":"gzip",
"app":{"appVersion":"1.17.15","platform":"android"},
"createdAt":1791771912165}
A web-app-created backup is a ZIP containing:
manifest.json 320 bytes
db/chunk-0.bin 4,346 bytes
opfs/media/<ownerId>/attachments/<file>.png
manifest.json:
{"backupVersion":4,"ownerId":"user_...","mediaPaths":["media/..."],
"salt":"...","databaseVersion":"31","chunkCount":1,
"createdAt":"2026-10-25T18:44:59.208Z","name":"Windows11Chrome"}
Key divergences:
Suspected cause
The restore worker detects container type by attempting a ZIP read first. Given a JSON file it fails at EOCD lookup and never tries a JSON path. Separately, the two platforms appear implemented against different format generations (formatVersion: 2 vs backupVersion: 4) that were never reconciled.
Suggested fixes
Sniff the container by first bytes —
PK= ZIP,{= JSON — instead of assuming ZIP.Unify the formats, or have the Android app export the ZIP layout so one parser serves both.
Widen the restore picker's
acceptfilter to include.venicebackupand.venicebackuppack.Fix the Chrome export path — fall back to a blob download when the File System Access write fails, so failures are visible rather than silent.
Impact
Cross-platform restore is unusable. Users lose chat history, media, folders, Minds and memories when moving between tablet and desktop. Current workaround is manual copy-paste, which drops media and structure.
Attachments
Happy to supply a 12.7 MB sample .venicebackup (passphrase-encrypted, safe to share) plus a web-created ZIP for comparison.
Log in to comment and vote
No comments yet
Be the first to share your thoughts.