Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I don't know what point you're trying to make here. Obviously developers will choose to break compatibility every other day for very flimsy reasons -- I have a million examples, including "Why did Conversations decide to remove OTR support ?" Or even "why are you forking software at all in Snikket?".

My problem here is that XMPP encourages this by adopting a _breaking change_ to a protocol. To my knowledge this is not a client deciding to go out of its way to break compatibility, it's a client deciding to implement the current version of OMEMO and as a consequence ending up incommunicado. If you look at the most recent version of popular XEPs you'll end up with a client that can talk to nobody. This is not a good example of stewardship and doesn't look good look as a candidate for replacing email, a protocol that must last for at least half a century. Core XMPP did look good candidate, but the chase for the shiny has corrupted this protocol as has countless others. Same reason we're down to basically only two workable Jabber server implementations.

Arguments like "oh don't worry, we'll smooth things over by updating all clients in tandem" just don't make me see things better, because I know by experience that it never happens in practice.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: