XEP-0096, 0095, 0047: File transfer

[cburschka]

You know what would be cool?

This would be cool.

http://xmpp.org/extensions/xep-0234.html

[cburschka]

I can't test 0234 (Jingle) because I haven't got a client that uses it. Pidgin can only do 0096 (SI).

Since 0234 is experimental and 0096 is a draft standard, the latter one is probably the way to go for now.

[cburschka]

Here's what Pidgin sends.

<iq xmlns="jabber:client" from="[email protected]/luna/pidgi53BDC85C" 
to="[email protected]/cadence/v1.10.0-57-gb5b1414/1451503561362" type="set" 
id="purple1eae2ba4">
   <si xmlns="http://jabber.org/protocol/si" id="purple1eae2ba5"
profile="http://jabber.org/protocol/si/profile/file-transfer">
      <file xmlns="http://jabber.org/protocol/si/profile/file-transfer" name="listen.py" 
size="1532" />
      <feature xmlns="http://jabber.org/protocol/feature-neg">
         <x xmlns="jabber:x:data" type="form">
            <field var="stream-method" type="list-single">
               <option>
                  <value>http://jabber.org/protocol/bytestreams</value>
               </option>
               <option>
                  <value>http://jabber.org/protocol/ibb</value>
               </option>
            </field>
         </x>
      </feature>
   </si>
</iq>

[cburschka]

If I send a similar stanza to Pidgin, and accept the file transfer there, then Pidgin will respond with the following:

<iq xmlns="jabber:client" from="[email protected]/luna/pidgi53BDC85C" 
to="[email protected]/cadence/v1.10.0-57-gb5b1414/1451503561362" 
type="result" id="5:sendIQ">
   <si xmlns="http://jabber.org/protocol/si">
      <feature xmlns="http://jabber.org/protocol/feature-neg">
         <x xmlns="jabber:x:data" type="submit">
            <field var="stream-method">
               <value>http://jabber.org/protocol/ibb</value>
            </field>
         </x>
      </feature>
   </si>
</iq>

[cburschka]

And if I send that in response to a file offer from Pidgin, I get

<iq xmlns='jabber:client' from='[email protected]/luna/pidgi53BDC85C' 
to='[email protected]/cadence/v1.10.0-57-gb5b1414/1451505633454' type='set' 
id='purple1eae2bcf'>
  <open xmlns='http://jabber.org/protocol/ibb' sid='purple1eae2bcd' block-size='4096'/>
</iq>

[cburschka]

Of course, actual transfer involves also implementing XEP-0047.

Basically, we have 0095 for the Stream Initiation, 0096 for a particular kind of stream (File Transfer), and 0047 for the method of transport (In-Band Bytestream, which the web client is basically limited to because Javascript has a really hard time trying to open arbitrary TCP sockets.)

[cburschka]

The rest of the protocol is pretty much just responding ACK to everything the initiator sends (or, on the other end, packing the data into chunks and sending them, waiting for each ACK before sending the next).

Oddly, I don't see a way to match an IBB bytestream to a SI file transfer. If you have multiple file transfers pending from the same entity, is there no way to identify which bytestream is which?

[cburschka]

No wait, the session ID (<open sid>) of the byte stream has to match the ID (<si id>) of the stream initiation.

[cburschka]

Note: IQ stanzas are freely propagated by MUC, so you absolutely can send a file to a nickname instead of a JID directly.

Since this protocol is the first one that has to actually interact with the user in response to a remote-initiated IQ, this means the IQ callback will need to generate a user object from a JID.

Up to now, this has been done in message callbacks directly (using intricate logic, no less). Just as #292 added an xmpp.jid() function that turned an object into a JID, we need a function that does the reverse.

[cburschka]

Also, check if we have any chance of implementing XEP-0065 (Out of Band SOCK5 streams) after all. Maybe it can be done with a server component that mediates the stream, to avoid the firewall/CORS issue (maybe there's an ejabberd module?).

[cburschka]

Finally, some of the scalability of In-Band hinges on this question. While a file of maybe ~10 MB should be fine, anything larger may be too much of a performance hit. The sock5 URI might be saved directly to a file.

[cburschka]

maybe there's an ejabberd module?

mod_proxy65

[cburschka]

... I'm going to postpone this. It's not even remotely ready, and if the Nightmare update is going to be out before summer, it has to be out next week.

[cburschka]

There seems to be some error in the decoding process. Binary files arrive completely unusable, and non-ASCII Unicode characters are altered in interesting ways.

Byte order stuff?

[cburschka]

A JPEG file was transferred from Pidgin to Cadence. It begins:

FF D8 FF E0  00 10 4A 46  49 46

(4A 46 49 46 = JFIF)

The result begins:

C3 BF C3 98  C3 BF C3 A0  00 10 4A 46  49 46

How does FF become "C3 BF", and D8 become "C3 98" and E0 become "C3 A0"?

[cburschka]

Considering the low performance and the bugs, this is likely to be a niche feature at best (unless replaced by mediated HTTP POST uploads, which are also a thing). Going to table this for now.