[aeontech]

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 there's nothing, and I am reluctant to commit to the time required to find out for myself. It doesn't help that people who spend time in that land seem to all forget how to speak about it except in the terms of Urbit, unable to translate it for laypeople. I suppose that's true about any highly technical subject though.

[0]: https://en.wikipedia.org/wiki/Mimsy_Were_the_Borogoves

[1]: https://books.google.com/books?id=yPVbDv5DqkoC&lpg=PA181&dq=...

[chc4]

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 an append-only log of all events that platform handles being the most important parts.

Right now you can build decentralized apps like Mastodon, except they 1) take hours to setup a node, along with having to know arcane Linuz sysadmining 2) aren't actually decentralized, but federated. Urbit wants to make it easy to setup your own server, which runs as a node for all these decentralized apps (instant messaging, Twitter, etc.), along with be useful for server-y things like aggregate APIs (email, Facebook).

There's not actually anything that amazing about Urbit once you figure it out. It just wants everyone to be able to run their own server, and make it easy to build decentralized apps that talk to other Urbit servers. The important part is that somehow, they saw how bad trying to do that currently is, said "let's rewrite everything", /and then did/. It's like reading about Oberon or Plan9/Inferno.

Edit: This post is probably the worst introduction to Urbit imaginable. It basically is a technical spec for bootstrapping a PKI over Ethereum, and you should expect about as much as if you got linked something from BitTorrent about that. It assumes domain knowledge from both Urbit and Ethereum (both of which are terrible to explain), and /doesn't actually matter/ for most people interested in Urbit. Please don't use this as the benchmark for "babies first urbit intro".

[imtringued]

Federated systems are the middle ground between full centralisation (one provider) and decentralisation (everyone is a provider). They allow users to choose between the two depending on what they actually want.

With decentralised systems you are forced to run all computation and store all data yourself. The average user isn't going to buy their own server and run it 24/7. That's incredibly wasteful. Even in the best case scenario they will just get an "urbit server" from AWS or somewhere else.

The problem with centralised services isn't that they are centralised. The problem is that you are locked-in to a specific provider. You can't send messages to your facebook friends from your freedom respecting gnu social server or whatever. You have to install a dozen apps (facebook, whatsapp, telegram, etc) to talk with all your friends.

[chc4]

That's pretty much the end goal of Urbit, though. It doesn't want everyone running a server in their closet, just a server in general which includes on AWS. The point is that it should be easy enough to control that your mother can do it: pay eth, click a button, get urbit running in the cloud should be the final flow.

Having a common platform, all using the same RPC and identity and network layer, allows for the removal of lock-in across different Urbit apps.

And since it's your own server, you /can/ send to Facebook friends from your Urbit clone just by hitting the API endpoints. Migrating to an Urbit clone of a centralized service should be gradual to fight back against network effects: first make a UI frontend for the service from Urbit, then make it mirror content on Urbit back, and gradually transition over. GNU Social does this with Twitter, but kinda badly, and can be locked out from one central API token because everyone has to go though their node.

[tptacek]

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 only by incrementing a number until it's 1 less than the current number. All of these concepts have their own weird names; for instance, the constant-time version of "decrement" (this is a programming environment that goes out of its way to achieve constant-time decrement†) is an example of a "jet", where a jet is apparently a non-native implementation of an algorithm that can be expressed but not efficiently on the VM that they've chosen to build their entire system on and it just gets weirder and weirder from there.

You don't have to memorize the new names they've come up with for most of the ASCII punctuation characters, like "gal", "gar", and "hax" for "<", ">", and "#", "but it helps". A normal engineer's reaction to a system that tells it that it will help to remember a new name for the pound sign is to ask "Why? What fresh horror lurks in the deeper meaning of your new name for the percent sign? And why won't you tell me before I commit to this system?"

Stuff like that would be bad enough, but the founders ideological views are also infused into the system, and those views are not mainstream distributed systems engineering views. For instance: 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.

