Allow options.init to at least overwrite the identity for an existing browser repo

[5310]

We should be able to switch the identity of a browser node.

If not with the existing options.init.privateKey option (and perhaps an additional flag), then by some other standard means.

• Version: 0.37.0
• Platform: browser; not specific to any particular browser
• Subsystem: core / init

Type: Enhancement

Severity: non-critical but an important use-case

Description:

For my browser IPFS app I need users to be able to supply their own identities and log in as different identities when they need to.

It is already possible to provide an identity for the creation of a browser IPFS instance with the options.init.privateKey config. But it is only ever used once, before the creation of a repository, and then never again as long as a repository of the same name exists in the browser's IndexedDB. Subsequent initializations simply ignore all the configs under options.init and read the identity stored.

(Aside: And the identity is stored as plain text in the config it seems! Even if I use the options.pass option, thereby initializing the keychain, it merely copies the identity into the encrypted keychain as self while leaving the plain text identity in config! The most important secret is always stored in plain text in the browser, even if the node was initialized from scratch with a passphrase, for reasons I cannot appreciate: #1138)

This means I can never replace an IPFS instance within my application without either deleting the IndexedDB stores manually, which very opaque and hacky, OR by recreating a repository with a different name from scratch, probably identified with some sort of public aspect of the identity the user is providing, but also duplicating all of the blocks I know will be needed by the app even as this different user.

I believe this is a shortcoming of the API. It is bad enough that on the browser repositories are isolated by domain (purely from the storage space perspective, I am not arguing the privacy concerns are immaterial if we somehow managed to share a repository without needing extensions, as long as the keys are also stored in these repositories.) To then need to do so for every identity the user wants to create for my own app under my own domain seems especially undesirable.

There should be a way to force at least a new identity on an existing repository (under our control) without losing other configuration and blocks. It seems that there used to be an option to force the initialization process, but it was removed according to issue #515. Right now, I have to resort to manually deleting <reponame> and <reponame>/keys. But even if that's to be the right solution, it should be part of the API.

Steps to reproduce the shortcoming:

1. Create a browser IPFS node with the default configuration.

• const node = await IPFS.create()

2. Note the generated ID.

• await node.id()

3. Edit in the following config option for the node creation.

• const node = await IPFS.create({ init: { privateKey: key64 } })

4. Note the new ID.

• await node.id()

It should be different due to being provided a private key. But it remains the same as the first generated key.

[caelumdev]

Is there a fix for this by now?

[achingbrain]

js-ipfs is being deprecated in favor of Helia. You can #4336 and read the migration guide.

You can do this by generating a new PeerId and passing it as the libp2p config. The node will use the passed PeerId instead of generating one itself.