[Media+Timeline] Local echo support for media attachments

[stefanceriu]

Sending media attachments through the Timeline should make use of local echoes for a seamless experience.

---

Sub project: handle media upload in the send queue

• break apart uploading in a small state machine that can be reused in the send queue
  • Turns out this was not strictly required, because the code in the send queue and out are so different.
• modify the send queue storage format so it takes care of "requests", not only sending "event content"
• add a new request type for uploading a media
• (draw the rest of the freaking howl)
• handle medias local echoes in the timeline

Tasks

• refactor(media): some preparatory refactorings #4140
• media: cache media's content after uploading it #4149 (cache media and thumbnail)

Related

• [Media+Timeline] Expose media uploading progress through the timeline items #1968
• element-meta task

[jplatte]

Synapse implements asyncronous uploads from v1.97.0 onwards, with which this should be easier to implement (can generate a transaction ID / get an event ID for it in parallel with the upload). Ruma also supports the new endpoint.

[bnjbvr]

I intended to use the async uploads for this, but realized something…

• if we try to use the async media endpoints, that's a request that needs to be sent to the server
• as such, it may fail and needs to be retried
• we can't afford to lose the media the user requested to send, meanwhile
• so we need to cache that media in the database (after all, the request to create the empty MXID may fail a few times, b/o networks or [reasons]; or the user may force-kill the app; etc.)
• but we can't cache it using the event cache, since we don't have a stable MXID yet (that's the whole point of the request!)

So, I'm circling back to:

• using temporary fake MXID, e.g. mxc://send_queue/{TRANSACTION_ID} since the transaction id is memoized in the database
• use those to preemptively cache the media's contents before any request is sent,
• not use async upload at all, since this doesn't bring us anything new here
• after the upload happened, replace in the media cache the temporary MXID with the actual one

I will implement this, since I'm not happy about the alternatives below (unless someone has a strong objection / another new great idea :)).

Alternatives could be to:

• either have a new table in some store, to store those to-be-sent media content bytes. Scatters state in multiple tables, and really duplicates the functionality of the media cache
• or save them in the send queue directly, e.g. as base64, but this is going to inflate the media's size, so I don't think this is a good idea either