p2p commands are not supported

MichaelMure commented 6 years ago

The p2p command (https://github.com/ipfs/go-ipfs/blob/master/docs/experimental-features.md#ipfs-p2p) is available in go-ipfs since the 0.4.10 version. If supported in js-ipfs-api this could be very useful to implement custom protocols on top of ipfs.

For Arbore (https://github.com/MichaelMure/Arbore) I would use it to replace the pubsub in 1-to-1 communications.

ghost commented 6 years ago

We'll start implementing dedicated go-libp2p and js-libp2p daemons soon, and the p2p commands are something we'll likely move there and not continue supporting in the ipfs daemon itself.

MichaelMure commented 6 years ago

Do you mean that I will need to run both daemon ? What about the ipfs keystore ? Will it be possible to do message signing and encryption ?

daviddias commented 6 years ago

I have a humble request. Can we put the network commands behind net, so ipfs net <command>? It feels more intuitive to me than p2p. The same way that IPLD is behind the word dag, because it is the Graph API, the same way that what we are adding is the Network API.

Pretty please 🙏🏽

MichaelMure commented 6 years ago

I'm going to take the occasion to say that this is an important feature. If you want to build apps on top of ipfs, being able to communicate between node is quite useful. Pubsub does part of the job, but broadcasting is not always an option, nor it is efficient.

ghost commented 6 years ago

I have a humble request. Can we put the network commands behind net, so ipfs net ? It feels more intuitive to me than p2p. The same way that IPLD is behind the word dag, because it is the Graph API, the same way that what we are adding is the Network API.

Sure, we should consider that (same applies for the config file of go-ipfs). I don't feel too excited about creating yet another API (Network API) that's just a subset of another existing API. This should really not be a new API, it's just libp2p things exposed through IPFS. But a subcommand is totally fine. I know a subcommand effectively is an API over HTTP and the CLI, but calling it officially "the Network API" is a whole different game.

From what I gather, the current commands that aren't ipfs-specific and simply bubbled up from libp2p are:

ipfs swarm
ipfs pubsub
ipfs dht
ipfs ping
ipfs p2p (this one I'd like to just move to the upcoming libp2p daemon, instead of promoting it in ipfs from experimental to stable)

daviddias commented 6 years ago

@lgierth my intention with the Network API proposal is to move all of those commands behind ipfs net

ipfs net pubsub
ipfs net peers (previous ipfs swarm peers)
ipfs net dial (previous ipfs swarm connect + ipfs p2p dial)
ipfs net dht
ipfs net ping

ReisenB commented 4 years ago

With the recent improvements to the fetch API as noted in https://ipfs.io/blog/2019-08-29-pubsub-in-the-browser/, is this feature closer to implementation? I'm also waiting with bated breath for it.

I did have one question: I would like to be able to open a p2p stream from the browser and use it entirely from there (that is, local browser -> local daemon -> remote daemon -> remote browser). I see the current arrangement involves routing a stream from a remote peer (addressed as /ipfs/QmPeer) to an IP address. Is the plan to make the stream routable directly to the browser window instead? Ideally, there would be a method for monitoring a connection via JS and returning a buffer of all messages since last poll.

zot commented 4 years ago

I started a project to do this here as kind of an add-on to js-ipfs-http-client. It's currently just under 500 lines of Go code to implement a server that multiplexes p2p streams through a websocket connection using a simple binary protocol. It's mostly ready to start testing (which plan to be doing over the next couple days).

@ReisenB, this does allow browser->local daemon->remote daemon->browser connections or even browser->local daemon->remote daemon->non-browser program since it multiplexes between websocket messages and a vanilla binary stream.

Please let me know if this helps with this issue. Here's the simple websocket protocol I'm defining to control the local IPFS daemon:

/ws/control

Allow browser to control the relay over a websocket using a very simple binary protocol. When a connection closes, clean up all of its child connections. The client and server exchange these command messages, with the first byte of each message identifying the command.

CLIENT-TO-SERVER MESSAGES

  Listen:       [1][PROTOCOL: rest]              -- request a listener for a protocol
  Stop:         [2][PROTOCOL: rest]              -- stop listening on PORT
  Close:        [3][ID: 8]                       -- close a stream
  Data:         [4][ID: 8][data: rest]           -- write data to stream
  Peer Connect: [5][PROTOCOL: STR][PEERID: rest] -- connect to another peer

SERVER-TO-CLIENT MESSAGES

  Listener Connection:     [1][ID: 8][PROTOCOL: rest] -- new listener connection with id ID
  Connection Closed:       [2][ID: 8]                 -- connection ID closed
  Data:                    [3][ID: 8][data: rest]     -- receive data from stream with id ID
  Listen Refused:          [4][PROTOCOL: rest]        -- could not listen on PORT
  Listener Closed:         [5][PROTOCOL: rest]        -- could not listen on PORT
  Peer Connection:         [6][ID: 8]                 -- connected to a peer with id ID
  Peer Connection Refused: [7][PEERID: rest]          -- connection to peer PEERID refused

zot commented 4 years ago

The chat example is ready to play with (still a bug with certain disconnecting in the example but plan to fix that soon).

I renamed the project: https://github.com/zot/libp2p-websocket

I had plenty of false starts and difficulties with circuit relay and I found that pubsub takes a very long time, causing startup delays of a minute or more. I plan to investigate this over time but for now I just hacked my own application-level relay in JavaScript so that a browser can function as a relay.

Anyone interested can check out the project and please post issues if you have problems

SgtPooki commented 1 year ago

js-ipfs is being deprecated in favor of Helia. You can https://github.com/ipfs/js-ipfs/issues/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 https://github.com/ipfs/js-ipfs/issues/4336).

This issue is most likely resolved in Helia via another method or function. Please let us know if it's not!

ipfs / js-ipfs