Notation for groups


#1

Groups are become a crucial part of Prismo (group is gonna be a equivalent of sub-reddit - more here: How to name sub-prismos? ) at some point in time (soon) and as there is no official ActivityPub Group spec, i think it would be great to agree on this together. I’m not sure if any other project here is gonna implement the Groups feature but if so - i would love to hear about it and know your thoughts.

So far, the only federation-related project having Groups i’m aware of is GNUsocial (https://gnusocial.net/doc/groups). They use a bang notation [email protected] and i have absolutely nothing against it. Also, they are kind of a pioneers in that matter so we could say “they were first - let’s stick to their convention”.

On the other hand, Mastodon author once said somewhere that he doesn’t like the bang notation (which means he would prefer to use a different one? hard to guess) and as a Mastodon being the biggest activitypub project out there, we need to take his words seriously. We would rather not end up with few different notations for describing/mentioning a AP group as it would be a paint to maintain for all of us.

So, what’s your thoughts on that? Personally i’m for the bang notation or eventually a “at-bang” one (@! - it would make it compatible with mastodon out of the box.)

cc @Anfora @Pixelfed @Funkwhale


#2

As far as I know, there is a Group type in the ActivityStreams specification.

To be honest, I don’t have any take on the notation part, and I’m more interested about the business logic: how does someone join or leave a group, how do you fetch group members, how do you represent a group in json-ld, etc.


#3

Woah, how on earth i missed that :face_with_raised_eyebrow:

Anyway, personally i was planning to implement prismo group as a special kind of actor maintained by multiple other actors (users)

  • Joining a group is like sending a follow request to other user - public groups does not requires owner confirmation while the private ones does
  • Outbox of a group is a list of all posts posted to the group
  • Each post posted to a group is both in group outbox and original poster outbox
  • Posting post to a remote group is about posting to group inbox with original author attribution
  • Group members = group followers

#4

In the spec, Group is type of actor, so no surprises here :slight_smile:

I’m not sure using Follow to imply group membership is the best way to modelize this. I can easily imagine some cases where this would be an issue, for instance a Group where not anyone can post, but everyone can read.

I’d rather use something else, like Add (https://www.w3.org/TR/activitystreams-vocabulary/#dfn-add). An actor would Add itself to a Group, which would be accepted automatically if the group is open, and an Accept would be send in reply to this activity. I’d also use a dedicated members collection, or something like that to list members of the group.

Otherwise, since Group is an Actor, having an inbox / outbox as you suggested makes sense!


#5

Hmm and what about using Follow to imply group membership and Add/Accept for posting to a group (that was my initial plan for this).

  • Public group -> Follow activity is automatically accepted
  • Private group -> Follow activity needs to be confirmed by staff member
  • Add activity -> post is Accepted if any internal validations are fulfilled. Otherwise it’s Rejected if validation fails or staff member rejects the post. Basically, reject activity might be used both for rejecting the join request and post create if i get it all well.

#6

What is the value of using Add to post to group outbox? Since Group is an Actor type, it seems more spec-compliant to have activity posted directly to the group outbox without wrapping them in an additionnal Add activity.

IMHO , a Group should behave like a traditionnal actor, in the sense that you can follow it to access its activity. The main difference with other actors is that multiple actors can post to the group outbox.

I know that Follow is used on Mastodon to limit access to activity using the “manually approve followers” thing, and it makes sense (at least for me). Following something or someone is about getting information from it.

For that reason, using this mechanism as a way to say “Actor X can write in Group Y” seems a bit odd. Also, it followers and members, and I don’t think tha will scale well or work for all use cases. Imagine a blogging app where multiple users can collaborate on the same public blog (anyone can read, only specific persons can write). People following the blog for its content are not necessarily the same as people having the right to publish in it.

You cannot really modelize that if you are using Follow as a way to imply read and write access.