How the pieces fit
Four layers, one node. The CRDT layer carries live, mergeable state between devices. Repositories turn that state into durable, signed history and hold the large files. The HTTP API is how every client talks to a node. Publishing is a catalog listing that points at a repository and, once signed publication files exist, makes the app installable from the desktop.
| Layer | What it holds | How it works | Surface |
|---|---|---|---|
| CRDT sync (lt-crdt-core) | Live, mergeable state: documents, workspace file index, catalog overlay, capability grants | Mode 1 plain (local only), Mode 2 content + authorization (server-readable), Mode 5 end-to-end encrypted (server routes opaque updates) | /crdt/ws, device pairing |
| Repositories (lt-repo, lt-blobstore) | Durable history: seals (signed commits), refs, text lanes for source, chunked bytes for weights | Live frontier is CRDT state; a seal freezes it into content-addressed history in Postgres and the object store | /api/v1/repos |
| HTTP API (tr-web-shell) | Everything a client or script does: catalog, repositories, reviews, social, mirrors, publishing, billing | Session Biscuit or a scoped token; every mutation is request-bound; routes behind flags answer 404 | /api/v1/*, /api/v1/client-config |
| App publishing | A listing (catalog row) pointing at a repository, with signed publication files for installs | Listing metadata is Postgres; files are seals + object store; the desktop verifies tier attestations | Settings › Listing, Releases |
| Desktop app | Runs apps on your hardware, syncs folders, seals and publishes | Talks to a node over the same API and sync socket; falls back to local-only Mode 1 | thumper:// hand-off |
Where each kind of data lives
Plaintext, authorised, or end-to-end encrypted
The sync layer has three modes. Mode 1 keeps a document on one device with no server. Mode 2 syncs through a node that can read the content and enforces capability grants (the catalog overlay, public repositories, reviews). Mode 5 syncs through a node that only ever sees authenticated ciphertext: private E2EE repositories and projects, where the field keys live on your devices and the recovery envelope is yours.
Postgres and the object store
Listings, users, handles, refs, seal metadata, reviews, stars, mirror links and moderation state are Postgres rows. Seal bodies and file chunks go to the object store (S3-compatible). The CRDT oplog is persisted by the node and snapshotted; a seal is the only thing that turns it into a fixed, signed object.
The node is one process
One web process serves the site, the API and the sync socket. Authority operations (minting session tokens, franking, account verifiers, the Mode-5 root broker) run in isolated sidecars reached over Unix sockets and never share a database with the web process; the root broker keeps its state on local disk only.
Open-source node vs business vs managed
The community edition is the open-source node: everything needed to run repositories, the catalog, publishing, sync and end-to-end encryption, with baseline sign-in. It does not include content screening, trust-and-safety tooling, franking, advisories or the audit anchor: uploads and repositories on a community node are unscreened and the operator is responsible for what the node hosts. The managed edition at app.thumper.run adds billing, the managed cloud wallet and the desktop update channel.
| Feature | Community (open source) | Business (self-hosted) | Managed (thumper.ai) |
|---|---|---|---|
| Sign-in: OIDC via Rauthy, passkeys, browser signing key, Biscuit sessions | yes | yes | yes |
| End-to-end encryption: Mode-5 fleet, private E2EE repositories and projects, recovery | yes | yes | yes |
| Catalog: listings, curated mirrors, upstream poller, screenshots | yes (unscreened) | yes | yes |
| Repositories: app/lib/model/modelpack/dataset, issues, releases, checks, paths, access, webhooks, time machine | yes (unscreened) | yes | yes |
| Publishing: namespaces, user-held signing keys, package versions | yes | yes | yes (T2/T3 attestation) |
| Sync: CRDT relay, device pairing, plaintext and E2EE projects | yes | yes | yes |
| Federation: relay-to-relay sync | yes (off by default) | yes | yes |
| Agent: web agent with your own keys, in-browser model | yes | yes | yes |
| Cloud runs on Akash with your own wallet | yes | yes | yes |
| Content screening: image moderation, ClamAV upload scan, licence/content enforcement | — | yes | yes |
| Trust and safety: moderation queue, DMCA, enforcement ledger, killswitch, account standing | — | yes | yes |
| Repository hardening: franking (signed evidence), security advisories, WORM audit anchor | — | yes | yes |
| Managed cloud wallet, plans, credits, Stripe, seller payouts | — | — | yes |
| Managed desktop update channel, observability bundle | optional | optional | yes |
Choosing an edition
Run the community node when the people using it are your own team and you accept that nothing is screened. Choose the business edition when strangers can upload and you need moderation, advisories and signed evidence. Use the managed node when you want none of the operations, or when you sell apps and need billing and payouts.
The edition a node runs is reported at /version and in /api/v1/client-config; the desktop app adapts its menus to it.