Implementing Secure Scuttlebutt (SSB) Protocols #3456
-
I'm playing around with libp2p in the context of a Scuttlebutt node. I was initially hoping to start a swarm with basic TCP connections to test connectivity, and then later tackle libp2p protocol implementations for Secret Handshake and MUXRPC, but I don't think this is currently possible (based on #2396). Reading further about some of the work that may be require to implement the SSB protocols in libp2p-land, I now wonder if libp2p would be viable. As I understand it, libp2p peers use multistream-select for protocol negotiation. What if a node running libp2p wants to connect and communicate to a peer without libp2p (therefore no multistream-select)? Is that a non-starter? I'm thinking about interoperability with all the Scuttlebutt nodes which do not use libp2p. Thanks for your patience with my clumsy question. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
I am not too familiar with SSB but by the looks of it, it allows for an encrypted transport. We do something similar with QUIC. There, the multiaddr ( I think SSB could be used to implement a You'd have to implement those on top of MUXRPC which seems a bit silly. Do SSB nodes allow for something else other than MUXRPC to be used on top of the established connection? |
Beta Was this translation helpful? Give feedback.
I am not too familiar with SSB but by the looks of it, it allows for an encrypted transport.
We do something similar with QUIC. There, the multiaddr (
/quic
) suggests that we set up a QUIC connection on the specified port withoutmultistream-select
.I think SSB could be used to implement a
Transport
that offers authentication but no multiplexing, at least not in the same way libp2p applications expect it. Those want reliable, ordered streams on top of a transport.You'd have to implement those on top of MUXRPC which seems a bit silly.
Do SSB nodes allow for something else other than MUXRPC to be used on top of the established connection?