Peer discovery

[tzdybal]

Initial peer discovery will be done via static configuration. Those bootstrap/seed nodes will then be used by go-libp2p-discovery to connect to the rest of the network and maintain a peer list.

[tzdybal]

For better UX, we should re-use options/configs already available in cosmos-sdk apps.
(This will also greatly limit changes required in cosmos-sdk.)

[tzdybal]

It seems that go-libp2p-kad-dht, which provides most advanced peer discovery for libp2p, can also handle bootstrapping.

[tzdybal]

ref: libp2p/go-libp2p#222

[liamsi]

There are a few examples using the libp2p bootstrap nodes here: https://github.com/libp2p/go-libp2p-examples/tree/master/

[tzdybal]

All those examples are using public libp2p bootstrapping addresses.

There are two three options:

1. Use public bootstrapping nodes.
2. Use own bootstrapping nodes (also reachable from the Internet).
   1. One set of seed nodes for all all ORU networks.
   2. One set of seed nodes per every application/network

The more "granular" approach, the more "specific" peers will be returned by seed nodes.
In 2.ii, there is no need to further filter peers based on supported protocol, app, etc.
The 1. should probably result in very large number of peers, but only few will be actually interesting.

And this is not only configuration issue. If we allow 1. or 2.i, we need a filter peers by protocol and application/network.

[liamsi]

And this is not only configuration issue. If we allow 1. or 2.i, we need a filter peers by protocol and application/network.

But the filtering will be done by libp2p internally and does not require any additional code from our side, right?
If so, can't we go with 1. and optimize for "granularity" as we progress with the rest of the optimint stack? I think 1. would have the benefit that these nodes are simply available and we can use them directly without bothering on spinning up our own bootstrap nodes.

[tzdybal]

I was experimenting with it, but it seems that we will need to do some filtering. Now I'm looking at connection gater and connection manager.

My experiment above, spawned 100 libp2p hosts, and 1 "seed node" and then used DHT to find connections. After "bootstrapping DHT" (internat DHT thing, do not confuse with seed connections bootstrapping) most hosts know about and are connected to other peers. I tried "active discovery" (DHT based namespace Advertise + FindPeers), hoping to get hosts "grouped by namespace", but in the end everyone is connected to everyone else (with some small exceptions, but I guess it's just a matter of time).

[liamsi]

Is it a problem if everyone is connected to everyone though? For LL-core (at least for the MVP) we will accept that our peers connect to all IPFS nodes. Later we will try to narrow it down to ipfs peers that run a particular protocol ID s.t. ll nodes only talk to ll nodes (basically ipfs nodes with a particular plugin installed). ref: https://github.com/lazyledger/lazyledger-core/issues/154

[Wondertan]

@tzdybal, what is the difference between "seed" and "bootstrap" node?

[Wondertan]

To make nodes prefer connections for applications they are more interested in, use ConnectionMaganer to tag peers with namespace and some weight num the namespace have for the concrete node. ConnectionManager then will drop unneeded connections if the connections limit exceeds while keeping useful(with weight) peers connected.

[Wondertan]

Does the 2.ii option force application developers to host bootstrap nodes for their applications?

I am leaning towards having one big network(separate from IPFS) that would allow any node to access any namespaced application/overlay network by finding nodes that are advertising themselves as a part of that namespace. That would require us to have only one static set of bootstrap peers for initial bootstrapping where later nodes could bootstrap themselves through a saved dynamic list of more useful peers.

[tzdybal]

@tzdybal, what is the difference between "seed" and "bootstrap" node?

There is no difference (except the name).

Does the 2.ii option force application developers to host bootstrap nodes for their applications?

Yes, 2.ii is the most simplified version, where each network is absolutely separated, consists of participating nodes only.

---

Both 1 and 2.i requires the same amount of development - we need to find peers for exact application. Tagging peers to select those interesting, while participating in broader network seems to be very good option.
@Wondertan could you elaborate why you're leaning towards network separated from IPFS? Pros I can see: not cluttering IPFS network, smaller number of peers to check/filter.

[liamsi]

I think, if we connect to the main IPFS network, peers will be connected to a lot (hundreds of) nodes and most of them will not have the LL plugin installed. Hence it's not really useful to connect to them.

Both 1 and 2.i requires the same amount of development - we need to find peers for exact application.

I was somehow assuming that this is sth that libp2p provides without us having implement the filtering etc our self. Is that not the case?