Name: Anonymous 2016-03-27 20:20
Modern web boils down to downloading a blob of code written in extremely contrived language not too far from cobol - and executing it in an adequately complex software diminutively called the "web browser". A behemoth operating system comprising of layers upon layers upon layers of cruft. There was this glimmer of hope with asm.js, pnacl and most recently wasm, but all is lost because those are yet again additional layer on top of browser, just more cruft, and none of it actually executes native code, just some IR.
Can we, the most accomplished programmers, stand idly? We reinvent the wheel every day, so let's talk big - reinvent the web. Consider putting "internet browser" on a radical diet.
From the top perspective, it'd be a stripped down VM like qemu-user. Browsing consists of loading and executing an image within it - a model slightly resembling mobile apps.
This is the initial pitch:
* Web pages, or "apps" are just native code running in sandbox. The publisher has to supply binaries for all architectures, not this IR compiler crap (useless, java-esque abstraction). All modern OSes support fairly lightweight sandboxing [1].
* The sandbox environment is otherwise not that different from pnacl - there is a broker process for upcalls to the host OS. opengl/directx, audio, keyboard, mouse, limited filesystem, network is exposed. It is posix compliant to a degree - threads, signals, processes, IPC within sandbox.
This is to make deployment of posix software and scripting languages trivial.
* Cross-linking 3rd party resources within an app can be done both in-VM (basically a shared library), or isolated [3].
* What makes this a browser is simple overlay p2p client to distribute the binary blobs (ipfs-like). Even the UI chrome, is just an app "shell", running in the VM.
Such a browser would be extremely thin, perhaps under 10k loc, yet it could do everything modern browser does. Yes, even browsing web - that would entail web browser software, say chromium ported to run within the VM. It could do far more, though - run win32 or android software, provided an emulator could run within the VM. The idea is that all the cruft would shift towards app publisher If someone wants to publish a slow blob of behemoth code, let them do it - but don't have that as an implicit part of the system.
Open question is what to do with DNS, popularly known as Zooko's triangle [2].
GNUNet and Namecoin resolve this with hashcash, but that introduces problems of its own (average joe not having the hashpower to register his domain in gnunet, rampant bitcoin-like speculation in the case of namecoin).
Personally I'd go with straight DNS SRV records (name to DHT hash), or some sort of custom cabal, say, like how Tor consensus cabal works, acting like DNS or usenet TINC so that it's not dependent on the fickle ICANN.
I'd like to hear some ideas you have, especially if you have some experience in p2p design.
[1] seccomp-bpf on linux+android, AppSandbox on OSX, ProcessSystemCallDisablePolicy on Win8 onwards. Gutted QEMU (modulo drivers) needed for fallback on win7/xp.
[2] https://en.wikipedia.org/wiki/Zooko%27s_triangle
[3] http://www.angryredplanet.com/~hackbod/openbinder/docs/html/
Can we, the most accomplished programmers, stand idly? We reinvent the wheel every day, so let's talk big - reinvent the web. Consider putting "internet browser" on a radical diet.
From the top perspective, it'd be a stripped down VM like qemu-user. Browsing consists of loading and executing an image within it - a model slightly resembling mobile apps.
This is the initial pitch:
* Web pages, or "apps" are just native code running in sandbox. The publisher has to supply binaries for all architectures, not this IR compiler crap (useless, java-esque abstraction). All modern OSes support fairly lightweight sandboxing [1].
* The sandbox environment is otherwise not that different from pnacl - there is a broker process for upcalls to the host OS. opengl/directx, audio, keyboard, mouse, limited filesystem, network is exposed. It is posix compliant to a degree - threads, signals, processes, IPC within sandbox.
This is to make deployment of posix software and scripting languages trivial.
* Cross-linking 3rd party resources within an app can be done both in-VM (basically a shared library), or isolated [3].
* What makes this a browser is simple overlay p2p client to distribute the binary blobs (ipfs-like). Even the UI chrome, is just an app "shell", running in the VM.
Such a browser would be extremely thin, perhaps under 10k loc, yet it could do everything modern browser does. Yes, even browsing web - that would entail web browser software, say chromium ported to run within the VM. It could do far more, though - run win32 or android software, provided an emulator could run within the VM. The idea is that all the cruft would shift towards app publisher If someone wants to publish a slow blob of behemoth code, let them do it - but don't have that as an implicit part of the system.
Open question is what to do with DNS, popularly known as Zooko's triangle [2].
GNUNet and Namecoin resolve this with hashcash, but that introduces problems of its own (average joe not having the hashpower to register his domain in gnunet, rampant bitcoin-like speculation in the case of namecoin).
Personally I'd go with straight DNS SRV records (name to DHT hash), or some sort of custom cabal, say, like how Tor consensus cabal works, acting like DNS or usenet TINC so that it's not dependent on the fickle ICANN.
I'd like to hear some ideas you have, especially if you have some experience in p2p design.
[1] seccomp-bpf on linux+android, AppSandbox on OSX, ProcessSystemCallDisablePolicy on Win8 onwards. Gutted QEMU (modulo drivers) needed for fallback on win7/xp.
[2] https://en.wikipedia.org/wiki/Zooko%27s_triangle
[3] http://www.angryredplanet.com/~hackbod/openbinder/docs/html/