PSYC on mobile phones makes a lot of sense as soon as we have compact keywords which will make the PSYC protocol consume even less bandwidth than it does now.

Contents

WAP

psyced currently provides basic WAP support. You can use net/wap/login to check incoming messages and send messages using net/wap/msg.

WAP-Push

To tell the user that he's got a new message, wap push would be great. but since you need to send a SI or SL over SMS, it's not free... are there any other options?

sms prices start at 4c per sms to 8c.... what about a psyc-auth based paying service? ;)

UMTS etc

You may think bandwidth is no longer an issue in modern 3G+ smartphones, but in fact it still is a factor as this informational XEP from Dave Cridland shows. The really critical issue in keeping in touch with a client on a phone is the strategic amount of keepalive (pinging) and how well little bits of information manage to stay small.

One interesting conclusion Dave makes in his XEP is, "Experimentation suggests that uncompressed XMPP will never trigger the FACH state, leaping directly into the more costly DCH state. However, compression does make FACH possible, if rare."

It would probably be good to develop an optimized binary protocol to fit the size and timing requirements of smartphones the best, but as you probably know by now, PSYC's syntax is very compact and comes very close to being binary, so you might even be able to have an SMS-like conversation entirely in FACH-mode, with or without compression on the line.

Concerning pinging, PSYC's two byte pings are entirely optional, so you can just leave a TCP connection open or downgrade to UDP. IRC isn't a grand option either, as it does far too much pinging and is usually also rather verbose at it with its unnecessary server prefix.

Concerning timing, it may not be enough to just combine several packets in a single write() operation.. you should probably have a strategy also for queuing up asynchronous packets for a mobile phone over a longish time frame in order to send them all at once. Since this introduces latency and is generally not what you want for regular Internet use, this could be a feature to request during circuit establishment.

Concerning connection loss, which happens, we could think of a way to avoid a large greeting packet on reconnect. But maybe it's just more strategic to use UDP anyway?

If you're thinking about developing a PSYC client for mobile phones let us know, we'll bake compact mode for you which in the libpsyc benchmarks has proven to be a lot more efficient to process than several other options.

J2ME

A j2me client could be a slim psyc client, only able to parse _message_public and _message_private + login/logout stuff. using gprs over java shouldn't be a problem, many email apps do it...

Does anybody know if its possible to fork a j2me app into background?

A project in Java called PSYCobile was once started to bring PSYC to mobile phones. Here are some similar projects:

What's left of PSYCobile is kept at http://www.psyced.org/files/psycobile.tar.bz2

Winblows Mobile / .NET Compact Framework

<Monkey> I'm no fan of Microsoft, however, my cellular phone has TCP/IP and runs .NET applications. It would not be terribly difficult to implement a simplistic PSYC client in C# that would run on this type of mobile device. It would seem that this has some advantages over SMS, however, mobile internet services are not very inexpensive. My service is $9 (USD) per month for 2 megabytes and $0.05 per kilobyte overage. Mobile PSYC will surely become even more appealing as the cost for mobile internet comes down.

libpurple

There are several libpurple-based applications for different mobile platforms, so once we have libpsyc ready and it's added to libpurple we'd have PSYC support on these platforms as well. I've found the following software so far: on Maemo the Conversations application supports libpurple plugins and also there's pidgin for it, for iPhone I found ApolloIM, and for Android there's pidroid. The latter two probably need some more work before they're usable.