warp/Warp

0 Fork 0

Files

T

tajniak81andClaude Opus 5.5 b507753172 Phase 8: push and notifications

Implements PLAN.md Phase 8. internal/pushrules is the rule language: the
spec's default ruleset, all six condition kinds, glob and word-boundary
matching, intentional mentions switching off the legacy body rules, and
rule ordering as Synapse has it. internal/pushserver keeps the rules,
pushers and notifications and talks to push gateways.

Push rules are the m.push_rules account data, written only by the push
server; reads keep the user's own rules and the enabled/actions of each
default and take the rest from the current defaults, so new default rules
reach every user without a migration. PUT account_data/m.push_rules is
refused with 405.

The push server listens on the roomserver's emit stage and evaluates each
event on its own worker for every local member and an invite's target.
Notifications and per-room unread counts are stored in migration 0010;
counts are a seventh sync token stream, so /sync reports
unread_notifications and picks up count changes made after the event or by
a receipt from another device. m.read and m.read.private receipts clear
the counts; leaving a room clears it.

Pushers (http kind only) push through a bounded sender pool with retries,
honour event_id_only, drop push keys the gateway rejects, and go away with
their device. GET /notifications pages the history. New config section
push: enabled, include_content, gateway_timeout, notification_retention.

Account data writes now wake the user's blocked syncs.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-10-17 11:43:36 +02:00

Dockerfile

Phase 5: federation

2026-10-16 17:14:20 +02:00

entrypoint.sh

Phase 6: media

2026-10-16 21:26:49 +02:00

README.md

Phase 7: E2EE support

2026-10-17 10:34:08 +02:00

run.sh

Phase 8: push and notifications

2026-10-17 11:43:36 +02:00

README.md

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).

The test set

COMPLEMENT_TESTS in run.sh lists what is expected to pass. Phase 1:

TestRegistration
TestLogin
TestDeviceManagement

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_EXCEEDED and 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.