I agree that it would be helpful if we had more open protocols but I disagree with the conclusion that not having them inevitably leads to AOL 2.0. First, I t

I agree that it would be helpful if we had more open protocols but I disagree with the conclusion that not having them inevitably leads to AOL 2.0. First, I think it's helpful to clarify what jacquesm is saying. My interpretation in concrete terms of URI[1]. URI: <scheme>://<location>:<port> As of 2015, the scheme is almost always "http" or "https" and the port is almost always "80" or "443". Because of many factors (I'd say mostly social dynamics[2], not technical), companies end up layering their proprietary/opaque protocols on top of "http". I believe the essay asserts that the web would be more "free" and "open" if we pursued more "schemes"[3] For example, if you're starting a new company that lets people crowdshare cooking recipes, the 1980s mindset may have been to submit a new RFC so everyone could then do: cooking://johndoe.com (and default port for "cooking://" would be 867 or whatever) Instead, we now have a situation where we have a cooking REST API or cooking iPhone/Android app that sends proprietary undocumented bytes over "http". Yes, the "http" is open in an academic sense, but for practical purposes, the cooking data is "closed" because the bytes over it are proprietary. Related to this is that the bytes go to a central entity that has self-interested economic motives instead of a peer-to-peer situation like "ftp://" or SMTP email. I don't have to time at the moment fully explain my disagreement but I don't believe this leads to AOL 2.0. Instead, what happens is that the proprietary protocols simply become more inefficient by "tunneling" or "layering" in or on top of "http". We collectively waste lots of HTML/MIME overhead bytes to send opaque data. We also expend a lot of security effort with cat & mouse "deep packet inspection" of "http" because of this. Lots of cpu cycles are burned up to pay for these inefficiencies. As for pushing for the ideal of more schemes with public and transparent RFCs, this is a goal that's couched in technical terms and it hides what we're really asking of each other: we are asking economic actors to forego their economic interests. That is a very tough sell. For example, in the USA, there's Intuit Quicken and they have a proprietary transport for downloading financial transactions. I loathe Intuit and their business practices but I do understand why their protocol is opaque instead of being an RFC. They are the ones that did all the legwork of convincing the banks to open up their mainframes to facilitate data downloads. The government didn't grease the wheels; Intuit did. Now they want to be rewarded economically for it. Can't blame them. That's why it's not an open RFC. Contrast Intuit's situation with the public RFCs for "ftp://" and SMTP. The people creating those protocols were economically secure. They had stable jobs at universities or government institutions. Today, the opaque protocols are made by actors in a different economic landscape. If a YC2015 company takes $130k from ycombinator and several million $$$ from VC rounds, defining a transparent RFC that harms their economic interests doesn't make sense. This goes against human nature. The essays pushing for a more open web are not addressing the hard-to-resolve economic interests. [1]https://en.wikipedia.org/wiki/URI_scheme#Generic_syntax https://en.wikipedia.org/wiki/URI_scheme#Generic_syntax [2]corporate firewalls and network appliances policies of restricting ports, users' home computers' firewalls default config of blocking ports, etc. New software can't expect to reverse the conservatism of Cisco admins, etc. Also look at why residential SMTP mail servers are blocked by others even though SMTP is theoretically "open". That's a social problem caused by spam. [3]https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml https://www.iana.org/assignments/uri-schemes/uri-schemes.xht...