How do we handle Groups (Reconciling FEP-400e and FEP-1b12)?
-
Angus McLeodreplied to Gregory on last edited by [email protected]
Great to see you here again!
grishka:And it’s also fine to be incompatible
True! Albeit, I think the general consensus here is that there isn't an inherent incompatibility between 400e and 1b12. The question is more how an implementor approaches processing a Group actor's activities. @trwnh helpfully lays out the possibilities above
How do we handle Groups (Reconciling FEP-400e and FEP-1b12)?
This is a topic to track the FEP-400e and FEP-1b12 reconciliation, aka “How do we handle Groups”. I’ve made this a wiki to let implementers describe their current status quo Implementations See also
SocialHub (socialhub.activitypub.rocks)
The point of this topic and the spreadsheet I just shared is not to contrast the two standards. It's more of an empirical reference of sorts for implmentors.
grishka:you can’t exactly imagine Mastodon and a phpBB forum interoperating in any meaningful capacity simply because their user experiences are so disparate.
Well, I might slightly disagree with you there as Discourse, NodeBB and other forum-like implementations in the #activitypub:threadiverse-wg interoperate with Mastodon
silverpill:Added “Yes (partial)” to FEP-1b12 column.
Thanks!
silverpill:I intend to fully support both FEP-1b12 and FEP-400e in the future.
I think this is where the Discourse plugin will end up too.
Actually, now that I think of it, the Discourse plugin does partially support 400e as it will recognise a Collection in the
target
property. However it doesn't processAdd
itions to such a collection, so saying it supports 400e is premature. -
Actually, now that I think of it, the Discourse plugin does partially support 400e as it will recognise a Collection in the target property. However it doesn't process Additions to such a collection, so saying it supports 400e is premature.
This is where there is some potential to trailblaze as the other half of the equation might be implementing 7888, aka a resolvable
context
.I have a feeling that context and target would work well to point to the same thing.
@[email protected] said in How do we handle Groups (Reconciling FEP-400e and FEP-1b12)?:
By-the-by it strikes me that these implementation spreadsheets we're making should be synthesised in some way at some point.
My assumption was that the surveys and spreadsheets would be helpful to guide discussion at WG meetings, but eventually lead to a SocialCG report of non-normative findings, followed by a recommendation for new implementors.
-
Angus McLeodreplied to julian on last edited by [email protected]julian:
This is where there is some potential to trailblaze as the other half of the equation might be implementing 7888, aka a resolvable
context
.I have a feeling that context and target would work well to point to the same thing.
Agreed! The Discourse plugin treats them as equivalents, with a preference for context over target.
def create_collection(post) # See https://codeberg.org/fediverse/fep/src/branch/main/fep/400e/fep-400e.md # See https://socialhub.activitypub.rocks/t/standardizing-on-activitypub-groups/1984 raw_collection = object.context || object.target ...
julian:My assumption was that the surveys and spreadsheets would be helpful to guide discussion at WG meetings, but eventually lead to a SocialCG report of non-normative findings, followed by a recommendation for new implementors.
Also agreed, that is my thinking too. I just meant that when I was making the spreadsheet it occurred to me that it could also be the basis for an academic project. Perhaps I'm also just being lazy and thinking of who would be enthusiastic about and have the time to do this kind of thing comprehensively.
-
grishka:
My main idea with FEP-400e was to avoid posting group posts to one’s own profile at all costs.
You can't prevent this, because there's no such thing as an explicit "profile" that you add posts into. I don't really understand why Smithereen and Mastodon are so strongly concerned with this point that it leads to some frankly very strange decisions. There are two "correct" paths forward:
- Explicit manage your "profile" stream as a Collection
- Use something like
audience
to hint which "streams" the activity should be displayed in (see https://socialhub.activitypub.rocks/t/overlapping-taxonomies-and-the-audience-property/4229/8 and https://socialhub.activitypub.rocks/t/overlapping-taxonomies-and-the-audience-property/4229/11 for more details)
Really, my concern is that the use of
grishka:target
is not only spec-incompliant, it's also not a guarantee of the thing you're trying to guarantee. If you really want to make sure posts don't get displayed "at all costs" then why not stop using to/cc for such posts? As far as I can tell, Mastodon at least will ignore theaudience
property and should discard your "group" post as having no recipients.it’s not just walls — it’s a generic mechanism of creating objects into someone else’s collections, while also relinquishing full control over them. My FEP explicitly says that the collection owner can delete someone else’s objects contained in the collection.
This also strikes me as unnecessary. There's no need to delete other people's objects, you can just not include them; they effectively become orphaned references that can be garbage collected (or added back later!)
-
trwnh:
If you really want to make sure posts don’t get displayed “at all costs” then why not stop using to/cc for such posts?
I don't address them to any followers and don't put them into the outbox. This should be enough, in theory.
trwnh:This also strikes me as unnecessary. There’s no need to delete other people’s objects, you can just not include them; they effectively become orphaned references that can be garbage collected (or added back later!)
How would you prevent that from leaking into the UX? How would you explain that to users? It's generally expected that group moderators can delete any content from the group. And again, the semantics of you not owning the post, not having a complete authority over it, are important.
-
Is there a practical difference between "deleting from the group" or "removing from the group"? In both cases the end result is that the post is not visible anymore. Semantically it's a red herring, you should own the collection, not other people's posts.
The most basic of examples: I make a static HTML page that I claim is in response to one of your static HTML pages. You have the option to acknowledge my page as a response, or otherwise not acknowledge it. But you can't stop my page from existing. The problem is entirely conventional and third-party observers should view only your page and its acknowledged responses if they care about your authority to decide what gets acknowledged. In other words, "moderation" is in what you choose to include or exclude, not in preventing the existence of something.
The way I'd explain it to users is very simple: "Your post has been removed from the group". UX-wise, you can invalidate the stale cache for the orphaned object. I don't see why anything has to "leak" anywhere.
-
[email protected]replied to Angus McLeod on last edited by
I agree that group actors should not be able to
Delete
posts, onlyRemove
them from a "wall" or acontext
. It should be always clear who owns what. Without that, authentication and authorization are difficult and that leads to numerous security issues.@grishka I'm writing a FEP on this very topic: https://codeberg.org/silverpill/feps/src/branch/main/c7d3/fep-c7d3.md
-
Gregoryreplied to a on last edited by [email protected]trwnh:
The way I’d explain it to users is very simple: “Your post has been removed from the group”. UX-wise, you can invalidate the stale cache for the orphaned object. I don’t see why anything has to “leak” anywhere.
Well then for me,
silverpill:Remove{Note}
would simply be a fancier way for moderators to do the same thing thatDelete{Note}
would do.It should be always clear who owns what. Without that, authentication and authorization are difficult and that leads to numerous security issues.
It is clear — the group owns its wall collection but each post author also owns each individual post they made, to a degree. The group can't edit posts, but it can delete them. The author can both edit and delete their own posts.
I also have a mechanism for checking that the object is truly in a collection, but that isn't documented as a FEP (yet?). It is documented in my federation document.
-
[email protected]replied to Gregory on last edited by [email protected]grishka:
The group can’t edit posts, but it can delete them. The author can both edit and delete their own posts.
But how recipients are expected to know that?
In a regular
Delete{Note}
activity, authorization check is straightforward:Delete.actor == Note.attributedTo
.But ifDelete.actor
is a different actor (a group actor), then I wouldn't be able to process it without 1) knowing the type of application I'm federating with 2) discovering the members collection.Remove{Note}
, in comparison, doesn't require any special knowledge. It updates thetarget
collection (according to ActivityPub spec), so I just need to verify thatRemove.actor == Remove.target.attributedTo
. -
Gregoryreplied to [email protected] on last edited bysilverpill:
But how recipients are expected to know that?
It's specified like that in FEP-400e ¯\\\(ツ)\/¯
You don't need to discover the members of the collection to make this work. Remember, I treat ActivityPub like an API.
If you already have this post in your local database, you know which wall it's on, so you check that, in AP terms,
Delete.actor == post.target.attributedTo || Delete.actor == post.attributedTo
(my actual DB schema is different, I haveowner_id
andauthor_id
in my posts table so I just check if it's either the one or the other).If you don't have that post in your local database, it's a no-op because it's asking you to delete something you've never seen to begin with.
Delete
s already work like that. -
[email protected]replied to Gregory on last edited bygrishka:
Well then for me,
Remove{Note}
would simply be a fancier way for moderators to do the same thing thatDelete{Note}
would do.This is exactly what Lemmy does. Delete for your own posts, Remove for mod actions.