[buddypress-dev] Data Portability and Microformats
sublick at gmail.com
Thu Apr 3 04:55:03 GMT 2008
It's probably premature, but for "fine grained access", OAuth might be
something to look into. I think it fits into the data portability
discussion by defining a common protocol for services to request
protected data. A quick visual overview can be seen here:
On Wed, Apr 2, 2008 at 9:19 PM, Joseph Scott <joseph at randomnetworks.com> wrote:
> 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
> 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
> buddypress-dev mailing list
> buddypress-dev at lists.automattic.com
More information about the buddypress-dev