Net API - Design discussion

[daviddias]

The same way that the dag API is the IPLD API, we should have a Net API that is the libp2p API. This follows proposals such as https://github.com/ipfs/interface-ipfs-core/issues/249 and the need from apps such as PeerPad to actually have access to libp2p APIs and today it is accessing IPFS internals (antipattern).

This means that a) we would remove the ipfs swarm APIs, change the scope of the PubSub API and create a new ipfs net with commands such as (example of potential calls):

• ipfs.net.dial
• ipfs.net.hangup
• ipfs.net.pubsub.publish
• ipfs.net.pubsub.subscribe
• ipfs.net.pubsub.ls
• ipfs.net.peerRouting.findPeers
• ipfs.net.contentRouting.findProviders
• ipfs.net.contentRouting.provide
• and so forth..

FAQ:

• Why net? - Comes from Network. IPFS exposes a Network API and uses libp2p to do so.
• Why not p2p? - calling something ipfs.p2p sort of implies that everything else is not p2p, it also doesn't communicates correctly why some commands are under the p2p scope. The word Network/Net does a better job.

[magik6k]

Why not p2p

go-ipfs also implements experimental feature which allows to forward libp2p streams to/from network connections under ipfs p2p - https://github.com/ipfs/go-ipfs/blob/master/docs/experimental-features.md#ipfs-p2p / ipfs/kubo#4929 (and it too would fit in net. api)

[achingbrain]

Closing as not planned.