I don’t think I’d consider it to be a deletion, since it’s just rejection from that group. I also don’t imagine that any implementations would actually accept a random actor deleting other posts
I don’t understand what you’re trying to make. If it’s those “groups” that boost whatever you mention them in, then yes, it’s Undo{Announce}. But I was talking more about full-blown groups that you post directly in. Of course that won’t be compatible with any existing implementations, but if everyone keeps making everything compatible with existing microblogging software through hacks of varied degrees of ugliness, no progress will ever be made.
You can’t introduce an entirely new concept and keep your implementation 100% compatible with everything else.
I agree. And a Delete from the Group actor makes sense to me for moderated groups. From my experience as forum moderator I know it is a good idea if it is not the moderator actor doing the delete directly, as this makes the action unnecessarily personal (well, if there is just one moderator, then it is clear who done it). Looking at Discourse you have the feature that multiple moderators agree with an action beforehand, or a bot (Akismet) is taking precautionary action. For the actor that is the target, it is the system that performed the action, and if they don’t agree they can always DM a moderator (or the action itself opens a discussion thread).
I don’t really see much disadvantage to the Announce path. How is that not “full-blown”?
It is not, because you post in your own profile and then the “group” boosts/announces your post to its followers. There’s one group bot like this I’m aware of, but I’m sure there are more. The post is still in your profile and your followers still see it, because it has to be public to be able to be announced. It’s a half-measure kind of solution that’s about the best that can be done to work with (and around) the feature set of existing microblogging implementations.
A “full-blown” group is the one that’s a completely separate context from your profile. You open the group, you post something in it and it’s there and only there. The activity goes out to the group members/followers but not to your personal followers. Whether anyone then sees that post in their feed or only when they open the group profile is an implementation detail that doesn’t affect federation. If you’ve ever used Facebook or VKontakte groups, you know what I’m talking about from the user experience standpoint.
I think “public-but-not-to-followers” is a case that should be looked at anyway. Twitter handled this by hiding posts that started with a mention, which works for most cases but falls apart whenever you actually do want to start a post to your followers with a mention
If a note was addressed to #Public but not to the author’s followers collection, would that work? I’m guessing current implementations don’t care
Twitter has a bunch of weird legacy that started out as sort of unspoken convention but was then picked up as a platform feature. Replies are one of these, retweets too — I remember when retweet with quote was a third-party-client-only feature around 2011. It worked by copying the tweet text, prepending RT: @username and letting you write whatever in the remaining characters.
But that is still not quite what I want. What I want is basically the ability to put my own activities into someone else’s outbox (with their permission). That’s how I made walls in Smithereen.
That would work to a varying degree. I changed my comments recently to not be addressed to followers — only as:Public, the top-level post author and whoever is mentioned. The idea was to show that I don’t want them in any feeds; that they aren’t really self-contained posts. Mastodon simply doesn’t care and displays them in the feed anyway. Pleroma apparently freaks out and doesn’t show them publicly, that is, in the web ui without logging in.
How we’re doing groups in lemmy, is that a user sends messages to a group, then the group announces (acting as a forward) to all other members of that group, on all the various other instances. Their shared inbox then receives the announce.
What if the owner leaved the group?
Could the group still survive?
Hi, just to share some thoughts, at GNU social, for v3, we’re planning on adding a logic layer of umbrella groups that we’ve elaborated a bit here: https://notabug.org/diogo/gnu-social/issues/186 . We haven’t got to a lot of implementation details yet as we’ve been busy with other priorities. But it seems that the rest of the world is already having fun with implementing Groups in ActivityPub and, since we really aren’t available enough to get into these implementation discussions at the moment, just wanted to share this here so that the others could start deliberating a bit about it as well. TL;DR: GNU social may need a property in the group actor indicating whether it is meant to be under an umbrella (as described in the linked issue) or not. Thanks. If someone else has already thought about this or came up with a better solution, sorry for bothering, we will eventually read about it when with time to implement this.
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.
2 Likes
I don’t think groups copying the user’s content is a good solution, since that loses the connection with the original object/actor. If a user wants to post to a group, they need to send the object with enough permissions to be viewed by all group members (or public if the group is public), otherwise the post should be rejected by the group host.
In Friendica the group is an actor with the type “group”. The users then are following the group account. To publish a note (or article) a user simply writes a (public) message and is mentioning the group account. The group then automatically shares this post via announce.
1 Like
@heluecht Public posts to public groups and wide-open comment permissions work fine with that model. See gup.pe groups. However, if your software supports both public and private groups and restrictive comment permissions (and/or aspects), the same mechanisms are fatally flawed so that approach won’t work. How would you suggest supporting both behaviours? A completely different UX for each, or (as I’ve done) finding a method which works well for the private case as well as across all platforms and protocols; which can then be used for all situations and policy variants - wherever you need to post to a group? There’s method to my madness…
Private groups won’t work quite as seamlessly with other software, but it’s still a viable option with similar mechanics. The Group would need to have manually approved followers, then mark all the Announces as to its followers and not public. For any posts to the group, they should also be sent to the group’s followers. Implementations that don’t know about groups probably wouldn’t do this, but they could technically still post to the group with a public post
Restricting comments is a separate discussion that is still ongoing
That won’t actually work in our environment (where restricted comments are a fact, as well as permission to examine/enumerate the followers list). This ultimately implies a different implementation for every platform just like we do with protocols and signature requirements and mention formats and “obligatory mentions” to trigger notifications and markup support and differing comment policies.
No big deal.
The followers don’t need to be enumerable to target them, the collection can be specified as a target
I don’t think membership in a group should be implicit through following. A group should have two collections, one of followers and one of members. You become a member of a group by Joining, not by Following. Restricted messages are addressed to both the group and the members and get Announced to the members. Public messages are addressed to the group and the public and get Announced to the followers.
1 Like
How should an implementation know whether they need to Join vs Follow? For some groups I guess they would need to offer both, but for the groups I’ve implemented so far there would be no difference