Thumper-Run is a three-tier Rust application: a Leptos frontend compiled to WASM, a Tauri IPC layer, and backend services.

┌─────────────────────────┐
│  Leptos Frontend (WASM) │  tr-shared-ui
│  Components + Hooks     │  invoke_tauri(cmd, args)
├─────────────────────────┤
│  Tauri IPC Layer        │  tr-tauri-shell
│  #[tauri::command]      │  → ApiResponse<T>
├─────────────────────────┤
│  Backend Services       │  tr-services
│  Launcher, Models, Sync │  lt-crdt-core
└─────────────────────────┘

IPC Command Categories

IPC Pattern

// Backend: define a command
#[tauri::command]
async fn app_launch(id: String) -> ApiResponse<AppStatus> { ... }
 
// Frontend: call it from Leptos
let result = invoke_tauri("app_launch", &json!({"id": "comfyui"})).await;

60+ IPC commands across 35 modules.

Thumper-Run uses CRDTs (conflict-free replicated data types) for offline-first sync. Data lives on your device first and merges automatically when devices connect.

Cargo Features

• crdt-mode1 through crdt-mode5 — enable each security mode
• crdt-sqlite / crdt-localstorage — persistence backends
• crdt-websocket / crdt-http — sync transports
• keyhive-authz + beekem — E2EE implementation features; release claims remain gated

Full protocol docs in crates/lt-crdt-core/README.md.

Thumper-Run is designed offline-first. Every feature works without an internet connection. When you go online, queued changes merge automatically.

How It Works

1. All data is local — CRDT documents live on your device. The server is a sync relay, not the source of truth.
2. Mutations are queued — when offline, writes go to an IndexedDB-backed queue. Each queued action includes the CRDT path, value, and timestamp.
3. Auto-merge on reconnect — when connectivity returns, queued CRDT operations are replayed. Because CRDTs are conflict-free, there's no manual conflict resolution.

What Works Offline

• Launching and using installed apps (all local)
• Managing models (if already downloaded)
• Using the AI assistant (with local LLM engine)
• Browsing the image gallery
• Writing reviews (queued for sync)
• Editing settings (synced when online)

What Requires Internet

• Installing new apps (needs to clone repos)
• Downloading models (needs to fetch weights)
• Cloud compute (needs GPU instance)
• OIDC login (needs Rauthy server)
• Cloud API LLM engines (OpenAI, Anthropic)

Sync Indicator

The status bar shows your current sync state:

• Green — WebSocket connected, real-time sync active
• Blue (pulsing) — HTTP polling mode, periodic sync
• Yellow (pulsing) — offline, changes queued

Click the indicator to see detailed sync status: connection state, pending queue depth, and E2EE epoch (when encryption is active).

Thumper-Run uses encrypted transport for supported connections and layered authentication and authorization. It is not currently a zero-knowledge service, and private E2EE remains a gated design rather than a release guarantee.

Authentication

Three authentication methods, all optional:

Identity Phases (Progressive Identity)

Users can start anonymous and gradually upgrade their security level without losing data:

Identity upgrades support additional recovery and device controls. They do not by themselves establish private E2EE; shipping-client custody and protocol gates must also pass.

Authorization: Biscuit Tokens

Thumper-Run uses Biscuit tokens for authorization — a Datalog-based capability token system with public-key cryptography.

• Tiny — 258–600 bytes (vs 1–3 KB for JWT)
• Offline attenuation — restrict a token's capabilities without contacting the server (e.g., delegate read-only access to a subset of documents)
• Datalog policies — express complex authorization rules like "allow write if user is owner and document is not archived"
• Public-key verification — any service with the public key can verify, no shared secret needed

When a user logs in, the server mints a Biscuit token containing their principal identity and granted capabilities. The token is stored in an HttpOnly session cookie (XSS-proof) and sent with WebSocket sync connections.

Path-Based Access Control

CRDT documents use JSONPath-based ACLs to control who can read or write specific paths:

// Grant alice read+write on documents
acl.grant_jsonpath(
    "$.documents",
    Some(&PrincipalId::Email("alice@example.com")),
    UnifiedAction::READ | UnifiedAction::WRITE,
    None  // No expiration
);
 
// Grant everyone read on public data
acl.grant_jsonpath(
    "$.public[*]",
    None,  // Wildcard = everyone
    UnifiedAction::READ,
    None
);

Session Security

• HttpOnly cookies — reduce direct JavaScript access to session tokens
• SameSite=Lax — limits cross-site cookie sending as one CSRF defense
• PKCE (S256) — OAuth code exchange protected against interception
• CSRF state parameter — validates callback wasn't forged
• Automatic token refresh — frontend refreshes tokens 10 minutes before expiry

Trust Boundaries

• Device — may hold Ed25519 identity material in platform storage where supported; custody varies by workflow and build.
• Server — handles account, authorization, sync, and deployment state needed for current server-assisted workflows.
• Network — supported connections use TLS for encrypted transport. This does not imply private E2EE.

Encryption Per Sync Mode

Forward Secrecy

In Mode 5 (BeeKEM), member changes create new epochs with fresh symmetric keys. The protocol is designed so new members cannot read past epochs and removed members cannot read future epochs once signer, import, and roster enforcement are complete. The BeeKEM tree is stored as a CRDT document itself, so epoch transitions can converge across devices.

Planned Private E2EE Boundary

A future private E2EE path would keep document-decryption authority with authorized endpoints. Current server-assisted admission and sync paths do not provide that release guarantee. The design separates:

• Encrypted CRDT operations (opaque binary blobs)
• Biscuit root key (for token minting, not content decryption)
• Managed identity records (Rauthy subject ID, identity phase, encrypted seed)
• BeeKEM tree structure (public keys only, no private keys)

These are design responsibilities, not current breach-impact guarantees. Release claims remain blocked until shipping-client custody, rotation, persistence, and independent security evidence pass.

Spin up cloud GPU instances from the same interface you use locally. Your apps, models, and data stay encrypted — the cloud VM is just extra GPU power.

How It Works

1. Choose a GPU — RTX 4090, A6000, H100, or custom
2. Select a deployment mode — Inference (run an app), Fine-Tuning (train LoRAs), or Custom
3. Review cost estimate — per-hour pricing based on GPU and region
4. Launch — instance spins up, models transfer, app starts
5. Use — same UI, same data, just faster GPUs
6. Stop — billing stops immediately, outputs download to your device

API Endpoints

The protected cloud API validates the authenticated account, launch context, billing authority, and server capabilities. See the API Reference for endpoint details.

Run Thumper-Run as a web service for your team or community. The web shell provides catalog browsing, model discovery, blog, and CRDT sync with SSR.

Stack: Leptos SSR + Axum, PostgreSQL, Redis, Nginx (reverse proxy + SSL), Rauthy (OIDC).

Quick Start

git clone https://github.com/thumper-ai/thumper-run
cp .env.production.example .env.production
# Edit .env.production with your secrets
docker compose -f docker/docker-compose.prod.yml up -d

Required Environment Variables

What's Included

Public catalog, model browsing, blog, supported server-assisted CRDT sync, and device pairing.

Coming Soon