Deleted posts still show up on the fediverse

[vanitasvitae]

Hi! While we're at it... :D If I create a post in my blog and later decide to delete it, the post still shows up from within mastodon. Only if I copy the link to the toot and open it in a browser, I get a 404 on my blog. I don't think that this is a caching issue, as the post is still available on mastodon after a few hours.

Keep up the great work!

[pfefferle]

I will have a look at mastodon/activitypub if there is a delete action.

[GidiKroon]

Deleted or trashed posts are indeed not deleted from the fediverse. I suspect unpublished posts aren't either. There is a Delete activity in the spec, section 7.4. Mastodon, Friendica and Pleroma say they support this. See e.g. https://git.pleroma.social/pleroma/pleroma/issues/682

[vanitasvitae]

Relevant section of the spec.

[lapineige]

I have the same issue. Any update on this ?

[GidiKroon]

I see that delete is now implemented in the code, however testing it shows that it doesn't yet work. I think it is because a callback is used which isn't implemented. From my log:

[24-Nov-2019 21:38:24 UTC] PHP Warning:  call_user_func_array() expects parameter 1 to be a valid callback, class 'Activitypub\Activitypub' does not have a method 'schedule_delete_activity' in /srv/data/web/vhosts/gidikroon.eu/htdocs/wp-includes/class-wp-hook.php on line 288

(The action hook trash_post also doesn't seem to exist in the documentation; it suggests wp_trash_post and delete_post)

Also, in the schedule_post_activity in that same file, a different argument to activitypub_send_delete_activity is used than the handler itself is expecting. I tried to fix these things locally, but since I totally don't know what I'm doing I didn't succeed.

[michaeljamesdunn]

I see this is being worked on for a future release and that's cool. I'm curious if anyone knows of a workaround for managing fediverse posts in the meantime? Not only deleting posts but even correcting typos and so forth.

[lapineige]

And I have an additional question: when this feature will be release, will we be able to delete older publications ?

Not only deleting posts but even correcting typos and so forth.

Some software won't allow you to edit the content (in particular, Mastodon doesn't support that). So I think it's more versatile to delete&repost.

[pfefferle]

I would not recommend to delete&repost on updates, because it breaks the complete comment/boost/like/share history and might cause inconsistency. I would prefer, to convince @Gargron to support federated updates in Mastodon.

[lapineige]

Indeed that's a loss, but I was more thinking about the use case when you publish some content, you check its look from Mastodon (or another federated software), and it looks bad / have typo / … then you "edit" (delete&repost) it a short time after publishing. So most of the time few or no federated interaction (comment/share/like/bookmarks/…) will be lost.

I'm not sure Mastodon will ever integrate such a possibility, and if it will it doesn't seem to be in the near horizon. Until that potential moment, imho delete&repost is the best that we can do to stay compatible with Mastodon. I don't mean an edit feature is not necessary/useful, but it comes with the cost of not being supported by a lot of software (mastodon/pleroma/… ?).

[pfefferle]

Indeed that's a loss, but I was more thinking about the use case when you publish some content, you check its look from Mastodon (or another federated software), and it looks bad / have typo / … then you "edit" (delete&repost) it a short time after publishing. So most of the time few or no federated interaction (comment/share/like/bookmarks/…) will be lost.

Bu then it might be very tricky to handle it properly on the WordPress site. I see your point, but what about small change some days/weeks/years ago.

One example: WordPress introduced Gutenberg as new editor. I updated a lot of my old posts, to be Gutenberg compatible. These changes are mostly cosmetic changes, with no real content updates, but it would have:

• killed the complete reaction history
• pop up (several times) in the timeline of all of my followers (depending on how often I hit the save button) and might be very spammy
• caused a lot of GithHub/Support issues, because it might be misinterpreted as a bug/issue

[lapineige]

But then it might be very tricky to handle it properly on the WordPress site.

What do you mean ?

but what about small change some days/weeks/years ago.

Editing it would still be interesting, but we'll know that Mastodon and other client won't support it. It will stay like this (or be removed if we delete it). And if the published content was not the full article content, maybe it's not a big deal as the changes might not after what federated viewers will see.

