BuddyPress.org

I’m not sure how those plugins in particular work, but here’s a solution that worked for me with the plugin More Privacy Options: https://buddypress.org/forums/topic/more-privacy-options-private-blogs-and-activity-streams

The same principle can probably be applied to your case. Figure out how your plugins are recording fine-grained privacy options, and then adjust the code at the above link to match.

With BuddyPress being used now by/for different interest groups from colleges to niche organizations to purely social networking, etc. there is no doubt that there would be different opinions regarding importance of the friends component vis-a-vis groups component.

I’m surprised in the first place that the friends component could even be considered for deprecation since that’s a popular feature. How about a switch to enable or disable the friends component? In one install, e.g. for a professional organization, they don’t need “friends” and prefer “groups.” In another install, for a social club, they’d like “friends” and “groups.”

It would be great if we see categorization of friends (as Bowe mentioned above) as it makes a lot of sense and extend it so that you could send a message only to Friends-Family or send a message only to Friends-CollegeBuds.

However, should the friends component be deprecated, I would request devs to expand Groups component with a user function to have the ability to privately categorize the people within a Group he/she belongs. e.g. Group-Hiking-Friends, Group-Hiking-Pros, Group-Hiking-CollegeBuds, Group-Hiking-NeedsMoreTraining.

hola, sorry guys – wish i’d get an email notification every time someone had a bug with this theme. anywho, i’ve moved all the project files to google code at http://code.google.com/p/avenuek9-bp-theme/ where I have several FAQs and patch files available.

*please note* that bp 1.2 will improve things dramatically by adding a boatload of new features, which includes theming. if you go to testbp.org you’ll see how the default theme has changed. consequently, the avenuek9 theme will change accordingly near BP 1.2 release.

if you are not running bp 1.1.x on a development server (with the avenuek9 theme), please hold out on theming your installation, as it may become a royal pain in the arse once you upgrade. also, if you need any additional help, i usually respond better to private messages (because they fire off a notification to my personal email account saying that i need to bug squash )

I can see how it might be good tokeep friending, but give the option not to use it. I hate it when Ning takes away features …

Just in general I don’t like the idea of any features being taken away …

If friending gets taken out in 1.3, then I’ll stay with Buddypress 1.2 …

We should be thinking about extending the BuddyPress framework and not deprecating major components at this time …

Not sure why JJJ wants to remove the “friending feature” in favour of the “following-feature”? Can we not have both ? …

I am worried Buddypress will fall into the trap of trying to be everything to all people and will become a bloated mess. For my projects I need a coherent, reliable core before I need any more features – forums, events, galleries, enterprise features, ecommerce, …

It’s great the developers are rethinking friending, how it can make more sense in the Buddypress context. If Buddypress can come up with a different approach, logically tied into groups and (micro)blogging, that could really set BP apart from Facebook, Ning, etc. Less is more!

JJJ’s proposal already is the best of both world imho (yes, we can have both!):

1. Deprecate “Friends” component code into a separate downloadable plugin that can still be used exactly like it is now, just not part of the core anymore.

2. Merge friends functionality into private “user” groups so that developers can choose to ditch the “friends” model if they want …

3. “Friends” would replaced with the core ability to “follow” peoples activity, and for your activity to be followed by others …

This is also a next step in the evolution in web friending, from classic Friendster/Facebook -> Twitter following -> following/friending with more context in groups and blogging (not just based on 140 chars brain farts).

Absolutely agree with Windhamdavid btw!

@Bowe

setting up different group types is fairly easy. You just have to attach some groupmeta to the group, that basically let you add as many types as you’d like. Then you just check the metadata to figure out what type of group you’re in. Using the groups API you can then add different functionality for different groups.

I’ve written a types-plugin for one of my sites. It doesn’t have an interface, though. The 3 types I needed are hardcoded into it, so it’s really not suited for a release at the moment. There’s also a lot of more stuff, like a shopping cart, part of that plugin. So, I’ve stripped the functions needed for group types out (hopefully al of them).

First we need to add the addtional fields to our registration form:

function sv_add_registration_group_types()

