In the Telepathy framework there is a mechanism, called tubes, for arbitrary data transfer with your IM contacts so you can play games, do collaborative editing, etc. Until now telepathy-gabble (the component that does XMPP) supported only in-band bytestreams, or IBB for short: all the data is sent inside the XMPP stream encoded in base64. The pro of IBB is that you don’t have to worry about NATs or listening on new ports but on the other hand it’s slow and could use too many resources on the server.
In the long term we want to use Jingle also for data transfer and not only for audio/video calls, but in the meantime we needed something better than IBB so Guillaume Desmottes and I started to implement SOCKS5 bytestreams support in telepathy-gabble. With SOCKS5 bytestreams you just send a list of IP addresses, both yours and the ones for possible intermediate proxies, when you want to start a bytestream. The other side tries to connect to the addresses it received and, when it succeeds connecting to one of them, sends the working address back to the initiator. This leads to three possible results: a direct connection, a connection through a proxy (still better than with IBB as you don’t use base64 and the proxy can be a separate machine from the XMPP server) or just fail if no connection is possible.
In XMPP you decide whether to use SOCKS5 or IBB using a negotiation method called stream initiation that allows the choice of a single bytestream method, if it fails you cannot fallback to the slow but safe IBB. Just failing is not acceptable as the applications running fine with just IBB could stop working for somebody, so we decided to extend stream initiation. With our simple extension we can keep compatibility but also be able to try SOCKS5 and, in case of failure, switch to IBB.
With fallback we were able to finally merge the SOCKS5 branch, so now the next two steps are adding support for intermediate proxies (for now we do only direct connections), and add file transfer using the same bytestream mechanisms. Hope to have good news about this soon 
Marco Barisione's blog 
Hi!
It’s good to hear you can finally do SOCKS5 filetransfers!
Regarding your ‘simple extension’ – Jingle File Transfer XEP uses also SOCKS5 and IBB and can fall back to IBB, so it seems you are reinventing a wheel here. Jabbim client implements this. Maybe you should have asked other developers on jdev and/or standards mailing lists – they would have pointed you to this XEP.
http://xmpp.org/extensions/xep-0234.html
LikeLike
@Lukáš:
Please, read the post before commenting next time.
1. We still don’t have file transfer, just tubes.
2. Jingle is our long term plan but we needed something now.
3. I talked about this on jdev.
LikeLike
Sorry I jumped to conclusions, of course I read the post. I forgot you can only do FT with telepathy-salut, if I remember correctly.
Still, why can’t you use JFT instead of extended SI for your tubes? Seems like really small step for FT support then. And later you could add other transports (ICE) to JFT (alongside existing SOCKS5 and IBB).
There aren’t many applications implementing tubes with which you have to be backwards compatible, are there.
Never mind, it was just suggestion.
LikeLike
What’s the exact point?
On the one side you are just implementing the common denominator of most chat protocols, and on the other hand you are advancing the protocols in a way that only telepathy-enabled apps can use them.
Wouldn’t it make more sense to extend _one_ messaging protocol for a start, so that every app/plattform may support it?
LikeLike
@mike:
On the one hand, we aren’t restricting ourselves to supporting a common denominator of protocols; we aim to support as much of each protocol as we can.
On the other hand, all protocol extensions I can think of have been to XMPP, and in each case we’ve discussed our efforts with the XMPP community and worked to standardize it.
LikeLike