tajniak81andClaude Opus 5.5
a47e15cc1c
CI / Test (ubuntu-latest) (push) Canceled after 0s
CI / Test (windows-latest) (push) Canceled after 0s
CI / Storage tests on PostgreSQL (push) Canceled after 0s
CI / Complement (federation off) (push) Canceled after 0s
CI / golangci-lint (push) Canceled after 0s
CI / Smoke test the binary (push) Canceled after 0s
CI / Admin panel (push) Canceled after 0s
CI / Web client (push) Canceled after 0s
CI / Desktop client (ubuntu-24.04) (push) Canceled after 0s
CI / Desktop client (windows-latest) (push) Canceled after 0s
The pocketbase driver no longer embeds PocketBase: Warp keeps its data as PocketBase collections on a server of its own and reaches it only through the REST API, the way the postgres driver reaches PostgreSQL. database.connection_string is the server's URL, and Warp signs in as the superuser in WARP_PB_SUPERUSER_EMAIL / WARP_PB_SUPERUSER_PASSWORD (or a WARP_PB_SUPERUSER_FILE of the two). Every SQL table is a superuser-only collection of the same name and columns, created by warp migrate. Reads go through PocketBase's SQL endpoint with the SQL drivers' queries, via a read-only database/sql driver that inlines arguments, moves long ones into warp_params and pages past 1000 rows. Writes are record operations in batch requests under one write lock in the Warp process. Media is a protected file field in warp_media, local or in the S3 bucket Warp writes into PocketBase's settings. Search matches word prefixes with LIKE. The storage tests run against an in-process PocketBase and pass as on SQLite. Docker: the PocketBase stacks get a pocketbase service running tajniak81/pocketbase-docker-root (WARP_PB_IMAGE), with a pb-data volume and its admin UI on loopback; the AIO images run that PocketBase binary as a process beside the homeserver, making up a superuser when none is set. The .env examples, READMEs, docs and warp.yaml.example follow. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Documentation
| Document | What |
|---|---|
| configuration.md | every setting, and its environment variable |
| development.md | building, testing, Complement, adding a migration |
| event-core.md | internal/matrix: canonical JSON, events, auth rules, state resolution |
| rooms.md | internal/roomserver: the input pipeline, room storage, known gaps |
| sync.md | internal/syncapi: stream tokens, long polling, filters, the ephemeral streams, Simplified Sliding Sync |
| relations.md | threads, edits, reactions and references: /relations, /threads and unsigned.m.relations |
| spaces.md | /hierarchy across servers, and room_summary |
| search.md | /search on FTS5 and tsvector |
| federation.md | the Server-Server API: discovery, keys, taking in events, joins across servers, the outbound queue, the switch |
| media.md | internal/mediaapi: uploads, downloads, thumbnails, other servers' media, where the files go |
| e2ee.md | internal/keyserver: device and one-time keys, cross-signing, device list tracking, key backup |
| calls.md | voice and video calls with MatrixRTC and LiveKit: ringing, delayed events, OpenID, the JWT service, deploying it |
| push.md | internal/pushrules and internal/pushserver: push rules, notification counts, pushers, the push gateway client |
| appservices.md | internal/appservice: registration files, namespaces, acting as users, delivering events to bridges |
| admin-api.md | /_warp/admin/v1: the operator API behind the admin panel |
| deployment.md | storage drivers, the image, Compose, Helm, metrics and the dashboard, tracing, load testing |
The design and roadmap are in PLAN.md at the repository root.