Summary Since it first opened, mastodon.social has operated without any sort of explicit IP grant from the users to the service, which is unusual for a social networking service. Today Mastodon ann...
So CAP theorem says you can have a distributed system with at most two of Consistent, Available, or Partition tolerant. I haven’t looked too closely into the federation implementation of Mastodon but I suspect they opted for Available and Partition tolerant (as Consistent and Partition tolerant would mean the entire network goes down when one node does, while Consistent and Available would mean once any node lost contact with the network it could never again rejoin). Since consistency is not guaranteed (and provably can’t be) there is absolutely no way to guarantee that deleting something from one instance will remove it from all instances even allowing for a very generous time span.
TL;DR: You’re not just right, you’re mathematically right.
There’s also the fact that instances can simply choose to ignore delete requests. Because that’s all it is; A request. Let’s say I post on .world and it gets federated to other instances. If I then delete that .world post, there’s nothing requiring those other instances to actually delete anything. .world simply sends a delete request, but the individual instances can choose to ignore it if they want.
That’s a large part of why the “I delete my content after a day or two so LLMs can’t use my data” crowd is so stupid. If someone was looking to train an LLM on Lemmy data, they’d simply set up an instance to aggregate posts, and refuse to delete anything.
Mastodon’s federation is not at all consistent even when it could get much closer with a little effort.
Servers don’t remote fetch old posts from recent follows for example, nor replies to off-server posts from people on a third server. There’s work being done on both, but I’m surprised it wasn’t prioritized much earlier. Some other Fediverse software handles these situations better.
So CAP theorem says you can have a distributed system with at most two of Consistent, Available, or Partition tolerant. I haven’t looked too closely into the federation implementation of Mastodon but I suspect they opted for Available and Partition tolerant (as Consistent and Partition tolerant would mean the entire network goes down when one node does, while Consistent and Available would mean once any node lost contact with the network it could never again rejoin). Since consistency is not guaranteed (and provably can’t be) there is absolutely no way to guarantee that deleting something from one instance will remove it from all instances even allowing for a very generous time span.
TL;DR: You’re not just right, you’re mathematically right.
There’s also the fact that instances can simply choose to ignore delete requests. Because that’s all it is; A request. Let’s say I post on .world and it gets federated to other instances. If I then delete that .world post, there’s nothing requiring those other instances to actually delete anything. .world simply sends a delete request, but the individual instances can choose to ignore it if they want.
That’s a large part of why the “I delete my content after a day or two so LLMs can’t use my data” crowd is so stupid. If someone was looking to train an LLM on Lemmy data, they’d simply set up an instance to aggregate posts, and refuse to delete anything.
Mathematically right, the best kind of right.
Mastodon’s federation is not at all consistent even when it could get much closer with a little effort.
Servers don’t remote fetch old posts from recent follows for example, nor replies to off-server posts from people on a third server. There’s work being done on both, but I’m surprised it wasn’t prioritized much earlier. Some other Fediverse software handles these situations better.