Update supported protocol on the fly

[drHuangMHT]

I've come up with this early in #3902 when I tried to write a macro for composing NetworkBehaviours:

when handshaking with a unknown peer, it's best to leak as little information about yourself as possible instead of dumping everything, but I don't think it's possible with derive macro only.

But what is the best way to do this? Behaviour is invoked once per connected peer and polled afterwards so changes to Behaviour(Toggle for example) will take effect after reconnecting to that peer, which is not ideal. Should it be done on the connection handler level? Also, while debugging the macro, UpgradeInfo was observed to be sent to the other peer once in a while, what about changes to it?

[thomaseizinger]

Are you using identify? If you don't want to share your supported protocols, I'd suggest stop using identify and write your own protocol that perhaps only shares information with manually selected peers.

The Swarm by itself does not share information with other peers. It will answer to inbound streams if your behaviour supports the given protocol.

[drHuangMHT]

Are you using identify?

Of course, why not?

If you don't want to share your supported protocols, I'd suggest stop using identify and write your own protocol that perhaps only shares information with manually selected peers.

I'm looking for ways to configure the visibility though. Interoperability and sort of "privacy" are both important. However that's probably not the goal of identify.

It will answer to inbound streams if your behaviour supports the given protocol.

Is it fully automatic? Is there room for configuration?

[thomaseizinger]

Are you using identify?

Of course, why not?

Well, it seems you don't like what it does :)

If you don't want to share your supported protocols, I'd suggest stop using identify and write your own protocol that perhaps only shares information with manually selected peers.

I'm looking for ways to configure the visibility though. Interoperability and sort of "privacy" are both important. However that's probably not the goal of identify.

It depends on which nodes / networks you want to be interoperable with. I think some parts of go-libp2p require identify for example but outside of that, identify is "just another protocol" and you don't need to add it to your stack if you don't want its behaviour.

If you don't want to expose your supported protocols, you can also fork libp2p-identify and add a configuration option to control whether or not your list of supported protocols is shared with peers. That is still wire-compatible and allows you to change at runtime, when the list of protocols is shared.

It will answer to inbound streams if your behaviour supports the given protocol.

Is it fully automatic? Is there room for configuration?

Yes it is automatic and currently cannot be configured (outside of using Toggle). rust-libp2p is complex enough as it is, I don't see us adding configuration switches to enable / disable protocols per peer.

Note that, this is pretty much the default behaviour of most protocols on the internet. An HTTP server will respond with HTTP if you send it a (legitimate) request. We do the same thing. If your node supports gossipsub, we will allow an inbound gossipsub stream from other nodes. I don't really see why we shouldn't.

[thomaseizinger]

Identify is not a very complicated protocol. You can easily write a protocol yourself that does something similar but with your privacy goals in mind.

[drHuangMHT]

OK then. Have to figure it out myself.