Tracking: refactor + transports effort

[jbenet]

Tracking: refactor + transports effort

Transport Interface Refactor: libp2p/go-libp2p-transport#21

(this is actually a DAG, not a tree).

• TLS PRs

  • Precisely determine and record the blockers.
  • Decide if we want to merge the existing PR before the refactor. This really depends on how much work is left in this PR.
    • Con: The package against which the current PRs have been made won't exist after the refactor so this may be more work in the long run.
    • Pro: If we can just merge this now, we won't have to do any additional work undoing hacks/rebasing (because the go-libp2p-conn library is going away).
    • Con: If we merge it now, we have to get it working in the refactor before merging the refactored transport system (or we'll lose a feature).
  • Migrate the TLS integration to the refactored libp2p. This should actually be fairly straight forward. The transport refactor will make security transports pluggable.

• Finish the transport interface refactor

  • Implement
  • Review/Merge
  • Implement in go-ipfs
  • Review/merge in go-ipfs

• Get QUIC merged into go-ipfs

  • Option 1: Hack it (Tracking: refactor + transports effort #279 (comment))
    • Come up with a viable hack.
    • Implement the hack.
    • Review/merge the hack.
    • Finish the transport interface refactor.
    • Rollback the hack and make this use the refactored transports.
  • Option 2: Finish the transport interfaces refactor.
    • Merge the QUIC implementation.

[jbenet]

cc @Stebalien

[Stebalien]

Given that the libp2p transport refactor will still take a while to review/merge (although they're getting pretty close to being done), @jbenet asked me to come up with a few hacks to get QUIC merged now so we can start playing around with it.

Requirements:

• Contained. The hacks shouldn't require cascading changes. Ideally, just change swarm a bit (and revert the commits later).
• Invisible. Along the same vein, the hacks shouldn't be noticeable, if at all possible. No changes to interface.
• Easy. If it takes us too long to implement/design the hack, it's not worth it.

This comment will track the proposed hacks.

[marten-seemann]

I tried hacking QUIC into libp2p some time ago, and I didn't find an easy way to get it running. Considering how different the QUIC connection setup is from what we had before, I don't think it will be possible to fulfil the three requirements listed above.

Today I managed to get the libp2p echo example working over QUIC, using the refactored transport interfaces and the new libp2p QUIC transport: https://github.com/marten-seemann/libp2p-quic-transport/tree/feat/refactor.

QUIC also uses TLS for the handshake (TLS 1.3, but I don't think it makes a difference for us). I only had a quick look at the TLS PR so far, but it might be possible to reuse some code. What are our priorities regarding this? Maybe it makes the most sense to first change the transport interfaces, and then take care of the QUIC and TLS integration afterwards (at the same time?).

[marten-seemann]

This has been resolved a loooong time ago.