- Payments, particularly from P2P transactions. If I send you money, and then you request the deletion of your profile, there's plenty of complexity there.

- Enforcement records from illegal content / violating content

- Local data cache for offline mode in mobile apps

I'm not saying all of these apply to "Threads". But there are tons of edge cases to consider that need code changes t o behave as expected.

> Payments

There's really no complexity there. The right to be forgotten doesn't superseed other laws, and it is required by law in most countries, that transaction data be stored for 5 years plus running year, so in case you request to be forgotten, that can only happen once the mandatory data retainment has expired, which can easily be handled by a "transaction date", and simply run a batch job that matches each user to their transactions (and desire to be forgotten), and once transaction are expired and the user has requested to be forgotten, you simply delete.

> Local data cache for offline mode in mobile apps

The right to be forgotten has a "grace period", so set your cache expiration to less than that amount of time and you're pretty much home safe, or better yet, don't cache GDPR sensitive data and you can pretty much cache for as long as you like.

There's a lot more to payments than raw transaction data. Payments are usually related to the exchange of goods or services. The delivery data of those could be essential for winning a chargeback dispute or a liability for a customer that asked to be forgotten.

You aren’t holding raw transaction data on the basis of consent, so it doesn’t matter.

such as the ability easily support redaction of personal data?

Errg: sorry folks. I miss read the thread and thought the "such as" was responding to the comment next to it about the design flaw of not being able to delete personal data.

That's not an edge case in the law, that's a limitation in your system.

That doesn’t sound like an edge case.

And this is nasty because?