pop up (several times) in the timeline of all of my followers (depending on how often I hit the save button) and might be very spammy

I'm not arguing that any update should trigger a delete&republish. My point is that the workaround for "not being able to edit a post" is to manually delete the content and then publish it again. I see that workflow mainly as a short term tool.

Here is my main use case: I try different publishing format (because I never remember which one looks like what, and had several surprises in the past). Right now if I can't delete the federated content (by changing my blog post visibility from public to draft), if I do several tries, it's several duplicates with probably a lot of broken looks. So if I the first publication is wrongly formatted, it'll stay as it is forever. My only choice is to publish a double with the right formatting. The same goes for a typo in the tittle, for instance.

[pfefferle]

Ok, I see! Makes sense!

[lapineige]

Sorry if I wasn't clear.

Also, that's why I think having the possibility to delete content takes precedence over editing, as it fixes some majors issues (content impossible to remove, including private content published by error, and so on) and also can fix a small "editing" use case (the one I explained before).

[pfefferle]

(The action hook trash_post also doesn't seem to exist in the documentation; it suggests wp_trash_post and delete_post)

Also, in the schedule_post_activity in that same file, a different argument to activitypub_send_delete_activity is used than the handler itself is expecting. I tried to fix these things locally, but since I totally don't know what I'm doing I didn't succeed.

The problem with "delete" is, that WordPress changes the permalink and some other things when a post is trashed... and all of the hooks are called after the post is deleted, so I have to find a way to (manually) fix the permalinks, because they are used as IDs for AP.

[lapineige]

That looks complicated 😅

Lets us know if we can help you :)

[pfefferle]

Latest master version should now support "delete" but I have to add some tests before the new release, because I changed a lot!

[PhieF]

On my side I guess delete still doesn't work on 0.12.0 :(

Sorry and thanks for your work !

[mediaformat]

@pfefferle i've just made some tests and it seems the generate_id function returns home_url(/?p={post_id}) when the post is in the trash, this causes the Delete activity to fail, because it references a different object id than the slug that was published.

It would be possible to fake the slug based on sanitized title and permalink settings, but this makes some assumptions. Another possibility would be to save this permalink to a meta field.

Ultimately though, it might make most sense to have the AP object id be related to this post id. This would be more robust when federating an Update allowing for slug changes as well.

[pfefferle]

sure, but we have to think about backwards compatibility then, I think.

[mediaformat]

Yes we should provide a methode. I've tested this manually by sending a Delete activity with the original post URL.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[mediaformat]

Will fix

[mediaformat]

TLDR: Delete using a hack & maintain fediverse interactions vs. Change to robust IDs breaking or supporting existing interactions

Depending on the importance of maintaining Backwards Compatibility (existing Post interactions in the Fediverse), consider the following 2 approaches:

1. Keep existing AP Object ID (pretty-permalink) Pros: Keeps interaction history on the Fediverse (Comments will still appear linked to Original post) Cons: System is brittle, Changing Post slug or permalink structure breaks Interaction history

2. Change to reference Post ID (ugly-permalink) Pros: More resilient to slug and permalink changes, End user won't have to consider Cons: Break backwards compatibility, or Support Backwards compatibility but at a cost (require upgrade scripts, and a non-trivial amount of checks and refactor which would ultimately slow down Feature development).

[vanitasvitae]

What would be the consequences of the second approach? Would the change in behavior affect the rest of the WP installation?

[mediaformat]

@vanitasvitae no effect to the WP installation

[lapineige]

What backwars compatibility will this break ? Just the link to fediverse post in the comments ?

For my part I'm fine with that, we still have account names and comment datetime, we can find them again if needed.

[mwt]

Mastodon's backend now understands edited posts. You can't actually edit them in the frontend yet because gargon is waiting for more people to update.

[shaunrobinson]

Hey, is there any update on this? It's quite a problem if you can never delete a post that get federated!

[mediaformat]

@shaunrobinson Yes, it's included in https://github.com/pfefferle/wordpress-activitypub/pull/142

[gbraad]

I got bitten by an unwanted post, the (trash restore) Privacy Policy page. Is there a way to force the deletion/edit?