I agree that the best way to explain this system while encouraging people to engage with it is to distill it down to anodyne concepts and then sprinkle "decentralization" on top. But of course, this system isn't really that. From the proteins of its cell membranes to the DNA in its nucleus, this is a system that coercively projects the idiosyncrasies of its founders into everything it comes in contact with. It's decentralized and free in the sort of way its founders would explain with a 3000 word paper that invented 50 new terms in its abstract.

People confused about Urbit are probably not confused about the value of serverless computing or of overlay networks. Those are pretty straightforward concepts we can all get our heads around. There is something deeper that is challenging about Urbit.

† Rather than, you know, just deciding to have it.

[chc4]

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.

[tptacek]

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.

[chc4]

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.

[ineptech]

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

[tptacek]

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.

[njarboe]

4,294,967,296 is the number of planets which is a much more than 4 million. Think about a planet as a piece of land more than a phone number. How many people on earth own a piece of land? And when will that reach 4 billion?

Also, if Urbit becomes popular other groups will start similar systems and they will be able to interact.

[grzm]

I believe the 4 million in your parent's comment is a typo. Further along in the same comment they refer to 4^32 and down thread they refer to 4 billion.

[yebyen]

Like IPv4, it's a theoretical maximum that will be hard to reach because the number of allocations are divided up into blocks... Universe(Galaxy / Star / Planet / Moon) are the top 64 bits of the address space, so there is a 2^32 space for planets, and the top 8 bits of each segment followed by all zeros would refer to a (Galaxy / Star) of which each are also addressable, single machines.

So yeah, 2^32 planets (minus 65536 stars (minus 256 galaxies)) and each planet has a plot of "land" that is 2^32 wide to allocate moons out of. What happens if we run out of planets? Then people will start living on moons, simple. Or comets (the remaining 64 bits in the 128-bit address space are for comets, which are not comparable to land or homesteads.)

[adiabatty]

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

[ubernostrum]

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.

[adiabatty]

Yeah, 2^32 was _clearly_ chosen based on what makes for nice, round numbers in binary, not based on reasonable population and cell-phone-use projections.

On the other hand, Urbit might never become popular enough for this sort of thing to really matter. We're at about 7 billion people now and the second derivative of the world population is negative, so it should level off at some point. If only 5% of 20 billion people care enough about this sort of thing to actually run a planet, then that'll be only 1 billion people, or a quarter of Urbit's 4-billion address space. 5% doesn't seem unreasonably low to me, either; app.net probably didn't even get 0.5% of Twitter's user count.

[ubernostrum]

Urbit might never become popular enough for this sort of thing to really matter.

And decisions like this might be a part of why it never becomes popular. Elsewhere in the thread people are suggesting that, say, children don't need their own "planet" or whatever it's called, and that they could be one per family and still service the whole world. But that bakes in an awful lot of assumptions about culturally-specific ideas of family and stability of family units. Granted, I think those are culturally-specific ideas Moldbug would love to impose on the world if he could, but this is why people keep saying that even the technical decisions in Urbit are pushing specific political positions of his.

Also, at this point anyone who deliberately designs an address space to be too small to handle already-existing popular things is probably not making sound long-term technical decisions to begin with.

[adiabatty]

> You don't have to memorize the new names they've come up with for most of the ASCII punctuation characters, like "gal", "gar", and "hax" for "<", ">", and "#", "but it helps". A normal engineer's reaction to a system that tells it that it will help to remember a new name for the pound sign is to ask "Why? What fresh horror lurks in the deeper meaning of your new name for the percent sign? And why won't you tell me before I commit to this system?"

Odd, I saw the rationale early on, when I was just reading the documentation for Urbit. If you've ever seen Hoon code, you'll notice it has a lot of punctuation in it. Have a look at tumblr.hoon[0]. If you want to speak with fellow Hoon programmers in person and communicate fluidly, it's nice to have a compact, standardized-within-Urbit way of saying things like "$%"[1] out loud.

