Feature Discussion: Groups

• At first, just local implementation is enough because we can expect people in a group will register mostly at the same pod. For example, let me create a group in my pod. Almost everyone I want to invite to the groupd will not have registered on any pod of Diaspora or even never heard about it.

I'm not keen on any code being implemented which would encourage people to sign up to the same pod (or would require people to be on the same pod to use a certain feature). The distributed nature is key to Diaspora, and we shouldn't do anything which would weaken that.

Of course, a first iteration in develop could be only local, but it shouldn't be pulled into a production release until it was federated across the network.

I would suggest that groups should be a priority if we are to ‘convert’ people from fb

But Diaspora's purpose isn't to 'convert' people from FB. It's trying to be a completely new type of online social experience. There's therefore no need to ape what FB does, unless it is actually going to be beneficial for the community.

It will be beneficial for the community because people will be able to do a lot more socializing and organizing with the ability to make and join interest groups within Diaspora, to meet others of like mind.

I'm new to this conversation but I had a rough idea the other day and posted it on D* #feature and it was suggested I'd post it here also.

Now when you come to think about it, the aspect part of Diaspora works in a similar way to groups. Would it be possible to implement groups by adjusting the aspect code to allow shared/locked aspects? So when for example I add a person to an aspect it gets added to that said aspect for everyone that has joined it earlier.

And also so that these special aspects wouldn't get confused with the others they would pretty much be categorized as groups (or Aspect Groups?, or Shared Aspects?)

In other words, is it possible to reuse the Aspect logic to create a group functionality?

I am happy to see this conversation take place. Although tags are very useful and D* folk make good use of them, it is often not relevant to the topic at hand.

Likewise, when sending out a tagged post, it needs to be public in order for people I don't know -but whom I want to connect with due to common interest - to see.

I have lots of atheist friends, I'm not atheist, so sending out a post regarding my personal beliefs for all to see (Even those who aren't interested) can be rather unappealing for all involved. Also with groups there is the ability to remove fully irrelevant posts/spam that clutters the topic at hand.

I agree that the ability to put our photos into albums (maybe based on initial tag we use for it?) would be great too, but right now I am hearing more that people want groups and events.

(hope it's okay that I chimed in here) ~ Birch**

Yeah, I am also thinking about implementing group function on top of/utilizing aspect function. Things like "shared-aspect".
* If I decide to be a group owner, I create the group as "shared-aspect", and add people to the aspect. If I make post with the aspect, people in the aspect can see the post and comment as normal aspect.
* Let the aspect be automatically copied to group member's aspect. Then group members easily post with the aspect.
* Only owner can add/delete people to/from the aspect. The change should be reflected to group member's aspect automatically as well.

It's just basic framework, and I am thinking about thread title, event function, notification e-mail,etc, so I am not sure if utilizing aspect is good idea at this moment...

taro-k. I would say both would need to be a possibility. The ability to set so only owner (or owners/admins) can add people, and also, everyone can add people, for groups that need more "natural unhindered growth". (or maybe tags are more fitting for that kind of stuff...)

Another problem would be that group aspects would need to be searchable as long as group admins don't set them to private.

I have used a combination of aspect and tag to make a customized closed group. The tag of course has to be unique, so I choose something very special, and I and the others only post to the group aspect.

If we could somehow reserve some tags for groups (##-for group, ###-for closed group) and have shared aspects that are open to be edited by other people like Johannes suggest, a group could maybe be created from existing functionality?

This would at least solve the title problem T-caro :)

Use of tagging for creating groups is error-prone: a typo, a missing letter would be enough to break that construct.

Just some encouragement: Private groups is the missing feature I'm waiting on before myself and my community join D*. A million thanks to all those that can make it happen : )

As my group and I use it now: Yes it is error prone. But if you could choose the group from a dropdown menu like the aspect-dropdown, tag could be automatically placed in the bottom of the post - like the right aspect could automatically be chosen.

I think it could be useful to take what is already there: tags (whichs create a stream only consisting of concerned posts) and aspect/public (targeting only concerned users), instead of reinventing a lot of stuff. I already use a combination to create a group, and it is working.

What I do see as a problem is having tags that are not used by someone outside the group. This would pollute the group stream with irrelevant posts. I have solved this by choosing a tag that I anticipate will not be used by others. I do not know if you could reserve a special kind of hashtag like the ## and ### i propose above to groups, maybe someone else with a better understanding of the code can enlighten us.

I guess the groups could actually be below the aspects, separated by a thin line in the already existing dropdown-menu.

A sort of oldish newbie here. I know that's the contradiction/irony there but that's life as we know it :) . Forgive me but from what I understand it, aspects is a label we make on people. Say I know few friends who like football and so I can publish it only on those aspects. This somehow feels restricting the conversations.

