This is the detailed talk track of the presentation, "The Martian Curiosity" available for modification and sharing withing the Urbit Meetup Presentations Figma file from the Urbit Foundation: https://www.figma.com/community/file/1050511912000858585
Intended Audience: Technical users who would be interested in an overview of the Urbit stack and to whom the pain points of the modern networked computing experience is familiar. Prior to giving this presentation it is recommended you become somewhat familiar with some of the documentation included below as it will help to smoothly tell the story herein.
Welcome. This presentation is on the topic of modern computing, particularly for more technical users. We will cover:
- Brief history of computing and why it is broken
- How this history undermines your ability to truly own your digital footprint
- Urbit; what it is, what it does, and its component parts
- Discussion / Q&A If you have any questions, give a shout!
While modern web applications and connected devices may seem to be smooth and shiny, they hide a variety of scars and a storied past. To understand your computer today, and the broader networked computing experience, it is important to understand where it came from.
The first generation of 'computers' were room or building-sized contraptions, often designed to be utilized by many different users. The high cost and specialization of these computers meant that maximizing utilization of the capital investment was critical. Time or compute power would be rented out and the computer itself was structured to be accessed by various users in the same physical location.
As technology advanced; computer chips got smaller and less expensive, more people got experience with using computers, and use cases expanded, the era of the personal computer arose. These computers were low cost enough that they would be used by an individual or perhaps a family unit. They built on the backbone of existing operating systems designed for mainframes (largely speaking, Unix) but added capabilites onto that technology stack.
As personal computers exploded in popularity, so too did a desire to communicate and share information between computers. This was the original vision for the internet--researchers and individuals sharing files and data between computers in a peer-to-peer manner. Again, this technology built on top of an existing (and ever growing) tech stack. Unfortunately, this tech stack was not one that was designed for managing security, trust, reputation, or identities, so as the internet continued to get more populated, a variety of pain points arose. We could call this era of the internet, Web1.0.
From identity management and security issues, to just plain spam or bandwidth issues, the peer-to-peer nature of the early internet was not important to the average user, and more importantly, did not offer a viable user experience. Because of this, the internet has evolved--not technologically, but rather, operationally--from a peer-to-peer interaction, into a client (i.e. a Viewer of information) to server (i.e. a Host of information) interaction. When you visit a website today, the computer on the other end does not recieve information that you own and share in order to understand who you are or interact with you, but rather it knows and owns data about you that it uses to decide how it will interact with you. It is a one-way interaction about which you have a diminishing amount of control. We can call this era of the internet, Web2.0; it is the prevalent experience today.
- Patchwork solutions - Modern computers are basically building on the backs of pre-internet structures, where computers were not designed to speak with one another, the modern networked computing stack is essentially held together with duct tape and bubblegum.
- Millions of lines of code - These patchwork solutions lead to an ever growing codebase. Linux, the open source operating system that runs most of the internet, has a kernel of over 25 Million lines of code and comments. With this, being able to robustly understand and intuit solutions to novel challenges is impossible.
- Massive system administration overhead - This endless patchwork of code means that to run a networked computer, host data, or create a product or service, you need to have an army of developers, system adminstrators, product managers, and middle managers.
- Security vulnerabilities - It also introduces a wildly large surface area for hackers to exploit. For example, this is one of the many reasons why people tell you to never put your seed phrase on a computer, or to get a hardware wallet. There are so many ways that a thief could get into your computer that the safest place for your bitcoin is not on your computer.
- Proprietary software - This massive overhead also is causal in why so much software is proprietary or provided along a 'SaaS' model. In order to fund that development, companies need to be created and drive revenue.
- Spam & malicious actors - Because modern computers were hacked into being involved in a network, there is also no great way to manage for spam and malicious actors. In computer science, the concept is called a sybil attack; essentially that because there is no (or effectively zero) cost of a digital identity on the internet, spammers (or trolls) will find it worthwhile to flood the network with attacks (or nearly valueless data) if they can gain even the slightest of benefits, whether those benefits are financial (i.e. successfully scamming 1 in 10000 poor saps that think they are the prince of nigeria) or comical, because in the event that their current identity is blocked, there is no blocker to just generating a new one.
You are a line in a database that belongs to a great faceless corporation which is dedicated to selling you things you don’t need, to impress people you don’t even like. Oh, and they censor you, spy on you for government entities, and utilize your data to manipulate societal behaviors.
So why do people use them? They make things bearable by dealing with the technical debt in exchange for our data.
This is fine, in a world where you are happy to trust centralized services and what they do with your data. If that's you, go ahead and put your money into USD and let the centralized decision makers at the federal reserve protect the value of your savings. For the rest of us who are concerned, whether it is censoring of journalists, deplatforming of politicians, losing your private keys to hackers, or any other number of vulnerabilities to centralized control, decentralization and sovereign ownership can't stop with our money--it must extend to our computing.
Urbit's Operating System, also called Arvo, contains all the pieces necessary for a modern computing experience; a low level computer langauge called Nock, a high level functional language called Hoon, and a variety of modules designed to provide services to your urbit. More details on this in a moment.
Every urbit has a unique, memorable, and human pronounceable identity, known as a @p (pat-pee). These are finite in quantity and are cryptographically owned by Ethereum addresses as an ERC-721 token, or NFT. There are a few tiers of identities that are responsible or capable of different types of interactions on the network. From rarest to most common:
- Galaxies: there are 256 galaxies in the network, they serve as network infrastructure nodes, helping route traffic. They also are the voting members of the Urbit Galactic senate, responsible for governance of the network. These can be recognized by their single syllable name, such as
~zodor~wex - Stars: there are 256^2 stars on the network (~65k) which also serve as network infrastructure nodes, as well as often serving as service providers (i.e. providing access to a bitcoin full node for the bitcoin wallet application). These can be recognized by their two syllable name, such as
~marzodor~datwet - Planets: There are 256^4 planets on the network. These are intended for use by the average individual; unique, valuable to their owners for accrued reputation and capital investment cost, thus naturally limiting the risk of spam or low-effort malicious actors on the network. These can be recognized by their four syllable name, such as
~rovnys-ricferor~sitful-hatred. - Moons: Each planet has the power to issue and control 246^4 moons. These identites are subservient and permanently linked to the planet which issues them, and are intended to serve as things such as connected devices, or access controlled identities (such as for minor children)
- Comets: last, and most definitely least, are Comets. Comets are free, 'disposible' identities which are useful for: trying out urbit before buying a planet, bots, remaining anonymous, or testing software. They come with some technical restraints, but more importantly than that, the features that make them easy to aquire and disposible, also make them less trusted identities when interacting on the network. For example, a planet owner could relatively easily choose to block all incoming data from a comet; or a star could chose not to connect a comet to any peers.
The last key element of Urbit is that it is an end-to-end encrypted, peer-to-peer network. What that means this that messages you send to a different uribt identity, cannot be read or modified by anyone along the way. Stars and Galaxies do assist in the peer-discovery process; I.e. if your ship doesn't know the ip address of the @p you are trying to reach, they will help you find that information; just like a DNS provider such as Cloudflare; but once your ship learns the location (ip address) of that other ship, your messages go directly to that IP address; they don't get routed through some central server at Facebook or Telegram or Apple.
Urbit was designed from the ground up to replace the broken networked computing tech stack; but bootstrapping such a project to include building customized hardware was beyond the scope of the endeavor--instead, you urbit computer runs as a virtual machine ontop of a more traditional operating system and the uses Vere as the interpreter between Urbit and Unix. The only other thing that it keeps from the traditional networked computing stack is TCP/IP. Other than that, Urbit comes with a new low-level computer assembly language, a typed high level language, and a protocol versioning system, 'Kelvin' where new iterations count down towards zero, at which point no more changes will be implemented. This allows for building towards a solid foundation, rather than an ever incleasingly patchworked stack of ever changing code and protocols. While current urbit ships are all running as virtual machines, in the future nock is capable of running directly on silicone -- it is a project just waiting for someone to take it on!
Nock - Urbit's low level assembly language, Turing complete and operates as a pure function. Can be defined on a tshirt or single sheet of paper. Hoon - Urbit's typed high level programming language, compiles itself to Nock and is used to program the Urbit Kernel.
Vanes are microservices that perform the core functions of your urbit. Ames - Networking protocol Behn - Timer Clay - Version controlled file system Dill - Terminal driver Eyre - Webserver Gall - Userspace Agents Iris - HTTP Client Jael - Networking key infrastructure
Technically, userspace is made up of the following:
%graph-store - A graph database heavily used by the 'Groups' app and available for utilization by gall agents, structured towards use by social media applications.
Grid - Previously 'landscape', serves as the 'home' of the urbit userspace. It is from this that ship pilots will launch apps, download software, and interact with system settings.
Gall - Also known as Gall Agents, these are are application modules on your urbit. As explained by ~timluc-miptev:
Gall's capabilities go well beyond what you normally think of as "standalone applications." Because of Urbit's design, Gall apps/modules can cleanly interact with other apps/modules on the local ship or remote ones. They also can call the operating system in ways that are much more manageable than you may be used to in Unix programming (if you have that background).
Threads - Transient state IO framework capable of complex IO operations. Compared to Gall agents, threads are relatively simple to manage when dealing with high amounts of inputs / outputs; but they sacrafice permenance and upgradability.
Software Distribution - Urbit's userspace is fast growing, with userspace hitting a key milestone in Q4 2021--3rd party software distribution. The current software distribution model enables seamless peer-to-peer distribution of software via the sharing of a %desk between ships.
From rarest to most common:
- Galaxies: there are 2^8 galaxies in the network, they serve as network infrastructure nodes, helping route traffic. They also are the voting members of the Urbit Galactic senate, responsible for governance of the network. These can be recognized by their single syllable name, such as
~zodor~wex - Stars: there are 2^16 stars on the network (~65k) which also serve as network infrastructure nodes, as well as often serving as service providers (i.e. providing access to a bitcoin full node for the bitcoin wallet application). These can be recognized by their two syllable name, such as
~tocwexor~datwet. Each start can spawn 2^16 planets. - Planets: There are 2^32 planets on the network (~4.3B). These are intended for use by the average individual; unique, valuable to their owners for accrued reputation and capital investment cost, thus naturally limiting the risk of spam or low-effort malicious actors on the network. These can be recognized by their four syllable name, such as
~sarlev-sarsenor~sitful-hatred. - Moons: Each planet has the power to issue and control 2^32 moons. These identites are subservient and permanently linked to the planet which issues them, and are intended to serve as things such as connected devices, or access controlled identities (such as for minor children)
- Comets: last, and most definitely least, are Comets. Comets are free, 'disposible' identities which are useful for trying out urbit before buying a planet, bots, remaining anonymous, or testing software. They come with some technical restraints, but more importantly than that, the features that make them easy to aquire and disposible, also make them less trusted identities when interacting on the network. For example, a planet owner could relatively easily choose to block all incoming data from a comet; or a star could chose not to connect a comet to any peers.
When the internet was first created, scarce identities weren't built into the networking protocol, but ratehr were just a function of the fact that a limited number of users even had access to the internet (largely government and academic institutions). As internet access became more widespread, the near infinite number of identities (IP addresses, largely) and near zero cost of spinning up new identities makes spam and sybil attacks a huge issue and drives users towards the current networking model of centralized services which function to block the worst of the spam. By having a finite number of long lasting identities which are low enough cost for anyone to acquire once (think, 10-20 dollars at the low end), but costly enough that spinning up thousands to spam isn't profitable the Urbit Identity layer tackles a huge centralizing force of the modern networked computing experience, and cuts it out at the root.
In order to attest to the ownership of a given ship, Urbit's identity layer, Azimuth, serves as the public key infrastructure for the network. Currently Azimuth is implemented both on your ship and in Solidity on the Ethereum blockchain (including an L2 Rollup implemented in Hoon). What this does is enable the holder of the private keys to an ethereum address to demostrate ownership of a given Urbit Identity (aka Azimuth Point) as represented by an ERC-721 NFT. It is important to note that while Ethereum presented an opportunity for bootstrapping a decentralized PKI, Azimuth will not always be on Ethereum, with the ultimate goal being to host the Urbit PKI on the Urbit Network itself. Implementing the L2 contract in Hoon is the first step to that goal.
The other element relating to the Ethereum network is the Wrapped Star project, $WSTR, which is an ERC-20 token that enables fractionalized ownership of Urbit Stars. While you can learn more at star.market, the long and short of it is that the Star level identities have grown in value and as granting stars to contributors is a primary method used to fund development by companies which own large amounts of higher-level address space, being able to give out fractional amounts of high-level address space is of immense utility. It is also such that ownership of a complete star is often out of reach for many people who have interest in the project. The $WSTR project gives the chance to smaller players to see a part of the upside, dollar cost average into star ownership, or otherwise trade in stardom.
We touched on Ames above, as it is part of the Arvo kernel, but to dive a little deeper, Ames is a protocol for end-to-end encrypted communications between urbit ships, along with the relay and acknowledgement of packets. Typically these are sent to a specific UDP port, but it would be possible to use a different network. When one ship sends a packet to another ship, that packet is encrypted using 256 bit AES symmetric key encryption, and signed using ECDSA. Public / private keypairs are generated using Curve25519 and exchanged via the Diffe Hellman key exchange method using the Azimuth state as a reference for the public key of known ships. The ship then attempts to send a packet directly to the target recipient ship. If the physical location (IP address and port) of the intended recipient ship is unknown, the packet will be sent to the originating ships higher level sponsor (star or Galaxy), which keeps track of the locations of all it's sponsees, and the sponsors of ships not under it's domain, and will route it in the appropriate direction. As this packet is encrypted with the recipient ship's public key, none of the routing nodes can decrypt the contents and when the packet makes it to the final recipeint, the recipient decrypts the message and sends an acknowledgement directly to the originating ship which includes it's physical location, such that future interactions are directly peer-to-peer.
The Urbit network is decentralized, but also hierarchical in its network architecture. The different types of identities which we covered earlier, aside from being able to spawn lower level identities, also provide key functions to the network. While this part of Urbit is expected to grow and evolve, there are currently a few things that occur to keep the network running smoothly.
As we explained Ames, if a ship does not know the location (IP Address) of a ship with which it wishes to communicate it's packet will be routed through higher level nodes. The current mechanism for routing and peer discovery is handled by Galaxies, although as the network scales, that duty will be pushed down to Star operators. It is expected that start operators will begin to charge nominal fees for this service, and that stars which do a poor job of routing packets and assisting in peer discovery will lose sponsees to better operators.
In addition to routing and peer discovery, Sponsorships are the mechanism by which a ship recieves Over-The-Air updates, or OTAs, which keep the kernel updated automagically. Typcially speaking, a ship is sponsored by the identity which spawn it. Currently all sponsors will ship the same OTAs, so the most important part of sponsorship is that your sponsor is actually running and remains online to deliver OTAs. In the future, sponsors may adjust or customize OTAs for thier customers.
While there are currently not a wide array of services being provided on the network, it is expected (and starting to be the case), that trusted nodes will provide services to other urbit ships. These may include things like %btc-provider which is the function of allowing other ships to access a Bitcoin Full Node (aka a full copy of the blockchain), or running a hosting service so that less technical pilots don't have to administer their own ships.
Taking questions to the extent that you can is always a useful mechanism. If you don't feel comfortable with that, facilitating a discussion of potential uses for a personal server can also be a great way for meetup participants to grok what urbit means for the world of networked computing.