This spec defines a desktop service for announcing user geo location and also a component for aggregation of this announcements to be displayed on the user's desktop


In out days may users are constantly on the move, moving from project to project (physically) or from meeting to meeting in other towns. To let other users know where I am an announcement service could be helpful, having announced my current or future geo location other users may interact with me in the same place in the real world.

Use cases

Tom is currently in Munich and made a new appointment with a client at Stuttgart, he makes this appointment in Evolution. Tom would like to have the geo location of this appointment announced as soon as the appointment begins.

John is in Stuttgart, at some point in time his desktop notification for geo location pops up and notifies him that Tom is in Stuttgart starting at 08:00 and until 18:00.

Paul wonders where Georg is and opens up his desktop notification application to see the history of received geo location announcements.


This spec covers A. the architecture, B. desktop notification application and C. interfaces to other applications.


A. Architecture

The geo location service is based on a publish-subscribe infrastructure [1]. Every user participating in the service is required to have an account on a geo location serivce providers server. Any user willing to receive geo location announcements subscribes to the publishing users account. The desktop notification component may store received announcements for local exposure or retransmission.

B. desktop notification

The desktop notification component is a GNOME [5] based application that shows received geo location announcements to the user in an unintrusive way. The user may configure how to display the announcements. Received announcements may be stored locally.

In addition to the receiving aspect, the desktop notification component is responsible for sending geo location announcements to the server infrastructure. For security reasons the geo location announcements may be encrypted.

C. interfaces to other applications

A number of differnet desktop applications may provide data that relate to my geo location, e.g. Evolution Calendar, a GPS daemon... Other application may receive notification or retransmitted announcements via a local messaging infrastructure like D-Bus [6].

Evolution Calendar

The Evolution [9] Calendar may use the information provided in an appointment to send out geo location announcements. To do so, Evolution make a call to the desktop notification's announcing component and emmits an announcement. The desktop notification' announcing component may process the geo location announcement to e.g. ensure privacy or add additional data. Evolution may send out announcements directly, which is not encoraged for security and privacy reasons.

a GPS daemon

Another component may have read the current GPS position from a daemon or device and is going to announce this using the geo location desktop service. To do so, the component communicates with the desktop notification's announcing component and emmits an announcement.

D. security considerations

Send out geo location announcements may be GnuPG [7] encrypted to a number of users. Privacy must be ensured by the announcing component, either by not sending an announcement or by encrypting it.


The geo location service is based on a publish-subscribe infrastructure [1]. Every user participating in the service is required to have an account on a XMPP [2] Server that supports JEP154 [3] and it's depending JEPs. Having this account the user can utilize a Simplified Personal Publish-Subscribe (SPPS) [4] node, and announce geo location information.

For the geo location service only section 6.3 'Geolocation Data Aspects' of JEP154 is used. Items published to a user's SPPS node may be GnuPG encrypted to a list of other users to provide a decent level of privacy.

A client component is required to discover where the SPPS node of a given user id, more specifically a jabber identifier [8], is.


It is proposed to implement a JEP163 [4] and JEP154 [2] compliant server component and client library, preferable using Mono or Pyhon.

Outstanding issues


Have a look at GeoClue [10]













GeoLocDesktopService (last edited 2008-08-06 16:37:48 by localhost)