julian on Nostr: For a lot of things in ActivityPub, there are almost direct parallels in NodeBB. An ...
For a lot of things in ActivityPub, there are almost direct parallels in NodeBB. An as:Note object pairs well with a NodeBB post, an as:Person is a NodeBB user, etc.
One thing that didn't map 1:1 was the Delete activity, which at surface level, seems rather straightforward — just delete the object! However, once you dig in, there are some additional considerations:
<li>in NodeBB, we have two separate states for content removal.
<ul>
<li>A delete, where the post is still present (but its content unavailable to non-privileged users), and a</li>
<li>A purge, where the post is scrubbed from the database entirely, and all references to it, removed</li>
</ul>
</li>
<li>in ActivityPub, there is a single activity, <code>as:Delete</code></li>
<li>Implementors <em>may</em> opt to replace the object representation with an <code>as:Tombstone</code> (how quaint!), but they may also just opt to use a 404</li>
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](https://socialhub.activitypub.rocks/t/the-delete-activity-and-its-misconceptions/137 ), 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):
<li>When a local post is deleted, we will federate out an <code>Update(Tombstone)</code> referencing the id</li>
<li>Afterwards, if the content is retrieved, an <code>as:Tombstone</code> will be served.
<ul>
<li>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.</li>
</ul>
</li>
<li>If we receive an <code>Update(Tombstone)</code>, we will delete the local representation of the post</li>
<li>When a local post is purged, we will federate out a <code>Delete(Note)</code></li>
<li>Afterwards, if the content is retrieved, we will serve a 404
<ul>
<li>The note will no longer exist in the context collection</li>
</ul>
</li>
<li>If we receive a <code>Delete(Note)</code> (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:
<ul>
<li>If we see an <code>as:Tombstone</code>, we will delete the post (soft delete)</li>
<li>If we encounter a 404 or 410, we will purge the post (hard delete)</li>
</ul>
</li>
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.
One thing that didn't map 1:1 was the Delete activity, which at surface level, seems rather straightforward — just delete the object! However, once you dig in, there are some additional considerations:
<li>in NodeBB, we have two separate states for content removal.
<ul>
<li>A delete, where the post is still present (but its content unavailable to non-privileged users), and a</li>
<li>A purge, where the post is scrubbed from the database entirely, and all references to it, removed</li>
</ul>
</li>
<li>in ActivityPub, there is a single activity, <code>as:Delete</code></li>
<li>Implementors <em>may</em> opt to replace the object representation with an <code>as:Tombstone</code> (how quaint!), but they may also just opt to use a 404</li>
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](https://socialhub.activitypub.rocks/t/the-delete-activity-and-its-misconceptions/137 ), 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):
<li>When a local post is deleted, we will federate out an <code>Update(Tombstone)</code> referencing the id</li>
<li>Afterwards, if the content is retrieved, an <code>as:Tombstone</code> will be served.
<ul>
<li>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.</li>
</ul>
</li>
<li>If we receive an <code>Update(Tombstone)</code>, we will delete the local representation of the post</li>
<li>When a local post is purged, we will federate out a <code>Delete(Note)</code></li>
<li>Afterwards, if the content is retrieved, we will serve a 404
<ul>
<li>The note will no longer exist in the context collection</li>
</ul>
</li>
<li>If we receive a <code>Delete(Note)</code> (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:
<ul>
<li>If we see an <code>as:Tombstone</code>, we will delete the post (soft delete)</li>
<li>If we encounter a 404 or 410, we will purge the post (hard delete)</li>
</ul>
</li>
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.