| ▲ | FloorEgg 8 hours ago | |||||||||||||
I'm not commenting on the core point of your comment, only the "why retain for 30 days" question. Im an age of automated backups and failovers, deleting can be really hard. Part of the answer could simply be that syncing a delete across all the redundancies (while ensuring those redundancies are reliable when a disaster happens and they need to recover or maintain uptime) may take days to weeks. Also the 30 days could be the limit, as oppose to the average or median time it takes. | ||||||||||||||
| ▲ | chasd00 7 hours ago | parent | next [-] | |||||||||||||
The most likely explanation is whatever storage solution they’re using has a built in “recycle bin” functionality and deleted data stays the for 30 days before it’s actually deleted. I see this a lot in very large databases. The recycle bin functionality is built in to the data store product. | ||||||||||||||
| ||||||||||||||
| ▲ | chemotaxis 4 hours ago | parent | prev | next [-] | |||||||||||||
> I'm not commenting on the core point of your comment, only the "why retain for 30 days" question. Im an age of automated backups and failovers, deleting can be really hard. I doubt it's that. Deletion is hard, but it's not "exactly 30 days" hard. The most likely explanation is that OpenAI wants the ability to investigate abuse and / or publicly-made claims ("ChatGPT told my underage kid to <x>!" / "ChatGPT praised Hitler!"). If they delete chats right away, they're flying blind and you can claim anything you want. Now, whether you should have a "delete" button that doesn't really delete stuff is another question. | ||||||||||||||
| ▲ | dylan604 7 hours ago | parent | prev [-] | |||||||||||||
What is the standard way of being forced to restore from backup while ensuring deleted data does not also become restored? Is every delete request stored so that it can be replayed against any restore? | ||||||||||||||
| ||||||||||||||