> Hypothesis: it would be better to live in a world where UI is mostly user-authored, and B2C is mostly an API marketplace.

I tentatively believe in this hypothesis. That's part of the reason I moved most of my computing into Emacs - I get greater control over the UI there, and reap the benefits of deep interoperability.

I think this would be a working system. You'd have a separate market for services, and a separate market for software consuming these services. I doubt most regular people would become full-blown creators, but they would happily shop for more ergonomic tools and customize them to the limit of their needs. It's kind of similar to the "right to repair", where nobody honestly expects that everyone will be fixing their appliances themselves - the point is that those who can, would, and they would also offer their services to those who can't or don't want.

I'm not sure how to get to this world. That's kind of the question in my original post - I see fixing the browser for productive use to be a potential stepping stone involving the same or similar changes.

I have one idea I'm hesitant about: it would be nice if we could force all services on the Internet to communicate with open and documented protocols and APIs, while simultaneously banning any kind of "you can only use our official app" clauses in ToS. That is, force the decoupling between a service and client software that consumes it.

I like the idea, but I think most users never would/could author their own UI's, and many who could would only want to a small percentage of the time.... but maybe your idea could work if there was essentially an API marketplace AND a UI marketplace, and services competed on both of them seperately... v1 from a service would (probably) always offer both to be usable but if it published some contract for how they talk to each other so they were decoupled and anyone could author a new UI (and, I suppose if it were a marketplace, sell it, but maybe given constraints only selling the API is realistic and UI is more FOSS/enthusiast driven/fork based?) and make it discoverable as an alternative to try out.

I think having a distinct separation between back-ends and swappable front-ends would be a good thing, but by this point, it would require government intervention to make it happen. Twitter, Facebook, etc. froze out third-party clients to protect their advertising revenue. They're not going to let third-party clients back in unless they're forced to, and such a move by the government would be tantamount to declaring war on the advertising industry, so, it's not likely to happen.

I agree with your points here, and I think two markets - service API market and client software market - would be a great thing to have. One of the things that makes a lot of services suck (social media platforms in particular) is the control they have on APIs they provide. To pick one example, I can sort of use the Facebook API for some of the things, after jumping through enough contractual hoops, but I can't really go and build a Facebook client that would have feature parity with the official one. Not without risking my account getting banned. I especially couldn't distribute such a client either.

To do this we need to build technologies that can work with information and meaning in code in addition to data. Users think in terms of information and meaning much more than in terms of data. These technologies would allow us to build code in the language that users use. This will give us the right tools to build meaningful user interfaces easily. In other words, we need the right tools for the job. I am building one of the many tools needed for this. It is called the endeme. It is a library for c# that can be found here: https://github.com/jonrgroverlib/InfoLib. Discussion can be found here: https://thisstack.wordpress.com.