Self-Sovereign Web3 Social: Why We Invested in Comm

Self-Sovereign Web3 Social: Why We Invested in Comm

The problem: There is currently a trade-off between product functionality and data sovereignty in web2 messaging.

There is a fundamental misalignment between web3 values and the communication platforms we use today. The centralised cloud servers underpinning Telegram, Discord, and Twitter open risk avenues not only for centralised companies to monetise our influence, but governments to access our personal data. Cambridge Analytica was a prime example; and most recently, the Indian government allegedly gained access to sensitive user data on Twitter, including DMs.

The problem: There is currently a trade-off between product functionality and data sovereignty in web2 messaging.

It’s clear that we need private, E2E-encrypted chat messengers. Yet despite their closer alignment to web3 values, most web3 communities do not use them — largely due to their limited scalability. To ensure E2E encryption, most messengers use Signal’s Double Ratchet Protocol (or similar). Every (n)th message requires decrypting message (n-1), and sending it to m people in a group chat requires m separate encryptions. As the network grows, the more exponential “work” it takes to encrypt, decrypt, and re-encrypt messages. Hence why E2E-encrypted Whatsapp restricts group chats to 512 people, while LobsterDAO hosts more than 19,000 members in one single group chat on Telegram.

The problem: There is currently a trade-off between product functionality and data sovereignty in web2 messaging.

In essence, current messaging solutions trade off product functionality and data sovereignty. While the web3 community closely aligns with the value of data ownership, the product functionality on Telegram is too comprehensive too ignore. With Telegram, anyone can create a channel with more than 55,000 subscribers, send large files, view previous message history on a group chat, and receive messages on multiple devices at once. E2E-encrypted chat messengers today, by contrast, cannot.

The Solution

Enter the keyserver. As Comm’s secret sauce, keyservers unlock web3 self-sovereignty without sacrificing product functionality. By providing access to plaintext, keyservers scale E2E encryption and enable features previously restricted to cloud-based messengers.

Its MVP features large group chats, access to past message history (before a user joins a group chat), and synchronous message retrieval across both web & mobile. These features, in combination with its threading model, makes Comm the first E2E-encrypted chat messenger to support the Discord & Slack feature set while maintaining data sovereignty.

The problem: There is currently a trade-off between product functionality and data sovereignty in web2 messaging.

When the product fully launches, Comm will be significantly more fitting than Discord to coordinate DAO communication. Its focused notifications and unified inbox reduces the noise users typically face on Discord considerably, and web3 communities will be able to customise their “server” with a collection of community modules fitting their various needs. Potential integrations with DAO tools such as Snapshot, Superfluid, and Lit Protocol will also streamline web3 community operations to enhance DAO efficiency.

The problem: There is currently a trade-off between product functionality and data sovereignty in web2 messaging.

The Transition

While Comm’s frontend will attract both community managers and users alike, the transition to a future where every single user hosts a keyserver — each with their own private key — is a long-run journey. While the keyservers of the future may be easily purchased as a small personal device, the easiest place to install a keyserver today is on a spare laptop at home. When compared with a 3-minute Discord account setup, it would be a telling difference.

Thus, in its initial phase, Comm will abstract friction away from onboarding end-users by making it optional for them to host their own keyservers. Instead, Web3 communities that value self-sovereignty and efficient coordination will host keyservers for their members. This way, Comm can set up a sufficiently decentralised network of keyservers without compromising user growth.

In stark contrast to Big Tech, Comm will never have access to the keyservers’ hosted data even at this transitory stage.

To support Comm at this initial stage of adoption, our team at LongHash Ventures will facilitate integrations with the relevant DAO tools in our portfolio, before bridging our relationships with some of the largest DAOs in Web3.


We invested in Comm because the keyserver pioneers the marriage between web3 self-sovereignty and web2 product functionality. While the shift from cloud to keyserver will be a challenging one, we invested due to our following thesis:

As an ever-increasing amount of big data is collected by centralised conglomerates, users will opt for decentralised solutions such as keyservers to protect their privacy and self-sovereignty.

We are confident that Comm’s founder, Ashoat, is the right leader to execute this vision. Throughout our interactions with him, he has showcased deep thought and knowledge on the history of E2E-encrypted messaging and strong drive to learn from past projects’ challenges. His past experience as one of Facebook’s early engineers (since he was 20!) provides valuable insight into centralised data ownership, and we believe that his unique combination of entrepreneurial acumen, technical expertise, and vision can deliver a worthy decentralised alternative.

We look forward to collaborating with him to usher in the era of self-sovereign Web3 social. While E2E-encrypted messaging on “Web3 Discord” serves as a first use case for Comm’s keyservers, it merely scratches the surface of the pivotal role they could play in the protection of our personal data. From IoT devices to the metaverse, Big Tech will own an exponentially-growing amount of personal data. The keyserver, at its maturity, may be our best chance to opt out.

Leave a Reply