In Groups the conversation is usually more informal and more interaction takes place. In a federated environment, this would be more interesting and dynamic as well. The possibilities are endless :)

A group based on tags has no moderation capabilities.
I realize that specialized tags is much easier because it is already here - but I do think moderation of a group is a desired feature.

@shirish You can have people in many aspects at a time. For a closed group you would post to a group-aspect, in an open group you would post public ...

@Birch Moderation as in throwing people out? If so that would happen in the group aspect Taro and Johannes talked about. Removing posts ... maybe could be a problem.

It is the combination of tag and aspect that gives group-like functionality, and most of the complex stuff would be in the aspect ... as I see it.

To long since I was in a Facebook group. What does group moderation imply.

This may/will borde on censorship. If there are people who form a group say about sexuality or bestality or nazism or something which may be obnoxious to large number of people, you will throw them out ? Wouldn't that be majoritism?

I do hope that censoring or moderation is the rare thing (the lightest touch) rather than what is being talked about here.

@shirish Moderation within the group. That means that if you create a group, you (or other designated moderators of that group) can moderate: delete posts or ban users from the group. It's censorship, but if you don't like how a group is being run, you are free to start your own.

@Brent, oh, for some reason I didn't get that. Thank you for clarifying. In that case I'm for having moderation within a group BUT with the caveat that an admin could have a group with no moderation at all . If that is also possible then have no objection at all.

Thinking about mailing list.

From the point of view of your e-mail program the mailing list is just another account, just like any other.

Similarly a (set of) group(s) might be implemented as a diaspora account that, to external pods, look exactly like any other account.

They would have to have some automated client behind them but except for the need to connect that client diaspora need not change anything.

What do you say? Are there things you would want from groups that cant be done this way?

There once were groups on Diaspora : it was only one one pod maintained by pistos who had added a group feature to D* : has the code changed too much to add the "pistos code "? Or is this code not usable because of too much change ?

@loelousertranslato the code changed a real lot, rewriting is much less effort. And if it weren't that way, he implemented local groups only, we would want them to work across pods.

I see. I was expecting that answer. Thx

@Loelo TBH, I don't remember how Pistos' groups were any different from hashtags. Maybe there was moderation? The implementation looked similar to GNU Social's. (Posts to the groups are marked with a ! instead of #.)

They also had an actual group page and you could log into that account as admin. And it showed up in its own drop down and you could search groups specifically.

It seems like everyone agrees that D* needs groups in some form. I would like to take this up (as final year project). Are tasks/bugs "assigned" to a contributor in D* dev or you tackle the problem and finally make a PR saying that you're done?

I am very happy many people got involved in this discussion after I re-activated this thread. I'd like to summarize my opinion base on everybody's discussion:

1. Implement group functionality independently (not based on aspect/tag).
   At the beginning, the implementation based on aspect/tag maybe OK and quick, but after that, for me it's obvious that we will want to add many many features exceeding capabilities of aspect/tag. It won't be sustainable. Also, it's not seamless if we decide to remake it as independent function later.

2. Quickly implement as local function with perspective of seamless upgrade to federated one in the future. Yeah, I totally agree the ideal (every communication should be federated in D*) is paramount, but also we should realize the fact we are loosing oppotunitiy of attracting users without group function. If the local group is seamless with federated one of the future, it's not problem.
   (However, if recognized skilled developer declares his/her commitment for federated function as quick as local one, starting with federated one is of course better.)

Hi @kevinmartin, it's great that you'd like to code for Diaspora.

There isn't an open issue that I can see in Github for the groups feature. There is this closed issue which basically attempted to port some very old groups code which was created for one pod, but which wasn't finished as Diaspora's code base is now so different that it wasn't really workable. Still, it might inspire a point to start from.

Have a look at our wiki article on starting to contribute, and do ask any questions you have on the #diaspora-dev IRC channel. Once you're ready, you can 'claim' the issue in Github by opening an ticket for it, or making a pull request once have some code.

Good luck, and look forward to seeing the results of your work!

Also for such a big feature I would love to see some interaction designs being posted and discussed here first, the specifics should be laid out and maybe even prototyped before too much work on code is spent.

