armrecords

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.

Hi everyone! I'm the developer of SecureBitChat. Thank you for checking out the project and for all the feedback so far. If you have any questions about the architecture, cryptography, WebRTC implementation, design decisions, or the project's roadmap, feel free to ask them here. I'll do my best to answer openly and explain the reasoning behind the implementation. I'm also very interested in hearing criticism, suggestions, and real-world experiences-especially regarding privacy, decentralized communication, and WebRTC reliability. Constructive feedback helps make the project better.