There is a need for a truly private and decentralized p2p ChatProtocol. One that:
- does not rely on centralized services
- does not rely on benevolent server operators
- does not require existing secure channels to communicate
- does not leak metadata around the social graph and user activity.
- does have forward secrecy and post compromise security guarantees.
- can efficiently handle the growing interest in group chats.
Status Quo
There is general consensus that Status-Backend is in need of some work in order to be a foundation to build upon into the future.
For many of the same reasons, the chat protocol used by Status is also in need of some improvements to make it a stable platform to build upon.
Specifically its needed to have:
-
Long-lived Installation Keys
Device injection attacks pose one of the greatest risks to users, as they allow an attacker to register a device that receives legitimate copies of all messages. Without a longterm key it’s not possible for users to differentiate between SignedPrekey rotation and registration of a new installation. Long-lived installation keys are required to allow users to audit their installations and remain safe while communicating.
-
Identity Rotation and Revocation
Status functions on a deterministic Trust-on-First Use(ToFU) identity model. These
ChatKeysare derived deterministically from the wallet key. One artifact of this process is that users have no recourse in the event of a compromise. Without the ability to rotate their identity, and attacker could masquerade as the compromised user forever. To plan for the future a messaging protocol needs solutions which allow users to rotate their identity and recover their accounts. -
Improved Protocol Guarantees
As specified the current protocol does not provide certainties to developers and users. For example, It provides Forward secrecy in most cases but not all; It provides Sender Authenticity in some cases but not all. The lack of categorical certainties means developers cannot be clear about what the protocol offers. More importantly every conditional on a protocol property is a potential “footgun” for developers and implementors. It’s important that a secure and private communication protocol, is always secure and private so that developers can trust they are using it correctly.
It is also desirable to have
-
Self describing types + resilience
A weakness of decentralized protocols is they are difficult to update when compared to centralized alternatives. The result of protocol ossification is features and upgrades get harder and harder to deploy. Investing in versioned, self describing types from the beginning optimizes for protocol innovation as it ages.
-
Standardized Encryption paths
The current protocol uses many different encryption techniques and formats, which were built upon as the protocol grew and developed. The end result is a protocol which is difficult to verify its correctness. The success of Signal can traced back to its focus on extreme readability, which enabled external reviews and contributions by to community. Reducing complexity and optimizing protocols/implementations is a pre-requisite for building a wide and diverse community.
-
General cleanup of cryptographic primitives
What originally was the optimal decision when a project started, isn’t necessarily the best decision today. Taking a moment to review and upgrade cryptography to best practices, helps improve the longevity and future security of the protocol. Domain separation, KDF Usage in the protocol could both use an update.
Ref: Status-Go Review
Ref: Status Component Summary
If the implementation needs work, and the protocol needs work; then there is little which is remaining the same. Given there are breaking changes either way - investing in a Protocol + Implementation that promotes future growth and maintainability has high ROI.
Existing Solutions
Many messaging protocols already exist; each focusing on a distinct set of features. Building upon an existing protocol would be the preferred path. At this time however, the prominent existing solutions do not align with the needs outlined. Below is a survey of the existing protocols and why they are not a good fit.
WhatsApp/Signal/Telegram
These chat protocols are tightly coupled to the applications which use them, and rely on centralized infrastructure to function.
Modifications to these protocols are possible, but adapting to a decentralized context is difficult.
- Centralized servers implies a centralized authority, which puts networks at risk of censorship.
- Centralized features/services do not translate well to decentralized environments, resulting in poor performance if ported. Implementations like Serverside fanout in WhatsApp
- The privacy models of these protocols require users to trust server operators to protect social graph information.
One area of specific concern is excessive message mitigation. Solutions like RLN require specific usage patterns to be effective.
While future solutions will borrow from these existing protocols, they need to be uniquely optimized for the decentralized environment to be successful.
XMTP
The Extensible Messaging transport protocol is a decentralized web3 native messaging protocol which focuses on creating an interoperable network with no application lock-in for users. The protocol is based on MLS, and is quite attractive from a technical perspective.
Unfortunately their near term privacy focus is not in line with Logos. Privacy based solutions like Unlinkable Identity Associations are not on the roadmap, as they focus on usability and network growth first. Centralized solutions to Spam Mitigation(verification needed true as of 2023) also are a cause for concern.
In general deferring privacy and decentralization features, represents an operational risk to adopters as it’s unclear how these features will integrate into the future. “Eventual Privacy” pushes some of the hardest problems until later in to protocol development lifecycle. As protocols age and calcify the solution space becomes more limited, which puts limitations on outcomes. Protocols reflect their development priorities and Privacy focused protocols, need privacy now.
Matrix Protocol Family
Matrix the platform is a federated platform, built upon a series of communication protocols namely Olm + MegaOlm.
Federated protocols are an improvement over requiring centralized services, however they too have draw backs.
- Known server locations make it easier to censor the network.
- Fragmentation and inconsistent features make it difficult for users onboard.
- Network operators/Server admins have too much power, and add an extra required trust relationship.
Their work on de-MLS has been phenomenal for the decentralized messaging community, however even with MLS their future still relies on federated home-servers. This does not enable success given the focus on trustless censorship resistant communication.
SimpleX
SimpleX is a protocol is private chat protocol which focuses on having zero user assigned identifiers. The lack of user identifiers is advantageous in some use-cases, but can be a hindrance in a more general purpose messenger. Specifically when it comes to sender authentication. Without identifiers there are less protections about who you are actually communicating with, and the possibility of key binding attacks or impersonation are higher.
For online only communities it cannot be assumed there is an established channel with participants which they can verify their identities - which is required by SimpleX
From a technical perspective they build group chats on top of pairwise channels which does not scale efficiently.
While a complete lack of identifiers is a desirable in some circumstances, their implementation isn’t a great fit for a general group focused messaging use case.
Something New
With the current solution lacking foundations for future growth and current solutions not satisfying the requirements; options are limited.
To have a messaging platform which is inline with the IFT’s principals and aligned on future goals, the best path is to build a version of the protocol which aligns with current and future needs.
To succeed, we need to put a powerful SDK in developers’ hands—one that’s clean, privacy-first, groupchat-ready, and built to thrive in censorship-resistant environments.