Live data from Hacker News

Bootstrapping Urbit from Ethereum

urbit.org

71–80 of 172 posts

Re: Bootstrapping Urbit from Ethereum

#71
post #70
post #63

Earlier quoted context omitted.

"Of similar maturity"? What does that mean? What is one mainstream application --- let's define "mainstream" here as having more than 10,000 active users --- that is built directly on top of the Urbit stack?

By maturity I meant something like "continuous opeartion for a year with cryptographically signed live update (including cryptography themselves, implemented in VM)", which Urbit did. But okay, I am also interested in competing projects of any maturity.

Because implementing cryptography in a bespoke VM is an important feature? Why? That's the kind of thing cryptography engineers try to avoid.

Re: Bootstrapping Urbit from Ethereum

#72
post #65
post #61

Earlier quoted context omitted.

Do you have something in mind? Using GNU Social as a convient whipping-post, it's built on PHP and MySQL and Salmon and PubSubHubbub and... The point of Urbit is to be a cobherent, self-contained platform. Every other decentralized app I've seen had to reinvent several wheels and can't interact with each other because of it. Urbit has a typed versioned filesystem exposed as a global namespace, typed RPC with a diff/p…

The problem I think a lot of people have with this system is that they agree with you: the underlying concept of an overlay network with abstracted addressing and an embedded programming language VM is straightforward, and may indeed be useful. Since all the core technological ideas in this system are simple enough to be undergraduate projects, why not just wait until someone builds one out of conventional components…

I think urbit started out as a pomo critique of modern academia and tech, with heavy jargon and wheel rebuilding. Then, some other people started taking it seriously. I’m not sure if that is the best or worst outcome for this kind of joke.

Re: Bootstrapping Urbit from Ethereum

#73
post #61
post #48

Earlier quoted context omitted.

Right, but you could do that with any P2P overlay network with any embeddable VM. Why use the very unorthodox one that Urbit came up with? I really think that's the question people are asking when they say they don't understand Urbit. Not, "why would we want to do what this system claims to let us do", but rather, "why would we want to do it that way ?"

Do you have something in mind? Using GNU Social as a convient whipping-post, it's built on PHP and MySQL and Salmon and PubSubHubbub and... The point of Urbit is to be a cobherent, self-contained platform. Every other decentralized app I've seen had to reinvent several wheels and can't interact with each other because of it. Urbit has a typed versioned filesystem exposed as a global namespace, typed RPC with a diff/p…

Coherent, self-contained platforms seem to always lose in the market, so it's not even clear that's a good goal to aim for. That's why I prefer Sandstorm; it provides an evolutionary path from normal Linux.

Getting back to your question, Blockstack is claiming to provide virtually the same personal cloud features as Urbit but it's only boiling half the ocean.

Re: Bootstrapping Urbit from Ethereum

#74
post #51

Urbit likes like an awesome idea. Are they shipping a product? Or it’s just theory for the moment? If it’s the second, any idea when we can expect to see the first products?

> Are they shipping?

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.

Re: Bootstrapping Urbit from Ethereum

#75
post #69
post #67

Earlier quoted context omitted.

> To me, all you're doing here is describing an object-based language in which functions are first-class. Obviously, Urbit didn't invent this concept. Its predecessors used normal names for these terms. Why does Urbit invent new ones? That's a pretty (unintentionally) misleading description of it. What is an object? An Urbit function has basically nothing that an OOP object has. No class, no inheritance, no attribute…

How are these not problems that every VM for a high-level programming language also addresses?

They absolutely do, with their own terms. Isn't an S-expression just a list? Isn't a method just a "member function", which is really just a function, which is really just a subroutine? Every language comes up with its own terms, especially for things that are a little different from previous work.

Urbit isn't trying to solve many new problems; it's trying to solve old problems in different ways. They just want to be able to talk about the constructs in their solutions.

Re: Bootstrapping Urbit from Ethereum

#76
post #75
post #69

Earlier quoted context omitted.

How are these not problems that every VM for a high-level programming language also addresses?

They absolutely do, with their own terms. Isn't an S-expression just a list? Isn't a method just a "member function", which is really just a function, which is really just a subroutine? Every language comes up with its own terms, especially for things that are a little different from previous work. Urbit isn't trying to solve many new problems; it's trying to solve old problems in different ways. They just want to be…

Right, I get that. So I guess my question is: in what ways justifying new terminology are the approaches taken by Urbit different? And whether or not they're different enough from prior art to merit obscure new terms, are those differences worthwhile, or are they different for the sake of being different? Because not all of the last 30 odd years of systems and programming research was pointless.

Re: Bootstrapping Urbit from Ethereum

#77
post #58
post #54

Earlier quoted context omitted.

