Draft Issue. Groups: What are they? How they work? #625

Closed
opened 2019-07-29 14:58:10 +00:00 by lambadalambda · 28 comments

Discussion / Evaluation issue.

The topic of group support came up again on IRC. Backend-wise, the topic is rather clear. A bigger question is how groups are supposed to work for the user.

Backend issue for the thing that AP calls groups: pleroma/pleroma#656

Current state of groups on the fediverse:

Gnu Social

Groups federate. You can join groups on other servers. Posting in a group happens via putting a ! (e.g.: !cofe) in front of the group name in a post, otherwise these posts are normal posts. A user has to join a group before they can post to it.

I don't remember if there were private groups or not, and if so, how that worked. Please somebody add that info.

Posting to multiple groups at the same time is possible.

Gab

Groups do not federate. Groups have an id, name, description and banner. UI is like this.

Screenshot_2019-07-29_Gab_Social_1_

Screenshot_2019-07-29_Gab_Social

Client side, the post api is extended with a group_id. If you use that, the post is internally associated with that group. As far as I can tell, this does not federate at all, although I read on fedi that they federate the id. I can't find it in the activity json, though (https://gab.com/users/pennyfortheguy/statuses/102525197179306906.json).

Posting to multiple groups at the same time is not possible.

Misskey

[NOT CHECKED, COULD BE WRONG. WILL ADD]

Groups don't federate.

Other, non fedi

I think most people associate something different than the GS groups with the name 'groups', more along the lines of gab groups (that is, a page you go to and then you post there). Another popular feature is the whatsapp style chat group. It might make sense to call all these different expectations of users by different names in the frontend, even if they are implemented similarly on the backend.

Ideas:

  • Gab style groups: Groups (I suspect this is the thing most non-GS users associate with groups)
  • GS style groups: Federated Hashtags (They behave more like hashtags you can follow)
  • Whatsapp style group: Chat Group. Similar to Gab style groups, but map a long conversation instead of a set of thematically similar posts.
Discussion / Evaluation issue. The topic of group support came up again on IRC. Backend-wise, the topic is rather clear. A bigger question is how groups are supposed to work for the user. Backend issue for the thing that AP calls groups: https://git.pleroma.social/pleroma/pleroma/issues/656 Current state of groups on the fediverse: # Gnu Social Groups federate. You can join groups on other servers. Posting in a group happens via putting a ! (e.g.: `!cofe`) in front of the group name in a post, otherwise these posts are normal posts. A user has to join a group before they can post to it. I don't remember if there were private groups or not, and if so, how that worked. Please somebody add that info. Posting to multiple groups at the same time is possible. # Gab Groups do not federate. Groups have an id, name, description and banner. UI is like this. ![Screenshot_2019-07-29_Gab_Social_1_](/attachments/0dea7191-8165-4fb4-aba4-6acf54e01762) ![Screenshot_2019-07-29_Gab_Social](/attachments/4ecfd7c0-afcb-4bb9-b696-5ee614eabab7) Client side, the post api is extended with a `group_id`. If you use that, the post is internally associated with that group. As far as I can tell, this does not federate at all, although I read on fedi that they federate the id. I can't find it in the activity json, though (https://gab.com/users/pennyfortheguy/statuses/102525197179306906.json). Posting to multiple groups at the same time is not possible. # Misskey [NOT CHECKED, COULD BE WRONG. WILL ADD] Groups don't federate. # Other, non fedi I think most people associate something different than the GS groups with the name 'groups', more along the lines of gab groups (that is, a page you go to and then you post there). Another popular feature is the whatsapp style chat group. It might make sense to call all these different expectations of users by different names in the frontend, even if they are implemented similarly on the backend. Ideas: - Gab style groups: Groups (I suspect this is the thing most non-GS users associate with groups) - GS style groups: Federated Hashtags (They behave more like hashtags you can follow) - Whatsapp style group: Chat Group. Similar to Gab style groups, but map a long conversation instead of a set of thematically similar posts.
Member

Pleroma groups should federate

Pleroma groups should federate
Member

But how should they be moderated across instances, especially with instances blocks in place?

But how should they be moderated across instances, especially with instances blocks in place?
Owner

i still don't understand what gab groups are, but "federated hashtag" is incredibly stupid name, what normal hashtags are then? Not federated? Shouldn't you be able to subscribe to a hashtag already?

What is a "what's app style group"? I never used that, i only know telegram group chats and channels tho.

I think GS styled groups are the most intuitively understood and they work like Discord/Slack roles. I.e. like mentioning @moderators would notify everyone in that role.

