Kraken XMPP IM Gateway

Introduction

You may have noticed that there's a slight difference between what happens after you register with a transport from Spark, and when you register with a transport from anything else (other clients, admin console, etc).  Using Spark to register, the transports will not appear in your roster.  Instead, Spark offers icons across the top to interact with the transports, to handle login support, automatic logins, that sort of thing.  The mechanism that Spark uses is usable by other clients, so the following describes how to make use of it!

Registration w/o Transport JIDs in Roster

First off, upon registering with the transport, if you tag on our custom jabber:iq:gateway:register extension, you will instruct the IM Gateway plugin to register your account, but not put the transport's JID in your roster.  So to extend example 4 in XEP-0077:

<iq type='set' id='reg2'>
  <query xmlns='jabber:iq:register'>
    <username>bill</username>
    <password>Calliope</password>
    <email>bard@shakespeare.lit</email>
    <x xmlns="jabber:iq:gateway:register"></x>
  </query>
</iq>

So at this point, you do not have the transport's JID in your roster.  When you log into your XMPP account, there is no way for the IM Gateway plugin to be aware that you have logged in.  In a standard setup, it detects that you have logged in because you have a subscription with it and your presence is sent on to the transport in question.  So how do we get around that?  We'll go into that in the next couple of sections.

Detecting That You Are Registered

Without having a transport's JID in your roster, you need to be able to find out whether you are registered with a transport.  You can do this by performing a direct disco#info request direct at the transport's JID.  The response will included another custom extension, jabber:iq:registered, if you are registered.  The response will look something like:

<iq type='result'
    from='aim.example.org'
    to='text@example.org/somewhere'
    id='info1'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity
        category='gateway'
        type='aim'
        name='AIM Transport'></identity>
    <feature var='http://jabber.org/protocol/disco#info'></feature>
    <feature var='http://jabber.org/protocol/disco#items'></feature>
    <feature var='jabber:iq:gateway'></feature>
    <feature var='jabber:iq:register'></feature>
    <feature var='jabber:iq:version'></feature>
    <feature var='vcard-temp'></feature>
    <feature var="jabber:iq:registered"></feature>
  </query>
</iq>

How Does The Transport Know Our Presence?

Well, that's an interesting question.  The gist of it is, if you use this extension, it is completely up to you to tell the transports your presence.  You must send directed presence packets to the transports you wish to log into and make sure to send any changes as well.  (away status's, offline, etc)  The only thing the IM Gateway plugin will detect presence-related without a presence packet is a session being terminated.  Best practice is to send your unavailable presence packet none-the-less.  I repeat, it is up to you to make sure presence packets get to the transports.

Best Practices

Spark stores it's knowledge if what you want to automatically log into upon starting Spark in private data on the server.  This means your settings will follow you to any machine you are on that is running Spark and user's will not have to remember to check the "automatically log in" option for each transport on every new machine.