The latest feature of pokenHUB is our maps widget – a mashup of Google Maps and our new Open Social widget platform. So now Poken not only displays the contact details and address that your fellow Pokenites share, but it also shows you where your friends are located – view your Poken network geographically ! It’s fun, check it out. Zoom in, zoom out, click to find out more… you get the idea.
Want to expand your network ? Find a pokenEVENT, currently represented by a purple pyramid… what ? (There’s a story, but we’re going to keep up the suspense on this one just a little longer… ) In the meantime, know that at these events you will find fellow Pokenites with whom to build your network and get to know your community.
Still wondering how Planet of the Apes fits in? Simple, your friends’ locations are represented by our beloved blue gorilla. It’s genius, hehe. We are, however, planning to eventually show other poken types as well, so hang tight if you want to see your geisha or ninja on the map.
For more info (all brilliant ideas welcome!) about building 3rd party widgets using Poken’s Open Social platform and API, developers should contact our development team at firstname.lastname@example.org.
At Poken we’ve been discussing the idea of accessing poken data via APIs inside Poken and with some of our community for a while. In theory it’s easy to do – in fact we already have an API working together with access via OAuth which we are using for testing internally at Poken.
However there are 3 things we want to get right before we open up access to our community to use the API:
- We want to make sure that we’ve addressed all the privacy concerns with allowing 3rd parties to access some or all of this data. And we want to be sure that the Terms & Conditions protect the users data from being misused.
- We want to give out some example code
- We want to make sure our documentation is good
I’ve said “privacy concerns” so I expect some of you are worried straight away so I’ll expand on this and give a couple examples:
- Your Email address and your friends email addresses. Do you want a 3rd party to have these?. Eg. with Facebook connect the 3rd party site can email your friends but only through the facebook site (the 3rd party doesn’t get the addresses themselves) and only 100 emails can be sent at one time.
- Your list of social networks. Do you want eg. one social network to be able to know which other social networks you (or you and your friends) use?. Would it be enough to restrict this in the terms & conditions that the 3rd party signs to get access to the API?
Before going into more details about the privacy concerns I think that it’s best to understand what are the applications which will use this data. Here is my list:
- a stand alone app that the user controls such as an iPhone app or a “tweetdeck” for poken. On these the user has installed the application so it doesn’t matter if this application has access to all the data the user can see when he’s logged in to doyoupoken.com
- an application running at a 3rd party site (such as a social network) which displays Poken data
- a “mashup application” which is merging poken data with other data (such as GPS co-ordinates, calendar, friend lists) – we are sure that our community will come out with far more ideas than we can ever come up with ourselves.
It’s very clear that there aren’t many issues with “stand alone” apps having your poken data as they hold the data on your computer or phone. However with 3rd party sites there may be some issues. A lot of this comes down to understanding what the Poken data is:
- is it a “business card” which you accept is our there on the internet. It maybe that you accept that most of this information can be found out (eg. at google.com or zoominfo.com) and that you are responsible for managing the security of the information that you put on the different sites (facebook, linkedin, etc.).
- is it private information which is only available to people you’ve pokened with? And they are not free to redistribute it.
At Poken we have to take the lead in understanding this but we need to listen to our community. I think that the data is a mix of public and private information. Eg. your linkedin profile is public, your email address and mobile number are private, and your skype, direct office phone number, etc. are somewhere between private and public. But different people have different views on this. Plus their view can change over time. Plus different people have different abilities to understand the granularity of this data.
So the options for opening up API access are:
- keep this data open (wrong approach because of the reasons outlined above)
- keep this data closed (safe but not what most people want). This would mean that only Poken can create applications with this data.
- open up the data with controls.
Faced with these choices we’re heading down the path of “open up the data with controls” which is nice and simple until you think about how can this be presented in a way that all users understand it. Can’t we just hop on the Open Social & Portable Contacts community and use the same controls and presentation they have?. Yes and no. We have your info and your friends info which is data which is “Open Social” data (in fact we use the Open Social data schema internally in our application). But we have data which is not the same:
- the “poken events” of people connecting their pokens where timestamp (date and time) is recorded.
Our API will present this “poken events” data in an Open Social compatible way so that the Open Social specification could be extended to include this as a “physical meeting event” or similar.
- The list of your social networks
- your phone number(s) and email address(es) etc.
In fact the most interesting things to use the API for will relate to “poken events” and the social network lists which is not Open Social data.
So in summary our challenges are
- deciding what the right controls are on the Poken data and the granularity to use for this
- presenting this in a way that is intuitive for all users
So that is background to how we are approaching the API. My next post will deal with some more concrete examples of data and API usage. Please comment!