Topic removal from a category/community

[silverpill@mitra.social]

@julian @rimu No, when one object is embedded in another, it doesn't change its behavior. A Delete activity wrapped in Announce doesn't mean something else, it exists as an independent object that can be fetched by its id.

The invalid Delete activity 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@activitypub.space]

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)) where Object is the root-level post, it occasionally would send out Deletes where the sender is not the owner of the object. This is the 1b12-speaking logic.

In 7888-speaking logic, Object would 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.

[julian@activitypub.space]

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?

[silverpill@mitra.social]

@julian

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.

[julian@community.nodebb.org]

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?

[silverpill@mitra.social]

@julian Client generated collections are impractical. Collections are dynamic by nature, they can be paginated, filtered.
That's why there is no Create(Collection), Update(Collection) and Delete(Collection).

[julian@activitypub.space]

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

[rimu@piefed.social]

Try doing a bare delete (no announce wrapper), with the actor being the moderator who deleted the post.

Federation

(join-lemmy.org)

[julian@activitypub.space]

Thanks Rimu. Will give this a shot.

Upon reflection, since Deletes aren't wrapped in an Announce, then I would recommend that any Move activity we use not be wrapped in Announce either.

[rimu@piefed.social]

Yes I'm fine with that. It doesn't make much difference in the end.