I still have not been able to figure out if there's actually something that amazing about Urbit, or if behind the obfuscated terminology there's nothing, and I am reluctant to commit to the time required to find out for myself. It doesn't help that people who spend time in that land seem to all forget how to speak about it except in the terms of Urbit, unable to translate it for laypeople. I suppose that's true about any highly technical subject though.
[0]: https://en.wikipedia.org/wiki/Mimsy_Were_the_Borogoves
[1]: https://books.google.com/books?id=yPVbDv5DqkoC&lpg=PA181&dq=...
Urbit is a platform for building decentralized apps. To that end, it's a tightly integrated set of different features that play into that: an identity system so that all the apps can refer to the same people by the same handle, a typed RPC network for easy message sending, and an append-only log of all events that platform handles being the most important parts.
Right now you can build decentralized apps like Mastodon, except they 1) take hours to setup a node, along with having to know arcane Linuz sysadmining 2) aren't actually decentralized, but federated. Urbit wants to make it easy to setup your own server, which runs as a node for all these decentralized apps (instant messaging, Twitter, etc.), along with be useful for server-y things like aggregate APIs (email, Facebook).
There's not actually anything that amazing about Urbit once you figure it out. It just wants everyone to be able to run their own server, and make it easy to build decentralized apps that talk to other Urbit servers. The important part is that somehow, they saw how bad trying to do that currently is, said "let's rewrite everything", /and then did/. It's like reading about Oberon or Plan9/Inferno.
Edit: This post is probably the worst introduction to Urbit imaginable. It basically is a technical spec for bootstrapping a PKI over Ethereum, and you should expect about as much as if you got linked something from BitTorrent about that. It assumes domain knowledge from both Urbit and Ethereum (both of which are terrible to explain), and /doesn't actually matter/ for most people interested in Urbit. Please don't use this as the benchmark for "babies first urbit intro".
With decentralised systems you are forced to run all computation and store all data yourself. The average user isn't going to buy their own server and run it 24/7. That's incredibly wasteful. Even in the best case scenario they will just get an "urbit server" from AWS or somewhere else.
The problem with centralised services isn't that they are centralised. The problem is that you are locked-in to a specific provider. You can't send messages to your facebook friends from your freedom respecting gnu social server or whatever. You have to install a dozen apps (facebook, whatsapp, telegram, etc) to talk with all your friends.
Having a common platform, all using the same RPC and identity and network layer, allows for the removal of lock-in across different Urbit apps.
And since it's your own server, you /can/ send to Facebook friends from your Urbit clone just by hitting the API endpoints. Migrating to an Urbit clone of a centralized service should be gradual to fight back against network effects: first make a UI frontend for the service from Urbit, then make it mirror content on Urbit back, and gradually transition over. GNU Social does this with Twitter, but kinda badly, and can be locked out from one central API token because everyone has to go though their node.
But of course, that's not all it is.
It's also a ground-up reinvention of mainstream functional programming languages like Lisp, built on the foundation of an abstract virtual machine in which the "decrement" operation can be performed natively only by incrementing a number until it's 1 less than the current number. All of these concepts have their own weird names; for instance, the constant-time version of "decrement" (this is a programming environment that goes out of its way to achieve constant-time decrement†) is an example of a "jet", where a jet is apparently a non-native implementation of an algorithm that can be expressed but not efficiently on the VM that they've chosen to build their entire system on and it just gets weirder and weirder from there.
You don't have to memorize the new names they've come up with for most of the ASCII punctuation characters, like "gal", "gar", and "hax" for "<", ">", and "#", "but it helps". A normal engineer's reaction to a system that tells it that it will help to remember a new name for the pound sign is to ask "Why? What fresh horror lurks in the deeper meaning of your new name for the percent sign? And why won't you tell me before I commit to this system?"
Stuff like that would be bad enough, but the founders ideological views are also infused into the system, and those views are not mainstream distributed systems engineering views. For instance: the most available first-class address in the system is in a 32 bit address space. Why? Not for efficiency, but because the authors believe there aren't and never will be 4 billion human beings on the planet worthy of having a first-class address in their system. This, by the way, is their actual response to the objection of an overlay network with 32 bit addressing.
I agree that the best way to explain this system while encouraging people to engage with it is to distill it down to anodyne concepts and then sprinkle "decentralization" on top. But of course, this system isn't really that. From the proteins of its cell membranes to the DNA in its nucleus, this is a system that coercively projects the idiosyncrasies of its founders into everything it comes in contact with. It's decentralized and free in the sort of way its founders would explain with a 3000 word paper that invented 50 new terms in its abstract.
People confused about Urbit are probably not confused about the value of serverless computing or of overlay networks. Those are pretty straightforward concepts we can all get our heads around. There is something deeper that is challenging about Urbit.
† Rather than, you know, just deciding to have it.
As for ideological views: there are 4 million planets. They are, essentially, houses, but each one of those planets can also issue 2^16 "moons", which can themselves be their own people. I don't know the reasoning behind why 2^32, but I'm also not going to ascribe the reasoning to human worth any more than I would the author of IPv4. There are also 2^64 comets, which are their own ships outside the trust heirarchy, which really just means that they have a default karma of 0 because they have no cost, and so can be Sybil attacked - not that they can never get a positive karma, or that you couldn't use one indefinitely instead of a planet (just that it's be unwieldy). Saying Urbit can't scale bigger than IPv4 is kinda like worry that Hoon can't be programmed in Chinese - there are probably bigger problems, and it could be solved by just doubling the amount of galaxies. Hell, Urbit is open source. There would be push back against doing it, but there is nothing stopping that from being patched in tomorrow.
The most common thing I've see n called fascist in Urbit is it's identity system, and this Urbit+Ethereum spec seems to be a direct solution to some of it. Now, even buying a star you don't have to trust the owner of the galaxy you bought it from, because it's a redeemable token.
One of the things they want is for identities to cost some nontrivial amount of money, about $10 or so. This mostly solves the spam problem because it's unlikely that spamming will get you $10 worth of value before you're blacklisted by your parent star and it refuses to route your packets.
Can you think of an identity count that would preserve moderate scarcity like this? Or would you have the address space be indefinitely mineable, kind of like bitcoin?
Odd, I saw the rationale early on, when I was just reading the documentation for Urbit. If you've ever seen Hoon code, you'll notice it has a lot of punctuation in it. Have a look at tumblr.hoon[0]. If you want to speak with fellow Hoon programmers in person and communicate fluidly, it's nice to have a compact, standardized-within-Urbit way of saying things like "$%"[1] out loud.
Now, at this point you're probably wondering "why would they have names that are all punctuation?". As far as I can tell, this keeps the identifiers short and of uniform length. From what I understand, one of the problems that they're trying to solve is that single-assignment code in, say, Lisp tends to flow down and to the right. They're trying to limit rightward visual creep, as I understand it.
Now, I'm not convinced that focusing on standard-library-identifier length is a good idea. Early C linkers could only handle function names that were six characters or shorter, and constraints like the ones in Hoon's standard library sound similarly arbitrary and likely to lead to unintuitive names like "strchr".
[0]: https://github.com/urbit/examples/blob/master/app/tumblr.hoo...
[1]: buccen, which I pronounce as "buck sen". It's used for making tagged unions, which reminds me of Erlang/Elixir {:ok, Value}/{:error, Reason} value-passing style.
Speaking of that.. I looked again at the reference documentation and the "hello world" (Fizzbuzz). It feels like I'm playing a game of Magic the Gathering on another world, with different physics and vocalizations I cannot do.
https://urbit.org/docs/hoon/reference/
{$book p/(list {{aura @} moss})}: mold which recognizes a union tagged by head atom.
{$lamb p/moss q/moss}: mold which normalizes to an example gate.
{$port p/moss q/seed}: form an iron gate.
{$gill p/moss q/seed}: form a gill, a wet one-armed core with sample.
{$gasp p/seed q/seed}: form a gate with burnt sample.
And their demo (Fizzbuzz) is just as illegible. https://urbit.org/docs/hoon/demo/ . I get programming. I know there's concepts in different langs that need understood. But one thing I know is that the demo should be easy to dip your toes in.
And it starts. "Tape" is really a string. "Home Desk" -Im guessing its the urbit home directory for your user? Urbit Pier? No bloody clue. But Im supposed to copy the file (oh wait, is file even used, or maybe its joobpflep?) to it. But at least the "Urbit Dojo" is the shell.
haven't "actually succeeded", haven't "shown any real movement towards", but "wants to".
And that's the problem. Years ago it was funny: "look at our ludicrous documentation isn't it funny that we claim this is a real thing", now it's just more assholes boiling the seas.
This sounds vaguely intriguing. But the problem that most Ethereum projects have is that they put the solution and technology before the problem. Half the time I don't even know what I'm looking at or if it's worth looking further.
Can you restate the problem that Urbit solves in the simplest terms you can think of?
This is probably similar to how Scientology got started. Nobody really believes in it, but are too afraid to strongly denounce it because they don't want to be the one who "doesn't get it." So they all just go along and get sucked further along down the rabbit hole. The difference between Scientology and Urbit is that Scientology managed to rope in a few celebrities and gained some sustaining mass. If Urbit wants to make it big, they should pay Zuckerberg and Musk to evangelize it, and then everyone will be falling all over themselves to be part of it.
Urbit is well documented, in easy-to-understand terminology, from low level, to high level: https://urbit.org/docs/ https://urbit.org/docs/nock/definition/ https://urbit.org/docs/hoon/concepts/
The code is open source, under MIT license: https://github.com/urbit/urbit
Heck, urbit even shows up to Hacker News semi-regularly: https://news.ycombinator.com/threads?id=urbit
What backs your claim they have done nothing to clear up the confusion about it?
"A value in Hoon is called a noun" - or you could just call it a value.
"A gate is a Hoon function" - or you could just call it a function.
"A core has no exact equivalent in conventional languages, but the closest equivalent is an object. An object has methods; a core has functionally computed attributes (arms). An arm that produces a gate is the Hoon equivalent of a conventional method;" - or you could just say that objects in Hoon (the language) can have methods and attributes, and you would never need to invent the core/arm/gate terminology.
They try to give themselves an out by saying stuff like "Hoon has concepts like all these abstractions, but they remain false cognates." When you dig into it, the only unique things are the words. It's like children trying to come up with a code- "instead of door we'll say blorp and instead of close we'll say bleep. Now bleep the blorp before we continue inventing our code.
In other words, what is Urbit's "Killer Feature"? Cause I'm not seeing one.
And a runner up question: Is Urbit still heavily dependent on unreleased root node code? In other words, is this distributed computing just a load of hype covering over a overly complicated star topology?
I think Curtis Yarvin is a master huckster and wordsmith, but near as I can tell what's good about Urbit isn't original and what's original isn't very good. The central concept is basically Java's "write once, run anywhere" concept from the 90s. Remember that? It wasn't just about applets; applets were only the beginning. With "mobile code" that could run on any device, Java was going to make existing operating systems obsolete and finally bury Microsoft.
Sound familiar?
Curtis adds sizzle to the steak by mixing in ideas Hackernews people will find appealing -- functional programming, blockchain, distributed computing -- and finally he plays the same semantic shellgame with his words he plays with his political essays, to convince you that the horrible political views he has aren't so horrible. Except this time it's to convince you that Urbit is more than a reimplementation of interesting ideas from the past, some of which failed massively.
Why? Well, the fact that he is selling "virtual real estate" in his new internet that's totally going to change everything real soon now might be a clue.
I suggest you leave your ideological biases out of your assessment of Urbit the technology. We all have our political beliefs - mine are hard libertarian, yours are hard feminist/leftist - but hopefully we can put those aside when assessing technology.
I mean.. what's not to like about Nazism and eugenics?
(I wish I could attribute a sarcasm tag, but Go look up Mencius Moldbug and read for yourself.)
That by itself might be a good idea, but if you're going to sell people on your project, you need to give some rationale / objective for your projects. And there, Urbit doesn't do well. There is some talk of decentralization, but it's not clear what the goals are.
Like many people, I find the way it's being done slightly confusing (the names, etc), but it is being done. At this point, I would just lump it in the stack of intellectual curiosities, right next to TempleOS. It might turn into something yet, but I'm not holding my breath.
https://www.youtube.com/watch?v=Md4boH1eZvc
This snippet also helps:
> Making the web programmable
> The first thing your Urbit can do is act as a transparent layer to your existing services. We’d like urbit to be usable as a self-hosted IFTTT for geeks. Your urbit can hold your keys, store data, run programs and seamlessly connect to your existing services. Plus, with a global revision controlled filesystem it’s easy to share API connectors and keep them up to date.
> With an Urbit running on your machine you can ls your Gmail from Unix. Write a short script to poll Twitter on a keyword and deliver the results to your email or into a Slack channel. Send an SMS when an HTTP request doesn’t resolve. These are just a few examples. Your Urbit is designed to make data trapped in your existing services feel like an extension of your local programming environment.
(TL;DR: "Urbit also invents a lot of alien technical jargon. We admit that this is annoying. Abstractly, it’s part of the clean-slate program: words smuggle in a lot of assumptions." - to which all I can say myself is: qupnux.)
I guess I'd put it on a poster as: lyrics by blockchain; melody by Xanadu.
Curtis, in his eminent brilliance, was the first of us to realize this, and so became the first of these wise and benevolent engineers, forging a bright path for other open-minded people to follow.
Now come, let's get you changed into this robe and learning these chants. :)
There were no takers.
The question of "but what can you actually do with it?" went unanswered by Urbit's own promoters, even when they were incentivized with real cash money to come up with an answer.
Also, what does "Urbit's formal semantics makes ships trivial to migrate" mean?
The main audience of this post is people who're already into Urbit and understand some of the basic lingo around running a ship. If you don't have that terminology down, and don't know Ethereum either, this probably reads like Jabberwocky[0].
Yes and no; it's a completely functional OS for which there are AFAICT no useful applications yet. You can absolutely run it, but there's no reason to run it other than to hack on it.
https://storage.googleapis.com/urbit-extra/etc/the%20not%20s...
My own perspective regarding these new decentralized platforms is that we're at the very tail end of low-hanging fruit in regards how easy the next generation of software innovation will be to explain to "your average layperson". The problems that decentralization are trying to solve are uniquely understood by developers, particularly people well-versed in the metagame of content, advertising, identity, and privacy on the web, which is a vast field filled with thousands of great reasons to consider decentralization, but are unfortunately hard to distill down into a 30-second elevator soundbyte.
Another problem is that having high-density conversations about software innovation is fundamentally absurd. Every software innovation is ultimately just "another way to write code", so you can boil down everything Urbit and IPFS and Ethereum are doing to "well, our current code for everything is this way, and it seems to suck, so we're going to try writing the code a completely new way". That's it. Every time someone asks "what can you even do with this thing?", the answer is "well, you can develop software on it".
Edit: Apparently the original article has been un-paywalled. Perhaps you can access it here:
https://medium.com/@IsaacSimpson/urbit-and-the-not-so-dark-f...
This essay sums it up nicely, so I won't repeat it. But I very much identify with, and am personally vexed by, the disorganized, Balkinized, online world we citizens of the "first world" are being forced to navigate.
One idea I don't grasp is how an Urbit server might integrate with a service like Facebook. Let's say you could set up your Urbit server to integrate your social news feeds from different services.
Would this violate the terms of service of a system like Facebook?
One could hypothetically create an application that at least would handle submission of personal content to any social network. And it could thereby keep a local copy of the content. But it would have to scrape the site, or use the provided API, to present any response to posts.
The linked article mentions that Facebook sued a company that tried to market an app that would present an integrated social news stream from FB and Twitter. I wonder how they would respond to an app that would let a user setup their own system to do the same thing?
I find the increasing power of the big tech companies disturbing, though I do appreciate the services they provide.
Yep. As far as I'm aware they don't allow you to display Facebook content next to content of competing sites, like Twitter. But if everyone's doing that locally on their own machines, how will Facebook know? And what can they do to stop them?
If the API is being used, they can take that away. But website scraping will remain as a viable (if slightly sub-optimal) way of getting the data out. Facebook won't stop its users from using its website, after all.
We're not sure exactly when or precisely how that market will get initialized — but you get the basic idea. Your star ownership will get mirrored in the contracts.
Basically, star owners will be handed a mechanism to run their own mini-ICO, where planets represent ICO tokens.
Why would you want to buy a planet from star owner X? I presume the answer lies somewhere in the statement: "Galaxies and stars are network infrastructure. Regular users have planets."
Urbit is on about the same level as the next Zoë Quinn game in terms of hype-to-actual-value-delivered ratio.
There was definitely a feeling of "holy shit they're doing our thing!" going around, but we can't be entirely sure if they got the idea from Urbit specifically. More likely, they aggregated ideas from all decentralization projects going on right now.
Definitely cool to see these kinds of ideas being represented in more mainstream media though!
I am not kidding. It might have came out like this by accident, but i could spend days mapping the semiotics of this to, say, scientology "books".
The most blatant technique there is the slightly out of place technical terms and insertion of sci-fi elements. Here is a paper on christian texts and the use of metaphor on the willingness of the audience http://cogprints.org/4863/1/Cognitive_Semiotics_and_On-Line_...
I strongly believe in voting with my attention and/or money against ideals that are abhorrent to me, so I thought I'd put it out there for others in the same boat.
https://medium.com/@curtis.yarvin/why-you-should-come-to-lam...
He seems like a reasonable, intelligent person, and people have gone out of their way to mischaracterize what he did say and to label him a racist.
He was also writing under a pen name, and -- believe it or not -- roleplaying is common recreation. Just because Moldbug believed something doesn't mean Chris believed those things.
All in all, I think this is just another example of the insular tribalism present in all of Silicon Valley. It's ironic that the place that prides itself on being the most tolerant and the most progressive is in fact so victorian and reductionist that their ideas can't withstand a simple debate.
Easier to label and shun, eh? I'm not a fan.
It's somewhat ridiculous that I have to add a disclaimer that I don't share any of their ideology, even in secret. I'm proud of my beliefs, and this has nothing to do with the politics at play. If you're going to be inclusive, then be inclusive. To shun someone so intelligent and to reduce their entire body of work to a few glib sentences isn't a productive strategy.
From my perspective, it seems strange that anyone could read that Medium post and come away hating Chris. He's clearly here to talk tech, not politics. So what's the problem?
When you join a Twitter mob and serve as a sort of informal government — by deciding, for instance, who can speak at a conference — you’re feeding your inner chimpanzee. It feels good. Your conscience may be convinced that it’s spiritually the right thing to do. But your limbic system is just plain high. Twitter is a drug cartel. The drug is power. Or at least, apparent power.
Hear, hear. When you seek to suppress an idea, people like me get curious. Why are you so worried that Chris is the founder? It makes me want to dig in to their beliefs and decide for myself.
Don't you see? Speaking out like this actively helps the very side you're trying to defeat. They come off looking reasonable, whereas your argument boils down to "He's toxic because reasons."
One of the most persuasive things you could do in this situation would be to post a quote written by Chris. Posting a quote from Moldbug would be the second most persuasive thing. Failing either of those, are we supposed to just take your word for it that the dude should be excluded from society?
This whole "label and exclude" thing is for the birds. Why not judge ideas instead of people?