Why use XMPP?

What XMPP has to offer

We believe that XMPP, the engine best known for its instant messaging capabilities, can serve as a solid foundation for the new social web. There are several similarities that can be leveraged:

  • A unique identifier called Jabber ID or JID e.g. alice@wonderland.lit in a familiar e-mail like format
  • A profile with basic information about you (in the shape of the upcoming Vcard XML spec & avatar)
  • A list of friends (the so called roster)
  • A means to share events of individuals (called Personal Eventing Protocol or PEP)

A tremendous advantage of XMPP is that in its very nature it tackles security issues that are not straight forward to solve in the web world. Since all traffic is routed through the server and the identity of that server can be validated with signatures issued by Certified Authorities, end users do not need to worry about complex things like signatures to establish secure communication. Like in the email world the trust is at the server level: the server is expected to behave according to several rules.

Another advantage is that XMPP has been designed to send all messages in real-time using a very efficient push mechanism. Existing web or polling based mechanisms are often making many unnecessary requests introducing network load and are not real-time.

Finally XMPP is already a distributed social web in its own right for the purpose of chatting. With several subtle modifications it could very quickly become a full fledged social web with substantial critical mass.

What XMPP is still lacking

To realise our vision the XMPP foundations would need to be extended and complemented with the following elements:

  • Activities: the core elements shared on social networks. OneSocialWeb uses the ActivityStrea.ms standard for this purpose. This is the de-facto standard and a 1.0 has already been released.
  • Fine grained access control: we wanted to enable both public-oriented Twitter-like social nodes as well as more private-oriented Facebook-like social nodes. For this we thought it essential to include fine grained access control at a protocol level. With fine-grained we mean that end users have precise control on who can see or do what: for activities on a per activity basis, for profiles on a field per field basis. This is not only about viewing rights, you could also delegate editing or updating to third parties e.g. you could allow a location provider to update your location.
  • Subscriptions: we allow anyone to subscribe to another’s activity, profile or relation updates again with fine grained control e.g. maybe you only want to get photo’s or blog posts from someone. This is to keep the user in control and avoid information overload. Subscriptions can be asynchronous, can be setup without friending and respect relevant access control rules. You only receive what you are allowed to see.
  • Collaboration: this is a different flavour related to fine grained access control. You can allow others to edit or work together on projects or tasks e.g. a shared photo album.
  • Relations: you can define the nature of the relationships of your friends e.g. colleague or fiancé. Relations can be confirmed or declined. We add a mechanism for anyone to validate a claimed relationship.
  • Offline message store: if a user is offline, normal chat messages are dropped. We need to add an offline message store that stores messages when you are not online. We will effectively put all messages you get in a database so end users can navigate backwards in time.

Activities, profile and relations would have to be extensible to accommodate unforeseen future use cases. All the existing standards we selected are employing extensible XML formats using name spaces.

The role of the web

Does this mean there is no role to play for the web? We believe that the web will remain a very important place to discover, consume and publish social activities as well as people’s profiles. Moreover we think that http based interfacing (e.g. via REST) for now will remain the de facto way of communicating between social web clients and servers. That is why we are including a web client for OneSocialWeb and an ideally, a REST API for client to server communication should be offered as well.

We foresee that in the future you can selectively expose activities and parts of your profile transparently through your browser when you are browsing the web. You could for instance authorize Amazon when you visit their website to read your book reviews and recommend relevant books to you without having to login.

XMPP on the mobile

OneSocialWeb enabled clients can work on mobile phones just like existing social network or chat clients on the market place, either using web based APIs or native XMPP. To offer real-time notification, it is important that the mobile platform supports background threads (otherwise you always need to have the app activated) and that the client uses native XMPP. Since XMPP has really different characteristics, we have implemented an Android client to understand connectivity issues when switching bearers or reconnecting (2G/3G/WIFI/No network), network traffic implications (XMPP by default broadcasts presence changes of your complete roster, but is otherwise highly efficient) and overall impact on battery life.