You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 7, 2022. It is now read-only.
While the dat-node network stack is in flux (see #247), I would like to propose running discovery-swarm-webrtc in parallel with hyperswarm going forward. WebRTC is currently the best way to reach the web platform at present, and a better alternative is unlikely to come in the short or medium term.
Having a dual network stack in dat-node would allow it to bridge dat content to web clients for little extra cost. In Cliqz we currently run webrtc discovery in parallel with discovery-swarm, and this improves peer connectivity in several cases.
Here are some of the advantages of a dual stack approach:
(Partial) uniformity in peer discovery across platforms. Dat in the browser will be compatible with dat-node. This could revive dat-js, and avoid the hacks currently needed to bridge between node and web.
Improved peer connectivity. WebRTC has lots of NAT traversal tricks built into it. In tandem with hyperswarm's holepunching this could help peers on tricky NATs become connectable.
There are some disadvantages:
Requires one or more central signalling servers for brokering webrtc connections. Note that discovery-swarm's discovery was also fairly centralised, particularly the DNS discovery mechanism, so this is not a significant paradigm shift. I currently host a signal server at https://signal.dat-web.eu/ for projects using webrtc discovery, and would be happy to offer it for use in dat-node.
Performance. WebRTC data channel performance is not as good as raw TCPSockets. I am, however, not sure that we are hitting the upper bounds of network performance in most dat use-cases anyway.
Size. The node webrtc implementation is a large project and requires native binaries. This could affect install speed and somewhat bloats binary size.
Would be happy to hear other thoughts on this.
If you would accept this change, I would be happy make a PR with this change.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I am reporting:
While the dat-node network stack is in flux (see #247), I would like to propose running discovery-swarm-webrtc in parallel with hyperswarm going forward. WebRTC is currently the best way to reach the web platform at present, and a better alternative is unlikely to come in the short or medium term.
Having a dual network stack in dat-node would allow it to bridge dat content to web clients for little extra cost. In Cliqz we currently run webrtc discovery in parallel with discovery-swarm, and this improves peer connectivity in several cases.
Here are some of the advantages of a dual stack approach:
There are some disadvantages:
https://signal.dat-web.eu/
for projects using webrtc discovery, and would be happy to offer it for use in dat-node.Would be happy to hear other thoughts on this.
If you would accept this change, I would be happy make a PR with this change.
The text was updated successfully, but these errors were encountered: