Bootstrapping Urbit from Ethereum

So, there are absolutely no "Killer Features" then? That was my primary question, which you refused to answer.

That's what I suspected.

Edit: Quote from your post-- "However, recently, I finally heard the first solution which felt like the completely right solution to me, and I believe they're pursuing it."

Yet no answer.

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.

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.

This is a great question.

The best way i've found to describe Urbit as a product is a decentralized, open source version of WeChat. No, nobody really cares about privacy, but I think the argument is that for the consumer there is the potential for a way better experience. If all of your data is in one place, as a consumer, you only ever need to enter it once. More interestingly, all of your apps can work together in a seamless way that's currently impossible with the current paradigm. Your maps app has ubers and lyfts driving around on it, with yelp/opentable postings on all restaurants, etc.

On the developer side, you save so much time not reimplementing identity, payments, reputation, etc., everytime. There are more reasons why Urbit is better for developers, but I won't go into them here. Checkout the whitepaper...it's a little dense, but there is logic there:

Now, to your question. WeChat won at chat and once they owned communication / identity, it was fairly easy to move into payments and everything else. Urbit has a classic chicken & egg problem: its tech is designed to be better at doing everything for everybody. The current stack is already much more robust and better suited than urbit for most if not all one-off 'killer apps.'

So, you're right, they need to find the first killer app, equivalent to WeChat's 'chat'. I've been following the project for years, and the answer to this question has eluded me. However, recently, I finally heard the first solution which felt like the completely right solution to me, and I believe they're pursuing it.

Yes, some of the language is pompous and unnecessarily 'verbose'(being generous). Yes, they could do a better job explaining the problem in laymen's terms. However, I can tell you that the people behind this project are very intelligent and very serious. And, of course a little crazy..but you have to be a little bit to attempt something on this magnitude...right?

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. Before committing to building a new product in someone else's framework, I'd want to know about all such weird decisions, and about why they are that way. Maybe Urbit's principles are compatible with the way you think about every possible aspect of how your system will interact with any of its users ever (since that's what you're buying into when you literally adopt an entirely new network to build against and deploy on). But maybe not!

Most framework designs coercively project opinions about whether the efficiency of register-sized addresses are worth the flexibility tradeoff, or whether it should be easier to define new URL patterns versus making it easier to dispatch the full complement of HTTP verbs, or whether closures are first-class or sum types are worth the complexity. Not a lot of programming environments ask us to determine what double-digit percentage of the world's population is too irresponsible to deserve an address. Again: their words (almost; I changed the order).

I'm trying to be careful not to use loaded terms like the f-word you just used, by the way. What I think about Urbit's founder is not necessarily the same as what conclusions I'd draw about this particular system, which is, I think, fatally flawed on its own demerits.

People are very strongly repulsed by what they perceive as excessive novelty: Lisp parentheses, Haskell monads, Urbit jargon. Maybe because it comes off as antisocial. I somehow really enjoy all those things.