[buddypress-dev] Privacy component

[Justin Ball]

I try to hang out in the IRC channel during the day.  I think that
going forward this is an important piece so let's chat more on how to
implement the ideas.

Justin

On Tue, Apr 15, 2008 at 5:15 PM, Andy Peatling
<andypeatling at automattic.com> wrote:
> 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
>
>
>  _______________________________________________
>  buddypress-dev mailing list
>  buddypress-dev at lists.automattic.com
>  http://lists.automattic.com/mailman/listinfo/buddypress-dev
>