@goob Thanks! The wiki looks very useful. I'm afraid that we cannot start right away.

@jonnehass We will definitely come up with designs and do discussions before spending too much time on the code.

Thanks a lot. I hope I can do something useful here.

@Kevin Martin - Great to hear that you will try to make this happen.

We discussed a group implementation that treated groups as multisided, basically that a group could have several aspects where its users have different permissions to read/write/invite/manage. I'll try to write a sum-up on the wiki so that we can discuss and merge ideas. :)

Okay, so here's a starter. It is hard to write everything in a proposing way, but I've tried to include most thoughts and problems. Nothing on implementation/federation yet.

https://wiki.diasporafoundation.org/Groups_feature_proposal

@Ivan Thanks a lot! I'll read it when I get time and come back with a proper plan if plan if possible

What happens if all accounts get the ability to switch group functionality on or off for each aspect?

A 'group' then would just be an aspect with extra functions turned on.
I still think we'd make special 'group' accounts, but I'm not sure we gain anything by having the software notice the difference ...

Why special group accounts??? Sounds very bureaucratic!

I think that having a special account for groups introduces new annoyances and no benefits.

By special accounts I'm just referring to the practice some of us already have of having different accounts for different things.
Like me having one for posting in Danish and one for English.
The difference (the 'specialness') is all in the users head.

I'm just noting, as it were, that I think we will see things like '[email protected]' aggregating science-groups.
But again the difference should be in the users head. NOT in the Diaspora software.

Thanks for clarifying about the 'within group' moderation.
@shirish @jakobnorregard --
Yes, I've run groups. Someone joins, ends up trolling or hating.I would like the option to toss someone like that out of a group I run.

+1

@kevinmartin - would be great to see someone working on this - thanks!

as i read all posts, i strongly agree that people who stuck on facebook are mainly stuck there because of this group organising feature ..
however, i surprisingly did not read the most easy way to archieve a group feature (in my naive thoughts at least):
.
why not take a special user class which does nothing else than re-share whatever share is coming in from connected people. So this special user class become the group itself.
.
users are in many ways functional equal to groups - you have to connect to them and than share informations. the only things needed to get this working is make this user re-share everything somebody else is sharing with him, so everybody who is connected to this fake-user/group get this stuff (without necc. have to be connected to the original sender)
privacy of this group is than given at start because the user share only with conneted user.
Their are some more benefits - but if users are not auto accepted you have to login seperatedly ...
..
however, i really would love to have some ideas how i could get this autoshare working - so you get groups for free

@Jens Viisauksena : I know nothing about D* code but your idea seems to be a very clever and simple way to implement groups.

@Jens Viisauksena, I don't understand how your "user"-groups differ from a simple hashtag.

Idea posted by @jensviisauksena is interesting, but it forces users to have one special aspect for each group - to share only with that group. Or maybe it wouldn't be a problem to implement sharing with some user's public aspects? I wonder if automatic reshare option would be a problem to implement. Also having an ability to create multiple accounts with the same e-mail address would be useful.

Using aspects/tags as groups is a little problematic, because it requires that every group member has to add other members as a contact and then create a group aspect.

Local groups have no use for me, and we shouldn't go that way, because it breaks diaspora's network distribution.

I was thinking about another way to implement groups as user accounts, somehow similar to facebook groups. Things that would need to be implemented in order to make it work include:
- an ability to create more than one account with same email
- an ability to post on people's (or groups') account "walls"
- an ability to set a default visibility of posts posted on account's wall (could be "all aspects" for private group or "public" for public group account)

