How an App Runs on LastDB
We spent a day trying to answer a plain question: what actually has to be true before you can run an app against a local LastDB node? The answer is nicer than a store, and stricter than “just launch the binary.”
LastDB is a local database on your machine. Apps are how you work with that data — notes, boards, memory, whatever lens you need. As more apps show up, the natural product questions follow: is there a registry? Do you pre-approve what can run? Is there a place to look apps up?
We went looking for the shortest true answer. Not the roadmap pitch — the current shape of the system, exercised end to end on a throwaway node so we could not kid ourselves.
The short answer
You do not pre-approve a list of binaries for the launcher. You also do not need a public app-store browse surface to make the model work. What you need is clearer than either: a process that can talk to the node, an app identity that means something, and your consent on this device. For third-party apps, the firm data rule is read broadly, write only your own namespace.
Three layers people collapse into one verb
When someone says “run an app,” they usually mean three different machines of thought at once. On LastDB those are separate on purpose.
- Launch. A command can start a process under an OS jail so the child cannot open the node’s private data directory and cannot reach the full-power owner control surface. The jail is a process parent. It is not a package manager, and it does not ask a catalog whether the path is “allowed.”
- Identity. A shared registry answers a narrow question: is this app id a real published name with a publisher, or is it made up? That is lookup-by-known-id, not a scrollable storefront. Local pickup lists for agents and tests are not that registry.
- Consent. On each device, you grant the app permission to act. That is the iOS-style half of the model: you are the authority; the app holds a revocable slip. Granting happens on the owner plane. The restricted app surface is for data work after that, not for negotiating permission.
Once you see the three layers, a lot of product confusion evaporates. Jail without consent is just a confined process that cannot usefully write. Consent without a real app id is meaningless. A registry entry without a running process is only a name.
Two doors into the same database
A LastDB node exposes more than one way to talk to it. For day-to-day work that distinction matters more than packaging formats.
The owner door is for software you build and already trust on your machine — the tools we use ourselves to run memory and boards on our own nodes. Same user, device trust, full read and write. No ceremony. That is the honest path for first-party work.
The app door is for code you would rather not treat as yourself. The node can launch it into a jail that cannot read the on-disk database files and cannot reach the owner control surface. The process gets a restricted data path, an attributed identity, and the write rule below. That is the path we care about when LastDB starts to host apps that did not come from the node owner’s own hands.
Important product honesty: apps do not have to be compiled native binaries to exist. A script under a runtime is still an app. What the jail needs is an executable path. What the data plane needs is attribution you can stand behind. Those are different requirements, and conflating them is how people invent an “only signed .app bundles” story that is not actually the product rule.
The rule that makes multi-app feel safe
On the attributed path, the data rule is simple enough to put on a whiteboard:
- Read broadly. Other apps’ data on your machine can stay visible to an attributed app after you have consented. That is what makes composition possible without shipping every feature into one mega-app.
- Write only your own namespace. The node enforces this at the mutation chokepoint. A notes app can write notes; it cannot quietly rewrite someone else’s board rows. We proved the deny path live: own-namespace write succeeded; cross-namespace write was rejected.
This is attribution and accident prevention more than a fantasy security wall. Same-user software on your laptop can still reach the owner door if you let it. The point is that two honest apps on one node stop stepping on each other’s data by construction — which is what you need once “apps on LastDB” stops being a single prototype and becomes a small ecosystem.
What we had to prove, not assume
Diagrams are cheap. We ran the real loop on an isolated node: jail the process, grant consent as the owner, attribute the process as a real app, write a row through the restricted data path, read it back, confirm the owner can see it, and confirm a write into another namespace fails. We also confirmed the jail cannot open the node’s private data files. That is the standard we want for any claim about how apps run: show the user-visible capability, not only the architecture sketch.
What this is not
- Not a pre-approval list for launch. The jail launcher does not consult “is this binary on the good list?” It starts what you hand it, under confinement.
- Not a public app mall (yet). Identity registry lookup is by known id. A place where people browse and install is product surface on top of this model, not a prerequisite for the model to make sense.
- Not “every script is as trusted as you are.” The owner door is for that. The app door exists so third-party code can be narrower by default.
Why this feels nice
A lot of platforms answer “how do apps run?” with a store, a packaging format, and a permissions dialog that still leaves you unsure what can write where. LastDB’s answer is closer to how people already think about a personal database:
- Your data lives on your machine.
- An app is a namespaced lens over that data.
- You decide which apps get a slip.
- Once they have one, they can read enough to be useful, and write only their own rows.
- If you want stronger process hygiene for someone else’s code, the node can parent the process into a jail that never sees the raw database files.
That is enough to start building apps without inventing an entire mall first. The mall can come later. The invariants should not wait.
If you are building on LastDB today: use the owner door for software you fully trust, claim a namespace for anything that will outlive a prototype, and treat write-own as a product promise you can depend on — not a style guide suggestion.
Built while dogfooding the app path on LastDB itself. See also Declared, Not Registered for how schemas get names without phoning a registrar first, and Apps for the product surface we are growing on top of this model.