Hi everyone!
I'm working on a privacy-focused peer-to-peer messenger built on WebRTC, and I'm researching how WebRTC behaves in real-world conditions.
Rather than benchmarks or lab tests, I'm interested in hearing about your actual experience using WebRTC-based applications (Signal, Element, Jitsi, PeerTube, Brave Talk, browser P2P apps, or any others).
Some questions I'd love to hear your thoughts on:
- Have you experienced random disconnects during calls or chats?
- Do connections fail more often on mobile networks, public Wi-Fi, or behind strict firewalls?
- Have you noticed problems when switching between Wi-Fi and cellular data?
- Do you frequently end up using relay servers instead of direct P2P connections?
- Have you encountered NAT or firewall issues that made WebRTC unusable?
- Have you ever had a WebRTC application work perfectly for one person but fail completely for another?
- Are there any recurring issues that you think developers tend to overlook?
If you're a developer, I'd also be interested in hearing about the most difficult networking problems you've encountered while building or maintaining WebRTC applications.
I'm especially interested in reliability under poor or restrictive network conditions, since one of my goals is to improve connection resilience while preserving privacy.
Thanks in advance to everyone willing to share their experiences!
I think overall, WebRTC works reasonably well and is quite reliable. It's technology, though and technology will fail. I had issues in larger videoconferences with people on a super slow and unreliable connections. They'd intermittently drop out, pop back in again etc. And I had issues with people (me) using a Libre version of Firefox and some codecs weren't supported. I also had issues with people having their microphone set to weird sound devices.
Other than that, I generally had a good time with WebRTC. Especially the 1:1 direct peer calls. They're awesome and generally well supported. Peertube etc also work flawlessly here.
I guess 80% of the experience depends on how you implement it. And what code you write to handle edge cases like a poor internet connection. Or people who are bad with computers and can't figure out why their microphone doesn't work.
And if you're looking for a more bleeding edge Web API and data transport channel... I recently learned about WebTransport. It's a W3C draft for the more recent HTTP versions.
Totally agree - WebRTC itself is solid technology, and the 1:1 direct peer connections are genuinely great when they work. Most of the pain really does come down to implementation choices and edge-case handling, exactly as you said.
I'm actually building a messenger (SecureBitСhat) that leans heavily on WebRTC as one of its transport channels, with a fairly aggressive security posture layered on top. The core philosophy is that nothing should depend on a server we control - no message content, no session data, no metadata sits anywhere except on the users' own devices, encrypted, and it's wiped once the session ends. Key exchange happens per-session with ephemeral keys, and we do a real cryptographic SAS (short authentication string) check derived from the actual DTLS fingerprints at connection time, not just a random code - plus full ASN.1 validation on the key structures to make sure nothing malformed slips through.
The reasoning for going fully server-less is less about performance and more about the threat model: any server, even a well-intentioned one, is a point a government or third party can pressure, subpoena, or just block outright. Right now users can already point the app at their own STUN/TURN servers if they want full control over their connection path.
Next on the roadmap is a community-run node network so users can optionally host their own nodes - this should lower the barrier to entry for less technical users and speed up handshake time, especially for reconnecting with peers they've had prior sessions with, without introducing a central point of control.
On the drop-out issue you mentioned - I don't think that's a WebRTC problem per se, it's more a reflection of the underlying network conditions and NAT/routing limitations users are stuck behind. I'm currently researching connection resilience patterns and looking at building a control layer on top that can better handle reconnects and flaky links, rather than treating every drop as a hard failure.
Also good call on WebTransport - I hadn't looked closely at it yet, will dig into the spec, especially if it ends up handling adverse network conditions more gracefully over HTTP/3.
If you're curious, the code (web client + crypto core) is here: https://github.com/SecureBitChat/securebit-chat and the live app is at https://securebit.chat/
Is the project coded by AI? Or humans? Or a combination thereof?
The project is entirely coded by me. I do not use AI to write the application's logic or architecture. I use an AI tool only to help generate documentation, comments, and function descriptions during development. All implementation, design decisions, and source code are written by me.
Sounds alright. Yeah, I'm asking because we have some wave of new accounts popping up in the Fediverse, promoting some entirely vibe-coded "privacy" or "selfhosting" stuff. And those aren't worth bothering because those regularly don't run.
I completely understand, and I actually agree with your point. I've been developing this project for about a year in my spare time outside of work. My goal isn't to build "just another messenger," but to give people a way to communicate without depending on infrastructure imposed by large companies, relying instead on trusted, peer-to-peer methods of communication.
And yes, I think we're seeing a lot of people who believe that if they have an idea and feed a prompt into an AI, the rest will somehow happen automatically. In reality, that's far from how software engineering works. Building something secure and reliable still requires a lot of research, design, testing, and iteration.
My product isn't perfect yet, but I'm constantly learning and adopting technologies that can make it more secure, more reliable, and more accessible.
And thank you for taking the time to share your experience with WebRTC and the issues you've encountered. Feedback from people who have actually worked with the technology is genuinely valuable to me.