One of the hard problems to solve with onesoup integration into the native messaging protocols is ensuring messages are actually displayed to the user.

The problem that exists is that onesoup acts as a gateway to the phone, but also as a client to the messaging network. To the network, once a message gets delivered to the client, it has been displayed.

Well, not always. XMPP is the exception and it provides extensions to differentiate between “received” and “processed”. A message might be received many times, but it will only be processed once. IMPS also provides similar acknowledgement capabilities, which are very necessary given the nature of the network. But since this is an “extension”, a draft, to the protocol, we can’t rely on it. Gtalk for example does not use it.

But the problem comes with Yahoo!, AIM/ICQ and MSN (and XMPP until such extension is supported). None of these protocols support transactions, so once onesoup consumes the message, even if the user has not seen it yet, the message won’t be redelivered. Why is this a problem? Let’s use AIM for illustration purposes but this really is the same problem across all of them.

Suppose an AIM message gets delivered to onesoup. AIM will then remove the message from their IM server’s archival offline storage (if the user has one). If the phone fails to pick up the message for whatever reason, and then the user connects via desktop client to the proprietary protocol, the message will be waiting at onesoup. The only time the user will see it is when he or she sign back into onesoup.

To avoid this behavior I am planning to implement at least a couple of features. One is necessary to support the IMPS specs anyway, but the other ones will be an alerting system:

• The spec provides a so-called TimeToLive or KeepAlive, basically the time that needs to pass without any client request for the server to be able to evict the session. It is during this time, until the session times out, where there is a problem of receiving messages and not being able to deliver them if the client has, for example, gone off the cell network. If the KeepAlive setting is too low, besides unnecessary data transfers, one risks frequent disconnections and reconnections, but the chance of messages being kept in the onesoup message store is lower.
• The spec also defines a TCP channel for the server to notify the client that there are messages to collect (CIR). One possibility to limit the risk of storage of undelivered messages is evicting the session if such socket is closed on the client side, and obviously, close the connection to AIM, etc. On cases where the cell phone is re-allocated an IP by the operator, this trick basically means that the phone will need to re-login. But I think this is acceptable, since such behavior is happening daily in our desktop clients due to firewall rules.

But even these two tricks are not enough. If the socket is not closed, there is no guarantee that the client will come to pick up a message after it being notified via CIR. Additionally, not all phones support CIR, so such mechanism won’t work too well for them. But for most phones it should work, assuming the clients behave well-enough to poll right after receiving the CIR.

Ideas or comments appreciated. Should we lower the KeepAlive at the cost of higher data transfers but lower risk of messages sitting on onesoup undelivered?

I was implementing last night the integration with Jabber/XMPP using the Smack API, when I came across one of the most interesting features in XMPP that I was not aware of.

Every JabberID (JID) consists of user@service/resource, so for example, one could have a JID like donald.duck@gmail.com/Adium meaning:

• username is donald.duck
• service is gmail.com
• resource is Adium

but the thing that I found more curious is that nowhere it says what the hosts are to establish a TCP/IP connection!! Actually, you could specify them, but that’s unnecessary, and you shouldn’t!

XMPP is expected to use SRV DNS Records to discover the service, so in this case, using dig, one would discover the host for jabber (“_jabber”) service using TCP (“_tcp”).

$ dig _jabber._tcp.gmail.com SRV

;; QUESTION SECTION:
;_jabber._tcp.gmail.com. IN SRV


;; ANSWER SECTION:
_jabber._tcp.gmail.com. 86400 IN SRV 20 0 5269 xmpp-server1.l.google.com.
_jabber._tcp.gmail.com. 86400 IN SRV 20 0 5269 xmpp-server2.l.google.com.
_jabber._tcp.gmail.com. 86400 IN SRV 20 0 5269 xmpp-server3.l.google.com.
_jabber._tcp.gmail.com. 86400 IN SRV 20 0 5269 xmpp-server4.l.google.com.
_jabber._tcp.gmail.com. 86400 IN SRV 5 0 5269 xmpp-server.l.google.com.

The fantastic thing is that Smack does this behind the scenes on the XMPPConnection class. Kudos!

I still find it surprising that the “classical” messaging network operators don’t support the native (“Wireless Village”) mobile clients shipped with almost every phone nowadays, and they rather prefer to write their own proprietary clients. Besides the development and distribution costs associated, being locked to a proprietary network limits the user’s freedom. In contrast, the native clients are based on a standard specification optimized for mobile networks and mobile phones:

• Standards based means freedom for the user. You can chose between service providers, like Yamigo.
• Optimized for mobile networks means supporting maintaining a session across multiple connections, perhaps even with different IPs. Imagine entering a tunnel, loosing your connection and being able to reestablish the connection and your conversations seamlessly.
• Optimized for mobile phones means things like not draining your batteries by using operator infrastructure like WAP Push or even UDP datagrams.

When thinking Wireless Village, I am really looking at Yamigo, the largest free mobile chat service. Yamigo started in Finland in 2003, developed an OMA IMPS CSP server, formerly known as Wireless Village, and provided a gateway to the mainstream instant messaging networks: Yahoo! messenger, AIM, MSN, and ICQ. Yamigo grew to reach its first 100,000 users in 2006. Since then, there has been little to no development. Even without development and support, Yamigo currently has grown to over 135,000 users.

I strongly think the world needs a service like Yamigo. Personally, I believe we’ll look back at 2008 as the year when mobile IM finally kicked off. Unlike in the past, most operators are now open, and phones ship with better native WV IM clients installed. While some operators still remove the default IM client shipped by the manufacturer, this is becoming less of a norm. In other words, Wireless Village is silently ubiquitous, at least now that Yamigo has been dead for over a year.

It’s to time to wake up! And so I have started the onesoup service, in order to bring a WV service back live. I want the service to be useful and really simple, even if that means only partially supporting the specs. For example, at least initially, onesoup will just be a gateway to the existing networks, and there won’t be any “onesoup network”, meaning no groups, no search, etc.

My goal is to make the experience of using instant messaging on your mobile phone as easy and streamlined as possible. Onesoup will provide automatic registration, and you will be able to access your instant messaging network seamlessly without requiring downloads or complex setups.

I am just starting coding and setting up this blog as I walk through the implementation. I’ll be setting up a mailing list for folks that might be interested in this service, e.g. as private beta testers (since we’ll need to test with a lot of phones!).

Comments or suggestions are highly welcome.