Seems there are a lot of conflicting implementations. Zap has a conflicting implementation as well which grew from the way we initially tried to do groups across multiple protocols such as ActivityPub and OStatus and Diaspora - none of which gave much thought how to implement groups in their initial specs . These earlier efforts are still visible in Friendica and Hubzilla and have issues with privacy conflicts.
A group in Zap looks just like any other actor except the type is ‘Group’. You can join a group with either a normal follow/group or use a join/group activity if you prefer. Groups, like Actors - can have either public, restricted, or private scope.
Posting to a group is done either via a wall-to-wall post or a direct message to the group. These are re-written as normal posts from the group containing an embedded reshare activity (embedded as html, with some care taken to work around Mastodon’s aggressive HTML filtering). We couldn’t use Announce because of privacy conflicts (*) and resultant complex delivery chains; as well as the fact that projects like Pleroma can’t handle LD-signatures on relayed posts and I’ve yet to see another project that correctly handles attribution on federated wall-to-wall posts correctly without embedding them - though I haven’t yet had an opportunity to test Smithereen. If the original post is edited or deleted, the embedded share is updated accordingly and re-pushed.
Comments behave no different from any other activity.
(*) Privacy conflicts arise when the posting actor has a different privacy and permission profile from the group. For instance if the actor only accepts comments from connections, they won’t see replies to the group post. Likewise if an actor with a public profile posts to a private group, all the replies to the private group would end up being shared publicly. A privacy conflict also arises in Pleroma because of their inability to use LD-sigs. The object must be fetched from the original actor site and will be blocked if the actor has restrictive permissions. You can’t easily use OCAP methods to allow this because if the group is public, your private access key is now fully public.
I don’t claim the solution I’ve come up with is elegant, only that it works and is fully compatible with existing ActivityPub implementations and works correctly even when there are privacy conflicts between the posting actor and the group. This behaviour has been honed and refined as a result what we’ve learned in ten years of supporting this feature across protocols that are hostile to or ignorant of privacy and permissions. Maybe if we all share what we’re doing we might find a combination that is both elegant and works for everybody, though I am willing to live with “works for everybody” and go it alone if the end result is elegant but only works with fully public groups or actors.