USuserbinator·Jan 18, 2021
As someone who has worked on thirdparty clients for IM since the days of MSN Messenger (MSNP), the degradation is sad to see and extremely obvious.
The backend protocol that Teams uses is essentially MS-Skype (as opposed to the "OG Skype" binary P2P one), with some Teams-specific additions. Even the authentication token is called the "skypetoken". The only good thing about that is it should make a thirdparty Teams client relatively straightforward, given that things like https://github.com/EionRobb/skype4pidgin already exist.
All the users see and complain about is the horrid sluggishness, and Electron and the "webapp everything" craze is mostly responsible for that, but the backend protocol itself is also a bloated abomination.
A long time ago I wrote an MSNP client and used it right until MS finally shut down the servers a few years ago
Read the rest
. It was a native Win32 application in a single binary <32KB and barely took any memory (at most a few MB). No audio or video, but IM and presence worked perfectly. Like HTTP, FTP, SMTP, and the other oldschool Internet protocols, MSNP is also a text-based protocol that runs directly over a socket. You could almost use it from a netcat if you really wanted to. It wasn't perfect but everything about it was in some ways sane. If I remember correctly, a single message would be a few dozen bytes of overhead.
The Teams/MS-Skype protocol is a stark contrast. It runs over HTTPS, which is an advantage in some ways with the current trend of stuffing other protocols over it, but it's not like they simply took MSNP and tunneled it over HTTPS, which would've been a far saner approach --- it's radically different and everything is far less efficient and more complex to handle as a result. JSON everywhere. Each message has several hundred bytes of overhead, and more like kilobytes if you count the HTTP layer and everything below it. Things are split between .skype.com and .messenger.live.com with no real consistency. Trying to get presence to actually work reliably has been a nightmare (the official client apparently has problems with that too...) I'm not surprised there's no official documentation on the API/protocol, because it's a bloody mess. As you may guess, I have been trying to write a native client for it.
Some of the features that work well (searching for reaction GIFs) seem unnecessary, and it's almost insulting to see the amount of add-ins and superfluous crap that's available when the core of the program/service is so lacking in comparison.
This may be a rather controversial point, but software quality overall seems to have taken a steep nosedive not long after the whole "everyone can code/diversity/inclusion" movement took off. Yes, apparently everyone can code --- just not very well. I think things like all this proliferation of mostly-useless features are a symptom of that. We are simply seeing the results of quantity over quality in an industry which has shifted to rewarding sheer participation and "disruptive change" over a carefully deliberated path to perfection.