fix: Rename `Protocol::WebRTC` to `Protocol::WebRTCDirect` #78

mxinden · 2023-03-17T11:39:14Z

See multiformats/multiaddr#150 (comment) for context.

@melekes @thomaseizinger can you give this a review?

See multiformats/multiaddr#150 (comment) for context.

melekes

👍

melekes · 2023-03-18T03:42:22Z

src/protocol.rs

@@ -202,7 +202,7 @@ impl<'a> Protocol<'a> {
            }
            "p2p-websocket-star" => Ok(Protocol::P2pWebSocketStar),
            "p2p-webrtc-star" => Ok(Protocol::P2pWebRtcStar),
-            "webrtc" => Ok(Protocol::WebRTC),
+            "webrtc-direct" => Ok(Protocol::WebRTCDirect),


I must say having both webrtc-direct and p2p-webrtc-direct is confusing, but I guess nothing we can do about it other than adding clear documentation.

We could as well deprecate p2p-webrtc-direct. I am not aware of anyone using it. Though intuitively, that decision should happen on https://github.com/multiformats/multiaddr.

thomaseizinger

Could we first release a version where we accept parsing as /webrtc-direct and not rename the variant, thus making this a non-breaking change?

I'd like to batch some breaking changes in rust-multiaddr together, e.g. #77 and #73 but those are not ready yet. Especially #73 needs a breaking change in libp2p-identity first which implies a round of breaking changes to libp2p.

mxinden · 2023-03-20T16:10:53Z

Could we first release a version where we accept parsing as /webrtc-direct and not rename the variant, thus making this a non-breaking change?

On first thought this is a great idea. Though I am not sure there are no hidden surprises with this strategy. E.g. the guarantee of round-trip parsing (/webrtc-direct -> binary -> /webrtc-direct) no longer holds.

Breaking change:

Avoid long-term confusion, i.e. get it over with quickly
Needs a breaking change in libp2p

Non-breaking change:

Safes us and our users a lot of work
Might be a footgun
Could also default to /webrtc-direct from binary to text already now
Takes time to fully finish, thus less time between now and the introduction of browser-to-browser /webrtc

Thoughts @thomaseizinger?

mxinden · 2023-03-21T18:15:24Z

Friendly ping @thomaseizinger. What are your thoughts here?

thomaseizinger · 2023-03-21T18:19:57Z

Friendly ping @thomaseizinger. What are your thoughts here?

Didn't submit my comment 🤦‍♂️

thomaseizinger · 2023-03-21T18:20:21Z

Could we first release a version where we accept parsing as /webrtc-direct and not rename the variant, thus making this a non-breaking change?

On first thought this is a great idea. Though I am not sure there are no hidden surprises with this strategy. E.g. the guarantee of round-trip parsing (/webrtc-direct -> binary -> /webrtc-direct) no longer holds.
Breaking change:

Avoid long-term confusion, i.e. get it over with quickly

Needs a breaking change in libp2p

Non-breaking change:

Safes us and our users a lot of work

Might be a footgun

Could also default to /webrtc-direct from binary to text already now

Takes time to fully finish, thus less time between now and the introduction of browser-to-browser /webrtc

Thoughts @thomaseizinger?

What we'd need to work out is how exactly we are going to introduce the other /webrtc protocol after this.

We definitely need to log a deprecation warning if we are now adding the 2nd representation.

Then in a breaking change, we can rename the variant and add the "new" /webrtc protocol.

How big is the footgun actually?

thomaseizinger · 2023-03-21T18:26:42Z

How big is the footgun actually?

The only problem I can think of is that in the "breaking" change where we add the new (browser-to-browser) /webrtc protocol, users of multiaddr might not realise that the WebRTC protocol semantically changes. However, afaik the only user of this is us in libp2p-webrtc and we know to be careful here.

Ideally, semantic breaking changes are also compile-time breaking changes but I'd say with sufficient documentation, we can also deviate from that. I've pushed multiformats/rust-multihash#272 forward a lot so I'd love if the next breaking change can already include that (and thus be the last one in a while).

thomaseizinger · 2023-03-21T18:27:18Z

If we move forward with this, it would have to be done as a patch-release from 0.17.0 because master already contains breaking changes.

mxinden · 2023-03-22T12:55:35Z

Pull request for the non-breaking change: #84

… into webrtc-direct

mxinden · 2023-03-23T09:32:02Z

With #84 released as v0.17.1, I updated this pull request, making the breaking change of renaming Protocol::WebRTC to Protocol::WebRTCDirect and removal of the deprecated /webrtc string representation.

mxinden · 2023-03-23T09:32:50Z

I seem to only be able to request a review from one of the two of you.

thomaseizinger · 2023-03-23T13:45:52Z

CHANGELOG.md

@@ -1,9 +1,15 @@
-# 0.18.0 [unreleased]
+# 0.18.0 - unreleased

 - Add `WebTransport` instance for `Multiaddr`. See [PR 70].
 - Disable all features of `multihash`. See [PR 77].
 - Mark `Protocol` as `#[non_exhaustive]`. See [PR 82].


