Mastodon: Deleting toots across instances

[taoeffect]

People post dumb/incorrect stuff accidentally sometimes. That's where deleting toots comes in handy.

My (possibly incorrect/outdated) understanding is that toot deletion does not federate across instances.

This can result in potential privacy problems, not to mention various social problems.

If a "CREATE TOOT" message can be federated across instances, I see no reason why a "DELETE TOOT" message can't be federated across instances too.

Now, this obviously has the potential, if improperly implemented, to result in censorship attacks. That's just something to think about when implementing this.

Ideally, Mastodon users would have private keys and all messages would be signed... but that's probably asking too much at this point.

EDIT: I'm told that this is an OStatus issue, and if that's the case, this problem is big enough on its own that it may be worth considering an OStatus 2.0 effort at some point. Such an effort could be used to address various other problems with OStatus as well.

---

• [x] I searched or browsed the repo’s other issues to ensure this is not a duplicate.

[taoeffect]

Kaito (@cphuntington97) shares the ActivityPub W3C effort as a possible "OStatus 2.0".

I haven't looked into it at all, so I have no idea how good (or bad) it is.

To really do this correctly, you need proper cryptographic key management (that's my area of expertise), and I doubt ActivityPub has that, but maybe it can be built on top of it?

[Gargron]

If a "CREATE TOOT" message can be federated across instances, I see no reason why a "DELETE TOOT" message can't be federated across instances too.

This happens.

[taoeffect]

This happens.

Wait, so then what about the people saying it doesn't and that it's a bug in OStatus?

Are you saying that Mastodon has special support for this while Quitter et. al. do not, and that the problem is limited to non-Mastodon instances?

(Edit: Or is this just a totally untrue rumor?!)

[lambadalambda]

There is some kind of bug that lets GS not handle the Mastodon delete notifications. That's why deleted posts will stay on GS.

Also, GS mandates crypto key management for salmons.

[bortzmeyer]

The experience of Usenet, with its control messages, leaves no doubt that such a feature would be widely used for denial-of-services attacks (deleting other people's toots) since there is no authentication of toots (in the federation, anyone can claim to be [email protected]).

Also, even if this feature would be implemented, it does not mean the privacy / right to be forgotten issues would be addressed. Think of the people who immediately do a screenshot of Twitter outrageous tweets by famous people, because they know these tweets will soon be deleted. In the same way, a rogue instance could copy everything and keep it forever, ignoring the deletion requests, even if authenticated.

So, nice idea, it would certainly be useful, but I don't see how to do it properly.

[rogerbraun]

It's already implemented and works. That it doesn't federate to GS is just a bug. Toots/Notices ARE authenticated, either through a shared secret (websub) or through public key cryptography (salmon).

[Cassolotl]

People take screenshots of tweets and people still delete tweets and it is good that Twitter has a delete function for tweets.

[lambadalambda]

Deletions still don't federate to GS.

[Gargron]

@lambadalambda Can you get me a log of why it fails? It is not evident to me, the delete message contains old URI, and the delete verb, what else does GS need?

[ikeji]

Hi

I met the cases that failed to delete.
(In this cases, all people uses different instance)

Case1: C follow B but C doesn't follow A. (C is me)

• Person A, toots X. https://friends.nico/users/hamasuho/updates/692453
• Person B boosts X.
• Person C replied to X. https://ostatus.ikeji.ma/@ikeji/355417
• A removed X.

In this case X is removed in instance for A, but is not deleted from instance B and C.

Case2:

• Person D toots Y.
• Person E boost Y. (using searchbox with URL.)
• D removed Y

In this case Y is removed in instance for D, but is not deleted from instance E.

Case3:

• Person F toots Z.
• Person G replied to Z. (using searchbox with URL.)
• F removed Z

In this case Z is removed in instance for F, but is not deleted from instance G.

Is this expected?

I'm not sure but I guess if a account is not followed by the instance,
delete action is not propagate.
because the instance didn't subscribe the user.