From 286778bbd7498ee734b06533dbb662fd4f15ce42 Mon Sep 17 00:00:00 2001 From: timedout Date: Mon, 26 Jan 2026 18:34:22 +0000 Subject: [PATCH] Update federation mechanism to utilise an EDU for redaction notifications --- proposals/4322-simple-media-self-redaction.md | 41 ++++++++++--------- 1 file changed, 21 insertions(+), 20 deletions(-) diff --git a/proposals/4322-simple-media-self-redaction.md b/proposals/4322-simple-media-self-redaction.md index abfe33364..0450c8306 100644 --- a/proposals/4322-simple-media-self-redaction.md +++ b/proposals/4322-simple-media-self-redaction.md @@ -51,28 +51,29 @@ permitted to redact it. ### Server-to-server changes -A new authenticated federation endpoint, -`POST /_matrix/federation/v1/media/redact/{server_name}/{media_id}`, is created in order to allow a -server to notify other servers that a piece of media has been redacted. - -The same rules apply as client-to-server (e.g. a server may retain the media), -however, the receiving server **must** ensure that the calling server is the same server -that the media URI belongs to. -For example, if `server1.example` sends a request to -`server2.example/.../redact/server3.example/abcd`, this is not permitted and must return a forbidden -error. - -If the media on the remote server does not exist, it must take a note of the given media URI and -mark it as redacted, consequently preventing it from being acquired in the future. - -In order to know which servers to federate a redaction to, the server should take a log of which +In order to know which servers to federate a redaction to, the server may wish to take a log of which servers download media (typically done by recording the origin of the [`GET /_matrix/federation/v1/media/download/{media_id}`][spec_s2s_download] endpoint). -When a redaction is made, the server may then accordingly send a federation request to each of -the servers that has previously downloaded the media ID, notifying them that the media has been -redacted and must no longer be served. This is a suggested method, a server can choose to record -a list of targets in any way it likes, however it is not recommended to associate media with events -or remote users until [MSC3911 (Linking media to events)][3911] makes that connection explicit. + +When a media redaction is performed, the server should send an EDU to every remote that downloaded +the media. For this, the new EDU type `m.media_redaction` is created, shaped as follows: + +```json +{ + "type": "m.media_redaction", + "media_id": "opaque_identifier" +} +``` + +Upon receiving this EDU, servers MUST remove the media from the data store, refusing to serve it +to clients in succeeding requests. Servers SHOULD make a note of which media IDs are redacted +in order to prevent lookups for known redacted media, however this is not required, as the origin +should serve `404 / M_NOT_FOUND` on the media afterwards anyway. + +> [!TIP] +> Media IDs are only unique per origin, so ensure your file lookup is scoped correctly. +> For example, if a transaction came from `server.example`, with the `media_id` of +> `foobar`, that could be turned into `mxc://server.example/foobar`. ## Potential issues