Forem: Alfredo Rivera

Escape the cloud

Alfredo Rivera — Thu, 23 Apr 2026 17:18:56 +0000

A local-first platform where users own their data cryptographically — built on encrypted SQLite, CRDTs, and libp2p.

Here is the simplest thing you can do with the platform:

const platform = await createPlatform()

const rows = await platform.exec(
  'SELECT * FROM notes WHERE scope_id = ?',
  ['user:alice']
)

That looks like any other database query. The difference is where it runs.

The exec call crosses into a Web Worker running an encrypted SQLite database stored on the user's device. The encryption key is derived from the user's 12-word mnemonic and never transmitted anywhere. No server was involved.

Add a second device:

// Same mnemonic → same keys → same identity
// Devices find each other on the LAN via mDNS
// Changes sync peer-to-peer — no server, no internet required
const platform = await createPlatform({ mnemonic })

Add a collaborator:

// Alice grants Bob editor access to a document
await platform.peers.grant(bobPublicKey, 'doc:abc123', 'EDITOR')

// Enforced inside the WASM binary via a BEFORE INSERT trigger
// Bob's writes to other scopes are rejected before they touch the database

Add a live query:

const unsub = await platform.live(
  'doc-blocks',
  'SELECT * FROM blocks WHERE scope_id = ? ORDER BY pos ASC',
  ['doc:abc123'],
  diffs => {
    applyDiff(blocks, diffs)
    render(blocks)
  }
)

The diff arrives when a remote peer's change lands locally. Column-level — only what changed. The developer does not manage WebSocket connections, conflict resolution, or presence channels.

The schema is the configuration

CREATE TABLE blocks (
  id       TEXT PRIMARY KEY,
  scope_id TEXT,
  content  REALTIME_TEXT,   -- syncs at 5ms, live queries fire on change
  cursor   EPHEMERAL_INT,   -- syncs fast, never backed up
  title    LWW_TEXT         -- last-write-wins, batched at 50ms
);
SELECT crsql_as_crr('blocks');
SELECT crsql_policy('blocks', 'OWNER:RW, EDITOR:RW, VIEWER:R');

The column type affinities configure sync strategy, CRDT merge behaviour, and access policy. One CREATE TABLE. The runtime handles the rest.

When you need a server

Some problems need centralization — aggregation, ranking, feed algorithms. The platform handles this through server peers: specialist participants on the same mesh that receive capability-gated data from users, do the work, and write results back through the same sync mechanism.

// Write a request row — server peer picks it up via live query
await platform.exec(`
  INSERT INTO peer_requests VALUES (?, 'srv:ai:alice', 'ai.assistant', ?, 'pending', NULL, ?, ?)
`, [ulid(), JSON.stringify({ prompt: 'summarise my week' }), myPubKey, Date.now()])

// Response arrives through CRDT sync — no separate API layer
const unsub = await platform.live('ai-result',
  'SELECT status, result FROM peer_requests WHERE id = ?', [id],
  rows => { if (rows[0]?.status === 'complete') { show(rows[0].result); unsub() } }
)

The server peer only sees data from users who have issued it a capability grant. Aggregation happens server-side. The underlying data stays with users.

What exists today

slf-db — the WASM binary. Encrypted SQLite with CRDT replication, live queries, sync outbox, and capability enforcement baked in.
slf-worker — the Web Worker. Owns libp2p networking, identity, sync protocol, pairing, inbox, and leader election.
slf-sdk — the main thread SDK. Comlink bridge to the worker, Drizzle adapter, and proxies for peers, files, identity, and publishing.
slf-proxy — the Go binary. Gives native apps TCP connections and LAN discovery via mDNS. Same source compiles to an Electron child process and a Capacitor gomobile framework.
slf-auth — the auth authority. Registers identities, issues attestations, manages @handles, and federates across instances via the same CRDT sync everything else uses.

The apps that will run on this — notes, health, finance, passwords — are next.

The hard open problem is recovery. Losing a mnemonic with no backup is permanent. WebAuthn sealing mitigates the daily-use risk — the mnemonic lives in the secure enclave, daily opens are biometric — but it does not solve the lost-all-devices scenario. That is an active design problem, not a solved one.

Codebase is private while the core stabilises. Questions welcome in the comments.

One-trick ponies are easy to replace

Alfredo Rivera — Sun, 19 Apr 2026 20:12:28 +0000

There's a structural weakness in almost every app built in the last decade and we don't talk about it much because we're all doing it.

The app requires our infrastructure to function. The moment we stop paying the server bill, the moment the company gets acquired and wound down, the moment we make a business decision that doesn't work out — the app stops working. Everything the user put into it becomes inaccessible, or gone.

