HTTP-based IM le 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 rewalls and/or NAT

Therefore:
Use a central HTTP-based le repository to offer the le 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 benet, users can send the same les 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 nished. Also, the user needs to trust in the central repository, and security meausures (like, it should be impossible to download a le without permission) should be in place.

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

HTTP-based IM le transfer
User scenario:
1. Sender has the le 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 le. These can include: le size le 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 le. 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 les to. Server is not necessarily the XMPP server, but the entity which gives the le 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 notication about the le'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 le, but it can also be that the Receiver is notied only after the le was uploaded 4. Receiver has to get metadata of the le. Restricted metadata (le name, size) can be given without the le already uploaded; however, preview could be given only afterwards. 5. Receiver should be able to download the le . Therefore, a HTTP link must be present to the receiver 6. Receiver may or may not be granted to let others download the le . This can be achieved either by creating a session between the Receiver and the Server, offering the le 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 le to multiple peers without further uploads. This can be achieved with metadata-communication between server and client.

HTTP-based IM le 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 le 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 le transfer
Implementation notes
1. For metadata, the OEmbed standard may be used. This provides reasonable knowledge about a le'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 les. This prevents further unnecessary uploads as well as makes the Sender able to get a history of uploads without the reach of the les 4. Sender may be able to choose from already uploaded les. This prevents further unnecessary uploads as well as makes the Sender able to get a history of uploads without the reach of the les (like, in a webclient) 5. Sender may or may not get information about a successful download. This could be through notication with an XMPP component of the server after download or by other means