In his dotpoast of ~2024.8.29 [1], Curtis Yarvin proposed a model for an Urbit application layer that temporarily decouples Azimuth-based logins from full decentralization on a fleet of Arvo ships. Such full or partial centralization allows apps to be polished with an anticipated later full decentralization to a mature Arvo release.
Yarvin's initial post laid out these possible apps by security factor:
-
“Red-dot tiles are wallet apps which can can send your money to Burkina Faso where you can never get it back. You know. Crypto stuff. Be careful!
-
“Gray-dot tiles are public feeds which show you public Web2 or Web3 data.
-
“Green-dot tiles are captive Urbit apps. Captive apps look and work just like decentralized apps and even share code with them, but run on a big central backend. You know, like Facebook.
-
“Blue-dot tiles are private Urbit apps. Private apps run on your personal cloud server. This is your own permanent, purely-functional private sky computer.
-
“Violet-dot tiles are like blue-dot tiles but remind you that you are using confidential computing , where you don't have to trust your hosting service.
-
“Mauve-dot tiles remind you that are using native computing —you brought your own hardware. It's in your closet with the grow-light and the gold safe.”
We add a few comments on the feasibility of this scheme:
-
Red-dot crypto functionality seems like an attribute of some apps, namely those with microtransactions or betting functionality, rather than a fundamental app type.
-
Blue–violet–mauve seem like they are attributes of the server process rather than the app.
-
One could imagine a third-party vetting service, like Consumer Reports, that further provides a gold dot or ring to audited apps.
This argues against a simple one-app-one-dot scheme in favor of a handful of simple, legible attributes, something like this:
-
Red dot = can transact in real money.
-
Green dot = runs as centralized service.
-
Blue–violet–mauve footer bar = degree of decentralized security of platform.
-
Gold dot = audited by third party service of your choosing.
Another possibility is to divide the concept of apps into bundled threads, where a thread is more like a callout to Paypal or another payment processor like we do today. Then the particular strand has the attribute, contributing to the app-as-bundle. Or maybe an app can have a petty cash wallet, like a game that requires or can make some money.
While Urbit is a personal server and is capable of the classic client–server model, most apps to date have preferred to function in a decentralized manner. Exceptions to this pattern include:
%blog%feature- The Urbit Systems Technical Journal Forum
One of the main draws, and programming difficulties, of Urbit is the possibility of fully decentralized, permissionless app creation and distribution. The only privileged participant is the publisher, but others can trivially republish to syndicate the app.
%rumorsand the%pals-verse%trill%hits- Tlon Groups
Much like a dental bridge, CWAs must present the appearance of a decentralized app while affording a high degree of polish like a conventional Web 2.0 centralized app.
__ __ __ __ __ __
( ) ( ) |__|(__)|__| ( )
|| || || || ||
The appeal of CWAs is that they can build a standalone user base on top of a pseudo-Urbit framework that can then be switched over to a fully decentralized Urbit backend at some point in the future.
No CWAs really exist in Urbit today, so ours is the privilege of architecting and introducing them.
How is this world possible? A user owns an Urbit ID/Azimuth, but may not be using an Urbit OS/Arvo instance. The landing page (call it Landscape for convenience even if no relation to the current code base exists) is accessible from a web browser or similar client. That landing page serves as the portal to the apps which the user has installed.
The most satisfying solution, if most fraught with difficulty, is for on-network ships to treat off-network identities as IPFS-style sharded data. The state can be gossiped as necessary, preserving the reality of a decentralized network with the appearance of a centralized service portal. (This is rather like the old Sun Ray thin clients.) Because this is a complicated maneuver, we do not recommend starting here, but keeping it in mind for Butyl 2.0 (“N-Butyl”).
The straightforward solution, then, is to offer the user a portal based at sampel-palnet.urbit.network or similar that actually doesn't touch Arvo at all, but affords an interface into a Web 2.0/web3 world that is the aspirational Urbit decentralized world. The apps should be constructed with care such that transition to full decentralization will eventually be viable without major changes in the user experience. Call this Butyl 1.0 or “Isobutyl”. (Butyl 1.5, then, is to merge the Arvo-based Landscape experience with the centralized CWA experience.)
At the outset, Isobutyl does not touch Urbit OS at all. Only a classic web app platform needs to be built, and several Urbit apps need to be ported as demos. Ultimately, the highest value will be shown by creating best-in-class wallets, feed tools like 𝕏/Farcaster/RSS, blockchain full nodes, an IPFS node, and similar sorts of Web 2.0/web3 tools.
To promote the Urbit model, these tools should have corresponding backends available at each step: an Ethereum full node and light client, a Farcaster API reader, &c. Each should be sketched out in Gall and/or Neo, and used to motivate further userspace development in the medium term. We tend to know where the difficulties will lie: Ames responsiveness, Gall subscription issues, &c. WebRTC-style Urbit-brokered connections as in the old Campfire video chat app offers one approach to handling these.
Partial decentralization would be quite challenging, and would involve gossiped and possibly sharded state. This is theoretically interesting and may be desirable, but represents a serious engineering commitment.
We also need a product plan. There have been a lot of great ideas implemented in some form on Urbit in the past few years: spaced repetition, torrenting,
The demo pattern should aim at
At the alpha stage:
- Simple chat app (like
%hut/%squad), perhaps with shinier UI %bookscrypto accounting%boardimageboard%duikertorrent site, with new torrent downloader
At the beta stage:
%turf- Tlon
%groups - Bitcoin+Lightning/Ethereum full nodes
At the release stage, all significant Urbit apps should be viable in both form factors. We should also not be afraid to steal ideas, like Uqbar's and m-tron's.