Topic removal from a category/community
Technical Discussion
29
Posts
5
Posters
112
Views
-
We only federate the deletion if it is in one of our local communities.
The activity is signed by the person who did it, so if Mastodon detects that the person deleting is not the author and doesn't know how to find out if someone is a moderator or not, that's their problem.
Mastodon has been dropping the ball on groups support for years so I didn't even bother to find out if they handle it well - I bet they don't.
-
We only federate the deletion if it is in one of our local communities.
The activity is signed by the person who did it, so if Mastodon detects that the person deleting is not the author and doesn't know how to find out if someone is a moderator or not, that's their problem.
Mastodon has been dropping the ball on groups support for years so I didn't even bother to find out if they handle it well - I bet they don't.
so if Mastodon detects that the person deleting is not the author and doesn’t know how to find out if someone is a moderator or not, that’s their problem.
It is not their problem. If your actor
Deletes an object that is owned by a different server, then your implementation of ActivityPub standard is incorrect:https://www.w3.org/TR/activitypub/#delete-activity-inbox
The side effect of receiving this is that (assuming the
objectis owned by the sending actor / server) the server receiving the delete activity SHOULD remove its representation of the object with the sameid -
so if Mastodon detects that the person deleting is not the author and doesn’t know how to find out if someone is a moderator or not, that’s their problem.
It is not their problem. If your actor
Deletes an object that is owned by a different server, then your implementation of ActivityPub standard is incorrect:https://www.w3.org/TR/activitypub/#delete-activity-inbox
The side effect of receiving this is that (assuming the
objectis owned by the sending actor / server) the server receiving the delete activity SHOULD remove its representation of the object with the sameidI think
Announce(Delete(Object))skirts around that, though. Maybe not if you're being technical about it, but the shape of the activity is different enough to mean something else in 1b12-land:- A community/group-actor announced a
Delete - The object may or may not belong to the same domain as the community/group-actor or
Deleteactor - Verify that the community/group-actor and
Deleteactor are same-origin (might not need this if cross-instance moderation is a thing) - Verify that the
Deleteactor is a moderator of the community/group-actor as per 1b12
- A community/group-actor announced a
-
@julian @rimu No, when one object is embedded in another, it doesn't change its behavior. A
Deleteactivity wrapped inAnnouncedoesn't mean something else, it exists as an independent object that can be fetched by itsid.The invalid
Deleteactivity worked for Lemmy only because they didn't care about federation with non-forum software. But it can't work in the multi-app network without ugly hacks like checking remote server's NodeInfo. -
@julian @rimu No, when one object is embedded in another, it doesn't change its behavior. A
Deleteactivity wrapped inAnnouncedoesn't mean something else, it exists as an independent object that can be fetched by itsid.The invalid
Deleteactivity worked for Lemmy only because they didn't care about federation with non-forum software. But it can't work in the multi-app network without ugly hacks like checking remote server's NodeInfo.Perhaps resolvable contexts can be a solution for this then.
I have been implementing topic deletion logic in NodeBB, and while I can send out
Announce(Delete(Object))whereObjectis the root-level post, it occasionally would send outDeletes where the sender is not the owner of the object. This is the 1b12-speaking logic.In 7888-speaking logic,
Objectwould be the local context collection. A receiver would be able to resolve the context URL to the appropriate local representation and delete it as needed. This would also satisfy the "sender needs to own the object" constraint. -
Hey rimu@piefed.social, I sent over this activity but I wasn't able to make crust delete that representation.
{ "id": "https://bb.devnull.land/post/2#activity/announce/delete/1759851369554", "type": "Announce", "actor": "https://bb.devnull.land/category/2", "to": [ "https://www.w3.org/ns/activitystreams#Public" ], "cc": [ "https://bb.devnull.land/category/2/followers" ], "object": { "id": "https://bb.devnull.land/topic/2#activity/delete/1759851369554", "type": "Delete", "actor": "https://bb.devnull.land/uid/1", "to": [ "https://www.w3.org/ns/activitystreams#Public" ], "cc": [ "https://bb.devnull.land/category/2/followers" ], "origin": "https://bb.devnull.land/category/2", "object": "https://bb.devnull.land/post/2" } }Am I missing something?
-
Delete(Context)? This is very unusual because other collections are not created or deleted, they are server-generated views.I assume this problem arises when you create a topic for a remote post? Perhaps deletion of such topics shouldn't be federated?
Or you can generate
Announce(Remove(object: root, target: Context))It would be valid from the authorization point of view.
-
Delete(Context)? This is very unusual because other collections are not created or deleted, they are server-generated views.I assume this problem arises when you create a topic for a remote post? Perhaps deletion of such topics shouldn't be federated?
Or you can generate
Announce(Remove(object: root, target: Context))It would be valid from the authorization point of view.
Well, the whole idea behind them being resolvable is so that when they are acted upon (by the context owner), they can be queried.
For example if I receive a
Delete(Context), I'll resolve it to find the root level post, and from there find my local representation, and delete it, assuming the actor was allowed to delete it.They're only server generated views per current usage... but why do they have to be constrained to that usage?
-
rimu@piefed.social I think it might have been ignored because I don't serve a moderator collection as per 1b12.
I'll try to get that set up this week and test again :see_no_evil:
-
Try doing a bare delete (no announce wrapper), with the actor being the moderator who deleted the post.
https://join-lemmy.org/docs/contributors/05-federation.html#delete-post-or-comment
-
Try doing a bare delete (no announce wrapper), with the actor being the moderator who deleted the post.
https://join-lemmy.org/docs/contributors/05-federation.html#delete-post-or-comment
Thanks Rimu. Will give this a shot.
Upon reflection, since
Deletes aren't wrapped in anAnnounce, then I would recommend that anyMoveactivity we use not be wrapped inAnnounceeither. -
Yes I'm fine with that. It doesn't make much difference in the end.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@silverpill @technical-discussion it's part of the outbox delivery algorithm, which bridges between c2s and s2s. the intention is that the outbox publishes activities via c2s, but then optionally delivers based on addressing properties via s2s
(this ends up having other issues in practice due to the lack of an envelope, but at least the intent of "relevant activities should trigger notifications for relevant entities" makes sense, per 6.1 clients "look at" some relevant props)
-
@silverpill @julian @technical-discussion
example: alice and bob on site.example each have followers collections, but alice can't see bob's followers. if alice addresses bob's followers collection, then alice's outbox can't deliver to bob's followers. alice must address bob, and bob can choose to forward to bob's followers (inbox forwarding)
if site.example has a collection of "local users" that alice can see, then alice can address it and alice's outbox can deliver to items
-
@silverpill @julian @technical-discussion
a "local collection" might still have access control on it.
(the interface being assumed throughout the AP spec is HTTP, or at least HTTP semantics; "with the user's credentials" in this case means using an Authorization header that lets the outbox access the collection. it's only confusing if you have a monolith with no boundaries between the outbox and anything else; in that case it'd be "lookup the collection in your db/store/etc")
-
@julian Yes, I think in practice expansion should be performed only for local collections.
the server MUST dereference the collection (with the user's credentials) is confusing, because it sounds like we're talking about remote collections here.
-
@julian well, sure, with a monolithic implementation, the client and the outbox and the delivery agent are all the same app. but they don't have to be. the model is that the client submits to the outbox, and the outbox could also talk to a separate delivery agent internally. it's all opaque from outside the outbox. your internal "outbox" is the code that serializes activities and sends them to the delivery workers.
-
@trwnh@mastodon.social said in Expanding collections on delivery:
> say you are an outbox and you get an activity to: some id. you deref the id and get some info. what do you do?Simple. My outboxes send a "not supported" HTTP tag 🤣
But I'm being facetious.
From a C2S standpoint I suppose that makes sense. Thanks.
-
@julian now remove the requirement. what do you do instead?
- if it has ldp:inbox, send an LDN
...and that's it. at no point were you ever told or required to do anything else, so your followers/audience/members/etc will never get the activity even if addressed, because the collection was never expanded.
-
@julian i don't think it's "inferred", and leaving ambiguous cases up to inference in specification is typically called "unspecified behavior" ;)
say you are an outbox and you get an activity to: some id. you deref the id and get some info. what do you do?
- in all cases, if it has an `inbox`, you send an LDN to that id if you can.
- in case it's an as:Collection, you iterate over its items in theory and repeat step 1 recursively. (this is also problematic because it can be both paged+unpaged)
