Implements PLAN.md Phase 5: the Server-Server API. Warp joins rooms on other servers and lets their users join its rooms, invites across servers with the invitee's server countersigning, rejects remote invites (locally if the inviter is unreachable), and exchanges events, typing, receipts and to-device messages with other homeservers — all behind the runtime switch, which now starts and stops real outbound traffic. The protocol lives in internal/federation with no knowledge of rooms: X-Matrix signing (fuzzed parser), the spec's discovery algorithm keeping the dial address and the TLS name apart, a signed client that refuses every request while the switch is off or the policy denies the destination, and a key ring that caches other servers' keys for at most a week, with optional notaries. The roomserver takes events from elsewhere through the spec's intake: signatures and hashes (a hash mismatch keeps the redacted form), the rules against the event's own auth events, against the state before it — with /get_missing_events for small gaps and /state_ids for wide ones — and against the current state, where a failure is a soft failure. Events held without their state are outliers: a column on roomserver_events, because the current state of a room joined over federation is almost all outliers, and excluded from every timeline query. Forks are resolved at the room's head. Membership across servers is make_join/send_join, make_leave/send_leave and countersigned invites, in both directions; m.room.server_acl is enforced on everything another server sends. History before a remote join is backfilled when /messages pages past it, stored at negative stream positions. internal/federationapi is the running component: the inbound endpoints, and an outbound queue that persists what it owes each destination, sends it in transactions of 50 PDUs and 100 EDUs, backs off from ten seconds to six hours, survives restarts, and drops events persisted while federation is off rather than delivering a backlog in one burst. Its Module is what the switch starts and stops. Also: a TLS listener for port 8448, trusted key servers, key validity and an outbound CA bundle in the config; per-destination health and backoff reset in the admin API; remote profiles, aliases and directories in the Client-Server API; a Complement federation profile. See docs/federation.md, including its known gaps (no partial-state joins, no key rotation). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
3.4 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 C-S set, federation off
make complement-federation # the federation 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
COMPLEMENT_PROFILE picks one; each has its own test set in run.sh.
csapi (the default, make complement) — the Client-Server tests in
tests/csapi, with WARP_FEDERATION_ENABLED=false. Port 8448 is still
served over TLS, because the CA is mounted either way, but the gate answers
every federation request with M_UNRECOGNIZED.
federation (make complement-federation) — the federation tests in
tests/ and the multi-server tests in tests/csapi, with federation on.
The entrypoint has Complement's CA at /complement/ca sign a certificate
for the server's name, serves the API on 8448 with it, and points
federation.tls_ca_file at the same CA, so that Warp trusts the other
homeservers of the run and the servers Complement itself pretends to be.
The switch reaches the container through COMPLEMENT_SHARE_ENV_PREFIX:
run.sh sets PASS_WARP_FEDERATION_ENABLED, which Complement passes on
as WARP_FEDERATION_ENABLED.
The federation set leaves out partial-state joins (MSC3706,
TestPartialStateJoin*), which Warp does not implement, and anything that
needs application services (Phase 9) or device lists (Phase 7).
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.