yarvin’s Reddit AMA warning: high level of smarmy fascists. I can’t find the post where he claims Urbit is the only networked functional language so it might be elsewhere
the original Urbit spec, lots to sneer at here as yarvin decides Urbit is best described as how neo-feudal martians would write software
@dgerard@awful.systems linked this in the masto thread but it’s too important not to link: one of Yarvin’s later tech specs with less obfuscation, which literally calls the network address space digital feudalism

e: holy shit I revisited that last link

The $2^64 question is thus: who are the dukes?

My answer is simple. The dukes are the developers of Urbit. They created it - they get to own it. This is standard Lockean libertarian homesteading theory. Lend a hand - earn a slice. Thus Urbit, unlike most open-source projects, offers a rational motivation for contribution.

this is the most mask off description of the fake decentralization crypto projects build on (and Urbit might have invented, unless we can dig up prior art) I’ve ever seen

[–] self@awful.systems 3 points 1 year ago

I decided to head the acasualrobotgod off at the pass and torture myself by reading through the early Urbit spec in full (whose content is completely different from the one @gerikson@awful.systems posted), and I found something interesting; the info I gave above about Urbit taking ideas from Nix isn’t quite accurate. the reality is much worse.

so yarvin’s specs are meandering as fuck of course, but eventually they get to some kind of point. in short, Urbit’s main computational function consists of two other functions.

urbit-infer knows how to pull code from the network, cryptographically verify its integrity, and transform (build) it. this is Nix’s fetchurl and half of Nix’s derivation function.
urbit-render takes the output of urbit-infer and stores it in a unique path in Urbit’s pathspace. this is the other half of derivation.
the Urbit pathspace is a set of paths on a storage device with the invariant that every path must uniquely represent an output of urbit-infer, and that the existence of a path guarantees that its contents are the output of urbit-render for that path’s instance of urbit-infer. this is just Nix’s core data structure, the Nix store, copied wholesale into Urbit but with a much stupider uniqueness algorithm

now note that Nix is actually a lot older than I indicated before. it was first released in 2003, and Eelco Dolstra’s first paper on it was published in 2004, 6 years before Yarvin’s first posts about Urbit. that 2004 paper featured details on derivation, fetchurl, and the Nix store, all of which exist almost unchanged in modern Nix

a lot of the differences between Urbit and Nix (like pathspace forks) seem to be attempts to work around implementing the trickier parts of the Nix evaluation model

given the big similarities in functionality and structure between the Urbit computational function and Nix’s core functions and data structure, the wide span of time during which Yarvin could have read the Nix paper (and Dolstra published about Nix several more times between 2004 and 2010), and Nix’s obscurity until around 2015, I’m willing to upgrade my suspicion to an accusation:

Urbit’s core functionality is a shitty, plagiarized version of Nix, but intentionally crippled to keep Yarvin in control

this has got to be my last Urbit deep dive for a while, but I figured it couldn’t hurt to write up some notes here in case Urbit starts marketing hard again