This means we can then later add WebRTC in a non-breaking way right?

CHANGELOG.md

Co-authored-by: Thomas Eizinger <thomas@eizinger.io>

DougAnderson444 · 2023-05-05T12:46:08Z

@mxinden when is this v0.18 planned for release so that we can use the new naming without patches?

thomaseizinger · 2023-05-05T12:52:13Z

I'd first like to get a release of rust-multihash out: https://github.com/multiformats/rust-multihash/milestone/1

thomaseizinger · 2023-05-05T13:04:33Z

I'd first like to get a release of rust-multihash out: multiformats/rust-multihash/milestone/1

I've created a milestone for rust-multiaddr too so we can easily keep track of this: https://github.com/multiformats/rust-multiaddr/milestone/3

fix: Rename /webrtc to /webrtc-direct

d58d333

See multiformats/multiaddr#150 (comment) for context.

mxinden force-pushed the webrtc-direct branch from 79d3c7b to d58d333 Compare March 17, 2023 11:46

mxinden mentioned this pull request Mar 17, 2023

feat: Add /webrtc protocol (browser-to-browser) #79

Draft

melekes approved these changes Mar 18, 2023

View reviewed changes

thomaseizinger reviewed Mar 20, 2023

View reviewed changes

mxinden mentioned this pull request Mar 23, 2023

/webrtc /webrtc-direct rename proceeding #86

Open

3 tasks

mxinden changed the title ~~fix: Rename /webrtc to /webrtc-direct~~ fix: Rename Protocol::WebRTC to `Protocol::WebRTCDirect Mar 23, 2023

mxinden changed the title ~~fix: Rename Protocol::WebRTC to `Protocol::WebRTCDirect~~ fix: Rename Protocol::WebRTC to Protocol::WebRTCDirect Mar 23, 2023

Merge branch 'master' of https://github.com/multiformats/rust-multiaddr…

8cc971f

… into webrtc-direct

mxinden force-pushed the webrtc-direct branch from a327b19 to 8cc971f Compare March 23, 2023 09:30

mxinden requested review from thomaseizinger and melekes and removed request for thomaseizinger and melekes March 23, 2023 09:32

thomaseizinger approved these changes Mar 23, 2023

View reviewed changes

Update CHANGELOG.md

2c2582e

Co-authored-by: Thomas Eizinger <thomas@eizinger.io>

mxinden merged commit 13a1e9e into multiformats:master Mar 24, 2023

DougAnderson444 mentioned this pull request Apr 14, 2023

Construct addresses using MultiAddr, defaulting to IPv6 libp2p/universal-connectivity#46

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix: Rename `Protocol::WebRTC` to `Protocol::WebRTCDirect` #78

fix: Rename `Protocol::WebRTC` to `Protocol::WebRTCDirect` #78

mxinden commented Mar 17, 2023

melekes left a comment

melekes Mar 18, 2023 •

edited

Loading

mxinden Mar 19, 2023

thomaseizinger left a comment

mxinden commented Mar 20, 2023

mxinden commented Mar 21, 2023

thomaseizinger commented Mar 21, 2023

thomaseizinger commented Mar 21, 2023

thomaseizinger commented Mar 21, 2023

thomaseizinger commented Mar 21, 2023

mxinden commented Mar 22, 2023

mxinden commented Mar 23, 2023

mxinden commented Mar 23, 2023

thomaseizinger Mar 23, 2023

mxinden Mar 24, 2023

DougAnderson444 commented May 5, 2023

thomaseizinger commented May 5, 2023

thomaseizinger commented May 5, 2023

fix: Rename Protocol::WebRTC to Protocol::WebRTCDirect #78

fix: Rename Protocol::WebRTC to Protocol::WebRTCDirect #78

Conversation

mxinden commented Mar 17, 2023

melekes left a comment

Choose a reason for hiding this comment

melekes Mar 18, 2023 • edited Loading

Choose a reason for hiding this comment

mxinden Mar 19, 2023

Choose a reason for hiding this comment

thomaseizinger left a comment

Choose a reason for hiding this comment

mxinden commented Mar 20, 2023

mxinden commented Mar 21, 2023

thomaseizinger commented Mar 21, 2023

thomaseizinger commented Mar 21, 2023

thomaseizinger commented Mar 21, 2023

thomaseizinger commented Mar 21, 2023

mxinden commented Mar 22, 2023

mxinden commented Mar 23, 2023

mxinden commented Mar 23, 2023

thomaseizinger Mar 23, 2023

Choose a reason for hiding this comment

mxinden Mar 24, 2023

Choose a reason for hiding this comment

DougAnderson444 commented May 5, 2023

thomaseizinger commented May 5, 2023

thomaseizinger commented May 5, 2023

fix: Rename `Protocol::WebRTC` to `Protocol::WebRTCDirect` #78

fix: Rename `Protocol::WebRTC` to `Protocol::WebRTCDirect` #78

melekes Mar 18, 2023 •

edited

Loading