Topic removal from a category/community

[julian@activitypub.space]

Yeah you're right, Move has some prior art for account migrations so it's worth some thinking through.

I'd like to work together on this though. I'm working through context ownership and inheritance first, but once that FEP is drafted I can move on to this.

[julian@activitypub.space]

rimu@piefed.social said in Topic removal from a category/community:
> All of these activities are enclosed in an Announce and the http POST is signed using the community key. So in a way the content 'belongs' to the community, not to the original author.

Oh that's right! That makes sense. Having the community sign the activity (and the Announce wrapper) would effectively differentiate it from a simple author-initiated content deletion.

The impetus for this question was that occasionally I will move topics out of a category for being off topic. Federated copies don't see this change reflected, so both Move and Delete are things I want to federate out in lockstep with Piefed and Lemmy.

[silverpill@mitra.social]

@rimu Still, I think it would be nice to deprecate Delete and slowly migrate to Remove(target: context), since both PieFed and Lemmy implement the context collection now.

My server rejects Delete if its actor is different from object's owner, and I have to treat Announce(Delete) as a special case where the normal processing logic doesn't apply.

[rimu@piefed.social]

Possibly although the differences of federation between the threadiverse and the rest of the fediverse go way beyond deletes. FEP 1b12 is a whole thing, chipping away at it piece by piece would be slow going.

[julian@activitypub.space]

Personally I think 1b12 doesn't need to be changed or hacked around. It doesn't specifically call for federating out deletes so I'd think any solution we come up with together would work with that FEP, not go against it.

cc silverpill@mitra.social (if your app notifies you of new replies without a direct mention I'll stop tagging you too)

[julian@community.nodebb.org]

I also think that backfill will have a side effect of connecting the threadiverse and the rest of the fediverse.

Exposing context collections will mean consumers will be able to see both *verses. Once Mastodon starts consuming them I predict you will start seeing much more engagement from the microblogs.

The same would apply if Piefed or Lemmy begin consuming them as well.

That is an angle I had not even considered until now!

[silverpill@mitra.social]

@julian

if your app notifies you of new replies without a direct mention I'll stop tagging you too

Inclusion in to or cc is enough to generate a notification.

[julian@activitypub.space]

rimu@piefed.social silverpill@mitra.social I gave this a bit more thought and I am coming around to the idea that Remove could work.

I am assuming that when Piefed sends Announce(Delete(Object)) this is only understood by Piefed? Not Lemmy (and certainly not NodeBB, yet)...

In that case, a move to a simpler Remove(target: context) signed and acted on by the community actor, would send a more explicit message that the object was removed from the community.

The "1b12-speaking" portion of it would be an Undo(Announce(Create)), although once again I am not even sure if that action is understood by Piefed/Lemmy.

[rimu@piefed.social]

only understood by Piefed? Not Lemmy

No, that's a Lemmy thing too.

[julian@activitypub.space]

Oh okay. I wasn't sure about that since I don't think it's documented in the FEP, though it's been awhile since I've given it a read through.

[julian@community.nodebb.org]

rimu@piefed.social Do you send the Undo(Announce(Create)) as well for microblog compatibility?

[rimu@piefed.social]

Looks like for Mastodon we just do a bare Delete.

[julian@community.nodebb.org]

rimu@piefed.social got it, thanks. How do you reconcile the Delete coming from outside your domain? I would figure Mastodon would drop those Deletes.

Edit: that was confusing wording... I mean — how do you sign a Delete for an object that doesn't belong to your instance?

[rimu@piefed.social]

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.

[silverpill@mitra.social]

@rimu

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 object is owned by the sending actor / server) the server receiving the delete activity SHOULD remove its representation of the object with the same id

@julian

[julian@community.nodebb.org]

I 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 Delete actor
• Verify that the community/group-actor and Delete actor are same-origin (might not need this if cross-instance moderation is a thing)
• Verify that the Delete actor is a moderator of the community/group-actor as per 1b12

[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.