search

mafintosh / hyperdb

Distributed scalable database
MIT License
753 stars 75 forks source link

Reproducible local writers #163

Open aral opened 5 years ago

aral commented 5 years ago

Summary of changes:

Adds two (optional) options to the options object you can pass when creating a hyperdb to support reproducible local writers:

If present, these are used when creating the local writer instead of randomly choosing a keypair.

This is a non-breaking change. If the local writer key details are not passed in, hyperdb works as before.

Use case:

In a multiwriter system, once a writer (e.g., a browser node) has been authorised, we do not want it to have to re-apply for authorisation if the local database is destroyed (e.g., local data is cleared) as this adds a non-trivial experience cost to the person using the system. The alternative is to create a new writer every time which also adds to the overhead of the hyperdb.

This pull request makes it possible to implement seamless device/node authorisation for multiwriter when used in conjuction with passphrase-derived keys and a module like secure-ephemeral-messaging-channel.

Links:

Closes #158

aral commented 5 years ago

I’m closing this, as well as #158 as I’ve realised it’s not necessary for what I wanted to achieve and currently cannot think of a use case for it.

aral commented 5 years ago

Reopening this as I now have a genuine use case for it:

  1. Create original hyperdb on Node/device 1
  2. Create a second writer on Node/device 2 (and have Node/device 1 authorise it for writing)
  3. Delete the hyperdb on Node/device 2 (e.g., “sign out”)
  4. Recreate the hyperdb on Node/device 2 (e.g., “sign in”) ← at this point, we should not create a different writer but reuse the writer we already had on Node/device 2. In terms of experience, this is the difference between having to autorise the node/device again or not so it has a non-negligible effect.

In order to recreate the same writer on node/device 2 we need reproducible writers for hyperdb.

aral commented 5 years ago

@mafintosh I’m happy with this now, please do let me know if you need anything further from me.

aral commented 5 years ago

An update on the use case: I’ve come to the conclusion that while we can easily have reproducible local writers, having a reproducible local unique identifier is a much harder problem that can only be approximated at on browser nodes with methods such as browser fingerprinting, etc. Given that, I’ve decided to keep on with random key material for local writers in Hypha and to persist an encrypted copy of the local write key. If a local database is destroyed (which should not happen often*), we can take the overhead and experience hit for that edge case and create and authorise a new writer.

* It’s too soon to speculate either way and trying to use reproducible local writers at this point (along with the work of trying to create unique ids for nodes) feels like a premature optimisation. It is also very difficult to do without some sort of centralised counter, etc., which I do not want.

All that said, reproducible local writers might have other use cases I haven’t thought of. As such, it’s entirely up to you @mafintosh whether it makes sense to accept this PR. Please feel free to close it if you feel it introduces complexity cost with only theoretical benefit at this point.

OK, I’m confusing myself now. Whether or not we have pre-determined or random key material for local writers is unrelated to our need to have reproducible local writers so that we can recreate the same writer. e.g., with random key material, we can save an ecrypted copy of the secret key and then recreate the writer from that. So, yes, we need this functionality.

(At least you can be sure I’m trying to ensure that we don’t add anything unnecessary to the core modules.) :)