Adding a multiaddress key for SSB

[gpicron]

This is to allow representing Secure Scuttlebutt addresses in MultiAddress format

[rvagg]

will defer to libp2p team on this, it seems reasonable to me although it appears to be among a bundle of protocols rather than handshakes; maybe that distinction is irrelevant though?

[gpicron]

Actually, SHS is very similar to noise. In the spec, it is described as in 2 parts:

• https://ssbc.github.io/scuttlebutt-protocol-guide/#handshake : describes the handshake
• https://ssbc.github.io/scuttlebutt-protocol-guide/#box-stream: describe the encrypted stream encapsulation using the shared secrets (keys and nounces) produced by the handshake.

Historically, it was created before Noise was published.

[marten-seemann]

Tagging @dhuseby, since we recently talked about Secure Scuttlebutt.

[dhuseby]

So the shs handshake is similar to XKpsk0 Noise handshake but it is distinct as is the "box stream" it uses for it's transport. @p-shahi I think the name is pretty descriptive. This is a distinct handshake and transport protocol used only by Secure Scuttlebutt. AFAICT, there are no SSB clients that use libp2p; they all assume a TCP connection to the remote host.

[dhuseby]

So the shs handshake is similar to XKpsk0 Noise handshake but it is distinct...

What makes it distinct is the addition of the fixed network identifier key for the HMAC'ing of the initial initiator and responder hello messages (https://ssbc.github.io/scuttlebutt-protocol-guide/#client-hello).

Noise (https://noiseprotocol.org/noise.html#protocol-names-and-modifiers) and its extensions like Disco (https://discocrypto.com/disco.html#protocol-naming) mix the protocol name into the internal handshake state.

[gpicron]

So the shs handshake is similar to XKpsk0 Noise handshake but it is distinct as is the "box stream" it uses for it's transport. @p-shahi I think the name is pretty descriptive. This is a distinct handshake and transport protocol used only by Secure Scuttlebutt. AFAICT, there are no SSB clients that use libp2p; they all assume a TCP connection to the remote host.

Currently, yes... The reason I wish to put shs in the table is that it has some interesting properties (simplicity and client requested to present itself first to be immediately at equal "state" than the server that has publicly published its public key/IP link) while the SSB network stack is not very flexible (no negotiation). So I would like to progressively move SSB apps to accept LIBP2P negociated transports.

[gpicron]

And by the way, multi-address is supposed to be only loosely coupled to libp2p. SSB has its own "multiaddress" and it would be good to progressively move SSB to less proprietary standards (even if they were created after SSB)...

[BigLep]

@p-shahi @dhuseby : what's the decision here? Do we have an approve and merge?

[dhuseby]

@BigLep it looks to me like it just needs reviewer approval. I was weighing in on the fact that this is a distinct protocol and should have it's own line and identifier.

@vmx, @rvagg, @marten-seemann, @mxinden any reason not to merge this? If not, then approve it and merge it.

[rvagg]

can be merged when that typo is fixed