PixelFed is also working on groups support based on FEP-400e although I’m not quite sure whether they have a workable implementation yet or not.
I do think Lemmy’s implementation is simpler, however:
as I outlined earlier, aiming for compatibility with ActivityPub implementations that do not have a specific concept of groups is a double-edged sword: this means it’s hard to distinguish a provide a consistent UX for groups (e.g. people complaining about everything from a group being boosted in their timeline) especially with other projects (such as Peertube) using Group actors to mean a different thing
this is an extension of the previous point that is more of a Mastodon-specific issue, but the accounts UX relies heavily on @-mentions and webfinger, a condition we are able to lift for groups thanks to us considering them as a totally different thing
it does not ensure a post and its related interactions only exists within the context of a group
I talked with Dansup about group implementation in Pixelfed last November, but didnt hear anything new since then. Based on that, there doesnt seem to be much progress (though I might have missed things as I dont follow the development actively).
as I outlined earlier, aiming for compatibility with ActivityPub implementations that do not have a specific concept of groups is a double-edged sword: this means it’s hard to distinguish a provide a consistent UX for groups (e.g. people complaining about everything from a group being boosted in their timeline) especially with other projects (such as Peertube) using Group actors to mean a different thing
I am actually considering to specify the group in as:audience field in the future, as discussed in [this thread}(Unresolved issues surrounding Follow activities - #20 by nutomic). This seems much cleaner as it doesnt rely on extracting the group from cc field. It should also solve your first and third point (not sure about the second).
I’ve talked with Dansup over the past few weeks, and what he was describing and advocating for was based on FEP-400e, though I’m not sure that he has released code for that yet, and I have in any case not tried yet.
This is also the way I’m doing thing in my work-in-progress code, although there’s still a bunch of unresolved stuff.
If this completely replaces to/cc for posts, it could work, as current Mastodon versions do not look at as:audience. It wouldn’t really allow us to make a distinction on the actor level itself though.
I agree, I do have multiple issues with this FEP (I’d say it’s insufficient clear in many respects, and the thing about inlining an abbreviated form of the collection object can be at odds with JSON-LD), but they do not matter very much in practice. I missed the fact that target was not a valid property for non-activity objects (and would clash with the meaning of target in activities). This is not a practical issue for this specific use case either, but that’s not great.
Nevertheless, I think the initial Mastodon implementation will be based on this, considering it is almost done, and the NLNet fund deadline is mere days away…
Another thing I’m interested in (but will probably have to address after the initial implementation) is being able to report group posts to group admins specifically. Indeed, while one can report content to the instance admin, I think that should be a distinct action, as:
rules for a group may be stricter/more specific than those of the instance hosting it, in which case it does not make sense to report to the instance admins
someone may want to report a group to the hosting instance without the group admins knowing about it (e.g. group that is abusive, with the group admins’ blessing)
In Mastodon, we currently report content by sending a Flag activity to the reported user’s inbox (because there is no mechanism to represent what actor is responsible for moderating an activity), without any other explicit addressing, and with the offending actors/posts in the object attribute.
For reporting to group admins, I think we can simply deliver a similar activity to the group actor’s inbox, with an explicit to addressing to the group. I don’t think that would cause any ambiguity, but it is something I want discussed before going ahead, to avoid the possibility reports intended for the group admins accidentally going to the instance admins instead.
The details are described in this PR, but essentially, it would be compatible with Smithereen if not for the PublicGroup (http://joinmastodon.org/ns#PublicGroup) actor type and the fact the group posts must have only the group’s member collections in their to addressing.
Both of those changes are deliberate in order to prevent current Mastodon versions from interpreting groups and group posts in a way that would break the group expectations and make migrations a headache.