Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bootstrapping Urbit from Ethereum

urbit.org

Post reply on HN
Print view View original

81–90 of 172 posts

Re: Bootstrapping Urbit from Ethereum

#81

Post by jolux »

munin wrote: post #72
tptacek wrote: post #65

Earlier quoted context omitted.

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.

Moldbug hates pomo though. Pretty sure the dude doesn't read anything that was written after the year 1900.

Re: Bootstrapping Urbit from Ethereum

#82

Post by ineptech »

tptacek wrote: post #48
chc4 wrote: 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 ?"

> 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?

Urbit claims to be uncrackable. Not "secure when well-configured and patched regularly" uncrackable, but "Put one on an EC2 instance and tell the world there's 50 BTC inside it and come back in five years, or fifty, and your money will still be there" uncrackable.

That's its selling point - that you could run server apps on it (in some hypothetical future where someone has written some useful apps) and not have to be a part-time sysadmin like you would if you ran any sort of *nix server.

I'm not saying that's true, I'm just answering your question. More details on why they claim it to be that way here: https://urbit.org/blog/2017.5-frozen/

Re: Bootstrapping Urbit from Ethereum

#83

Post by pcmonk »

tptacek wrote: post #76
pcmonk wrote: post #75

Earlier quoted context omitted.

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.

> not all of the last 30 odd years of systems and programming research was pointless.

Indeed, which is why it's a shame our primary server OSes (Unix-likes) can't incorporate them. Urbit can.

As for what are the approaches different, there have been many words spilled over that, but here's a few examples to wit, most of which exist in one or two other systems, but aren't widely used:

- All events are transactions, down to the VM level. There's no concept of an event that left garbage around because power was cut or the machine was rebooted. You can always crash an event, making it as if it never happened.

- Single-level store. Never worry about ORM because your in-memory state never goes away (because all events are transactions).

- Persistent connections with exactly-once messaging. Disconnection is just seen as long latency.

- Strict, purely functional language with a strong type system but no Hindley-Milner (so you don't need category theory).

- Sane indentation for a functional language, known as "backstep".

- The file system is a typed revision control system, which allows intelligent diffs on types other than plain text.

Most, if not all, of these, have been described in research, but nobody's bothered to build a system with them.

Re: Bootstrapping Urbit from Ethereum

#84

Post by state »

fra wrote: post #9

It's not clear to me what this means for folks who bought urbit stars earlier.

Addresses can be committed to the contract in exchange for sparks. The contract then holds those addresses, until someone burns a spark in exchange for them.

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.

Re: Bootstrapping Urbit from Ethereum

#85

Post by pcmonk »

tptacek wrote: post #80
ineptech wrote: post #77

Earlier quoted context omitted.

> 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'…

There are about 5 billion adults[0], and they don't all need separate planets. Married couples, for example, may not.

That's beside the point, though. Using scarcity to create value is not "extremely unconventional"; it's about the most ho-hum idea in Urbit. If you want a 128-bit address, you can use those in Urbit just fine. The only difference is that they don't have a default-positive reputation (where "reputation" is an abstract concept -- in practice, e.g. some channels wouldn't let 128-bit address post comments)

[0] https://www.census.gov/population/international/data/idb/wor...

Re: Bootstrapping Urbit from Ethereum

#86

Post by adiabatty »

tptacek wrote: post #41
chc4 wrote: post #28

Earlier quoted context omitted.

I'm one of those people that get it, so I'll try to explain it without going off the deep end and waxing poetically about planets or whatever. 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…

This is a good, well-written explanation of the most reasonable, mainstream aspects of Urbit, leaving the impression that it's essentially like a P2P version of AWS Lambda. 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 on…

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

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?

Re: Bootstrapping Urbit from Ethereum

#87

Post by dropit_sphere »

aeontech wrote: post #14

Every time I read something about Urbit I am reminded of the Lewis Padgett short sci-fi story, "Mimsy Were The Borogroves" [0], [1] describing children discovering alien future toys, and subsequently via use of those toys learning to manipulate reality in incomprehensible ways. I still have not been able to figure out if there's actually something that amazing about Urbit, or if behind the obfuscated terminology ther…

That is such a cool story. Thank you for mentioning it.

Re: Bootstrapping Urbit from Ethereum

#88

Post by ineptech »

tptacek wrote: post #80
ineptech wrote: post #77

Earlier quoted context omitted.

> 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'…

You said the founder believes "there aren't and never will be" 4B people "worthy" of an urbit planet. I'm asking where you got that "never will be" part.

I think your reading of that bit you quoted is extremely uncharitable. I don't see where urbit is passing pronouncements on anyone's "worthiness". The way I read that quote is, "an urbit planet is server software, and there are way less than 4B people with a server to run it on."

Re: Bootstrapping Urbit from Ethereum

#89

Post by chc4 »

tptacek wrote: post #65
chc4 wrote: 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…

My dude, how can you read code out loud and not understand the draw of having single-syllabul names for all the weird characters in ASCII. I don't have many of them, but this is a hill I will die on even if Urbit falls off the internet tomorrow. Luckily, you don't /actually/ have to memorize those. They aren't used if you aren't saying runes out loud.

There's a difference between reinventing ten wheels ten different ways for ten apps, and reinventing one really big wheel. It has to be self-contained enough that other apps can use it without having to roll their own anything, so all of them has the same API.

One of the problems with "just use a different P2P VM" is that it probably wouldn't solve the problem of having a server your mother could use. You'd probably still have to install and setup Apache and MySQL and ElasticSearch and whatever, even if someone implements the perfect transport protocol and platform. For Urbit you just run it, which can be hidden behind a pretty "click to start" button that pings our to AWS. Hence, one big wheel.

If you do see an Urbit-like project that has the same goals, I would be ecstatic to hear about it though. I've basically had "urbit but different" on my TODO list since I first saw about it.

Re: Bootstrapping Urbit from Ethereum

#90

Post by ubernostrum »

adiabatty wrote: post #86
tptacek wrote: post #41

Earlier quoted context omitted.

This is a good, well-written explanation of the most reasonable, mainstream aspects of Urbit, leaving the impression that it's essentially like a P2P version of AWS Lambda. 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 on…

> 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. One of the things they want is for identities to…

If it hasn't already, the total number of humans with mobile phone service will exceed 2^32 within the next year or two, and phone service typically isn't given away free out of the goodness of the phone companies' hearts.

So the mobile industry is already past or very soon to be past the 32-bit space with paying customers.

Post reply on HN