@rasmusfuhse : hashtags are similar as in twitter, so public in general, the user expected function of a group will be mostly somehow of being in a closed circle (i guess)
@mikemacgirvin : things are more complicated, after some days of digging in code and functionality it become clear that public post, hashtags and user posts are fundamentaly different. while hashtags work more-or-less like in twitter and public post work like an public rss fee - normal posts work like a email from user to user.
so actually everytime you share a "limited" (socalled) post to some of your aspects, the server takes this aspects, looks who is in there and write somehow a "email" to the other pods, that have some serious implications.
** posts once sends and not deliverable will not be delivered in future (something like 3 retrys are there)
** posts are saved by its guid on other pods who than manages who can see this
** it is not possible to give users access to older posts when they join into an aspect later (that would be somehow a expected functionality of a group)
..
it seems that the reorganisation of my incoming posts only happens if i login myself (what is bad in this case, because that means we have to manually trigger this linking to get all the new posts) ... there some research is needed.
..
so actually we work on a script to get the content of a specific user (extra created) and push it as its own post (with a note of the origin)
not so clear now is how we link our "new" posts to the incoming posts - so we can delete them when incoming posts are deleted as well. (but if this wont work now its annoying but nothing so bad, since group posting will work)
the skript should have access to the database, ideal on the same server, very very nice would be if the pod user can tick it in preferences so that this skript automaticaly work for this user.
..
while we are at research at this time, it also is possible that we solve this inside the code itself, but we are not fluent in ruby, that make things difficult - but not unsolveable.
..
just to mention that there is this reshare function for public posts, but we are not sure if we can "use" this - because this works so different - if we could : we got all this later deleteable stuff for free (thats whats possible now , reshare public post with mentioning the origin and deleteable by the origin)
.
and yes, this problem that 1 email actually could only have one user is also at our focus.

I just wanted to add one important userbase of facebook Groups: Artists

There are several Groups with speedpainting topics and Groups where you can ask for constructive criticism. These groups are quite huge and very active.

I follow a lot of these groups but do not like to post anything, simply because i dont agree with facebook Terms of Service regarding Images & Copy Right.

Still these groups are the main reason i am still on Facebook. Everything else can be replaced by different services, but the active userbase in these groups is incredible.

I think Diaspora could really become popular with a better # or Groups feature which allows some moderation.

The Topics of Copyright & Sensorship & Privacy could help making it more interesting for people who want to TEMPORARY want to share work in progress Artwork.

Facebook sometimes prevents users from posting artistic nude poses for example.
Lots of reasons for peope to switch..

Hello. I don't know if I am in the right place, but I have some ideas and about a group function on Diaspora*. Please, Have a look at some of my ideas, and please pardon any typing errors. (I'm a lousy typist) I don't know such things as coding or how things work like that. But I do realize the importance of a group function. As mentioned before, Groups enable folks with a common interest to join together and participate in conversation, Image sharing, etc. about that interest. All without having to sort through other irrelevant topics in the stream. I hate to make the same comparison, but it is necessary, Facebook groups. The way they work is quite wonderful, for the most part. But I, and many others feel that FB's attitude toward user privacy, users in general, and the constant adding of unwanted fluff & filler, is becoming out of hand. I have set up a "Closed" (private) group on facebook. But I have to limit membership to under 250. Anything over 250 will result in the group privacy setting to be nullified. Plus, even in groups, users are relentlessly tracked and bombarded with ads. (unless like me, they run an adblocker) I have been searching for a clean straight-forward site for two years now. Diaspora* is almost the answer to my prayers. I say "almost" because D* does not yet have the desperately needed Function to create a secure, private group, where members can upload, post, comment, and converse about the topic. Also the creator of a D* group would need the ability to appoint administrators or moderators who can delete irrelevant or inappropriate material or posts, or members who become detrimental to group security, well being, and activity. Creating the group function would necessitate an Admin panel or dashboard where group admins can Edit headers, manage group functions, and edit group header images/logos. I do have a mockup prepared. It is just my idea of how a D* Group could look. Please pardon the crude nature of the mockup. I used Windows "Paint", and borrowed elements from my D* profile, and a header/banner image form my own FB group. Other sidebar buttons/icons I made in "Paint". Please Have a look at the image. And Please do not hesitate to give me feedback on my D* profile. I very much welcome it. So sorry for this being such a long post, but I wanted to explain in detail. I will link the image, and my D* profile now.

Thank you for your time and patience,
~JIM~
IMAGE >> https://diasp.org/uploads/images/scaled_full_ba319a59408a710e1307.png
MY PROFILE >> https://diasp.org/people/2fc96cd0a96801328d1700259069449e

@jimhoberek : You are in the right place. We know that groups are definitely a desired feature. As far as I know, someone was working on it some time ago. I don't know where is his work. Your idea seems quite good. We just need for someone to work on this, as usual :/

Hi,
It seems there are some valid ideas about groups in this thread and the only element lacking is a volunteer to convert those ideas to code.
If either of the two following stuff happen, can any of the Diaspora developers mentor the idea?

1. Hire a developer by crowd funding.
2. Get interested students to do this as a project as part of their college course.

IMO, mentors are important since the feature has to co-exist with existing code and abide to existing conventions. So, with a mentor to oversee the developments, the time required to implement can be reduced (can avoid too many trial-and-errors)

