[buddypress-dev] Privacy component

[Isaac Chapman]

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:

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.

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.)

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.

Even if being able to privatize content such as posts, pages, links,
etc. doesn't seem all that important, I really think end users will
appreciate being able to change the privacy settings of their profile
data.  From writing a fairly similar WPMU extended profile component,
the only real changes that are necessary to allow "simple" profile
privacy are:
a) Add a "restricted to" field to bp_xprofile_data, allowing options
a,b,c,e from question 1 above as either enums, integers, or bits (bits
are better if you want to later add options that are not subsets of
one another and hence mutually exclusive).
b) Change the xprofile_edit function to allow changing/saving the
privacy options.
c) Change the profile display code to honor the privacy settings.

(This simple approach leaves a user's email address or other
wp_usermeta data in limbo as far as profile data is concerned.)

Unfortunately, I can't share the profile component I wrote as it is
contains a lot of proprietary code, and I'm not sure how useful it
would be anyway as it has to piece together profile components and
their permissions from several MS SQL tables.  I ended up using a
combination of permission bits in my profile data table and a separate
profile permissions table to track the fields of the other MS SQL
tables containing separate profile data (mostly pre-WPMU associated
member and demographic information) along with wp_users->user_email.

Isaac Chapman

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.