Update federation mechanism to utilise an EDU for redaction notifications

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