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/

“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.