I managed to get the basic in-band bytestream file transfers working. It still doesn’t have any user interface, that’s depending on a project by my mentor. For now, it’s simply triggered by a hardcoded target JID that gets a file transfer when it sends a presence.

After finishing the proof of concept, I added some error handling and did some code cleanup. With that done, I did some interoperability testing. With Gajim , the file transfers now worked well, so I moved on to test with Conversations . Here, something funny happened, my Dino code sent (abbreviated for brevity):

<iq type='set'>
  <jingle action='session-initiate'>
    <content>
      <description xmlns='urn:xmpp:jingle:apps:file-transfer:5'>
      	…
      </description>
      <transport xmlns='urn:xmpp:jingle:transports:ibb:1' block-size='4096' />
    </content>
  </jingle>
</iq>

And Conversations responded:

<iq type='set'>
  <jingle action='session-accept'>
    <content>
      <description xmlns='urn:xmpp:jingle:apps:file-transfer:5'>
      	…
      </description>
      <transport xmlns='urn:xmpp:jingle:transports:s5b:1'>
        <candidate host='146.255.57.229' type='proxy' jid='proxy.jabber.ccc.de' port='5224' />
      </transport>
    </content>
  </jingle>
</iq>

In essence, my Dino code asked to open a Jingle session for a file transfer, using in-band-bytestreams as the transport. Then, Conversations responded that it accepts my offer of Socks 5-based Jingle transport for the file transfer, accepting an offer I didn’t make. I think this is a violation of the Jingle XEP ( XEP-0166 ): If the other party wants to negotiate a different transport, it should probably use the transport-replace Jingle action. I created an issue ( Conversations#3478 ) which was quickly resolved. I have yet to test the fix, I don’t have a development setup for Conversations yet.

The in-band bytestream file transfers I tested were quite slow (<2KB/s), probably some rate-limiting of the servers, I didn’t investigate furtherly.

As the first task, we planned to get a working, proof-of-concept Jingle file transfer over an “in-band bytestream” (IBB, XEP-0047 , XEP-0261 ). To get to this point, I planned to write a module for basic Jingle interactions, supporting the necessities for file transfers, and a non-final API for transport methods on the other side.

What do in-band bytestreams look like? “In-band” means that the file data will go through the same connection as the rest of the XMPP stream that also contains your chat messages and metadata like read receipts, etc. It has to fit into the XML stream, an example with an 28-byte file below:

<iq xmlns="jabber:client" to="tish@example.com/gajim" from="blagovest@example.com/dino" type="set" id="e8656828-2da8-48a5-828d-804542945851">
	<data xmlns="http://jabber.org/protocol/ibb" seq="0" sid="514ef10b-22e7-4e58-bf46-cca01629e826">
		SGVsbG8sIGluLWJhbmQgYnl0ZXN0cmVhbXMhCg==
	</data>
</iq>

As you can see, this is quite inefficient. The <iq> / <data> tags amount to roughly 256 bytes. The actual data has to be base64 -encoded because XML cannot contain arbitrary binary data, leading to an extra 33% overhead. With the default blocksize of 4096 bytes as specified in the IBB XEP, we get a total overhead of 40%. Nevertheless, this transport is simple to implement as it does not need additional network connections beyond the already existing.

While trying different approaches for the Jingle transport API, fiaxh (my mentor) helped me decide: I’m now using abstract classes for the different transports, and signals for the users of a Single session, a pretty Vala-esque approach. After this planning, I went ahead and tried to realize this in actual code. This resulted in basic session opening support (only initiating), support for in-band bytestreams and file transfers.

What’s still missing for merging this? I was pretty happy that the code almost worked after fixing syntax error and obvious oversights. It still has a pretty serious bug: Currently, when testing the file transfer from Dino to Gajim, Gajim drops the last chunk we send. Additionally, the code needs proper error handling, currently it just writes a message to the standard error output.

During the weekly organization chat, flow sent me an interesting document written by someone who implemented the Jingle protocol in multiple clients and wrote about the “enlightenment” he achieved in doing so. Thanks for that, I’ll check it out the next week.