Update MSC4039 #1
Conversation
096ef1c to
f58482e
Compare
- added download API to handle MSC3916 "Authentication for media" - added e2ee aware variants for both upload and download Signed-off-by: Kim Brose <kim.brose@nordeck.net>
f58482e to
4784869
Compare
Signed-off-by: Kim Brose <kim.brose@nordeck.net>
Signed-off-by: Kim Brose <kim.brose@nordeck.net>
Signed-off-by: Kim Brose <kim.brose@nordeck.net>
Signed-off-by: Kim Brose <kim.brose@nordeck.net>
Signed-off-by: Kim Brose <kim.brose@nordeck.net>
Signed-off-by: Kim Brose <kim.brose@nordeck.net>
Signed-off-by: Kim Brose <kim.brose@nordeck.net>
|
TODO: review wrt. actual current implementation TODO: deprecate |
Signed-off-by: Kim Brose <kim.brose@nordeck.net>
Signed-off-by: Kim Brose <kim.brose@nordeck.net>
Signed-off-by: Kim Brose <kim.brose@nordeck.net>
Signed-off-by: Kim Brose <kim.brose@nordeck.net>
Signed-off-by: Kim Brose <kim.brose@nordeck.net>
3c2aa8c to
08d4b7f
Compare
There was a problem hiding this comment.
Looks good overall. 👍 Some smaller remarks
XMLHttpRequestBodyInit can also be form data or URL search params. Maybe we should use a binary format instead (array or blob…)?
| unauthenticated download endpoint, provided they acquired the URL of the homeserver, the widget API does not currently | ||
| contain a way to authenticate with the upload and new download endpoints nor does it otherwise expose these functions | ||
| from the client hosting the widget to the widget itself. This would be useful to post images or attachments, but also to | ||
| upload larger data that can't easily be stored in a room event, like a whiteboard's content that can easily grow larger |
There was a problem hiding this comment.
I would keep this more general, something like
„but also to upload larger data that can't easily be stored in a room event exceeding the 64kb event size limit“
There was a problem hiding this comment.
this is a leftover from the original MSC; I think illustrating the point preempts questions such as "whatever could be so big!" but am also fine with changing it 🤷
Signed-off-by: Kim Brose <kim.brose@nordeck.net>
while possibly true, I deliberately did not touch this (which you didn't see because the diff hides unchanged parts - see the upload direction) as it describes the existing implementation of the MSC prior to this PR. looking into the link you provided
sounds like XMLHttpRequestBodyInit can also be a Blob. Sounds then like it could be easy to change if we are the only ones using this API and already using Blob. An alternative could be to create a new MSC and hence a new unstable endpoint, and having to care less about backwards compatibility. This appears to be the original reasoning for the genericness of the interface: https://github.com/matrix-org/matrix-widget-api/pull/86/files#diff-67e6f0676307a87283ca4533526de9b3ac4ff3bafdd0d016947e40e2b3574757R693-R694 🤷 |
|
Should we directly update the MSC pull request or first implement it to see if it works? |
|
We should start implementing (at least the authed media parts) right away regardless, but I would also suggest to get some SCT (and maybe Element) eyes on it asap, particularly in terms of Authed Media and possible support/alignment with that. |
updates matrix-org#4039
changelog:
policy stuff:
Signed-off-byline in the message (more info).