libp2p / libp2p/universal-connectivity
WebRTC browser-to-browser connections fail in github version (deployed or local `yarn dev`) but work in official, deployed app
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 167
- Forks
- 75
- PR merge metrics
- No merged PRs in 30d
Description
**Commit / version:** `0254d9602a89492ae61bffa9ae3e41bb7ff7a493`
**Description:**
I’m generally able to establish WebRTC connections using the Universal Connectivity app, but only when using the **official deployed app** at:
[https://universal-connectivity.on-fleek.app/](https://universal-connectivity.on-fleek.app/)
When running the app locally using `yarn dev`, direct browser-to-browser WebRTC connections fail. The different instances discover each other though and can also exchange messages.
**What works:**
* WebRTC connection: **Official App → Dev App** ✅
* WebRTC connection: **Official App → Official App** ✅
**What doesn’t work:**
* WebRTC connection: **Dev App → Local App** ❌
I tested this under different local networks, both online and offline — results are consistent. I also deployed my own version of the app online (using the same p2p-code as the official version ) and getting the same error.
What I don't understand is why this works only in the deployed version, but not in the github version. I tried deploying it to my own https. domain and it doesn't work there either I am getting the same errors there as in local dev version.
---
**Suspected cause:**
From my debugging, it seems the failure might be related to the inability to negotiate `/webrtc-signaling/0.0.1` in the github version of the universal connectivity demo. This likely prevents proper SDP exchange for WebRTC.
**Relevant error log (excerpt):**
```
libp2p:discovery:pubsub discovered peer 12D3KooWGqVLhqqyvhLiWW9KfM5vgFbJim1QWrEAQLEsZtLQ1NNf on universal-connectivity-browser-peer-discovery +7s
10:56:33.701 ui:libp2p dialling WebRTC multiaddrs: [...]
10:56:33.741 libp2p:websockets:connection:outbound:... error could not create new outbound stream on connection to /ip4/147.28.186.157/tcp/9095/tls/sni/... for protocols /webrtc-signaling/0.0.1 - UnsupportedProtocolError: protocol selection failed
```
Full attached console log shows this error consistently when attempting **Local App → Local App** WebRTC connections.
[console_output.txt](https://github.com/user-attachments/files/22545913/console_output.txt)
---
**Steps to reproduce:**
1. Clone the repo at commit `0254d9602a89492ae61bffa9ae3e41bb7ff7a493`.
2. Run `yarn install`.
3. Run `yarn dev`.
4. Open two browser windows (or different devices) pointing to the local app.
5. Attempt to establish a WebRTC connection between them.
**Expected result:**
Direct browser-to-browser WebRTC connection established.
**Actual result:**
Fails with `UnsupportedProtocolError: protocol selection failed`.
---
**Additional notes:**
This issue does **not** occur in the deployed app. This suggests there may be differences in how signaling is handled locally vs. in production — I don't know what it could be as I am using the same relay as the deployed version. different instances/peers are able discover & talk to each other etc.. Just the webrtc connections don't work..
[console_output.txt](https://github.com/user-attachments/files/22545913/console_output.txt)
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce commit 0254d9602a89492ae61bffa9ae3e41bb7ff7a493 with yarn install and yarn dev, using two browser windows as described. Start with the attached console log and the /webrtc-signaling/0.0.1 negotiation path; done means local or self-deployed browser peers establish direct WebRTC connections without UnsupportedProtocolError.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100