Skip to main content

P2P Messaging Technical Breakdown

⚠️ NOTE: This is still a work-in-progress and far from finished. It is free to use and not sold or monetized in any way. It has NOT been audited or reviewed. For testing purposes only, not a replacement for your current messaging app. I have open source examples of various parts of the app and I'm sure more investigation needs to be done for all details of this project. USE RESPONSIBLY!

This documentation provides a technical update and roadmap for the P2P messaging project. It explains how the system works, what's currently implemented, what's in progress, and what's planned for the future. Cybersecurity is a constantly evolving field and no system can be completely secure. This document outlines the features and practices that help make the messaging app as secure as possible.

Demo

Current Status: Implemented Features​

The following features are currently working and implemented:

  • P2P Architecture - The app is fully decentralized and does not rely on a central server for exchanging messages. WebRTC is used to establish direct peer-to-peer connections between browsers.

  • Peer Discovery - Peer IDs are cryptographically random, generated automatically client-side with good conflict resilience to prevent ID guessing attacks. The peerjs-server (open source, self-hostable) is used as a connection broker to establish WebRTC connections.

  • End-to-End Encryption - Messages are protected with an application-level cascading cipher layered on top of WebRTC's built-in encryption. The cascading cipher combines multiple protocols including Signal Protocol, MLS, and AES. While there has been some pushback on the cascading cipher approach, it functions at the application level and ensures that the strongest algorithm provides protection. Any failure results in a cascading failure, providing redundancy on top of WebRTC's mandated encryption. I plan to add more protocols to this cascade to investigate post-quantum solutions.

  • Perfect Forward Secrecy - If a key is compromised, past messages remain protected. WebRTC already provides reasonable forward secrecy support in Firefox, and the Signal and MLS protocols in the cascading cipher contribute additional resilience in this regard.

  • Key Management - Users manage their own keys without relying on a central authority. The focus is on local-only encryption keys. Key sets are generated for each new connection and reused in future sessions.

  • Secure Signaling - The initial connection between peers is established securely. While exchanging connection data offline is a good approach, I'm working on providing more options. It's possible to establish a WebRTC connection without a connection-broker as demonstrated here.

  • Minimal Infrastructure - Fewer points of failure and attack. With WebRTC, messages can be sent without a central server and will work in offline hotspot networks.

  • Multimedia Support - Users can share animations and videos. This is important for providing an appealing user experience. Progress has been made on the UI component library to provide various features and functionality users expect in a messaging app.

  • Minimal Metadata - The app minimizes metadata to prevent tracking of who's messaging whom or when. The metadata footprint is fairly minimal, though this is relative to how feature-rich the application becomes. Features like "user is typing" notifications can be disabled, though they're common in messaging apps. Similarly, read receipts can be useful but come with metadata overhead. I plan to discuss these features more in the future and provide the ability to disable them.

In Progress: Features Under Development​

The following features are currently being worked on:

  • Open Source Strategy - Moving towards a hybrid approach where relevant repositories are open source.

  • Registration-Free Operation - Creating a messaging app that eliminates the need for users to register is a feature desired in the cybersecurity space. The webapp approach offers these capabilities and is working. However, as I explore monetization options, I'm unable to see how registration can be completely avoided.

  • Encrypted Storage - Browser-based cryptography is capable, and it's possible to have important data like encryption keys encrypted at rest. This works well when using passkeys to derive a password. This approach is still incomplete—improvements are needed to take advantage of the Filesystem API for better persistence. Passkeys won't address this easily because they get cleared when you clear site-data (and you lose the password for decrypting the data).

  • User Education - The app is fairly technical, and I need more time to provide better information to users. The current website has a lot of technical details, but I think it's a mess if you want to find specific information. This needs to be improved.

  • Offline Messaging - P2P messaging has limitations, but I have an idea for addressing this: a self-hosted version that remains online and proxies messages to users when they come online. This is still in the early stages of development and has yet to be demonstrated.

  • Self-Destructing Messages - This is a common feature in secure messaging apps. It should be relatively simple to implement and will be added as a feature "soon".

  • JavaScript Security Concerns - There's a lot of rhetoric against using JavaScript for a project like this because of concerns about code being served over the internet. This is understandable, but I think these concerns can be mitigated. I can provide a self-hostable static bundle to avoid fetching statics from the internet. There's additional investigation towards using service workers to cache necessary files for offline use. I would like to add an explicit button to "fetch latest statics". The functionality is working, but more needs to be done before rolling it out.

  • Decentralized Profile - Users will want to continue conversations across devices with multi-device sync. It's possible to implement a P2P solution for this. This is an ongoing investigation.

  • STUN/TURN Server Configuration - The app currently uses metered.ca TURN servers only for brokering P2P connections. You have the option to use your own API key to enable features like "relay-mode", which will proxy all messages. I'm open to making this as configurable as necessary if users want to add multiple of their own servers.

Future Work: Planned Features​

The following features are planned for future development:

  • Regular Security Audits - This is important for identifying and fixing vulnerabilities promptly. Security audits are very expensive, and until there is funding, this won't be possible (Radically open security feedback). The logical alternative is an in-house security audit. I have made attempts to create such audits for the Signal Protocol and MLS. I'm sure I can dive into more details, but ultimately an in-house audit is invalidated by any bias I might impart.

  • Anonymity Features - Enabling users to communicate without revealing their identity is a feature many privacy advocates want. P2P messaging has nuanced tradeoffs. I'd like to further investigate onion-style routing to hide origins, but I also notice that WebRTC is generally discouraged when using the TOR network. It could help if users use a VPN, but that strays further from what I can offer as part of my app. This is an ongoing investigation.

  • Decentralized Architecture - The aim is for a resilient infrastructure. AWS S3 is not expected to fail, but in a multicloud approach, if any cloud provider has issues, the app should already have multiple redundancies in place. This is an ongoing investigation.

  • Formal Proof and Verification - Improve expertise around formal proof and verification to provide transparency and clarity.

Frequently Asked Questions​

Project FAQs (monetization, open source, comparisons, JavaScript delivery, Chat Control, and more) live on the Enkrypted Chat FAQ.

IMPORTANT NOTE: It's worth repeating: this is still a work in progress and not ready to replace any existing solution. Many core features like group messaging are not working. Provided for testing, demo, and feedback purposes only.