[Standards] Request HTTP upload slots over XMPP
christian.schudt at gmx.de
Sun Jun 28 17:16:25 UTC 2015
I agree that XMPP is lacking such a specification („MUC File Transfer“, „Offline File Transfer“).
Maybe it’s even better, if the client and server could negotiate the transport method first, so that the client could choose between „HTTP Upload“, "SOCKS 5 Upload (XEP-0065)“ or „In-Band Upload (XEP-0047)“.
What about the idea, that an XMPP server (component) acts as a Jingle File Transfer receiver, so that a client and the server (component) negotiate the File Transfer by means of XEP-0234 with just another (third) transport method (HTTP), besides XEP-0260 and XEP-0261?
That way clients could just reuse existing protocols and the sending entity wouldn’t care if they are sending the file to another client or to a server component.
Another advantage: HTTP upload might not always work (e.g. when behind a HTTP proxy) and in this case the upload could fall back to IBB.
After successful upload, the client (or the server in behalf) could send an XEP-0066 OOB message with the URL to all interested parties. The URL has to be communicated of course, maybe as session-info.
Am 28.06.2015 um 14:25 schrieb Daniel Gultsch <daniel at gultsch.de>:
> current file transfer techniques in XMPP all share the same downside. They are P2P and thus don't work with Carbons and MUCs. The synchronous nature of P2P protocols also doesn't play nicely with MAM.
> Uploading files manually to an HTTP server and sharing the link has been an workaround for this for a long time now. (This has also been used in the good old IRC age)
> While users have a variety of services to choose from (imgur, mediacrush, self hosted OwnCloud, Google Drive, ...) the major downside of this is that an xmpp client can not automate this process since the different services don't share a common api.
> Furthermore using a third party service might require the user to enter additional credentials on top of the XMPP credentials.
> Thus it would make perfect sense to have the xmpp provider also provide a way to upload files to an HTTP server.
> Today I want to introduce a simple protocol for requesting what I call 'HTTP upload slots'.
> An HTTP upload slot is basically a tuple of a PUT and a GET URL.
> The user requests a slot from a component (most commonly running on the users servers and discoverable by disco items) providing a desired file name and a file size. The component does some checking on the data (quota, max file size, authorization) and provides the user with a PUT and a GET url which both are unique. (long random string in path)
> <iq to='upload.domain.tld' id='random1' type='get'>
> <request xmlns='urn:xmpp:http:upload'>
> <iq to='user at domain.tld' id='random1' type='result'>
> <slot xmlns='urn:xmpp:http:upload'>
> Note that the get and put host are not the same. This allows for the files to (optionally) be served over some standard HTTP server /or even a CDN.
> Also note that the user provided file name is reflected in the GET url as well this way allowing the recipient of that URL to see the original file name. (However this is the something a sane component should do and is not required)
> I would like to get some comments before I actually put this down into a XEP.
> For those interested here: https://github.com/siacs/HttpUploadComponent is a sample python implementation of such a component.
> And here is a branch for Conversations that can talk to that component. https://github.com/siacs/Conversations/tree/feature/http_upload
More information about the Standards