Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Archive old messages #58

Open
robby1066 opened this issue Jun 8, 2021 · 1 comment
Open

Archive old messages #58

robby1066 opened this issue Jun 8, 2021 · 1 comment

Comments

@robby1066
Copy link
Owner

What's the problem you're hoping this new feature will solve?

Messages currently have no expiration dates, and can be viewed indefinitely. This probably doesn't serve too much of a purpose in most cases, but it likely matches user expectations. It's expensive to store all those files on the server, however.

Moving old messages that are unlikely to be viewed again to archive storage would save money, and if done correctly, would have minimal impact on user experience.

Description of feature

An 'archive' feature would flag the video stored in S3 for storage as either:

  • S3 Standard-IA
  • S3 One Zone-IA
  • S3 Glacier

research needs to be done to determine the best option for the archive storage class

This change should be reversible with minimal interaction from the user. Likely, this can be done in a way based on access. When a message has not been accessed for a certain amount of time (~30 days), it's put into archive state. If someone tries to access it again, they're presented with a message saying the message is being fetched (this will depend on the restore times from the infrequent access S3 classes), and then they'll be able to view the message after it restores. Next time it goes more than 30 days without being accessed, it's archived again.

Alternatives and workarounds

No current way to do this in the app.

@robby1066
Copy link
Owner Author

After a little bit of research, it looks like the simplest version of this can happen all in AWS configuration. That seems like a reasonable place to start, and then if needed look for fine-tuning options that are more hands-on down the road.

This has a fair bit of overlap with some of the other things going on, like #57. I'll leave this out of the June milestone so those other issues can get the focus they need. Once they're done, it will be more clear how much impact this change will have.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant