Urbit is a new decentralized global computing infrastructure. Urbit is three layers: a continent (Azimuth), a computer (Arvo), and a civilization (Casbah).
To oversimplify: Casbah is a decentralized social network between Arvo servers with Azimuth addresses.
What is the actual status of these things?
TPM (Trusted Platform Module) is as useful for preventing real attackers as the TSA is at preventing real terrorists. The architecture is fundamentally flawed and most existing implementations are completely broken. I thought this argument was settled decades ago[1] when "trusted computing" was introduced mostly as a way to provide DRM and ownership capabilities to organizations. It has largely failed to impact the consumer market when it was introduced back in the early 2000s. However, recently there seems to be a movement by certain parties to reintroduce this failed product back to the market. Microsoft argues that in order to use Windows 11, you need TPM 2.0 compatible hardware because[2]:
The Trusted Platform Module(TPM) requirement ena
The target audience is people who are familiar with Urbit's architecture, though not necessarily much of its code.
As some of you already know, i recently left my job as a core dev for the Urbit Foundation to work on a similar system called Plunder. Plunder was created in 2020 by two former Tlon employees, after their proposal for a new version of Nock was rejected. They have since reworked that significantly and built a reference implementation of their own system. You can follow its continued development on its mailing list.
I've known about Plunder for quite some time now, but their recently released demo -- in which the system is used to serve a 70 GB dataset, complete with metadata and searchable -- made me feel the need to explore it again and in greater detail. Doing this with my personal server doesn't feel like a big ask, but there is currentl
| !. | |
| => ~ => | |
| |% | |
| ++ add | |
| |= [a=@ b=@] | |
| ^- @ | |
| ?: =(0 a) b | |
| $(a (dec a), b +(b)) | |
| :: | |
| ++ sub |
"Stepwisdom" and "step nomadism" are two competing philosophies of how to sequence code upgrades, and they have a very long history in Urbit.
Stepwisdom is the idea that the system should guarantee that every
update to a piece of code is run stepwise, in order. That is, you only
ever upgrade from version n to n+1. This is very nice for
developers -- instead of considering n different possible upgrade
scenarios, you can consider only one. This sounds so nice that we've
always planned to do it, though somehow we've never quite got there.
The screenshots were taken on different sessions.
The entire sessions are included on the screenshots.
I lost the original prompts, so I had to reconstruct them, and still managed to reproduce.
The "compressed" version is actually longer! Emojis and abbreviations use more tokens than common words.
An Urbit runtime with near-machine execution speed and NAS-equivalent addressable storage enables most classes of personal applications to be built directly on Urbit.
Currently standard library functions which implement highly-iterated loops, such as turn, are jetted to remove arm invocation overhead arising from indirect jumps, dynamic jet matching, and allocation for parameters. The majority of overhead in hot codepaths (such as Ames) is in arm invocations themselves, not in the code for arms.
This is a proposal for a "lure service".
While this can serve as the foundation for countless features, the primary goal is to solve the "boot into an empty landscape" problem. In other words, it's trying to close the loop of "one person uses Urbit" -> "they invite another to their group on Urbit" -> "they get on Urbit and immediately know what to do with it" -> "they invite another".
Thus, we will first consider the case of inviting someone into an Urbit group who may not already use Urbit.
Invites should be regular links. These work on any device, can be transmitted over any transport (including publicly in a tweet or physically via qr code), and are very low-friction to click. When you click this link, you should expect to receive an invite to that group.
To make this happen, we must somehow establish an association between the person who clicked the link and their @p. We should make this work for as many cases as possible -- especially, it should work even if they don't yet have a @p.
Mill, or mill.hoon, is the execution engine for Uqbar. At a high level, it takes the current state of a town (a "shard" of our rollup) along with a set of transactions (referred to in code as eggs) and creates a state transition which can be applied to that town. Here, I will document the specifics of this process and explore implementation choices available to us.
It's important to note that our current implementation of the execution engine can be modified in some ways by Sequencers. The result of an individual transaction must be ZK-verified, that is, the sequencer must generate hints to prove the computation was performed correctly, but the overall state transition can be composed of these results in many ways. A Sequencer therefore has the ability to exclude or order transactions in ways they see fit (with the potential, here, for MEV extraction). The implementation choices made outside of the "must-prove" portion of mill.hoon are made for performance, not validity, and can