We built a generation of software where the app and the company are the same thing. One-trick ponies. Easy to replace, but only after the damage is done.

The user bears the cost of that fragility. Not us.

The ownership gap

Most apps have a line in their terms of service that says something like "you own your data." It's technically true in a legal sense. In practice it means almost nothing, because the data lives on infrastructure we control. We can read it. We can lose it. We can hand it over. We can take it with us when we shut down.

"Your data" and "data we're storing on your behalf" are very different things. The gap between them is where most of the broken trust in modern software lives — data breaches, forced migrations, shutdown notices, subpoenas, acquisitions. Every one of those is a moment when users find out what "your data" actually meant.

We built a world where users have to trust us not to misuse what we can never stop ourselves from seeing.

This isn't a policy problem. Strong privacy policies don't close the gap — they just describe it more politely. The gap is architectural. The only way to close it is to change where the data lives.

What if the data just lived on the device

The idea I've been exploring: each user has their own SQLite database, on their own device, encrypted at rest with a key derived from something only they know. The app reads and writes to it directly. There is no server-side copy. Not "we anonymize your data." Not "we encrypt it at rest." It simply isn't there.

This isn't a new idea. Local-first software has been a research topic for years. What's changed is that the primitives to build it properly in a browser finally exist. OPFS landed in all major browsers in 2023 — real persistent file system access with the synchronous I/O that SQLite needs. Before that you were stuck with in-memory databases that evaporated on tab close. cr-sqlite brings CRDT semantics to SQLite tables, which means two local databases can sync and merge correctly without a central authority to resolve conflicts. libp2p handles peer discovery and transport so devices can find each other directly — on a local network, over WebRTC, through a mesh that includes cloud nodes as peers rather than authorities.

The server component doesn't disappear entirely. But it changes its role. Instead of holding data, it helps devices find each other. Instead of being the source of truth, it's a well-connected peer with better uptime. If it goes away, the app keeps working. The data is still there, on the device, where it always was.

What this means for how you write the app

The direction I've been exploring is encoding behavior directly in the schema. SQLite lets you declare any string as a column type — it stores it verbatim and applies the closest standard affinity, but ignores what it doesn't recognize. A sync runtime can read those type names at open time and self-configure:

CREATE TABLE notes (
  id        TEXT PRIMARY KEY,
  body      REALTIME_TEXT,
  is_pinned LWW_INTEGER,
  cursor    EPHEMERAL_INTEGER
);

REALTIME_TEXT streams changes to connected peers as they happen. LWW_INTEGER gets last-write-wins semantics from cr-sqlite's CRDT merge. EPHEMERAL_INTEGER broadcasts for presence and expires — never persisted, never synced to offline peers.

The same CREATE TABLE statement runs against a vanilla SQLite database. The schema is the configuration. No separate sync layer to set up, no registration calls, no framework to learn on top of the framework you're already using.

I find this direction interesting but I'm genuinely uncertain whether it covers real developer needs or just the ones I've imagined. This is one of the things I most want to stress-test.

The identity question nobody wants to answer

If the data lives on the device and moves between devices as encrypted payloads, identity has to work differently too. There's no server handing out session tokens. The approach I've been working through is a keypair derived from a mnemonic — twelve words that generate the same Ed25519 keypair deterministically on any device. Your keypair is your identity. Your data is addressable by your public key. Messages for you are encrypted to it.

Lose the mnemonic, lose the identity. No password reset. No support ticket. That's technically clean and I'll be honest — practically uncomfortable for most consumer use cases. Whether it's an unsolvable friction point or an abstraction problem that hasn't been cracked well enough yet, I'm not sure. Hardware keys, biometrics, social recovery schemes all exist as partial answers. None of them feel complete.

What I'm actually asking

I've been building toward this for a while and I'm at the point where the architecture makes sense to me but I'm aware that's not the same as it making sense to anyone else.

The one-trick pony problem is real. Apps die and take user data with them regularly enough that we've stopped being surprised by it. The ownership gap is real. "Your data" as a marketing claim rather than a technical property is a kind of slow dishonesty that erodes trust in software broadly.

Whether this specific approach to fixing those problems is the right one, or whether there are practical walls I haven't hit yet — that's what I want to find out.

If you've thought about this problem and decided the tradeoffs weren't worth it, I want to hear why. If you've built something in this space and hit walls I haven't mentioned, same. The parts I'm least certain about: whether schema-encoded sync is actually usable or just elegant on paper, and whether keypair identity is a dealbreaker or a solvable UX problem. Both feel important to get right before spending a year building.