@ariadne@social.treehouse.systems right. I think functionally I'll never encounter a Delete, check the origin, and find that the note hasn't actually been deleted, but stranger things have happened!

@julian I'm focusing on Deletion (both Notes and Actors) in Discourse at the moment and I'm thinking of essentially adopting the approach you've outlined here. Have there been any updates to your approach since you wrote this?

eeeee:

The only thing Delete then Purge does is add extra step to removing something!

Discourse also uses a "soft delete" (we call it "Trash(ed)"). The main point of it is that it allows restoration if the delete was in error.

julian:

my gut feeling is no, because post visibility (which at present, NodeBB doesn't even support at all) and deletion are two separate properties in ActivityPub.

I agree.

No, there have been no major concerns arising out of this.

A couple observations:

1. There is a mismatch between what other instances expect for deletions and what actually happens. A Mastodon user deleting post expects it to be gone for good, but on our end it will simply be soft deleted. This isn't a major issue, it just means admins get to see all the deleted stuff (useful when people say hurtful things, delete them, and pretend they never happened.) Even then it's only a small percentage, most of the deleted stuff I see are for fixing typos.
2. I am reasonably sure that nobody else besides NodeBB (and now Discourse) knows what to do with an Update(Tombstone), so nothing happens. It means soft deleted posts on our end are essentially ignored and still visible.

The latter may actually be a concern and warrant an admin-side option to explicitly federate out a Delete.

Thanks for clarifying.

julian:

1. I am reasonably sure that nobody else besides NodeBB (and now Discourse) knows what to do with an Update(Tombstone), so nothing happens. It means soft deleted posts on our end are essentially ignored and still visible.

The latter may actually be a concern and warrant an admin-side option to explicitly federate out a Delete.

Yeah, I'm currently weighing this one. I'm wondering whether Update(Tombstone) really makes sense. I can see why you took that approach. I'm just mulling the implications, particularly

julian:

It means soft deleted posts on our end are essentially ignored and still visible.

I'm currently thinking users may find this surprising and it may interfere with things like moderation. But I'm still mulling it.

I can look into putting together an FEP for this. It would solidify the concepts and open it up for wider discussion if necessary.

tbh the more I think about this, the more it feels like federating Update(Tombstone) is never going to work very well.

We'd first have to win the argument that federating Tombstones make sense at all. I found the arguments to the contrary relatively persuasive on that front (I know you're aware of this, but just giving context for other folks reading this):

I wonder if we can't just do point 6 on your list:

If we receive a Delete(Note) (or Article, or Question, etc.) we will not delete it immediately. Instead, as kaniini advises, we will attempt to retrieve the object from the origin:

• If we see an as:Tombstone, we will delete the post (soft delete)
• If we encounter a 404 or 410, we will purge the post (hard delete)

So to play that out:

PublisherPost is deleted

1. On soft delete:
   • Convert (Note|Article) to Tombstone
   • Federate Delete(Note|Article)
2. On hard delete:
   • Delete (Note|Article)
   • Federate Delete(Note|Article)

ReceiverReceives Delete(Note|Article)

1. Remote (Note|Article) returns Tombstone
   • Convert (Note|Article) to Tombstone
   • Soft-delete associated post.
2. Remote (Note|Article) returns 404 (or 410)
   • Delete (Note|Article)
   • Hard-delete associated post.

Agreed. That makes sense since receiving a Delete should trigger a cache invalidation, so there's no reason it need be a different activity. I will make the appropriate changes soon.

Angus, while I haven't made the appropriate changes to NodeBB's implementation yet, I did draft an FEP including the changes we discussed.

It is not PR'd upstream yet, but I will do so in the coming days unless there are some concerns.

I recognize that this makes the Delete activity work differently for S2S than it does C2S, which is to say that a user or client cannot distinguish between "soft delete" and "hard delete" this way. Otherwise, the "cache invalidation" idea is a sensible one.

Hi @trwnh,
I'd prefer expiry + renewal over cache invalidation or deletion every time. https://www.w3.org/TR/activitystreams-vocabulary/#dfn-endtime

This way data sets could also auto-clean abandoned actors and servers.

It's not a NodeBB in particular but it's worth mentioning another mismatch: Misskey and forks will also delete replies when a post is deleted.