A few definitions

Before going any further, we need to define a few words - because I realized through all the dicussions I had that everyone has its own definitions of words like presence.

The word presence as we use it is how XMPP defines it. To summarize, it's a flag that will let you know if someone is online or offline. This flag is updated by the user itself and made available to others by different ways.

By device we define any piece of hardware that may update the user presence. It's most of the time a phone, but by extension it can also be the desktop browser. Maybe one day we will extend this to the whole operating system on desktop, but right now it's easier to stay in our realm: the Firefox desktop browser and the Firefox OS.

We also make the distinction between app-level presence and device-level presence. The first one is basically the ability for an online app to keep track of who's currently connected to its service. The latter, device-level presence, is the ability to keep track of who's active on a device - even if that user is not active in an application - which can even be turned off.

Being active on a device depends on the kind of device. For the desktop browser, it could simply be the fact that the browser is running and the user has toggled an 'online' button. For the phone, there are things like the Idle API that could be used to determine the status. But it's still quite fuzzy what would be the best way to use this.

Last very important point: we're keeping the notion of contacts out of the picture here because we've realized it's a bit of a dream to think that we could embed people's contacts into our service and ask all of the social apps out there to drop their own social graphs in favor of ours. That's another fight. :)

Anyways, I've investigated a bit on what was done on iOS and Android and found out that they both more or less provide ways for apps to reach out their users even when they don't use the app. I am not a mobile expert at all so if I miss something there, let me know!

Presence on iOS

In iOS >= 7.x, applications that want to provide a presence feature can keep a socket opened in the background even if the application is not running any more in the foreground.

The feature is called setKeepAliveTimeout and will give the app the ability to register a handler that will be called periodically to check on the socket connection.

The handler has a limited time to do it (max 10 seconds) but this is enough to handle presence for the user by interacting with a server

The Apple Push Notification Service is also often used by applications to keep a connection opened on a server to receive push notifications. That's comparable to the Simple Push service Mozilla has added in Firefox OS.

Therefore, building an application with device-level presence on an iOS device is doable but requires the publisher to maintain one or several connections per user opened all the time - which is draining the battery. Apple is mitigating the problem by enforcing that the service spends at most 10 seconds to call back its server, but it seems that they are still keeping some resources per application in the background.

Presence on Android

Like iOS, Android provides features to run some services in the background, see http://developer.android.com/guide/components/services.html

However, the service can be killed when the memory becomes low, and if TCP/IP is used it can be hard to have a reliable service. That's also what currently happens in Firefox OS, you can't bet that your application will run forever in the background.

Google also provides a "Google Cloud Messaging" (GCM) service. That provides similar features to Simple Push, to push notifications to users.

There's also a new feature called GCM Cloud Connection Server - (CCS) that allows applications to communicate with the device via XMPP and with client side "Intent Services". The app and the devices interact with CCS, which relays the messages back and forth.

There's a full example on their documentation of a Python server interacting with the GCM service to interact with users.

What's interesting is that the device keeps a single connection to a Google service, that relays calls from application servers. So instead of keeping one connection in every application, the phone shares the same pipe.

It's still up to the app to leverage this service to keep track of connected devices to get device-level presence, but the idea of keeping a single service in the background that dispatches messages to apps and eventually wakes them up, is very appealing to optimize the life of the battery.

Plus, XMPP is a widely known protocol. Offering app developers this standard to interact with the devices is pretty neat.

And Firefox OS ?

If you were to build a chat application today on Firefox OS, you would need to keep your own connection open on your own server. Once your application is sent in the background, you cannot really control what happens when the system decides to shut it down to free some resources.

In other words, you're blacking out and the application service will not really know what's your status on the device. It will soon be able to send a notification via SimplePush to wake up the app - but there's still this grey zone when the app is sent in the background.

The goal of the Presence project is to improve this and provide a better solution for app developers.

At first, we thought about running our own presence service, be it based on ejabberd or whatever XMPP server out there. Since we're hackers, we quickly dived into all the challenges of scaling such a service for Firefox OS users. Making a presence service scaling for millions of users is not a small task - but that's really interesting.

The problem though, is the incentive for an app publisher to use our own presence service. Why whould they do this ? They all already solved presence in their applications, why would they use our own thing ? They would rather want us to provide a better story for background applications - and keep their client-side interacting with their own servers.

But we felt that we could provide a better service for our user experience, something that is less battery draining, and that puts back the user in the center of the picture.

Through the discussions, Ben Bangert came up with a nice proposal that partially answered those questions: Mozilla can keep track of the users' device status (online/offline/available) if they agree, and every user can authorize the applications she uses to fetch these presence updates through the Mozilla service - via a doorhanger page.

This indirection is a bit similar to Android's GCC architecture.

Like GCC, we'd be able to tweak the battery usage if we're in control of the background service that keeps a connection opened to one of our servers. There are several ways to optimize the battery usage for such a service - and we're exploring them.

One extra benefit of having a Mozilla service keep track of the presence flag is that users will be able to stay in control: they can revoke an application's authorization to see their online presence at anytime.

There's also a lot of potential for tweaking how and who see this information. For example, I can decide that BeerChat, my favorite chat app to talk about beer, can see my presence only between 9pm and 11pm.

And of course, like Firefox Sync, the devices could point to a custom Presence service that's not running on a Mozilla server.

What's next ?

The Presence project is just an experiment right now, but we're trying to reach a point where we can have a solid proposal for Firefox OS.

As usual for any Mozilla project, everything is built in the open, and we trying to have weekly meetings to talk about the project.

The wiki page of the project is here : https://wiki.mozilla.org/CloudServices/Presence

It's a big mess right now, but it should improve over time to something more readable.

We're also trying to have a prototype that's up-to-date at https://github.com/mozilla-services/presence and an end user application demo that uses it, a Chat Room at: https://github.com/mozilla-services/presence-chatroom

There's a screencast at http://vimeo.com/80780042 where you can see the whole flow of a user authorizing an application to see her presence and another user reaching out the first user through a notification.

The desktop prototype is based on the excellent Social API feature, and we're now building the Firefox OS prototype - to see how the whole thing looks from a mobile perspective.

There's a mailing list, if you want to get involved: https://mail.mozilla.org/listinfo/wg-presence