-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
go-libp2p v0.24 #1766
Comments
Proposal to add deprecation warning for insecure WebSockets in this release: #1830 (comment) |
Great writeup on the changelog @marten-seemann ! A few things:
Idea (might be a good thing in a retro @p-shahi ): author changelogs in markdown file like https://github.com/ipfs/kubo/blob/master/docs/changelogs (in future). It would allow building up the changelog incrementally as part of a PR for the relevant work and easier to comment on than an issue where can't suggest changes inline. |
It's still experimental in this repo. This isn't to say that we're not confident in the implementation, but we've made a ton of changes to the WebTransport code for this release, so keeping it experimental for a little bit longer seems like the safer way to go. Regarding terminology: There were two reasons why we called WebTransport experimental:
While we're gaining more confidence regarding (1), the protocol itself is guaranteed to change, which means that at some point browsers will switch from one draft version to the other, in all likelihood without any regards for backwards-compatibility (at least that's what happened for QUIC draft versions). This will immediately break compatibility with the WebTransport already deployed in go-libp2p nodes. We need to be clear in our communication that this is almost guaranteed to happen sooner or later.
That's a very unfortunate typo. Thanks for spotting it. I fixed it.
I added a "Breaking Changes" section.
I have mixed feelings about this, partly due to prior experience with this approach. Let's discuss this in the next triage call? |
Makes sense - thanks. Given our experimental status is dependent on IETF work/decisisions, we'll need to have a way to talk about it. We can talk during a triage meeting, but maybe talk about having WebTransport-draft support.
Sure. Talking about it during a retro or triage meeting sounds good. |
Is #1915 still a part of this release? It's mentioned in v0.25 as well. |
No. I just removed it. |
Because of #1904 (comment) I won't be able to make a release this week. Next week I should be able to fix that issue and make a release. |
I propose we add a bugfix section to release notes (makes it easier than going through the changelog) 🐞 Bugfixes since v0.23.4
|
The two remaining open items for this release are
Because Kubo 9423 will be closed by Kubo maintainers and we have completed our responsibility, closing this release issue as completed. |
🗺 What's left for release
Early Muxer Selection: #1789 (tracking issue)
WebTransport:
Misc:
Breaking Changes
Constructor options
libp2p.DefaultStaticRelays
andlibp2p.StaticRelays
options. Static relays can be configured as an option tolibp2p.EnableAutoRelay
libp2p.Security
now requires passing in a constructor (previously, it also allowed passing in a fully constructed security transport)libp2p.Muxer
now requires passing in a fully constructed muxer (previously, it also allowed passing in a muxer constructor)libp2pquic.DisableReuseport
andlibp2pquic.WithMetrics
. These options are now available in thequicreuse
package (quicreuse.DisableReuseport
andquicreuse.WithMetrics
), and can be enabled by using thelibp2p.QUICReuse
option (example:libp2p.QUICReuse(quicreuse.NewConnManager, quicreuse.DisableReuseport, quicreuse.WithMetrics)
).Under the hood, we now use fx in the construction of the host, which lead to a great simplification of our setup logic (see #1858 for details).
QUIC Versions
When we first rolled out QUIC support in 2020, QUIC wasn't an RFC yet (in fact, we were involved in the standardization process at the IETF!). Back then, we rolled out support for QUIC draft-29. This version is almost identical to RFC 9000, so there was never a good reason to force an update.
Now that rust-libp2p is shipping QUIC support, we decided to finally initiate the update. We do so by introducing a new multiaddress component:
/ip4/1.2.3.4/udp/4001/quic
now denotes a multiaddr that uses QUIC draft-29 (as it has before, we're just making it explicit now). QUIC v1 would use/ip4/1.2.3.4/udp/4001/quic-v1
.We intend to keep support for QUIC draft-29 for roughly half a year, and disable listening on draft-29 addresses after that.
Depending on how you configure your node, you might need to update the addresses you're listening on (i.e. change
quic => quic-v1
in the addresses, or duplicate the QUIC addresses).🔦 Highlights
WebTransport
We added experimental WebTransport support in our last release. Since then, we're using some magic to allow running QUIC and WebTransport on the same port. This means that users who've already configured port forwarding / firewall rules for QUIC don't need to do anything to allow WebTransport connections to their node.
Optimized Stream Multiplexer Selection
When dialing a TCP connection to another libp2p node, we perform the following steps:
In total, this handshakes takes 4 RTTs. In this release, we optimize this handshake by inlining the stream multiplexer negotiation into the security handshake. On the wire, this looks very different for TLS 1.3 and for Noise, but the result is the same: we know which stream multiplexer to use when the handshake finishes, and can therefore save one roundtrip on every handshake. Head to the specification to learn how this works in detail.
Changelog
...
✅ Release Checklist
go get -u ./...
to see if there are any out-of-date deps that look important. If there are, bubble them. Try to avoid directly updating indirect deps in go-libp2p'sgo.mod
when possible.The text was updated successfully, but these errors were encountered: