Rust seems to be designed to last a very long time. With the default features, the ID timestamps will only last about 136 years into the future, and there is a feature that decreases the precision of timestamps, and a feature that extends the timestamp period to 34841 years.
I feel like there could be a significant number of users/developers (in about 136 years) who would be caught off guard if the default settings for this library were enabled, and if the EPOCH date wasn't being routinely updated in their backends.
It makes a little sense to make the features subtractive, but I feel like the optimal solution would be to implement a MasterKey as in #1. Or mayhaps there could be a timestamp compression-level parameter rather than a feature, or there could be a Config struct similar to base64 if it feels like there are too many parameters for IDs.
Rust seems to be designed to last a very long time. With the default features, the ID timestamps will only last about 136 years into the future, and there is a feature that decreases the precision of timestamps, and a feature that extends the timestamp period to 34841 years.
I feel like there could be a significant number of users/developers (in about 136 years) who would be caught off guard if the default settings for this library were enabled, and if the EPOCH date wasn't being routinely updated in their backends.
It makes a little sense to make the features subtractive, but I feel like the optimal solution would be to implement a
MasterKeyas in #1. Or mayhaps there could be a timestamp compression-level parameter rather than a feature, or there could be a Config struct similar tobase64if it feels like there are too many parameters for IDs.