- Rust 89.4%
- Python 5.1%
- Shell 1.8%
- JavaScript 1.5%
- Fluent 1.1%
- Other 0.9%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
qwolff
3db39b61e7
Records written before a page's writes waited for their record can hold a write built on a change its writer let go unsent. The relay's fold could not apply it and kept it beside its snapshot, so every newcomer was sent it and refused the record as incomplete. The snapshot also carried the stuck change itself, waiting. The governor, which every write of a record reaches, now names the writes of its history stuck behind a change their writer never sent. A keyed fold that finds writes it cannot apply asks it, and folds again without those: they leave the record for good, are kept in the store's archive as their writer sealed and signed them, and are logged with workspace, record, writer and sequence. The fold's snapshot holds only what applied, and a fold whose writes do not load as one batch (a change under a sequence another change holds) takes each write on its own and keeps a refused one as it is, rather than never folding the channel again. The governor's own compaction of such a record compacts it into what reads, rather than failing until its history fills, and its whole-record read counts it whole. A store kept from an earlier run is repaired as the relay starts: every sealed record whose governor finds such writes is folded without them then, not at whatever write next brings its fold. Nothing changes on the wire or on disk: the fold is the sealed compaction it already wrote, now covering the stuck writes too. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
||
| .cargo | ||
| .codex | ||
| .config | ||
| .cursor | ||
| .forgejo | ||
| .githooks | ||
| .github | ||
| apps | ||
| crates | ||
| dist | ||
| docs | ||
| examples | ||
| fuzz | ||
| keys | ||
| os | ||
| scripts | ||
| sdk | ||
| shots | ||
| tools | ||
| vendor | ||
| .containerignore | ||
| .gitattributes | ||
| .gitignore | ||
| AGENTS.md | ||
| Cargo.lock | ||
| Cargo.toml | ||
| clippy.toml | ||
| CONTRIBUTING.md | ||
| deny.toml | ||
| flake.lock | ||
| flake.nix | ||
| LICENSE | ||
| LICENSE-MIT | ||
| LICENSING.md | ||
| README.md | ||
| rust-toolchain.toml | ||
| SECURITY.md | ||
| t.toml | ||
Website · Contribute · Build an app · Source & issues
Tilo is a Linux desktop built around collaboration and around working across your own devices. You share a workspace with someone and work together in every Tilo app, with full history, undo, search and sync between devices and people. You can add AI agents too, with their own permissions and history.
We build the desktop, the apps and the system underneath them together. Tilo is early alpha: expect things to break, and don't trust it with your only copy of important data.
How it works
- Workspaces are the unit of collaboration. Each has its own members, roles, apps, layout and data, and is on every device of every member.
- People and devices are separate. A member is an identity; each of their devices has its own key. Devices sync directly over iroh, end to end encrypted with MLS. A server is just a device that stores more.
- All shared state is CRDT. Edits from several people and devices merge.
- Apps are resources, actions and views. An app declares its typed state and the actions that change it; collaboration, history and undo, permissions, sync and search come from that. Scripts, assistive technology and agents use the same actions as the buttons.
- The shell is built like an app. Launcher, top bar and settings run on the same toolkit and model as every other app. Windows sit in horizontally scrolling strips; tabs can group different apps.
The architecture overview explains the model
and where it lives in the code; workspace.md
is the full specification. The apps directory lists the apps.
Try it
There is no public release download yet. Getting started covers virtual machines, adding the desktop to an existing Linux system and installing the OS. From a checkout, one command runs it:
cargo desktop # the desktop in a window on your desktop
cargo headless # the session with no window, for agents and tests
cargo web # the web desktop on the local hosting stack
CONTRIBUTING.md says what each needs and does.
Help build it
You don't need to understand the whole system to help, or even to program: bug reports, small fixes, accessibility testing, translations, documentation and design feedback all count. CONTRIBUTING.md takes you from a checkout to a pull request; Build an app covers the app SDK.
Our home is code.tilo.so/tilo/tilo. GitHub is a mirror; please send issues and pull requests to Forgejo. People and coding agents are both welcome; if you use an agent, understand the change you submit and say what you tested. AGENTS.md is for the agent.
License and security
Tilo is open source: everything you need to publish an app is MIT, the rest is AGPL 3.0. See LICENSING.md.
Please report vulnerabilities privately as described in SECURITY.md, not in a public issue.