Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

migrations needed after updating go-libp2p v0.24.0 update #9410

Closed
5 tasks done
Tracked by #9417
marten-seemann opened this issue Nov 15, 2022 · 4 comments
Closed
5 tasks done
Tracked by #9417

migrations needed after updating go-libp2p v0.24.0 update #9410

marten-seemann opened this issue Nov 15, 2022 · 4 comments
Assignees
Labels
kind/enhancement A net-new feature or improvement to an existing feature

Comments

@marten-seemann
Copy link
Member

marten-seemann commented Nov 15, 2022

Checklist

  • My issue is specific & actionable.
  • I am not suggesting a protocol enhancement.
  • I have searched on the issue tracker for my issue.

Description

Updating to go-libp2p v0.24.0 will require a few changes / migrations on the kubo side. I'm creating this issue to keep track of these changes.

This issue is not actionable until v0.24.0 was released.

QUIC v1 codepoint

QUIC now uses a new code point to signal support for QUIC version 1 (RFC 9000). The existing code point now means signals support for QUIC draft-29. On the IPFS network, there are many nodes that support only draft-29. See multiformats/multiaddr#145 for more context.

Required kubo changes:

  • create a migration that adds listen addresses for QUIC v1, i.e. adds a /ip{4,6}/<ip>/udp/<port>/quic-v1 address for every /ip{4,6}/<ip>/udp/<port>/quic address

WebTransport support

It's now possible to run QUIC and WebTransport on the same port (see libp2p/go-libp2p#1759).

Required kubo changes:

  • create a migration that adds a WebTransport listen address, i.e. adds a /ip{4,6}/<ip>/udp/<port>/quic-v1/webtransport address for every /ip{4,6}/<ip>/udp/<port>/quic-v1 address. Note that WebTransport doesn't support QUIC draft-29
@marten-seemann marten-seemann added the kind/enhancement A net-new feature or improvement to an existing feature label Nov 15, 2022
@BigLep BigLep moved this to 🥞 Todo in IPFS Shipyard Team Nov 21, 2022
This was referenced Dec 3, 2022
@BigLep BigLep moved this from 🥞 Todo to 🏃‍♀️ In Progress in IPFS Shipyard Team Dec 7, 2022
@BigLep
Copy link
Contributor

BigLep commented Dec 7, 2022

@Jorropo : how is the migration work going for you?

@BigLep
Copy link
Contributor

BigLep commented Dec 9, 2022

Migrations are happening in ipfs/fs-repo-migrations#162

@Jorropo
Copy link
Contributor

Jorropo commented Dec 9, 2022

@BigLep I implemented both of the required migrations in: ipfs/fs-repo-migrations#162
I'll have to fix and add tests.

lidel added a commit to ipfs/ipfs-webui that referenced this issue Dec 9, 2022
lidel added a commit to ipfs/ipfs-webui that referenced this issue Dec 9, 2022
lidel added a commit to multiformats/js-multiaddr that referenced this issue Dec 9, 2022
multiformats/multiaddr#145
ipfs/kubo#9410

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>
achingbrain pushed a commit to multiformats/js-multiaddr that referenced this issue Dec 10, 2022
This PR adds support for `/quic-v1` which will be enabled by default in
Kubo 0.18 (ipfs/kubo#9417,
ipfs/kubo#9410).

@achingbrain @tinytb FYSA an important caveat is that WebTransport addrs
will be `/quic-v1/webtransport`
(as noted in ipfs/kubo#9410).

Ref.
- ipfs/kubo#9410
- multiformats/multiaddr#145

Signed-off-by: Marcin Rataj <lidel@lidel.org>
@BigLep
Copy link
Contributor

BigLep commented Dec 13, 2022

Closing since handled in ipfs/fs-repo-migrations#162

@BigLep BigLep closed this as completed Dec 13, 2022
Repository owner moved this from 🏃‍♀️ In Progress to 🎉 Done in IPFS Shipyard Team Dec 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement A net-new feature or improvement to an existing feature
Projects
No open projects
Archived in project
Development

No branches or pull requests

3 participants