[buddypress-dev] Data Portability and Microformats

[Joseph Scott]

On Apr 2, 2008, at 5:21 PM, Andy Peatling wrote:

> One thing I haven't added to the BuddyPress site yet is how we are  
> going to handle data portability.
>
> This is a fairly hefty topic and I've heard a wide range of  
> different ideas. I'm not completely set on an absolute direction  
> for BuddyPress in this area yet. It is however something that is  
> very important, and much needed in the social networking space.
>
> These are my thoughts so far after having discussions with various  
> people:
>
> - Data needs to be as easy to get out as it is to put in.
>
> - Sharing of data between BuddyPress installations should be as  
> easy. You should be able to pull in data from one BuddyPress  
> installation for use in other installations.
>
> - There is no central information "hub" with BuddyPress. The DiSo  
> project envisions using a basic WordPress installation as a place  
> where you add your information to share with other networks. What  
> if BuddyPress could utilize this, and pull in as much information  
> from this source as possible when you first register? A BuddyPress  
> installation could periodically check this source and ask if you  
> wanted to import new information.
>
> - The use of Microformats when rendering information so that it can  
> be utilized by other non BuddyPress sources.
>
> - The ability to completely export all of your data in 'X' format.
>
> - The use of Gravatar to implement a shared profile picture library  
> across all networks.
>
> - The ability to finely tune privacy settings, and the creation of  
> data access level groups. This would give you the ability to pick  
> and choose the amount of data available to specific sites.
>
> Lets discuss this area in more detail. I really want to hear  
> people's thoughts and ideas on how we can make BuddyPress as  
> distributed and open as possible.


In my ideal world I'd be able to manage all of my profile/social data  
in WordPress with fine grained control over who can do what with the  
data.  Similar to the way the Flickr application authorization works,  
it would be nice to have LinkedIn (just one example) contact my blog  
asking for data.  I can then approve it and specifically list what  
data it can read and write.  Instead of polling for new data,  
LinkedIn would be able to push updates (that I've authorized) back to  
my blog.

And there's no reason why this would need to be a one way thing.  If  
I change something in my profile that I've granted LinkedIn read  
access to, no reason why I shouldn't just push that data out to  
LinkedIn.

This doesn't have to be limited to traditional profile data either.   
The social graph data could also be passed back and forth.  If  
someone who only uses LinkedIn makes a contact request in LinkedIn  
and I approve it, that "relationship" could be pushed back to my blog  
(assuming I allowed LinkedIn to do that).

I used LinkedIn as an example because many people are familiar with  
it, but in this scenario WordPress could not only be a profile/social  
data server, but a client as well.  My WordPress blog could contact  
Bob asking for access.  Bob can then approve my blog and specify  
which data I can read or write and I can do the same on my blog.   
This way when I change my email address, my blog goes out and tells  
Bob's blog about this change and vice versa (assuming both blogs had  
the correct permissions to do so).  A decentralized profile/social  
data network.

Fine grained access settings is a major feature here.  I might want  
to share my mobile phone number with Bob, but not LinkedIn.

--
Joseph Scott
joseph at randomnetworks.com
http://joseph.randomnetworks.com/