04··Quinten·4 min read

Who tilo is for

The honest per-audience version of what tilo offers—for people who just want a computer that works, collaborators, teams, self-hosters, free software people, and agents—and where it still falls short.

Different people want different things from a computer, and a project this size only earns attention by being clearly better at something specific. This is the honest per-audience version: what tilo offers, and where it currently falls short for you.

It is early alpha throughout. Everything below is written as the design intends, with the gaps marked.

People who just want a computer that works

Free, automatically updated, and not working against you. No account required to use your own machine, nothing upsells you, and the applications that ship with it are meant to be genuinely usable rather than placeholders.

The image is immutable and rolls back, so an update that breaks something is one reboot away from not having happened.

Not yet: multi-monitor polish, audio routing edge cases, and session lock hardening are still in progress. Do not install it over the only machine you rely on today; try it in your browser at tilo.coffee or in a VM first.

People who work with other people

The shared state is the default state. Two people in the same workspace are in the same documents, with cursors and selections visible, rather than one person narrating a screen share while the other reads out coordinates.

That extends to applications where nobody would have built collaboration deliberately: the ebook reader, the file manager, notes. It is a property of the toolkit rather than a feature somebody funded per application.

Pair programming is the case that motivated a lot of this. It should not require either per-application support or handing somebody unrestricted access to your machine.

Workspaces also let you leave work behind: switch workspace and the colleagues, the permissions and the shared files go with it, while your own music keeps playing.

Not yet: peer-rendered sessions are the weakest link in the sandbox story, and are documented as such in the security post.

Teams and organisations

Per-workspace permissions and membership, with an access log that comes from the action model rather than from an audit bolt-on: every change carries who made it, because that is how the storage works.

Nothing has to pass through somebody else’s SaaS if you don’t want it to. A workspace can be hosted on a machine the organisation owns—or on a dedicated node we run for you on Tilo Cloud—and the interface is identical whether that machine is a laptop on the same desk, a server in a rack, or a cloud node opened in your browser.

Not yet: there is no enterprise administration story beyond the workspace UI, and no automated fleet provisioning at scale.

Self-hosters

A home server is just another tilo machine running workspaces in relay mode. Produce a custom image from a running system, install it on a spare box, and connect to it from any browser via tilo.coffee or from another tilo machine rather than through a separate web admin panel.

The per-application backend choice matters here: rather than one cloud per ecosystem, you decide where each workspace’s state lives. Your notes can sync through your own machine while something else does not sync at all.

Not yet: building custom images for other people is still manual, and standalone relay packaging is being smoothed out.

Free software people

Open standards where they exist: Wayland, portals, freedesktop conventions. Flatpak applications run.

The security model deliberately keeps owner-enrolled keys rather than vendor keys, so building your own images does not cost you the ability to prove what you are running. That is the one property worth copying from GrapheneOS and the one most commonly dropped.

Not yet: third-party application distribution is early, and the public registry is a single implementation rather than an ecosystem.

Gamers

Proton bundled, images with NVIDIA drivers included.

Not yet: honestly, very little of this is tested under load, and the compositor has no VRR or HDR path that has been proven with a game. Treat this section as an intention.

Agents

Worth stating plainly because it is a real consequence of the architecture: the questions an agent raises are the questions collaboration already raised. What was done, and by whom and who is allowed to do what are the same two questions whether the other party is a colleague or a program.

A system that answers them properly for people answers them for agents without a second mechanism. Every action is enumerable, attributable and revocable, so an agent operating an application uses the exact same semantic interface a screen reader uses and a script uses—at the speed of a tool call rather than scraping screenshots—and its edits carry authorship and one-click revert the same way a person’s do.

The corollary matters more: a permission model that only works for humans ends up with a worse, parallel one bolted on when the other case arrives.