A bit of a special topic today, but I wasn’t aware about this before: For small files and videos, my XMPP server uses HTTPS and a local file storage at the server side to store and forward files. The file size limit is configurable and by default 20 MB. This suffices for 99% of my use cases. However, what about larger files, e.g. videos?
When I recently tried this, I noticed that on the recipient size I get a dialog box in the message stream to confirm that I want to receive the file. Once acknowledged, the sender app sends the file to the receiver app without using storage on the network side. The file is not sent peer to peer however, as in most cases, two NATs are between sender and receiver. Even if direct communication was possible, it is perhaps not such a good idea to let the two sides communicate directly, anyway, as the receiver would get the sender’s IP address. This could be a privacy issue. So what actually happens in practice is that the file is transferred through the STUN/TURN server I have set up for voice and video calls. How interesting!
The only slight problem: Both sender and receiver have to be online when the user on the receiver side initiates the file transfer and connectivity must not be lost while the file is being transferred. Otherwise, the file transfer fails and has to be restarted again from the beginning. Not ideal, as we are talking about large file transfers. Also, if the sender offers the large file while being in WiFi, the receiver might only accept it when the sender is out and about and has transferred to the cellular network Here, data might be charged quite differently, and if reception is bad at the time, the file transfer could take quite some time. But well, I guess you can’t have them all.