Hacker News Reader

Comment by pdonis | Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com