Hacker News new | past | comments | ask | show | jobs | submit login

Yeah.

I recently began to the process of digitizing family photos and thinking about the best way to keep them around for another fifty years and found myself playing with the idea of building this kind of infrastructure.

You're still relatively early in the game - on a decades long timeframe at least - but it's worth considering these kinds of policies. Your average customer is probably not savvy enough to have a preformed opinion, but from one technologist to another I find myself naturally pedantic over what "ample notice" might mean.

If you're lucky and successful you'll eventually have to deal with stuff like, "what if the user dies, and stops paying" - do you delete the data?, and how do you handle people associated with them looking to grab the info?

Having a next-of-kin login process or a "shutdown the webview but allow people to always have access to their backups" would be considerate.

Good luck :).




Agreed. I made data-portability a key point from the start, but these scenarios are important to think through.

Some details:

* Anyone who has access to a user's stories can download a backup at any time.

* If a user stops their subscription for any reason (including death), I will notify all users who have access to those stories with the option to download a copy (or renew the subscription). Depending on the size of the data, I may even be able to include the full backup in the notification email.

* I will keep backups available for download for as long as possible after the subscription has lapsed, ideally indefinitely (this also makes resubscribing more compelling).

* For full peace of mind, I send you all the text responses by email, so you have a copy archived there. I will look into including the actual audio attachments in the emails as well.

The trickiest scenario is if a user dies and their stories aren't shared with anyone. I could assume that the person didn't want these stories shared, but I think these will have to be dealt with on a case by case basis.

[edited to fix line breaks]




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: