We currently use a single, hard-coded libp2p relay peer id:
|
/** |
|
* Fixed local ID for the relay server. |
|
* This ensures the relay server always has the same PeerID across restarts, |
|
* making it easier for clients to connect to a known relay address. |
|
* The ID must be between 1-255 to generate a deterministic keypair. |
|
*/ |
|
const RELAY_LOCAL_ID = 200; |
Instead, we must make the relay libp2p peer id configurable. Since libp2p distinguishes internally between relays via their peer ids–even if they're on different ip addresses–libp2p would be unable to distinguish between two relays spun up using our implementation. This is just a matter of threading the relay local id through to the site of libp2p keypair generation, as opposed to hard coding it. In production, we'll just randomly generate a keypair and store the private key on disk. We may wish to support a mnemonic / some way of generating a deterministic yet unguessable peer id as well, in case the user wants to resuscitate "the same" relay on a different device.
We currently use a single, hard-coded libp2p relay peer id:
ocap-kernel/packages/kernel-utils/src/libp2p-relay.ts
Lines 13 to 19 in 04e9315
Instead, we must make the relay libp2p peer id configurable. Since libp2p distinguishes internally between relays via their peer ids–even if they're on different ip addresses–libp2p would be unable to distinguish between two relays spun up using our implementation. This is just a matter of threading the relay local id through to the site of libp2p keypair generation, as opposed to hard coding it. In production, we'll just randomly generate a keypair and store the private key on disk. We may wish to support a mnemonic / some way of generating a deterministic yet unguessable peer id as well, in case the user wants to resuscitate "the same" relay on a different device.