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, AntecipateLabels: Geo Location, Presence, Publish Subscribe, XMPP
