hn_urbit_thr123

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.

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)

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.

I really like the idea of Kelvin versioning for an OS: instead of counting up and adding features forever, count down until you're done.

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?

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.

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.

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?

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.

My (relatively unbiased and informed) summary of what urbit is from the last time it came up is here: https://news.ycombinator.com/item?id=31124343

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!

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.

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).

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.

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.

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 :)

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.

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).

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.