Why Isn't Telegram Decentralized?
Three Things #135: September 8, 2024
I did my best to disconnect and take a step back during Burning Man, but one thing in particular kept coming to mind: the recent arrest of the Telegram founder and CEO, Pavel Durov. I don’t have a strong opinion about the specifics of the case, and Durov and Telegram are controversial for a number of reasons, but I do feel strongly that his arrest sets a terrible precedent and in many ways perfectly demonstrates much of what’s wrong with software today.
Thing #1: What’s Wrong 🤦♂️
While the details are complicated, it seems that Durov was arrested in France for, among other things, negligence and complicity in crimes committed on the platform, for refusing to cooperate with the French government in handing over user data, etc. This is worrying for a number of reasons. While Durov is a French citizen, Telegram is not a French company and as far as I know it has no direct corporate relationship with France or with the EU at all. It’s not immediately obvious why France feels that it has jurisdiction over Telegram: how it treats user data, which data it reveals and how it chooses to respond to government requests or not, which users it censors or deplatforms, etc. And it’s crazy that France decided the right approach was to arrest the CEO and hold him personally responsible for the actions of users of the platform.
But it’s deeper than that. The world needs software over which no government has jurisdiction or executive authority. That was the vision of the cypherpunks and it’s precisely what Bitcoin and Ethereum made possible (one OG version of the Ethereum vision is unstoppable applications). As John Perry Barlow famously wrote in the seminal Declaration of the Independence of Cyberspace,
Governments of the Industrial World, you weary giants of flesh and steel, I come from Cyberspace, the new home of Mind. On behalf of the future, I ask you of the past to leave us alone. You are not welcome among us. You have no sovereignty where we gather.
In other words, governments and bureaucracies have de facto indirect jurisdiction over much of cyberspace not because specific, novel laws have been passed to ensure that this is so, but for precisely the opposite reason: for decades we’ve forced old laws to adapt to new technologies that they weren’t originally designed for.
As Barlow hinted at so presciently, the Internet itself doesn’t inherently belong to this or that physical jurisdiction. The Internet is natively global and borderless. So why isn’t software, the applications and services that we rely on today for so much of commerce and our daily lives, also borderless and global?
There are a few answers. For one thing, governments, bureaucracies, and alphabet soup agencies are notorious for taking an extraordinarily expansive interpretation of their jurisdiction and remit. Unless we explicitly prevent them from doing so, by default they’ll claim jurisdiction over as much of cyberspace as they plausibly and practically can.
For another, that there are several weakest links: most obviously, companies and the people that run them. The physical servers that run those applications are also an issue: they must necessarily be located in this or that jurisdiction, so that they can never be totally immune from the executive authority of the host country. (This was the dream of seasteading, but that failed to take off for a number of reasons.)
Bitcoin and Ethereum did eventually overcome this problem. No single jurisdiction could take either of those networks down today, and I doubt that even several nation states collaborating could stop Bitcoin today. It’s achieved escape velocity. It’s certainly theoretically possible to run something like Telegram using Bitcoin or Ethereum. And it’s possible to govern even complex protocols using a DAO, a governance structure that doesn’t necessarily have any legal locus or person of record.
So why are we still facing the same problems today, more than a decade into this cypherpunk journey? Why are we still relying on centralized applications run by companies with known executives and employees that run centralized client-server architecture? Especially when governments, from France to Nigeria, can arbitrarily and unilaterally decide to detain those executives or seize those servers. In other words, why isn’t Telegram decentralized? This is literally the trillion dollar question of the entire blockchain and cryptocurrency industry—and it has ramifications far beyond the industry.
Thing #2: Where We Are Today 📍
While in theory it’s possible to build something like Telegram on Ethereum or even Bitcoin, in practice there are several obstacles. The most obvious ones are cost and performance. In the strictest possible sense, if you wanted to build Telegram on Ethereum and make it maximally censorship resistant, every individual message would need to be a transaction. Ethereum would serve as the messaging layer itself, user identities could map to Ethereum accounts/keypairs, and messages could be end-to-end encrypted so that only the intended recipient could read them. Such an application would gain all of the powerful features of Ethereum including censorship resistance and permissionlessness. The design of such an application is actually rather straightforward.
However, if you understand anything about Ethereum, you understand why this is totally impractical. For one thing, it would take seconds or, in times of congestion, minutes to successfully send a message. Ethereum is only capable of processing around a million transactions per day. If all of the hundreds of millions of active users of Telegram were using Ethereum to send messages, each person would effectively get to send only one or two messages per year! And it would get expensive quickly. Sending a single message would at minimum cost a few cents, and could cost significantly more in times of contention and congestion.
Layer two chains or more performant networks like Solana might improve things somewhat, lowering costs and increasing capacity by two or three orders of magnitude, but it’s still not enough for a data-intensive application like Telegram. Blockchain has come a long day since the days of Bitcoin and single, expensive transactions per second, but we’re still quite far from being able to support even one truly massive, global-scale application that runs on chain—to say nothing of supporting many such applications.
In short, achieving global consensus on every single message is out of the question. It’s simply too slow and too expensive to be practical, and in any case it isn’t necessary. Unlike the money use case, the entire network doesn’t need to agree on the fact that Alice sent Bob a message, or that they exchanged messages in a group. The only way such an application would work is if consensus were “holographic” or hierarchical. You need more than two nodes to ensure censorship resistance, but you don’t need thousands.
The opposite of Bitcoin or Ethereum and their global consensus is Urbit, which in a sense is a decentralized Telegram: each user is an identity associated with a keypair, all messages are encrypted, and there is no global consensus. The only parties to a chat, or to the data exchanged by any application, are the parties actually involved.
One of the big downsides to Urbit is that it requires every user to run a server process, known as a “ship.” The UX is therefore fairly complicated. It is possible for a hosting provider to manage this for a user, and to make onboarding pretty quick and cheap (the hosting provider spins up the server on the user’s behalf), but this sort of defeats the idea of self-sovereignty over one’s data, and it’s not very censorship resistant. In other words, the government could just come after the small number of known hosting operators, rather than the (nonexistent) centralized network operator. There are still single points of failure: known people running servers in physical data centers.
The only other viable, existing model is the federated model, adopted by sufficiently decentralized networks including Farcaster, Nostr, Mastodon, and Matrix. This is not unlike Urbit with hosting providers, and it still doesn’t solve the problems of Telegram.
This is basically the state of decentralized software today, and it’s deeply frustrating and unsatisfying.
Thing #3: What’s Still Missing 🕵️♀️
There are two ways to approach the question of what’s missing.
The first starts with infrastructure. I already hinted at some things that are missing or could be improved. It would be nice to have a blockchain with transactions that are orders of magnitude cheaper, and one that could process orders of magnitude more transactions than any blockchain today is capable of.
As a thought experiment, consider the fact that Telegram charges $5 per month for their premium service. Assume that the average Telegram user sends around 100 messages per day, or around 3,000 messages per month. Throw in other sorts of transactions, such as those involving apps, updating one’s status, or changing settings, and let’s imagine that a user should be able to generate 5,000-10,000 transactions for the same $5, which works out to about a tenth of a cent per transaction. That should be our goal. It’s theoretically possible with certain types of layer two chains, rollups, and compression. Transactions on high throughput chains including Solana are sometimes this cheap, sometimes more during times of contention. There may eventually be a large enough supply of high-quality, decentralized, censorship-resistant block space that prices are consistently this low, but we’re not yet there today on any reliable, production blockchain network.
It would also be nice to have a blockchain where running a node is super easy, say, in a browser or on a mobile phone. It would have to not consume many resources and synchronize almost instantly. We’re nowhere near being capable of this today. In fact, this is something that lots of projects have promised as being just around the corner, but no one has actually delivered this yet. Consensus is simply too hard and requires too much bandwidth and compute. The alternative is light clients. Even these aren’t yet viable for most chains, which means you have to trust a third party data provider.
I could go on. We could use faster, cheaper ZK proofs for compression and scalability. We could use parallelization of transaction execution. We could reduce the resource requirements for running nodes. There are projects working on all of these things, and I expect that we’ll have all of them eventually, but we don’t have them today.
The other side of the coin, and the other way to approach this question, is from the application side. In my opinion this is the more interesting approach. Most blockchain builders are infrastructure engineers, not application designers, so the vast majority of projects, companies, and ecosystems have taken the first approach, trying to improve the infrastructure. But this is exactly the wrong approach: it’s putting the infrastructure cart before the application horse. The correct way to approach the problem is by starting with the application, then building infrastructure that serves it. I’m not sure I can think of a single blockchain project taking this approach today, other than possibly Bitcoin.
In short, what we’re missing is well designed, usable, useful, decentralized applications with good UX. It’s that simple. You could make the case that it’s not possible to build such applications today on the basis of the infrastructure shortcomings I just mentioned, but I have a high degree of confidence that, if you start with the application and design and build your infrastructure around its use case, you can overcome most or all of these challenges in various clever ways.
But aren’t there many usable DeFi applications today? Yes, there are a handful of games, mostly casino and betting games, and prediction markets. There are a few applications built around things like identity or NFTs. But there are no usable, decentralized applications that do simple, generally useful things like messaging, email, document sharing, calendaring, etc. This actually makes sense. For one thing, the casino games are uniquely enabled by blockchain since they’d be illegal to operate in many jurisdictions, fairness and transparency are crucial, etc. In contrast the types of general purpose applications I’m thinking of aren’t sexy and don’t immediately lend themselves to shitcoins worth billions of dollars, which is probably another big reason they haven’t been built, but these are the applications the world really needs.
The other thing that’s still missing is good monetization strategies for protocols and decentralized applications that don’t involve shitcoins, or that involve healthy, organic, sustainable token economics. This is the other reason these applications aren’t being built: building them is expensive, and there isn’t a clear revenue model or a clear way to return value to investors. Incentives matter enormously, and the incentive today is to build applications based on shitcoins that immediately generate liquidity before product market fit or value is generated. We need some creative financial engineering as well. Another shitcoin probably isn’t the solution, but neither is relying on benevolent billionaires or mercurial public goods funding. No approach that solves for infrastructure without putting the application first, and without contending with these social and economic challenges, stands a chance of succeeding.