Introduction

• Why does OSLO advocate XMPP as a server to server transport?
• Why does OSLO advocate DNS SRV for server discovery?

Problem definition

OSLO attempts to enable:

• See friends on other mobile social networks.
• their location
• their profile
• Send messages to friends on other social networks
• Search participating social networks for nearby friends

To be useful, the location information of friends should be delivered in real-time or at least every minute or two.

OSLO's remit is to share millions of users location's with millions of friends.

XMPP vs Polling

Trying to solve this with HTTP-based polling across many member sites is not going to scale. To get an idea of the limitations inherent in HTTP-based polling based systems have a look at the restrictions Twitter puts on the frequency of API calls. (last time I checked they had reduced it to 30 per hour). People moving around generate far more events than tweets. People moving around on multiple networks, even more!

A successful solution will comprise three fundamentals:

• publish-subscribe: for sharing data
• federation: to get it to the right place
• server to server security and authentication

Publish-subscribe

(also known as Pub-Sub) A loosely-coupled pub-sub setup would let users subscribe to their friend's location, when the friend moves, they get an update. The user controls who gets their location, and the level of place granularity.

Federation

Federation refers to agreeing upon on a common protocol for sharing location data. Then individual networks are free to enable incoming and outbound queries. Federation also means not relying on a single point of failure, and each company retains control of their user's location data and and more importantly it's safekeeping.

As a network operator, control is important: if you don't like a particular vendor's policy of republishing or reusing your user's location data for their benefit or their loose privacy policy? Chop them. Done. Federation mean each network maintains control.

Server to Server Security

Location, profile and chat information can be sensitive. Participating servers should ensure that this data is encrypted and passed to trusted partners authenticated using public key authentication.

Using XMPP

By using a mature protocol stack like XMPP members both solve the founding remit and gives members a framework to share other information, for example a twitter-like status messages or presence information in the future.

It puts the user in control of granting permission to their friend's to see which parts of their location and profile. Powerful for users and good for OSLO members!

The pub-sub mechanism gives our operations teams an efficient means to share updates between participating networks without the drawbacks of polling potentially 100s of member networks for updates every second.

Each network still maintains their user's identity. They can use Open-ID if they want to authenticate users that way. The user-generated content, location and friend-graph lives on, and is displayable only by that member network.

The XMPP protocol may be unfamiliar to some it's gained adoption at the core of networks (Facebook Chat) and from end user applications like Sesmic's comment system and is the right protocol for to be building a scalable location and message sharing future on.