From 19c3c230526d1d685ead205a884b7755627bdd2c Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Wed, 3 Jun 2020 17:11:25 +0100 Subject: [PATCH] clarify why we picked js-libp2p rather than go-libp2p --- How-p2p.riot.im-works.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/How-p2p.riot.im-works.md b/How-p2p.riot.im-works.md index 7ea4db1..6e74a79 100644 --- a/How-p2p.riot.im-works.md +++ b/How-p2p.riot.im-works.md @@ -58,7 +58,7 @@ Overall, working with service workers has been the hardest part of this entire p Finally, we use a [rendezvous server](https://github.com/libp2p/js-libp2p-websocket-star-rendezvous) to act as a relay for peer-to-peer traffic. This means all traffic goes via a central server: not quite as peer-to-peer as we'd like. We'd like to use WebRTC data channels in the future, but currently [service workers do not support them](https://github.com/w3c/webrtc-pc/issues/230). This means that if you have two browsers on the same laptop they'll still bounce via the relay server. -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). +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 to avoid having to shim all the p2p network activity (e.g. websockets or webrtc) through to JS from Go, and to make it easier to debug the libp2p side in-browser. 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 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.