|
|
|
|
|
|
by rytor718
1742 days ago
|
|
|
I missed this, very interesting read. He's not entirely wrong. But why are these protocols frozen? I've never developed one so I may just be ignorant of the challenges there, but if, for example, I wanted the XMPP protocol to be able to work with rich media, what's stopping me from updating said protocol to work with rich media instead of relying on optional extensions? In my mind, users of the protocol will receive the update (if they choose of course), thereby making the feature a default for the protocol that isn't reliant on extensions. I admit I don't fully understand why protocols are frozen in this way, even though I agree with the author that the ones we currently have are definitely frozen. Any insights appreciated! |
|
|
They're not "frozen". As mentioned in a sibling comment I wrote a blog post about this very topic - https://snikket.org/blog/products-vs-protocols/
Your point about optional extensions vs a protocol update isn't really as clear-cut as people think it is. To add a non-optional change to an open protocol in a decentralized network would necessitate blocking people from the network when you roll it out. That's not going to make for a good communication network.
The alternative is what XMPP does. The protocol evolves by adding new extensions, and deprecating old ones. Each extension generally has fallback considerations.
For example when group/offline media sharing was added many years ago, it was designed such that clients implementing the extension could render the media. Older clients, or clients that can't render media (e.g. terminal clients) simply display a URL.
The XMPP Standards Foundation annually publishes its "compliance suites", which (versioned by year) guides implementations on what they need to support. https://xmpp.org/about/compliance-suites.html