Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reproducible local writers #163

wants to merge 4 commits into
base: master


None yet
1 participant
Copy link

aral commented Feb 1, 2019

Summary of changes:

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

  • localKey
  • localSecretKey

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.


Closes #158

aral added some commits Feb 1, 2019

Add localKey and localSecretKey support in options object
If present, these are used when creating the local writer.

This comment has been minimized.

Copy link
Contributor Author

aral commented Feb 1, 2019

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 aral closed this Feb 1, 2019


This comment has been minimized.

Copy link
Contributor Author

aral commented Feb 16, 2019

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 aral reopened this Feb 16, 2019

@aral aral changed the title WIP: Reproducible local writers Reproducible local writers Feb 17, 2019


This comment has been minimized.

Copy link
Contributor Author

aral commented Feb 17, 2019

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


This comment has been minimized.

Copy link
Contributor Author

aral commented Feb 18, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.