-
Notifications
You must be signed in to change notification settings - Fork 389
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
MSC2834: Media IDs as hashes #2834
Conversation
`via` specifies which homeserver to fetch the media from, and should be specified at least once. | ||
`viaroom` specifices which room the media is and may be specified at least once. | ||
|
||
For example, when uploading a file, the mxc URI returned by the server should look like the following: `mxc:m.sha256:9834876dcfb05cb167a5c24953eba58c4ac89b1adf57f28f2f9d09af107ee8f0?via=blob.cat`. |
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.
isn't returning via
kinda unneeded here? The client can just add their own server.
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.
This is mainly for backwards compatibility in bots / lazy clients.
|
||
Since secure hashing algorithms will create hashes that are unique across the Matrix network, homeservers are no longer part of the `mxc`. | ||
To allow routing, two parameters are added to the `mxc` URI, and therefore also supported by all endpoints for fetching media and media thumbnails: `via` and `viaroom`. | ||
`via` specifies which homeserver to fetch the media from, and should be specified at least once. |
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.
A mxc uri might make sense without any via
at all, just with viaroom
. If an m.image is sent in a room a client could easily construct a viaroom
based on the room id and a via
based on the senders domain. Though in the future the later might go away 🤔 Just not sure if mandating at least once via to be present being a good idea
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.
I think it's generally good to include it. A client might choose to not add on anything (even though they should), and we should expect that. And only a viaroom
could lead to potential recursion issues.
`via` specifies which homeserver to fetch the media from, and should be specified at least once. | ||
`viaroom` specifices which room the media is and may be specified at least once. | ||
|
||
For example, when uploading a file, the mxc URI returned by the server should look like the following: `mxc:m.sha256:9834876dcfb05cb167a5c24953eba58c4ac89b1adf57f28f2f9d09af107ee8f0?via=blob.cat`. |
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.
While you use plural forms further below, maybe state explicitly that multiple via
's and multiple viaroom
's are allowed, giving an example, too? mxc:m.sha256:9834876dcfb05cb167a5c24953eba58c4ac89b1adf57f28f2f9d09af107ee8f0?via=blob.cat&via=matrix.org&viaroom=!someroom&viaroom=!someotherroom
Rendered
Signed-off-by: mewmew alexafediverse@gmail.com