I’ve implemented groups in Tavern and would like feedback and comments. All of the group specific actor and activity behavior is documented in https://gitlab.com/ngerakines/tavern/-/blob/issue-21-groups/FEDERATION.md as well.
Groups share the same namespace as users and it is up to instance operators to moderate how that namespace is managed. For example, both @email@example.com, @firstname.lastname@example.org, and @email@example.com are all valid names. I’m considering adding name filtering via allow-list or regex to give operators more control.
Groups have 3 roles: viewer, member, and owner. Viewers will only receive activities published by the group (
Announce/Note). Members will receive published activities and can also submit activities to the group inbox. Owners receive activities, can publish activities, and can also manage the group through the website. Groups can also be configured to auto-accept new followers.
To join a group, an actor must send a
Follow/Group activity to the group inbox. If auto-accept is enabled by the group, the actor will receive an
Accept/Follow/Group activity and be recorded as a follower of the group with the default membership role.
To leave a group, an actor must send the
Undo/Follow/Group activity to the group inbox.
To publish to the group, include the group inbox in the to/cc/bto/bcc fields and ensure the activity is sent to the group’s inbox. Activities received from actors that are not “member” or “owner” will get an authorized error on submission. The group will create an
Announce/Object activity and publish it to all followers for the received
Person actors may be invited to a groups.
When a group sends the
Announce/Object activity to members, the “to” attribute is set to the group’s followers collection. The activity is not intended to be public and only the object id is set. The expectation is that privacy mechanics between actors is meant to be respected and only minimal meta-data shared between group members.
Group Membership Changes
When a member joins or leaves a group, an
Update/Collection activity is created for the group follower’s collection and sent to all members of the group. This activity may be throttled to occur less frequently by instance operators (no more than once every 30 minutes to allow batching).
Group Conversation Viewing
The specifics of how group messages and threads are viewed is left to the actors receiving the announcements.
A “public group” is a group that is configured to auto-accept new followers with the “member” role.
A “broadcast group” is a group that has one central creator of activities, and many followers that are only viewers. New followers may be auto-accepted with the “viewer” role.
This is useful for:
- Providing “top down” updates for projects, teams, or organizations
A “working group” (or committee) is a group has a mix of both viewers and contributors. New followers may be auto-accepted with the “viewer” role.
This is useful for:
- Public project groups where discussions are visible, but contributions limited to a select number of individuals.
A “private group” is a group that is limited to contributors who are invited to the group. New followers are kept as “pending” until accepted, or the group may be invitation only.
- How can roles be conveyed in invitations?
- Can group actors or follower collections be limited to members of the group?
Leaveactivities be sent to group members instead of