MSC2246: Asynchronous media uploads

[tulir]

Rendered

Implementations:

• Server: https://github.com/turt2live/matrix-media-repo/pull/364, https://github.com/matrix-org/synapse/pull/12484
• Client upload (actually a bridge): https://github.com/mautrix/go/commit/3b9911029134eb2d5de96f7898a70064199061a5 + https://github.com/mautrix/whatsapp/commit/f79ca422e8c3df7801f3e5e6a896ccf725eb1f14
• Client download should work with all existing clients to some extent with the 20s default stalling

Signed-off-by: Tulir Asokan [email protected]

---

FCP Proposal

[ara4n]

sounds excellent to me; would love to unblock streaming transfers at last. need to consider risk of DoS by creating lots of IDs, and define the json if any handed to the /create (for instance, could be useful in future for defining whether a give mxc url should be locked behind auth of some kind)

[bmarty]

The idea is then to send a media event, after the new /create endpoint, and before sending the media itself; isn't it? We have to consider the failure of the upload: it can lead to media event with eternal not found media. Also the client should have a way to know that the media is not yet available to the server for a better UI, by displaying a waiting message (ex: Bob is sending an image) for instance?

[JuniorJPDJ]

bump?

[turt2live]

The author believes this MSC has all the required implementation detail and is ready for FCP.

[richvdh]

looks great to me.

@mscbot fcp merge

[mscbot]

Team member @mscbot has proposed to merge this. The next step is review by the rest of the tagged people:

• [ ] @dbkr
• [x] @uhoreg
• [x] @turt2live
• [x] @ara4n
• [x] @anoadragon453
• [x] @richvdh
• [x] @erikjohnston
• [ ] @KitsuneRal

Concerns:

• ~~Different spam reduction controls appear to be required (read: taking a while to upload is a feature)~~
• ~~Edge case error codes need to be specified~~
• ~~Empty security considerations on a user-generated content endpoint~~
• ~~The client shouldn't be allowed to stall the server for infinite milliseconds (the server should impose a limit)~~

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

[sumnerevans]

FWIW, https://github.com/matrix-org/synapse/pull/12484 is a working implementation of this MSC in Synapse.

[turt2live]

@mscbot concern Different spam reduction controls appear to be required (read: taking a while to upload is a feature) @mscbot concern Edge case error codes need to be specified @mscbot concern Empty security considerations on a user-generated content endpoint @mscbot concern The client shouldn't be allowed to stall the server for infinite milliseconds (the server should impose a limit)

[turt2live]

@mscbot resolve Different spam reduction controls appear to be required (read: taking a while to upload is a feature) @mscbot resolve Edge case error codes need to be specified @mscbot resolve Empty security considerations on a user-generated content endpoint @mscbot resolve The client shouldn't be allowed to stall the server for infinite milliseconds (the server should impose a limit)

[mscbot]

:bell: This is now entering its final comment period, as per the review above. :bell:

[mscbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

[richvdh]

Spec PR: https://github.com/matrix-org/matrix-spec/pull/1499

[turt2live]

Merged 🎉

[tezlm]

I know I'm very late, but it's surprising that nobody mentioned tus yet, which allows for resumable file uploads. Since the core is headers + PATCH it can luckily be retrofitted into matrix in a future msc, if anyone wants it.

[sumnerevans]

For future code sleuths:

Async uploads PR: https://github.com/matrix-org/synapse/pull/15503

Released in Synapse:

• https://github.com/matrix-org/synapse/releases/tag/v1.97.0rc1