{

?>

<div id="account-type" class="register-section">

<h3 class="transform"><?php _e( 'Choose your account type (required)', 'group-types' ) ?></h3>



<script type="text/javascript" defer="defer">

jQuery(document).ready(function(){

jQuery("#account-type-normal_user").attr("checked", true);

jQuery("#group-details").hide();

jQuery("#account-type-type_one,#account-type-type_two,#account-type-type_three").click(function(){

if (jQuery(this).is(":checked")) {

jQuery("#group-details").slideDown("slow");

} else {

jQuery("#group-details").slideUp("slow");

}

});

jQuery("#account-type-normal_user").click(function(){

if (jQuery(this).is(":checked")) {

jQuery("#group-details").slideUp("slow");

} else {

jQuery("#group-details").slideDown("slow");

}

});

});

</script>



<?php do_action( 'bp_account_type_errors' ) ?>

<label><input type="radio" name="account_type" id="account-type-normal_user" value="normal_user" checked="checked" /><?php _e( 'User', 'group-types' ) ?></label>

<label><input type="radio" name="account_type" id="account-type-type_one" value="type_one" /><?php _e( 'Type 1', 'group-types' ) ?></label>

<label><input type="radio" name="account_type" id="account-type-type_two" value="type_two" /><?php _e( 'Type 2', 'group-types' ) ?></label>

<label><input type="radio" name="account_type" id="account-type-type_three" value="type_three" /><?php _e( 'Type 3', 'group-types' ) ?></label>



<div id="group-details">

<p><?php _e( 'We will automatically create a group for your business or organization. This group will be tailored to your needs! You can change the description and the news later in the admin section of your group.', 'group-types' ); ?></p>



<?php do_action( 'bp_group_name_errors' ) ?>

<label for="group_name"><?php _e( 'Group Name', 'scuba' ) ?> <?php _e( '(required)', 'buddypress' ) ?></label>

<input type="text" name="group_name" id="group_name" value="" />

<br /><small><?php _e( 'We suggest you use the name of your business or organization', 'group-types' ) ?></small>



<label for="group_desc"><?php _e( 'Group Description', 'scuba' ) ?></label>

<textarea rows="5" cols="40" name="group_desc" id="group_desc"></textarea>

<br /><small><?php _e( 'This description will be visible on your group profile, so it could be used to present your mission statement for example.', 'group-types' ) ?></small>



<label for="group_news"><?php _e( 'Group News', 'scuba' ) ?></label>

<textarea rows="5" cols="40" name="group_news" id="group_news"></textarea>

<br /><small><?php _e( 'Enter any news that you want potential members to see.', 'group-types' ) ?></small>

</div>

</div>

<?php

}

add_action( 'bp_before_registration_submit_buttons', 'sv_add_registration_group_types' );

Then we have to validate things and add some usermeta when a regitration happens:

/**

* Add custom userdata from register.php

* @since 1.0

*/

function sv_add_to_signup( $usermeta )

{

$usermeta['account_type'] = $_POST['account_type'];



if( isset( $_POST['group_name'] ) )

$usermeta['group_name'] = $_POST['group_name'];



if( isset( $_POST['group_desc'] ) )

$usermeta['group_desc'] = $_POST['group_desc'];



if( isset( $_POST['group_news'] ) )

$usermeta['group_news'] = $_POST['group_news'];



return $usermeta;

}

add_filter( 'bp_signup_usermeta', 'sv_add_to_signup' );



/**

* Update usermeta with custom registration data

* @since 1.0

*/

function sv_user_activate_fields( $user )

{

update_usermeta( $user['user_id'], 'account_type', $user['meta']['account_type'] );



if( isset( $user['meta']['group_name'] ) )

update_usermeta( $user['user_id'], 'group_name', $user['meta']['group_name'] );



if( isset( $user['meta']['group_desc'] ) )

update_usermeta( $user['user_id'], 'group_desc', $user['meta']['group_desc'] );



if( isset( $user['meta']['group_news'] ) )

update_usermeta( $user['user_id'], 'group_news', $user['meta']['group_news'] );



return $user;

}

add_filter( 'bp_core_activate_account', 'sv_user_activate_fields' );



/**

* Perform checks for custom registration data

* @since 1.0

*/

function sv_check_additional_signup()

{

global $bp;



if( empty( $_POST['account_type'] ) )

$bp->signup->errors['account_type'] = __( 'You need to choose your account type', 'group-types' );



if( empty( $_POST['group_name'] ) && $_POST['account_type'] != 'normal_user' )

$bp->signup->errors['group_name'] = __( 'You need to pick a group name', 'group-types' );



if( ! empty( $_POST['group_name'] ) && $_POST['account_type'] != 'normal_user' )

{

$slug = sanitize_title_with_dashes( $_POST['group_name'] );

$exist = groups_check_group_exists( $slug );

if( $exist )

$bp->signup->errors['group_name'] = __( 'This name is not available. If you feel this is a mistake, please <a href="/contact">contact us</a>.', 'group-types' );

}

}

