Let's discuss groups

[grishka]

There will be a moment when I’ll have groups. And then there will be a moment when I’ll have to federate these. There seems to be no consensus on what groups actually are and how to represent them. So,

• Group members. How are those represented? Are they the followers collection? Can a group have followers at all? Or should it be a separate, custom collection a-la Mastodon’s pinned toots?
  • Since it’s a collection of actors anyway, can groups be members of groups? This feels weird to think about. This makes little sense too, because groups aren’t accounts and so don’t have news feeds, do they?
  • In a group that is an event, how do I represent the “not sure” members?
• Group posts. If a user posts in a group, where does the post go? Post to group’s inbox, address it to the group members collection, and then it appears in its outbox? So, basically, if you’re to post in a group that is on another instance, you’d send your post to that instance (only), and it would then forward it to all the instances where there are any members?
• Posts on behalf of groups. Are these technically allowed? Like when not a particular user but the group itself posts something? I’m not going to have these myself because they diminish the users that are actual people, but if they are allowed, I do have to support storing and displaying them because dropping something users might be interested in isn’t a good thing to do.
• Usernames/aliases. Should it be assumed that group and user aliases use different namespaces and so there can be a user and a group with the same alias on the same instance? I will have the same namespace because my user-facing URLs have the form of https://instance.domain/alias, so this, again, is the question of what I have to expect from other implementations.

[lanodan]

[2020-02-18 11:44:54+0000] Gregory via SocialHub:

There will be a moment when I’ll have groups. And then there will be a moment when I’ll have to federate these. There seems to be no consensus on what groups actually are and how to represent them. So,

We more or less already have them, see Peertube Channels.

• Group members. How are those represented? Are they the followers collection? Can a group have followers at all? Or should it be a separate, custom collection a-la Mastodon’s pinned toots?
  • Since it’s a collection of actors anyway, can groups be members of groups? This feels weird to think about. This makes little sense too, because groups aren’t accounts and so don’t have news feeds, do they?

Why shouldn’t groups have an account? They don’t have to be a mere collection of actors (you don’t need groups for this btw, activities can have multiple actors, even if that’s broken in Mastodon and Pleroma, mainly because of QvitterAPI/OStatus/MastodonAPI for Pleroma).

I guess as:Organisation would make even more sense to have at least a management account for them, for me they were always a weird kind of as:Group.

• In a group that is an event, how do I represent the “not sure” members?

Events should use something like replies collection, not Groups. Specially as there is as:Event and it’s an activity.

• Group posts. If a user posts in a group, where does the post go? Post to group’s inbox, address it to the group members collection, and then it appears in its outbox? So, basically, if you’re to post in a group that is on another instance, you’d send your post to that instance (only), and it would then forward it to all the instances where there are any members?

Should be the Group’s own policy, it goes to the group inbox (this is how addressing works, and you don’t have the rights to address another’s collection) and then it can do whatever it wants with it, popular behaviors for pre-ActivityPub groups being repeating with or without moderation.

• Posts on behalf of groups. Are these technically allowed? Like when not a particular user but the group itself posts something? I’m not going to have these myself because they diminish the users that are actual people, but if they are allowed, I do have to support storing and displaying them because dropping something users might be interested in isn’t a good thing to do.

Why not? I don’t think I want to have the ability to do it either, not sure about support Peertube has been using groups in their activities for channels IIRC.

• Usernames/aliases. Should it be assumed that group and user aliases use different namespaces and so there can be a user and a group with the same alias on the same instance? I will have the same namespace because my user-facing URLs have the form of https://instance.domain/alias, so this, again, is the question of what I have to expect from other implementations.

Why would you care? I think the only case where is matters is because of webfinger (which is optionnal in Pleroma, no idea if Mastodon fixed this bug from them) and similar kind of addressing, as-in should we use @preferredName@host or do it like OStatus/GnuSocial with !groupName@host.

I think both have their values but the former will probably break things for legacy instances (which is probably just GnuSocial so ~100 nodes that are dying or dead).

Pleroma and Mastodon uses /users/:username for AP (and the shitty /:username or /@:username thing for HTML, thus breaking orthogonality), Peertube seems to have them neatly namespaced.

[heluecht]

Friendica is doing groups this way:

The group is an account with the type “group”. You post to a group by mentioning it. Then the group account is announcing the post to its followers.

This works out of the box not only with Friendica but at least also with Mastodon and it should work with Pleroma as well.

[grishka]

The group is an account with the type “group”. You post to a group by mentioning it. Then the group account is announcing the post to its followers.

There are several Mastodon bots that do this. But what I want eventually is full-featured groups with at least discussion boards, somewhat like this:

