Two Worls Colliding and a Decentralized Web

The original bitcoin software is written in C++, is a standalone application and uses low level 'sockets' to build its peer-to-peer network over the Internet.

Then we have the other world where apps run in a webbrowser, are using the Internet only via methods webbrowsers support: http and web-sockets.

Those two worlds hardly ever interact and what I want to focus on is thinking about decentralization in a world of the web.

The situation today is pretty dire. Any web-app or browser-plugin is not capable to connect to full nodes via the peer-to-peer network because the browser simply won't allow web-sockets to connect to normal Internet sockets.

What we mostly see today is web-apps that connect to an indexing server in order to sync with the blockchain. Most of those apps even have the indexing server specified by the server-operator. Is this decentralized? Not only is the webserver that hosts the app a central point of failure, the indexing server is another central point of failure.

An obvious solution is to make such web-apps connect to a lot of indexing servers, just like our p2p network has lots of servers.

At the moment we are simply looking at people adding some 15% more disk space usage next to their existing full node.

But as explained here, the cost of such indexers will continue to rise and it won't simply be the additional disk space as our base of users grows. As usage grows, the machine to run such an indexer will start to cost more, costs growing much faster than Moore's law. Which again leads to centralization as the cost of running such indexers means more will not do so.

At best, indexer decentralization is then a temporary solution.

Bridge the gap

If we are interested in bringing the decentralized and permissionless development to the web as well, there is a need to bridge the gap between the two worlds outlined in the start of this article.

It feels very important to make sure that the two worlds actually connect. The existing peer-to-peer network that full nodes use is the core of our decentraization today, reusing that means we strenghen the current decentralized network. Remember basic networking theory; the network grows in value relative to the amount of possible connections. Having one peer to peer network used by full nodes as well as by the web will thus have a massively more value than two seperate ones.

Yet, the problem is that the web uses 'web-sockets' while the full nodes use raw sockets. Conceptually the same, but incompatible. So, websites can't use the existing p2p network.

But what if we made full nodes create the peer to peer mesh over both raw sockets as well as allowing people to connect on web-sockets from their browser?

Adding web-sockets to software like BCHN would be easy enough, afterall it already has a web-server (using libevent) for the RPC/JSON interface. The biggest issue is likely encountered by users deploying the full node: web-sockets use a priviledged port and thus needs configuration to make it work. On Linux with systemd that is easy enough, maybe someone with knowledge of Windows can comment on how hard that is.

So, if web-browsers can connect to full nodes directly and talk with some nice JavaScript library the native peer-to-peer language, what would that give us?

A web-wallet, deployed via ipfs / on many servers, that stores all its private keys locally. It can then become an SPV client (using merkleblock messages) without any central servers, getting blockchain data from the big amorphous p2p network.

Just providing this option in full nodes won't magically make web-apps decentralized. But the reality is that web-app developers today basically don't really have any options. I end up saying to devs that they can go to commercial suppliers of APIs, but naturally open source devs find that less appealing.

What do web-devs think about this? Would you use a library (assuming someone smarter than me writes one) that makes your wallet update via the p2p network?