
Urbit: The Internet failed (slides and video) - urbit
http://personal-clouds.org/wiki/Events:SF2013-09-25
======
mbrubeck
The thing that got me interested in Urbit when it was first announced back in
2010 was reading Van Jacobson's "Networking Named Content" paper [1] and
related work from PARC, referenced in this blog post [2]. As someone who has
spent 15 years now working on web development, browser development, and web
standards, I feel the Internet really needs some form of "named data"
networking as its next big step. I don't know if Urbit is the way it's going
to happen, but it'll happen somehow. Maybe we'll evolve browsers and HTTP into
a named data network instead. (On the one hand, it would be orders of
magnitude easier than building an entire new model of computing from
scratch... on the other hand, you don't get to throw out the whole ball of mud
if you just keep building on top of it.)

Anyway, I encourage everyone to read the Van Jacobson paper or watch the tech
talk. It points out some assumptions that are so baked into our network
architectures that I had never really thought about them. And it gives some
context for these slides' claim that "the internet has failed," by pointing to
a working alternate system that's a better fit for some common cases. The link
from the Urbit blog to the Van Jacobson talk is broken since Google Video was
shut down, but you can now find it on YouTube [3].

[1] [http://www.parc.com/publication/2318/networking-named-
conten...](http://www.parc.com/publication/2318/networking-named-content.html)

[2] [http://moronlab.blogspot.com/2010/01/urbit-functional-
progra...](http://moronlab.blogspot.com/2010/01/urbit-functional-programming-
from.html)

[3]
[http://www.youtube.com/watch?v=oCZMoY3q2uM](http://www.youtube.com/watch?v=oCZMoY3q2uM)

~~~
pdonis
_the Internet really needs some form of "named data" networking_

Don't we already have that? URIs are names for data. I had this same reaction
when I read about "Content-Centric Networking" back when it first came out.

 _Maybe we 'll evolve browsers and HTTP into a named data network_

They already are. We don't need to evolve them so much as _use_ them in the
way HTTP was originally designed to be used: you retrieve and (if you have the
privileges) act on data by addressing appropriate HTTP verbs and payloads to
its URI.

~~~
api
The real problem is that I can't host a web page. I have to host it in the
cloud. That's because there is no (easy) way for you to connect to my
computer.

~~~
urbit
Here, I think, we disagree, because I think your primary computer (ie, your
personal state and main applications) _should_ be in the cloud.

(But not for everyone - just for everyone who doesn't have powerful enemies.
That's why it's essential to abstract across cloud hosting and personal
hosting. If people who have powerful enemies and need to host at home have the
same experience on the network as most people (who don't have powerful
enemies), except that their enemies can't own them in some data center, they
experience a kind of "herd immunity." Everyone doesn't need privacy against
powerful enemies - everyone just needs to be able to obtain privacy, without
deleting their digital lives, if they find out they have powerful enemies.)

~~~
api
I've thought for a long time that you could have it both ways. If it's hard to
completely decentralize networks (e.g. meshnets), then why not decentralize
the computer?

I've got some ideas for an execution environment based on HTML5 and
eventually-consistent cryptography-based distributed databases, but they're
only ideas. It'd be a much bigger bite to bite off than ZeroTier One, and I
don't have that kind of time/money right now.

The overall idea is to have a virtual cryptographically-defined system
boundary that could be loaded -- invoked -- on any hardware running the
appropriate VM.

~~~
urbit
I don't know, man. I really try very hard to make sure there's no one between
me and outright insanity. But sometimes I wish there was... are you talking
about homomorphic encryption? I'm not sure I'd hold my breath waiting for a
practical homomorphic VM.

------
platz
Around the same time I heard of Urbit, I was listening to Don Stewart talk on
a podcast (Haskell Cast episode #2) about using Haskell to avoid running an
entire OS in the cloud; only the necessary code to perform the necessary
operations to integrate with other systems was necessary.

He was using Xen to run a GHC process which he describes as a "microkernel
environment".

Xen + Language Runtime (ghc) + user functions = the whole stack, and this
boots in milliseconds, using only 1 or 2 meg of memory.

What's interesting is that this is a technique that he's using in development
_today_.

I didn't read all the Urbit documentation, but the concepts between Don
Stewart's approach and Urbit seem to share some similarities with eliminating
OS bloat.

Some folks have claimed Urbit is as much art at practical, but Don is already
doing practical things like this; unless I'm mistaken about what Urbit is
about (I'm sure it does a lot of other things differently as well).

~~~
urbit
I can argue with Haskell but I would never argue with teh awesome that is Don
Stewart.

Urbit runs on Linux right now - but you're right, it would be very cool to run
directly on the hypervisor, and it's totally possible for a self-contained
system like this one. Personally I think Haskell never should have tried to be
a language for producing Unix system calls - the impedance mismatch between FP
and imperative OS is just too great.

~~~
asciilifeform
I'd go one step further and argue that: no sane language should be a language
for producing Unix system calls.

The impedance mismatch between sanity and imperative OS (and imperative
hardware) is too great.

------
urbit
A direct link to the video:
[http://www.youtube.com/watch?v=6S8JFoT6BEM](http://www.youtube.com/watch?v=6S8JFoT6BEM)

~~~
brian_cloutier
Near the end of the talk someone asks you how to delete data if the state of
the machine is just a function of the network packets it has received.

I have to admit I didn't really understand your answer:

> [When you try to forget data] you're making a subset of this computer that
> will not compute when it tries to use this information.

Could you elaborate a little on what that means, and how you'd apply it in
practice. If I wanted to not just make data inaccessible but actually purge it
from my machine, how would I do so?

~~~
urbit
So, you're doing exactly the same thing when you press ^C on an event - what
happens is, the event fails to compute. It doesn't go into your log. It
doesn't affect your state. It never happened. Packet caused an infinite loop?
You never got that packet. And so on.

If an event depends on data that's been deleted, that event never happened.
But, at the Unix level (which can generate any events it wants), we can
generate _another_ event which reports the error. So it's not like things fall
silently down the hole, either. (For the same reason, you can also get the
stack trace of the infinite loop that was interrupted by your ^C.)

------
api
[http://blog.zerotier.com/post/58157836374/op-ed-internet-
cen...](http://blog.zerotier.com/post/58157836374/op-ed-internet-
centralization-is-not-a-conspiracy)

~~~
urbit
ZeroTier looks awesome and that's a great post too.

I'd dispute the point about the CAP theorem slightly. Thing is, _your data_ \-
Little Data - is naturally centralized. It doesn't have to be centralized in
the same center as everyone else's data though! Then it becomes Big Data,
where it's having this giant privacy-violating orgy with everyone else's data
all day long.

The amount of traffic that your own Little Data has to serve, unless you're a
celebrity in which case you can pay for serious hosting, is never going to
require a giant cluster of replicated servers. So CAP just isn't that much of
an issue.

~~~
api
It's been obvious to me for a long time that the firewall and NAT are the
primary causes of Internet centralization. I think they're a far greater
factor than the CAP theorem or protocol / programming model difficulties. For
whatever reason, I seem unable to get other people to see what I see here.
Most people seem to just not get it.

I mean seriously... if nodes cannot easily contact each other horizontally
then _of course_ everything evolves toward a super-centralized model with
large central groups of nodes acting as intermediaries. What part of that is
hard to understand?!?

Thanks for the props. A new alpha release of ZeroTier is coming soon, and then
it's going into beta with downloadable installers and other nice things. ZT1
is _not_ going to decentralize the 'net, but it does create a lab where people
can play with such things. (And it's an interesting VPN alternative for
decentralized orgs too.)

~~~
urbit
I would argue that spam is an even bigger one.

Basically, the Internet has spam because identity isn't a limited resource. IP
addresses are kind of a limited resource, but they're not really the property
of the person using/abusing them, so a blacklist doesn't inflict precise
targeted damage, can't be made too draconian, and is easy to evade in lots of
ways.

And everything above the IP level is unlimited. If there's an unlimited supply
of identities, you can't tell the difference between a new customer and an old
enemy. You want the first to have positive default reputation and the second
to have infinite negative reputation.

People in the personal cloud community often point to email as proof that spam
can be solved. Yes - but spam was solved in email because email already
existed in an spam-free Internet. On the Internet we have, there's a much
easier solution to the fact that any new protocol which is successful starts
to attract spammers. The solution is: stop using the protocol. Google turned
off XMPP federation for this very reason.

Basically in an orc-infested environment, you can't have your own cute little
bungalow in the cloud. You gotta have an apartment in a giant fortified castle
in the cloud.

Having a limited supply of identities, in which identities are (a) property
and (b) property you control cryptographically (Bitcoin style, "allodial
title"), makes it easy to make spamming not pay, once the price of an identity
is greater than the profit a spammer can earn by burning it. And it does not
require a central governance authority, or even a central reputation
authority. (Reputation authorities shouldn't be built into any system, because
if they abuse their own reputations the consequences are insanely dire.)

NAT is a problem, but there are lots of ways to tunnel around it. Which all
suck, of course, but...

~~~
api
NAT can be tunneled around, but there's two problems with that:

(1) Every NAT traversal protocol is unique, so there is no interoperability
between different apps. The power of IP lies in the fact that it's a lingua
franca-- anything can open TCP or send UDP. But anything cannot speak
BitTorrent-DHT or Skype or whatever. So there's no potential for exponential
growth in capability by tying disparate things together. Firewalls and NAT
kill protocol interoperability.

(2) NAT traversal is hard. I know cause I just did it. It's a pain in the
rear, and I'm still going to have to build port 80 HTTP tunneling into
ZeroTier for that 0.1% of users who cannot use UDP or tunnel through their
NAT. So you have to implement NAT-t + a proxy service for everything.

As far as spam goes, you're right. I should have mentioned that. But there are
lots of strategies for dealing with spam. Why can't we have a few million
small castles instead of one big one, for example? BBSes each had sysops who
would kick off abusive users. There are also cryptographic things like hash-
cash, Bitcoin economies, trust matrices, etc. These are complex but if we
could engineer something good here then it could eventually be packaged into a
friendly library that programmers could use without having to understand all
the devilish details.

The fact is that we did build a decentralized many-to-many Internet. Then we
broke it with firewalls and NAT.

~~~
urbit
Well, dude, I just did NAT traversal too but I have a funny feeling you did it
better.

Prediction: one day my protocol will run on top of yours. Rebuilding teh
Internets, one layer at a time...

~~~
api
Your protocol doesn't have to run on top of mine. Just build it to use IP and
it can run over ZT1's virtual networks or plain vanilla IP or cjdns or
whatever.

With IPv6 every device could have a first-order IP. We just need to get people
to give up middle-box firewalls. That and anyone who attempts to build IPv6
NAT should be placed on trial for crimes against humanity, with the punishment
being impalement followed by incineration atop a pyre.

NAT is the devil incarnate. Virtually all evils in the world -- from child
abuse to war -- can safely be blamed on NAT.

~~~
wmf
Yeah, I was kinda wondering why aliens don't use IPv6 and let Teredo or
whatever worry about NAT traversal. I heard that IPv6 makes it much harder for
Jeff Goldblum to upload the virus.

~~~
api
joke comprehension error at 0x93: core dumped

------
sz4kerto
It's a shame that as a developer, I need to see these stuff (like this Urbit
fantasy) to remind myself about why I really started to tinker with computers.

~~~
urbit
Fantasy? Laugh while you can, monkey-boy! :-)

------
mkhalil
Initially by the title, I thought this was going to be another overly-dramatic
simplification of problem article. Turns out to be a good one. I was thinking
about this a lot lately.

------
Gravityloss
Is the link right?

~~~
urbit
Yes. It's the second talk on the list.

The other talks are great too! Watch them all!