If there are mentors, we can try to make any of the above two happen.

We were having a discussion about conducting a crowd funding to hire developers to implement features that are missing (groups, photo albums etc) and I thought having a mentor would help a lot.

So, what do you say?

Checking in to see if there has been more discussion about this. Checked out a new site (to me) called minds.com and it touts as being open source, privacy centered and user controlled.. and has groups AND blogs. I really am tired of these other sites coming in as though they are something new and special when Diaspora surpasses in SO many ways.. but we really need to get the groups going. I cant code worth beans but SOMEBODY.. please help!

Birch, a lot of sites in the internet have groups as a feature. Moodle, Stud.IP, ForumBB, whatever. A lot of them are open source as well. But none of them are decentralized. That's the difference.

If you can't code check out bountysource. You can spend money for those who implement the groups feature someday.

https://www.bountysource.com/issues/7718252-implement-group-like-feature-with-modified-user-in-given-diaspora-structure-as-experimental-opt-in

Also you can spend time and creativity in creating concepts of the group feature. Create mockups, workflows and so on.

@rasmusfuhse GNUSocial is a decentralized network with groups.

I can also name a few other projects that are decentralised and have groups and that work to varying degrees with Diaspora already. But that's just a correction, not to sidetrack the discussion.

Agreed Mike, they do. And have for a while. (RM has tons of features I love)- what comes to mind is when the masses go crazy when they have found these new 'VCF' platforms that are clunky and mainly useless yet they have those little 'perks' that people really want.

Personally I think that groups are a great feature. Imagine Facebook without groups, Reddit without subreddits. It's a key feature of every social interaction. This would make Diaspora more comfortable for users.

+1 @Robert

birch they have these features because they have funding for developers who get paid to do these things full time. In the open source world we're constrained by folks that are willing to roll up their sleeves (some 0.001% of the population typically) and who see value in the feature.

I will mention that what we did for Friendica was incredibly simple to get the feature "out there" and took minimal development effort. If you saw a mention for a group account, you redeliver the post to the group members. That's really all it did. Otherwise a group wasn't any different than a social profile. It wasn't until redmatrix that we polished the feature up and gave it a full range of features and public/private permissions, group photo albums, chatrooms, cloud storage, nested groups, yadda yadda. These required a lot of additional work (about 2 man years I reckon).

I know. And I just find it shocking that because they (paying companies) have those lil bells and whistles, people flock there, even if the whole thing is a clunky mess. Diaspora looks at LEAST as good as Minds.com. Not sure who can find the time or who WANTs to find the time and put the effort to get groups going.. but it would be good.If I could help .. i totally would. runs off to RM to make a grouo

For me a group-feature wouldn't be complete if it doesn't include privacy settings like closed groups with group-admins have.

It's a real shame that after all these years, this (as well as chat) still has not been implemented. It is hard to convince people to join given the lack of these basic features.

Its always sad so see complaints by users about features still not being implemented. Especially given the small number of active developers and the many basic features that are functioning better and better.
Be patient or start coding. :)
I know what you feel, but there's many forms of pressure that may reduce productivity. Assume people are working their hardest, on multiple projects, on a voluntarily basis out of ideals.

I'm not expecting a lot of Fb users to switch for extra features, btw. I've been using Telegram for a while, and eventhough it has the same (and more I think) features as WhatsApp it's proven quite hard just to get people to install the free app next to their current one. Of course every bit helps, but I think the best way to get people to switch is activating privacy awareness. Which I think is more of a goal then a means. So...
Protest and converse; it's no use preaching to the choir.

Is there already some kind of sum up of what definitely should be covered by the group function? Maybe we could try to determine what people expect of a simple version of groups (take a look at other SN etc.) and write it down somewhere. If someone comes up who would like to implement the feature he can refer to this 'plan'.

I haven't read any of this thread but wanted to throw my 2c in the pot.

-- VERY interested in a group/pages type of functionality similar to Facebook. Specifically, private/secret pages/groups.
-- Would crowd funding be a viable option to encourage development of this?

Q: From a developer's perspective, can anyone quantify (even speculatively) what is needed to make this feature a reality? Number of developers, man hours, etc.

Thanks! :)

OK I should have read first. Reading now. Thanks for putting up with my crap! ;)

There's a bounty for this on GitHub https://github.com/diaspora/diaspora/issues/6278