Offline photo sync with kinedb

The phone saves a photo and its record in an embedded kinedb database, with no network. The sync sends the photo as chunks named by their hash. The link between the phone and the server is a proxy that you control: slow it down, cut it, or lose a reply.

Loading…

Phone

Sync with the server when the page opens

Waiting to be sent

—

Photos on the phone

Log

Link (proxy)

Offline Speed: full 3G (384 kbit/s) GSM (40 kbit/s)

Scenario 1 — the connection drops halfway

Save a photo of 1 MB or more.
Sync now. The sync fails. The server holds no row of the photo, only some of its blocks (right side).
Sync again. Only the missing chunks go: see "chunks sent now".

Scenario 2 — the server commits, the phone misses the reply

Save a photo.
Sync now. The sync fails. The server holds the photo and its record, once: they are one commit.
Sync again. The server answers "replayed" for both. 0 chunks go, and nothing is stored twice.

What passed the link

0chunks

0chunk bytes

0pushes

0drops

0replies lost

Frames

Server — db.kinedb.com

The selected photo:

—

Photos on the server

No photo yet.

The last sync

No sync yet.

Known limits of this PoC (kinedb gaps, not solved here):

The phone database is stored in the browser (OPFS, kinedb B1215 and B1461, new on 2026-09-30). It is tested in Chrome on a desktop; on an iPad it is not tested yet.
The demo syncs the whole photo table: a first sync downloads every photo on the server (200 photos took 71 s, measured).
The page reads a photo as a whole into memory. The engine can stream a large file (kinedb B1429); the page does not use that yet.
This is the browser runtime (WebAssembly). Native iOS and a Swift interface do not exist yet.