> I advocate a switch to direct hardware execution of exclusively high-level (human readable!) code. Does it get more user-modifiable than that?

What sort of code the hardware executes is irrelevant to whether that code is Free. JavaScript is high-level and mostly human-readable, but it's trivial to obfuscate JavaScript such that modification by the user is difficult or impossible. And JavaScript is a relatively limited language; a LISP-like language executed directly by the hardware could be even more difficult to modify.

> it's trivial to obfuscate JavaScript such that modification by the user is difficult or impossible.

This is a moral, rather than technological problem. Anyone writing any kind of code can choose to make life less-pleasant for those who will read it.

Under current architectures, you do not even have the option of making life pleasant for those who wish to read the code that is presently running on their machine, at the time it runs. In fact, the very idea sounds like schizophrenic soapbox heresy to most people. Which is a crying shame.

You're missing the point. Currently, I do not have to run proprietary software to use the Web. Under your design, I would have to surrender control of my computer to arbitrary third parties to use even the most basic features.

What kind of control do you presently have over your computer, that would be taken away?

Current CPUs come with hypervisors; running native code need not lead to any loss of control. Sanely designed CPUs would give the user yet more control.

Where does the code come from and how is its use specified? To be able to change code, my edit must affect all copies. If I'm receiving code dependencies over the network from the same source as my data, I need some sort of override rule that will use my edited copy instead. The package also needs a global name such that the datasource cannot change the name and put me back to the old code. And how do we reconcile changes to the code bundle from the datasource with my local changes?

We can mitigate most of these issues with cryptographic identities and trust systems, but with that amount of surrounding infrastructure, why does the datasource even need to specify which code to run for well-known datatypes if those packages already have to be on my trusted sources?

I would love to post a reply which answers these and other excellent questions from some of the replies here!

But if I were to write such a comment, it would, in a sense, be the code. Not that I wouldn't love to post the latter, when it is ready, but this is not the intended use of this site.

My apologies if this sounds like a slick excuse, but it is the truth.

Well, I'm curious about your conceptual design for this, because to me, the whole No Formats post directly contradicts your seventh rule. We can make the network transparent, but we cannot ignore the authority boundary between our two nodes. If I am to control the code running on my node, then I can't be expected to pull in common library code from your service to view your published data.

For example, this is the way things work with a standardized format. ( -x-> means depends on and trusts through some interface (non-transitive!))

    MyEnv -1-> MyImageLib ---> Jpeg specification
    YourCode ---> YourImageLib ---> Jpeg specification
    MyEnv -2-> YourCode

Interface 1 defines what I may do with images, while interface 2 defines how I may interact with your service. MyImageLib and YourImageLib may of course be the same library, or they may not.

This is what I interpret your post as saying:

    MyEnv -3-> YourCode -4-> YourImageLib

In this new relationship, I am relying on interface 3 both for my relationship with you and for what I am allowed to do with images. If you are nice as well as thorough, I am able to rely on interface 3 to get the identity of interface 4 such that I can both work with the image library directly, as well as override the reference after forking my own copy. However, if you wish to restrict me, or even simply update reference 4 to an incompatible api, my ability to work with the library directly goes away and/or my local modifications are no longer referenced.

What have I misunderstood?

Copy-on-write.

And, as I've said before, you can't "technology-away" moral problems. All you can do is to refrain from deliberately hardcoding them into your creations.

Are not your laws of computing, specifically (VII, VI, IV, II, I), moral judgments? Trying to "technology-away" a preexisting moral problem is folly, but software, platforms especially, set a stage of default behaviors. One could argue that those who blindly go along with said default are moral failures (for their lack of analysis), but this would do little to negate the resulting effects of those masses.

On the technical front, what do you propose to copy-on-write? I'll presume by "morals", you mean that I should trust the authors of the hypothetical ImageLib and YourCode to not restrict my use of images through technical means, and to generally do the right thing when it comes to library changes.

Let's say I wish to modify ImageLib as used in your application. For copy-on-write, what is "written" ? Forking YourCode along with ImageLib (immutable references) is a non-starter, as the common case is that YourCode changes periodically, and that I'm uninterested in manual merging, as YourCode just isn't a large part of my life.

So, I've got my locally forked version of ImageLib, but any changes I make are only applied to that specific version of ImageLib. Every other XXCode which uses a different lineage or revision of ImageLib will lack the customizations I've made!

So how can this be solved? Freezing the API of ImageLib would alleviate the need for incompatible releases. But to freeze the API, it needs to be trimmed down to the bare minimum of core functionality, with extras pushed out into other modules using well thought out hooks. After eventually reaching perfection, the API can finally stop changing, and overriding all possible ImageLibs is easy (as only one exists). However, we have completely locked down the API (and thus cut off unexpected new functionality), and have effectively created a format!

(also, a tidbit that's kind of a continuation: http://news.ycombinator.com/item?id=2121549)