How gab groups work i have no clue even looking at screenshots.

Imo groups should be like in GS with !group@server handles, but act more like a user, so that you can visit that group and see what people are posting in there, who's in, and two buttons - "Join" and "Subscribe" with one of them will just make posts appear on your TL and other will notify you about new posts. Biggest issue however would be transferring groups and such.

i still don't understand what gab groups are, but "federated hashtag" is incredibly stupid name, what normal hashtags are then? Not federated? Shouldn't you be able to subscribe to a hashtag already? What is a "what's app style group"? I never used that, i only know telegram group chats and channels tho. I think GS styled groups are the most intuitively understood and they work like Discord/Slack roles. I.e. like mentioning `@moderators` would notify everyone in that role. How gab groups work i have no clue even looking at screenshots. Imo groups should be like in GS with `!group@server` handles, but act more like a user, so that you can visit that group and see what people are posting in there, who's in, and two buttons - "Join" and "Subscribe" with one of them will just make posts appear on your TL and other will notify you about new posts. Biggest issue however would be transferring groups and such.
Member

What gab does with group_id is clever and 1 group per post is not objectionable.

The simplest is handle them like a conversation thread ("hell thread") with its own title and link in the sidebar, and some kind of join / leave / subscribe (receive notification) buttons. Twitter sort of does this with group direct messaging, which is actually a very pragmatic way of handling groups. I believe with Twitter groups, only the creator of a group can add new users, while any members can eject themselves if they choose. (This was one of the problems with hell threads, which I would call our own homebrew take on groups as much as anything else)

I agree with HJ where a group should have a syntax like !group@server . Groups like this should have an admin and URL initially. They could be treated a little like users (changeable display name, permanent URL, visibility settings) --> requesting to join a closed group should be similar to requesting to follow a private user.

An open group should allow anyone to post to them simply by mentioning the group in a message, eg including !group the same way users include #tags or @mentions now. Joining an open group should not be so different from following a user, and in fact joining should not be required for participation.

A closed group perhaps must be direct-messaged by its members to relay posts, which are then relayed on the group's feed to group members / subscribers.

If a group were to have an admin, I think a way a group can really distinguish itself from hashtags would be allowing the admin to remove posts from the group made by other posters. Maybe it doesn't delete the post from their feed but it does remove it from the group timeline. So rather than using the term "federated hashtags" I would consider "managed hashtags" ...

What gab does with `group_id` is clever and 1 group per post is not objectionable. The simplest is handle them like a conversation thread ("hell thread") with its own title and link in the sidebar, and some kind of **join** / **leave** / **subscribe** (receive notification) buttons. Twitter sort of does this with group direct messaging, which is actually a very pragmatic way of handling groups. I believe with Twitter groups, only the creator of a group can add new users, while any members can eject themselves if they choose. (This was one of the problems with hell threads, which I would call our own homebrew take on groups as much as anything else) I agree with HJ where a group should have a syntax like `!group@server` . Groups like this should have an admin and URL initially. They could be treated a little like users (changeable display name, permanent URL, visibility settings) --> requesting to join a closed group should be similar to requesting to follow a private user. An open group should allow anyone to post to them simply by mentioning the group in a message, eg including `!group` the same way users include `#tags` or `@mentions` now. Joining an open group should not be so different from following a user, and in fact joining should not be required for participation. A closed group perhaps must be direct-messaged by its members to relay posts, which are then relayed on the group's feed to group members / subscribers. If a group were to have an admin, I think a way a group can really distinguish itself from hashtags would be allowing the admin to remove posts from the group made by other posters. Maybe it doesn't delete the post from their feed but it does remove it from the group timeline. So rather than using the term "federated hashtags" I would consider "managed hashtags" ...
Author
Owner

i still don't understand what gab groups are, but "federated hashtag" is incredibly stupid name, what normal hashtags are then? Not federated? Shouldn't you be able to subscribe to a hashtag already?

I gave these different names to make it easier to talk about them. They are features that are used very differently but are all called groups. I'm sorry that my naming did not live up to your intelligence standards.

But yes, normal hashtags are not federated and you can not subscribe to them.

I think GS styled groups are the most intuitively understood and they work like Discord/Slack roles. I.e. like mentioning @moderators would notify everyone in that role.

I don't want to judge on what is more intuitive or not, but I doubt many people associate roles with groups. I can mention @moderators without being a moderator myself, for example.

