-
Notifications
You must be signed in to change notification settings - Fork 375
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
MSC4177: Add upload location hints proposal #4177
base: main
Are you sure you want to change the base?
Changes from all commits
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,63 @@ | ||
# MSC4177: Upload Location Hints | ||
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. Is this only useful for uploads, or is would something similar also be useful for downloads? 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. Both really - specified at upload time but yields benefits on download (assuming others downloading are in the same location/region). |
||
|
||
This MSC proposes extensions to the media APIs that allow servers and clients to provide each other | ||
location hints for uploaded media. | ||
|
||
Often Matrix homeservers serve users in many geographical locations. For media that is uploaded and | ||
downloaded via a CDN (see: [MSC3860](https://github.com/matrix-org/matrix-spec-proposals/pull/3860), | ||
[MSC3870](https://github.com/matrix-org/matrix-spec-proposals/pull/3870)) it is advantageous to use | ||
a location as close to the user as possible. This MSC allows servers to advertise available media | ||
storage locations and for clients to request media is uploaded to one of these locations. | ||
|
||
All the changes are optional, ultimately the server retains control of where media gets put. | ||
|
||
## Proposal | ||
|
||
Firstly, to provide available locations to clients, the [`/_matrix/client/v1/media/config`](https://spec.matrix.org/v1.11/client-server-api/#get_matrixclientv1mediaconfig) | ||
endpoint is extended with a new response field: | ||
|
||
```json | ||
{ | ||
"m.upload.locations": ["EU", "NA"], | ||
... | ||
} | ||
``` | ||
|
||
The `m.upload.locations` field is a list of strings. Interpretation of the strings is up to clients | ||
and servers and undefined in the spec. (Note: does this make sense?) | ||
|
||
When clients wish to upload media, they can then include one of the location hints from the config | ||
in upload or create media requests using the `location` query parameter, for example: | ||
|
||
- `POST /_matrix/media/v1/upload?location=EU` | ||
- `POST /_matrix/media/v1/create?location=EU` | ||
|
||
When clients request a location the server MAY use that location hint to upload the media to a | ||
bucket matching that location. Clients must not expect this to be guaranteed and ultimately the | ||
server decides. | ||
|
||
## Potential issues | ||
|
||
How do clients/servers interpret location hints? Is it sensible to leave this undefined/open. We | ||
could provide explicit options, or a baseline of options, "it is recommended location hints use | ||
geographical ISO codes" for example. | ||
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. Is the idea that a client would auto-select the most appropriate hint or would the user have to manually pick from the hints the server presents? For auto-selection to work, I think at least a recommendation of hint formats would be needed. 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’s the idea, perhaps with a speed test endpoint as mentioned above. |
||
|
||
## 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. This sounds more like a routing issue and not a protocol issue. Can using something like Anycast routing or geo-based DNS help find the closest location? 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. I think the term you are looking for is EDNS Client Subnet. https://en.wikipedia.org/wiki/EDNS_Client_Subnet What Wikipedia doesn't mention is NextDNS (and DNS0) and Adguard having more private implementations of it. 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. Kind of, I'm talking about how authoritative servers use that + the original source IP to serve close servers, like the GeoIP backend of PowerDNS or Route53 geolocation routing. Maybe that's one in the same, but more the application instead of the underlying technology. 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.
Definitely, although requires a more complicated setup. But also using request IP would satisfy most use cases here I think. My thought process for the PR was to give explicit control/negotiation of locations over to clients/servers rather than the server guessing the best location for a client to upload files to. Now that I’ve said that I’m not sure there’s really much improvement with this change.. |
||
|
||
Server could use request IP to achieve this without any hints, though inaccurate and invalid when | ||
a user is abroad. This is reasonable fallback behaviour for a server when clients do not provide | ||
any location hint. | ||
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. I don't have a whole lot of experience with CDNs, but would it be reasonable to expose an endpoint that would allow the client to measure the network speed, e.g. by uploading/downloading a small file, from each location? And then it can use the location with the shortest time. It might not be entirely accurate, but might be better than guessing based on IP address, or trying to divine the right location based on a location code? 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. Yeah a test endpoint per location would be a handy addition here so clients can make informed decisions. |
||
|
||
## Security considerations | ||
|
||
None? Reveals bucket locations (to logged in users), but servers are aware of this and there's | ||
no security issue (I think). | ||
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. Since the hints are expected to be more accurate than IPs, the server would possibly gain more metadata about the client. |
||
|
||
## Unstable prefix | ||
|
||
`com.beeper.m.upload.locations` | ||
|
||
## Dependencies | ||
|
||
Though not a hard dependency uploads will only get speed benefits from this MSC once [MSC3870](https://github.com/matrix-org/matrix-spec-proposals/pull/3870) | ||
is merged (otherwise uploads still route through the users homeserver location). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementation requirements: