Distributed Hosting Hacks
If your background is in computer science, engineering or you have deep understanding of IT, Distributed Hosting does not sound too amazing and disruptive. For some of you it even sounds boring. Let me clarify some things for you. BlackGate, that is the name of this Distributed Hosting project, solves some of the challenges in a clever way.
Websites come to you, not the other way around.
In difference to classical hosting solution, BlackGate does not need a dedicate server architecture, but makes use of powerful enough consumer devices, like laptops and computers, in the future maybe even your fridge. That not only reused unusued storage, but makes the whole system also censhorship resistant. Hosted pages can be updated in the background, making them offline available for later and increasing the access speed.
This approach is pretty new in the field. Instead of using one global blockchain, each hosted page receives a completely new blockchain. Additional to the scalability gain — only the page creator can create new blocks — it also allows to selective host and keep track of specific pages, without having to download all pages ever created. A hosting algorithm, that will be developed in the scope of the project, will determine what pages should be hosted, in order to guarantee best distribution and availability, but also increased user experience.
Data and Metadata Separation
Hosting from everywhere, without worrying about security and privacy
By using Tor Hidden Services (the .onion domains) it is possible to host pages even behind Firewalls and NATs. This makes distributed hosting on end-user devices possible. An additional side-effect is increased security and privacy. No personal data is exposed and the fact that only static content is hosted makes the attack vector is pretty small.
Trust-less page distribution
An update transaction, created by a page owner, includes not only a reference to the updated page, but also checksums for each endpoint. The two endpoints, http://clone.onion/about and http://clone.onion/contact have different checksums if they return different content. Each node that accesses the page, via local configure proxy, checks these checksum and fails if they returned content checksum does not match with the checksum in the blockchain. This makes it possible to return a page from a random node in the blockchain, without relaying on the trust worthiness of this specific node.