100% urbit. The idea behind it (briefly: "personal server", an easy-to-use, no-frills place for an end-user to run server-side use cases like storing important files, hosting a blog, etc that's portable between cloud hosts and designed for long-term stability over performance) is a good one. Implementing it as a novel VM with built-in identity and crypto makes sense. It includes some genuinely hard/useful features, like exactly-once messaging between nodes. Kelvin versioning (counting down towards "done" rather than counting up as features are added) is a great idea for software that serves infrastructural purposes. Charging a one-time fee for cryptographic identities is an elegant way to make a de facto reputation network that disincentivizes malicious actors, and is also that rarest of beasts, a non-dumb reason to use a distributed ledger.
It had so much going for it, but it was DOA from launch for two reasons: first, the implementation is so bizarre that the kernel documentation is frequently mistaken for an elaborate joke, and second the founder's racist blog went viral at virtually the same time as the public launch. It's not technically failed I guess as it's still being developed and does work, but a network without a network effect can only go so far.
I honestly think the "personal server" idea would be incredibly useful, and it would also be very profitable (not the software itself, but for cloud providers) if every suburban family rented a $15/mo VPS. I post about it here from time to time in the hopes that someone will fork it or re-implement what is basically a great idea, but in a non-ridiculous way and without #cancelled taint of the founder. Bezos, if you're reading this, please put a small team on it just to see if it goes somewhere, I'll be your first customer.
This is the first time anyone's ever explained Urbit in an even vaguely comprehensible way. It always seemed like a ridiculous, grandiose exercise in ideology-first development to me, similar to the eye-scanner crypto orb.
"Oh, a distributed platform for small scale server apps," sounds like a valuable but not earth-shattering idea.
Like most platforms, it's valuable IFF a lot of people build on it. But the fact that I can make an on-topic, constructive and informative comment about it and still get downvoted tells you everything you need to know about how likely that is.
I think tech people often forget how important the human component is. Nobody wants to build their sandcastle in your sandbox if you're too weird or too much of an asshole.
Sorry if I was unclear, it's a hard thing to summarize, but the useful part of it is in being a platform for app development, not just the fact that it hosts stuff. "End user server-side apps" isn't really a thing that exists, because current server-side applications e.g. wordpress have to run on a variety of stacks, have to reinvent user authentication, etc. Another way to put it would be that urbit is a platform on which to run build server-side apps in the same sense that Android is a platform for client-side apps.
It does work tolerably well, people are building stuff on it, but I think it's too widely-hated to build a network effect. (Source: search for urbit on HN and click on literally any thread)
Thanks for working on this. Have you considered abandoning urbit references and nomenclature? I've been casually following urbit a long time, and think there's a case to be made that it has accumulated enough toxic baggage to rub off on onto any project with even a whiff of association. I mean, you can see this thread as well as I can. Would it be realistic or possible to keep what you've got in plunder but reframe it in such a way as to make it less susceptible to guilt by association?
there are pretty few mentions of Urbit in the core Plunder project/codebase & many of the core concepts are different (and more conventional, I might add).
I've been following along w/ Plunder for the past 10ish months and I essentially "bounced off" of Urbit's (imo) opaque terminology, opting to learn Plunder instead as it seemed much more concise and better conceptually distilled. not knowing Urbit has not been much of a hindrance. so I think the "guilt by association" you are seeing comes more from the framing of the above gist, which was aimed at an Urbit audience & cross-posted to HN by someone not associated w/ Plunder.
It's disappointing how much low-effort bashing there is in this whole thread. Sure urbit is weird and has a lot of baggage and questionable design decisions, but the project we're discussing is explicitly an attempt to separate out a few good ideas and remove the bad parts. Is that really deserving of casual mockery?
I know I'm shouting into the void here, and under a pseudonym to boot, but this is an active FOSS project that real live people work on in their spare time because they hope it'll be important and useful. I like to think it's a convention here not to shit on such people for comedy value.
Do they work on it because they hope it will be useful, or because they hope their crypto-fiefdom will be valuable and make them rich?
Behind the impenetrable jargon, Urbit has always put a lot of emphasis on this "digital real estate" aspect. For example:
"Urbit IDs are property, and we think of the entire registry of Urbit IDs as a vast territory of digital land."
[https://urbit.org/overview/urbit-id]
It's not exactly an altruistic open source project if your fundamental motivation is to become a member of the digital landowner upper class.
(And if you scratch the surface of Urbit, you'll find the creator is a reactionary extremist who has said he prefers feudalism to democracy. Those ideas are embedded in the platform design that makes lip service to decentralization but actually concentrates control to the very few.)
Disconnected thoughts (having just spent a couple of hours of fascinated reading around Urbit).
Thirty years ago I would have been on this train. No question. It's giving me early 90s internet optimism techno-utopia feels. Now I'm older and a lot more jaded, I think I'll give it a miss and set my sights lower with something like Gemini for my weird niche internet protocol needs.
The deliberately impenetrable jargon reminds me of 90s-era Wired's reader-hostile graphic design. We're so cool, we can put barriers in your way and you'll clamber over them to get to us. That's a marketing technique - I've heard it called challenge appeal.
All federated solutions need some kind of trust model. Money is not, at first glance, a terrible answer to that problem (hashcash for email, and some web forums charge a few dollars for accounts just to keep the spammers out). Mastodon delegates trust to the instance admin, Scuttlebutt limits its web of trust to two degrees. But this elaborate tiered model is just unnecessary - they must have considered, and rejected, proof of work or many other possible solutions. It's sad that I assume bad faith because of someone's political position, but so it goes on the post-enshitiffication internet. The trust has already been eroded.
Isn't it interesting that a piece of software can be the concrete embodiment of a philosophy?
Urbit made the choice to use a bunch of silly new words for familiar concepts, not because they were inventing something so new that there were no words to describe it, but because they wanted to fool people into thinking that's what they were doing. Actually they just spent 10 years trying to do https://sandstorm.io/, but made it 10 times harder than it needed to be by coming up with a wacky new set of programming languages with silly names for everything.
Probably, as they were asking for it by doing their work in cultish style. If you want to change the world, you need people to accept the change you want to bring, and for that you must make it understandable, approachable for them.
Why would I need to put a lot of effort to be able to be part of a discussion which is seemingly not intended for me? If the ideas behind it prove to be useful, they will eventually resurface/be done by a more welcoming/industry standard way. Then it will be worth the effort. Until then if I want to waste my time on esoteric nonsense I go look at the Woynich Manuscript or read schizo larp on /x/. (Or just try to keep up with the SV JS scene where everything is reinvedted ignoring every industry standard ligo and is named crazily)
> this is an active FOSS project that real live people work on in their spare time because they hope it'll be important and useful.
So what? There are lots of other project done on the same basis, and for most of them you don't have to learn a new dialect just to understand what their work is about.
Parent is perhaps comedic but has a valuable point: This writeup is unapproachable for a general audience due to heavy use of meaningless (“brand”) names.
For me it’s also a red flag: Neither system seems to be designed to be approachable. One or two brand names are OK, but these systems seem to use them way too liberally.
If you decided to make a fork of linux, and wrote an article explaining why, would you expect it to be easily comprehensible to someone who's never used linux?
I'd expect someone that worked on the BSD kernel or SunOS or whatever else to be able to read about your linux fork and come away with a certain level of understanding as to what sort of thing you hoped to achieve vs what's in the existing mainline kernel. People with some kernel theory under their belt, that sort of stuff.
They may not grasp every little thing, but they would be likely to get an understanding.
But the use of deliberately weird terms for things makes it less possible for those who likely have overlapping domain knowledge to understand these systems or posts about them.
The problem isn't that you're wrong, it's that this is the same cutting insight everyone has in their first five minutes of exposure to urbit. It's like going to Australia and telling everyone you meet that vegemite probably won't take off in America because it tastes weird. We know, man.
But there's also probably some new and interesting criticisms one could make? Perhaps about the actual project described in the article? And maybe after having read it and understand it? That doesn't seem like too high a standard.
I'm not bored, just sad. The "personal server" thing is a cool idea. I think the world would be better if it existed and worked well enough for wide adoption, but it seems like it'll never happen because the first guy to try to build one was a weird racist. So sorry to rag on you for something literally every other commenter in this thread is doing, it's just dispiriting to see, over and over.
You know you don't have to use Urbit to get a "personal server", right? You can get a small VM, install Linux or BSD on it (whatever floats your boat), set up email, web server, mastodon instance...
this would be a true "personal server", and it will achieve much more than Urbit ever could.. except insane jargon at least...
They literally kicked him out of town. If there was any person you could pick that best represents the whole Urbit community now, it would be anyone but this person.
And that's not because I am beefing with him or have any personal beef with him. He's literally not there anymore. He went away, years ago.
yes. I've read some of low-level technical VAX/VMS and Solaris articles, and they were mostly comprehensible. Connection Machine stuff is impractical but _fascinating_ (despite being much farther from Linux than Urbit ever was)
Urbit is really an outlier, with jargon/innovation fraction far exceeding anything else I have seen.
Urbit is a weird freak system built to be intentionally hard to use by a bunch of actual fascists whose goal is to become the new landlords of an imaginary digital real estate economy. Yes, it deserves all the ridicule you can give it and more.
As someone who thinks urbit would solve an important use case but is too hopelessly weighed down by the stench of its founder to go anywhere, a good fork seems is a reason for optimism, so best of luck Plunder team!
Yes, but the receiver can be faulty. If it acknowledges the message and then crashes before handling it, you've got at-most-once, and if it handles the message and then crashes before acknowledging it, you've got at-least-once. You can avoid this if the receiver handles and acknowledges in a single transaction, but I only know of one platform that implements this and everyone hates it (hence the throwaway).
Even with a transaction, if the processing involves external side effects, e.g. sending and email, the rollback won't matter and you still get at least once.
There's no rollback, it's an atomic transaction. The certainty that messages are always handled completely or fail completely is one of the big design constraints that made the whole thing so hinky.
Is it even realistic to make a provably secure/stable applications on an OS like windows or linux? This (provable correctness of programs, at the expense of performance) is one of the explicit design goals or urbit. I know HN hates urbit and don't want to rehash that, but it seems like a good goal for some use cases and I'm not sure it's possible to achieve without building the OS around it.
Urbit has not put much effort into security, for some reason. To be fair, they don't claim their runtime is secure (yet)[1]. The process downloading and executing code from the network is not sandboxed with seccomp or anything similar, and its "jets" are unverified C libraries which any of this code is allowed to call into. They could sandbox it pretty easily (the worker process which runs third-party code only talks to a host process and not the rest of the world, so it could probably be run under seccomp, not even seccomp-bpf) which makes it all the more surprising that they haven't.
Urbit has also had (and almost certainly still has) bugs where jets give different results than the code they're supposed to accelerate (a "jet mismatch") [2]. I agree that its "axiomatic" bytecode would lend itself well to verification theoretically, but Urbit as she is spoke is not anywhere close. They also at least historically seemed somewhat hostile towards academic CS research (including formal methods) probably for weird Moldbug reasons.
Let's say that Urbit claims to be formally, provably secure. But approximately nobody actually understands Urbit, which means that nobody knows whether the proof is solid. So as an outsider, I have to either take it on faith that it's secure, or I have to spend a fair amount of time immersing myself in this hard-to-learn system to see if the claimed benefits are really there.
But it's not just Urbit. Rust has essentially the same problem.
In fact, perhaps all of formal verification has this kind of problem. How do you prove the benefits to someone who doesn't know the tools?
You don't have to understand the linux kernel to buffer overlow a linux application; If they do something like "Here's the IP of a running urbit with 100BTC in it, good luck!" and it's still up in a few years, that'd be compelling.
But more generally, if it's true that the only way to make a provably secure app is to design the OS and language around that purpose, then the problem you describe is general too - it will always be a challenge to find auditors.
FWIW here's an explainer I wrote up a year ago for a friend who asked. I'm not affiliated with urbit, except that I want a product that does what it does (which at this point means I'm hoping someone reinvents it, because it seems fatally doomed by how hated the founder is).
What is Urbit?
Urbit is a virtual machine OS for server-side applications. If you imagine a future in which it is common for non-technical people to rent cloud server space on which to host server-side applications (say, a small blog, a mastodon node, a minecraft server, etc), Urbit aspires to be a good platform on which to host them.
Urbit features:
1. All input events (http request to an urbit-based api, signed message from another urbit, keystroke from console, etc) are transactions which change the OS state (or don't, if they fail). As a result, it should be impossible for a transaction to fail halfway through and leave the urbit instance hosed.
2. Exactly-once messaging between nodes. This is possible because nodes have persistent connections; disconnection is indistinguishable from long latency. This may sound minor, but it is a huge part of what makes urbit novel and (theoretically) stable and secure.
3. Built-in identity and auth. An urbit instance can't boot without an identity, which serves as username, network-routing address, and also as the public key with which all outgoing messages are encrypted. In practical terms, this means no urbit app or service needs to deal with logins or passwords or crypto.
4. There are only 2^32 first-class identities, which makes urbit a de facto reputation network. This is to minimize malicious behavior; if an identity costs $5, and you can only make $2 from spamming before that identity is blacklisted, no one will spam.
5. The urbit network is hierachically federated, and hence resistant to censorship. (Of course, this is a misfeature if you want to be able to censor people off of the networks you participate in)
6. It's not there yet, but the urbit kernel aspires to be so small and simple and formally-provably-correct that at some point it's done. As in, done done - no features to add, no bugs to fix, done. A lot of the design decisions (some of which are wildly unperformant) make no sense unless you take this goal in to account. More on that here: https://urbit.org/blog/toward-a-frozen-operating-system
Main Criticisms:
1. The founder has objectionable politics/beliefs. For its first decade, urbit was the solo project of one Curtis Yarvin, who moonlighted as an alt-right-ish blogger, and flamed out of polite society as a result. I've read a tiny bit, it was pretty dumb. The tl;dr is that he wants to get rid of democracy and bring back feudal monarchies. He also said some pretty racist stuff from time to time and that's the main reason everyone hates him. He left the project several years ago, which accomplished absolutely nothing in terms of anyone hating it any less.
2. The language is very strange and possibly bad. By "language", I mean both the programming language (hoon, the native language you write urbit apps in) and urbit's terms for core concepts, almost all of which have new, made-up names. More info here: https://hooniversity.org/urbit-and-hoon-glossary/
3. A lot of people think it's a shitcoin of some kind. AFAICT this is objectively not true. There's no way anyone will make any amount of money speculating on urbit unless it works in the sense that it's a good OS that millions of people want to use. Besides, if it were some kind of scam, it would've fallen apart when the founder left under a black cloud. That didn't happen; it is still chugging along. There are competent programmers who understand it and have worked on it for a year or two and still think it's genuinely good technology and continue to work on it for that reason.
>5. The urbit network is hierachically federated, and hence resistant to censorship.
This is not true. Urbit is essentially a proof-of-stake network where the Galaxies and Stars have the authority to ban anyone off the network that they want.
After Planets are already routed to some of their friends, they can keep those connections, but if a Planet is refused service by Stars, it will be limited in reach and capabilities.
The whole point is that there is accountability in the system and there does need to be a kind of Byzantine (literally it is set up like an empire) consensus.
If you're banned by one Star, you can still be served by another Star, but it does affect the reputation (not hard-coded, but actual) of the Star that serves unsavory Planets.
It's not far off from the Fediverse in this regard.
I agree, I was being terse; it'd be more accurate to say you can be banned off of the urbit network entirely if everyone hates you, but if only most people hate you, you can still use it (but may only be able to talk to the other outcasts that most people hate).
Not really? You could have thousands, hell millions of people who love your twitter account or your podcast but if a critical mass (not even a majority! just a large and sufficiently noisy minority) complain about you, you're gone.
On Urbit there are 65k tracker nodes and ~4B permanent peer nodes. So long as a single 1 out of those 65k is willing to sponsor you and broadcast your location anyone can find you and get packets from you, and even if the last 1 gets sick of you he's still just the equivalent of a torrent tracker: anyone who is already your peer will continue to see you on the network. It doesn't matter how many enemies you have or which corporations you piss off, you know? You're your own platform, once you install the software to share tweets or photos or interviews or whatever there is no one left between you and your audience to play gatekeeper.
On Urbit you have ~65,000 potential star sponsors and can switch at any time. (Worth noting: after a year and a half on the network, I have not heard of anyone being refused service by any star.)
That's a clear difference from today's internet, where effectively all discourse gets siphoned off, by a series of vicious megacorporation incentives -- the need to lock you in, the need to serve you up manipulative advertising -- onto the servers of one of four FAANG companies. (I think we can safely remove the N at this point, but then the acronym ends up looking rather seemly.)
> it seems fatally doomed by how hated the founder is
Having been around the network for a few years now, and having talked up Urbit to countless people of countless different professions, political beliefs, ages, etc, I can confidently say: This isn't true.
It's just that a specific sort of Hacker News/Reddit gets agitated and makes a lot of noise on this subject whenever Urbit gets brought up.
Normal people who just want their digital lives improved aren't interested in these cringe 2010s-era blogosphere political beefs.
No, Urbit doesn't require an always-on connection. It does work better with an always-on connection, since its peers will send it a lot of events to process as soon it reappears after a long absence.
> This also means that all apps have full access to all your money, private info, bank accounts etc.?
If you wanted to write or install an app that had access to a hot wallet stored on your Urbit ship, for example, you could. It doesn't have access to secrets you haven't intentionally stored on your Urbit. When you say "all apps have full access" - what do you mean? For example you could write an app that is both a display case for POAPs and also spies on your private messages, but the actual app that is a display case for POAPs is written to have no way to access your messages: is this the question you were asking?
> When you say "all apps have full access" - what do you mean?
I mean this: "this means no urbit app or service needs to deal with logins or passwords or crypto.". If apps don't need to deal with that, they have access to your info, doesn't it?
I think you're turning the question around the wrong way - there are hundreds of thousands of apps and services on the internet that all force you to make an account with their service to use their software, access data you've uploaded to their service, and interact with other users. That's the thing that is a huge hassle and also, increasingly (with web3 and on-chain applications growing in popularity) a huge security problem because of the attack surfaces those services' front ends offer. On Urbit none of this is necessary, because the "account" (i.e. network identity and keys) of your ship is already baked into all your interactions with the network.
As far as the apps having access to cryptographic secrets you store elsewhere on your Urbit ship: the apps are all installed and running on your ship, so just like other software running on a computer you control they can have access to other local data if you intentionally give them permissions, or they can have no access, or they can have access conditional on some additional safeguard. It depends how you write the app. But an app always knows the Urbit identity of the ship it is installed and running on, and that is baked into messages the app sends to other ships.
You also have the ability to spin up 4 billion virtual identities ("moons") per primary identity ("planet"), and it is a standard use case to run an app/service you don't want to interact with the rest of your ship on one of your moons. The main value currently is, if you host a high-traffic groups or distribute a popular app, these would make your primary ship run slow so you stick them on a moon. But the reason Urbit was designed to associate each identity with 4B virtual identities was so that your IoT devices can communicate with the network without having access to your personal computer.
> It depends how you write the app. But an app always knows the Urbit identity of the ship it is installed and running on
So, it has all the access necessary to go ahead and steal my money, right? Because, quote, "network identity and keys are already baked into all your interactions with the network"
Urbit is an OS, apps have access to whatever you give them access to. If you want one app (say, a dating profile) to not have access to data stored by another app (say, your bitcoin wallet), you run them under separate sub-identities as described above.
That has nothing to do with the thing you quoted ("network identity and keys are already baked into all your interactions with the network"), which describes how urbit nodes talk to each other. Whatever identity you run an app under, all traffic from that app will be cryptographically signed by that identity.
> If you want one app (say, a dating profile) to not have access to data stored by another app (say, your bitcoin wallet), you run them under separate sub-identities as described above
You're dancing around the issue.
So:
1. By default all apps have access to everything.
2. In order for apps to not have access to everything, you have to set up a different identity which is magically different from having to set up different identities now because it has cute names like "spin a moon away from your ship"?
3. The burden is still placed on the user: to set up and manage all these different identities and subidentities to just make sure that a chat app doesn't have the ability to steal all my money
3.1 And when in the current systems the burden is to keep track of logins and passwords, in Urbit it's the burden of understanding all the technical mumbo jumbo and going the trouble of spinning new servers (which I assume are not free) just to run a banking app.
How do you keep apps from accessing other apps' data on linux? By creating separate user accounts with limited permissions for the apps to run under, right? Same deal here. Except that in urbit, "different user account" implies that it's running in a separate VM.
I'm not arguing with you, just trying to answer your questions. If you want to make really damning accusations about how awful urbit is, it will help to learn more about how it works :)
I want something similar but that has true validated id's, and separate person accounts and business accounts. Person accounts then would have taxation built in and UBI and mutual aid, and there'd be some algorithm that taxes and pays dividends based on how much you hodl and how much you utilize or transfer in a month, etc... essentially if your payment habits are that of a poor person you'd get more UBI if your spending habits are that of Elon Musk you'd pay taxes.
There'd also be a cap on how much your account could hold to basically bar billionaires and oligarchs from controlling the system. Maybe something like x amount times the average users' monthly income(transactions received).
Starting out it'd aim for like 500 million being a cap, and try to aim to keep some sort of stable price as well. Business accounts wouldn't have the caps because I mean a huge company like walmart has tons of money come in for payroll, etc.. and just there'd be no way to really handle that, and you want businesses to accept the currency as utilization is everything.
I think possibly having a dedicated exchange built in as well that basically floods the market with new dollars if stability starts to fade. Say the price of a coin is $10 usd, it would autotax the top 50% of earners and redistribute that to the bottom 50%, or something similar or mint new currency and distribute from that -- essentially to encourage prices to remain stable.
Now combine that w/ all the other features of something like urbit os, and I think you've got something.
TLDR: Imagine if as a US citizen you were born with an id and a bank account tied to that id. It's the only bank account you can have, it's the only bank. Now imagine there's a cap to that account and every billionaire ceases to exist because they'd be taxed at 100% until they're max holdings are 500 million. You can't hide money, or get separate accounts, etc... There are no loopholes as it's all by smart contract.
It had so much going for it, but it was DOA from launch for two reasons: first, the implementation is so bizarre that the kernel documentation is frequently mistaken for an elaborate joke, and second the founder's racist blog went viral at virtually the same time as the public launch. It's not technically failed I guess as it's still being developed and does work, but a network without a network effect can only go so far.
I honestly think the "personal server" idea would be incredibly useful, and it would also be very profitable (not the software itself, but for cloud providers) if every suburban family rented a $15/mo VPS. I post about it here from time to time in the hopes that someone will fork it or re-implement what is basically a great idea, but in a non-ridiculous way and without #cancelled taint of the founder. Bezos, if you're reading this, please put a small team on it just to see if it goes somewhere, I'll be your first customer.