search

holepunchto / hyperdrive

Hyperdrive is a secure, real time distributed file system
Apache License 2.0
1.86k stars 135 forks source link

Use name when generating content feed #304

Closed RangerMauve closed 3 years ago

RangerMauve commented 3 years ago

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.

andrewosh commented 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!

andrewosh commented 3 years ago

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...

RangerMauve commented 3 years ago

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.

mafintosh commented 3 years ago

@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.

andrewosh commented 3 years ago

Published 10.19.0