Open saul-jb opened 1 year ago
This is also useful for clients that can connect to both local and remote services. For example, it would not be unreasonable to run the IPFS API over a unix socket. However you may also want to use the IPFS client to manage a remote API. Right now these cases have to be handled separately.
As was pointed out by infinity0, unix domain sockets can be either stream or datagram. Therefore I recommend a multiaddr format such as
/unix/stream/\path\to\sock/some-protocol/0.1.0
or
/unix/datagram/\path\to\sock/some-protocol/0.1.0
It's not pretty, but it's a path forward for a problem that's been around for several years.
Another use case is for Tor transport. We can start a peer with/unix/xxx/onion3/xxx
. The unix socket is the address configured as a onion service in Tor and the onion address is the one used to dial the peer.
@littlebenlittle we could have a shorter version /unix/s/xxx
and /unix/d/xxx
. One inconvenience is that \path\to\sock
is a valid path name on unix systems.
Unix domain socket addresses become ambiguous when they encapsulate other addresses. This is obviously because unix addresses are not a fixed length and can contain forward slashes. This becomes an issue when you need to when you need to encapsulate other protocols like
/p2p
for example:This type of address would be needed if you have multiple nodes on the same machine that need to connect to each other. (VMs/Docker comes to mind.)
This also relates to issue: #55