-
Notifications
You must be signed in to change notification settings - Fork 447
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
It's (beyond) time to sunset the *-star protocols 🌅 #385
Comments
I suggest to make this effort implementation independent. That should make it fairly straightforward to adapt libp2p/go-libp2p-webrtc-direct and get webrtc working between the browser and Go clients. |
I'm 👍 on this. Maybe I'm missing something but I think there's a piece missing... Right now, websocket-star is the most reliable way for JS IPFS nodes in the browser to discover and communicate with each other. It kinda works because we don't have the whole of the IPFS network using it, and it cannot be discovered by the rest of the IPFS network (or used since there's no Go impl). This makes it great for demos, development and testing. In the proposal , we'd be taking this resource away from the community without providing a replacement. Can we setup some circuit relays that JS IPFS nodes can use for demos, development and testing but the rest of the network doesn't discover and use on a day to day basis? I'm not familiar with how you'd go about doing that, it's possible right? I imagine it's something application developers would really need also. |
Not the case, let me clarify. The proposal contemplates:
This is a direct replacement that will be transparent. In fact, users might see things getting faster and more reliable as they will be able to use go-libp2p (more performant) as a circuit relay. This way everything is a libp2p node, no custom pieces that reimpl the same thing. |
https://github.com/libp2p/js-libp2p-rendezvous should be close as the initial spec didn't deviate much but needs to be updated and heavy testing still needs to be done. It doesn't have any federation at this point, but we don't need that to replace the star servers. Federation will need to be added in the future to better support decentralization of the node. I have been thinking through the flow for doing connection upgrades for WebRTC signaling over the circuit. Part of that potentially uses the DHT (local or delegate) as a means of finding services instead of Rendezvous. This would allow us to spend more of our effort improving that, instead of fragmenting our focus. Here are my notes on how that flow could/would look: Connection flow
|
On `js-ipfs@0.41`, we removed the `websocket-star` module from the libp2p default configuration for browser nodes in `js-ipfs`. We removed it because this module was not refactored during #1670, since the libp2p goal is to [sunset the star protocols](libp2p/js-libp2p#385) and we preferred to use the time refactoring `websocket-star` into improving the browser support. In the refactor, the `webrtc-star` module was refactored so that browser users could discover other peers in the network. In addition, `circuit-relay` may be used for establishing connections between browser nodes using `websockets`. However, this migration has not been smooth for `js-ipfs` users. Users previously using `websocket-star` swarm addresses, did not have enough visibility of this change, since the removal of `websocket-star` was transparent for them and on the default `js-ipfs` release and not technically a programmable breaking change. With the above in mind, once `js-ipfs` users updated they started getting errors from `js-libp2p` in scenarios where they were providing only `websocket-star` swarm addresses. When `js-libp2p` receives listening multiaddrs, it throws an error if it cannot use any to listen on the configured transports, which was the case here (For instance #2779). In `js-libp2p`, we added an option to tolerate these errors [libp2p/js-libp2p#643](libp2p/js-libp2p#643), which was also mentioned for some other cases earlier. After syncing about this issue, we decided to temporarily throw an error when `js-ipfs` receives `websocket-star` multiaddrs. This aims to help users who still need to migrate to identify the problem faster.
@p-shahi with |
Yes closing this, we're deprecating them here: #1488 |
Long story short for context:
Proposal:
Let's sunset the *-star protocols 🌅
To clarify:
Direct benefits:
Candidate Roadmap:
The text was updated successfully, but these errors were encountered: