Implements PLAN.md Phase 1. A client can now register, log in, manage its devices and set its profile; an operator can create accounts and flip the runtime switches. There are still no rooms and no real /sync. userapi: accounts, argon2id passwords in PHC format, devices, access and refresh tokens stored as SHA-256 hashes, account data and the admin flag. Its storage interface is storage.UserStore, implemented once in sqlstore with `?` placeholders; the postgres driver supplies a rebind function and unique-violation recognition rather than keeping a second copy of thirty statements. Timestamps in these tables are int64 milliseconds, the unit the Client-Server API uses on the wire. Client-Server API: register (user-interactive auth with m.login.dummy and optional registration tokens), register/available, token validity, login with m.login.password, logout, logout/all, refresh, account/whoami, capabilities, devices/* with password-gated deletion, profile/*, global and per-room account data. GET /sync is a deliberate placeholder: it answers a valid token with an empty but well-formed response and refuses a revoked one. Phase 1 has no rooms, so that is the whole truth, and it is what makes session revocation observable. Phase 4 replaces it with the syncapi. Auth middleware resolves a bearer token (header or the legacy query parameter) to a device and user, answering an expired token with the soft logout the spec asks for. Rate limiting is a token bucket per endpoint class keyed on the client address, returning M_LIMIT_EXCEEDED with retry_after_ms. adminapi v1 under /_warp/admin/v1: admin-only auth via a normal Matrix token, GET/PUT /federation and /registration driving internal/settings and reporting a config-pinned switch as a 409, GET/POST /users, GET /stats. warp create-account [--admin] creates the first account straight in the database, so a new install with registration off has a way in. Complement is wired up for the federation=off profile: an image meeting its contract, an entrypoint that configures Warp entirely from WARP_* variables, and a runner that builds, clones and executes the target set (TestRegistration, TestLogin, TestDeviceManagement). It has not been run yet -- there is no container runtime on the development machine -- so the three tests' assertions were read from the Complement sources and pinned as httptest tests instead, and CI gained a job that runs the real thing. Also fixes a .gitignore bug from Phase 0: the unanchored `warp` pattern, meant for the built binary, also matched the directory server/cmd/warp and silently excluded the entire command package from the repository. The binary patterns are now anchored to the repository root, and cmd/warp is committed for the first time. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2.6 KiB
Complement
Complement is the official Matrix integration suite and this project's primary progress metric (PLAN.md section 9). It runs one container per homeserver per test and drives it over the real HTTP API.
make complement # the current target set
bash run.sh TestLogin # one test
COMPLEMENT_DEBUG=1 make complement # with the container logs
Needs Docker. run.sh builds the image, clones Complement into
.complement/ at the repository root (git-ignored) and runs the subset for
the phases that are done.
Files
| Dockerfile | the homeserver image, built from the repository root |
| entrypoint.sh | the deployment, entirely WARP_* environment variables |
| run.sh | build, clone, run |
Profiles
federation=off — what runs today. Only the Client-Server tests;
WARP_FEDERATION_ENABLED=false, port 8448 exposed but unserved.
federation=on — Phase 5. It needs a TLS listener on 8448 with a
certificate signed by the CA that Complement mounts at /complement/ca,
which is the first thing to add here when federation lands.
The test set
COMPLEMENT_TESTS in run.sh lists what is expected to pass. Phase 1:
TestRegistrationTestLoginTestDeviceManagement
Extend it as each phase lands rather than switching to the whole suite: a pass count that drops because a later phase is missing is noise, not information.
Two notes on the environment, both in entrypoint.sh:
- Rate limiting is off. The whole suite comes from the one address the
test runner has, so the limiter would spend the run returning
M_LIMIT_EXCEEDEDand tell us nothing about the server. Synapse's own Complement image does the same. - Registration is on, because the tests create their own users.
Tests that need later phases
Some subtests of the three above reach for endpoints that are not Phase 1
work. TestDeviceManagement calls /sync after creating a session, and
TestLogout checks that a revoked token cannot sync. Phase 1 answers
/sync with an empty but well-formed response for exactly that reason —
there are no rooms yet, so an empty sync is the complete truth, and it makes
token revocation observable. Phase 4 replaces it with the real syncapi.
The shared-secret registration subtests of TestRegistration probe
/_synapse/admin/v1/register and skip themselves when it 404s, which it
does here: that endpoint is Synapse's, and warp create-account covers the
same need.