Import / export user keys

[cristiano-belloni]

[correct me if I'm wrong, please, these are my first days with orbitdb :) ]

orbitdb uses public key cryptography to sign databases. This means that the identity of users is defined by their public key, and their ability to actually do things with that identity is defined by their private key. The public-private key couples broadly defines what in a centralised system would be called an authenticated user.

Now, if I start a node in my browser, a key pair is generated (randomly?) and persisted in the browser storage. But if I start it in another browser, on in another device, or I simply erase my browser storage, the key pair changes. This means that my identity is linked to a particular browser storage and it's not portable.

There could be many ways of storing the keys and reusing them (the most simple would be saving them to a file and importing them back manually copying the file to another device), but I think all them would need a key import / export functionality baked in orbitdb.

Is this right? If yes, would it be possible to implement this import / export functionality?

[shd101wyy]

Hi there. I am also very curious about importing public/private key to orbitdb.
It seems that there are two functions orbitdb.key._importPublic and orbitdb.key._importPrivate, but I don't know if they are relevant to importing?
Thanks

[haadcode]

Right now we don't have a way to import/export keys. However, the keys are located in ./orbitdb/<peerID>/keystore/ from which you can copy them manually. This is tedious, error prone and definitely not what we want as the solution.

My thinking has been that we'll use the nice keystore interface IPFS will provide. There's an open PR ipfs/js-ipfs#1133 to bring into the js-ipfs land, so I would wait until we have the keystore and then see what's the best way to import/export. Right now there's nothing on import/export in the spec but I don't see why we couldn't add a layer on top of it, or as part of the spec, to import/export keys.

Any thoughts?

[cristiano-belloni]

@haadcode - Supporting IPFS keystore would be cool. There's another thing too: what about the actual data? Imagine the simplest case, where a user buys a new PC and wants to migrate data to it. They export their keys and gain the possibility to tweet as themselves in the new PC, but when they db.load() there is no data in the new PC's IndexedDB, so they get an empty user info object and, an empty tweet feed, plus an empty follower list (currently I use three dbs, two kvs and a feed). How do they go about importing all their previous state? They should replicate their old dbs with their old computer turned on and running the Twitter app?

[nothingismagick]

FYI - the PR mentioned above has been merged two months ago.

[aphelionz]

Closing this for now but can re-open or revisit if necessary