Thise is not accidental; devs adopt protocols because they are able to understand them and play with them - and most of the devs (grown on stackexchange) have limited capacity to understand and contemplate about something (or just do not want to bother) - that is why “AI” is already able to make a work better than they do. That is why it is not the robustness or security which matters, but simplicity and as few components as possible.
It is the reason why crazy-weird combinations like “Web technology” - an agglomerate of highly-inefficient and insecure HTTP, JavaScript etc - boosted internet adoption, while it took decades to solve this protocol issues with additions like SSL/TLS, HTTP/2, ECMAScript 6, TypeScript etc “ugly sticked as siding”.
IT differs in these terms from other forms of engineering in a way that if in a physical world you would build something with this approach, it will kill people (like cars and electrical equipment can do that) - while in IT the risks are much lower (usually financial) and more tolerable, thus less advanced and secure systems emerge.
So, there are two different strategies in protocol creation and adoption, similar r- and K-strategy in biology ( https://en.wikipedia.org/wiki/R/K_selection_theory ):
* r-strategy: very few devs, careful thoughtful design, high quality
* K-strategy: no design, “evolution as it goes”, development by a crowd of low-quality devs, until eventually something will start working due to a pure “mining of chances”
r-strategy always struggles with adoption, since “very few can understand it”. The only way r-protocols can be adopted is via products, which must be robust and good in UI/UX; i.e. not via dev community/crowd, but via people community/crowd. But usually r-products are not loud in marketing (the only exception is probably apple products - with NeXSTEP-based tech and product/language design teams being very r-like)
On the opposite, with K-strategy, things like JSON happen because they allow not to design a protocol - they are sufficiently agile and malleable to any protocol changes and things will contrinue to “sort of working” - thus devs can start with a “no design” and stick random elements into the network until something would start working. 99% of these protocols will die, but out of 1000 attempts one nostr will appear.
So any carefully-thought solution to nostr design issues (which will cause its painful growth/scaling in the future) is doomed: nostr devs see these not as a design issues but as features that allow them to build products without designing the protocol per se, leveraging JSON agility. So they agree to migrate to binary formats _only_ if they are same flexible as JSON - while the main problem is not a text/binary format but that flexibility, which will cause network decoherence - or centralization around oligopoly of “standard” relays. The funny part is that this r-strategy still can be the strategy which wins.
Details: https://github.com/nostr-protocol/nips/pull/512
