Update 3888-voice-broadcast.md

tweak MSC4016 references

proposals/3888-voice-broadcast.md

@@ -167,9 +167,10 @@ _Implementation based on [MSC4016: Streaming E2EE file transfers with random acc
 
 Streaming file transfer could be relatively easy on the server-side, given Glow exists and works (other than the operational unpleasantness of introducing an entirely new server), but client-side it requires major changes on all three platforms:
 
-- Switch the whole file-upload/download pipeline to be streamed rather than in-memory blobs
-- Switch crypto to AES-GCM (and spec it) to solve hashing causality
- - Switch the whole voice message UI to calculate waveforms locally as the file is received (rescaling the waveform as more message is received!?), and to allow scrubbing within a file whose length is changing from under you
+- Switch the whole file-upload/download pipeline to be streamed rather than in-memory blobs (desirable anyway for memory usage of clients, and ability to send > ~1.5GB files)
+- Switch crypto to AES-GCM to solve hashing causality
+- Switch to use async file uploads (MSC2246)[https://github.com/matrix-org/matrix-spec-proposals/pull/2246] so you can send the event to reference the URL before finishing uploading the media
+- Switch the whole voice message UI to calculate waveforms locally as the file is received (rescaling the waveform as more message is received!?), and to allow scrubbing within a file whose length is changing from under you
 - Optional: random access to the download, letting the receiver jump to the end of the voice message without having to download the rest of the file first. (a 2 hour voice message is roughly 20MB, so it might not be a disaster to have to download the whole VM first rather than doing random access). This would mean:
 - Change crypto to send in self-contained AES-GCM blocks (of 16KB or so), to support random access
 - Support scrubbing into chunks of the file which haven’t been downloaded yet