clarify libp2p section

Matthew Hodgson 2020-06-03 17:09:54 +01:00
parent ca0a8e361d
commit 609c35bc43
1 changed files with 1 additions and 1 deletions

@ -60,7 +60,7 @@ Finally, we use a [rendezvous server](https://github.com/libp2p/js-libp2p-websoc
We implement a custom `http.RoundTripper` in our Federation client which hits out to the p2p network. We actually use the JS version of libp2p rather than the Go version because it was easier to get things set up that way. This code uses similar communication techniques already decribed and the [code can be found here](https://github.com/matrix-org/go-http-js-libp2p). We've found peer discovery can take a while, and latency when sending data scales badly with load - likely because the rendezvous server gets overloaded (it often maxes out a CPU core).
The libp2p JS libraries themselves are haphazard, with a mix of old and new style JS. Many libraries depend on other libraries, and it's easy to use incompatible versions of certain libraries together (e.g a newer version of `peer-info` with an older version of `peer-id`) which then fails in obscure ways. We've hit various scenarios whereby requests seemingly black hole, even when specifying sensible timeouts. Overall though, it just about works for demo purposes but we wouldn't want to run anything "production grade" on it.
The libp2p JS libraries have some quirks - stylistically they are in the middle of a transition from old to new JS codestyles, and the large number of dependencies means that it can be easy to use incompatible versions of certain libraries together (e.g a newer version of `peer-info` with an older version of `peer-id`) which then fails in obscure ways. We've also hit a few various scenarios whereby requests seemingly black hole, even when specifying sensible timeouts. Overall though, it works okay enough for the purposes of the demo.
#### Conclusions