Now, at this point you're probably wondering "why would they have names that are all punctuation?". As far as I can tell, this keeps the identifiers short and of uniform length. From what I understand, one of the problems that they're trying to solve is that single-assignment code in, say, Lisp tends to flow down and to the right. They're trying to limit rightward visual creep, as I understand it.

Now, I'm not convinced that focusing on standard-library-identifier length is a good idea. Early C linkers could only handle function names that were six characters or shorter, and constraints like the ones in Hoon's standard library sound similarly arbitrary and likely to lead to unintuitive names like "strchr".

[0]: https://github.com/urbit/examples/blob/master/app/tumblr.hoo...

[1]: buccen, which I pronounce as "buck sen". It's used for making tagged unions, which reminds me of Erlang/Elixir {:ok, Value}/{:error, Reason} value-passing style.

[occultist_throw]

> You don't have to memorize the new names they've come up with for most of the ASCII punctuation characters, like "gal", "gar", and "hax" for "<", ">", and "#", "but it helps". A normal engineer's reaction to a system that tells it that it will help to remember a new name for the pound sign is to ask "Why? What fresh horror lurks in the deeper meaning of your new name for the percent sign? And why won't you tell me before I commit to this system?"

Speaking of that.. I looked again at the reference documentation and the "hello world" (Fizzbuzz). It feels like I'm playing a game of Magic the Gathering on another world, with different physics and vocalizations I cannot do.

https://urbit.org/docs/hoon/reference/

     {$book p/(list {{aura @} moss})}: mold which recognizes a union tagged by head atom.
     {$lamb p/moss q/moss}: mold which normalizes to an example gate.
     {$port p/moss q/seed}: form an iron gate.
     {$gill p/moss q/seed}: form a gill, a wet one-armed core with sample.
     {$gasp p/seed q/seed}: form a gate with burnt sample.

Uhm.. What? I know I'm reading words. But part of it makes me feel like Im also in Game of Thrones. Iron Gate, wet one-armed core, and a burnt sample?

And their demo (Fizzbuzz) is just as illegible. https://urbit.org/docs/hoon/demo/ . I get programming. I know there's concepts in different langs that need understood. But one thing I know is that the demo should be easy to dip your toes in.

And it starts. "Tape" is really a string. "Home Desk" -Im guessing its the urbit home directory for your user? Urbit Pier? No bloody clue. But Im supposed to copy the file (oh wait, is file even used, or maybe its joobpflep?) to it. But at least the "Urbit Dojo" is the shell.

[Fang_]

The reference docs honestly aren't the best place to start when learning Hoon, as backwards as that may sound. I've found the tutorial docs[0] to be much more helpful when first exploring Urbit, and there's a fair amount of good community documentation listed on the docs page[1] as well.

[0]: https://urbit.org/docs/arvo/

[1]: https://urbit.org/docs/

[timClicks]

Also a decent portion of that address space is also reserved by an individual who doesn't believe that humans are equal. I think he just wants to be king of his own universe. The technology of Urbit is neat, but I find the politics abhorrent.

[Avshalom]

>wants to

haven't "actually succeeded", haven't "shown any real movement towards", but "wants to".

And that's the problem. Years ago it was funny: "look at our ludicrous documentation isn't it funny that we claim this is a real thing", now it's just more assholes boiling the seas.

[apo]

Right now you can build decentralized apps like Mastodon, except they 1) take hours to setup a node, along with having to know arcane Linuz sysadmining 2) aren't actually decentralized, but federated. Urbit wants to make it easy to setup your own server, which runs as a node for all these decentralized apps (instant messaging, Twitter, etc.), along with be useful for server-y things like aggregate APIs (email, Facebook).

This sounds vaguely intriguing. But the problem that most Ethereum projects have is that they put the solution and technology before the problem. Half the time I don't even know what I'm looking at or if it's worth looking further.

Can you restate the problem that Urbit solves in the simplest terms you can think of?

[chc4]

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 still means you lose all your content and new players on the block have to bootstrap up an entire new corpus of content and userbase.

