4 ms·

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 w

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-content.html http://www.parc.com/publication/2318/networking-named-conten... [2] http://moronlab.blogspot.com/2010/01/urbit-functional-programming-from.html http://moronlab.blogspot.com/2010/01/urbit-functional-progra... [3] http://www.youtube.com/watch?v=oCZMoY3q2uM http://www.youtube.com/watch?v=oCZMoY3q2uM

pdonis 13y ago
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.
- urbit 13y ago
  URIs are names for data - but they're not referentially transparent names. Basically, the inspiration for URIs is Unix filesystems, whereas it should have been Git repositories. It's easy to build mutable resources on top of an immutable namespace. Just put the date, change number, or label, in the name. But once you stop being referentially transparent, you can never recover that virginity. There was sort of an attempt to make Cache-Control headers work in HTTP, but they really don't (I speak as a recovering browser developer), and there's just no substitute for everything having an infinite lifetime.
  - pdonis 13y ago
    It's easy to build mutable resources on top of an immutable namespace. Just put the date, change number, or label, in the name. But git repositories don't work this way. Every object in a Git repo is immutable; when I pull a new commit from somewhere, it looks to me like the files in my working copy magically change to the new versions (i.e., that they are mutable), but what's actually happening in the repo is that a set of new immutable objects are added; nothing that was there already changes. This sort of scheme can just as easily be built using URIs (or, for that matter, Unix filenames), so I don't see what the big deal is. You have some URIs (analogous to the filenames in my git working copy) that appear to be mutable resources, but they are implemented on top of other URIs (analogous to the hashes of commits in the git repo) that are immutable resources. All this can be done now, using existing HTTP.
    - urbit 13y ago
      Aren't we agreeing vehemently? The problem is when you try to build immutable resources on top of a mutable namespace. How exactly do you know they're immutable? By what convention? What happens to your code if they mutate? Even worse, using a mutable-namespace for immutable bindings, you have two immutable systems talking to each other through a mutable pipe. First the kind of transformation you describe has to be applied, then it has to be reversed. It's a recipe for madness.
      - pdonis 13y ago
- api 13y ago
  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 13y ago
    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 13y ago
      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 13y ago
        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.
  - anonymous 13y ago
    > That's because there is no (easy) way for you to connect to my computer. Er.. just give me your IP and we're good to go, no? Even easier if you register a name for free on dyndns (for instance) and then give me something like mshaxxorette.homelinux.org.
- mbrubeck 13y ago
  > URIs are names for data. Yes, they are, essentially. But the difference is that an HTTP URI is not a name for a piece of data -- instead it is a set of instructions that say "connect to this network endpoint and send them this string; in return you will get some data." The data may be different every time someone follows these steps to dereference the URI. A single URI does not name a single piece of data. In a URI scheme where the URIs really name the data (rather than an address for finding data), you can get away from TCP-style point-to-point networking in cases where it makes sense, like in one-to-many broadcasts. The paper I linked [1] specifically compares PARC's content-centric network protocol against TCP+HTTP in these scenarios. And it's not just one-to-many that can benefit; see also the VoCCN paper [2] for a very different use case. I agree that you could (and should) still use URIs for data in your content-centric network, which is why I think we could evolve the web platform to use CCN without any major upheaval. You just need to add a new URI scheme besides http and https. For the web, the changes would not be at the application layer but at lower layers like TCP and routing. But more importantly, CCN would help enable new types of platforms (like Urbit?) that do not look like the web. [1] http://conferences.sigcomm.org/co-next/2009/papers/Jacobson.pdf http://conferences.sigcomm.org/co-next/2009/papers/Jacobson.... [2] http://www.parc.com/publication/2319/voccn.html http://www.parc.com/publication/2319/voccn.html
  - pdonis 13y ago
    A single URI does not name a single piece of data. It doesn't have to; but there's no reason why it couldn't. And there's no reason why a standard couldn't be developed that let the owner of a URI designate that it named a single piece of data that would never change. Thanks for the links, I'll read them to get a better idea of the proposal.
    - mbrubeck 13y ago
      > And there's no reason why a standard couldn't be developed that let the owner of a URI designate that it named a single piece of data that would never change. Yes, I agree. The "new URI scheme" I suggested in my previous comment is one possible way such a standard might be written. That's just one part of the solution, though; if you want the benefits of getting off of TCP then you also need standards for the new content-centric network layer protocol(s) that will replace it, and you need to implement that in your networks and routers.
- dragonwriter 13y ago
  > URIs are names for data. URIs are the result of merging the formerly-separate concepts of names for data (URNs) and identification of mechanisms for locating/accessing data (URLs). A particular URI may or may not be a name for a piece of data, and, except in certain cases, the scheme of a URI won't tell you whether or not it is such a name (one using the urn: scheme unambiguously is such a name, but one using the http: scheme may or may not be.)
