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.

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.

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/

A few ideas that could further strengthen the design:

• Consider deriving separate keys from a master secret using HKDF (e.g. encryption key, authentication key, attachment key) instead of relying on a single key for everything.
• Room IDs alone could leak metadata if discovered. An HMAC-based room authentication scheme could help without requiring the server to know any encryption keys.
• Adding replay protection with counters/nonces and periodic key rotation would make the protocol more resilient.
• For public deployments, some abuse protection (rate limiting, room creation limits, optional proof-of-work) would help prevent DoS attacks.

“Privacyslop” actually fits pretty well. You see more and more services throwing around words like “private” and “encrypted” without explaining anything.

I think most F-Droid drawing apps are aimed at quick sketches rather than full digital art workflows.

The choice of cryptographic primitives in Securebit was made based on a balance between maturity, availability, and implementation simplicity at the time of the current architecture design. The goal was not to introduce experimental or fragile constructions, but to rely on well-studied, widely deployed primitives that are available across standard cryptographic libraries and can be audited and replaced as the protocol evolves. The system is intentionally designed to be modular. Cryptographic components are not treated as fixed marketing claims, but as replaceable building blocks. This is important because in real-world systems, cryptography evolves, and protocol agility is more valuable than locking into specific primitives. If there are concrete proposals for improving the cryptographic layer - including modern primitives, protocol adjustments, or security model refinements - contributions are welcome. The project is open to review and discussion via the GitHub repository.

Thank you all for your interest in SecureBitChat and for taking the time to check out the project! We recently completed a full redesign of the application and are actively working on the next major update. Some of the features currently in development include:

• Audio and video calling
• Mesh groups with multiple simultaneous peer-to-peer connections
• Faster connection establishment
• The ability to create and manage entities for quickly reconnecting with trusted contacts and sessions

Your feedback and questions are incredibly valuable and help shape the direction of the project.

Thanks again for the support, and stay tuned-there’s much more to come!

Great question.

WebRTC still relies on STUN and, when direct connectivity isn’t possible, TURN for ICE.

SecureBitChat currently supports ^Direct Mode^, where users exchange the SDP manually (copy/paste, QR code, file, etc.). Once exchanged, the peers establish a direct WebRTC connection.

Right now, users can configure their own STUN and TURN servers directly in the settings, use public servers, or any infrastructure they trust. An optional assisted connection mode is currently in development.