Closed RangerMauve closed 3 years ago
@RangerMauve yep :+1: from me on the overall approach, and can see many benefits. Just gotta make sure it handles mounts too!
The need for this definitely highlights a shortcoming with the current Corestore API. It'd definitely be nice to have something in Corestore that would let you avoid needing to construct a big, opaque string to use as entropy for the content feed key, since now that string needs to covered by semver and all that...
Anything in particular I should watch out for on mounts? Also, is the name okay?
I was also thinking that if we could assume that all hyperdrives had a unique namespace and were using namespaced corestores, then we could use a shorter name.
@RangerMauve we were discussing some of that today, and i think we'll add a better name api in the future to make stuff like this easier (ie no key mangling yourself). one thing to look out for here, in this case, is that you should only derive it this way if it's not already specified in the header message. your pr might do that already but just wanted to point that out, then it's backwards compat.
For mounts you just gotta make sure you are using the metadata key from those to derive it - can prob catch that with some tests.
Published 10.19.0
At the moment content feeds aren't using corestore's namespace feature for deriving their private key. This makes backups a little harder since you need to keep track of both keypairs and need some way of injecting both private keys into the hyperdrive (only the metadata one is easy it seems).
This change uses corestore's
namespace
feature to derive the private key of the content feed based on the key of the metadata feed and some extra text.With this in place, hyperdrives are generated more predictably, and hyperdrives generated with a name can be re-generated on other devices for backup restoration purposes.
Does this approach make sense? Wanted to get a bit of review before I added unit tests and docs.