protocol-select/: Add Protocol Select specification

[mxinden]

This pull request adds the specification for the Protocol Select protocol.

Protocol Select is a protocol negotiation protocol. It is aimed at negotiating libp2p protocols on connections and streams. It replaces the Multistream Select protocol.

Status

Ready for review.

See also https://github.com/protocol/web3-dev-team/pull/119.

[mxinden]

This proposal, namely the Protocol Select specification, is ready for review and we welcome feedback by everyone across the whole libp2p community. Note that Protocol Select aims to replace Multistream Select and thus intents to become one of the core libp2p protocols.

Protocol Select builds on top of the security-protocol-in-multiaddr extension (https://github.com/libp2p/specs/pull/353).

[cheako]

Why not take this opportunity to make breaking changes not split the network? Supporting multi-versions is a simple solution, there must be others:

syntax = "proto2";
message ProtoSelect {
    uint32 version = 1;
    uint32 max_forbid_version = 2;
    message Protocol {
        oneof protocol {
            string name = 1;
        }
    }
    repeated Protocol protocols = 3;
}

max_forbid_version is set/updated to the oldest/highest offensive version that is hereby banned... because

1. a change so critical it warrants banning all clients older than
2. years, perhaps decades and it's just time

Allow the other end to reply with, sorry, I speak version X and continue accordingly.

[mxinden]

Hi @cheako, I am sorry for the late reply here.

Why not take this opportunity to make breaking changes not split the network? Supporting multi-versions is a simple solution, there must be others:

I am not quite sure I understand where you are going with this. Could you describe a small scenario where the current versioning scheme would not suffice but your proposal would?

max_forbid_version is set/updated to the oldest/highest offensive version that is hereby banned... because

In particular I am having a hard time understanding why the max_forbid_version needs to be exchanged explicitly.

1. a change so critical it warrants banning all clients older than

Say client A receives a ProtocolSelect message with a version pre-cricitical-change from B, it could then simply cut off the connection. I expect clients to start with their highest version available, thus there is no need for A to retry as B likely does not support a higher version.

Allow the other end to reply with, sorry, I speak version X and continue accordingly.

Note that this would conflict with Optimistic Protocol Negotiation where the remote might have already sent application data.

[cheako]

The point is to avoid disconnection because version. So... The lower version should be the one to give up and disconnect when it can't satisfy the required version.

ACID rules should already cover the case where a transaction needs to be rolled back, so it's not a problem that a higher version sends some data that needs to be disregarded.

[mxinden]

Again, would you mind describing a concrete example where the current versioning scheme would not suffice? I am still having a hard time understanding which problem you are trying to solve @cheako.

[cheako]

The notion of a sudden disconnect is not expressive enough and is just ambiguous. I don't think it's right to put a lot of effort into the case where a node would be banned. However, it can be done more than the, simple and to the point, max_forbid_version scheme. Another solution is to have a response along with a disconnect(you can try to pad the TCP RST with data) clients are written to understand. There are three things I can think of for such a reply:

1. That you're being banned, the packet type(obviously the newer node would be sending a legacy packet) expresses this.
2. The severity of the ban, like should the application close(as in you're a danger to society) after getting a few of these, or is it just this node that it's banned from.
3. Documentation, a web address for the user to get more information as to why. a. The new software may have updated guidance for where documentation lives.