Implementation

[vyzo]

Initial implementation with a unix socket protocol; provides just enough to open connections and streams.

[bigs]

looks great. let's get this merged and take it from here

[bigs]

idk if it's necessary for this PR, but we can definitely abstract this to support handler functions of the variety

func (req *pb.Request) *pb.Response

[bigs]

ah well it seems it doesn't perfectly map

[vyzo]

yeah, the stream breaks the abstraction. Also, notifications later on.

[Stebalien]

Can we somehow extract this transport to a go-libp2p-unix-transport?

[vyzo]

We could do that I guess, although I am not sure how it would work for the control protocol (that's missing currently!).
Let's get this working first and see how the whole thing crystalizes before adding intra-package complexity.

[Stebalien]

We could do that I guess, although I am not sure how it would work for the control protocol (that's missing currently!).

My thinking was that we'd have:

1. Libp2p all the way down.
2. Open a stream to a control service (and use multistream to do this).

That means applications would have to implement:

1. The unix transport.
2. Multistream (it's a dead-simple protocol).

We could also, in theory, make protocol negotiation transport specific (like we've done with stream muxing and security) but we'd have to think carefully about that.

[vyzo]

Not objecting, just not rushing.
Let's add the control protocol and see how it shapes up, and we can think about extracting a UNIXFS transport later.
But the less applications need to implement, the better.

[Stebalien]

👍 I'd just also like to optimize for fewer abstractions. That is, if we can get away with reusing existing abstractions, we should. However, we do have to balance that with simplicity and fit.