> i still don't understand what gab groups are, but "federated hashtag" is incredibly stupid name, what normal hashtags are then? Not federated? Shouldn't you be able to subscribe to a hashtag already? I gave these different names to make it easier to talk about them. They are features that are used very differently but are all called groups. I'm sorry that my naming did not live up to your intelligence standards. But yes, normal hashtags are not federated and you can not subscribe to them. > I think GS styled groups are the most intuitively understood and they work like Discord/Slack roles. I.e. like mentioning `@moderators` would notify everyone in that role. I don't want to judge on what is more intuitive or not, but I doubt many people associate roles with groups. I can mention @moderators without being a moderator myself, for example.
Author
Owner

What gab does with group_id is clever and 1 group per post is not objectionable.

I disagree, it's pretty hacky and does not federate well. Also, if we want to implement gs style !groups, it would be possible (and natural) to mention several groups at once. This is not the case for private / closed groups, which makes me think that they should be a different kind of group altogether.

> What gab does with `group_id` is clever and 1 group per post is not objectionable. I disagree, it's pretty hacky and does not federate well. Also, if we want to implement gs style !groups, it would be possible (and natural) to mention several groups at once. This is not the case for private / closed groups, which makes me think that they should be a different kind of group altogether.
Owner

that reminds me to bring up the whole "intuitive ui" topic i got reminded of at work today. It's only intuitive if you're used to something like it, people kept saying that Apple makes intuitive UIs and things are easy to learn, but in reality, for me, whole thing was very counter-intuitive for me because I was used to different things and a lot of intuitive things (like gestures for instance) were very confusing and repulsive to me.

I'm used to Discord roles and at my day job we have bot-backed flowdock groups which act in similar way. You essentially can enter or leave group (depending on implementation you may need to be an admin to manage role/group) so that when someone mentions group everyone in it gets mentioned, but ability to mention role is an optional thing in discord, so we can also configure who gets to mention it. I never used GS/gab/whatsapp so I don't know how group works there but I assume it's just an entity which rebroadcasts posts by other users who post it as "group post" or mentioning the said group, so that you can subscribe to that group and see posts in it in your TL so that you won't have to follow everyone in the said group.

