On Fri, Nov 09, 2018 at 10:20:58PM -0500, Paul Wouters wrote:
> Some of this could be used for good, but my experience so far suggests
> it just leads to more centralization.
Centralization is mostly a result of need for efficiency, convenience
and scalability.
I think you're vastly underestimating the effects of strong branding, and the consequences of information asymmetry in purchasing services, actually, alongside a dozen other factors. People do not, after all, buy Coca Cola (or even wine) for the taste compared to its rivals, nor the cost. However, your implicit assertion that there are benefits to centralization is of course quite correct.
Centralization is not, in and of itself, a bad thing. Having large providers who can take advantage of economies of scale means that end-users can enjoy the services at a lower price, and this expands access, and from there it follows that - assuming we believe that the technology we design generally improves people's lives - the world is a better place.
But I do believe that, in order to maximize their shareholder value, the larger service providers act in monopolistic ways, or form cartels, in order to control the technology and its standards... In the case of WHAT-WG, I think that's obvious, but there are a number of less overt cases. This in turn cements their position, and places them in a position of power over people and their data which at best is questionable, at worst outright dangerous. I believe this runs the risk of outweighing any positive benefits.
There are strong protections in place in most jurisdictions against collusion on price in a cartel or monopoly, but we do not have the same protections in place to prevent direct collusion in technology standards which can similarly lead to greater control of the market to the detriment of the consumers.
Mom-n-pops can't really run a good datacenter, and so
on. So one way or another we end up centralizing. Of course, we could
still maintain cloud / CDN vendor mobility, and be distributed at a
layer where that mobility can be taken advantage of to get us
resilience. But it's too late for many services.
There is, of course, always the great question of why a mom-n-pop needs to run a content delivery network and a multi-availability-zone datacentre in order to run basic services - indeed, in those services where federation has been a success, it's not really the case. We've addressed scalability and availability in the web by introducing "heavy" technical fixes like load balancers and so on (which, incidentally, are invisible to the standards model), whereas we've addressed the same in email and XMPP through largely different means like SRV and MX.
Loosely, we've made the endpoints in these protocols - particularly the clients - play a greater part in handling scaling and availability, and - perhaps - the result is stronger provider independence, less centralisation, and (I suspect) more complex configuration for trivial cases.
If anyone has concrete suggestions for how to improve XMPP, and in particular, making the deployment of a new XMPP domain simpler, I'd welcome suggestions. At the moment, however, my feeling is our biggest barrier is that we've trained the market so thoroughly that all application services run over HTTP that any deviation from this model is met with bewilderment and confusion. Perhaps we need a specification for XMPP S2S over Websockets and BOSH. :-)
Dave.
