Will there be a Distributed HTTP?(mnot.net)
mnot.net
Will there be a Distributed HTTP?
https://www.mnot.net/blog/2015/08/18/distributed_http
71 comments
Isn't that more or less how Freenet works?
Yep. Freenet is inefficient, though, because it has a bunch of indirection in order to obscure the originator of the inserted documents. You could remove that indirection if you just cared about the content, not about anonymity.
If I don’t need anynomity, I would choose the Download mesh from Gnutella.
If I do need anonymity, Freenet is a very good choice.
If I do need anonymity, Freenet is a very good choice.
Sorry to be pedantic... I thought their main website actually just proxies to the actual ipfs gateway. Is it technically a mirror?
I actually don't know. Since it's static HTML and assets and IPFS is still in beta they might host their webpage the old-fashioned way.
In May I contributed an example to the IPFS documentation. (https://github.com/insanity54/website/commit/64db436e33662f2..., https://github.com/ipfs/examples/pull/5/commits) At that time, the site was served by github pages, but parts of the site, including the examples, were served by IPFS. On IRC, I had heard of plans to migrate the entire site to IPFS once IPNS was ready.
EDIT: seems like it's all IPFS now https://botbot.me/freenode/ipfs/search/?q=github+pages
EDIT2: Better link. https://botbot.me/freenode/ipfs/2015-08-22/?msg=47828655&pag... (The way the IPFS gateways work is you run them on a machine and bind to port 80 or whatever. Then in your DNS TXT records, you put the hash of the content you want to serve, and the gateway picks up on this and fetches the hash from the network.)
EDIT: seems like it's all IPFS now https://botbot.me/freenode/ipfs/search/?q=github+pages
EDIT2: Better link. https://botbot.me/freenode/ipfs/2015-08-22/?msg=47828655&pag... (The way the IPFS gateways work is you run them on a machine and bind to port 80 or whatever. Then in your DNS TXT records, you put the hash of the content you want to serve, and the gateway picks up on this and fetches the hash from the network.)
This is one of the most crucial things we need to make free software viable again. In 2006, I wrote that the only solution to the problem of proprietary services was to "build these services as decentralized free-software peer-to-peer applications, pieces of which run on the computers of each user": https://www.mail-archive.com/[email protected]/msg001...
And, in particular, I wrote a few months later that replacing HTTP URLs for naming content is necessary and nearly sufficient: https://www.mail-archive.com/[email protected]/msg001...
We still have a long way to go, but it's heartening to see so much work toward solving the problem! Perhaps one of the systems mnot links to will evolve to solve the problem; perhaps it will be something that we haven't started to build yet.
This is crucial to the future of civilization and to the longevity of your personal work. Nearly all the effort that went into proprietary software in the 1980s and 1990s has been lost rather than becoming part of the cultural heritage of humanity, in the way that Emacs and GCC have. Similarly, everything you invest today into proprietary web services is ultimately destined for the dumpster, whether it's code you write to build them or data you store in them. We need an alternative that has a chance of lasting.
And, in particular, I wrote a few months later that replacing HTTP URLs for naming content is necessary and nearly sufficient: https://www.mail-archive.com/[email protected]/msg001...
We still have a long way to go, but it's heartening to see so much work toward solving the problem! Perhaps one of the systems mnot links to will evolve to solve the problem; perhaps it will be something that we haven't started to build yet.
This is crucial to the future of civilization and to the longevity of your personal work. Nearly all the effort that went into proprietary software in the 1980s and 1990s has been lost rather than becoming part of the cultural heritage of humanity, in the way that Emacs and GCC have. Similarly, everything you invest today into proprietary web services is ultimately destined for the dumpster, whether it's code you write to build them or data you store in them. We need an alternative that has a chance of lasting.
A variant form of "Conquest's second law of politics" almost certainly applies to all innovation in this space: Any protocol that doesn't explicitly exclude Google sooner or later becomes Google.
It may be impossible to win this game.
It may be impossible to win this game.
How do you foresee the decentralized production of CPUs being achieved?
A bit of a non-sequiter, but I'll bite.
Replicating toolboxes. Or self-replicating benchtop factories.
Microcontrollers could be produced using dip-pen nanolithigraohy, or a few other techniques.
Of course we need decent open source atomic force microscopes first.
There will always be components that can't be produced on that kind of scale. In reprap parlance we call the "vitamins". An apt metaphor.
Replicating toolboxes. Or self-replicating benchtop factories.
Microcontrollers could be produced using dip-pen nanolithigraohy, or a few other techniques.
Of course we need decent open source atomic force microscopes first.
There will always be components that can't be produced on that kind of scale. In reprap parlance we call the "vitamins". An apt metaphor.
The production of integrated circuits is very much dictated by economies of scale. The capital require is simply too large to justify the creation of a production line for a small run. If you crack that particular nut then you're going to be the next Bill Gates.
The capital required to currently produce top-of-the-line ICs is too large. But we're getting closer - people are building their own CPUs. E.g. there was the article of someone breadboarding a CPU in the 10's of MHz range recently. And there are plenty of FPGA projects, which while still depending on ICs manufactured by a central manufacturer substantially reduces their role.
How exactly do FPGAs do antything at all to reduce the role of central manufacturing?
The same way computers do: you can reprogram them instead of buying a new thingamajig.
This makes no sense. Computers are made of centrally manufactured components, and are regularly replaced by new ones as technology advances.
This applies to CPU's too and is in no way mitigated by FPGAs.
This applies to CPU's too and is in no way mitigated by FPGAs.
I use my computer to read books, for example. This eliminates the central manufacturing of books; when I want to read a book, I tell my computer to turn into a book, thus manufacturing one temporarily on my desktop until I'm done.
I use my computer to graph equations. This eliminates the central manufacturing of graph paper; when I want graph paper, I tell my computer to turn into graph paper.
I use my computer to make telephone calls. This eliminates the central manufacturing both of telephones and of telephone switches; when I want a telephone call, I tell my computer to turn into a phone, and it turns routers into phone switches.
I use my computer to watch pornography. This eliminates the central manufacturing of porn VHS tapes; when I want a porn video, I tell my computer to turn into a porn video.
I use my computer to store books. This eliminates the manufacturing of bookshelves, although to be fair, bookshelf manufacturing has never been as centralized as computer manufacturing.
I use my computer to do engineering design. This eliminates the central manufacturing of drafting tables, slide rules, and pocket calculators.
I use my computer to find out what time it is. This eliminates the central manufacturing of wristwatches.
I use my computer to send letters such as this one. This eliminates the central manufacturing of envelopes and postage stamps.
I use my computer to find out about Syrian children drowning in Turkey. This eliminates the central manufacturing of newspapers, although again, this may not have been as centralized as computer manufacturing is.
Perhaps this can help you to understand in what sense the original statement is true, as well as the sense you've already pointed out in which it is false.
I use my computer to graph equations. This eliminates the central manufacturing of graph paper; when I want graph paper, I tell my computer to turn into graph paper.
I use my computer to make telephone calls. This eliminates the central manufacturing both of telephones and of telephone switches; when I want a telephone call, I tell my computer to turn into a phone, and it turns routers into phone switches.
I use my computer to watch pornography. This eliminates the central manufacturing of porn VHS tapes; when I want a porn video, I tell my computer to turn into a porn video.
I use my computer to store books. This eliminates the manufacturing of bookshelves, although to be fair, bookshelf manufacturing has never been as centralized as computer manufacturing.
I use my computer to do engineering design. This eliminates the central manufacturing of drafting tables, slide rules, and pocket calculators.
I use my computer to find out what time it is. This eliminates the central manufacturing of wristwatches.
I use my computer to send letters such as this one. This eliminates the central manufacturing of envelopes and postage stamps.
I use my computer to find out about Syrian children drowning in Turkey. This eliminates the central manufacturing of newspapers, although again, this may not have been as centralized as computer manufacturing is.
Perhaps this can help you to understand in what sense the original statement is true, as well as the sense you've already pointed out in which it is false.
An open-source, cheap AFM: http://hackaday.com/2015/01/13/cheap-diy-microscope-sees-ind...
> benchtop factories
This is feasible even using current production techniques. Just make smaller tools.
Open hardware designs are a bigger part of the problem, IMO.
This is feasible even using current production techniques. Just make smaller tools.
Open hardware designs are a bigger part of the problem, IMO.
We have open hardware designs including the RISC-V, the OpenRISC, and the SPARC, but we don't have desktop semiconductor fabs, nor will we in the foreseeable future.
> need decent open source atomic force microscopes
If the LHC stuff pans out, we may need open source replicators. :)
If the LHC stuff pans out, we may need open source replicators. :)
That's a bit further down the line, but for now it's adequate to have end-users buy CPUs produced in a centralized manner, as long as they are able to control what those CPUs do by running free software on them.
> Ultimately, it was a losing game, because of the inherent conflict of interest between software author and software user.
This is exactly what is broken with our current software business models. On-prem software is expensive to deploy and manage but gives users control of their data. SaaS software is cheap to deploy and manage but takes control of the user's data. We must find middle ground between the two models. A solution that takes the best of both on-prem software and cloud based SaaS services may be that middle ground, but it's going to require a globally federated cloud.
Here's an article from a few months talking about this concept: http://venturebeat.com/2015/05/09/goodbye-saas-hello-contain.... The basic premise is that ISVs should be able to deploy their stacks on-prem, similar to the way they deploy to their SaaS-based solutions today.
I've been kicking around a slightly modified vision for a new software model I call MSaaS for about 3 years now after spending an inordinate amount of time thinking about infrastructure trust. MSaaS is short for managed software as a service. The idea is to build a federated platform for storing/signing code and images used to deploy applications, infrastructure deployment targets which carry various levels of trust, and a method for payments and identity management for settling resource consumption, including development time.
First, MSaaS needs to have a means by which an ISV's software components, such as source code or images, can be placed an immutable data structure similar to a blockchain. IPFS' merkle DAG is one such example of a blockchain that allows for immutable, decentralized data storage with signing capabilities. It allows for a company to sign a given piece of code, stuff it, and the accompanying configuration information, into an immutable data store, and make it globally accessible in a trust-less manner (i.e. anyone can fetch it anonymously). Bits can be signed and/or encrypted using public keys where needed for privacy and security.
Side Note: IPFS has an interesting 'problem' with it in that if a node containing data goes away, it is lost from the network. That's actually acceptable here regarding the source code or images users would need to pull to run applications or services as the code could be pulled from one or more centralized repositories (Github) by a trusted authority, built into an image, re-signed and then placed back on the network on-demand. Keys/configuration bits could be shared in a similar manner, or handled a tad bit differently for backups.
Second, MSaaS will introduce the idea of multiple trusted deployment target endpoints, such as those provided by AWS, Digital Ocean, OpenStack running on-prem in a DC, or even your local computer. These deployment targets respond to cryptocurrency payments and provision themselves where the trust levels exist between parties (or depending on the use-case, don't exist) using the data stored in the previously mentioned merkle DAG/blockchain. The payments themselves represent identity in the form of signing keys (which can be related to the keys used to sign the code/images) and payment for resources, perhaps including a managed service provider along the way. For example, if your images need to be built from code, you enter into a relationship with XYZ Container Builders, Inc. and they become responsible for building and signing your images. Payment chains are used to tie these transactions together.
Finally, we'll need search engines to assemble all this together into a cohesive offering that anyone can join or use. Searches for trust, compute power, storage costs, network speeds, container specs, etc. can all be included in the results returned.
I would note that the first thing people usually ask when I talk about this stuff is "How can I trust XYZ provider with my data/code?". The answer is that you establish relationships with individuals who provide you software and/or infrastructure that is a fit based on your particular use-case's trust needs. If you have sensitive data you don't trust anyone with, then deploy the application on-prem in your own cloud and don't allow the software company to remotely manage it. If it's a CI test on a public repo, who cares who does that as long as consensus is reached on the outcome over time?
This is exactly what is broken with our current software business models. On-prem software is expensive to deploy and manage but gives users control of their data. SaaS software is cheap to deploy and manage but takes control of the user's data. We must find middle ground between the two models. A solution that takes the best of both on-prem software and cloud based SaaS services may be that middle ground, but it's going to require a globally federated cloud.
Here's an article from a few months talking about this concept: http://venturebeat.com/2015/05/09/goodbye-saas-hello-contain.... The basic premise is that ISVs should be able to deploy their stacks on-prem, similar to the way they deploy to their SaaS-based solutions today.
I've been kicking around a slightly modified vision for a new software model I call MSaaS for about 3 years now after spending an inordinate amount of time thinking about infrastructure trust. MSaaS is short for managed software as a service. The idea is to build a federated platform for storing/signing code and images used to deploy applications, infrastructure deployment targets which carry various levels of trust, and a method for payments and identity management for settling resource consumption, including development time.
First, MSaaS needs to have a means by which an ISV's software components, such as source code or images, can be placed an immutable data structure similar to a blockchain. IPFS' merkle DAG is one such example of a blockchain that allows for immutable, decentralized data storage with signing capabilities. It allows for a company to sign a given piece of code, stuff it, and the accompanying configuration information, into an immutable data store, and make it globally accessible in a trust-less manner (i.e. anyone can fetch it anonymously). Bits can be signed and/or encrypted using public keys where needed for privacy and security.
Side Note: IPFS has an interesting 'problem' with it in that if a node containing data goes away, it is lost from the network. That's actually acceptable here regarding the source code or images users would need to pull to run applications or services as the code could be pulled from one or more centralized repositories (Github) by a trusted authority, built into an image, re-signed and then placed back on the network on-demand. Keys/configuration bits could be shared in a similar manner, or handled a tad bit differently for backups.
Second, MSaaS will introduce the idea of multiple trusted deployment target endpoints, such as those provided by AWS, Digital Ocean, OpenStack running on-prem in a DC, or even your local computer. These deployment targets respond to cryptocurrency payments and provision themselves where the trust levels exist between parties (or depending on the use-case, don't exist) using the data stored in the previously mentioned merkle DAG/blockchain. The payments themselves represent identity in the form of signing keys (which can be related to the keys used to sign the code/images) and payment for resources, perhaps including a managed service provider along the way. For example, if your images need to be built from code, you enter into a relationship with XYZ Container Builders, Inc. and they become responsible for building and signing your images. Payment chains are used to tie these transactions together.
Finally, we'll need search engines to assemble all this together into a cohesive offering that anyone can join or use. Searches for trust, compute power, storage costs, network speeds, container specs, etc. can all be included in the results returned.
I would note that the first thing people usually ask when I talk about this stuff is "How can I trust XYZ provider with my data/code?". The answer is that you establish relationships with individuals who provide you software and/or infrastructure that is a fit based on your particular use-case's trust needs. If you have sensitive data you don't trust anyone with, then deploy the application on-prem in your own cloud and don't allow the software company to remotely manage it. If it's a CI test on a public repo, who cares who does that as long as consensus is reached on the outcome over time?
> This is exactly what is broken with our current software business models. On-prem software is expensive to deploy and manage but gives users control of their data. SaaS software is cheap to deploy and manage but takes control of the user's data. We must find middle ground between the two models. A solution that takes the best of both on-prem software and cloud based SaaS services may be that middle ground, but it's going to require a globally federated cloud.
I think something like remoteStorage can address this need.
https://remotestorage.io/
It's a federated, open storage protocol that has multiple server implementations that anyone can host. I think it has the potential to enable a new model for SaaS software where users, rather than service providers, own the data.
I think something like remoteStorage can address this need.
https://remotestorage.io/
It's a federated, open storage protocol that has multiple server implementations that anyone can host. I think it has the potential to enable a new model for SaaS software where users, rather than service providers, own the data.
I'm working on an interesting project right now where the web application behaves like a typical SaaS solution, except that all of the customer's data is hosted on premises.
After the initial install, their local servers (and data) don't have to be touched, but the SaaS portion can be continuously improved. So far it's worked really well.
Your MSaaS idea sounds really interesting, especially the multiple trusted deploys. That's the crux of trusting deployed open source software.
After the initial install, their local servers (and data) don't have to be touched, but the SaaS portion can be continuously improved. So far it's worked really well.
Your MSaaS idea sounds really interesting, especially the multiple trusted deploys. That's the crux of trusting deployed open source software.
There are others working on this now, here in San Francisco. I think it's the tip of the iceberg. The on-prem ISV market is fucking huge.
> replacing HTTP URLs for naming content is necessary and nearly sufficient
It depends what you replace them with. I quickly skimmed your essays looking for any proposals, but didn't quite see anything.
The obvious thing is Freenet-style public signing keys, but while this helps decentralize distribution (a boon to a person who wishes to publish anonymously - upload and run), the standard centralized naming hierarchy will form, at least for introduction.
The well-known "HNS" /com/ will just be 8b844459891e8f1840bfc4200e758483 instead of the DNS 192.5.6.30 (a.gtld-servers.net). Likewise, after introduction a discussion board would be known as 659f177ebea794e4e74f0708d832f65e (even if it is Petnamed) instead of news.ycombinator.com.
Public signatures are simply one layer and not the full solution, in the same sense that hash trees of immutable content are only one part.
What is important is forking, which relies on the ability for differing forks to be intelligently reconciled in an automated fashion. I should be able to use a version of "HN" where a specific user is/isn't banned, and still communicate with you (presuming that you want to, rather than whoever is running the popular "HN" aggregation node), even if you yourself are using a third version.
I think it ultimately comes down to the data model supporting some concept of "merge points" rather than strict top-down immutability/persistence. With these merge points and rules specified by the endpoints' schemas according to the users' desires. But it's awfully hard thinking about this stuff since I also keep seeing how any specific approach can calcify and turn into similar prescriptive monoliths as we have today.
It depends what you replace them with. I quickly skimmed your essays looking for any proposals, but didn't quite see anything.
The obvious thing is Freenet-style public signing keys, but while this helps decentralize distribution (a boon to a person who wishes to publish anonymously - upload and run), the standard centralized naming hierarchy will form, at least for introduction.
The well-known "HNS" /com/ will just be 8b844459891e8f1840bfc4200e758483 instead of the DNS 192.5.6.30 (a.gtld-servers.net). Likewise, after introduction a discussion board would be known as 659f177ebea794e4e74f0708d832f65e (even if it is Petnamed) instead of news.ycombinator.com.
Public signatures are simply one layer and not the full solution, in the same sense that hash trees of immutable content are only one part.
What is important is forking, which relies on the ability for differing forks to be intelligently reconciled in an automated fashion. I should be able to use a version of "HN" where a specific user is/isn't banned, and still communicate with you (presuming that you want to, rather than whoever is running the popular "HN" aggregation node), even if you yourself are using a third version.
I think it ultimately comes down to the data model supporting some concept of "merge points" rather than strict top-down immutability/persistence. With these merge points and rules specified by the endpoints' schemas according to the users' desires. But it's awfully hard thinking about this stuff since I also keep seeing how any specific approach can calcify and turn into similar prescriptive monoliths as we have today.
I don't know what the answer is. I agree with most of what you say. I think we have to experiment with things that could work in theory and see what works in practice.
Sandstorm is an interesting step in this direction. Not peer-to-peer but decentralized free-software.
https://sandstorm.io/
https://sandstorm.io/
There's already a quite large distributed "HTTP" being used everyday: BitTorrent's DHT network. URIs are just the keys of the distributed hash table. Keys are also mutable so one can change the content stored at specific keys. Right now it's being used to serve very large files and not HTML/CSS/JS files. Things like Project Maelstrom are a step in the right direction.
Problem is that it's hard to find things, just like it was hard when the Web started. There are opportunities for the next "google" of this new DHT space.
Problem is that it's hard to find things, just like it was hard when the Web started. There are opportunities for the next "google" of this new DHT space.
I'm curious if Cloudflare takes the torch on this, considering their acumen at running a CDN.
Is there a description of how maelstrom holds references in the DHT? I can think of half a dozen ways to bolt HTTP hosting on bittorrent, but the scale of "people using http" is orders of magnitude larger than "people who use bittorrent".
Yes, I've already implemented it:
Distributed HTTP: Maalstroom on MORPHiS :)
GPLv2 unlike Bittorrent Inc.'s Mælström
https://morph.is
It is very fast because it is not anonymous first. Although it is 100% designed with being non-leaking over Tor. It already works over proxychains great. I will add SOCKS5 support soon.
Also, don't forget the distributed spam resistant automatically encrypted and transparently authenticated mail:
https://morph.is/v0.8/dpush-whitepaper.odt
Dpush is distributed /unsolicited/ POST :) Solves the previously open problem perfectly.
MORPHiS hosted MORPHiS website:
morphis://sp1nara3xhndtgswh7fz OR localhost:4251/sp1nara3xhndtgswh7fz
URL is a hash of the data or the key that signed it. No MITM possible.
The next module I am implementing is DDS - Distributed Discussion System. It is quite easy because it is fully enabled by the existing Dpush invention that already powers MORPHiS Dmail.
Distributed HTTP: Maalstroom on MORPHiS :)
GPLv2 unlike Bittorrent Inc.'s Mælström
https://morph.is
It is very fast because it is not anonymous first. Although it is 100% designed with being non-leaking over Tor. It already works over proxychains great. I will add SOCKS5 support soon.
Also, don't forget the distributed spam resistant automatically encrypted and transparently authenticated mail:
https://morph.is/v0.8/dpush-whitepaper.odt
Dpush is distributed /unsolicited/ POST :) Solves the previously open problem perfectly.
MORPHiS hosted MORPHiS website:
morphis://sp1nara3xhndtgswh7fz OR localhost:4251/sp1nara3xhndtgswh7fz
URL is a hash of the data or the key that signed it. No MITM possible.
The next module I am implementing is DDS - Distributed Discussion System. It is quite easy because it is fully enabled by the existing Dpush invention that already powers MORPHiS Dmail.
how does it avoid timing attacks when running over Tor?
I met Mark and Tim Berners-Lee at Extensible Summit and was very happy that they are still actively fighting for the World Wide Web in its full distributed, decentralized glory.
I do work on synchronization in distributed systems, and would like to add my database, http://gunDB.io/, to the list. Why? Because it answers his questions in the "Some State and Processing Really Wants to Be Centralised" section. If you want more info on this, check out the github repo, or ask me.
Anybody interested in these subjects should be at https://2015.distributed-matters.org/ber/, Kyle Kingsbury will be doing the keynote and later on in the day I'll be presenting my protocol.
Mark's "Modifying The Web is Scary" section is important, I do see a lot of people reinventing the wheel but it isn't too hard to get everything to work over PATCH (sadly a verb which didn't take off but is in the specification) and upgrading to WebSockets.
Overall, great post. I hope more people talk about this.
I do work on synchronization in distributed systems, and would like to add my database, http://gunDB.io/, to the list. Why? Because it answers his questions in the "Some State and Processing Really Wants to Be Centralised" section. If you want more info on this, check out the github repo, or ask me.
Anybody interested in these subjects should be at https://2015.distributed-matters.org/ber/, Kyle Kingsbury will be doing the keynote and later on in the day I'll be presenting my protocol.
Mark's "Modifying The Web is Scary" section is important, I do see a lot of people reinventing the wheel but it isn't too hard to get everything to work over PATCH (sadly a verb which didn't take off but is in the specification) and upgrading to WebSockets.
Overall, great post. I hope more people talk about this.
It's not clear to me what's novel about this proposal, compared to existing distributed stores like the Freenet Project (https://freenetproject.org/).
1. This isn't a single proposal
2. It is not trying to be novel relative to existing distributed stores. It is trying to get the features in HTTP that have been used in lots of other custom applications.
2. It is not trying to be novel relative to existing distributed stores. It is trying to get the features in HTTP that have been used in lots of other custom applications.
How is this distributed model going to deal with the fact that a lot of (all of?) the websites we visit have dynamic content?
I feel like I'd be much better off, privacy-wise, if I could get a browser that had a user manageable list of locations to pre-cache with some kind of daily/weekly offline cache refresh. So when I go to a web page that fetches jquery from google's hosted libraries service, it instead pulls it from a locally cached copy and never ever fetches from google as a result of visiting a web page.
I feel like I'd be much better off, privacy-wise, if I could get a browser that had a user manageable list of locations to pre-cache with some kind of daily/weekly offline cache refresh. So when I go to a web page that fetches jquery from google's hosted libraries service, it instead pulls it from a locally cached copy and never ever fetches from google as a result of visiting a web page.
How is this distributed model going to deal with the fact that a lot of (all of?) the websites we visit have dynamic content?
Web content is rarely very dynamic. With the exception of social networks and news sites, most websites would be largely indistinguishable from what they look like now if they were serving the same page as yesterday or a week ago. Technologically we could trade the 'rendered on request' model with the very latest data for a 'rendered and then cached across the internet for a day' distributed model very easily.
Psychologically however, no one would agree to it. People believe their content has to be available to everyone the instant they press Publish.
Web content is rarely very dynamic. With the exception of social networks and news sites, most websites would be largely indistinguishable from what they look like now if they were serving the same page as yesterday or a week ago. Technologically we could trade the 'rendered on request' model with the very latest data for a 'rendered and then cached across the internet for a day' distributed model very easily.
Psychologically however, no one would agree to it. People believe their content has to be available to everyone the instant they press Publish.
I disagree - aside from blog sites or marketing/portfolio type sites basically every web application on the modern internet requires per-user dynamic content to function - e-commerce, banking, productivity apps, social networks, messaging etc. the modern web is all about displaying and processing users data.
Really any distributed cache is only going to be useful as a replacement for existing CDN's serving static assets (and thats totally fine - it would be great to see the democratization of the performance & scalability of a global CDN)
Really any distributed cache is only going to be useful as a replacement for existing CDN's serving static assets (and thats totally fine - it would be great to see the democratization of the performance & scalability of a global CDN)
I am just looking at the many tabs I have open right now.
I would say it is a 50 / 50 % mix. Gmail, Stack overflow, HN are all dynamic. There are a few blogs posts, and tutorials, which are probably mainly static, but get updated on n a regular basis. Newspaper sites, some I am signed into, some I am not.
I would say it is a 50 / 50 % mix. Gmail, Stack overflow, HN are all dynamic. There are a few blogs posts, and tutorials, which are probably mainly static, but get updated on n a regular basis. Newspaper sites, some I am signed into, some I am not.
Isn't this how IPFS works? Content is hashed so it will check to see if you have it locally first, then inside your network, then externally from the the closest node that has the data.
A little bit confused here. HTTP is already distributed, right? It's an open protocol with a very large number of servers serving a variety of content with little to no coordination.
> Finally, cutting the server out of the equation is seen as an opportunity to reset the Web’s balance of power regarding cookies and other forms of tracking; if you don’t request content from its owner, but instead get it from a third party, the owner can’t track you.
This is somewhat of a concerning line. Off the bat, I imagine it's not outside of the realm of possibility that CDNs could collude with "trackers". Yes, idealistically, a completely distributed model performs in such a way that provides no favor to any particular individual. But I don't think it is anywhere near close enough to being proved that the free-rider problem won't skew the issue towards providing trackers a de facto centralization.
Also, this doesn't eliminate other bottlenecks, like tapping into internet exchange hubs. If there are too many CDNs with which to collude, there are certainly not too many hubs. It works better for them, actually, as they can start dragnetting traffic completely outside of even more modern tracking systems like Super Cookies.
We have long past the point that people can no longer intuitively understand what data they leak on the network.
This is somewhat of a concerning line. Off the bat, I imagine it's not outside of the realm of possibility that CDNs could collude with "trackers". Yes, idealistically, a completely distributed model performs in such a way that provides no favor to any particular individual. But I don't think it is anywhere near close enough to being proved that the free-rider problem won't skew the issue towards providing trackers a de facto centralization.
Also, this doesn't eliminate other bottlenecks, like tapping into internet exchange hubs. If there are too many CDNs with which to collude, there are certainly not too many hubs. It works better for them, actually, as they can start dragnetting traffic completely outside of even more modern tracking systems like Super Cookies.
We have long past the point that people can no longer intuitively understand what data they leak on the network.
A more fundamental question, I think, is "Will there be effective distributed authority?". So far, this is problematic at best.
We should supercede authority with better technology. Such as bitcoin.
Being annoying to attack is not superior to the level of trust and certainty made possible with technologies such as DANE and DNSSEC. Which is to say that I agree with you that we should replace authority with better technology, but bitcoin is not such a better technology.
We are going to get a distributed something. He mentions a lot of the existing efforts.
I think these are tough problems but actually mostly solved in different projects that are out there. The hardest part is making the ideas work together and agreeing on protocols.
The solutions that become popular could really help quite a few people. I see it as possibly being the key to society's overall struggle for effective organization.
Right now I believe we need a small number of very flexible distributed protocols to be used as widely as possible, and have most if not all other systems built on top of them. That will mean a high degree of automation in systems integration while supporting diversity and freedom for systems to evolve. If we can do that and solve problems like privacy, synchronization, and latency issues at the same time, we could leverage that type of system for addressing things like inequality and efficient use of resources.
I think these are tough problems but actually mostly solved in different projects that are out there. The hardest part is making the ideas work together and agreeing on protocols.
The solutions that become popular could really help quite a few people. I see it as possibly being the key to society's overall struggle for effective organization.
Right now I believe we need a small number of very flexible distributed protocols to be used as widely as possible, and have most if not all other systems built on top of them. That will mean a high degree of automation in systems integration while supporting diversity and freedom for systems to evolve. If we can do that and solve problems like privacy, synchronization, and latency issues at the same time, we could leverage that type of system for addressing things like inequality and efficient use of resources.
One of the things I wish browsers supported would be signed content... IE your CDN/distributed content doesn't need to be on HTTPS, just have a header with a payload signature against the HTTPS cert that the application host uses... I don't know why such a beast was never introduced into the browsers.
I also feel that it would be nice to see more p2p protocols especially regarding live chat, and other systems. I think having a self-discoverable alternative to IRC could be a pretty nice thing... of course eventually the bots would destroy it if it got popular.
I also feel that it would be nice to see more p2p protocols especially regarding live chat, and other systems. I think having a self-discoverable alternative to IRC could be a pretty nice thing... of course eventually the bots would destroy it if it got popular.
That's actually been discussed quite a lot. However, it shares the "request privacy problem" that I talked about in the blog entry; the mere fact that you're requesting information -- even if it's public -- is sometimes sensitive information.
Keep in mind that the determination of its sensitivity is often highly contextual; e.g., something that's not a problem in your country may be illegal elsewhere, or someone in a different situation to you may feel differently about how their request stream should be treated.
Keep in mind that the determination of its sensitivity is often highly contextual; e.g., something that's not a problem in your country may be illegal elsewhere, or someone in a different situation to you may feel differently about how their request stream should be treated.
Fair enough... my main point was pragmatic... It would be nice to be able to serve certain assets more decentralized and widely distributed than even, for example cdnjs.
jQuery, React, shims for browserify, etc, would all be nice to haves outside of the main payload, and loadable/cacheable on a widely distributed signed system from the browser directly.
jQuery, React, shims for browserify, etc, would all be nice to haves outside of the main payload, and loadable/cacheable on a widely distributed signed system from the browser directly.
So this should be a user choice: Do I run my request through my download public accellerator or do I only get it from the server.
That would be similar to always providing a torrent for every single file — just without needing a torrent server, because the clients can handle that themselves.
That would be similar to always providing a torrent for every single file — just without needing a torrent server, because the clients can handle that themselves.
Do you remember the download mesh? http://rfc-gnutella.sourceforge.net/developer/tmp/download-m...
3 additional HTTP headers for fully distributed downloading.
The server provides an URN and some IPs from participating downloaders and the clients can (but do not have to) swarm that from other clients. Tiger tree hashing ensures that every chunk can be verified, the X-Alt header allows the clients to exchange IPs among themselves (the server does not need to know all) and an X-Nalt header gives distributed disruption avoidance.
Back then I wrote a simple server which provides that: https://bitbucket.org/ArneBab/gnutella_tracker/src/43dc24ddd...
This doesn’t give additional privacy (aside from the effect that the server owner does not need to know whether you just started the download or finished it), but the users can decide themselves where they download from. And the download mesh has proven itself with 50 million users.
3 additional HTTP headers for fully distributed downloading.
The server provides an URN and some IPs from participating downloaders and the clients can (but do not have to) swarm that from other clients. Tiger tree hashing ensures that every chunk can be verified, the X-Alt header allows the clients to exchange IPs among themselves (the server does not need to know all) and an X-Nalt header gives distributed disruption avoidance.
Back then I wrote a simple server which provides that: https://bitbucket.org/ArneBab/gnutella_tracker/src/43dc24ddd...
This doesn’t give additional privacy (aside from the effect that the server owner does not need to know whether you just started the download or finished it), but the users can decide themselves where they download from. And the download mesh has proven itself with 50 million users.
Yes. It's a "steam engine time" thing where the invention manifests in regionally disparate places in roughly the same period due to evolutionary necessity.
Even I have an instance(!): https://github.com/LukeB42/Uroko/tree/development
Even I have an instance(!): https://github.com/LukeB42/Uroko/tree/development
> That certainly isn’t impossible, but it’s going to require a fairly sophisticated protocol to achieve; I’m not aware of one yet, would be happy to be shown otherwise.
Well this means version control. Of course you don't need fine granularity, but version control is a good start to solve that problem.
> What about incrementalism?
Honestly I'd prefer something brand new. HTTP is plaintext just like telnet, which in my opinion is not adequate for such a complex decentralized protocol. If you want performance, look at how bittorrent does it. I think performance is important here, and since decentralization means being more vulnerable attackers, I think the protocol should really be designed around mitigating attacks. But maybe I'm wrong. Telnet or HTTP are things that should not be dealt with, in my opinion. I would gladly see them disappear to be honest.
Well this means version control. Of course you don't need fine granularity, but version control is a good start to solve that problem.
> What about incrementalism?
Honestly I'd prefer something brand new. HTTP is plaintext just like telnet, which in my opinion is not adequate for such a complex decentralized protocol. If you want performance, look at how bittorrent does it. I think performance is important here, and since decentralization means being more vulnerable attackers, I think the protocol should really be designed around mitigating attacks. But maybe I'm wrong. Telnet or HTTP are things that should not be dealt with, in my opinion. I would gladly see them disappear to be honest.
HTTP2 isn't, it's binary.
Version control is not a solution to the problem of shared state in a distributed system.
Version control is not a solution to the problem of shared state in a distributed system.
While it doesn't solve the whole problem of a distributed web, something called MORPHiS has a lot of these concepts handled pretty well. It was on HN a while back, the website is morph.is if you'd like to check it out.
I think he is talking about some semantic routing layer above http where you ask for content without querying a specific source/endpoint in the same way that dhcp looks for an ip address. I call it the neuroweb and I have made some satisfying experiments in this field; the only barrier I can see has to do with performance/scalability since we have schemaless data structures + realtime queries, which can easily bottleneck without some kind of efficient specialized index.
Why is distributed HTTP needed when you could just run a local (web)server that would act as a translator to the peer-based web which you could implement with other protocols? That way, you can continue to use existing browsers. Now you'd just need to implement that server...
Heck if you did it this way, you could just have remote servers actually pull content from the regular web and serve it up through the peer web. It could be similar to a proxy.
Heck if you did it this way, you could just have remote servers actually pull content from the regular web and serve it up through the peer web. It could be similar to a proxy.
There's a similar summary in the ietf draft: http://tools.ietf.org/html/draft-huang-ppsp-p2p-webrtc-surve...
It adds some information about the architecture of each solution.
It adds some information about the architecture of each solution.
i do think there is a lot to be had from p2p technologies. the centralised server is just the obvious and easy solution in most cases...
its a shame webrtc is such a disaster of a project though. it could be truly reusable and powerful... instead its a nightmare of obsolete things, difficult configuration and fictitious problems imposed by bad developers. a lot of this is a legacy of being meant for all kinds of things... but we seem to be lacking a clean and simple p2p library today.
i don't want to depend on systemd or obsolete headers MS deprecated in VC 6.
its a shame webrtc is such a disaster of a project though. it could be truly reusable and powerful... instead its a nightmare of obsolete things, difficult configuration and fictitious problems imposed by bad developers. a lot of this is a legacy of being meant for all kinds of things... but we seem to be lacking a clean and simple p2p library today.
i don't want to depend on systemd or obsolete headers MS deprecated in VC 6.
It's only vaguely related... do any of these new HTTPs (HTTP 2, SPDY, etc) support DNS SRV records for load balancing and failover at the DNS level?
Fundamental problem: either the distributed thing will be an extremely easy target for DoS attacks -- just because the service is distributed doesn't mean the attacker need be; the attacker can be as monolithic as he wants to be -- or, it will be only superficially distributed, and actually hosted on some honking big central infrastructure.
Things that are smaller than Google, Amazon, or Facebook can be DoSed into total oblivion. Abuse is the greatest unsolved problem of distributed systems.
Things that are smaller than Google, Amazon, or Facebook can be DoSed into total oblivion. Abuse is the greatest unsolved problem of distributed systems.
Here's how it could work: IPFS ("In some ways, IPFS is similar to the Web, but IPFS could be seen as a single BitTorrent swarm, exchanging objects within one Git repository") is a globally distributed hash-addressed versioned filesystem. (see: http://ipfs.io/)
They have a mirror of their homepage hosted on IPFS, here: http://gateway.ipfs.io/ipfs/QmeYYwD4y4DgVVdAzhT7wW5vrvmbKPQj...
To answer the question: distributed GET and HEAD are absolutely possible.