Public list of peer IDs

Ecosystem
1

Hey there :wave:

I want to kick off a discussion about sharing peer IDs.

Fission’s CLI tool tells the local IPFS daemon what the peer IDs of our servers are so that we can more reliably direct connect to a person’s desktop.

We’d love to include other well-known peer IDs that are run as super peers.

@dietrich what are the Protocol Labs peer IDs?

Where should we store them? In a repo somewhere, where anyone can PR new peers?

cc @carsonfarmer from Textile who’s on vacation but had some thoughts on this, and might have at least one PeerID to share.

2

I think we don’t guarantee stability of peer IDs (particularly the IPFS gateways). We have some more or less stable cluster peers at /dnsaddr/ipfs-nodes.cluster.ipfs.io but I also would not want people to think of them as eternally available.

Ideally the DHT works well enough as discovery service (best if people actually upgrade to post 0.5.0 releases).

3

Thanks @hector

In practice, we are seeing developers installing IPFS on their laptops around the world alongside our CLI tool. To ensure that they have a good route to our servers, we swarm connect with our peer IDs.

Without this, we haven’t seen the ability for our servers to reliably fetch FROM the ephemerally connected developer laptops.

The goal is to better connect these nodes on dev laptops into super peers, and thus have a good experience using the IPFS protocol.

4

We haven’t seen the ability for our servers to reliably fetch FROM the ephemerally connected developer laptops

Because they are probably DHT clients and are not dialable from the outside? Other than that, those dev machines should be getting good enough connectivity via standard bootstrappers, your supernodes and the DHT. Any other “superpeers” are more unlikely to request content from the developers laptops for this to make a difference, and will drop connections from their side as needed as they serve other purposes.

5

Maybe what is needed is to form rings of users with same interests (in this case Fission) so that they are better connected among themselves. This is what you are partially resolving by having them call home on specific nodes.

You could (additionally) use a specific pubsub topic to broadcast peer addresses from Fission users so that other Fission nodes subscribe and attempt to connect to them as they arrive.

6

Yep, we can do this, and we can build it into our defaults.

I guess I’m looking for a wider community of people actually using IPFS and wanting to interconnect and handle app / hosting use cases, rather than just documents / archive. If there isn’t anything like this now, we’ll build it and improve on it by ourselves.

Perhaps this is a bit like collab clusters – but not for static documents, but rather changing data as is used by apps, OrbitDB use cases, etc.