Ready for personal presence solutions?

Mike Gotta had a dream: a presence aggregator service on every Windows workstation. If Microsoft could execute on this excellent idea, this would bring them back to the forefront of the individual applications scene.

As in most disruptive changes, the issue will certainly not come from the technology side. What Mike calls a "headless presence client aggregator" is nothing more than a publish/subscribe broker where address handles are used as topics... I think that technically, it can be implemented in no time. If this service is aggregating presence information at a client level, the required processing power and memory footprint can be kept very low. A documented API would allow both applications and "watcher" clients to subscribe or publish information to the common presence aggregator, ending up in a fully layered architecture that could benefit any application running on the workstation. The secret here would be to keep it simple.

The unknown lies in the incontrollable urge Microsoft always exhibit to "control the world" when adding feature to its flagship products. For this aggregator to succeed, it would have to be open…

• If this presence aggregator imposes a particular communication protocol, such as the RTC flavor of SIP/SIMPLE, then the adoption would be severely impaired. On the contrary, if the aggregator is open to other communication protocols, and provide by default both an RTC and an XMPP transport, Microsoft would be sending a very strong signal to the industry.
• If the rivalries between different Microsoft line of products were ironed out and they agreed to use this service rather than creating their own version of a presence aggregator, they would certainly be sending a strong trust signal to their user base. And as the API would be publicly documented they would not be accused of creating an unfair advantage for themselves.

In the end, there are many "if" for a somewhat obvious and rational solution. This period of the year is always full of dreams and whishes. In this case, I am certain the model would work, but would Micosoft be rational and open?

Technorati Tags: Presence, Antecipate

Maps of every country unite!

Some time ago, I was researching XMPP presence indicators that could be embedded into a web or blog page. This is how I came across Jobble, a Google maps and XMPP presence mashup. I knew of other similar services, such as Jabber World Map, Jabber Google Map and Talk Maps. They all provide the same kind of information: a map with the presence state representation of online XMPP users. For some reason, I prefer the way the Jobble site presents the information. But it is only a matter of taste.

As I was toying with these different services, it appeared to me that they were used by different demographics, which were themselves geographically concentrated. For example, Jobble, which is a Polish project, has a vast majority of subscribers from north-eastern Europe. The same applies to Jabber World Map which is coming from the Netherlands. Talk Maps has a slight majority of users in Europe, but overall users are thinly spread. Curiously, north-american users don't seem to fancy this kind of service…
My second observation was that those of my contacts using these services were scattered on several separate maps. I would have liked to have them on the same map instead. This is how I thought of federating XMPP maps.

Putting people on a map is a way to make them feel closer, and somehow participate in a feeling of community. But when these communities do not intersect, the chances to communicate and establish new relationships remain low. I have discussed earlier why a closed community would ultimately be less sticky than an open one, and looking carefully at these services shows they somehow act as closed communities. I think that the choice of registering to a particular map service must only be governed by the features that can be derived from the user presence, and not from the presence collection itself. For example, someone may prefer the way Jabber World Map show online users when the mouse hovers above a symbol, other the traditional point and click approach of Google Maps found in Talk Maps. Furthermore, someone may want to develop a similar service using Yahoo flash based maps, to be able to add some overlays.

Unfortunately, the ways these services are implemented today only lead to a walled garden result. Each service is built around its own data store and does not communicate with the rest of the world. Furthermore, they only allow static geo-location mapping, leaving out mobile devices or traveling users. Thinking of it, it is not that difficult to modify these services and turn them into distributed geo-location providers. The base features I would expect of such services are summarized bellow:

• Single registration and management point. The options chosen for my geo-location information using a particular service may become available to other similar services without forcing me to register with each of them individually.
• Static and dynamic geo-location data support. I want to be able to specify either static longitude and latitude values for a fixed workstation, or have the service pick up this information dynamically from a particular client.
• Privacy and information propagation control. It may look strange to mention privacy amongst the expected features, as putting one's presence on a map is already revealing a lot. But I would expect the service to provide a way to control the propagation of these data outside the service through an appropriate combination of white and black lists.

Looking at possible implementation options, I believe we have to keep the current approach which exposes the service through a presence enabled bot. It has the immense advantage of being well understood by the average user.
As a first step, the bot would need to be modified to understand the Personal Eventing (PEP) extension notifications. This will cater for dynamic geo-location updates. As PEP implementation progress, the service will automatically get access to dynamic geo-location information as they are set on the end user device, and will be able to display it on the map along with the user's static data.  From an end user standpoint, this would also simplify the fine grain tuning of which piece of information is made available to the service directly at the PEP level.
The bot could also be adapted to support PEP subscriptions. This would be appropriate in case the user's home server or the user profile does not allow an automatic subscription to PEP when someone subscribes to the user's presence information.
Finally, the service itself would have to expose a user geo-location node as specified by the publish/subscribe XMPP extension.  It would not be necessary to implement a full fledged publish/subscribe service, but rather make the service understand only the appropriate subset dealing with the http://jabber.org/protocol/geoloc namespace. Another map service interested to get geo-location information would then subscribe to this node and receive any published modification.