urbit 13y ago
And of course the urbit frontpage itself: http://urbit.org http://urbit.org. Basically thanks to HN, 8300 people have watched a 10-minute screencast of a command-line session. Totally insane. My lovely and talented wife, who put together this video, was really hoping people would spend more time watching it than it took to edit. Edit: And Google makes my point and VJ's brilliantly, by breaking the link to his Google TechTalk. Brilliant!

pdonis 13y ago

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.

urbit 13y ago
URIs are names for data - but they're not referentially transparent names. Basically, the inspiration for URIs is Unix filesystems, whereas it should have been Git repositories. It's easy to build mutable resources on top of an immutable namespace. Just put the date, change number, or label, in the name. But once you stop being referentially transparent, you can never recover that virginity. There was sort of an attempt to make Cache-Control headers work in HTTP, but they really don't (I speak as a recovering browser developer), and there's just no substitute for everything having an infinite lifetime.
- pdonis 13y ago
  It's easy to build mutable resources on top of an immutable namespace. Just put the date, change number, or label, in the name. But git repositories don't work this way. Every object in a Git repo is immutable; when I pull a new commit from somewhere, it looks to me like the files in my working copy magically change to the new versions (i.e., that they are mutable), but what's actually happening in the repo is that a set of new immutable objects are added; nothing that was there already changes. This sort of scheme can just as easily be built using URIs (or, for that matter, Unix filenames), so I don't see what the big deal is. You have some URIs (analogous to the filenames in my git working copy) that appear to be mutable resources, but they are implemented on top of other URIs (analogous to the hashes of commits in the git repo) that are immutable resources. All this can be done now, using existing HTTP.
  - urbit 13y ago
    Aren't we agreeing vehemently? The problem is when you try to build immutable resources on top of a mutable namespace. How exactly do you know they're immutable? By what convention? What happens to your code if they mutate? Even worse, using a mutable-namespace for immutable bindings, you have two immutable systems talking to each other through a mutable pipe. First the kind of transformation you describe has to be applied, then it has to be reversed. It's a recipe for madness.
    - pdonis 13y ago
api 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      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.
- anonymous 13y ago
  > That's because there is no (easy) way for you to connect to my computer. Er.. just give me your IP and we're good to go, no? Even easier if you register a name for free on dyndns (for instance) and then give me something like mshaxxorette.homelinux.org.
mbrubeck 13y ago
> URIs are names for data. Yes, they are, essentially. But the difference is that an HTTP URI is not a name for a piece of data -- instead it is a set of instructions that say "connect to this network endpoint and send them this string; in return you will get some data." The data may be different every time someone follows these steps to dereference the URI. A single URI does not name a single piece of data. In a URI scheme where the URIs really name the data (rather than an address for finding data), you can get away from TCP-style point-to-point networking in cases where it makes sense, like in one-to-many broadcasts. The paper I linked [1] specifically compares PARC's content-centric network protocol against TCP+HTTP in these scenarios. And it's not just one-to-many that can benefit; see also the VoCCN paper [2] for a very different use case. I agree that you could (and should) still use URIs for data in your content-centric network, which is why I think we could evolve the web platform to use CCN without any major upheaval. You just need to add a new URI scheme besides http and https. For the web, the changes would not be at the application layer but at lower layers like TCP and routing. But more importantly, CCN would help enable new types of platforms (like Urbit?) that do not look like the web. [1] http://conferences.sigcomm.org/co-next/2009/papers/Jacobson.pdf http://conferences.sigcomm.org/co-next/2009/papers/Jacobson.... [2] http://www.parc.com/publication/2319/voccn.html http://www.parc.com/publication/2319/voccn.html
- pdonis 13y ago
  A single URI does not name a single piece of data. It doesn't have to; but there's no reason why it couldn't. And there's no reason why a standard couldn't be developed that let the owner of a URI designate that it named a single piece of data that would never change. Thanks for the links, I'll read them to get a better idea of the proposal.
  - mbrubeck 13y ago
    > And there's no reason why a standard couldn't be developed that let the owner of a URI designate that it named a single piece of data that would never change. Yes, I agree. The "new URI scheme" I suggested in my previous comment is one possible way such a standard might be written. That's just one part of the solution, though; if you want the benefits of getting off of TCP then you also need standards for the new content-centric network layer protocol(s) that will replace it, and you need to implement that in your networks and routers.
dragonwriter 13y ago
> URIs are names for data. URIs are the result of merging the formerly-separate concepts of names for data (URNs) and identification of mechanisms for locating/accessing data (URLs). A particular URI may or may not be a name for a piece of data, and, except in certain cases, the scheme of a URI won't tell you whether or not it is such a name (one using the urn: scheme unambiguously is such a name, but one using the http: scheme may or may not be.)

urbit 13y ago

And of course the urbit frontpage itself: http://urbit.org http://urbit.org. Basically thanks to HN, 8300 people have watched a 10-minute screencast of a command-line session. Totally insane. My lovely and talented wife, who put together this video, was really hoping people would spend more time watching it than it took to edit. Edit: And Google makes my point and VJ's brilliantly, by breaking the link to his Google TechTalk. Brilliant!