The use cases I see:

  1. Discord game-oriented roles, like when 3 people out of 10 play same game and don't want to mention everyone explicitly every time, instead they'd use something like @doomers or @ffxivSquad et cetera, usually more creative stuff. Good for movie nights too, i guess.
    • everyone can join
    • only joined can mention
    • everyone subscribes to it
  2. Administrative groups - @moderators @admins and so on. Pretty self-explanatory.
    • allowed users only
    • only local users can mentioned/everyone can mention
    • everyone subsribed to it
  3. Topic/location groups - think that @rf group bot Dr. Equivalent made. Stuff like people living in same place, or in same country, or like it would be possible to make !doomModding group about doom modding group.
    • everyone is allowed
    • everyone can mention (i.e. you're on in !berlin but you can still mention like hey !berlin i will be visiting next week does anyone need anything from helsinki)
    • subscription is optional, so you can follow the group instead of everyone involved, cleaning up timeline drastically.

I feel like groups should be one thing but very flexible.

Meanwhile, you SHOULD be able to subscribe/follow hashtags, right now you can only open hashtag in a separate tab or something since we cannot have multiple columns (yet) in Pleroma-FE

that reminds me to bring up the whole "intuitive ui" topic i got reminded of at work today. It's only intuitive if you're used to something like it, people kept saying that Apple makes intuitive UIs and things are easy to learn, but in reality, for me, whole thing was very **counter-intuitive** for me because I was used to different things and a lot of intuitive things (like gestures for instance) were very confusing and repulsive to me. I'm used to Discord roles and at my day job we have bot-backed flowdock groups which act in similar way. You essentially can enter or leave group (depending on implementation you may need to be an admin to manage role/group) so that when someone mentions group everyone in it gets mentioned, but ability to mention role is an optional thing in discord, so we can also configure who gets to mention it. I never used GS/gab/whatsapp so I don't know how group works there but I assume it's just an entity which rebroadcasts posts by other users who post it as "group post" or mentioning the said group, so that you can subscribe to that group and see posts in it in your TL so that you won't have to follow everyone in the said group. The use cases I see: 1. Discord game-oriented roles, like when 3 people out of 10 play same game and don't want to mention everyone explicitly every time, instead they'd use something like `@doomers` or `@ffxivSquad` et cetera, usually more creative stuff. Good for movie nights too, i guess. - everyone can join - only joined can mention - everyone subscribes to it 2. Administrative groups - `@moderators` `@admins` and so on. Pretty self-explanatory. - allowed users only - only local users can mentioned/everyone can mention - everyone subsribed to it 3. Topic/location groups - think that `@rf` group bot Dr. Equivalent made. Stuff like people living in same place, or in same country, or like it would be possible to make `!doomModding` group about doom modding group. - everyone is allowed - everyone can mention (i.e. you're on in `!berlin` but you can still mention like `hey !berlin i will be visiting next week does anyone need anything from helsinki`) - subscription is optional, so you can follow the group instead of everyone involved, cleaning up timeline drastically. I feel like groups should be one thing but very flexible. Meanwhile, you SHOULD be able to subscribe/follow hashtags, right now you can only open hashtag in a separate tab or something since we cannot have multiple columns (yet) in Pleroma-FE
Member

and 1 group per post is not objectionable.

I disagree, there is a lot of use cases where tagging multiple groups and tagging/untagging groups during an ongoing conversation is useful.

For example someone is posting in !cuteposting, but notices that Pleroma does something weird with the post, so they tag !pleroma-dev asking for clarification.

> and 1 group per post is not objectionable. I disagree, there is a lot of use cases where tagging multiple groups and tagging/untagging groups during an ongoing conversation is useful. For example someone is posting in `!cuteposting`, but notices that Pleroma does something weird with the post, so they tag `!pleroma-dev` asking for clarification.
Member

Meanwhile, you SHOULD be able to subscribe/follow hashtags

We discussed this on irc earlier. There are two ways to make subscriptions to a hashtag possible:

  1. Assign a hashtag to a particular server (e.g #mastodev@pleroma.social) . Essentially a hashtag would be a regular user that repeats all posts with the hashtag it sees. This has the benefit of actually getting all posts with the said hashtag, but is also not what the users would expect and sounds like the 3rd use case for groups but shittier.

  2. Just get all the posts with the hashtag present in the database to user's timeline. This will never work correctly because the instance has no way of knowing of all posts on the network with the said hashtag.

> Meanwhile, you SHOULD be able to subscribe/follow hashtags We discussed this on irc earlier. There are two ways to make subscriptions to a hashtag possible: 1. Assign a hashtag to a particular server (e.g #mastodev@pleroma.social) . Essentially a hashtag would be a regular user that repeats all posts with the hashtag it sees. This has the benefit of actually getting all posts with the said hashtag, but is also not what the users would expect and sounds like the 3rd use case for groups but shittier. 2. Just get all the posts with the hashtag present in the database to user's timeline. This will never work correctly because the instance has no way of knowing of all posts on the network with the said hashtag.
Author
Owner

there's the even more everyday case of posting in several hashtag-style groups at once like There's a big photo expo soon in Berlin !berlin !photography. And that's why I think that the only reason we think of them as groups is that they were called like this in GS.

there's the even more everyday case of posting in several hashtag-style groups at once like `There's a big photo expo soon in Berlin !berlin !photography`. And that's why I think that the only reason we think of them as groups is that they were called like this in GS.
Owner

This will never work correctly because the instance has no way of knowing of all posts on the network with the said hashtag.

Neither does TWKN, that's why it's called TWKN, not TWN. I don't think it matters that much anyway, but it's a neat way to filter out TWKN. I think searching all tagged posts by user is more important, masto even allows you to features some tags on your profile or something, so for instance lain could feature #dprk.

>This will never work correctly because the instance has no way of knowing of all posts on the network with the said hashtag. Neither does TWKN, that's why it's called TWKN, not TWN. I don't think it matters that much anyway, but it's a neat way to filter out TWKN. I think searching all tagged posts by user is more important, masto even allows you to features some tags on your profile or something, so for instance lain could feature `#dprk`.
Member

Neither does TWKN, that's why it's called TWKN, not TWN. I don't think it matters that much anyway, but it's a neat way to filter out TWKN

I mean, if subscribing to hashtags will indicate that you are subscribing only to hashtags known to the instance and users won't get confused by it, then I guess it is alright.

I think searching all tagged posts by user is more important, masto even allows you to features some tags on your profile or something, so for instance lain could feature #dprk.

We support the API endpoint for getting posts from a certain user that are tagged with particular tags. Mastodon does not really allow you to control featured hashtags, it just picks out the ones you post the most about, being able to pick them manually is both easier to do and sounds like a better idea to me though.

> Neither does TWKN, that's why it's called TWKN, not TWN. I don't think it matters that much anyway, but it's a neat way to filter out TWKN I mean, if subscribing to hashtags will indicate that you are subscribing only to hashtags known to the instance and users won't get confused by it, then I guess it is alright. > I think searching all tagged posts by user is more important, masto even allows you to features some tags on your profile or something, so for instance lain could feature `#dprk`. We support the API endpoint for getting posts from a certain user that are tagged with particular tags. Mastodon does not really allow you to control featured hashtags, it just picks out the ones you post the most about, being able to pick them manually is both easier to do and sounds like a better idea to me though.
Owner

as far as i understand, hashtags are still """federated""" in a sens that posts are tagged and if servers know about each other you can collect tagged posts. Groups however are attached to a certain server, which makes it all so much complicated (server needs to be known by other servers, server going down, etc) but most importantly users need to know about the "location" of that hashtag.

The beauty of hashtags is that you can just see what people are saying on some topic if they are using hashtags, the only problems are TWKN incompleteness, instance blocks and someone spinning up an instance just to flood some hashtag with trash. The thing is i doubt anyone would actually want to follow a hashtag (i.e. add them to your main TL, watching them in a separate column is a case however) due to all the possible dangers of it.

I think the biggest difference between a hashtag and a group, and reason it's called a "group" and not a "managed hashtag" or "federated hashtag" is because with hashtag you're essentially just yelling at the world hoping someone is interested in this topic, with groups - you're addressing certain people. Analogy would be:

Help i'm being mugged someone #help versus Help i'm being mugged !polis@helsinki.fi help me

as far as i understand, hashtags are still """federated""" in a sens that posts are tagged and if servers know about each other you can collect tagged posts. Groups however are attached to a certain server, which makes it all so much complicated (server needs to be known by other servers, server going down, etc) but most importantly users need to know about the "location" of that hashtag. The beauty of hashtags is that you can just see what people are saying on some topic if they are using hashtags, the only problems are TWKN incompleteness, instance blocks and someone spinning up an instance just to flood some hashtag with trash. The thing is i doubt anyone would actually want to follow a hashtag (i.e. add them to your main TL, watching them in a separate column is a case however) due to all the possible dangers of it. I think the biggest difference between a hashtag and a group, and reason it's called a "group" and not a "managed hashtag" or "federated hashtag" is because with hashtag you're essentially just yelling at the world hoping someone is interested in this topic, with groups - you're addressing *certain people*. Analogy would be: `Help i'm being mugged someone #help` versus `Help i'm being mugged !polis@helsinki.fi help me`
Owner

Mastodon does not really allow you to control featured hashtags,

image

image

>Mastodon does not really allow you to control featured hashtags, ![image](/attachments/30a06d90-5fe6-490b-93bf-ee7ec60a97e4) ![image](/attachments/7804012d-89c1-4385-9cf6-aea90e1a5a6c)
Member

Oh, my mistake.

Oh, my mistake.
Owner

for your example it would probably be like There's a big photo expo soon in Berlin !berlin #photography unless !photography is your local photography club/circle/academy/group

for your example it would probably be like `There's a big photo expo soon in Berlin !berlin #photography` unless `!photography` is your local photography club/circle/academy/group
Owner

I'm just gonna repeat myself and retract my statement that "you SHOULD be able to subscribe/follow hashtag" because i doubt anyone would want to add hashtags to their TL given the potential dangers of doing so, not to mention subscribe to them, we'll have to someone ask for it who actually needs it, meanwhile ability to "track" i.e. to display certain hashtags in FE as a link (and ability to add hashtag column) would probably be more useful.

I'm just gonna repeat myself and retract my statement that "you SHOULD be able to subscribe/follow hashtag" because i doubt anyone would want to add hashtags to their TL given the potential dangers of doing so, not to mention subscribe to them, we'll have to someone ask for it who actually needs it, meanwhile ability to "track" i.e. to display certain hashtags in FE as a link (and ability to add hashtag column) would probably be more useful.
Author
Owner

Subscribing to hash tags is a bit of a weird thing for the reasons already discussed. You never no what you'll get. Also, hash tags are not AP entities that can be followed or unfollowed, so this is more of an extra timeline, as you said.

re, intuitiveness: Yes, it absolutely depends on what you are used to, as you say. I find iPhones very intuitive as well. I don't like to talk about things being intuitive or not, but I think it makes sense to take a look at what people will probably expect. For example, Stories are very popular on snapchat and instagram, but you'd never come from the name Story to what the feature is (a set of pictures and text with an expiration date). Still, if we'd introduce Pleroma Stories, people would expect short-lived image collections and not some other feature.

Subscribing to hash tags is a bit of a weird thing for the reasons already discussed. You never no what you'll get. Also, hash tags are not AP entities that can be followed or unfollowed, so this is more of an extra timeline, as you said. re, intuitiveness: Yes, it absolutely depends on what you are used to, as you say. I find iPhones very intuitive as well. I don't like to talk about things being intuitive or not, but I think it makes sense to take a look at what people will probably expect. For example, Stories are very popular on snapchat and instagram, but you'd never come from the name Story to what the feature is (a set of pictures and text with an expiration date). Still, if we'd introduce Pleroma Stories, people would expect short-lived image collections and not some other feature.
Owner

"Groups" is already ambiguous enough, i never used Whatsapp, GNU Social nor have I ever used Gab. I expect something that connects or encircles specific people together. I can certainly say that I do not expect an implementation of ActiveDirectory even though it also fits the bill. Facebook and VKontakte also have groups I believe even though I haven't used them, and G+ used to have circles. That's probably something even more people are familiar with.

But then again if you present service summarized as "decentralized twitter" people kinda expect it to be like twitter, and since twitter doesn't have groups people probably don't know what to expect, I mean I'm still not sure what GS Groups are and how they work. So if you want something vast majority of normies are familiar with you should probably look at Facebook.

"Groups" is already ambiguous enough, i never used Whatsapp, GNU Social nor have I ever used Gab. I expect something that connects or encircles *specific people* together. I can certainly say that I do not expect an implementation of ActiveDirectory even though it also fits the bill. Facebook and VKontakte also have groups I believe even though I haven't used them, and G+ used to have circles. That's probably something even more people are familiar with. But then again if you present service summarized as "decentralized twitter" people kinda expect it to be like twitter, and since twitter doesn't have groups people probably don't know what to expect, I mean I'm still not sure what GS Groups are and how they work. So if you want something vast majority of normies are familiar with you should probably look at Facebook.
Owner

speaking of subscribing to hashtags, one thing would be nice is to follow to hashtag posted by certain users - biggest case would be japanese artists which post their art with a tag, but otherwise their feed is full of posts you can't really understand.

speaking of subscribing to hashtags, one thing would be nice is to follow to hashtag posted by certain users - biggest case would be japanese artists which post their art with a tag, but otherwise their feed is full of posts you can't really understand.
Member

What was actually wrong with gnusocial groups?

What was actually wrong with gnusocial groups?
Member

My two cents:

It seems to me the GS groups act more like email-lists then? Personally I think of groups more like how FB has them and so will most (even all) of my afk friends and I assume most people. From what I read here, I think what GAB has seems to be that, so I think we should go that way (but federated ofc).

Other non-fedi examples are Matrix and XMPP. A very nice property that Matrix groups have is that when the server where the group was originally created goes down, the group still works as long as there are members from other instances. You can also set an alias for your own instance or change the name which allows people to join even if the original instance is down. It would be very nice if we could have something similar here as this makes the groups very resilient.

And then there's also https://github.com/framasoft/mobilizon ofc. Not sure how far along they are, but there code is also Elixir (and based on Pleroma). They want a fedrated alternative to FB groups and events (which IMO are basically just groups extended with a date-time/calender thing).

My two cents: It seems to me the GS groups act more like email-lists then? Personally I think of groups more like how FB has them and so will most (even all) of my afk friends and I assume most people. From what I read here, I think what GAB has seems to be that, so I think we should go that way (but federated ofc). Other non-fedi examples are Matrix and XMPP. A very nice property that Matrix groups have is that when the server where the group was originally created goes down, the group still works as long as there are members from other instances. You can also set an alias for your own instance or change the name which allows people to join even if the original instance is down. It would be very nice if we could have something similar here as this makes the groups very resilient. And then there's also https://github.com/framasoft/mobilizon ofc. Not sure how far along they are, but there code is also Elixir (and based on Pleroma). They want a fedrated alternative to FB groups and events (which IMO are basically just groups extended with a date-time/calender thing).
Member

Hmm, One problem I see; I assume on gab that for the user side it's something like

  1. You go to the group
  2. You see the page of the group
  3. You post => it's a post in the group

However, that is not how things currently work (see also comment #624 ), so doing something like that brings inconsistency.

Another question that pops in my mind is who should see the posts? If someone follows me and I post to a public group that this person is not a member of, will they see my post? Do scopes work inside groups, and if yes, how?

Hmm, One problem I see; I assume on gab that for the user side it's something like 1. You go to the group 2. You see the page of the group 3. You post => it's a post in the group However, that is not how things currently work (see also comment https://git.pleroma.social/pleroma/pleroma-fe/issues/624#note_35952 ), so doing something like that brings inconsistency. Another question that pops in my mind is who should see the posts? If someone follows me and I post to a public group that this person is not a member of, will they see my post? Do scopes work inside groups, and if yes, how?
Member

There is also friendica groups, here is the group and here is a post mentioning a group. Both links can be fetched with curl -H "Accept: application/activity+json" to get the AP representation

There is also friendica groups, [here](https://forum.friendi.ca/profile/helpers) is the group and [here](https://libranet.de/display/0b6b25a8-895d-57fb-41b7-fbc246900720) is a post mentioning a group. Both links can be fetched with `curl -H "Accept: application/activity+json"` to get the AP representation
Owner

A bit late to the party, throwing some ideas about groups could or should work, might be unrealistic and not reasonable but read anyway

My basis started from GS groups but started diverting a lot the more I thought about it, GS groups worked to some degree but it was always kinda hidden in classic ui, not very discoverable, and they didn't really facilitate much that you couldn't do without them (which was partly because the network was so small you could read twkn regularly, but with way more noise now it makes more sense).

First of all groups should have a profile similar to any user, so you get to have a group picture, banner, name, description, buttons for join etc, settings, tabs for statuses posted for the group, lists of members, and more if it's your group or you are moderating the group (pending invites/join requests for example).

Some improvements I think our groups should have compared to what we had before:

  • private groups, not listed when someone checks your groups on your profile, all posts are visible only to group members, makes it easier to discuss stuff with more people you just don't want to be completely public without manually addressing everyone. this is a bit difficult if you can mention multiple groups, what happens when you mention a public group in a private group post? (actually what happens when you mention a public group in a dm?)
  • proper invite and join request system, should be controllable if anyone can join a group freely or not.
  • group posts on timeline should be pretty clear that they're addressed to a group and not just a !group at the beginning of a post (honestly being able to address just a single group starts to sound more and more sensible despite its drawbacks)
  • perhaps writing to groups should not be handled with a single ! like before, I don't think that's intuitive unless you already used groups on GS. maybe writing to groups could be done a) on a group page, have a "reply" form right below the header above statuses if you belong to that group, b) a group scope on post status form, picking it lets you then choose from the list of groups you're in
  • picking "Groups" from nav panel would show tabs for something like "groups you're in", "groups you control", "discover" (which lists some known groups, something to make it easier to actually find groups)
A bit late to the party, throwing some ideas about groups could or should work, might be unrealistic and not reasonable but read anyway My basis started from GS groups but started diverting a lot the more I thought about it, GS groups worked to some degree but it was always kinda hidden in classic ui, not very discoverable, and they didn't really facilitate much that you couldn't do without them (which was partly because the network was so small you could read twkn regularly, but with way more noise now it makes more sense). First of all groups should have a profile similar to any user, so you get to have a group picture, banner, name, description, buttons for join etc, settings, tabs for statuses posted for the group, lists of members, and more if it's your group or you are moderating the group (pending invites/join requests for example). Some improvements I think our groups should have compared to what we had before: - private groups, not listed when someone checks your groups on your profile, all posts are visible only to group members, makes it easier to discuss stuff with more people you just don't want to be completely public without manually addressing everyone. this is a bit difficult if you can mention multiple groups, what happens when you mention a public group in a private group post? (actually what happens when you mention a public group in a dm?) - proper invite and join request system, should be controllable if anyone can join a group freely or not. - group posts on timeline should be pretty clear that they're addressed to a group and not just a !group at the beginning of a post (honestly being able to address just a single group starts to sound more and more sensible despite its drawbacks) - perhaps writing to groups should not be handled with a single ! like before, I don't think that's intuitive unless you already used groups on GS. maybe writing to groups could be done a) on a group page, have a "reply" form right below the header above statuses if you belong to that group, b) a group scope on post status form, picking it lets you then choose from the list of groups you're in - picking "Groups" from nav panel would show tabs for something like "groups you're in", "groups you control", "discover" (which lists some known groups, something to make it easier to actually find groups)
Owner

perhaps writing to groups should not be handled with a single ! like before, I don't think that's intuitive unless you already used groups on GS. maybe writing to groups could be done a) on a group page, have a "reply" form right below the header above statuses if you belong to that group, b) a group scope on post status form, picking it lets you then choose from the list of groups you're in

option a sounds like you'll be able to post to a group only from group page, option b sounds like over-cluttering an already messy feature, plus it implies scope would limit visibility which it may not. Lastly, both options make it impossible to use groups on non-pleroma-fe clients.

I believe slack and discord do not differentiate groups from users so mentioning a group would be same as users - @moderators for instance, flowdock uses two ats, so it would be @@moderators, i feel like either way is more intuitive than ! especially since most people are used to discord or slack, and @ already implies mention, i.e. "Don't @ me" = "Don't mention me".

>perhaps writing to groups should not be handled with a single ! like before, I don't think that's intuitive unless you already used groups on GS. maybe writing to groups could be done a) on a group page, have a "reply" form right below the header above statuses if you belong to that group, b) a group scope on post status form, picking it lets you then choose from the list of groups you're in option a sounds like you'll be able to post to a group only from group page, option b sounds like over-cluttering an already messy feature, plus it implies scope would limit visibility which it may not. Lastly, both options make it impossible to use groups on non-pleroma-fe clients. I believe slack and discord do not differentiate groups from users so mentioning a group would be same as users - `@moderators` for instance, flowdock uses two ats, so it would be `@@moderators`, i feel like either way is more intuitive than `!` especially since most people are used to discord or slack, and `@` already implies mention, i.e. "Don't @ me" = "Don't mention me".
Owner

you're right about option a, and you're also kinda right about option b. and yes I think scopes together with groups are a very very bad idea, which is why I think it makes sense to limit group posts to the scope of the group itself, and why I think it makes sense to pick a scope or a group.

I don't think what slack and discord do are any different from a !mention, different characters but same method of having to know exactly what to do. When you join a group, how are you expected to know how to post to that group? if you can mention groups like that then you inevitable also create the expectation of being able to mention multiple groups which could be a really bad idea depending on where we want to take this feature, ie. do we just want them to be mailing lists or something else, I think allowing multiple group mentions completely locks out the possibility of private groups which personally I think could be a really good feature

yes I think clients should bring group support on their own, we can't expect every feature to just work without explicit support for them in the applications, that's how we end up with half assed features that don't need to be supported when they already kinda work but not really

you're right about option a, and you're also kinda right about option b. and yes I think scopes together with groups are a very very bad idea, which is why I think it makes sense to limit group posts to the scope of the group itself, and why I think it makes sense to pick a scope or a group. I don't think what slack and discord do are any different from a !mention, different characters but same method of having to know exactly what to do. When you join a group, how are you expected to know how to post to that group? if you can mention groups like that then you inevitable also create the expectation of being able to mention multiple groups which could be a really bad idea depending on where we want to take this feature, ie. do we just want them to be mailing lists or something else, I think allowing multiple group mentions completely locks out the possibility of private groups which personally I think could be a really good feature yes I think clients should bring group support on their own, we can't expect every feature to just work without explicit support for them in the applications, that's how we end up with half assed features that don't need to be supported when they already kinda work but not really
Owner

I think flavor text below group description like You can mention this group with @@group@server and permissions description i.e. "Only members can mention, membership must be approved, members are notified about posts". You can have both multiple group mentions and private groups, just if you don't have permission to post into private group you'll just get an error when posting with mention or just mention won't come through like it would with nonexistent users. Check out this comment for use-cases i see for groups #625

I feel like groups should be something close to a mailing list with flexibility of a subreddit or a discord mentionable role.

As for clients... I doubt a federated feature that's only available on one FE that only works with one BE will be all that useful. Option b would also completely break with huge explosion when it would come to using, say, tusky. Imagine you're in a group and you get a mention from a group, you try to reply to it but since it's tusky, group mention gets dropped because it's a pseudo-scope now.

If you think of groups as of subreddits, mentioning multiple groups suddenly makes sense since it essentially eliminates cross-posts.

I think flavor text below group description like `You can mention this group with @@group@server` and permissions description i.e. "Only members can mention, membership must be approved, members are notified about posts". You can have both multiple group mentions and private groups, just if you don't have permission to post into private group you'll just get an error when posting with mention or just mention won't come through like it would with nonexistent users. Check out this comment for use-cases *i see* for groups https://git.pleroma.social/pleroma/pleroma-fe/issues/625#note_36053 I feel like groups should be something close to a mailing list with flexibility of a subreddit or a discord mentionable role. As for clients... I doubt a ***federated*** feature that's only available on one FE that only works with one BE will be all that useful. Option b would also completely break with huge explosion when it would come to using, say, tusky. Imagine you're in a group and you get a mention from a group, you try to reply to it but since it's tusky, group mention gets dropped because it's a pseudo-scope now. If you think of groups as of subreddits, mentioning multiple groups suddenly makes sense since it essentially eliminates cross-posts.
Sign in to join this conversation.
No milestone
No project
No assignees
7 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
pleroma/pleroma-fe#625
No description provided.