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

chore(roadmap): move webrtc to done #549

Merged
merged 2 commits into from
Jun 1, 2023

Conversation

mxinden
Copy link
Member

@mxinden mxinden commented May 31, 2023

With #412 and
#497 merged, this roadmap item can be moved to "done".

With libp2p#412 and
libp2p#497 merged, this roadmap item can be moved
to "done".
@mxinden mxinden requested a review from p-shahi May 31, 2023 01:57
ROADMAP.md Outdated Show resolved Hide resolved
Co-authored-by: Prithvi Shahi <[email protected]>
@mxinden mxinden merged commit 7321c89 into libp2p:master Jun 1, 2023
@BigLep
Copy link
Contributor

BigLep commented Jun 2, 2023

This feels a bit premature to me to close. I can see the argument for doing so given the specs are done, but taking from the roadmap item text: "With WebRTC browsers will thus be able to connect to these previously unreachable nodes. In addition, being able to hole punch allows browsers to connect to nodes behind firewalls and NATs e.g. other browsers."

The items I think we need here are:

  1. Browser to go-libp2p nodes since go nodes are most plentiful public installation that we're aware of
  2. Neither go nor rust has enabled browser to private server right?

I agree lots of great work has happened here including browser to browser, but my concerns are:

  1. don't want to dilute the definition of done in general
  2. looking at the roadmap, there is nothing else about completing the connectivity matrix and I don't want to give the impression that we have full connectivity.

Maybe stepping back: what are we trying to signal or accomplish by marking this as done at this stage?

@mxinden
Copy link
Member Author

mxinden commented Jun 5, 2023

Maybe stepping back: what are we trying to signal or accomplish by marking this as done at this stage?

By marking this as done I want to signal that establishing WebRTC connections in all combinations (i.e. all permutations of private/public to private/public) is now fully specified. In other words, any libp2p implementation can now implement these protocols without the need for specification, in other words without the need for driving consensus, across libp2p implementations.

Browser to go-libp2p nodes since go nodes are most plentiful public installation that we're aware of

I would consider this a go-libp2p goal and thus an item for the go-libp2p roadmap.

Neither go nor rust has enabled browser to private server right?

Correct. I think that should be tracked in the corresponding implementation roadmaps. E.g. see rust-libp2p's /webrtc from the browser roadmap item.

Similar to marking WebRTC as done, we also marked WebTransport as "Done". Given that rust-libp2p does not yet implement WebTransport, we have a WebTransport roadmap item in the rust-libp2p roadmap.

looking at the roadmap, there is nothing else about completing the connectivity matrix

From a specifications perspective, that is the case, no?

I guess ultimately this boils down to whether the roadmap in libp2p/specs should be the general libp2p roadmap or the libp2p specifications roadmap. I don't have a strong opinion on this. I defaulted to the latter in this pull request.

In case we go for the former, how do we decide when to mark an item as done? When the majority of libp2p implementations implement the protocol? How do we measure majority? E.g. does py-libp2p as one example of an unmaintained implementation even be considered?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants