I use requirejs for module loading and for my personal projects try to limit each module to a single function. Contrived example:

    define('object/clone', ['object/each'], function(each) {
        /**
         * Shallow copy objects
         *
         * @param {object} - object from which to copy properties
         * @return shallow copy of `obj`
         */
        return function(obj) {
            var clone = {};
            each(obj, function(key, value) {
                clone[key] =  value;
            });
            return clone;
        };
    });

> Clients p2p connect over to the knower (or daisy chain style as a sort of ad-hoc STUN/TURN setup?), and virally spread the data by declaring they too now have the solution for the hash they just downloaded.

This is, in fact, exactly what Freenet does! It's a global DHT acting as a content-addressible store, where there's no "direct me to X" protocol function, only a "proxy my request for X to whoever you suspect has X, and cache X for yourself when returning it to me" function.

(Aside: Freenet also does Tor-like onion-routing stuff between the DHT nodes, which makes it extremely slow to the point that it was discarded by most as a solution for anonymous mesh-networking. But it doesn't have to do that. "Caching forwarding-proxy DHT" and "encrypted onion-routing message transport" are completely orthogonal ideas, which could be stacked, or used separately, on a case by case basis. "Caching forward-proxying DHT" is to the IP layer as "encrypted onion-routing message transport" is to TLS. PersistentTor-over-PlaintextFreenet would be much better than either Tor or Freenet as they are today.)

I agree that this could totally be done as a library in pretty much any language that allows for runtime module loading or runtime code evaluation. And, like you say, there are tons of interesting corollaries.

I think, though, that to be truly useful, you have to push this sort of idea as low in the stack as possible.

Unix established the "file descriptor" metaphor: a seekable stream of blocks-of-octets, some of which (files) existed persistently on disk, some of which (pipes) existed ephemerally between processes and only required resources proportional to the unconsumed buffer, some of which (sockets) existed between processes on entirely separate hosts. Everything in Unix is a file. (Or could be, at least. Unix programmers get "expose this as a file descriptor" right at about the same rate web API designers get REST right.) Unix (and most descendants) are "built on" files.

To truly expose the power of a global code-sharing system, you'd need the OS to be "built on" global-DHT-dereferenceable URNs. There would be cryptographic hashes everywhere in the system-call API. Because your data likely wouldn't just be on your computer (just cached there), you'd see cryptographic signatures instead of ownership, and encryption where a regular OS would use ACL-based policies.

At about the same level of importance that Unix treats "directories", such an OS would have to treat the concept of a data equivalence-mapping manifests (telling you how to get git objects from packfiles, a movie from a list of torrent chunk hashes, etc.)

For any sort of collaborative manipulation of shared state, you'd probably see blocks from little private cryptocurrency block-chains floating about in the DHT, where the "currency" just represents CPU cycles the nodes are willing to donate to one-another's work.

And then (like in Plan9's Fossil), you might see regular filesystems and such built on top of this. But they'd only be metaphors—your files would be "on" your disk to about the same degree that a process's stack is "in" L1 cache. Disks would really just be another layer of the memory hierarchy, entirely page-cache; and marking a memory page "required to be persisted" would shove it out to the DHT, not to disk, since your disk isn't highly available.

—but. Designing this as an OS for PCs would be silly. It would have much too far to go to catch up with things like Windows and OSX. Much better to design it to run in userspace, or as a Xen image, or on a rump kernel on server hardware somewhere. It'd be an OS for cloud computers, or to be emulated in a background service on a PC and spoken with over a socket, silently installed as a dependency by some shiny new GUI app.

Which is, of course, the niches Erlang already fits into. So see above :)

Related reading:

ipfs, an optionally-authenticated hash-based global filesystem: http://ipfs.io

subresource integrity: an emerging web standard whereby you can specify a resource by its hash: http://w3c.github.io/webappsec/specs/subresourceintegrity/

Thank you! I had searched but hadn't been able to find this idea this sounds exactly like what I have had bouncing around in my head for a while now!

I just read the w3c spec it seems more like an integrity check, but it so trivial to just use the integrity hash to download the data that the next step is removing the src tags all-together / using them as a fallback.

Yes. The spec includes the option of providing fallback URLs to fetch from, and gives the browser fairly broad freedom (as I read it) to fulfill the request so long as the response data matches the given hash. How this connects up with the other ideas being discussed in this thread isn't immediately clear to me, as DHTs in practice tend to be too slow to block on for most in-browser resources, but I'd definitely call it an intriguing development.

Sounds like we are looking at the same set of problem, just from slightly different starting point!

The reason to build the DHT on top of WEB-RTC rather than just using freenet:

* is freenet brings a lot of extra 'features' that you mention that aren't needed for a lot of use cases, I view freenet more as one potential implementation of the function getDataByHash(hash) * using a URI style notation (snow:?xt=urn:sha2:beaaca...) makes it clear that the data has 1 simple universal address, it's not terribly difficult to write a FUSE layer that mounts /mnt/snow/sha to your favorite sha providing client (possibly just calling through to node.js). * Using web-rtc given you a large platform to get the network kickstarted as the userbase is extremely large, and no install is required.

So I do agree 100% that we should try to build a language (or languages!) that refer to functions by the hash of their source.

I view the programming language as just a sub problem of 2 issues:

1. We have to make DHT that was trivially accessible on all platforms, including, and especially, in the browser (and likely there first).

2. Even with the DHT we need a way to alias/label the hashes. The alias can also be versioned. Immutable aliases would just be fixed to version 0.

So for a language implemented on top of the DHT, the aliases would correspond to the function names.

This would be a function

resolveAlias(alias) : Hash

where alias is something like "alias:dns.biz.jackman.code.spacegame.flySpaceship?v=0"

* v=0 fixes the function to a set version, so even if it is later patched the code doesn't change, there is no v specified then the latest is used, a more complicated resolution scheme might be desired)

* A dns. prefix is used because hopefully someday we can move beyond need to piggy back on dns for setting authority on keys, in which a different Super TLD can be chosen)

The corresponding putAlias(name, hash, signature, versionNumber=0) function that will attempt to associate a name with a hash to the network.

To prevent anyone from naming things under domains they don't control, a simple solution could be to use public/private keys. Vend the public key(s) of those able to set aliases under that (sub)domain as a DNS TEXT record, or even a CNAME. They can then sign the putAlias by hashing salt+name+hash+version with their private key (keeping in mind the need to avoid length extension attacks).

I have thought along the cpu cycles a currency, I haven't been able to think of a way to make that a tradeable & bankable currency. I think you still need to have a notion of currency that just tries to be a currency, albeit it needs to scale down to nano-transactions, BTC might work if it can handle higher volumes of TPS. This is because you might need to add to every api function an extra parameter, bounty, wherein you name a price you are willing to pay for your peers to perform that action. Under normal browsing routines, your client should be doing a lot more work than it asking to have done. Those normal clients should be accumulating currency.

When you are on mobile you might be a drain a on the network, in that case you will simply subsidize that activity from your home laptop, or build it up when you go home at night have your phone plugged in charging and are on a WI-FI (or maybe wifi mesh + UAVs that the network itself purchases to increase it's coverage) network.

One other thing, if you want to run a big data study on a bunch of SHA's and use a lot of compute, then obviously you are going to have to acquire some of this currency since you are a load on the network.

Here's how the hello world for that would look:

var hash = putDataByHash("Hello World") executeRemotely(function () { return getDataByHash(hash) })