Protected location data × Interocitor

Useful privacy boundary. Bad safety system.

Alex and Sam share protected location rows through a mailbox that cannot read the place names. Update one local device and watch the other receive the latest known state on the five-second sync cycle.

PayloadEncrypted before storageThe mailbox does not receive place names or map coordinates.

FreshnessAuto-sync every 5 secondsAn offline or sleeping device catches up after it reconnects.

TrustEvery paired endpointMesh keys grant access to every location row in this demo.

Trusted device 01

Alex’s view

local copy

Trusted device 02

Sam’s view

local copy

What this proves

Encryption solves less than a locator product must.

Protected payloads can keep stored coordinates out of the mailbox’s plaintext boundary. They do not establish consent, prevent an authorized family endpoint from misusing data, guarantee freshness, erase historical copies, or make delayed state suitable for safety decisions.

The minimal shape

Illustrative excerpt: location acquisition, consent UI, local stores, and mesh-key setup are omitted. The linked TypeScript source is the complete runnable demo.

const schema = {
  tables: {
    locations: {
      fields: {
        id: types.string,
        name: types.string,
        place: types.string,
        x: types.number,
        y: types.number,
        updatedAt: types.index(types.number)
      }
    }
  }
} satisfies DatabaseSchemaDefinition<LocatorDB>;

const locations = db.table("locations");

await locations.put("alex", {
  id: "alex",
  name: "Alex",
  place: "Riverside Park",
  x: 72,
  y: 74,
  updatedAt: Date.now()
});
// flushDebounce and pollInterval are both 5 seconds in this demo.

Read the full locator source →