4 Commits

Include renames

Author	SHA1	Message	Date
tajniak81andClaude Opus 5.5	a94794b866	Phase 9: application services and admin completion ... Implements PLAN.md Phase 9. internal/appservice reads registration files (appservice.config_files), matches namespaces the way Synapse does (anchored at the start), and delivers events to each service as transactions read from the roomserver's event stream at a cursor kept in appservice_state. A transaction in flight is recorded, so after a restart it is resent under the same ID; failures back off from 2s to 5m, and a successful ping cuts the backoff short. In the Client-Server API an as_token acts as the service's sender or, with ?user_id=, as any existing user in its namespace. Services register and log in their users with m.login.application_service; exclusive user and alias namespaces are refused to everybody else with M_EXCLUSIVE. Unknown aliases and users in a namespace are asked of the service first. The ping endpoint reports M_URL_NOT_SET, M_BAD_STATUS, M_CONNECTION_FAILED and M_CONNECTION_TIMEOUT. Services' own requests, and their users' when rate_limited is false, skip the rate limiter. Users can change their password (POST /account/password) and deactivate their account (POST /account/deactivate), both behind the password. Deactivation revokes tokens, deletes devices, optionally erases the profile and leaves every room through a new userapi.AccountObserver. The admin API is complete: user detail, the admin flag, deactivation and reactivation, password resets, devices, media quotas (media.max_user_storage_bytes plus per-user overrides), registration tokens with use limits and expiry (registration.require_token), server notices (internal/servernotices, server_notices.*), an editor for the federation allow/deny lists persisted in server_settings, a delivery view of the application services, and an audit log of every change. Migration 0011 adds the registration token, server notice room, media quota, audit log and appservice cursor tables. Policy lists are now returned sorted. The Complement entrypoint loads the registrations Complement mounts in /complement/appservice. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-17 12:58:28 +02:00
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
tajniak81andClaude Opus 5.5	fc49f56339	Phase 7: E2EE support ... Implements PLAN.md Phase 7: the server half of end-to-end encryption. Devices upload identity, one-time and fallback keys; other devices query and claim them, across servers too, and every one-time key is handed out exactly once. Cross-signing, signature uploads, device list tracking and server-side key backup complete the set. internal/keyserver is the component. Keys are stored in canonical JSON so that re-uploading the same key is a byte comparison, and signatures uploaded later are kept apart from the key they sign and merged in on read, so a key's own JSON stays what its owner uploaded. Device keys must be for the caller's own device; cross-signing keys must be the uploader's, carry the right usage and, for self- and user-signing keys, be signed by the master key. Signatures are verified against the key as stored. Replacing a master key asks for the password; a first upload or an upload of the keys already stored does not, as the spec allows. A signature of another user's master key is shown only to the user who made it and never federated. Every write that changes what /keys/query answers moves the device list stream in the same transaction, one position per device, and wakes the syncs of everyone sharing a room. The stream is the sixth field of a sync token; older tokens still parse. The syncapi works out device_lists changed and left from the stream and from membership moves in the window, skipping invites and knocks, and reports device_one_time_keys_count and device_unused_fallback_key_types, the latter as [] when empty. GET /keys/changes uses the same logic. Over federation: /user/keys/query, /user/keys/claim and /user/devices/{userId}, and m.device_list_update and m.signing_key_update both ways. Remote keys are not cached; an update about a remote user sharing a room moves them in the stream so local clients re-query. Device display names are not sent to other servers. With federation off, remote users are reported in failures at once. Deleting a device deletes its keys, through a new userapi DeviceObserver. Key backup keeps the better copy of each session by the spec's rule, never reuses a deleted version's number, and answers writes to a stale version with M_WRONG_ROOM_KEYS_VERSION. Storage is migration 0008 for sqlite and postgres, with a PocketBase stub. The Complement target sets gain the key, device list, fallback, cross-signing and backup tests. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-17 10:34:08 +02:00
tajniak81andClaude Opus 5	6004bb01de	Phase 1: accounts and sessions ... 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>	2026-10-15 18:18:37 +02:00