The web seam: a multi-user substrate, and what it does not yet prove
Over a few days DalkkakAI grew a cloud web seam on top of the local terminal app: Supabase-direct data, multi-tenant RBAC, two-way desktop sync, and a real-time coordination layer. Here's the whole picture in one place — and an honest line about what it has and hasn't earned yet.
Where it started
DalkkakAI is a local, native terminal multiplexer with Claude-Code augmentation — one person, one machine, fully offline. This stretch added a cloud seam so the same workspace can be opened in a browser, and eventually by more than one person.
What got built (all merged to main, web deployed)
- Retired the custom server. The web talks to Supabase directly; row-level security is the security boundary, not a server we maintain. The Fly deployment was torn down to zero cost.
- Multi-tenant RBAC. Entities → services → memberships, four roles (viewer / contributor / admin / owner), RLS enabled and forced on every table, access funneled through
SECURITY DEFINERhelpers, ownership moved only through owner-gated RPCs. An eight-agent adversarial audit found and closed the holes before merge; a later audit re-read the schema and found zero cross-tenant leaks. - Two-way sync. The desktop stays the source of truth and works offline; the cloud is an additive opt-in copy. Checklist and widget content sync both ways with per-item last-write-wins and tombstones (its own write-up covers the clobber bug that taught this).
- Real-time coordination. Ticket locks (atomic claim/release), a who's-online presence chip, and live checklist — over Supabase Realtime, so the coordination surface updates instantly instead of on a 20-second poll. An adversarial review caught that presence broadcast leaked member emails across tenants (presence channels are not RLS-gated like row changes); fixed with private channels plus a
realtime.messagespolicy, verified by a smoke test that a non-member is rejected.
The throughline: the desktop never regressed. Every cloud feature is additive, opt-in, and fails closed — if Supabase is unconfigured or a sync errors, the local app is untouched. That was the one non-negotiable.
What it does NOT yet prove
Honesty first, since that's the house rule:
- The two-way desktop sync has never been confirmed on the founder's real app with real data end-to-end — the verification was done on a throwaway test instance, and a separate write-up exists about catching exactly that gap.
- The real-time and presence features are verified in isolation (unit tests, e2e smokes, the security gate) but the multi-user experience hasn't been watched with two real people.
- And the bigger one: building a multi-user web substrate is not the same as proving anyone needs it. The wedge is still operating-memory; this is plumbing that makes a team product possible, not evidence that it's wanted.
The honest state
The architecture is in place and audited. The validation — does it work on the founder's real machine, does a second person actually use it — is the next thing, and it belongs to dogfooding, not to another branch.