Skip to content
This repository has been archived by the owner on Jan 7, 2022. It is now read-only.

Use discovery-swarm-webrtc in addition to existing swarm #249

Open
1 of 4 tasks
sammacbeth opened this issue Mar 26, 2020 · 0 comments
Open
1 of 4 tasks

Use discovery-swarm-webrtc in addition to existing swarm #249

sammacbeth opened this issue Mar 26, 2020 · 0 comments

Comments

@sammacbeth
Copy link

I am reporting:

  • a bug or unexpected behavior
  • general feedback
  • feature request
  • security issue

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.

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

No branches or pull requests

1 participant