Xblaze

One of the biggest features requested so far has been Push Notification support for Xblaze iPhone. The premise:

When a user quits the app, instead of being logged out of Xfire right then, the user would stay logged in and receive push notifications when new messages arrive.

There are a few problems with implementing this feature, some technical, some legal.

First the technical limitations.

Some people may not fully understand how push notifications work. So here’s a quick overview.

There are 5 major components:

1. The provider (In this case, Xfire)
2. The notification (The new message)
3. Apple’s Push Notification Service
4. The user’s unique iPhone
5. The Client Application (Xblaze)

For push notifications to work, the provider needs to know about the iPhone, and it’s UDID (Unique Device Identifier). Without knowing the UDID of the iPhone, there’s no way to get a notification from the server to the iPhone. If the Xfire could know your iPhones UDID, it would be able to create a notification and ‘push’ it to your device. But there is no way for Xfire to know your iPhone’s UDID.

So, the first technical difficulty is that there is absolutely no way to get Xfire to generate a push notification from its root server or no way to get it from the sercver to your iPhone. They’re not going to implement it, and we don’t have any access or control to make one ourselves. To get around this, we could set up a relay server that would maintain the Xfire Session and communicate between the Xfire server and the Client, and register the iPhone for push notifications (using its UDID).

Something like this (I don’t have time to make a pretty diagram):

Xblaze Sends UDID to relay server,
Relay Server receives message from Xfire,
Relay Server forwards message to Xblaze via push notification.

Unfortunately it’s not quite as simple as just setting up the relay server and carrying on. The relay server would require that all of the communication between Xblaze and Xfire go through this server. That includes logging in, sending/receiving messages, adding friends, retrieving game info, etc.,  etc.

It would be a massive undertaking and would probably require writing a complete implementation of the Xfire server itself so that it could proxy everything that the Xfire server does.

Once again, this is very unlikely to occur as the entire Xfire protocol is still yet to be documented, which large chunks still being undefined. In order to implement the entire server, we’d need to know exactly how everything worked…

Then, after spending the huge amount of time it would take to write and test the server, there’s the logistics of finding somewhere to host it, pay for it, maintain the health of the server, not to mention the cost of the server hardware. Also the server would have to be able to cope with accommodating thousands of Xfire users. This is not something that can be lightly thrown around as a “nice to have” feature.

Then even if someone did spend all the time, effort and money on writing this hypothetical relay server, they wouldn’t be allowed to use it anyway, which brings me on to the legality of this issue.

The Xfire Terms and Conditions specifically state (Emphasis mine):

You may not authorize any third party to access or use the Service on your behalf using any automated process such as a robot (or ‘bot’), a spider or periodic caching of information stored by the Service on your behalf, without a separate written agreement with Xfire.

It is against Xfire’s Terms and Conditions to implement such a server, and it would breach your agreement with Xfire if you used a service that relayed your connection.

Xblaze and other 3rd party Xfire clients are already treading a very fine line in terms of legality, because they’re only made possible by reverse engineering the Xfire protocol. If at any moment Xfire decided that they wanted to pursue the issue of reverse engineering, they could send a cease and desist order to all 3rd party Xfire clients, and make them stop working – or they could change the protocol and lock everyone out.

If Xblaze received a C&D order from Xfire, I would have no choice but to comply, as I am technically in breach of the Terms and Conditions, as is every other 3rd party Xfire client developer.

I’m hoping it will never come to that though, but I don’t think implementing any kind of push notification support is feasible. Possible: maybe, feasible: not right now.

The next version of Xblaze iPhone will contain a major new feature that has been asked about since its release. That ferature is Clan Support.

Clan support is definitely being worked on for Xblaze iPhone and is getting pretty close to being releasable. The current implementation is currently integrating the clan as a group within your friends list, kind of like a custom friend group, but not managed by you.

I have a better way to display the clan groups (and it’ll be sexy, I promise), so don’t get attached to this method, this screen shot is just to show that clans are working so far!

You may notice the “Communities” tab at the bottom-middle of the screen. If you don’t know, Xfire don’t call clans “clans” anymore. They’re called Communities now, so that’s the official title. And that’s where the better clan (community) interface is going to go.

Hope you’re excited!

PS. At some point – when I have time – I will merge all these new Xfire features that are in the iPhone version back into the Adium plugin. I’m sorry it’s taking so long, but all my time is being used up by the iPhone version and real life.

It’s 5:08am. I’ve just committed the typing notifications code to SVN. Sleeeepy.

I’ll release an update tomorrow at some point that will include the typing notifications support.

The incoming typing notes, (those that tell you who’s typing), were simple. A few short lines of code and they were working. But the outgoing typing notes, (those that tell your friends when you’re typing), were a lot more involved. The MacFire library didn’t have a packet to represent a typing notification, so I had to write one before writing the logic to send it.

I also learned something a little odd about the way Xfire handles typing notifications. According to all the documentation I’ve read about the Xfire protocol, the typing notification packet is the same packet that contains messages and message acknowledgments. The difference between these packets is the data structure within, their IDs are all the same. With that said, the typing notification packet contains a field aptly named ‘typing’ which represents an integer.
The documentation says this is treated like a boolean, 1 for typing, 0 for not typing. So my initial inclination was to send the packet with a 1 when a user is typing, and then again with a 0 when they finish typing.
I was wrong. This caused the typing notification to keep being displayed even after a message was sent. My only guess is that Xfire (for Windows) ignores this boolean value, and just assumes that any typing note packet that arrives means that the user is typing… Either that, or the field isn’t intended to be used as a boolean. We shall most likely never know.

Good night.