[buddypress-dev] Privacy component

[Andy Peatling]

On 14-Apr-08, at 4:39 PM, Isaac Chapman wrote:
> I guess this is mostly for Andy and/or Matt...
>
> I would like to contribute to buddypress by creating a privacy
> component which would allow people to set content to only be viewable
> by certain other people.  While WP is a very open platform and is
> great for sharing all its content, "social networks" usually allow
> their users to set up their own walled gardens based on who is defined
> as a friend, friend of a friend, being a part of a group, etc. If this
> is something that would be appropriate for BP, I have a couple of
> questions:

Contribution is encouraged, so thanks for putting yourself forward. I  
know that Justin Ball is also interested in contributing in this area,  
so lets see how we can put our collective heads together on this one.  
I'll be in IRC all day tomorrow - #buddypress on Freenode. Lets  
discuss how we can get this component moving forward.


> 1. How fine-grained should the privacy options be?  Since it seems I
> read something every week or so about some social network offering
> more fine-grained control over privacy options (to be fair, it is
> usually Facebook making an about-face after changing something
> private-by-default to public-by-default and recoiling from user
> backlash), this seems like a good place to consider both the existing
> BP framework and potential future BP enhancements. As an example,
> while I've never looked at XFN in depth, will XFN potentially be used
> as a basis for determining BP friendships?  To start off with, I think
> the following non-mutually-exclusive options should be available as
> they correspond with what I hopefully understand BP's capabilities:
> a) Public
> b) Logged in WPMU users
> c) Logged in friends
> d) Members of specified groups
> e) Nobody (really only the content creator, but "nobody" is probably
> less confusing to most end users)
>
> Potentially a f) friends of friends - kind of a sql nightmare in
> having to join the bp_friends table several times to itself to search
> for permutations of initiator_user_id and friend_user_id.

I'd like to see fine grained privacy as it gives the user the greatest  
level of control. However, I saw a talk by Chris Messina here at the  
Open Web Vancouver conference today. He mentioned only 25% of Facebook  
users have ever looked the privacy options page. As much as giving  
users fine control over their privacy, it also needs to be simple,  
otherwise people won't understand and/or use it.

I like the idea of tagging, and then giving the option to apply  
privacy settings to those tags. This allows you to be as fine grained  
with privacy as you want. These tags could be applied to friendships,  
blog posts, photos etc. Using XFN is an option and perhaps using XFN  
defined relationships as pre-defined tags? Currently I don't  
understand this area well enough either, however.

We could also provide generic options such as you mentioned, "Public",  
"Only My Friends", "Logged in Users" for those members who aren't  
concerned with fine grained control.


> 2. What existing and potentially future planned types of content can
> be privatized?  Items in the posts tables seem like a no-brainer.
> Either extended individual profile pieces of data or possibly entire
> extended profile groups seem like they should also allow to be
> privatized, as this would allow for someone to set something like a
> phone number or the "contact" group to only be viewable by friends
> instead of people intentionally leaving some fields blank (phone
> number, email & home addresses, etc.) to prevent identity theft or
> potential harassment. (As changing profile privacy settings should be
> on the same admin page as changing the actual profile data, the
> xprofile_edit function would have to be altered to support this.)

Just off the top of my head:

Profile data, profile data groups, blog posts, pages, links, photos,  
albums, wire posts, status updates, groups joined...


> 3. Answers to the above questions will go along way in determining the
> best methods for storing/accessing privacy data, but do you have a
> preferred method of storing this data?  The seemingly normal WP method
> would be to store it as a serialized array, and that can be easily
> done by adding a "restricted_to" or similarly named field to each
> table that contains something to be privatized (this wouldn't
> currently work on allowing bp_groups privacy settings on a user by
> user basis).  Another method that wouldn't alter the existing WPMU
> schema would be to use a bp_privacy table, and while this makes
> intercepting, parsing and altering sql queries potentially more
> troublesome, it does have the advantage of allowing setting
> permissions on arbitrary data that doesn't neatly correspond to
> setting row level security on existing data such as user_email from
> wp_users or other non-extended profile data in wp_usermeta.

This should be discussed. How does the existing privacy plugin that  
Andrea mentioned work?


> P.S. It might be worth adding an sort_order type of field to the
> profile tables so the rows will be displayed in a consistent,
> definable order that isn't dependent on the order the fields were
> inserted.

Agreed, I'll add this in.


Andy