Facebook Chat: you are doing it wrong.

A lot of people uses Facebook’s Chat without thinking about it. As I am a XMPP guru, I know it is based on some kind of XMPP. Together with some friends I am doing a little project right now: a game which will send game statuses and other information via XMPP. We thought it would be fun if we allow using the Facebook Chat account for that, too.

As I wrote some time ago, XMPP is just XML and you can easily extend it adding own XML data. So instead of sending an instant message with code like

<message type="chat" to="john@example.com" id="aaaa0">
  <body>Ohai! How's the weather?</body>
</message>

you could also transfer some data:

<message type="chat" to="john@example.com" id="aaaa1">
  <mygame xmlns="http://example.com/my/namespace">
    <action>fire</action>
    <target x="13" y="20" />
  </mygame>
</message>

That makes it really easy to use XMPP for such things.

Our idea

After we discussed that, we decided to use XMPP. To prevent users from seeing the stuff we send in their own clients we decided to

set the client’s priority to -128 to prevent our client from getting messages which are not relevant for the gameplay
send all game relevant messages directly to the resource, not just the JID – sending it for example to john@example.com/myGameClient instead of john@example.com to make sure our gameclient gets the messages and not the client with the highest priority
using type="normal" instead of type="message" in our <message/>-stanza, because the game-state-exchange is no conversation

Facebook’s XMPP is no XMPP

After we wrote down some specs, we wanted to test our XML stanzas. So we added two facebook accounts to Pidgin, opened a XMPP console and had some fun.

Surprise! Pidgin can connect to Facebook!

Yeah, it’s true. You can really use Pidgin’s XMPP plugin to connect to the Facebook Chat. The username is just your Facebook username, the server is chat.facebook.com and the password is your usual Facebook password – Facebook authenticates using some customized SASL authentication.

Chatting works.

Let’s take a look what Facebook is sending:

<message from="john@chat.facebook.com" type="chat" to="jane@chat.facebook.com">
  <body>Hello you Facebook contact!</body>
</message>

That looks pretty much like XMPP. That’s cool. Now let’s try to

Change the type from “chat” to “normal”

As I wrote above we wanted to use type="normal" instead of type="chat" for our messages. So we tried to send

<message type="normal" to="jane@chat.facebook.com">
  <body>Hello you Facebook contact!</body>
</message>

Fine. That actually works – the message was sent, we got no error and the other client showed us a notification for incoming messages. That’s what we got:

<message from="john@chat.facebook.com" type="chat" to="jane@chat.facebook.com">
  <body>Hello you Facebook contact!</body>
</message>

Huh? We sent the message using type="normal" and got back a type="chat". Wow, seems like Facebook just reads the <body/> part and kills the rest, huh? Okay, that’s no big deal for us, we could deal with type="chat". It’s more important to send the messages exclusively to the game client so let’s try

Sending a message to a XMPP resource

Again, we sent a message using the XMPP console:

<message type="normal" to="jane@chat.facebook.com/testpidgin">
  <body>Hello you Facebook contact!</body>
</message>

As you see, we defined a resource the message should be sent to, testpidgin in this example. We clicked “send” and Pidgin beeped. But surprisingly, the webchat beeped, too and the smartphone connected to that Facebook account made some vibrations. Yuck. What are they doing? It just doesn’t matter which resource you specify, every message will be sent to every device, no matter if the priority is low or not. It’s broadcasting everything. But okay, let’s try

Sending custom data

That’s the most important point as we need to send some data for our gamestate. So we sent

<message type="normal" to="jane@chat.facebook.com">
  <body>Hello you Facebook contact!</body>
  <mygame xmlns="http://example.com/my/namespace">
    <action>fire</action>
    <target x="13" y="20" />
  </mygame>
</message>

Guess what we received?

<message from="john@chat.facebook.com" type="chat" to="jane@chat.facebook.com">
  <body>Hello you Facebook contact!</body>
</message>

Wheeeee. No data, just the <body/> part. That’s horrifying.

Federation