Instead, you could use an Urbit app that does Reddit-ish things, and when a developer makes a Twitter alternative the userbase already exists. Because each user hosts their own content, developers don't have to host servers, and migrating to another Reddit-like app is really just switching to a different UI frontend. Whats more, since it's /your server/, you can integrate with existing 3rd parties: mirror all your posts to actual-Twitter or use Urbit as a client, and gradually migrate over to the decentralized platform without having to overcome market effects.

[tptacek]

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

[chc4]

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/patch system, an identitt system, forces apps (and the e tire platform) to be purely functional for easy saving and crash tolerance, and other fun things. It's like shitty OSX - it has a /vision/, even if some parts don't make sense.

[tptacek]

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?

You get the irony of complaining about how every competing design has had to "reinvent several wheels", right? The system you're advocating reinvented ASCII.

[wmf]

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.

[defen]

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/

[likeclockwork]

Well, there's a question of who I want engineering my social reality in addition.

I think there's quite a lot of selection going on and the criteria are much broader than just just "the smartest, most dedicated" engineers.

[ineptech]

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

[sanxiyn]

I am very interested to hear about other competing P2P overlay network with embeddable VM of similar maturity.

[tptacek]

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

[olympus]

Urbit has been around for a few years and has done nothing to clear up the confusion around it. I think at this point it is safe to say that any claims of Urbit being a revolutionary form of computing are hogwash.

This is probably similar to how Scientology got started. Nobody really believes in it, but are too afraid to strongly denounce it because they don't want to be the one who "doesn't get it." So they all just go along and get sucked further along down the rabbit hole. The difference between Scientology and Urbit is that Scientology managed to rope in a few celebrities and gained some sustaining mass. If Urbit wants to make it big, they should pay Zuckerberg and Musk to evangelize it, and then everyone will be falling all over themselves to be part of it.

[rhencke]

That's... a baffling claim.

Urbit is well documented, in easy-to-understand terminology, from low level, to high level: https://urbit.org/docs/ https://urbit.org/docs/nock/definition/ https://urbit.org/docs/hoon/concepts/

The code is open source, under MIT license: https://github.com/urbit/urbit

Heck, urbit even shows up to Hacker News semi-regularly: https://news.ycombinator.com/threads?id=urbit

What backs your claim they have done nothing to clear up the confusion about it?

[olympus]

My main claim was that Urbit isn't revolutionary. It is really just a Unix server and programming language. However, in an attempt to seem more sophisticated they invented new words so that nobody could figure out what it was. Urbit is purposely obtuse in their terminology, when they really could just use words that programmers already know and use. Here's some examples from the documentation you linked:

"A value in Hoon is called a noun" - or you could just call it a value.

"A gate is a Hoon function" - or you could just call it a function.

"A core has no exact equivalent in conventional languages, but the closest equivalent is an object. An object has methods; a core has functionally computed attributes (arms). An arm that produces a gate is the Hoon equivalent of a conventional method;" - or you could just say that objects in Hoon (the language) can have methods and attributes, and you would never need to invent the core/arm/gate terminology.

They try to give themselves an out by saying stuff like "Hoon has concepts like all these abstractions, but they remain false cognates." When you dig into it, the only unique things are the words. It's like children trying to come up with a code- "instead of door we'll say blorp and instead of close we'll say bleep. Now bleep the blorp before we continue inventing our code.

[pcmonk]

> "A value in Hoon is called a noun" - or you could just call it a value.

A "value" sounds like an abstract concept. A noun is one of two things: a natural number or a pair of nouns. Calling it a "value" makes it sound much more abstract than it is.

> "A core has no exact equivalent in conventional languages, but the closest equivalent is an object. An object has methods; a core has functionally computed attributes (arms). An arm that produces a gate is the Hoon equivalent of a conventional method;" - or you could just say that objects in Hoon (the language) can have methods and attributes, and you would never need to invent the core/arm/gate terminology.

A core is not an object in any meaningful sense. You can create stuff that looks like objects with them, but they're used for a lot more than that. For example, all gates/functions are cores, but there's no sense in which you'd call those "objects".

