Reconciling ActivityPub Deletes with NodeBB deletion
-
@julian
I don't know how it works at ActivityPub level, but would it make sense to represent a soft delete as an update to the visibility of the object? Like as a Mastodon user, if I changed a post to private?wrote on 8. maj 2024, 15.08 sidst redigeret af@blaue_Fledermaus@mstdn.io — interesting idea, but 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.
One is defined in the object itself (
to,cc, etc.), whereas if a post is deleted, it simply ceases to exist or becomes a Tombstone. -
For a lot of things in ActivityPub, there are almost direct parallels in NodeBB. An
as:Noteobject pairs well with a NodeBB post, anas:Personis a NodeBB user, etc.One thing that didn’t map 1:1 was the
Deleteactivity, which at surface level, seems rather straightforward — just delete the object! However, once you dig in, there are some additional considerations:- in NodeBB, we have two separate states for content removal.
- A delete, where the post is still present (but its content unavailable to non-privileged users), and a
- A purge, where the post is scrubbed from the database entirely, and all references to it, removed
- in ActivityPub, there is a single activity,
as:Delete - Implementors may opt to replace the object representation with an
as:Tombstone(how quaint!), but they may also just opt to use a 404
So there are some nuances that are left intentionally vague.
Kaniini on SocialHub makes the argument that a Delete should be treated like a cache invalidation, which has its own merits.
This is how NodeBB will interpret the protocol specification, and how we will align it with our own dual-state post deletion mechanic (delete & purge):
- When a local post is deleted, we will federate out an
Update(Tombstone)referencing the id - Afterwards, if the content is retrieved, an
as:Tombstonewill be served.- Deleted posts in NodeBB still maintain their place in the topic, so when the context is retrieved, the note will still be present in the collection.
- If we receive an
Update(Tombstone), we will delete the local representation of the post - When a local post is purged, we will federate out a
Delete(Note) - Afterwards, if the content is retrieved, we will serve a 404
- The note will no longer exist in the context collection
- 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)
- If we see an
I’m writing this out less as a guideline for myself, but to solicit opinions and to give others a chance to point out if I’ve interpreted the spec incorrectly.
wrote on 8. maj 2024, 16.54 sidst redigeret afJust my thought, but the whole Delete then Purge has always irritated me.
Delete should just be Delete.
If a Mod wants to temporarily hide something they could move post, or delete and keep a copy.
The only thing Delete then Purge does is add extra step to removing something! - in NodeBB, we have two separate states for content removal.
-
Just my thought, but the whole Delete then Purge has always irritated me.
Delete should just be Delete.
If a Mod wants to temporarily hide something they could move post, or delete and keep a copy.
The only thing Delete then Purge does is add extra step to removing something!wrote on 8. maj 2024, 17.12 sidst redigeret af@eeeee said in Reconciling ActivityPub Deletes with NodeBB deletion:
> The only thing Delete then Purge does is add extra step to removing something!Technically they needn’t be two steps. You could just go straight to purge.
We toyed with the idea of removing deletes altogether… not sure where we landed haha @baris?
-
For a lot of things in ActivityPub, there are almost direct parallels in NodeBB. An
as:Noteobject pairs well with a NodeBB post, anas:Personis a NodeBB user, etc.One thing that didn’t map 1:1 was the
Deleteactivity, which at surface level, seems rather straightforward — just delete the object! However, once you dig in, there are some additional considerations:- in NodeBB, we have two separate states for content removal.
- A delete, where the post is still present (but its content unavailable to non-privileged users), and a
- A purge, where the post is scrubbed from the database entirely, and all references to it, removed
- in ActivityPub, there is a single activity,
as:Delete - Implementors may opt to replace the object representation with an
as:Tombstone(how quaint!), but they may also just opt to use a 404
So there are some nuances that are left intentionally vague.
Kaniini on SocialHub makes the argument that a Delete should be treated like a cache invalidation, which has its own merits.
This is how NodeBB will interpret the protocol specification, and how we will align it with our own dual-state post deletion mechanic (delete & purge):
- When a local post is deleted, we will federate out an
Update(Tombstone)referencing the id - Afterwards, if the content is retrieved, an
as:Tombstonewill be served.- Deleted posts in NodeBB still maintain their place in the topic, so when the context is retrieved, the note will still be present in the collection.
- If we receive an
Update(Tombstone), we will delete the local representation of the post - When a local post is purged, we will federate out a
Delete(Note) - Afterwards, if the content is retrieved, we will serve a 404
- The note will no longer exist in the context collection
- 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)
- If we see an
I’m writing this out less as a guideline for myself, but to solicit opinions and to give others a chance to point out if I’ve interpreted the spec incorrectly.
- in NodeBB, we have two separate states for content removal.
-
@julian i still say delete only makes sense as a cache invalidation when it comes to remote content. that hasn’t changed
wrote on 8. maj 2024, 20.45 sidst redigeret af@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! -
For a lot of things in ActivityPub, there are almost direct parallels in NodeBB. An
as:Noteobject pairs well with a NodeBB post, anas:Personis a NodeBB user, etc.One thing that didn’t map 1:1 was the
Deleteactivity, which at surface level, seems rather straightforward — just delete the object! However, once you dig in, there are some additional considerations:- in NodeBB, we have two separate states for content removal.
- A delete, where the post is still present (but its content unavailable to non-privileged users), and a
- A purge, where the post is scrubbed from the database entirely, and all references to it, removed
- in ActivityPub, there is a single activity,
as:Delete - Implementors may opt to replace the object representation with an
as:Tombstone(how quaint!), but they may also just opt to use a 404
So there are some nuances that are left intentionally vague.
Kaniini on SocialHub makes the argument that a Delete should be treated like a cache invalidation, which has its own merits.
This is how NodeBB will interpret the protocol specification, and how we will align it with our own dual-state post deletion mechanic (delete & purge):
- When a local post is deleted, we will federate out an
Update(Tombstone)referencing the id - Afterwards, if the content is retrieved, an
as:Tombstonewill be served.- Deleted posts in NodeBB still maintain their place in the topic, so when the context is retrieved, the note will still be present in the collection.
- If we receive an
Update(Tombstone), we will delete the local representation of the post - When a local post is purged, we will federate out a
Delete(Note) - Afterwards, if the content is retrieved, we will serve a 404
- The note will no longer exist in the context collection
- 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)
- If we see an
I’m writing this out less as a guideline for myself, but to solicit opinions and to give others a chance to point out if I’ve interpreted the spec incorrectly.
wrote for 30 dage siden sidst redigeret af@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?
- in NodeBB, we have two separate states for content removal.
-
Just my thought, but the whole Delete then Purge has always irritated me.
Delete should just be Delete.
If a Mod wants to temporarily hide something they could move post, or delete and keep a copy.
The only thing Delete then Purge does is add extra step to removing something!wrote for 30 dage siden sidst redigeret afeeeee: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.
-
A activitypub@community.nodebb.org shared this topic for 30 dage siden
-
@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?
wrote for 27 dage siden sidst redigeret afNo, there have been no major concerns arising out of this.
A couple observations:
- 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.
- 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. -
wrote for 27 dage siden sidst redigeret af
Thanks for clarifying.
julian:- 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
julian:Update(Tombstone)really makes sense. I can see why you took that approach. I'm just mulling the implications, particularlyIt 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.
-
Thanks for clarifying.
julian:- 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
julian:Update(Tombstone)really makes sense. I can see why you took that approach. I'm just mulling the implications, particularlyIt 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.
wrote for 27 dage siden sidst redigeret afI can look into putting together an FEP for this. It would solidify the concepts and open it up for wider discussion if necessary.
-
wrote for 27 dage siden sidst redigeret af
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):
https://socialhub.activitypub.rocks/t/the-delete-activity-and-its-misconceptions/137
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
- On soft delete:
- Convert
(Note|Article)toTombstone - Federate
Delete(Note|Article)
- Convert
- On hard delete:
- Delete
(Note|Article) - Federate
Delete(Note|Article)
- Delete
ReceiverReceives
Delete(Note|Article)- Remote
(Note|Article)returnsTombstone- Convert
(Note|Article)toTombstone - Soft-delete associated post.
- Convert
- Remote
(Note|Article)returns 404 (or 410)- Delete
(Note|Article) - Hard-delete associated post.
- Delete
- If we see an
-
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):
https://socialhub.activitypub.rocks/t/the-delete-activity-and-its-misconceptions/137
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
- On soft delete:
- Convert
(Note|Article)toTombstone - Federate
Delete(Note|Article)
- Convert
- On hard delete:
- Delete
(Note|Article) - Federate
Delete(Note|Article)
- Delete
ReceiverReceives
Delete(Note|Article)- Remote
(Note|Article)returnsTombstone- Convert
(Note|Article)toTombstone - Soft-delete associated post.
- Convert
- Remote
(Note|Article)returns 404 (or 410)- Delete
(Note|Article) - Hard-delete associated post.
- Delete
wrote for 26 dage siden sidst redigeret afAgreed. That makes sense since receiving a
Deleteshould trigger a cache invalidation, so there’s no reason it need be a different activity. I will make the appropriate changes soon. - If we see an
-
wrote for 26 dage siden sidst redigeret af
Angus, while I haven’t made the appropriate changes to NodeBB’s implementation yet, I did draft an FEP including the changes we discussed.
https://github.com/julianlam/feps/blob/main/fep/15c5/fep-15c5.md
It is not PR’d upstream yet, but I will do so in the coming days unless there are some concerns.
-
wrote for 26 dage siden sidst redigeret af
I recognize that this makes the
Deleteactivity 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. -
I recognize that this makes the
Deleteactivity 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.wrote for 26 dage siden sidst redigeret afHi @trwnh,
I'd prefer expiry + renewal over cache invalidation or deletion every time. https://www.w3.org/TR/activitystreams-vocabulary/#dfn-endtimeThis way data sets could also auto-clean abandoned actors and servers.
-
No, there have been no major concerns arising out of this.
A couple observations:
- 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.
- 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.wrote for 25 dage siden sidst redigeret afIt'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.
-
For a lot of things in ActivityPub, there are almost direct parallels in NodeBB. An
as:Noteobject pairs well with a NodeBB post, anas:Personis a NodeBB user, etc.One thing that didn’t map 1:1 was the
Deleteactivity, which at surface level, seems rather straightforward — just delete the object! However, once you dig in, there are some additional considerations:- in NodeBB, we have two separate states for content removal.
- A delete, where the post is still present (but its content unavailable to non-privileged users), and a
- A purge, where the post is scrubbed from the database entirely, and all references to it, removed
- in ActivityPub, there is a single activity,
as:Delete - Implementors may opt to replace the object representation with an
as:Tombstone(how quaint!), but they may also just opt to use a 404
So there are some nuances that are left intentionally vague.
Kaniini on SocialHub makes the argument that a Delete should be treated like a cache invalidation, which has its own merits.
This is how NodeBB will interpret the protocol specification, and how we will align it with our own dual-state post deletion mechanic (delete & purge):
- When a local post is deleted, we will federate out an
Update(Tombstone)referencing the id - Afterwards, if the content is retrieved, an
as:Tombstonewill be served.- Deleted posts in NodeBB still maintain their place in the topic, so when the context is retrieved, the note will still be present in the collection.
- If we receive an
Update(Tombstone), we will delete the local representation of the post - When a local post is purged, we will federate out a
Delete(Note) - Afterwards, if the content is retrieved, we will serve a 404
- The note will no longer exist in the context collection
- 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)
- If we see an
I’m writing this out less as a guideline for myself, but to solicit opinions and to give others a chance to point out if I’ve interpreted the spec incorrectly.
wrote for 9 dage siden sidst redigeret afA little semantics thing: I'd argue that HTTP 410 and as:Tombstone are semantically equivalent, i.e.
- an
as:Tombstoneshould always be served with the HTTP 410 status, and - A HTTP 410 status should be treated as a tombstone
Software unaware of tombstones will then treat it as a hard delete. "Fully" tombstone aware software can then use logic like
if (status == 200 && contentType is as2) { // treat as normal} else if (status == 410 && contentType is as2 && in body.type) { // also treat as normal} else if (status == 410) { // synthesize a tombstone} else if (status == 404) { // hard delete?} else // existing error handling logic - in NodeBB, we have two separate states for content removal.