<message from= "map.montague.net" to="map.capulet.com">
  <event xmlns="http://jabber.org/protocol/pubsub#event">
    <items node="n48ad4fj78zn38st734">
      <item id="a1s2d3f4g5h6bjeh936">
        <geoloc xmlns="http://jabber.org/protocol/geoloc" xml:lang="en">
          <country>Italy</country>
          <locality>Verona</locality>
          <lat>45.44</lat>
          <lon>10.996</lon>
        </geoloc>
      </item>
    </items>
  </event>
  <addresses xmlns="http://jabber.org/protocol/address">
    <address type="replyto" jid="romeo@montague.net/orchard"/>
  </addresses>
</message>

Another possible approach would be to make the service itself support presence subscriptions and have the geo-location information implemented in a PEP node.  This way the relationship between two map services would be entirely presence driven, enabling added control through presence states. For example, there would not be notification toward a service which does not appear available. This is important in period of maintenance, or can be used as a way to throttle down heavy traffic. Presence would also be used to propagate end user's availability states.

<presence from= "map.montague.net" to="map.capulet.com">
  <show>away</show>
  <addresses xmlns='http://jabber.org/protocol/address'>
    <address type="replyto" jid="romeo@montague.net/orchard">
  </addresses>
</presence>

The end result would be a distributed geo-location information aggregation that could be leveraged through a standard and open protocol. Several local aggregators could be built by geographically close communities, but see their reach extended to the Internet as a whole because of the distributed design. From an end user stand point, there is not lock in, as it is possible to choose a service on the feature set offered and move to another service implementation without being forced to use yet another address handle. The combination of service based and PEP based filters would ensure a good level of privacy control.  And in the end my presence and geo-location information as seen by Jobble will be reflected on as Jabber World Map, Jabber Google Map and Talk Maps without forcing me to add a bot in my contact list for each different service.

Technorati Tags: XMPP, Jabber, Presence, Geo Location, Publish subscribe, Social network, Antecipate

XMPP.fm

The latest announcement of an XMPP based tool to support music fans communities got me thinking how easy this can be implemented by putting together the proper XEPs. Let us consider how to implement an XMPP internet music radio similar to Last.fm. Obviously we would want to put some "social" focus into it. So the scope is simple:

• Broadcast music to anyone joining the service, even on a temporary basis.
• Provide a music recommendation system.
• Provide discussion spaces amongst listeners.

From a protocol standpoint, the basic extensions we would need to provide this type of service are MUC for the community part, and PEP for the announcement part, obviously complemented by the user tune extension.

A very straightforward implementation route would be to create a presence enabled service to which any users could subscribe. The service will expose a number of "stations" implemented as MUC rooms corresponding to musical subjects of interest for the en users. So you may have rooms such as acoustic, alternative, ambiance, classical, dance, dark, experimental, folk, funk, groove, hip-hop, instrumental, jazz, lounge, metal, pop, punk, rap, reggae, rock, ska, techno, world, [add your own genre here]… To add the required "social" trend, one can imagine a system where users are able to tag and rate the music pieces and rooms are automatically created and added from these user preferences.

…kind of a lite social network system, featuring chat and commenting throughout…

The service "identity" is provided through some kind of DJ bot. End users subscribe to the presence of the bot, and are also automatically subscribed to the bot's personal eventing notifications. The bot also request to be subscribed to the user's tune events. Whenever a user come online, then it will receive XEP-0118 notifications from the bot describing what is currently playing in each active room. Obviously each notification will be augmented to include the URI of the corresponding room, to allow creating a "stations" list for the user to choose from.

Tuning to a station boils down to joining the associated MUC room, providing instant conversation between music lovers with similar tastes. These MUC room are augmented to allow direct presence subscription in the case end users prefer to tune directly to specific musical genre. Every "station" has its own DJ bot to which participants in the room can make suggestion as to the next piece of music to be broadcasted. The DJ bot is also in charge of notifying the room participants of the currently playing piece. It does it by simply posting notification to the room and relies on the standard MUC mechanisms to take over the distribution. This has the advantage of having the "station" past program automatically handled through the room history. The notification will be extended with the information about the physical connection URI in order to enable listening to the current track using the user’s workstation features.

Scrobbling tracks is directly available when the user set's its own user tune state. The notification is sent to the service DJ bot for collection and update of the appropriate statistics.

Additional “social” features could be implemented at each “station” level through the appropriate use of mood and activity publications and notifications. If participants are also able to publish their current room information through XEP-0194, the service could be enriched to provide what Wikipedia describes as:

The most-used community feature within Last.fm is the formation of user groups between users with something in common (for example, membership of another internet forum). Last.fm will generate a group profile similar to the users' profiles, showing an amalgamated set of data and charting the group's overall tastes.

I have already mentioned the lack of interest by the web 2.0 crowd in leveraging XMPP killer features. As one can see from the above quick jotting down, many of the puzzle pieces are readily available. In addition, they can be used from standard XMPP clients supporting MUC and PEP, which will be mainstream this year end. Those wanting to add all the bells and whistle of a multimedia UI can do so by building a flash based client with embedded audio and video players, and they will be ready to compete in the Media 2.0 broadcasting space without much technology investment. XMPP has reached a stage where a large number of applications can be built from its existing features set. It is still just a matter of imagination and creativity…

Technorati Tags: XMPP, Jabber, Chat, Flash, Publish subscribe, Social network, Antecipate