Let's discuss groups

[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.

2 Likes