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