How do we handle Groups (Reconciling FEP-400e and FEP-1b12)?
-
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.
-
I think in order to reconcile FEP-400e and FEP-1b12 the following changes can be made:
- Both FEP-400e and FEP-1b12 implementations: support FEP-7888 (context collection)
- FEP-400e implementations: upgrade to Conversation Containers
- FEP-1b12 implementations: add
target
property toAnnounce
activity that points to context collection.
Activity types will still be different (
Add
vsAnnounce
), but consuming implementations can easily accept both. -
@[email protected] Unless I'm reading this wrong, you're advocating that we should:
- Reduce the number of moving parts to 2 (400e bows out in favour of 171b)
- Encourage broader adoption of a resolvable
context
property (this would be the one differentiator that can be used as feature detection) - Implementations should accept both
Add
andAnnounce
activities as valid for appending to a resolvable context collection.
Let me know if I have that right, I'd like to discuss this at the upcoming ForumWG meeting Thursday.
-
julian:
Unless I'm reading this wrong, you're advocating that we should:
Yes, that's correct. I believe it is also important to make
context
a collection of activities, because reactions are part of a conversation too (I didn't fully realize that until I added support for FEP-1b12Announce(Like)
andAnnounce(Dislike)
) -
disagree that
context
should contain likes and dislikes. i think those should go in collections likelikes
or an extension-defineddislikes
.but also,
context
is agnostic to what it contains. this is why i was thinking of maybe defining new types to signal that the collection should contain "posts" (objects that havecontent
) only, or if it can contain other non-"post" objects like Like/Announce/etc activities.the main mechanism for deciding what goes in a context collection is more or less "whatever declares that
context
and gets delivered to / added by the authority" -
Okay, so we have some disagreement here with respect to what a
context
contains. Perhaps my understanding was outdated, but I thought there was some limited discussion aboutoutbox
containing the full activity log, and the collection containing the post objects. That would satisfy both sides, if I am not mistaken.Usually the conversation devolves into "what is an actor, anyway", but let's keep things on track today LOL
-
trwnh:
disagree that
context
should contain likes and dislikes. i think those should go in collections likelikes
or an extension-defineddislikes
.So servers will need to make additional requests for every object in a context collection when backfilling a thread? This is quite inefficient.
The goal is 0 additional requests because every activity in collection is signed.
-
i am in favor of having contexts contain "post" objects as you well know, and for making collections into actors that can be followed and can have outboxes. you're not outdated or mistaken there
the only missing bit is some signal to describe what a context collection contains, and if it is a collection-actor, then some signal to describe how it behaves.
specifically this where the new types could come in. very loosely i was toying with something like the following
for collections representing a conversation, we have the following attributes we could signal:
- "this collection contains objects sharing the same
context
" - "this collection contains objects that have text
content
"
for actors representing a topic or community, we have the following behaviors we could signal:
- "this actor announces any activity sent to it" (new style boost bots like 1b12)
- "this actor announces the object of any Create sent to it" (old style boost bots like guppe)
- "this actor adds any Create.object or activity it encounters with the same
context
to a context collection that it owns" (context manager)
maybe types aren't the best way to signal all of these things, but it's what we have available to us at the moment, barring the development of some kind of FEP to allow actors to signal which clients they have attached to them and how those clients behave.
at the very least, the collection subtypes make enough sense to consider for now... i might have to revisit the actor behaviors later, because if we just define types for every behavior then this could quickly lead to actors having more types than you know what to do with. also i think more precisely these behaviors are properties of the client attached to the actor, not the actor itself.
tldr if you want to distribute Likes and Dislikes and Announces as part of a context/conversation then i think the best we can do right now is have the author of the Like/Dislike/Announce consider putting
context
on those activities, and then it'd be up to the receiving context manager to decide whether they want to allow those contentless activities to be added to the context collection or not. - "this collection contains objects sharing the same
-
it's only inefficient if you care about like/dislike/share counts. i am fundamentally disagreeing that those activities should be considered part of a conversation. it adds nothing to the conversation to just tell everyone "i like this" with zero additional input to the conversation. now, if you wanted to clarify and say "i like this because ..." then maybe you actually are contributing to the conversation. you'd do that by putting
content
on your Like, which turns it into a "post". (posts dont have to be Notes or Articles. activities can be considered "posts" if they havecontent
.) -
From an implementor point of view, I will say that if I receive a context and it contains the entire activity history, I will simply retrieve everything and normalize it down to the items that I do care about.
For example, a collection containing:
Create(Note), Like(Note), Announce(Note), EmojiReact(Note), Create(Note)
would be collapsed down to
Note, Like, Announce, (ignored), Note
Whereas a collection containing just the objects would not need collapsing (it'd just be
Note, Note
). Either way, it containing the entire history does not impede my ability to parse it.Sure, I'd miss some of the activities around it, so that's a concern, but it's not a dealbreaker. That's why I'm on the fence about this one.
-
My personal opinion is that this could be a non-issue. If the verbiage on the FEP were amended so that it says:
The collection MAY contain complete activities (this includes Create, Update, Delete, Like, EmojiReact and other activities) OR simple objects.
I would have no problem with this, but I do not know if this is a problem for others.
-
@julian I'd lean towards activities, because it's a lot easier to remove data you don't care about, than to reinvent data that you do care about but never received.
-
julian:
Sure, I'd miss some of the activities around it, so that's a concern, but it's not a dealbreaker. That's why I'm on the fence about this one.
You'd be missing activities regardless. If someone sends a
Create Note
with acontext
to the context manager, and I'm following the context and receive this activity, I might send aLike
to the author of the Note but NOT to the context manager. In that case, the only way to obtain a complete view of thelikes
collection for that Note is to ask its authoritative origin. This is going to be something that happens a lot due to the messiness of fediverse implementations -- you might have 3 Likes be delivered directly to the context manager, but 7 other Likes be delivered only to the author of the liked post. If you are only processing the context collection, then does the post in question have 3 likes, or 10? -
It's probably not going to be what some people want to hear, but some degree of lossiness is unavoidable.
All we can do is apply our best effort and set forward a straightforward recommendation that other implementors can consume and implement with minimal variance.
That's why I eschew esoteric and complex implementations when a simpler mechanic would suffice.