> They try to give themselves an out by saying stuff like "Hoon has concepts like all these abstractions, but they remain false cognates." When you dig into it, the only unique things are the words. It's like children trying to come up with a code- "instead of door we'll say blorp and instead of close we'll say bleep. Now bleep the blorp before we continue inventing our code.

The thing about revolutionary concepts is that their underlying principles are different than what you're used to, so if they look similar on the surface, you're lulled into thinking they're basically the same. But anyone who's put significant effort into programming in Urbit will tell you the system is fundamentally different. Not in the sense of "you could never understand what's going on here"; but rather, "we made these few different design decisions in the beginning, and that permeates everything".

[tptacek]

For example, all gates/functions are cores, but there's no sense in which you'd call those "objects".

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?

We could productively stay focused on just this one example, and see if there's a better reason for Urbit to call its objects "cores" and its methods or attached functions or computed attributes "arms".

[pcmonk]

> 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 attributes, and no methods. It's just a way of encapsulating a formula (VM assembly expression) in a way that's convenient to call with formulas. It uses the the "core" pattern because it's convenient.

"Arm" is a pretty specific term that refers to the way an "element" of a core is represented in the core. When you want to map a particular use of cores to its underlying representation in the "core" pattern, you want to be able to talk about specific data structures.

In general, Urbit errs on the sides of giving names to concepts that could only otherwise be described in multiple sentences. Most projects just don't give names to those concepts. Urbit needs better human descriptions of its concepts, but using traditional names for them would be misleading.

[jerkstate]

> A noun is one of two things: a natural number or a pair of nouns

To most of us, a "noun" is a person, place, thing, idea, or feeling.

I started replying to the other stuff you were saying, but I started getting this feeling like you're in on the joke and I'm not.

[pcmonk]

To most of us an "object" is something you can touch. We overload these terms all the time.

[aboodman]

> A core is not an object in any meaningful sense. You can create stuff that looks like objects with them, but they're used for a lot more than that. For example, all gates/functions are cores, but there's no sense in which you'd call those "objects".

In many, many languages, a function is also an object.

[han-sel]

"It is really just a Unix server and programming language."

You should read https://urbit.org/posts/overview/

The whole reason Urbit exists is that Unix + the internet is broken and needs a complete overhaul

Re: the different names, there are slight differences between gates and functions, but I agree they're not important enough to merit the change in name. But hey, it takes a purist to spend 15 years rewriting the whole stack from scratch!

[occultist_throw]

Yep. Unix and Linux are broken.

So instead, I should load up Urbit, locate on a planet, spin up a garglemitz on the spitzenspeil with the hoon japing over the nock.

If you add Xenu, Body Thetans, e-meters, I think you might be on to something!

--------------------

No seriously. There are wrong things with the monolothic kernel as well as microkernels. Theyre design tradeoffs. But none of the existing, well established methods throw away the language of computing of the last 60 years. Some tech stacks may add a new type, but they are able to describe why a new classification is needed, and how it fits iin the existing model.

What Urbit is doing, is polluting the namespace by turning existing nomenclature into some sort of technofreakish cult. Up is now down. Down is now blarbbliboop. And anyone questioning the "Master" is berated and denigrated by means of 'lack of intelligence'. You all should be defending your way and means.

Because in my eyes, you all are wrong until you can start integrating standard and normal nomenclature - because it's hiding something unsavory.

[jacobush]

Best comment so far - you put words on what disturbs me so much about Urbit. It takes the technobabble to a whole new level. I don't care if they succeed, I want no part of it.

[occultist_throw]

Please identify one concrete computing action that I cannot do with Linux/Windows/Mac that Urbit enables.

In other words, what is Urbit's "Killer Feature"? Cause I'm not seeing one.

And a runner up question: Is Urbit still heavily dependent on unreleased root node code? In other words, is this distributed computing just a load of hype covering over a overly complicated star topology?

[han-sel]

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?