This obviously won’t be compatible with Mastodon and the rest of microblogging software. But thinking of it, we’d get stuck with a lot of cruft and subpar UX if we keep making everything 100% compatible with Mastodon.

[macgirvin]

In Zap, the initial posting to a group is either a DM or wall-to-wall post. We used to use mentions (I created the Friendica implementation many years ago) but this had a number of issues when it came to privacy and permissions differences between the posting actor and the group. We had also used bang-mentions for a time which had the same issues as well as a lack of general support outside a small number of projects. Wall-to-wall also has a lack of general support but we’ve kept it for those using compatible software as it matches the Facebook experience.

Relays or Announce activities have the same issues with privacy mis-matches. You can end up with group posts that nobody can comment on because the author’s permissions don’t allow it, even if the group does. This can only be partially solved with OCAP and really needs a replyTo field or the equivalent to work properly and that’s unlikely to find widespread support on the near term. So now we’re embedding the original DM into a post and having the group resend it as a new message with the group’s permissions.

Not saying this is the best way to do this, but given the constraints, it is fully functional and all privacy and permissions are handled completely separately between these two actors (there are no overlaps where permissions mis-match has undesired side effects).

We’ve looked at discussion board implementations and found these typically require a title and it isn’t clear how you require a title on external software. You can really do this only with a wall-to-wall post where the group server can impose this rule and there’s very little support across the fediverse for this construct.

[grishka]

Wall-to-wall also has a lack of general support but we’ve kept it for those using compatible software as it matches the Facebook experience.

Oh, this is interesting. And sorry for off-topic. I thought no one did wall posts in federated software. How are these represented in Zap? I tried different approaches but then just settled on the partOf field with the wall owner’s outbox URI, because differentiating posts to somebody else’s wall from regular posts, especially when mentions are involved, by addressing alone proved tricky. Also is there any kind of capability indication that an actor accepts wall posts? I did that with a custom field in my own namespace but haven’t gotten around to actually restricting posting on walls of, say, Mastodon users.

At this point I can still change things around without any implications because no one dared to host another Smithereen instance lol.

[macgirvin]

We use openwebauth, which is my own creation and grew out of the work we did in Friendica a decade ago to bring Facebook-like interactions to the fediverse. In its latest form it’s just webfinger and http-signatures used to provide web authorisation to a page on another domain. It’s completely separate from whatever message transfer protocol you use.

The issue with wall-to-wall posts is that signatures don’t work, but signatures don’t work in the fediverse anyway so it isn’t a huge loss. The post is signed by the wall owner instead of the author. I think Mastodon will reject these, but I don’t really care. It’s just one of hundreds of Mastodon quirks we have to live with.

Also is there any kind of capability indication that an actor accepts wall posts?

This is a permission and we don’t usually share our personal permission details with strangers. Basically if you visit a page on a remote site and you get a post or comment form (and for some people an upload button) you have permission to use it. The Zot protocol provides access to your own permissions so you can see this ability remotely and react accordingly. I haven’t converted that concept to ActivityPub because it uses a completely different permission implementation which has no direct association or mapping to individual actors.

[AceNovo]

We have Organization as an actor for a heavy, top-down implementation where users are likely to expect a high degree of control over membership, permissions, and routing

The fedi also still doesn’t have tags worked out. I think ultimately tags will be collections on an instance and maybe that can be followed in some implementations

Groups are turning up in implementations and conversations as informal, uncurated user collections

If we accept these functional definitions as a reasonable representation of the unstated semantics, we have a model where the Groups actor experiences the lowest threat profile among the 3 features

I think that the quality of organizations and tags as features, and that of the fediverse as a whole, would benefit from group behavior being quite diverse, with low expectation of privacy and minimal barrier to implementation

So a group would be an actor with no additional collections or behaviors defined. This can be a dumping ground for our opinions on multiuser actors, making consensus on tags and organizations easier to establish

Also, I’d like to see extension recommended as best practice for the implementation-specific behaviors

[lanodan]

[2020-02-18 13:20:34+0000] Michael via SocialHub:

Friendica is doing groups this way:

The group is an account with the type “group”. You post to a group by mentioning it. Then the group account is announcing the post to its followers.

This works out of the box not only with Friendica but at least also with Mastodon and it should work with Pleroma as well.

No idea for Mastodon but it definitely doesn’t works in Pleroma right now, we have no support for as:Group at all.

Do you have an example group which you could point to so this one can be fixed into pleroma?

[creatinglake]

perhaps we can make groups and communities, including existing software like elgg, make a short post to the fediverse so people following a group/forum get notified via their fediverse feed/s rather than via email. Same with this forum, I’d like a short summary Fediverse post that I can click on to find my way back to this thread if/when replies are added.