There was a brief period in the aughts when Pidgin and libpurple covered almost all messaging platforms in a single application. AIM, ICQ, MSN Messenger, Jabber, IRC, you name it. You could even layer on encryption with the OTR plugin, message logging, automation and countless other plugins.
At the time I took this for granted and didn't appreciate just how wonderful it was.
I used to work on Gaim/Pidgin (and in fact created libgaim/libpurple) back in my college days.
It was easier for us to build and maintain back then. We had push-back from some of the companies (Yahoo being notoriously aggressive about it, to the point of actively banning our developers' accounts and inventing new obfuscated auth schemes all the time), but from a technical standpoint:
1. Most of these were communicating over plain text channels (making it easy to sniff traffic from official clients)
2. The protocols were generally understandable (MSN for a long time was largely all MIME-based messages, and could be understood by watching a traffic stream)
3. Used simple usernames/passwords for authentication (just fewer hoops to jump through)
It's a different world nowadays, with more focus on keeping you in the chat environment and offering additional features as part of that experience. Harder to abstract a lot of that out.
That said, Gary Kramlich's been working on this diligently. (If interested, he also regularly streams development over at https://www.twitch.tv/rw_grim).
The protocols were generally understandable (MSN for a long time was largely all MIME-based messages, and could be understood by watching a traffic stream)
Microsoft even submitted an early draft of MSNP to the IETF. I'd consider (at least the early versions) MSNP the next step up in complexity from IRC, i.e. you can write a working client with both presence and messaging within a day or two. This is from experience of having written a client myself, which I used all the way up to them shutting down the servers.
Used simple usernames/passwords for authentication (just fewer hoops to jump through)
Earliest ones were literally plain user/pass, then followed challenge-response, and later MSNP used something surprisingly similar to OAuth, where you authenticate out-of-band to get a token that is then submitted to the protocol server itself.
I had forgotten they tried to standardize the protocol!
Yeah, it was surprisingly easy. Connect to the switchboard server, set up sessions from there, and then it's all MIME. We even implemented avatars for Gaim by chunking Base64-encoded images over MIME messages (they had a max length), which MSN would ignore but Gaim would use.
We never had any trouble from the MSN team. Rumor had it at the time that at least one dev on the team was secretly a Gaim user, and they just looked the other way.
I never released it, as there were plenty of others already available at the time. It was written in pure Win32, and a single portable .exe of <32KB.
We never had any trouble from the MSN team.
Judging by the huge number of other thirdparty clients, I don't think Microsoft bothered to do anything about them, and almost treated it like they did Windows piracy --- they would rather you use a thirdparty client with MSN than a competitor's network; I suspect the fact that this was also not long after their antitrust lawsuit also had some influence.
Begrudgingly-former Adium (~Mac equivalent of Pidgin) user here: it was glorious indeed!
I didn’t take it for granted because I had already been using the prior iteration of incompatible chat apps soup, and I clung to it far longer than most reasonable people would as it became a ghost town on supported protocols.
The biggest exodus at the time (from my perspective) was when Google closed up whatever their current branded chat service was. But the real nail in the coffin (again from my perspective) was Slack, for the fairly obvious reasons that chat is their primary product and active/paying users is their primary product. Of course the rise of other chat-first apps successful with the youngs, and well positioned instant incumbents from social media, the coffin had many nails.
But it really is a shame this era came to an end. I don’t know how it could have gone differently given the incentives and circumstances, but I’d go back to those tradeoffs (basically everything works in one native app where I can talk to anyone I know however I want to, but probably direct file transfers are gonna fail most of the time) in a heartbeat.
You may be interested to know that Pidgin 3 is targeting macOS natively. We don't have a release date yet, but we are inching closer and closer to an alpha which I've written a blog post about what we're targeting with it. Yes this is on patreon but it's public https://www.patreon.com/posts/what-were-with-3-78291546
When Apple dropped iChat it hurt too. I agree with you that Google was the mail in the coffin but the fact that there was no way for me to go from my .Mac iChat account to iMessage seamlessly (I could use the same ID but had to add everyone as contacts again).
Slack was definitely a major blow. I used Campfire at work but we still had to use other services, usually gChat, to message privately. When we migrated to Slack in 2014 or whatever, we now had a service that allowed private messaging AND had mobile apps too — something that the old era of the Adium/Pidgin/Trillian’s never quite executed on (I know there were mobile AIM and gChat clients back in the day; I had AIM on my SideKick in high school and a number of decentish apps on iOS even, but those protocols just weren’t ever designed or well-adapted/executed to push messaging a la BBM or iMessage or SMS the way it needed to be — largely thanks to the wireless carriers who wanted to keep a hold of that pure profit SMS for as long as possible.) We had mobile-first/mobile-only services like WhatsApp (which immediately took off outside the US) and the GroupMe’s had some success too, but those services were slow to support (if they ever did) XMPP or other bridges to get them working on desktop), so Slack was a nice unifier.
I loved Adium for so long. I even had a Slack bridge I think in it at some point. But I had to finally let it go and remove it from my dock.
I pay for Beeper today, but I don’t use it as much as I would like. But it remains one of the better ways for me to recreate the world I had 10 and 15 years ago.
Matrix is working on bringing that world back, and works pretty well, although configuring a homeserver with the necessary bridges is more difficult than pidgin was.
And there's still not a single decent Matrix client for macOS. Best case you get some ugly-ass QT thing that doesn't work anything like a macOS app would. The official and most featureful Matrix client is even worse than that, it's an electron app, ugh.
The Matrix protocol itself sometimes also leaves much to be desired. It's much more modern than XMPP, that's true, but the fact that you can't send an image with text in a single message is just... How did everyone involved decide that it's reasonable? Did people design the UX on top of a protocol when it should always be done the other way around?
Which specific Facebook messenger UI are you talking about? There are two just on the web alone.
The main issue I'm having with every single of the modern IM apps is that they combine the chat list and the chat switcher into a single control. It's part of the overall unfortunate trend of touchscreen-ification of desktop UIs. Tabbed chat windows need to make a comeback, yesterday.
This still has the problem of touchscreen-ification. I'm talking more about this sort of thing: https://i.imgur.com/uRkrpb0.png, this example isn't the best (the UI is confusing and too cryptic), but you get the idea. Separate window with chat/contact list, separate tabbed window with chats themselves.
We're still here!! And there's a ton of support for stuff via third party protocols. I know it's not ideal, but things will get easier when Pidgin 3 finally gets closer to a release.
In practice it's mostly whatever Jabber had, which is mostly whatever libpurple has.
We're not really moving forward with the proprietary chat protocols (Slack, Teams, Whatsapp). It is a much, much harder problem to solve than MSN and Yahoo ever was.
It took a while, but it's gotten pretty good again. Harder to get plugins running than it used to be, but now there's Slack, Matrix, Teams, and (shameless plug) GroupMe[1]. Works well enough for me these days :)
Back in the day I also used Miranda, a lightweight multiplatform messenger for Windows which I liked a lot. And later, Pidgin on Linux.
The status messages on ICQ and MSN were neat and anticipated Twitter for me.
What made it difficult for me was the added features of certain platforms. ICQ had little games and fancy emojis, and if somebody sent them to you you would miss it. I was really afraid to miss important social interactions :-). Also these apps didn't make the move to mobile, unfortunately.
I still use Pidgin regularly to this very day. Of course I only really use it for XMPP, but I did actually configure it to connect to my old ICQ account a while back. Unfortunately is seems to have quit working sometime or other. Think I'm being bit by this:
No big loss, I think there was like 1 other person in my ICQ contacts list that was still showing as online every now and then. Still, it's a neat nostalgia indulgence to connect to ICQ after all these years...
EDIT: I rebuilt icyque from the latest sources and it appears that I can once again enjoy the wonderful world of ICQ!
Check this out: https://nina.chat/
Nina/Escargot are working to bring back Aim, AOL, ICQ, Yahoo Messenger and MSN messenger via a new opensource cross-chatting unified system.
Looks like OMEMO support hasn't landed either https://issues.imfreedom.org/issue/PIDGIN-16801 The Pidgin/libpurple team has a lot to handle as all of these proprietary chat options are constantly moving targets and trying to maintain feature parity on all of them. At least the FOSS options have publicly-documented specs and aren't actively hostile towards reverse engineering.
Awesome. I hadn't seen that. I remember using OTR in the past and switching from machines didn't really work, but the multi-client support that OMEMO brings though is pretty critical in a time where a most have multiple devices. Is this something v4 brings?
You might want to check out matrix.org. It's its own protocol, so there is no "universal client" like pidgin. However you can easily host a homeserver and "bridge" a lot of protocols. Personally I only have tried telegram, and it works quite well for what it is. Since all the modern chat apps are not open protocols, the bridges usually work over some kind of limited bot APIs.
On the topic of super powers, I remember using a Pidgin plug-in that would pop-up a chat window if someone is typing a message for you, even before they sent their first message. That's because their client was sending a "User is typing..." signal. The plug-in would notice this signal, open the chat window and notify you with the sentence "You feel a disturbance in the force..."
Eion Robb has done an incredible amount of work in this space. His GitHub page[1] has tons of plugins, and I particularly appreciate the work he has done on the Matrix plugin to make it available to Windows users.
Lest you think this is less than cool because you don't use Pidgin, bitlbee[2] is a great tool to get slack (and others!) into your IRC client. I haven't run it myself, but I know that it heavily relies on purple[3] for its magic. I can tell it gets a lot of use, perusing the issues on the slack purple plugin[4] for example.
The protocol is far from being os-specific, but it does call for a lot of crypto facilities calls, which if you're not careful you might end up making os-specific.
Less OS specific and more "compilable", he took a plug in that was written in C and made sure it was cross-platform enough and compiled it on Windows for us.
I used Pidgin around 15+ years ago. Around the time of MSN messenger. Cool that it is still around although this reminder of it has made me long for the days I would log on to my PC and chat with my friends (IRL and Online).
Now I'm more connected than ever - I have everyone I know IRL on WhatsApp, FB Messenger, Instagram - but also never chat to people in the same way. I only chat to people I don't know IRL through sites like HN or Reddit which, in 7+ years, has never led to a connection with someone.
I generally just include a note about how easy it is to find my contact info in comments where contact would be welcome. I’m often surprised that some people bite.
Other times people have intuited this without me explicitly saying so. To credit the HN community, these surprise off-site contacts have been 100% positive so far. (I really hope I didn’t jinx that with this comment.)
Imagine a chat application with Teams that is actually /usable/. I really miss the days of Pidgin.
Fun fact: the KDE / Linux client for MSN had a feature whereby it would notify me (by opening a window) if someone had clicked on my profile in MSN Messenger and started typing a message, but not yet sent it. It was a really nice way of freaking regular MSN Messenger users out.
I cannot remember what the name of the application was but it was very handy.
A lot of thirdparty clients did that, and it's a natural consequence of the protocol relying on creating sessions (ephemeral chat rooms is a good description of what they're like), which its participant(s) are notified of being added to prior to the first message being sent; but the official client just keeps track of the session creations and doesn't actually indicate any activity in a session until a message is sent.
Yeah we're trying to tackle the usability stuff in Pidgin 3. Unfortunately due to API guarantees we just can't make the changes people want in purple2/pidgin2, so it is what it is. We are nearing an alpha soon (tm) (no date set) but they goal is to have basic pidgin 2 functionality with the ability to add all the new features.
There were a bunch of apps back in the day that could hook into MSN Messenger to provide a whole bunch of functionality like this. It could tell you when people closed their chat windows.
If there were ever two apps I had the opposite feelings about, they're Pidgin and Teams.
I loved Pidgin when I was a kid, and really admired its developers. I remember it as a reliable, flexible, unobtrusive, lightweight app that simplified my life. If I could run Pidgin instead of Teams at work, I would be so, so happy.
I don't want most of Teams' embedded Office widgets. I'd rather use the full fat Office apps, or the web browser versions, where at least I can hack in my own 'dark mode' to help with contrast issues I have.
I can't think of anything built into Teams which I don't remember Pidgin having that I would not gladly give up.
Every MS product (except for maybe VSCode and latest .NET) feels like Gates and Ballmer are still there saying "whatever - you'll have to use this because your $BIGCORP bought it from our salespeople!"
Aren't designers also responsible for the designs of the most pleasant GUI apps we ever use?
It seems like the real problem has to be deeper, having to do with upstream business demands or fashion trends among UI designers pushing designs from their original contexts into contexts where they no longer make sense.
On a computer, shrink the Teams application to its smallest allowed size, the hold up your phone next to it. Teams can display on the phone, so why can't you shrink it down to a phone size?
cmon microsoft let me have my small chats. It's been in your uservoice thingy ever since launch.
pidgin + libpurple is great, and it makes interacting with Slack and other chat systems I use daily so much better. It's too bad libpurple clients seem to have withered on other platforms (what happened to Adium?)
I really miss the days of a unified chat application (anyone remember how amazon the chat app on the Palm Pre was? It'd seamlessly switch between jabber/aol/messenger and sms)
I've even written my own libpurple plugins for chat systems I've had to use. I do wish libpurple had better tutorials and documentation though!
I'm planning on doing all sorts of tutorials for pidgin 3 when it gets closer to release. Things are so much different that it's going to be a requirement to get people to port stuff :)
With the rate of feature change in Teams I'd be afraid to use something like this. I have a hard enough time trusting the official client to work! Beeper was working on a Teams bridge but threw in a towel for, as I understand it, similar reasons.
There's user interface stability and then there's API stability. To backend API is probably much more stable so that the front end has something to lean on when it does all of its changes.
I mean things like polls, additional message reactions, self chat, and pinned chats (looking at new features from last year) not just front end stuff like message density, theme changes, and whatnot.
Many of these probably just extend the existing API and others may not break things just not work but if someone pins a chat, starts a poll, or sends a new reaction and you don't know it because your client isn't keeping as up to date with these sorts of things it can be annoying at best and problematic at worst. It gets especially bad if you consider meeting chats, it seems like there is an endless stream of new functionality happening there like stuff around breakout rooms.
From what i could tell about 2 years ago, if you stuck to the skype (for business) API you would get functionnal messaging and maybe calls, but anything beyond sending and recieving messages (basically anything that you couldn't find in a skype for business client) would break and break often.
It's a rather odd memory I have, but IIRC IETF hummed and hawed about certifying XMPP. As I recall it, there was a plenary where the IESG/IAB was taken to task by the WG participants who basically said if the IETF didn't get of its bum and WGLC the docs, they were going to make a lot of noise and walk to another SDO.
I totally did not understand what was the issue. I suspect, but only suspect it was the intersection of the vendor specific aspects of closed-walled-gardens, and not entirely grokking applications-layer specification in a body which focuses on the transport-network-routing layer problems a lot.
How does this even work? I’ve never managed to penetrate the MS API’s for chat, and as far as I’d found it’s impossible without apps installed by your workplace admin.
It just does the same things the official client does. The fact that it's a REST API makes inspecting the traffic relatively easy, although that trades off efficiency compared to the custom protocols that a lot of early IM clients used.
Note that the resemblance to Skype (and even references to Skype in the source code) are not coincidences; Teams is AFAIK largely based on the same backend as MS-Skype.
Early teams was fully compatible with skype for business, they were 2 front ends for the same API. The API has changed a lot since then but the very basic things are still skype-themed
This would be great until someone sends you something "important" via a built-in game or something that Pidgin can't display and then everyone will get confused when you didn't get the memo. I gave up on running a plain text email client years ago and that's supposed to be an open standard.
This dynamic content is normally a part of a multipart MIME message.
Should be opened with an external viewer in case the e-mail client program can not display it inline.
Regarding the MS teams, plain text messaging covers a huge part of use cases, provided the third party client implementation warns the user about limited rendering support, allowing fallback to genuine MS client.
Thanks. What protocol spec did you implement? Is it documented or reverse engineered? I ask only so we can watch for which ones Microsoft is most likely to iterate and change.
At the time I took this for granted and didn't appreciate just how wonderful it was.