I'll admit, Hoon is weird. But complaining about Nock is like complaining about the JavaScript VM. You can JIT it and replace common functions to replace with calls to C functions instead. Nock defines the /results/, not how to get them. Jets are basically just because the Nock spec didn't want to have to outline a bunch of primitives that don't really matter, since they would be replaced with native calls anyways. A…

Whoah, hold on. I hate to zoom in and nitpick, but I'm not guessing when I provide that reason for the 2^32 bit address space. It's the official stated answer from the project itself. And I'm not saying the problem with that design decision is that it's amoral (let's stipulate that it isn't). I'm saying that it's extremely unconventional , a landmine of orthogonal ideology buried in the architecture of the system. Be…

> I'm not guessing when I provide that reason for the 2^32 bit address space. It's the official stated answer from the project itself.

Link? My understanding was that the official answer was "there should be about as many urbit addresses as adult humans so that they're too expensive to spam from, and if urbit is ever so wildly successful that we start running out, it won't be that hard to add more." (though I don't remember where I picked that up either)

Re: Bootstrapping Urbit from Ethereum

#78
post #48
post #45

Earlier quoted context omitted.

Marketting spiel incoming. You use Reddit to share link, Twitter to keep up with people, and IRC for real time chat. In all of those cases you are trusting a third party corporation that they aren't keeping you data forever and they won't arbitrarily ban you. You can switch to alternatives like Mastodon or, like, voat but it's really the same problem: now you're just trusting a different server, and being banned stil…

Right, but you could do that with any P2P overlay network with any embeddable VM. Why use the very unorthodox one that Urbit came up with? I really think that's the question people are asking when they say they don't understand Urbit. Not, "why would we want to do what this system claims to let us do", but rather, "why would we want to do it that way ?"

Theory: only a system as esoteric as Urbit could generate the necessary asabiyyah to actually pull this off. It's not just a tech problem, it's also a social engineering problem. As in, how can you self-select for only the smartest, most dedicated people to build your system? Well, allow me to introduce you to Hoon https://urbit.org/docs/hoon/

Re: Bootstrapping Urbit from Ethereum

#79
post #58
post #54

Earlier quoted context omitted.

I'll admit, Hoon is weird. But complaining about Nock is like complaining about the JavaScript VM. You can JIT it and replace common functions to replace with calls to C functions instead. Nock defines the /results/, not how to get them. Jets are basically just because the Nock spec didn't want to have to outline a bunch of primitives that don't really matter, since they would be replaced with native calls anyways. A…

Whoah, hold on. I hate to zoom in and nitpick, but I'm not guessing when I provide that reason for the 2^32 bit address space. It's the official stated answer from the project itself. And I'm not saying the problem with that design decision is that it's amoral (let's stipulate that it isn't). I'm saying that it's extremely unconventional , a landmine of orthogonal ideology buried in the architecture of the system. Be…

I haven't seen that as the reason behind it (something about 4 billion planets being a good limit, maybe), and assumed it was hyperbole.

2^32 "houses", even if it was ideologically motivated, is a design decision that makes sense at first glance, is easily worked around (and was designed that way), and can be trivially changed. Some of Curtis' politics were visible in the Urbit first draft (naming galaxies after ancient rulers being the most egregious...), and both weren't important and have since been changed.

Thinking about it, 2^32 planets is one of the only weird design decisions that /would/ be ideologically motivated, other than the general dislike of Haskell or UNIX that birthed it. All of Hoon and the kernel are basically built from Nock first principles, which is both insane to read and amazing, and I'm not sure that you can say Curtis' ideology is the DNA of them. Urbit has tons of weird things in it that could make you drop it (like all of Hoon, even though most of it does make sense and is easy to learn, I promise! I'm not crazy!), but I don't think Curtis is the fatal flaw.

Re: Bootstrapping Urbit from Ethereum

#80
post #58

Earlier quoted context omitted.

Whoah, hold on. I hate to zoom in and nitpick, but I'm not guessing when I provide that reason for the 2^32 bit address space. It's the official stated answer from the project itself. And I'm not saying the problem with that design decision is that it's amoral (let's stipulate that it isn't). I'm saying that it's extremely unconventional , a landmine of orthogonal ideology buried in the architecture of the system. Be…

> I'm not guessing when I provide that reason for the 2^32 bit address space. It's the official stated answer from the project itself. Link? My understanding was that the official answer was "there should be about as many urbit addresses as adult humans so that they're too expensive to spam from, and if urbit is ever so wildly successful that we start running out, it won't be that hard to add more." (though I don't r…

A 32-bit planet is a tool, not a toy. Like a car, it's a device for a responsible and independent adult. There aren't 4 billion cars in the world, nor 4 billion independent adults.

If you aren't an independent adult, and you don't need or even shouldn't have unconditional digital freedom (no one's 8-year-old daughter needs unconditional digital freedom), a moon from someone else's planet is fine. (Even most of today's independent adults don't complain enough about being Facebook's moons.)

It's literally a bullet in their "objections" post.

Post reply on HN