7 ms·

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 platf

by chc4 9y ago

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

apo 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      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.
Avshalom 9y ago
>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.
tptacek 9y ago
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.
imtringued 9y ago
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 9y ago
  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.

by chc4 9y ago

apo 9y ago

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 9y ago
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 9y ago
  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 9y ago
    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.

Avshalom 9y ago

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

tptacek 9y ago

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.

imtringued 9y ago

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 9y ago
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.