Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

MSC3911: Linking media to events #3911

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
+281 −0
Open

MSC3911: Linking media to events #3911

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
b1da78c
MSC3911: Linking media to events
richvdh Oct 16, 2022
58e6150
minor edits
richvdh Oct 16, 2022
cc853ef
Move parts of this out to MSC3916
richvdh Oct 23, 2022
4a10395
add some clarifications
richvdh Oct 23, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
minor edits
  • Loading branch information
@richvdh
richvdh committed Oct 16, 2022
commit 58e61507603ae6c53253c7e346b2a00ab446fee3
25 changes: 15 additions & 10 deletions proposals/3911-linking-media-to-events.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -39,12 +39,12 @@ to a user if the user can see the corresponding event.
2. Attaching media
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the proposal is called "Linking media to events" and "linking" terminology is used outside of this list item. is this intentional? can we agree on a single term otherwise? "attaching" seems better suited.


* The methods for sending events
([`PUT /_matrix/client/v3/rooms/{roomId}/state/{eventType}/{stateKey}`](PUT /_matrix/client/v3/rooms/{roomId}/state/{eventType}/{stateKey})
and [`PUT /_matrix/client/v3/rooms/{roomId}/state/{eventType}/{stateKey}`](https://spec.matrix.org/v1.4/client-server-api/#put_matrixclientv3roomsroomidsendeventtypetxnid)
([`PUT /_matrix/client/v3/rooms/{roomId}/state/{eventType}/{stateKey}`](https://spec.matrix.org/v1.4/client-server-api/#put_matrixclientv3roomsroomidstateeventtypestatekey)
and [`PUT /_matrix/client/v3/rooms/{roomId}/state/{eventType}/{stateKey}`](https://spec.matrix.org/v1.4/client-server-api/#put_matrixclientv3roomsroomidsendeventtypetxnid))
richvdh marked this conversation as resolved.
Show resolved Hide resolved
are extended to take a query parameter `attach_media`, whose value must be a complete `mxc:` URI.

The `attach_media` parameter may be used several times to attach several
pieces of media to the same event. The maximium number of pieces of media
pieces of media to the same event. The maximum number of pieces of media
that can be attached to a single event is implementation-defined by servers.

If any of the `attach_media` parameters do not correspond to known
Expand All @@ -62,7 +62,7 @@ to a user if the user can see the corresponding event.
(with the original event ID) even though the media has already been attached.

* Alternatively, if a restricted media item is referenced in a call to
[`PUT /_matrix/client/v3/profile/{userId}/avatar_url`](PUT /_matrix/client/v3/profile/{userId}/avatar_url),
[`PUT /_matrix/client/v3/profile/{userId}/avatar_url`](https://spec.matrix.org/v1.4/client-server-api/#put_matrixclientv3profileuseridavatar_url)
it is instead attached to the user's profile.

Again, if the media is already attached, the server responds with a 400 error with
Expand All @@ -83,8 +83,8 @@ to a user if the user can see the corresponding event.
| [`GET /_matrix/media/v3/download/{serverName}/{mediaId}/{fileName}`](https://spec.matrix.org/v1.4/client-server-api/#get_matrixmediav3downloadservernamemediaid) | `GET /_matrix/client/v1/media/download/{serverName}/{mediaId}/{fileName}` | N/A |
| [`GET /_matrix/media/v3/thumbnail/{serverName}/{mediaId}`](https://spec.matrix.org/v1.4/client-server-api/#get_matrixmediav3thumbnailservernamemediaid) | `GET /_matrix/client/v1/media/thumbnail/{serverName}/{mediaId}` | `GET /_matrix/federation/v1/media/thumbnail/{serverName}/{mediaId}` |

[Question: should we move `/config`, and `/preview_url` while
we're at it, per [MSC1902](https://github.com/matrix-org/matrix-spec-proposals/pull/1902)?]
[TODO: we should probably move `/config`, and `/preview_url` while
we're at it]

None of the new endpoints take an `allow_remote` query parameter. (For
`/_matrix/client`, servers should always attempt to request remote
Expand All @@ -104,7 +104,7 @@ to a user if the user can see the corresponding event.
the corresponding original endpoints.

* For the new `/_matrix/federation` endpoints, the response is
[`multipart/mixed`]https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html)
[`multipart/mixed`](https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html)
content with two parts: the first must be a JSON object
(and should have a `Content-type: application/json` header), and the second
is the media item as per the original endpoints. The json object may have
Expand Down Expand Up @@ -291,9 +291,6 @@ media without attaching it to anything.

## Alternatives

* Use some sort of "content token" for each piece of media, and require clients to
provide it, per [MSC3910](https://github.com/matrix-org/matrix-spec-proposals/pull/3910).

* Allow clients to upload media which does not require authentication (for
example via a `public=true` query parameter). This might be particularly
useful for IRC/XMPP bridges, which could upload any media they encounter to
Expand All @@ -309,6 +306,14 @@ media without attaching it to anything.
this gives, beyond the fact a nonce could be smaller so marginally fewer
bytes to send.

* Rather than messing with multiplart content, have a separate endpoint for
servers to get the access controls for a media item. That would mean two
requests, but might make more sense than both `/thumbnail` and `/download`
providing the info.

* Use some sort of "content token" for each piece of media, and require clients to
provide it, per [MSC3910](https://github.com/matrix-org/matrix-spec-proposals/pull/3910).

## Security considerations

* Letting servers track the relationship between events and media is a metadata
Expand Down