The Future of Userspace
Urbit's decades-long journey includes a wide swath of interesting computer science problems. We've worked across domains like distributed systems, programming language design, and systems engineering. These problems are interesting to many, but for most they are background concerns. Only relevant, or noticed, when something doesn’t work.
But the wider world is beginning to notice that legacy systems have 'solved' these problems with duct tape and bubble gum.
Why is DHH building a docker container manager, called 'ONCE'? Because people are sick of the subscription model and not being able–or even allowed–to run their own software.
Why is Perplexity building their ‘Personal Computer’ offering? Because they can’t escape the fact that their ‘cloud-based’ Perplexity Computer product puts all your most personal information directly into their hands. And that people don’t actually want that.
Openclaw users are buying Mac Minis so they can have 'their own always-on agents', Nvidia is releasing open source security solutions, like ‘Nemoclaw’, to try to solve for the mess of allowing probabilistic computing agents into your operating system, and just about everyone is realizing is that their data is being scraped, stored, and exploited to a seemingly endless degree. The list goes on.
And all of these issues, while they have their social and cultural elements, have their underpinnings in the technical realities of our networked computing stack. They stem from the fact that the computers you use to store, share, and process your data aren’t really yours. As we are wont to say, "Urbit fixes this."
So why is everyone still using earth computers? Why aren’t they using Urbit yet, even if we hypothesized these issues decades ago?
Naturally, the world hasn’t stood still. Many pieces of the legacy software stack have improved. Linux servers will run for years on end without going down. Docker containers and orchestration brought a landscape of repeatable environments and scaling to bear on consumers and enterprises alike. But with this, the ball of mud grows larger, the centralization and spam problems getting worse by the day.
And of course, so too does Urbit's core development march onwards:
- Network continuity has been maintained since 2020
- Directed messaging is the first production scale implementation of Named Data Networking and is slated for release in Arvo 408k
- Runtime performance has improved on both resource usage and reliability
- And the loom size has approximated doubled every year for the last 5 years and is about to expand into the TBs with vere64
This work is foundational. And people are slowly starting to notice they want a computer that is truly theirs. A personal server that operates on their behalf. But, we haven't been good at one thing in particular. Something that Linus Torvalds has taken tremendously seriously in the Linux kernel. To quote:
Certainly there are reasons (or perhaps excuses) for why this hasn't been the case in the Urbit ecosystem–for why userspace, and Gall applications inside it, regularly experience breaking changes:
- “The system needed to be pressure tested before knowing what userspace should look like.”
- “The implementation effort to offer backwards compatibility to a small 3rd party developer community wasn't worth it.”
- “The Gall vane itself doesn't have breaking changes, rather it exposes userspace code to the standard library and kernel APIs directly, meaning breaking changes anywhere in the standard library and kernel are breaking changes to userspace.”
- “Other things were just more important.”
But it is time for these excuses to fall by the wayside. It is time for Urbit's userspace to mature.
Gall 2026 is the project where we break userspace one last time, in order to never break userspace again. It is a cross-organizational undertaking, with contributors from Tlon Corporation, The Urbit Foundation, Groundwire, and Native Planet working to bring into reality a userspace implementation that will help Urbit realize its purpose of a networked personal computer that can last, and which truly belongs to its users.
To put out a clear description of our goals for Urbit userspace in 2026, we are going to:
- Make userspace security real
- Make Gall amenable to alternate agent models/APIs
- Make Gall amenable to keeping agents running across kelvin updates
These three goals will make it so that users can trust userspace applications to be properly sandboxed for safe installation of 3rd-party applications, developers have a pathway for expanding userspace into different application models, and everyone can install and run software which is compatible with previous versions of Arvo.
Making userspace security real
Your computer can't be yours if at every turn the software you run can threaten to steal your secrets, change your kernel code, or modify data in unauthorized locations on your computer. That's not your computer, that's a hacker's computer that you pay for and run.
In 2022/2023, we designed a userspace permissions model to support the newly released 3rd-party software distribution capabilities. While there was a working implementation of 90% of the permissions, there was a glaring hole: HTTP security. Given the way your urbit’s Eyre vane serves interfaces into your browser, any application can re-use your cookie to make any request of any other application. We decided against releasing an explicit userspace permissions system to the network without resolving that security flaw, as giving people false security would be more dangerous than the current "make sure you trust the developers before installing their software" model. We now have a pathway to patching that hole.
In practice, the implementation of Eyre security will look like using the existing robust security affordances of the browser by scoping separate apps to dedicated subdomains, e.g. pals.palfun-foslup.arvo.network. Eyre will automatically handle an authentication redirect flow to provide properly scoped cookies to the browser, and the security properties of userspace permissions will be enforced throughout the stack.
What does this mean for users? For the most part, the experience will stay the same and they’ll just be able to trust their urbit that much more. Have a hosting provider running your ship, or using a service like Startram from Native Planet? You should just be able to continue along without a second thought. Ships running in a VPS with an arvo.network domain, or via automation tools like Groundseg, should also ‘just work’ as well. For those running more bespoke setups, such as bringing their own domain, there will be a little bit of configuration work to keep in step but nothing out of your depth if you are already running a bespoke arrangement.
Of course, in some future world Urbit will ditch the browser, but for now our path forward will include the browser for many years to come. This also means we inherit one limitation: “urbit-on-a-local-network-using-direct-ip-address-and-mdns” can’t take advantage of scoped authentication as they only use port numbers–no subdomains–and so they will not be able to take advantage of the new security offerings. Of course we won’t leave those users totally in the lurch; to maintain functionality, users running in this type of environment will be offered a setting to bypass Eyre authentication permissions, effectively maintaining the (insecure) status quo.
What then, if we have a secure userspace, might we want to do with it? What kind of applications would we run?
Supporting alternative agent designs
Current Gall has a very specific API: An agent core with ten arms that manage state, send and respond to requests, handle reads, and manage crashes. But this isn't the only way that people want to develop. Work in 2024/2025 around "Shrubbery" has evidenced that there is demand for and potential benefit to different models of userspace.
The rub is that Gall can’t offer that because it has a specific idea of what an agent or an application is. The only thing it sort of knows how to do—and even that is difficult—is change that model. Because totally throwing out the existing model would result in all software currently built on Urbit needing to be massively re-written, the solution is to make a change that supports making future changes.
Currently, an urbit’s userspace agents interact with the kernel directly. This means that the entire rest of the kernel needs to know what to expect from an agent. And that an agent must adhere to that expectation. To support alternative agent designs, we are changing the model from this mode of direct kernel interaction to one where agents interact with Gall’s API and then based on that interaction, Gall may interact with the kernel on the agent’s behalf.
This management of expectations between agents and the kernel also will enable us to deliver on one of the most important expectations of Urbit writ large: Write once, run forever apps.
Write once, run forever
To date, developers have needed to upgrade their applications alongside every kernel update. In practice, many of these upgrades are trivial. But so too are they antithetical to Urbit’s ethos. You shouldn’t need the software developer to do busywork–or to even put out an update at all–for the software you are running on your computer to just keep working the way it always has in the past.
To this end, the third goal of our userspace undertaking is to make Gall amenable to ‘kelvin shimming’, or the idea that your urbit should be able to run ‘old’ software even if it is on a newer version of the Arvo kernel. It is important to note two things in this goal, though:
- A technical solution cannot solve social problems
- The focus is on proof of concept
What does technical-not-social mean? Well, Urbit is a distributed system, and in such a system we can’t guarantee that everyone else won’t upgrade their system, leaving you in a network of one. For applications like your personal diary or other single-player use cases that you want to run unchanged for decades, the social solution is simple: “it's mine. It doesn’t need to change unless I tell it to.”
But with multiplayer software, the case of “it's ours,” is a little bit more complex. Be it community software governance, version negotiation protocols, or other unforeseen solutions, we aim to give it a strong technical foundation from the kernel level. But to be clear: our kelvin shimming solution only aims to give you guarantees about your own ship. Who knows what the rest of the network gets up to.
And with regard to being a proof-of-concept, the core effort is to conclusively prove that it is possible. We may not release an implementation of this immediately, but the important thing will be that we will know an implementation is possible without breaking userspace again.
The Trajectory of Userspace
As the world becomes flooded with ever more software, caking on more mud and complexity to the already unstable and incomprehensible layers beneath it, people’s eyes will continue to be opened to the fragile foundations of the legacy stack. Whether it is supply chain attacks, ever-accelerating maintenance obligations for vibecoded slop PRs, or just the classic painpoint of ever expanding subscription obligations, the pains of making, distributing, and running software will continue pointing at the root of the problem. That the networked computing stack needs to be rewritten from the ground up, made simple enough that dependency hell and breaking changes are a thing of the past, and that you can have a computer you can truly trust to be yours.
So for us to be able to continue saying, “Urbit fixes this,” we are going to deliver these solutions this year. Proof of concepts have been written, regular implementation work continues, and we are on target for our roadmap of Q4 2026 testing and release.
