This would be called ipfs - merkle tree -> iptp?

Actually, @AtnNn , I think this would be better implemented (as in less crufts to deal with) with go-libp2p.

I personally think this could be implemented pretty nicely with unix pipes (although then we end up not being cross platform)

although, i want all this interaction work... ipfs pipe has been too long in the coming.

take a look here: #1089

I closed it because of the difficult of passing stdin through the daemon, but it looks like you've got that figured out.

@rht I see some benefits of integrating this with go-ipfs. It avoids having a separate p2p node and it could benefit from future access control and encryption that go-ipfs might add. However it does add a little complexity and yet another feature to maintain.

@whyrusleeping I was inspired in part by your code. The core of the implementation is a simple two-way pipe transmitted over the http connection by upgrading it to use websockets. Which means this isn't limited to unix pipes, it can even be used by client-side javascript.

i'm excited for this, but its going to take me a while to get through it to an acceptable level of understanding.

I've left some comments, and you'll also want to make sure to run gofmt on your code (set it up on your editor to run on save)

also look at writing some sharness tests for this, i would do something like t0130-multinode.sh so you can work with multiple nodes.

Thanks for the comments. I've also found a few bugs in my code that I'll try to fix.

@AtnNn just a fair warning, this is going to take a little while to get merged (lots of review and testing will be needed) so bear with us! This is something i really do want.

@AtnNn this is great!! been wanting this, so cool to see it happen. some high level comments/questions:

• can it only be over websocket? any way of making just http work? (say over long-polling, for http-only clients)
• in the websockets case, we should really be implementing a version of the commands lib that works over arbitrary sockets, so do it over websockets and unix domain sockets (cc @ehmry as he wanted unix sockets a long time back)

for the service address, i'd prefer dialing something like this:

ipfs service dial /ipfs/Qmpeerid.../<service-name>

all one path. a service mounted and available at that peer. should coexist in the namespace of services already available (bitswap, dht, etc) OR nest under "service/":

ipfs service dial /ipfs/Qmpeerid.../service/<service-name>

getting kinda long, so maybe can still do as you had it for shorthand (but still allow the long version):

ipfs service dial Qmpeerid.../<service-name>

Could also work over explicit multiaddrs to prefer a connection over that transport -- useful when wanting to select an addr over TOR, or BLE, or whatever:

ipfs service dial /ip4/1.2.3.4/tcp/1234/ipfs/Qmpeerid.../<service-name>

@whyrusleeping how do you see this integrating with your vision for pipe? could there be some dedup of effort here? does pipe does need the websocket stuff?

@whyrusleeping thanks for picking up CR here! ❤️

@rht is right, likely libp2p could be a more general target for this-- and can also include it here. maybe a good path is build it on ipfs and then generalize a part to add to libp2p?

@jbenet this is basically what pipe was, it just has pipe+some extra stuff