HTTP-based IM file transfer

Problem:
User wants to transfer a document to IM peers

Context:
Protocol is XMPP Domains can be different User cannot be sure of the other side's support of the feature Either parties can use a web or mobile client Either parties can be behind firewalls and/or NAT

Therefore:
Use a central HTTP-based file repository to offer the file to the peer

Description:
There's no other solution simply which could work currently. Since we ran out of IPv4 addresses, and widespread IPv6 adoption is in the future, right now, every solution has to use a central part like STUN or ICE. If current trends continue instead of IPv6 becoming mainstream, less and less public IPs will be available to end-users. For restricted HTTP clients, in the current browser situation, HTTP is the only possibility. While HTML5-browsers are getting widespread, for corporate users, where XMPP is more widespread, old versions of IE are likely to be the prevailing browsers for years to come. As a side benefit, users can send the same files to multiple addresses uploading once Widespread library support exists for HTTP on all platforms, without exceptions. Also the system can offer previews and other metadata for the receiving party. The main disadvantage is, that the download can only start once the upload has finished. Also, the user needs to trust in the central repository, and security meausures (like, it should be impossible to download a file without permission) should be in place.

In the wild:
Multiple clients offer this solution for their users.

HTTP-based IM file transfer
User scenario:
1. Sender has the file on her device. Device can be a computer, a tablet machine or a phone (eg. sending pictures to peers), therefore 1.1 Sender has all the metadata of the file. These can include: file size file name title of the document (eg. in case of music) thumbnail or other preview (eg. in case of images) etc. 2. Sender has to indicate that she wants to send a file. Therefore, a request dqn be made to the server about the upload, possibly with the metadata 3. Server has to offer a way to upload. This can be a URL to HTTP POST the files to. Server is not necessarily the XMPP server, but the entity which gives the file transfer service in general. It can be, that the sender needs to be authenticated in order to do that 4. Receiver has to get a notification about the file's arrival . This can be either after or before the upload has started from the sender's side. It might be, that the Sender shouldn't start uploading until the receiver have "accepted" the file, but it can also be that the Receiver is notified only after the file was uploaded 4. Receiver has to get metadata of the file. Restricted metadata (file name, size) can be given without the file already uploaded; however, preview could be given only afterwards. 5. Receiver should be able to download the file . Therefore, a HTTP link must be present to the receiver 6. Receiver may or may not be granted to let others download the file . This can be achieved either by creating a session between the Receiver and the Server, offering the file only for a limited amount of time or number of trials, registering successful download, or by means of authentication (eg. linking to a session) 7. Sender may or may not be able to send the same file to multiple peers without further uploads. This can be achieved with metadata-communication between server and client.

HTTP-based IM file transfer
Sequence diagram:
Sender Request to upload Server Receiver

Upload File [OR] Download information Retrieve download information

Download information Download request File

HTTP-based IM file transfer
Example: DropBox
Sender Server [Beforehand] OAuth authentication OAuth token Receiver

upload Gather metadata ( path, is_thumbnail_available, icon_path, metadata ) Upload File (path, token) Download information (path, icon_path, metadata) Download request (icon_path) Download request (path) File

HTTP-based IM file transfer
Implementation notes
1. For metadata, the OEmbed standard may be used. This provides reasonable knowledge about a file's format. Sender may or may not embed OEmbed metadata into the sender request itself 2. For authentication, OAuth standard may be used. This gives reasonable service quality and client implementation libraries. Receiver's client may or may not be authenticated through this method. 3. Sender may be able to choose from already uploaded files. This prevents further unnecessary uploads as well as makes the Sender able to get a history of uploads without the reach of the files 4. Sender may be able to choose from already uploaded files. This prevents further unnecessary uploads as well as makes the Sender able to get a history of uploads without the reach of the files (like, in a webclient) 5. Sender may or may not get information about a successful download. This could be through notification with an XMPP component of the server after download or by other means