Draft Issue. Groups: What are they? How they work? #14
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
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:
Pleroma groups should federate
But how should they be moderated across instances, especially with instances blocks in place?
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
@moderatorswould 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@serverhandles, 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.What gab does with
group_idis 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
!groupthe same way users include#tagsor@mentionsnow. 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" ...
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 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 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.
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:
@doomersor@ffxivSquadet cetera, usually more creative stuff. Good for movie nights too, i guess.@moderators@adminsand so on. Pretty self-explanatory.@rfgroup bot Dr. Equivalent made. Stuff like people living in same place, or in same country, or like it would be possible to make!doomModdinggroup about doom modding group.!berlinbut you can still mention likehey !berlin i will be visiting next week does anyone need anything from helsinki)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
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-devasking for clarification.We discussed this on irc earlier. There are two ways to make subscriptions to a hashtag possible:
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.
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.
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.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.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.
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.
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 #helpversusHelp i'm being mugged !polis@helsinki.fi help meOh, my mistake.
for your example it would probably be like
There's a big photo expo soon in Berlin !berlin #photographyunless!photographyis your local photography club/circle/academy/groupI'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.
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.
"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.
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.
What was actually wrong with gnusocial groups?
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).
Hmm, One problem I see; I assume on gab that for the user side it's something like
However, that is not how things currently work (see also comment pleroma/pleroma-fe#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?
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 representationA 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:
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 -
@moderatorsfor 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".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
I think flavor text below group description like
You can mention this group with @@group@serverand 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 pleroma/pleroma-fe#625I 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.
something related to groups and their possible implementations came up on my timeline last weekend which I thought is pretty important. posting only to a group and not to peoples timelines is a useful feature, makes it easier to post some things without worrying about spamming those who are not interested
so it's basically a DM to group?
it doesn't have to be a DM, it can still be public, just not addressed to the user's follower collection
I find it questionable, if it's "public" but not delivered to regular timelines so discoverability is pretty much save as DM without the access restrictions of DMs. This is essentially "Only mentioned people and people that have the link to message/thread" scope which is confusing (like all non-public scopes).
How about we do it the same way with replies and add filtering options:
We already "annoy" people with noisy "all replies visible" which could be disabled with PleromaFE filters (but unfortunately broken mostly because of bad metadata). Filtering will allow people who don't want to see certain group posts or all group posts can opt-in to mute them, and if OP really doesn't want to bother anyone or something they can just use DM scope.
yes what lain said, posts not meant to appear on public timelines for regular followers but for anyone in the group or viewing the group, it's essentially filtering noise but not by the reader but the sender and that's the big difference between user settings for what can be seen and what can't be seen vs. this suggestion. making dms with groups just sounds like a very unintuitive way of achieving this kind of a thing, or scopes in general with groups
Non-public scopes already unintuitive by themselves and they make everything they touch unintuitive (i still have no clue what "unlisted" does exactly and what "timelines" considered "public" and activitypub terminology/architecture isn't making it any easier). However, it's something people are used to already and something new people have to learn, it's better to use those instead of adding even more options.
I feel like we need to define how exactly groups should work first, then we can see if scopes are intuitive and/or confusing.
OK, a little bit how i see groups right now:
Group entity
Groups are created on some instance, they have a profile like a regular user, complete with avatar, background, recent posts.
Additional "Members" counter, should be configurable to hide/show it.
Mute replaced with "Mute posts mentioning this group"
Subscribe replaced with "Always get notifications from this group"
"Become member" button is added.
If "viewer" doesn't have "become member" permission "Ask for invite" is displayed instead and group considered "locked"
If "viewer" doesn't have "ask for invite" permission, button is hidden. "Follow" button is also hidden. Being a member implicitly makes you follow that group.
Creating groups should have several templates for creating typical usecases (Telegram-styled channels, GS-style channels, Private groups, Mailing-list-styled, more could be added in future) including default ACLs, description explaining how group supposed to work, etc.
Administration
Group has a dynamic ACL which allows setting up roles, with basic roles being "Owner", "Member", "Viewer".
You can create more roles if needed. Pretty much same as Mumble/Discord ACL system but hopefully simpler. Should have presets like "Group admin", "Voice".
Roles define following permissions for users:
Additionally, roles (or entire group in some cases) can define following restrictions:
And how invalid messages should be handled
Interaction
Interaction somewhat depends on the group settings and membership status, but general idea is: Mentioning a group while being a member adds that post to group's feed. It also acts as your normal post, so - visible to followers and on your profile. People who are following a group (not necessary a member of the group) will see that post on their home timeline. Users that subscribe to the post also get a notification and so will members of role that has "always notify" option set.
Update to existing interaction.
This doesn't exclusively affect groups but instead affects all the posts.
Hello @foo@barwill add checkbox like[x] Notify @foo@bar, which will allow you to to reference them instead of mentioning them, which will look likeHello foo@barinstead but withfoo@barbeing a link. For compatibility sake you should be able to use some other way on clients that do not support this approach, such as using_prefix, likeHello _@foo@bar_@group@barwill generate link to group, for notifications another prefix should be used, like!@group@barHas anything happened since?
Agreeing with a lot of the points here. My 2 cents:
Groups are not hashtags
In practice, being "not a hashtag" means the group must be self-contained. It has one timeline containing only its own posts.
A status can only belong to one group.
A group must be joined to post in it, and the request may be rejected. Joining a group is a bit like sending a follow request - a public group accepts the join automatically, while a private one doesn't.
What makes a group
A group has members. It has posts. I think the UI should work basically like any other feed. When you've navigated to the group in the UI, you can post into the group. It's deceptively simple.
It has an avatar, a banner, and a list of members. You can upload media, report posts, and do everything you can already do anywhere else.
Privacy scopes
One difference is privacy scopes. The group itself has a privacy scope, and all posts within the group are locked to that scope. The group can update the privacy scope, but it only affects new posts. It's basically the same system people are already used to with their own accounts, but the setting applies to the whole group.
Moderation
Members of the group can have different user levels: User, Admin, Moderator. There are some tricky complications, like deciding whether an admin can kick off another admin, but overall this is straightforward.
Federation
Like Accounts, a Group is local to a particular server.
It can have a unique identifier, eg
&suya@lain.com. Using this syntax does not create a post in the group, but it does insert a hyperlink to the group. EgJoin my new group at &beer@gleasonator.com!Technically you could have a situation where a local group has only remote admins/mods, but the server admin could always take control of any group.
Group posts should use an unambiguous object type, eg GroupNote instead of Note, as incompatible servers shouldn't see them at all. Group posts should only be federated to members of the group.
That's all I've got for now. Looking forward to this!
Wanted to add another thought. On a data level, a Subreddit and Group are basically the same (a group has more privacy options). They're just different ways of presenting it.
At it's core, a group is a bucket of posts.
Hi, cross posting https://socialhub.activitypub.rocks/t/groups-implementation/591/55?u=diogo as we usually try to base our ActivityPub implementation on pleroma's.
Mobilizon has groups with discussions (like forum posts I guess), events related to a group, todos, public messages (announcements assigned to group actor, not author) and resources. They have admins, moderators and members
Thanks for the info, I'll see how they are doing things.
Smithereen (VK clone using ActivityPub) has simple groups that actually federate, they have memberships and simple moderation
We finally striked enough tasks from our version 3 tasklist to move from just an idea of what we would like groups to be, to a formalisation of how we think it can be achieved: https://socialhub.activitypub.rocks/t/decentralised-group/2200
Here's a bit of a plan/ideas i have in my head right now, especially how things could be split into different features for them later to come together and how technically implement stuff. Bear with me I'm not an AP expert.
STAGE 0 "Better than nothing"
@s (for compatibility sake only one@is require from clients)Drawbacks:
@@pleroma_supportaccount) (might change default to mention from anyone from get go?)Unanswered questions:
Sidenote:
Peertube has multiple "accounts" support, being the "root" account of the peertube instance
@peertube, user's own account and accounts for each of the user's channels. From pleroma perspective when a video is published user's own account is the one who creates it, followed by "repeats" by@peertubeand channel account it was posted to.Channel can be changed but this update doesn't seem to propagate to pleroma, and overall following any account except
@peertubeis ultra-jank. We could also create such "root" group for an entire instance, i.e.spc groupis automatically created just so that you could join it so that you don't feel left out when you migrate to self-hosted instance.Continuing the topic of changing the labels around, group account can just reprööt when it's mentioned (again, rfbot style) and supporting frontends could change label around from "GroupA repeated" to "GroupA you're in was mentioned"
STAGE 00 "Convenience not only for groups"
This is more of a list of features that would benefit groups but also help in other usecases:
Drawbacks:
sudo sudance withrootnot having a password)Unanswered questions:
STAGE I "Groups 1.0+"
Untouched subjects
Sorry if delirious and nonsensical, I had a revelation in bed and had to type it out before I'd forget it.
Thinking about it, I guess limit on who can post could effectively be linked to lock aka manual-followers-approval: