This discussion is directly related to this Pull Request here
Is this a feature we want in our code?
Does anything need to be updated for Backbone.js?
Do we need to add a “group” type to our federation spec?
outdated:
Pistos code originally didn’t have tests for groups. Naturally, it shouldn’t be all that hard to write some, however I myself am a bit shaky in this area still.
How does Pistos’ code stack up, and how can we improve it?
I seem to remember that Pistos’ groups could federate. Hypothetically, what do we need to do to ensure that groups are federated?
Note: This discussion was imported from Loomio. Click here to view the original discussion.
I agree that federation is a priority, but I also think it’s good of you to start this conversation, as I think a lot of people migrating from Facebook would like to have a Groups feature. I could definitely see decentralized groups being useful for things like activism.
I think we would need to add some kind of group type to the federation spec, the question of course points back to this: do we still want to make use of D* federation, or do we want to adopt something else like Tent to build upon (that’s for our federation discussion though).
AFAIK, the javascript used for Pistos’ Groups feature would need to be completely redone in Backbone.
If we can get it from the Pistos fork without a lot of hours of work, why not, else, I think something like photos album is really more needed than the group feature.
And my point about federation is “we should use something common to everyone”. Tent.io or something else, but not something that only Diaspora understands.
Indeed, I think we just need to take a look at how other projects have implemented these things for federation, and see if there’s anything we can use.
OStatus also has groups, but I think in Diaspora* we need some more exclusive groups, too. They might not be what diaspora-users are looking for.
I was wondering if a group is (or should be) something different than an “app”. We should clarify those questions before we start to push the merge-button.
I think the feature “group” or “forum” should be implemented in D*
A private or public group is very good for organizing with friends for different projects, like the university or a football team.
Please intergrate this feature
regards
Tobi
For me as an admin of pod, group functionality
is most desired one.
I can pull out many friends from Facebook or
other SNS once it gets ready.
As Flaburgan said, photos album is also
important of course. But I think users of Diaspora
are “Innovators” or “Early Adopters” than
"Late Majority" or “Laggards”, for whom photo
album is more important.
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.
Of course, globally federated group function is better.
However, having local group feature is still better than
having no such function.
The implementation could be upgraded later.
This would be extremely useful. Having groups makes it possible to organize and to become acquainted with people with common interests, without having to know them personally first.
I agree. Groups are very important for many of us. It is exactly this missing feature that forces many of us to use Facebook instead of Diaspora.
I would suggest that groups should be a priority if we are to ‘convert’ people from fb
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.
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
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 : )
