feature: p2p stream

[pgte]

Apparently go-ipfs now supports, in its external interface, dialing to a specific peer and protocol.
I'm not sure what are the plans for also adding this to the js-ipfs interface and implementing it.

This would be very helpful, allowing applications to use custom protocols in a standard way that would be usable across IPFS implementations.

[alanshaw]

@pgte we're working on exposing libp2p as ipfs.libp2p but is accessible as ipfs._libp2pNode right now.

I think this is really a question for @jacobheun / @vasco-santos.

[pgte]

@alanshaw understood, that’s the way I used to do it, but wewould need a standard way to access this, having the same interface whether across HTTP or using embedded js-ipfs. Is this something that can be incorporated in the standard interface? No dia 18/01/2019, às 13:00, Alan Shaw <[email protected]> escreveu:

…

@pgte we're working on exposing libp2p as ipfs.libp2p but is accessible as ipfs._libp2pNode right now. I think this is really a question for @***@***.*** — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[jacobheun]

@pgte could you elaborate on what you'd like to use the interface for? We are looking at improving the libp2p interfaces and it would be helpful to better understand the use cases you need. We could look at replicating the ipfs p2p interfaces from go, but I'd like to have a better understanding of what's needed before we do that.

[pgte]

@jacobheun In the browser, after I discover a peer and I have the peer address(es), we need to open a custom libp2p protocol to it, which returns me a duplex stream.
Right now we're using ipfs._libp2p.dial(), but that makes this application incompatible with using the HTTP interface with either go or js-ipfs running as daemons.

Instead, we would like to be able to open and use, from the browser, a duplex stream to a specific peer and protocol. It would have to support the browser clients (websockets) and I should be able to use an embedded IPFS node without any code change.

[pgte]

Another perhaps interesting aspect of this:
The current go implementation of the p2p command has a native socket interface.
We would require it to run over websockets.. (see comment)

[jacobheun]

Looking at the go p2p api, unless I am missing something, it looks like opening a stream to a specific peer and protocol for an embedded node isn't really supported. Most of the logic seems to be built around forwarding streams. It feels like a simpler approach would be:

const stream = ipfs.p2p.open(protocol, targetAddress)

[pgte]

I was talking about supporting this go-ipfs feature:

Yes, that JS API would work.

[pgte]

(with an optional third argument for the peer address, similarly to the go-ipfs CLI)

[jacobheun]

Ah! I'm running a recent build of go-ipfs master (0.4.19-dev) and dial is not in there. What version of go-ipfs are you running?

I think we can just stick to that existing go functionality, ipfs.p2p.streams.dial(...), to keep them the same. If dial accidentally got removed I'll create an issue in go-ipfs.

[jacobheun]

Yeah, it was removed in ipfs/kubo#4929. @magik6k we're looking at adding the p2p streams dial command that was previously in go into js-ipfs. Is there a reason that was removed? The dial command is really convenient for js-ipfs nodes. It looks like it was removed in favor of an ssh approach.

[magik6k]

There was a major refactor of this feature in 0.4.18, see https://github.com/ipfs/go-ipfs/blob/master/CHANGELOG.md#commands for more details. p2p stream dial changed name to p2p forward

[jacobheun]

Ok, I think we may want to update the docs for the command at some point. Using the cli --help to get more information about the commands locally it isn't very clear what the command is doing, or why/when it should be used, and the description is kind of a circular definition.

[SgtPooki]

js-ipfs is being deprecated in favor of Helia. You can #4336 and read the migration guide.

Please feel to reopen with any comments by 2023-06-02. We will do a final pass on reopened issues afterwards (see #4336).

This issue is most likely resolved in Helia, please try it out!