agnos.is Forums

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

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.

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.

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.

@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?

Hello @renchap, thanks for following up. I think the way to tackle this is a version of the following:

1. We agree on a normative approach to the use of context. <--- Discourse, NodeBB, Wordpress and others essentially agree on this already, but it would be helpful to clarify and include folks from Mastodon.
2. We develop a generalised implementation agenda. Generalised, but with the needs of different platforms in mind.
3. Individual implementers adapted the generalised implementation agenda to their specific circumstances. However that works with their individual development cycles / practices.

I suggest we start work on 1 and 2 now and discuss them both further in person at the next Threadiverse Working Group meeting at the start of March. The group was set up to address these questions.

@devnull @trwnh @pfefferle If you're on board with this, let's seize this rare opportunity of having the relevant players involved and finally settle this question so we can move forward. If so, could one of you please start a new topic in #activitypub:threadiverse-wg addressing where we're currently at with 1 as you're both better across this currently than I am.

cc @nutomic @silverpill

You're not wrong. I would make a PR to mastodon, but I fear it would languish in review for years. There has to be a better solution to this though.

julian:

When I refactored my 1b12 implementation, I actually removed the second Announce(Object), but I think I will add it back.

I would gently suggest that sending both Announce(Object) and Announce(Create(Object)) to all followers for the same content is not a good solution to the problem. Yes, other implementors can come up with ways to handle that (I just deployed the Discourse solution to this duplication to SoicalHub), but it's hardly ideal.

I recently switched the Discourse plugin back to only Announcing the first Create(Note) in a topic (Collection), but not replies, or updates, as announcing everything was causing issues with Mastodon.