The pre-message could include metadata for indicating that the same piece of content is attached in multiple alternate representations in the post-message. Ideally, one of the representations would be orders of magnitudes smaller (up to 140kB) so it could serve as a preview for the full content and also possibly satisfy those who are low on storage or cellular data cap. A global setting could specify which representation to render by default.
A static thumbnail or a few animated key frames could be provided as a preview for the full video file, possibly also stored at both high (>2Mb/s) and low bitrate (<200kb/s). If the user recognized the video based on these, their client would not have to download the whole video.
A lower resolution version with stronger compression would be attached of the same picture for small screen viewing and for frugal users along with a high quality version for printing and projecting on a big screen.
The same audio message could be included as encoded with codec2 or Opus at a low bitrate and separately in high fidelity.
A demo version of a webxdc app could be attached once with low quality textures, a smaller word list, lower fidelity sounds, minification and with only the basic levels. Additionally, a full version could be included as an alternate attachment containing all addons, such as levels, accessories, music and avatars that could weigh 5MB. The same webxdc could be included in multiple languages and the client would only download the one corresponding to their locale.
This would solve the long-running debate about the exact level of compression that should be applied:
This solves many but not all issues cos maybe the developers are also worried about filling up the receiver’s relay storage (especially in multi-device mode) or overloading relays which might have limited bandwidth by sending too much network traffic, if this is something the developers worry about. (I guess the relay storage issue could be solved with some smart automatic deletion logic.)
I think it would make things worse from both the convenience and privacy perspective. It would turn the asynchronous app into a synchronous one which is much less convenient because not everybody is constantly online and it also potentially exposes your IP address. (While the offficial DC position seems to be “just use a VPN to protect your IP address”, some of the developers seem doubtful that this is sufficient when using iroh and so far none of the developers have stated for the record that a VPN is actually guaranteed to prevent iroh leaking your IP.)
True. Although that issue could be mitigated in a myriad of ways.
Delta Chat is using Iroh already and leaking your IP already, right? Seems sort of tangential to my suggestion for that reason. They’ve already set down on this p2p pathway.