This leads into my next concern which is GDPR, because now i can't be certain that a users data gets deleted upon their request and i'm not certain whether i would be liable since my instance federates with the malicious instance (which may also not be hosted in the EU which is itself problematic, and even if i'm not liable it's still not great).

I'm not a lawyer, but I have done compliance work, but not for GPDR... so take with several grains of salt.

I'd be fairly surprised if other instances caching your data had any impact on your GPDR status (unless you wrongfully made that data public in the first place).

If WordPress.com hosts an intentionally public blog post for a user, and archive.org scrapes it and saves a copy, and the user deletes it from WordPress (which correctly handles the deletion), would GPDR hold WordPress liable for a different organization retaining a copy on a different server? It would surprise me if it did, I can't imagine how anyone could be in compliance while hosting public content under any circumstances if that were so. ActivityPub is not exactly the same as this, as it automates the process of copying data to many servers. But so does RSS and that's not new. If this were an issue, I think we'd have seen examples of it before now.

It's more likely that each ActivityPub instance is a different service from GPDR's perspective, and each instance needs the capability to delete content associated with a user upon request. But I believe deletes are already federated by default, so we're only talking about malicious instances that deliberately ignore deletion requests. These would not be GPDR compliant, but I suspect that doesn't reflect on your liability.

... which may also not be hosted in the EU which is itself problematic...

Data locality is an interesting question, but I'm again inclined to suspect that YOU are not hosting data outside the EU. Other instances are, and the liability for doing so is theirs not yours.

If you were concerned about this, you could do whitelist federation where you explicitly add instances in appropriate jurisdictions rather than Federating by default with a blacklist. The opportunity cost of doing this is, of course, cultural irrelevance. You'd be cutting yourself off from most of the physical and virtual world in order to achieve improved data locality.

The loss of control over content is also something that i don't particularly like...

This is real but rather the point of federation. If you really don't like it, then federation is not for you. But consider multiple perspectives:

• As a user of reddit or another centralized publishing platform, you already didn't have control over your data. The hoster did, as did the untold millions who scraped it maliciously and silently. This does not compare favorably to the fediverse.
• As an admin of a traditional forum like PHPBB, you do give up control in the Fediverse. Though when you account for malicious scrapers, how much you give up is debatable.
• But as a user of that PHPBB forum, the fediverse gives you MORE control. If the admin of that non-federated forum throws a tantrum and shuts it down, the community and posts are lost. As a user in the Fediverse, federation allows users on other instances to retain their account identity, recover posts from caches, and re-establish their community elsewhere against the wishes of the previous hoster.

Federation does require the hoster to give up power, but more than equally increases the power of users in return. Like GPDR, federation aims at increasing the data autonomy of users, but rather than focusing on privacy and data destruction to facilitate a user who wants to take their toys and go home, it focuses on how users can continue to access their data usefully in the face of an admin who want to take their toys and go home. Although the means to achieve them are often in conflict... control over data destruction and control over data preservation are two sides of the same data-autonomy coin.