libp2p spec

[daviddias]

It is getting form :) still a working progress, but leaving a PR here so people can start watching it, make comments, reviews, etc :)

[jbenet]

Great progress!! 👍

(i can spend some time working on this too later this week.)

[daviddias]

1st

2nd (After I realized that the current discovery only belongs to kad-routing and that peer-routing actually makes more sense to be called discovery, since we 'discover' peers for a given key)

each of these components exposes the given interface and is free to use any other of the modules available through that interface

[jbenet]

current discovery only belongs to kad-routing

we have three "discovery" protocols in go-ipfs running at the moment:

• initial config list bootstrap
• random walks on the dht
• mdns discovery

since we 'discover' peers for a given key)

"peer discovery" is already a thing in other protocols and it typically means "finding more peers", not "finding a specific peer in the network". in dht-land, the coral + kademlia papers describe the query as a routing process. and call it a "routing table".

Also, that's not what we've been calling "peer routing" either. recap:

• discovery a protocol that passively finds additional peers (e.g. periodically). (emits events/notifs)
• peer routing a protocol that actively (on request) searches for + finds specific peers in a network. (e.g. kademlia dht "FindPeer" query)
• content routing a protocol that actively (on request) searches for + finds specific pieces of content in a network (e.g. the "Providing system" (which is layered on top of a distributed record store, which uses --for example --the kademlia dht "Get" query))

Can we keep these names as they are? I've been talking to many people already about these.

---

(Updated)

[jbenet]

i think we can collect {Identify, Relay, NAT (there's multiple sub protocols for NAT), etc} into a heading like "Connectivity Protocols", which layer over Swarm, but are part of (under) libp2p (libp2p.Node).

[daviddias]

@jbenet really nice review, thank you! :D Also great to be doing this now as we are noticing some final polishing on how things are done (glad that we are doing that while we are jumping into go-libp2p too)

[jbenet]

• 👍 on this interface.

how about the below. This assumes that we don't sink protocol muxing into the Swarm, but again, that's up for discussion as it may be relevant to. regardless, we want users to use a libp2p.Node, not the Swarm directly.

// Node is the basic interface of libp2p. It represents a "Host" in the libp2p internet.
// It is capable of opening streams (either as a dialer or a listener) to other Nodes.
//
// The libp2p.Node uses a libp2p.Swarm internally to handle all connections and
// stream multiplexing.
//
// It is meant to have user protocols "mounted" onto the Node (as one would bind
// a socket and Listen, in a regular TCP/IP network stack). This is done with either
// the OpenStream or SetHandler functions (which represent Dialing or Listening) 
// for stream of a specific protocol. Only one "client process" may mount a protocol,
// that means that only one Handler is registered per protocol.ID. This tends to be
// the convenient thing to do, but may be up for discussion (e.g. being part of 
// multiple IPFS-DHTs, etc).
//
// The p2p.Node uses internal protocols (which are mounted on top, like any other
// protocol) such as Identify, NAT (traversal), and Relay, to achieve full connectivity
// on the networks it belongs to.
type p2p.Node interface {
  // OpenStream opens a reliable stream to peer.ID with given protocol.ID. 
  // If there is no prior connection to peer.ID, p2p.Node will attempt to establish one.
  OpenStream(peer.ID, protocol.ID)

  // SetHandler registers a function to be called whenever another peer opens a stream
  // with that specific protocol.ID. If HandlerFunc is nil (default), the handler writes an 
  // ProtocolNotFoundError back and closes the stream.
  SetHandler(protocol.ID, protocol.HandlerFunc)

  // Listen starts listening for incoming connections and therefore opening of streams
  // (this may need to handle the addresses, i'll look again at how go-libp2p does it).
  Listen()

  // this will need more things here, will look into go-libp2p to figure this out.
}

[daviddias]

The interface has evolved a lil bit with the last 'Swarm revisit' to support multiprotocols, but it is essentially the same:

https://github.com/diasdavid/node-libp2p-swarm#usage

we want users to use a libp2p.Node, not the Swarm directly.
Totally agree, we can have a 'front facing' interface from libp2p, in fact node-libp2p is just that, glue, take a peak at:
https://github.com/diasdavid/node-libp2p#setting-everything-up

Glad to remove the prefixes and make it everything libp2p.

[daviddias]

From @jbenet and @diasdavid discussion

• Agree that Protocol Muxing should stay in Swarm (@jbenet and @diasdavid)
• Agree that transport implementations should be the ones responsible to also offer NAT Traversal such as Hole punching and Relaying (@jbenet and @diasdavid)
• Make Discovery its own standalone subsystem (@diasdavid)
• Finalize API interface names (@jbenet)

[daviddias]

ping :)

[jbenet]

I'm going to merge this, we can make edits as we go.

[daviddias]

weeeee! :D