An Unlikely Candidate for a Mainstream Darknet
Over the years I've reviewed about half a dozen darknets (I2P, DAT Protocol, my own dissertation project, etc.) that promise to be the future of the Internet and solve many of the problems with today's Web platforms. Having seen numerous ideas for darknets fall by the wayside, I've come to the conclusion that three things are needed for a solution to become widely used: - Built on existing and common technologies. - Highly accessible to those with very little expertise. - Commercial support. A lot of commercial support.
Urbit is one of the more novel ideas I've come across, and I really like it as an abstract concept for a P2P system. It has simplicity in its design, when we look past all the jargon and weird terminology, and, if the addressing system was different (I'll come to that), anyone could theoretically use the software.
It consists of two components: The Urbit ID and the Urbit 'operating system'.
The Urbit 'operating system' is actually a virtual machine that sandboxes the users' online activities. It's referred to as an operating system because it has a single-function kernel that's coded in some obscure language, and has modules for 'a filesystem, build system, application sandbox, secret storage, web server, terminal driver and a networking protocol'. Basically every function underlying what one might do on a P2P network, from hosting sites to remote access on a terminal.
This addresses a number of problems inherent in the way things are done on the Web today. One of them is the lack of separation between our online activities from our physical lives, and the difficulty in maintaining pseudonymity, which lead to all sorts of undesirable consequences. Secondly, the Urbit docs point out that we're constantly switching between platforms that we have little control over, and it's not easy for everyone to explicitly control what they share online or how we interact with online services.
I should add that I believe the future of the Internet is one in which the client-server way of doing things will be largely (but not entirely) obsolete, and our online profiles are stored locally on our devices and most likely synced across them.
But there are a few reasons why I believe Urbit, as it currently is, won't catch on. In a subsequent post, I'll cover a solution that's better than Urbit and DAT, and is the most likely successor to the Web.
Problem 1: Getting the Urbit ID
I've pointed out that a solution must be highly accessible to potential users with almost no technical background. In order to use Urbit OS, one must acquire an Urbit ID.
'Urbit IDs aren’t money, but they are scarce, so each one costs something. This means that when you meet a stranger on the Urbit network, they have some skin in the game and are less likely to be a bot or a spammer.'
Currency is required to get an Urbit ID. Not just any currency, but Ethereum. None of the people I associate with physically or on social media are in the slightest bit interested in cryptocurrency, and I don't know anyone who would spend Ethereum on getting an ID just to access a social media/messaging platform.
This kind of artificial scarcity and cost would rule out Urbit as a mainstream darknet. Why would Urbit's developers cripple the addressing system to deal with an application layer problem, and make it less accessible? Other solutions will freely and readily generate IDs from a virtually limitless address space, and users don't necessarily need to care about them.
Problem 2: Urbit isn't really decentralised
The addressing system is hierarchical and tiered, in a way that potentially reintroduces the same problems we have with today's Web:
'Urbit IDs are distributed by a sponsorship tree. Each sponsor issues a fixed number of addresses. [...] One point that’s useful to understand about sponsors is that while Urbit IDs always need a sponsor, or parent node on the network (primarily for peer discovery), it’s always possible to change sponsors and sponsors can always reject children. This means bad actors can be banned and abusive sponsors can be ignored. We think this strikes a nice balance between accountability and freedom.'
This is a very naive projection, given this is supposed to be the basis of something that could be around for decades. I can think of a couple of ways this could be used and abused to give corporations (or 'MEGACORP', as the Urbit developers refer to them collectively) the means to once again control what gets published. Corporations could buy up addresses and essentially censor individuals the same way they arbitrarily ban user accounts over some criticism of The Establishment, and Urbit equivalents of Twitter mobs might cause higher-level nodes to punish and exclude users without due process. Potential users could be priced out of some or most networks by higher-level nodes. That's the opposite of where we want to be. Longer term, I can't see what would prevent the whole thing being controlled by a monopoly.
Problem 3: Development and Source Code
Programming languages are human-readable abstractions of software, and I've always maintained that source code should be self-explanatory, even to the point of arguing that readability is far more important than testability (one could argue that intelligible unit tests are a form of documentation).
The source code for Urbit OS is authored in a programming language called 'Hoon', and it looks godawful in the sense of being heavily obfuscated! The creation of the language itself is a work of genius, but the way it's been implemented for Urbit isn't good: None of the function names, file names or variables are descriptive, everything in the project is referred to by some code name scheme, and there's no structure in many of the source files. The syntax appears almost impossible to follow, without going through the Hoon documentation/specs, as the operators don't resemble anything seen in most languages.
This poses a number of major problems with trying to make this darknet mainstream. It also raises the question of who could maintain the project in five years, given hardly anyone in the software development trade has encountered the language.
Hoon is a programming language that's functional, not mature or comprehensive enough to allow for coding techniques that are considered best practice, or for reusability and extendibility. This would be important if Urbit OS was to be used for anything critical. The developers would also face the tricky task of adding well-documented APIs for third-party applications to run on the platform.