-
Couldn't load subscription status.
- Fork 414
MSC3859: Add well known media domain proposal #3859
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.
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
Changes from 2 commits
81ed592
cb259ac
f1ca606
86123b0
7ba95c8
4e7bf60
8aba847
305c9fa
c38579f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,38 @@ | ||
| # MSCXXX: .well-known Media Domain | ||
|
|
||
| Currently Matrix clients and servers discover homeservers and identify servers via the `.well-known/matrix/client` and `.well-known/matrix/server` endpoints. This is currently limited to the homeserver and for clients the identity server. This MSC proposes adding an additional field that can be used to specify a media server that can optionally be used for `/_matrix/media/*` endpoints. | ||
turt2live marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| The reasoning behind this change is to support hosting media behind a CDN designed and optimised specifically for serving media. Since media transfers and endpoints are very different to the other JSON based endpoints a separate domain offers maximum flexibility for server owners. | ||
turt2live marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
|
|
||
| ## Proposals | ||
|
|
||
| ### Extend the client .well-known | ||
|
|
||
| Add a new optional field, `m.media_server` that can specify a separate URL to be used for media requests. Clients can then optionally use this field for media endpoints: | ||
uhoreg marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| ``` | ||
| { | ||
| "m.homeserver": { | ||
| "base_url": "https://matrix.example.com" | ||
| }, | ||
| "m.media_server": { | ||
| "base_url": "https://matrix-media.example.com" | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| To ensure backwards compatibility the homeserver base URL must also be able to serve the same media requests (via a proxy or some other backend system). | ||
|
|
||
| ### Extend the server .well-known | ||
|
|
||
| This is the same as above but for the server endpoint: | ||
|
|
||
| ``` | ||
| { | ||
| "m.server": "matrix.example.com:443", | ||
| "m.media_server": "matrix-media.example.com:443" | ||
| } | ||
| ``` | ||
|
|
||
| As above, the non-media endpoint must also serve media requests. | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Please follow the proposal template. You're missing some sections that I would expect to see for this type of proposal, in particular "Alternatives", "Security considerations", and "Unstable prefix". Some possible alternatives:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Missng sections added in 86123b0. Re: login response I don't think this works because media is accessible without authentication with a known MXID which login would prevent. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
That seems reasonable. I'd suggest still including that in the "Alternatives" section -- part of the purpose of that section is to indicate other possible ways to achieve the goal, and say why the proposed solution is better. |
||
Uh oh!
There was an error while loading. Please reload this page.