Local-first is a relationship to ownership, not a badge

The local-first software essay by Ink & Switch argues for software in which users retain control of data and can work across devices without depending on a central service for every action. The term is broader than ‘stores a cache’. A product can render quickly from local data while still making a remote server the only authoritative copy.[1]

For a visual library, ask concrete questions: Can I browse and annotate offline? Is the primary copy readable without the vendor? Can I export sources and notes? What happens when two devices edit the same reference? Can shared material be revoked without exposing private assets? Answers matter more than the label.

Local storage changes the failure modes

Keeping a library on the device can reduce unnecessary transfer and allow an application to work without a network. It also concentrates risk on that device. Hardware can fail; profiles can be reset; an extension can be removed; malware or another local account may gain access; and a one-machine collection can be lost without a tested copy elsewhere.

Chrome’s extension documentation says storage.local remains after normal cache and history clearing but is removed when the extension is uninstalled. It also documents storage quotas. Those behaviors are implementation facts, not a backup policy.[2]

• Sync keeps working copies aligned; it may copy mistakes or deletions.
• Backup preserves a recoverable earlier copy; it should be tested.
• Export provides portability; it may omit binary assets or history.
• Encryption protects data in specific threat models; it does not prevent every leak.

Use a recovery checklist before trusting the library

Export a small sample and restore it somewhere separate. Confirm that the source URL, note, collection, capture date, and asset state survive. Decide how often important changes receive a backup and how many earlier versions are retained. If references are sensitive, include device access, disk encryption, shared-account boundaries, and deletion in the review.

Sesavu’s current Chrome extension stores captures locally, while the public web app remains a read-only prototype and fails closed when its backend is unavailable. It does not yet provide a production cloud-sync or backup promise. Keep an independent copy of critical reference metadata and do not place irreplaceable material in a single extension profile.[3]