[Story] Local echo for media upload

[manuroe]

Description

• As a user
• I want to see a local echo of my media uploads in the timeline while they are still being uploaded
• So that I can continue using the app without being blocked by the upload progress screen as we have now

Acceptance criteria

• Uploading media no longer results in a blocking UI while the upload is in progress
• The local echo shows a thumbnail of the media being uploaded
• The upload state is clear for the sender
• The user can cancel the upload
• Retries in case of failure are managed like for the message sending queue: except if it is an unrecoverable error, retries are automatically done
• Sending order is respected. Media and text messages have the same priority
• Multiple upload can happen at the same time
• Tech one: the media being upload is directly stored in the cache with its thumbnial. We do not want to reload it from the matrix media repository once the upload is done and the matrix event is returned by the sync.

Leads

• Tech:
• Design:

Size estimate

None

Dependencies

• None

Out of scope

• Nothing

Open questions

### Questions
- [ ] Do we want to support local echo for any file upload?
- [ ] Do we want an upload progress? Or can we reuse the indicator for text message, ie empty circle, then circle with a check?

Subtasks

### Android

### iOS

### Rust

### Other

Sign-off

Android

• [ ] Design sign-off on completion
• [ ] QA sign-off on completion
• [ ] Product sign-off on completion

iOS

• [ ] Design sign-off on completion
• [ ] QA sign-off on completion
• [ ] Product sign-off on completion

[manuroe]

Notes from a tech discussion in the SDK chapter:

• From a tech point of view, MSC2246: Asynchronous media uploads was useful to handle the local echo in the timeline but it was an old assumption. With the sending queue we introduced this year, it is no more mandatory to rely on this MSC for the pure purpose of making the media local echo implementation easier in the SDK. It is actually the opposite see below
• MSC2246 raises new edge cases to manage (there might be more we will discover if weimplement it):
  • Receiver side: the app must repeatly retries to load the content until it is fully uploaded
  • Receiver side: the app needs to compatible with the behaviou4cabove. It means EW, EA, EI and all other Matrix clients.
  • Sender side: the flow involved by the MSC breaks the generic simplicity of the sending queue. The sending queue sends data in a linear order. The MSC2246 with media uploaded asynchronously breaks this flow, leading to a more complex implementation (more bugs, harder to maintain, etc)
  • We need to check if it is compatible with the blur hash
• We are not confortable to fully use this MSC now as it will create more problems than what it will solve
• But we raised the idea to use it in a "synchronous way", ie use all the new API to upload the media but send the final matrix event in the timeline only when uploads are done. We are not sure yet about the benefits. It is more an implementation detail we will see when implementing the feature