Experiments in libp2p connectivity
Go to file
decentral1se bf36dc458c
wip: pears
2023-06-03 22:15:48 +02:00
.gitignore wip: pears 2023-06-03 22:15:48 +02:00
LICENSE wip: pears 2023-06-03 22:15:48 +02:00
README.md wip: pears 2023-06-03 22:15:48 +02:00
go.mod wip: pears 2023-06-03 22:15:48 +02:00
go.sum wip: pears 2023-06-03 22:15:48 +02:00
pear.go wip: pears 2023-06-03 22:15:48 +02:00

README.md

🍐

Experiments in local-first & friend-to-friend libp2p connectivity

libp2p Go binaries for testing p2p connectivity. I mostly rely on having out-of-band methods for sharing connection details, so I'm not looking at discovery. Since libp2p was developed within the context of global p2p connectivity, I'm curious if it smoothly supports local-first and friend-to-friend network architectures like those of the Scuttleverse (no DHT by default and use of relay facilitated connections ("pubs", rooms)).

Update: the answer is: yes, it does!

Scenarios

Public to public (IPv4)

First:

./pear

Second:

./pear -with <first-multiaddr>

Local-first

First:

./pear

Second:

./pear -port 9001 -with <first-multiaddr>

Private to private (NAT) using self-hosted relay

Here's some useful docs for this one.

There's quite a few things going on under the hood to keep in mind, e.g. both peers making connections to the relay first, reserving a slot via the one receiving the connection and then the multiaddr of the relayed address is also a bit involved.

Ideally, your two pear instances which will make relayed connections in this scenario won't have connectivity already.

You'll need two machines which are both NATT'd behind a router. I don't think they can be on the same machine because libp2p seems to be smart enough to know that two pear instances are on the same machine and achieve connectivity.

Run a pear instance in relay mode on a VPS with a public IPv4, and then connect two additional pear instances running on your NATT'd machines via this relay.

Relay:

./pear -relay

First:

./pear -reserve -with <relay-multiaddr>

The first peer must reserve a slot at the relay and permit the relay to listen for incoming connections on its behalf (docs).

Second:

./pear -with <first-multiaddr> -via <relay-multiaddr>

Private to private (NAT) using holepunching (also with self-hosted relay)

Same as the above example but for the first peer, you pass -holepunch:

./pear -reserve -holepunch -with <relay-multiaddr>

Build

go build -v .

Notes

Multiaddr including peer identifiers

pear encapsulates addresses that it outputs to stdout which is handy for copy/pasta'ing to other pear instances. So, for example, instead of only getting:

/ip4/10.137.13.236/tcp/9000,

You get:

/ip4/10.137.13.236/tcp/9000/p2p/12D3KooWPfGmeozKqrge9Peoi1KV8neku2rqTddZ9aLiZM7Htgpq

This is the pear multiaddr which includes the peer identifier which other pear instances will require for addressing.

Binary size

Even the simplest libp2p Go program ends up being ~ 20/30 megabytes in size. This can be reduced using some tricks e.g. upx --best --lzma and -ldflags="-s -w".