hyperdrive
hyperdrive copied to clipboard
hypercore-protocol
Access Rights Scheme - Multiple key-sets
From what I understand - the hyperdrive and the underlying hypercore supports a key/secret pair for encrypting it's content. Everyone holding the public key can read - and those with the secret key can write/delte. Is this correct - can you read the drive without the secret key?
It could be use cases where more differentiated access would make sense. One possible way could be to have multiple key pairs in the drive, where one might be the main key which public part must be known to all users. Then some users might additionally hold the public, or also the secret, from the other pairs. This allows them to read or make edits to "their own files" within the drive. This would technically sign their addition to the underlying hypercore with their keys. Although they could still force their edit/delete appends onto the other key-pairs' content-records - deleting a common file f.ex - these appends would be ignored if it's not the right key, or not even be understood, by the other parties.
I guess this would require some kind of key store, instead of the single key/secret pair today, and most likely an open identifier on every hypercore append-record specifying which key is used for the encryption.
In the end users would be able to see what their keys permit and edit likewise.
Would such scheme make sense for hyperdrive?
BTW: For my use case, I'm thinking about having several drives, and have a central authority (I know, we're not supposed to talk about such things in here) merge the individual users data with the common branch. This would not be pretty.
Also, it could be useful to be able to generate separate keys for every level in the folder structure. These would be stored on the parent node, maybe, to give holders of the "root key" access to everything.
Then, one could share child tree urls and key(s) with peers, without revealing the key to the whole lot.
This might not make sense technically, or performance wise, but giving someone access to a sub-tree could make lots of sense in some cases.
Everyone holding the public key can read - and those with the secret key can write/delte. Is this correct - can you read the drive without the secret key?
Yes, anyone with the public key can read. Currently only the owner, with the secret key, can write. Right now, only one person should have the secret key. There is no mechanism for avoiding corruption if multiple people write.
However! We will be adding mutli-writer support using hyperdb. This will have owners and authorized writers. Once that is in hyperdrive, you can authorize other people to write to the drive.
Going up the next level, so that there is differentiated access within a single drive sounds cool too. In the near-term, implementing that as multiple hyperdrives (like git submodules) should work. Sounds like what you are thinking here:
Also, it could be useful to be able to generate separate keys for every level in the folder structure. These would be stored on the parent node, maybe, to give holders of the "root key" access to everything.
But it seems like that should be implemented on top of hyperdrive, not within it. You can share multiple drives across the same connection, so it'd still be performant.
Thank you, this makes sense to me.
The efforts in hyperdb looks very promising, and might be a good match for my use case. However, you say "using hyperdb" above, does that mean that you will incorporate this tool into hyperdrive? Or, do you know if hyperdb will be "binary compatible" with hyperdrive in some way? Can the same hypercore instance be used for both?
I'm interested in "mounting" drives within drives, like you mention - perhaps with special link files containing keys or references for the next drive.
Thank you again - I very much enjoy learning about these promising technologies.
However, you say "using hyperdb" above, does that mean that you will incorporate this tool into hyperdrive
Yes, hyperdb will be integrated into hyperdrive afaik. Not 100% sure on how it'll work. They are all hypercore feeds underneath (hyperdrive has two, one for metadata and one for content; hyperdb has one for each authorized writer).
I'm interested in "mounting" drives within drives, like you mention - perhaps with special link files containing keys or references for the next drive.
Yep, take a look at https://github.com/substack/hyperdrive-multiwriter and https://github.com/poga/hyperdrive-ln for examples. They're both outdated but may give you some ideas on use.
Yes, hyperdb will be integrated into hyperdrive afaik. Not 100% sure on how it'll work. They are all hypercore feeds underneath (hyperdrive has two, one for metadata and one for content; hyperdb has one for each authorized writer).
This sounds promising - are there any resources or GitHub issues on this now?
Yep, take a look at https://github.com/substack/hyperdrive-multiwriter and https://github.com/poga/hyperdrive-ln for examples. They're both outdated but may give you some ideas on use.
These looks very relevant. A pity they are "abandoned" with very little documentation.