This was a ironic comment: the grotesque and absurd complexity and size of a Big Tech engine (google blink/geeko | apple webkit) with their SDK (c++ compilers,

This was a ironic comment: the grotesque and absurd complexity and size of a Big Tech engine (google blink/geeko | apple webkit) with their SDK (c++ compilers, gcc/clang) kill any "real-life" attempt at interop. You would need many, MANY good devs, for a significant amount of time to maybe acheive 'real-life' compatibility in, pheeew, some significant amount of time... if ever... And even when you get something "working", don't forget they control also the online services requiring their pieces of software... namely those guys will have to play cat and mouse about interop: permanent little changes on Big Tech services (more or less justified) and Big Tech web engines, breaking any other alternatives... I think you get the picture. And that is exactly the same issue with the c++ language syntax and its compilers (that would be the same issue with other complex computer languages like rust/java/etc). Seriously, I would go for a modular implementation directly in 64bits RISC-V assembly with a very small macro-preprocessor (because, moving the complexity from the language syntax to the macro-preprocessor would be riduculous). That's why, from this perspective, those small attempts are kind of pointless and even somewhat dishonnest since, in the end/'real-life', they are just font-ends of Big Tech... The email people did see the DNS "barrier" coming: it has always supported literal IPv4 addresses (and a similar IPv6 literal has been in specs for ages). Using the "excuse" of spam/phishing of script kiddies, they blocked IPv4 literal support and ignored the subsequent IPv6 literal support. If I recall well, IPv4 literal support was a thing on google mail a few years ago (even IPv6 if I recall properly), it means it was explicitely blocked. Then to get SMTP interop with them: you MUST rent/pay for a domain name, and in the last few years, very slowly but surely (I did live it, horrible), the DNS registars did stop working without a Big Tech web engine (they were working fine with lynx or links or netsurf, namely noscript/basic (x)html, which is more than enough, actually even overkill). Basically, they have big services, and they made sure that, slowly and in the end, you must use their software for their services, and they could not careless of the small alternatives even if the internet protocols did account for this. This is compuserve/AOL all over again. The remaining/surviving "small" did just cave in and is part of the problem now. The only sane way out of this "dominance" is to restore interop with simple , but good enough to do the job, and really stable in time protocols. And restoring 'interop' won't happen asking nicely: only hardcore _technical_ regulation can do it now. All is about technical interfaces: the very hard part is they must be simple and stable in time, _while doing a good enough job_. Ofc, things may significantly change, significant new usages can arise... then new simple and stable in time technical interfaces will have to be designed (but one or a small number of average devs should get it implemented in a reasonable amount of time), or new simple and stable in time "layers" added an an existing technical interface (the core of the dynamic web is noscript with basic (x)html forms, and I think it is already way too complicated). A set of layered and modular technical interfaces, but all simple and stable in time. Ofc, if there are billions of interfaces required to support a basic use case, there is something wrong somewhere... I did reach a point where I would not be even surprised if they did shadow-pay hackers to bring down any simple and stable alternatives. It far from easy to deal with all of this.