 The internet was going to be decentralized, a free and open cyberspace where people connected to people, everyone having their own digital home in their living rooms, collecting their own bits, sharing them with friends. And from the perspective of the average end user, that might as well be how things ended up. Is this better? Maybe? Sure. I can talk louder if you need me to. So from the perspective of the average end user, that might as well be how things ended up, but technically that was only very briefly the case. Centralization was just too quick and easy. Service providers quickly realized that if they just had one beefy server, they could cut down on complexity while saving a bunch of costs and gaining more control while they were at it. And this resulted in an internet that's not really connected anymore. You're not in touch with your friends, you're in touch with Facebook. Decentralization is good and powerful and people are starting to catch on. We see a few talks about it here at FOSDAM and the rise of projects like Scuttlebot and Matrix, the protocols, platforms like Mastodon and Ethereum, they're all very promising. Once we have a properly decentralized internet, it brings a lot of benefits that we're currently struggling to acquire. When people host their own data, there are no hosting costs. They have full control over the distribution of the data themselves and don't have to trust in a third party for this. And what's more, when there's no central authority, communities are free to make the rules themselves. Not just who to invite to your chat group but network-wide reputation and trust system across all network computing. Decentralization is often cheaper to provide too. As I said, you have no hosting costs since the users take care of that themselves. So all you really have to worry about is development. But the development is still pretty hard. Decentralization doesn't feel like a very standard thing to do and even the parts of it that are very common today often don't feel as such. For example, when I hook up a Linux box to the network, it isn't automatically safe from attackers. I have to do all kinds of manual configuration to make sure that it is. Make sure traffic gets encrypted, protect against cross-site scripting, sanitize and validate input safely and somehow store it securely too. And all of these things don't work out of the box even though they're practically required. Once your node is up, you still have to worry about networking inside of your application too. There's a lot of room there for different implementations and maybe a little bit too much. There just isn't a quick and easy way to say send a message and have any guarantees about it. In application logic too, you'll likely be writing lots of boilerplate code. We see this is especially true for messaging. We have all these different messaging apps and they're all basically doing the same thing. Isn't messaging a pretty generic problem? And why can I message my friends on WhatsApp using Signal? Like it's just a text message. Come on. And when these different implementations aren't interoperable, which is also the case for most decentralized services, since you're still connecting to a service instead of your friend, then it becomes really hard for these services to build up their networks. They have no network effect of their own. They have to build it from scratch. And there aren't just technical challenges for adoption. There are user-side ones too. Can you imagine asking your grandmother to spin up an AWS instance just so she can chat with you? And even if we can somehow get that usable enough and easy for all users across the world, you still have to get them to use your software over existing centralized solutions. And that's pretty hard. People want to keep messaging their friends even if they're not switching over with them. And it still feels weird to not be able to take your data with you. You often have to leave your connections, content, and messages behind. And that just feels wrong. So not only do you have to DIY your network effect, you have to fight against existing ones. And there are still unsolved problems in centralized systems too. Twitter has been infested with bots, and for everyone they ban, five new accounts get created. An account isn't really equivalent to online identity, and that leaves them a play area for malicious parties where they have free reign. Considering decentralization only really starts to shine when you have a peer-to-peer network to speak of, these are pretty big showstoppers. Urban helps make decentralization easier. It is not a framework, not a library. It is a general-purpose computer built from a brand new software stack from scratch. Most importantly, it's small and actually fairly simple. Let's take a look at that stack to see how it pulls it off. At Urban Score, there is one very simple function. This function says that your current state and any input event combine into new state and one or more outgoing events, or zero, I suppose. This function gets run for you in the Urban Virtual Machine. We have an implementation of our own in C, and someone from the community is making an implementation in Java. This Virtual Machine is responsible for hooking Urban up with all the functionality of the host operating system, and it interprets knock. Knock is Urban's functional assembly language. Everything on it compiles down to knock. Knock is really small. Its spec actually fits on a t-shirt. It only defines 11 operators, half which are macros, and you can program in it, some mad men have, but generally you want to be using hoon instead. Hoon is Urban's native programming language. It is functional, excuse me. Hoon is a vaguely list-like subject-oriented language, which means that your scope is a first-class value. You can reach into your parent scope and change values there if you want. And because Urban is statically typed and purely functional, this is safe and predictable. Hoon takes a hit to apparent upfront complexity in order to avoid hidden complexities down the line. You won't be hitting any strange gotchas or edge cases once you become familiar with the fairly simple semantics of the language. Everything that is built on Urban is written in Hoon, and that includes its operating system, Arvo. Arvo is an event-driven operating system that implements eight kernel modules, which realize all the functionality you might expect from a modern OS. A file system, build system, application sandbox, HTTP server, and of course a networking module. All of this it realizes in just under 30,000 lines of code. The last time Unix was this small, it was the late 70s. Using just that small stack, Urban can accomplish a pretty impressive amount of things, and it does them in ways that allows developers to take advantage of them without even having to try. Let's see what some of that functionality is. At the core of Urban's networking, you'll find an identity system. Unlike IP addresses, which are hard to remember, and often temporary assigned to machines, Urban addresses are easy to remember and permanently cryptographically owned by people. Like IP addresses, they are limited in supply and come in blocks. Owning such a block means owning its super node, and when you own the super node of a block, you are responsible for peer discovery and software updates for all of its children. Those children, if they're not satisfied with the server, with the service that node provides, are free to migrate to a different parent node. Likewise, the parent node can deny its children's service if they see that the child is behaving maliciously on the network. So you have an incentive to keep your reputation at least neutral because after all, identities are scarce, and so they have value. If you start spamming, that spammer better make you back the value of your identity before it gets an old manner of blacklist. By paving over IP with ID, we can already see a more human-centric approach to networking emerge. Ultimately, it's all still UDP traffic, but the module takes care of everything you don't want to worry about. Encryption, making sure the message gets where it needs to and gets delivered exactly once. And interfacing with that module is largely abstracted away for you, too. Applications only have to worry about implementing a handful of functions for handling incoming events and producing new states and new events from there. Once all that drunk work has been taken care of for you, it becomes really quick and easy to develop decentralized applications that live and breathe networking. Urban Chips with a generic messaging bus that specifies a limited but not limiting number of message types for you to use. And it also gives applications an easy way to interface with this. So when you want to realize a chat application on top of this, it's almost like building just a UI. And providing a generic messaging bus like this avoids lock-in. All your messages will be readable by all applications that use it. So if you don't like the UI you're currently using, just switch. It no longer means losing all your data. Urban will also provide standardized ways to build graphical interfaces for your applications. With this, we can have more easily a consistent look, feel, and experience across your digital workflow. After all, what is your digital home if not aesthetically coherent? We also believe it's possible to merge the command line and graphical interface into one new hole that both satisfies veteran terminal users and allows point and click users to discover the power of the keyboard in an organic way. With all of that, it's really easy to build and distribute decentralized applications. You can even update them live over the air, just like the rest of the OS. You get it for free, it's part of the system. But what about the parts that aren't part of the system? What about that networking effect? Urban can essentially bootstrap its own network effect by making use of existing services. Something we haven't mentioned yet is Urban's excellent API integration tools. It provides an easy hook for adding authentication to any outgoing HTTP request and a powerful way of converting between response request bodies and native data types. With this, it becomes almost trivial to hook up any existing service to your orbit. And this frees orbit applications from the confines of the orbit network. A strong initial use case for this is API aggregation, where you can give users an initial one single interface for all their social media gowns. This can then take local copies to give users back some control and then eventually transition into a model where you wouldn't even have to know if you're chatting with a user on orbit or on Facebook. Orbit is already live and would love to have you. We have arguably the friendliest online community, but we have great minds who are crazy enough to think they can make the future a better place. And we'd love to hear from you. What do you want to make? Thank you. Thank you very much.