Not much to say about that point. Facebook just kills any server-to-server communication, so you cannot add non-Facebook contacts and it’s not possible to chat with Facebook contacts using a non-Facebook account.

Result

So, Facebook’s XMPP is unusable for us. We are not really sad about this as we all have real XMPP accounts, but it could be more fun if we could use Facebook. Too bad they have no full XMPP support, I’m sure they would make some users happy with that.

Google Talk

It’s funny. Google offers XMPP, too, it’s called Google Talk and is well integrated in GMail, Android and some other stuff. Guess what? It just works. Google supports different chat-types, resources, custom data/namespaces and even server2server.

You can authenticate with your Google Mail address and your Google password, you can manage the Roster (XMPPs contact list) using the usual <iq/>-stanzas, talk to people on other servers and send custom data. Yay. So our “game” will have Google Talk support. :-)

Posted on 2012-05-06. 1 Comment. Tagged with #facebook #technologies #xmpp

XMPP - A little introduction

Recently I worked on a little project and I wanted to control a special device remotely. I am using XMPP for my daily chats and I had in my mind XMPP is extendable and so I decided to use XMPP for that.

Unfortunately my knowledge of XMPP wasn’t that huge, so I read a lot about that protocol. I ended up reading the RFCs 6120, 6121 and 6122

I got a lot of input and I had some long telnet-sessions with my XMPP-server. ;) As I’m sure I cannot remember everything in a year, I’ll write some blogposts describing XMPP a bit.

XMPP? What is it?

XMPP is short for Extensible Messaging and Presence Protocol and that’s what it is. XMPP is a decentralized system for sending messages around the world. That’s pretty cool as you can set up your own chatting server – privacy wins. (You know, I’m one of the coders and supporters of Diaspora* – it’s decentralized, too.) All data are XML – easy to use and easy to expand.

How XMPP works

XMPP is a decentralized network. Because of that, there are Server-to-Server-connections and Server-to-Client-connection. I’ll only write about stuff regarding the Server-to-Client-connections as I don’t want to write a XMPP-server.

XMPP’s user names look like email-addresses: user1@example.com – in that example there is a user1 on example.com. user1 is able to connect with guys from other servers, so user1@example.com can chat with user2@foobar.com.

XMPP is able to handle multiple logins with the same user at the same time. So you could leave your PC logged in, take your smartphone to the balcony and continue chatting outside. The differentiation is getting done by “resources”. A resource could be “balcony”, “android”, “pc” or whatever. You cannot use a resource multiple per user, of course.

Imagine you are outside and chatting with your android. It would be nice if you can receive all the incoming stuff at your phone, your PC should continue idling around, huh? That’s why there are priorities in XMPP. It’s an interger between -128 to +127. The server should deliever the messages to the client with the highest priority.

A basic XML-snippet

Let’s take a look at a very basic thing – let’s send a message to a friend over XMPP:

<message type='chat' id='123abc123' to='user1@example.com'>
  <body>Hello my friend!</body>
</message>

That is awesome, huh? Let’s analyse it a bit. I think there’s no need to explain what the opening <message> does. But let’s have a look at its attributes:

type: In our example it’s set to chat, because we want to send a direct message to another user. Other possible values are
- error: You’ll see this when something goes wrong. Every client should provide an error-dialog for that.
- groupchat: A message which belongs to a groupchat. Groupchats are not supported by default, they are an extension, I’ll write about it in another post.
- headline: Similar to chat, but that will be delivered to all available resources, ignoring the priority.
- normal: It’s like chat, but out of the context of any conversation. The client should provide an interface which allows the user to reply a message, but it should not log anything.
id: The id is used for tracking any response and/or errors in relation to the message you just send. For <message/> and <presence/> stanzas an id is recommended, for <iq/> stanzas it’s required. An id has to be unique – usually the id gets incremented.
body: Contains the message. :)

That’s enough for a little introduction. ~~More to come soon.~~ Right now, I am way too busy to write further posts about XMPP. Sorry for that.

Posted on 2011-09-24. 0 Comments. Tagged with #technologies #xmpp