BuddyPress.org

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

It should appear. Is the blog set as private?

The group component can be disabled; but how to only allow PRIVATE GROUPS where the groups forums are also not created in bbpress (and visible) ?

Edit: Just noticed that there is a plugin to do this: https://wordpress.org/extend/plugins/bpgroups/

I’m aware of the hakam00 thing. If akismet looked at BP private messages to see if they were spam, we’d also need to build in an area for people to go and ‘unspam’ the messages.

actually as private messages were not in WordPress, there is no akismet filter on its content, compared to posts and comments… maybe someone can add this to the posting actions ?!… it’s just 2 lines of code.

Is there not a way for users to mark spammers and draw them to the admins attention as such?

The user hakam00 in this website is a desperate spammer … how many desperate lonely geeks does “Tina” think “she” will scam on this site?

Presumably “Tina” comes from Romania or Nigeria?

See below:

Subject: Hello.

“Hello.

My Name is Tina I was impressed when i saw your profile buddypress.org and i will like you to email me back to my inbox so that i can send you my picture for you to know who i am.i believe we can establish a long lasting relationship with you.

In addition,i will like you to reply me through my

private e mail box for more introduction

Thanks,waiting to hear from you soonest.

Tina.

Please write to my inbox so that i can send you my picture.”

According to your project’s requirements, why do you absolutely need to develop a wiki ? I understand that you want easy writting facilities so why not using blogs ? Of course, there would be a lot to build in the group’s front end but at least you can use WP’s core functions.

1 – link a blog to a group, maybe using group meta (and make it private if needed) and give group users certain rights on blog.

2 – build a front-end tool for groups to be able to view, add pages and create content

3 – the post revisions could be useful to have full history of the page

Of course, work has to be done on user’s roles and capabilities to be able to view revisions and edit contents as non admin users.

This is just an idea, I don’t know if this could match your requirements.

I have the same issue. Private group, initial group image upload is fine. Can’t update image. Please see the linked screenshot:

http://bestagentblogs.com/bpgroupavatar.png