armrecords, armrecords@lemmy.ca

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.

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.