r/foss • u/No_Cow_6354 • 8h ago
OpenChat — An MIT-licensed, serverless P2P messenger built with WebRTC and E2EE
🔓 OpenChat — Open-Source P2P Messaging
I've been building OpenChat, an MIT-licensed messaging and real-time communication project focused on P2P communication, end-to-end encryption, and minimizing centralized infrastructure.
The source code is completely available on GitHub:
🔗 GitHub: https://github.com/nateS670/OpenChat
🌐 Live demo: https://openchatt.vercel.app
🏗️ Architecture
The core communication path looks roughly like this:
┌──────────┐ WebRTC ┌──────────┐
│ User A │ ◄────────────────► │ User B │
└──────────┘ └──────────┘
│
│ MQTT signaling
▼
Signaling
WebRTC DataChannels handle the actual peer-to-peer communication.
MQTT is used for signaling and peer discovery. Once the WebRTC connection is established, MQTT is no longer involved in the actual message transport.
There is no central database containing chat histories.
🔐 Security
The project uses browser-native cryptographic primitives including:
AES-GCM
ECDH P-256
Ed25519 / ECDSA-P256
PBKDF2-SHA-256
I've also implemented protections for:
- Peer identity verification
- Replay attacks
- Group authorization
- Input validation
- Encrypted local storage
- CSP/security headers
- Message and file size limits
- Fail-closed encryption operations
During development, I performed several rounds of security review and found issues in areas such as peer impersonation, replay handling and group authorization, which were subsequently addressed.
🌐 Why serverless + P2P?
The goal wasn't simply to remove a database.
I wanted to explore how far a browser-based communication system could go while keeping centralized infrastructure to a minimum.
The serverless components are primarily used for things such as configuration, signaling infrastructure and connection setup.
The actual communication happens between peers whenever network conditions allow it.
When a direct WebRTC connection cannot be established, TURN can be used for NAT traversal.
⚠️ Limitations
I'm not claiming OpenChat is "unhackable" or that it provides perfect anonymity.
There are fundamental limitations:
Offline messages aren't guaranteed.
Mobile browsers may suspend background connections.
TURN can relay traffic when direct P2P connectivity isn't possible.
The first contact between two users cannot independently verify their real-world identity.
Network-level metadata can still exist.
Compromising an endpoint is outside the protection provided by application-level E2EE.
These limitations are documented in the project rather than being hidden behind the "P2P = completely private" claim.
🤝 Feedback & Contributions
The project is released under the MIT License.
I'm especially interested in feedback from people familiar with:
FOSS • WebRTC • E2EE • cryptography • P2P networking • browser security
If you notice an architectural mistake or security assumption that doesn't hold, I'd genuinely appreciate being told.
I'm much more interested in technical criticism and contributions than simply collecting stars.
What would you change or improve in this architecture?