search

textileio / go-textile

[DEPRECATED] Textile is a set of tools and infrastructure for building composable apps and services on the IPFS network
https://textile.io
MIT License
357 stars 43 forks source link

Add QUIC transport layer to libp2p components #853

Closed carsonfarmer closed 4 years ago

carsonfarmer commented 5 years ago

After a discussion with folks at IPFS Camp (end of June), it has become clear that we need to start exploring using the QUIC transport protocol layer in our libp2p components. This, in theory, is a pretty simple change/update. However, because we are using ED25519 keys for our IPFS peers, things get tricky. This issue will document those issues, and hopefully outline a reasonable path towards adoption of QUIC.

First, why add QUIC support? Apparently it comes with easier NAT hole punching, better handling of network changes (i.e., from lte to wifi and back again), and generally a more consistent experience, particularly on mobile.

Secondly, what is the issue? Simply stated, a lack of support for ed25519 keys. Recently, Golang has added support for Ed25519 keys to the standard library. This will make it into the 1.3 release. This is great news, because it means things like crypto/lts, crypto/x500, etc will support Ed25519 out of the box. In fact, there is already a PR to add this support via a Golang upgrade.

The downside here, as stated in comments on that PR, is mainly that:

  1. its not really great until after 1.13 is released (which is very soon)
  2. this won't work with other nodes that haven't updated to a libp2p release compiled with Go 1.13 (and therefore won't be able to complete the handshake)
  3. there might be a more 'stable' approach that libp2p folks are already aware of: https://github.com/libp2p/go-libp2p-quic-transport/issues/18

It might be ok to use the go1.3 version if we also continue to support our current transports... which would make our nodes backward compatible with the rest of the network, but only compatible over quic with our (or other) peers that have made the upgrade.

So to summarize: quic transport is a really good idea... but given we are using ed25519 keys, we either a) wait for a libp2p generic fix (best), b) wait for go v1.13 to be released (easiest), or c) do it ourselves using a custom libp2p-quic implementation (hardest).

carsonfarmer commented 5 years ago

This should be ready to try thanks to: https://github.com/libp2p/go-libp2p-quic-transport/pull/67

carsonfarmer commented 4 years ago

Research in #926 and https://github.com/textileio/go-threads/issues/10 preclude this ticket