Hacker News Reader

Comment by pdonis | Hacker News Reader

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.

View on HN

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

[2] http://www.parc.com/publication/2319/voccn.html

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.

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

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.

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.

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.

How exactly do you know they're immutable?

You don't, unless the owner of the resource says they are and is trustworthy. No amount of code will change that.

If you mean, how does the owner of the resource signal that the resource is immutable, yes, I can see that establishing a standard for this would be helpful. But that's just a matter of adding an RFC to describe how to mark URIs as naming immutable resources. Why does it require completely reworking the Internet infrastructure from scratch?

using a mutable-namespace for immutable bindings, you have two immutable systems talking to each other through a mutable pipe

No, it's a matter of making sure you don't use a mutable namespace for immutable bindings. See above.

You don't, unless the owner of the resource says they are and is trustworthy. No amount of code will change that.

No, but you have to decide how your code will behave if it detects a change. Should it keep a hash and report an error?

But that's just a matter of adding an RFC to describe how to mark URIs as naming immutable resources.

That's certainly an interesting way to use the word just. You don't strike me as someone who first heard of the IETF yesterday.

And besides, we already have an RFC that does exactly that. It's RFC 2616 - use Cache-Control: max-age. Except that - this channel is polluted with crap information, because lots of sites set their cache-control wrong and don't mean it.

So you need a new channel that isn't polluted with crap information. Maybe we're agreeing after all.

Why does it require completely reworking the Internet infrastructure from scratch?

DNS is also not referentially transparent. Nor are HTTP responses signed by DNS identities.

When all is said and done, you have a new service by any standards. Why layer the new service (which is much simpler than the old service) over the old ball of mud? If you want to talk to it from the ball of mud, write a gateway.

you have to decide how your code will behave if it detects a change

That decision will depend on the application, and that will be true regardless of how resources are mapped to names.

That's certainly an interesting way to use the word just.

I agree. :-) But note that I'm making a comparison to inventing a whole new operating system, programming language, etc. Compared to that, getting an RFC through the IETF strikes me as fairly simple. :-)

we already have an RFC that does exactly that. It's RFC 2616 - use Cache-Control: max-age. Except that - this channel is polluted with crap information

But that's not for the specific purpose of marking resources as immutable; it's overloaded with a number of purposes, which don't always mesh very well.

DNS is also not referentially transparent.

Maybe this would make more sense to me if I had read more of the papers relating to this, but it seems to me that "not referentially transparent" is a very general term that can mean a number of different things. Do you just mean that the IP address pointed to by an A record can change? Or do you mean that the resource pointed to by, say, "peterdonis.net" can change?

Compared to that, getting an RFC through the IETF strikes me as fairly simple.

If I had to get the whole new operating system, etc, through the IETF, I might agree with you!

You know, all your questions have the same answer. Of course no standard can control the behavior of a remote server. But when you have an environment in which mutability is neither expected nor produced, any violation of immutability is easily recognized as a bug - and (in a highly specified system like Urbit) a very unlikely bug.

Whereas whatever conventions you add to the W3 environment that say "this resource is immutable," pretty much everything in that environment is "overloaded with a number of purposes, which don't always mesh very well" - and if the receiving end of a protocol actually treats your conventions as if they were ironclad rules, it's violating Postel's Law. There's just too much "give" in the whole system, and that's a mistake that's much easier to not make in a new system, than to fix in the old one.

> But that's just a matter of adding an RFC to describe how to mark URIs as naming immutable resources.

The simplest thing would be to just register a URN namespace specifically for immutable resources; the URN scheme already exists for resource naming separate from resolution.

Aren't we agreeing vehemently?

I don't know, because I don't understand (yet) what problem you think Urbit is solving, that can't be solved using existing tools (but possibly with new standards).

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.

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

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.

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.

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

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

Reply on news.ycombinator.com