On Wednesday I went to the WSG London Findability event, and I’ve finally got the last of my notes up.
The final talk was from Steve Marshall, on ‘Finding yourself with Fire Eagle’.
Steve doesn’t work on Fire Eagle but made the Python library.
Fire Eagle is a service that helps you manage your location data.
Most location-aware applications have two parts – getting the location, and using the location.
Better model – distribute the location information, but the application getting the location still has to know who’s using it.
Even better model: a brokering service. Fire Eagle sits between any ‘getting’ applications and any ‘using’ applications, and handles the exchange.
[FWIW, ‘Fire Eagle is a brokering service for location data’ is probably the best explanation I’ve heard, and I’d heard it before but I needed the context of the ‘get’ and the ‘use’ applications it sits between for it to stick in my brain.]
So how does it work? In the web application context (it’s different for desktop or mobile applications):
Web app: app asks for Request Token
Fire Eagle: returns Request Token
Web app: user sent to Fire Eagle with token in URL
Fire Eagle: user chooses privacy levels and authorises app
Web app: user sent back to callback URL with Request Token
Web app: app initiates exchange of Request Token
Fire Eagle: Request Token exchanged for Access Token
Web app: app stores Access Token for user
You can manage your applications, and can revoke permissions (who can set or get your location) at any time. You can also temporarily hide your location, or purge all your data from the service. [Though it might be kept by the linked applications.]
How to use:
1. Get API key
2. Authenticate with user (OAuth)
3. Make API call
Locations can be a point or a bounding box.
Location hierarchy – a set of locations at varying degrees of precision.
[There was some good stuff on who could/is using it, and other ideas, but my notes got a bit useless around this point.]
In summary: you can share your location online, control your data and privacy, and easily build location services.
Question: what makes it special? Answer: it’s not coupled to anything. It plays to the strengths of the developers who use it.
‘Fire Eagle: twitter + upcoming + pixie dust’.
URLs are bookmarkable, which means they can be easy to use on phone [hooray]. It doesn’t (currently) store location history, that’s being discussed.
Qu: what’s the business model? Ans: it’s a Brickhouse project (from an incubator/start-up environment).
All methods are http requests at the moment, they might also use XMP ping.
Qu: opening up the beta? Ans: will give Fire Eagle invitations if you have an application that needs testing.
I had to leave before the end of the questions because the event was running over time and I had to meet people in another pub so I missed out on the probably really interesting conversations down the pub afterwards.
Looking at their hierarchy of ‘how precisely will you let application x locate you’, it strikes me that it’s quite country-dependent, as a postcode identifies a location very precisely within the UK (to within one of a few houses in a row) while in Australia, it just gives you the area of a huge suburb. I’m not sure if it’s less precise in the US, where postcodes might fit better in the hierarchy.
I’ve also blogged some random thoughts on how services like Fire Eagle make location-linked cultural heritage projects more feasible.