add_action( 'bp_signup_validate', 'sv_check_additional_signup' );

And then we set up the group for the user (there are some constants in this function, so you’ll need to change that):

/**

* Create custom groups for skools, biz and org accounts

* @since 1.0

*/

function sv_init_special_groups( $user )

{

global $bp;



// get account type

$type = get_usermeta( $user['user_id'], 'account_type' );



if( $type == 'normal_user' )

{

// Do nothing

}

elseif( $type == 'type_one' || $type == 'type_two' || $type == 'type_three' )

{

// get some more data from sign up

$group_name = get_usermeta( $user['user_id'], 'group_name' );

$group_desc = get_usermeta( $user['user_id'], 'group_desc' );

$group_news = get_usermeta( $user['user_id'], 'group_news' );



$slug = sanitize_title_with_dashes( $group_name );



// create dive skool group

$group_id = groups_create_group( array(

'creator_id'	=> $user['user_id'],

'name'			=> $group_name,

'slug'			=> $slug,

'description'	=> $group_desc,

'news'			=> $group_news,

'status'		=> 'public',

'enable_wire'	=> true,

'enable_forum'	=> true,

'date_created'	=> gmdate('Y-m-d H:i:s')

)

);

// add the type to our group

groups_update_groupmeta( $group_id, 'group_type', $type );



// delete now useless data

delete_usermeta( $user['user_id'], 'group_name' );

delete_usermeta( $user['user_id'], 'group_desc' );

delete_usermeta( $user['user_id'], 'group_news' );



// include PHPMailer

require_once( SV_MAILER . 'class.phpmailer.php' );



$mail = new PHPMailer();

$mail->IsSMTP();

$mail->Host = SV_SMTP;



$auth = get_userdata( $user['user_id'] );

$profile_link = $bp->root_domain . '/' . $bp->groups->slug . '/' . $slug . '/admin';



$message = sprintf( __( 'Hello %s,



we have created a group for your business or organization. To get more out of your presence on Yoursitenamehere please take some time to set it up properly.



Please follow this link to fill in the rest of your profile: %s



We wish you all the best. Should you have any questions regarding your new group, please contact us at support@yoursitenamehere.com.



Your Yoursitenamehere Team', 'group-types' ), $auth->display_name, $profile_link );



$mail->SetFrom("support@yoursitenamehere.com","Yoursitenamehere");

$mail->AddAddress( $auth->user_email );



$mail->Subject  = __( 'Your new group pages on Yoursitenamehere', 'group-types' );

$mail->Body = $message;

$mail->WordWrap = 75;

$mail->Send();

}

}

add_action( 'bp_core_account_activated', 'sv_init_special_groups' );

When you write a group extension we’ll have to swap the activation call with a function like the one below to be able to check for group types.

/**

* Replacement activation function for group extension classes

*/

function activate_type_one()

{

global $bp;

$type = groups_get_groupmeta( $bp->groups->current_group->id, 'group_type' );

if( $type == 'type_one' )

{

$extension = new Group_Type_One;

add_action( "wp", array( &$extension, "_register" ), 2 );

}

}

add_action( 'plugins_loaded', 'activate_type_one' );

The last thing we need to do is add our group type names to group and directory pages:

/**

* Modify the group type status

*/

function sv_get_group_type( $type, $group = false )

{

global $groups_template;



if( ! $group )

$group =& $groups_template->group;



$gtype = groups_get_groupmeta( $group->id, 'group_type' );

if( $gtype == 'type_one' )

$name = __( 'Type 1', 'group-types' );



elseif( $gtype == 'type_two' )

$name = __( 'Type 2', 'group-types' );



elseif( $gtype == 'type_three' )

$name = __( 'Type 3', 'group-types' );



else

$name = __( 'User Group', 'group-types' );



if( 'public' == $group->status )

{

$type = sprintf( __( "%s (public)", "group-types" ), $name );

}

elseif( 'hidden' == $group->status )

{

$type = sprintf( __( "%s (hidden)", "group-types" ), $name );

}

elseif( 'private' == $group->status )

{

$type = sprintf( __( "%s (private)", "group-types" ), $name );

}

else

{

$type = ucwords( $group->status ) . ' ' . __( 'Group', 'buddypress' );

}



return $type;

}

add_filter( 'bp_get_group_type', 'sv_get_group_type' );



/**

* Modify the group type status on directory pages

*/

function sv_get_the_site_group_type()

{

global $site_groups_template;



return sv_get_group_type( '', $site_groups_template->group );

}

add_filter( 'bp_get_the_site_group_type', 'sv_get_the_site_group_type' );

It’s quite a bit of code, but it should get you started. This hasn’t been tested with 1.2 btw.

1. If I remember right, Jeff’s BP Privacy Options Plugin will allow the user to make profiles private. Just need to wait for the plugin upgrade for BP 1.2

2/3/5A. cosmic buddy theme – I would suggest asking Brajesh, the theme author about how to do that

5B. Yes you can create a Sitewide/global navigation bar in your blog’s themes, by using WPMU’s native switch_to_blog and restore_current_blog functions. Therefore, if you want the navbar of main site (blog_id_1) to be shown in you sub-blogs, you add the code below to your blog’s theme’s header.php

<ul id="nav"

<?php switch_to_blog('1') ?>

//copy the code from header.php of either bp-default/bp-sn-parent theme

//or the code used in main site plus any customized links you added in main site

<?php do_action( 'bp_nav_items' ); ?>

<?php restore_current_blog(); ?>

</ul>

You’ll get the correct URL’s which point to main site’s respective BP components.

I agree.

I would definitely not want the feature of “friending” with somebody to disappear. This feature is essential.

Ususally I am very happy when I do get a friendship-invitation, and this is a very important psychological factor as well.

First you need to “friending” with somebody, only after that you are able to “sort” your friends into different “Friend Groups” (like putting friends into different folders e.g. family, work, girlfriends, etc.) and also being able to make those “Friend Groups” either public, private or hidden.

Whether you “follow” your friends or whether you follow other people (who are not your “friends”), is a totally different story and a different feature.

Not sure why JJJ wants to remove the “friending feature” in favour of the “following-feature”…. ?

Can we not have both ?

Having the option of setting certain “Friends-List” to be “public, private or hidden” would be great. So I can set a certain “Group of Friends” to be hidden from other “Group of Friends”.

Not sure if Jeffs “Privacy-Plugin” is capable of doing this ?

I love the idea of as an admin, creating a relationship between profile fields (not necessarily required ones) and groups. In fact, I was scouring around my new 1.2 install hoping this feature was already live I see it as a good way to get folks involved in their specific demographic while always having the ability to leave the group if they want.

I see this as an option when defining a group, keeping the current public/private options intact, just adding another criteria or ‘group profile rule’.

I guess the “Group-settings” (public, private, hidden) would give an additional level of Privacy-Options for “Friends” if we go with the idea of Andy and JJJ.

So I can set a certain “Group of Friends” to be hidden from all my other friends.

That would be a very needed feature !

For example you are running a website for a niche-company-directory:

so the user will have friends at his suppliers and at his customers. But I am sure he does not want his customers to know who his suppliers are and vice-versa. This would be also the case at other niche-websites, like dating-websites, etc.

Just speaking strictly from a software design standpoint, calling someone’s friends a group does not make sense.

A friendship is a direct relationship between two people. It is a one to many relationship which is handled by using a lookup table that points back to the user table. It is just about the fastest possible relationship that you can have in RDBMS because both keys point back to the users table and the optimization of that query is killer if you have the right indexing. The only faster one would be a self join, for instance Bob is Jane’s spouse, which requires no lookup table.

A group however, is a one to many relationship, which is handled with a lookup table that acts as a bridge to a third table that holds the groups data. This is much different when it comes to querying. If friends are just Bob’s private group, it is going to make querying for relationships between two people very convoluted in many situations, especially where a fourth, fifth table or more is involved. There will be round tripping for data and/or nasty DISTINCT queries in many cases where it would not otherwise be necessary.

I think a lot of what Mike says is quite sensible, but my impression, reading what JJJ posted above and at the trac ticket, is that there would be next to no change in the way that the friend relationship works from the user point of view. Viewing a list of my friends, for instance, would be the same as it currently is. The difference is behind the scenes: the friend list is really the member list of a special kind of group (where ‘special’ entails private, stripped down, etc). While it might technically be true that, for instance, Mike’s friends would be a member of the “Mike Pratt” group, that’s not how it would be represented on the front-end of BP.

From a developer’s point of view I very much like the idea of merging components where possible, both to streamline the core BP code and to make extension easier to do.

A small thought about how it’d have to work. Currently if A requests membership in a private group, an entry is written to bp_groups_members = 0. When the group admin B approves membership, it changes to 1. If the current symmetrical model of friendship maps onto group membership, the second step – admin approval by B of A’s friendship request – will have to write another entry to bp_groups_members, this one making B a confirmed member of A’s friend group.

I am personally not a fan of taking it this direction (with a few caveats depending on where it goes)

@Peter – Yes, Facebook burned “friending” into the lexicon and made a mess of things as far as that definition goes. But it’s here and it’s what we have to work with. Not sure it would be wise to try and break the momentum 300mm users already understand. Now, expanding on the idea is another thing altogether.

We should start with what a “friend” means/should mean in the BP environment. There is overlap of the concept with Groups, but a major distinction, too that keeps me from supporting this shift you describe. If we expand the friend concept in its current manifestation, I think we’ll be better off.

Yes, @jjj friends are just groups of users. But that doesn’t make them Groups. Groups are organizations around a topic/idea. I think if you try to include an aggregation of users into that model, you will blur the lines as to confuse everyone. Since I don’t want being a friend of me being the same as being a member of the “Mike Pratt” group, you will force developers to have to change everything to make it look like the old process, or do it yourself. Is there really that much gained by you in the process? I mean, so much of the group functionality may not be necessary in a personal group.

Re the “it’s like Twitter following” it’s not either/or there. “friending” requires acceptance on the befriended’s part. Following does not. Admittedly, it would be great for BP to allow for a following kind of capability so I can keep tabs on those whose activity I care about but aren’t really “friends” with.

What is the filtering issue you speak of? On 1.2 I can look at activity of My friends or My groups and it works great. What BP needs, I think, is expanded friend functionality. Ie friend grouping a la facebook style so I can filter my ever growing list of friends into like groupings e.g. Family, etc. I’d even do it on buddypress.org and list @jjj @andy @jeffsayre etc into a group to follow what the sage’s all have to say. In this new concept, I will have to create a group for them? but they will already be in my “friends” group?

One thing to consider – the new Update functionality, in effect, already gives each user his own forum. A threaded conversation can already happen there and it’s centered on that user. If you are truing to make it a private one, then revamp the message system to allow me to send a private internal BP message to a group of friends (need that part too) and have it be a private threaded conversation/message. It’s dangerous to allow me to make it like you suggested

“Not only is it a group of people that I know, the people I’ve added to that group now can talk back and forth to one another because I’ve added them as a “friend.”

It gives the ability for someone to interact more personally with someone to whom they never initiated contact. Perhaps just adding a friend “type” ie “follow” would be very useful. It is the type that doesn’t require acceptance on the followee and the followee’s activities are visible according to their own set terms.

In summary, I think we keep Groups as topically focused “clubs” or “associations” that have members, content and activities and then each person has relationships with other users on the site. Some are “friends”, some they just “follow” with added functionality like grouping (pardon the use of the word), mass messaging (based on permissioning), etc

I have a network of web entrepreneurs. It’s hard enough to get them to create blogs and actually use them. OK, that’s not only BP’s fault of course, but “full invested writer/bloggers” will set up their own blogs – I’m also a journalist, I would never write/blog in someone else’s network.

I think more advances are necessary to take it beyond this where users can contribute more content without having to be a full invested writer/blogger.

That’s why I need to come up with an external blog feed-in solution. Currently stuck in upgrading my theme… I also like the microblogging suggestions.

And Groups has limitless and unique opportunities; dynamic groups with lots of content within a private social network/community.

My worry:

Will Buddypress eventually target schools, companies, trade associations, sports clubs, etc.? Or even become enterprise ready? Or will it stay a more limited play thing for insider groups of dedicated blogging geeks with a lot of free time on their hands?

I HOPE that BuddyPress does not become a member aggregation site where, the more people, the more successful a site is “perceived” to be. That to me is the game that Ning is playing. Why in the world woulu Buddypress want to be another Ning?

I agree. That model is dead. I believe the concept of “private social networks” is different. Jeff’s privacy component is essential – haven’t had the chance to test it yet.

But there should be opportunities for low threshold content creation and communication and I would develop them around (micro)blogging. Again, I have mixed feelings about the addition of old-fashioned forums.

I do see the potential. As I said earlier in this thread:

That’s why I believe Buddypress has a lot of potential. It’s a social network, but with a strong content publishing angle.

I’m absolutely not advocating copying Facebook etc. I’m a big believer in the idea of “private social networks”. And I actually think that adding old-fashioned forums dilutes the blog logic that should be Buddypress’ main strength.

Groups has enormous potential and seems to be pretty unique.

But imagine Buddypress being used by schools, companies, trade associations, sports clubs, etc. That is a very different audience from the experienced WordPress bloggers in the Buddypress development community.

I’d ultimately love to see things go in that direction, and have been sifting through code the past few days thinking of how to get more red in the trac than green.

However, if this was the case, and activity had a component scope and a serialized array of return values, then you could replace private messaging with a threaded activity stream that only the users involved in that thread can view. You could send activity to multiple groups at a time, or only 1, or all of your groups, or the entire site, or any other registered components serialized set of values that mean whatever they mean.

You can almost replace the notifications class all together too, because if you take a count of the number of activities a user has directed at them and store it in usermeta, when the user returns if that number is higher, there’s your total notifications. Filter those new activities and now you can see how many of each. Actually, the code already exists within both WP and BP to do this.

In that regard, the activity stream does start to replace core communication components like forums, private messages, status updates, notifications, and the wire. At that same time, BuddyPress becomes less about separate components with their own API’s and classes and subsets of functions, but more about creating new methods for users to interact with each other in specific scopes of communication.

You could take things like twitter lists and make them work both ways, where you could send a message/comment/update/picture to only specific users instead of only viewing tweets from users. You could create an endless array of ways and names for collaborative tools to develop the platform from within the platform. It’s basically the blog post_types concept attached to people’s activity instead of re-categorizing blog posts.

The way to further develop groups would need a whole new topic, but I’ve got some ideas for that too.

@mrmaz, what you propose is the fundamentals of how I’ve approached my development before finding WP; start with small basic classes and work my up in functionality. There very easily could be a basic “bp_component” class where every new component just extends off of that, and sets the needed vars and assigns the needed functions accordingly.

@ron/@maz@andy, I think that’s the way to go, and not unlike what already happens in terms of how activity gets in there.

I do like the idea of private messages going in there too… Huh.

Is it possible Andy that you just made one component to eliminate all the others? haha! I mean really if components can register themselves, then there’s no need for an activitymeta table, since the very act of interacting with an activity stream is in itself an activity. Think of the traditional facebook like/dislike setup. When I “dislike” a comment, that creates an activity that I disliked it, which is attached to the activity item I disliked.

It’s rather genius in a way. Huh again…

@trevorscottcarpenter, there’s three ways I can immediately think to do this…

1. Create a custom group component that isn’t a “forum.” Extend out the Group API to include a new sub component specifically that does what you want it to.

2. Create a plugin for BP forums to allow for “private” forum topics. Have it hook into the activity filters and actions and stop those processes from happening so they don’t appear in the site wide activity. This doesn’t prevent non-group members from interacting with the topic however.

3. If you’re okay with having the entire group forum be “private” but need the groups to be “public” then check if a user is a group member before displaying the forum. If not, create a message and redirect them to group root.

My take is that a public group is public. The group activity shows on the site wide activity stream because of that. You must be a group member to post an original update in the group, but you do not have to be a member of the group to leave your comment on something that is openly public.

A private/hidden group is different, the activity will not show on the site wide stream, so you will need to be a member to comment or even see the activity when you visit the group.

I think for now it’s going to be too messy to try and start auto-joining people or thinking about permissions even further. Not to say that this won’t be thought about in greater depth after 1.2.

I’m not sure exactly how to handle the syncing of forum replies and blog post comments with the activity stream. I don’t want to make the original source redundant. It may be worth considering disabling comments on these items and instead providing a link to be able to comment at the location of the original content.

You know you’ve made it when… LOL

I would highly recommend against closing off the private messaging system or even allowing it as an option. Being able to message someone you are not friends with is a HUGE use case in my opinion. Crucial even. I wouldn’t give users the option to set it to friends only. Or at least… I would like the site admin to have the ability to disable that option.

Personally… I despise CAPTHCA. Don’t pass your problems off on your users. Like websites that say “Best viewed in” or “Set your screen size to”… etc. Any solution must be invisible to users. I’ve heard of people using javascript events (mouse click for instance) as an alternative. Sounds good to me. Here’s something I found with a quick Google search.

http://www.webdesignfromscratch.com/javascript/human-form-validation-check-trick.php

Alternately… you could use a simple math question… like as in example. LOL

http://farm3.static.flickr.com/2174/2268237733%5Fcda4a1dbb3.jpg?v=0