[jacknoble]

>However, recently, I finally heard the first solution which felt like the completely right solution to me, and I believe they're pursuing it.

What's that?

[nyolfen]

hazarding a guess: a secure social integration layer for cryptocurrency?

now that i'm thinking about it, this has to be the answer

[pcmonk]

> Is Urbit still heavily dependent on unreleased root node code? In other words, is this distributed computing just a load of hype covering over a overly complicated star topology?

Urbit has always been fully open source as far as I know (at least since 2013). It is true that Tlon runs some of the galaxies and stars that most people use, but that's just because other galaxy owners haven't decided it's worth it to do so (because Tlon is doing a great job of it).

[occultist_throw]

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.

[han-sel]

See my comment above.

[imtringued]

That's not decentralisation. That's federation.

[rhencke]

(You might have hit reply on the wrong post? This is all stuff orthogonal to my point.)

[bitwize]

Others, including myself, have noticed this too and it reminds us of something else a little closer to home: namely, what happens to Scientologists and the like after they've been in the cult a while. Even the Scientologists who later leave still think in terms of engrams and body thetans.

I think Curtis Yarvin is a master huckster and wordsmith, but near as I can tell what's good about Urbit isn't original and what's original isn't very good. The central concept is basically Java's "write once, run anywhere" concept from the 90s. Remember that? It wasn't just about applets; applets were only the beginning. With "mobile code" that could run on any device, Java was going to make existing operating systems obsolete and finally bury Microsoft.

Sound familiar?

Curtis adds sizzle to the steak by mixing in ideas Hackernews people will find appealing -- functional programming, blockchain, distributed computing -- and finally he plays the same semantic shellgame with his words he plays with his political essays, to convince you that the horrible political views he has aren't so horrible. Except this time it's to convince you that Urbit is more than a reimplementation of interesting ideas from the past, some of which failed massively.

Why? Well, the fact that he is selling "virtual real estate" in his new internet that's totally going to change everything real soon now might be a clue.

[CryptoPunk]

>>finally he plays the same semantic shellgame with his words he plays with his political essays, to convince you that the horrible political views he has aren't so horrible.

I suggest you leave your ideological biases out of your assessment of Urbit the technology. We all have our political beliefs - mine are hard libertarian, yours are hard feminist/leftist - but hopefully we can put those aside when assessing technology.

[fusiongyro]

It's interesting that you want them left out and then, as an aside, bring the parent's into it.

[drngdds]

Are you implying that anyone who hates neoreaction is a hardcore feminist/leftist or is there context I'm missing?

[CryptoPunk]

No I'm not implying that. I'm describing the OP's political beliefs, based on his previous comments.

[dogecoinbase]

As tptacek pointed out upthread, his hateful ideology is deeply ingrained in the structure of the technology. In fact, no technology is free of its creator's ideology! The argument that one should "put [ideological biases] aside when assessing technology" is, in the most charitable case, naive attachment to the status quo.

[bitwize]

I suggest you read the entire comment before replying.

[occultist_throw]

-- and finally he plays the same semantic shellgame with his words he plays with his political essays, to convince you that the horrible political views he has aren't so horrible.

I mean.. what's not to like about Nazism and eugenics?

(I wish I could attribute a sarcasm tag, but Go look up Mencius Moldbug and read for yourself.)

[norswap]

It's a clean state reinvention of the computing environment (it's software component at least).

That by itself might be a good idea, but if you're going to sell people on your project, you need to give some rationale / objective for your projects. And there, Urbit doesn't do well. There is some talk of decentralization, but it's not clear what the goals are.

Like many people, I find the way it's being done slightly confusing (the names, etc), but it is being done. At this point, I would just lump it in the stack of intellectual curiosities, right next to TempleOS. It might turn into something yet, but I'm not holding my breath.

[pcmoore]

Take a look at https://github.com/tibru/tibru for an explanation of why the underlying technology is poorly chosen and how systems of this type don't need to be esoteric

[dropit_sphere]

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