[Standards] Request HTTP upload slots over XMPP

Daniel Gultsch daniel at gultsch.de
Sun Jun 28 17:51:07 UTC 2015


Hi

I've been developing this idea since almost a year now. Never got around to
actually write some code until now.

2015-06-28 19:16 GMT+02:00 Christian Schudt <christian.schudt at gmx.de>:

> Hi,
>
> 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?
>

Letting the component act as a Jingle File Transfer receiver was my
original idea as well. However if you try to find any jingle ft
implementations you'll see that there basically aren't any. (To my
knowledge there is Gajim, Conversations and Swift (beta) and Swift is
currently incompatible with Gajim and Conversations because it uses :4 and
this doesn't look like it will change any time soon if you see the Gajim
dev complaining about some missing features in :4) And there is basically
no library out there that has ready to use jingle support. Meaning a
component like that will probably not be implemented any time soon. (It
stopped me for almost a year.)
On the other side if your goal is to serve the uploaded files via HTTP I
don't see a reason why the file shouldn't be uploaded via HTTP as well.
Basically every platform has build in (or easy access to) methods for
uploading and downloading HTTP files.

I don't see any upside of sticking with Jingle besides that it is somewhat
the "XMPP-way".


>
> 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.
>

While this might pose a theoretical problem I find it hard to believe that
there will be a lot of firewalls that allow XMPP connections (or arbitrary
SOCKS connections) but no HTTP connections.


> 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.
>

I don't plan on specifying the distribution of the URL. It should be up to
the user (client) to decide whether to use OBB or just sending the plain
URL as text. Just providing the user with a possiblity to upload files and
get a public HTTP address for them will also allow the usage in something
like PEP avatars (they can contain HTTP URLs as source)


cheers
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150628/50b69c76/attachment.html>


More information about the Standards mailing list