Browser <-> go bootstrap and connect


I’m trying to connect a browser libp2p node over to a go libp2p node. I’m using the following config in the browser:

I use the following cljs code to initialize the node:

  (p2p/CreateNode (fn [err node]
                    (println "done creating " err node)
                    (.on node "peer:discovery" (fn [peer-info] (.log js/console "discovered a peer id: " (.-id peer-info))))
                    (.on node "connection:start", (fn [peer] (.log js/console "connecting", peer)))
                    (.on node "peer:connect" (fn [peer] (.log js/console "peer connected" peer)))
                    (.on node "error" (fn [err] (.log js/console "error" err)))
                    (.start node (fn [err] (println "started node")))))) 

I see in the browser that the web socket connects and a message is sent but the browser logs that a connection is starting and that a peer has been discovered but never logs the connect, nor an error.

What’s the best way to have a browser node bootstrap to a go node?

Update: go debug logs have:

21:07:19.935 DEBUG stream-upg: listener <stream.Listener /ip4/> got connection: /ip4/ <---> /ip4/ listener.go:91
21:07:19.946 DEBUG      secio: 1.1 Identify: 16Uiu2HAm3TGSEKEjagcCojSJeaT5rypaeJMKejijvYSnAjviWwV5 Remote Peer Identified as QmVo8h7vn6r8Ux9GrTidhyZxeuKKcocMVKD32nDRuCyf14 protocol.go:214
21:07:19.953 DEBUG stream-upg: accept upgrade error: failed to negotiate security protocol: EOF (/ip4/ <--> /ip4/ listener.go:107

I noticed in the config the Bootstrap peer is Looking at the debug logs the ports don’t match up to that Bootstrap peers addr. Did the ports change in the debug log?

What version of go are you using and are you customizing your key type? The peerId of the Bootstrap node makes me think this is the problem.

I just verified I can connect a go node to a libp2p node with your configuration, but both nodes are using RSA keys.

You are correct that I’m using ecdsa keys on the go side. Specifically this:

func p2pPrivateFromEcdsaPrivate(key *ecdsa.PrivateKey) (libp2pcrypto.PrivKey, error) {
	// private keys can be 31 or 32 bytes for ecdsa.PrivateKey, but must be 32 Bytes for libp2pcrypto,
	// so we zero pad the slice if it is 31 bytes.
	keyBytes := key.D.Bytes()
	if (len(keyBytes) != expectedKeySize) && (len(keyBytes) != (expectedKeySize - 1)) {
		return nil, fmt.Errorf("error: length of private key must be 31 or 32 bytes")
	keyBytes = append(make([]byte, expectedKeySize-len(keyBytes)), keyBytes...)
	libp2pKey, err := libp2pcrypto.UnmarshalSecp256k1PrivateKey(keyBytes)
	if err != nil {
		return libp2pKey, fmt.Errorf("error unmarshaling: %v", err)
	return libp2pKey, err

And then using the results in a libp2p option: libp2p.Identity(priv),

On the go side my versions: v0.0.21 v0.0.4 v0.0.3 v0.0.1 v0.0.2 v0.0.2 v0.0.10 v0.0.1 v0.0.2 v0.1.0 v0.0.5 v0.0.1 v0.0.1 v0.0.1 v0.0.1 v0.0.3

I believe that brings in v0.0.3

javascript side:

 "libp2p": "^0.25.3",
    "libp2p-bootstrap": "^0.9.7",
    "libp2p-kad-dht": "^0.15.2",
    "libp2p-mplex": "^0.8.5",
    "libp2p-secio": "^0.11.1",
    "libp2p-tcp": "^0.13.0",
    "libp2p-webrtc-direct": "^0.3.1",
    "libp2p-webrtc-star": "^0.16.1",
    "libp2p-websocket-star": "^0.10.2",
    "peer-info": "^0.15.1",
    "pull-mplex": "^0.1.2",

Oh interesting… I just saw this:

1 Like

Ok - just a quick update… I added that repo, and had the JS assign itself a secp256k1 key and that worked when the go code was RSA.

However, when I moved the key generation on the go side from RSA, but stopped using my custom code and just used:

	priv, _, err := libp2pcrypto.GenerateSecp256k1Key(rand.Reader)
	if err != nil {
		return nil, err

it failed again. So it appears the go side can only use RSA?

Update: also fails with GenerateEd25519Key

The issue may be on the JS side and what you’re encountering sounds like that’s the case. Changing the JS keys, go is still doing the crypto handshake just fine, but changing go keys causes the crypto shake to fail. This would be a great test suite to get added to Going to add an issue there.

Hi. One of our developers found out the issue and it’s related to this: . PR open here: and we await feedback on how to proceed.