4 Commits

Include renames

Author	SHA1	Message	Date
tajniak81andClaude Opus 5.5	74f7bc8805	keyserver: cache remote users' device and cross-signing keys ... POST /keys/query for a remote user who shares a room with a local user is now answered from a cache, fetched whole with GET /user/devices/{userId} on a miss. Incoming m.device_list_update EDUs are applied when their prev_id matches the cached stream_id; anything else marks the copy stale and it is fetched again in the background, and a stale copy is never served. m.signing_key_update replaces the cached cross-signing keys. A user's copy is dropped once no local user shares a room with them, by a keyserver listener on the roomserver's emit stage. Migration 0009 adds keyserver_remote_users, keyserver_remote_device_keys and keyserver_remote_cross_signing_keys for sqlite and postgres. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-17 10:36:08 +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.5	92836f8dcd	Phase 6: media ... Implements PLAN.md Phase 6: the media repository. Clients upload files, reserve an mxc:// URI and upload to it later, download and ask for thumbnails, all through the authenticated media endpoints of Matrix 1.11; other servers download this server's media through the federation media endpoints, and media uploaded elsewhere is fetched over federation on first use and kept. internal/mediaapi is the component. Content goes into a BlobStore named by its SHA-256, so the same file uploaded twice is stored once and the hash doubles as the ETag; the metadata that maps an mxc:// URI onto a blob is in media_repository and media_thumbnails. The local-filesystem store writes to a temporary file and renames it into place once hashed, so nothing ever refers to half a file. A storage driver can bring its own store through storage.BlobProvider, which is where PocketBase's filesystem abstraction (local or S3) plugs in with Phase 10. Reserved uploads belong to the user who made them, take one upload, lapse after a day, and are capped per user; a download of one waits for its content, woken in memory the moment it arrives, for as long as timeout_ms allows. Thumbnails come from a fixed set of configured sizes, so a thousand requested sizes cannot mean a thousand resizes. They are made on first request and kept, never enlarge, honour a JPEG's EXIF orientation, and point at the original when it already fits. The pixel count is checked from the header before anything is decoded, at most four resizes run at once, and concurrent requests for the same thumbnail share one. Remote media is fetched through the signed client: the multipart/mixed answer of Matrix 1.11, with a fallback to the legacy download endpoint for servers that answer M_UNRECOGNIZED, and Location redirects followed by a dialer that refuses loopback, private and link-local addresses. Concurrent requests share one fetch, detached from the request that started it. With federation off nothing is fetched, and what was cached before is still served. Downloads carry a sandboxing CSP, nosniff, inline Content-Disposition only for the types the spec lists as safe, and private immutable caching. The unauthenticated legacy download endpoints are off by default behind media.legacy_unauthenticated_downloads. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-16 21:26:49 +02:00
tajniak81andClaude Opus 5.5	6aaf554336	Phase 5: federation ... 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>	2026-10-16 17:14:20 +02:00