[switch] [interop] Handle missing public key in identify about js-libp2p

[daviddias]

@dignifiedquire changed the labels

[jbenet]

• I think Identify should send the pubkey by default.
• Maybe it could detect whether the connection is authenticated, and use the pubkey from there and avoid sending it then.
• in general, Identify is really awkward right now. part of me thinks that Identify should happen as a "fully async" protocol (so we can write through without waiting for RTTs) and it should happen after auth and before stream muxing. This could add a layer of multistream, but it would make the possibility of nodes without an identify protocol breaking things not a thing.

[jbenet]

cc @whyrusleeping @diasdavid

[daviddias]

It is almost that @dignifiedquire. What I and @whyrusleeping detected was that go-libp2p setup, available these examples https://github.com/libp2p/go-libp2p/tree/master/examples, doesn't set up the public key on Identify, however this happens correctly in go-ipfs.

We need:

• Be able to cope with an incomplete Identify in js-libp2p-swarm
• Have go-libp2p examples are fully set up, because users of libp2p will not understand what is going on

I think Identify should send the pubkey by default.

I would prefer that as well. But better not to panic if not set.

Maybe it could detect whether the connection is authenticated, and use the pubkey from there and avoid sending it then.

That is the plan, if the pubkey is not passed.

in general, Identify is really awkward right now. part of me thinks that Identify should happen as a "fully async" protocol (so we can write through without waiting for RTTs)

Identify is today fully async, it is not required to be executed at all and if some part of the code tries to getPeerInfo on the conn, it will execute Identify if it hasn't already.

and it should happen after auth and before stream muxing. This could add a layer of multistream, but it would make the possibility of nodes without an identify protocol breaking things not a thing.

Not so confident about this.

[whyrusleeping]

I can make sure that go-ipfs puts public keys in the identify handshake very easily. But i can't easily make us infer the remotes peer ID from the sent public key, that both requires us to think about that from a security perspective, and to restructure the entire way we're doing the identify to be closer to how @jbenet suggests here (with having identify happen before anything else).

I'll put up a quick PR to add in sending the public key, but i think that using it for any purpose is erroneous behaviour at this point.

[jbenet]

But i can't easily make us infer the remotes peer ID from the sent public key

Wait, how so? the peer.ID is well defined to be a function of pubkey -> peer.ID. what am i missing?

[dignifiedquire]

@jbenet @diasdavid what exactly should I change now in js land?

[daviddias]

@dignifiedquire go added the pubkey to identify so that we don't hit this issue. We are discussing (so far there is an agreement but it won't come in this quarter) that it makes sense to Identify and Multistream to be the two protocols that libp2p users must buy in. It's already obvious that Multistream is, but right now, it is kind of klunky that Identify might be skipped with a presence of a Stream Muxer. (tl;dr; the proposal is to do both in go and js what JS was doing before - https://github.com/libp2p/js-libp2p-swarm/issues/78)

[dignifiedquire]

@diasdavid cool. So should I hold off with the work on this for now? Can we then remove it from the milestone?

[jacobheun]

Issue has been fixed for some time, closing.