fixes #124

[indomitableSwan]

Fixes #124.

[indomitableSwan]

Thanks, this makes sense to me. Just left a couple of clarifying questions.

Also wanted to note that I may have to come back to the actual naming of the stored object because I had to define a StoredSecret object for storing an Encrypted<Secret> with its KeyId in the database. I was going to drop a question in the generate PR on whether we need that type if the associated data in the Encrypted has the KeyId too, so the name here might be based on that answer.

Ah, in terms of naming, I'll just note that the spec isn't trying to dictate names, per se, just sometimes using a bit of pseudocode helps for precision. In terms of the implementation and avoiding overlap with existing objects in the code... I think that's a good question for @marsella.

[marsella]

Yep, I was thinking we could use a similar abstraction as for encryption -- like, create a LocalStorage<T> whose constructor takes a &T and that "prepares it for storage", which in this case is just copying it. But later if we do something else, like encrypt it using a local-storage key, we just have to update the LocalStorage constructor.