Adium (https://adium.im/) used to be the MacOSX native version (port) of Pidgin. It seems they still recommend it. However, Adium seems kind of dead? Last commit (https://github.com/adium/adium/) was in 2016.
I build a MacOSX app bundle for the original Pidgin long time ago (https://sourceforge.net/projects/pidgin-macosx/). At that point in time, this was not so trivial, as the GTK support for native MacOSX was experimental (http://www.gtk-osx.org/). You could simply use the X11 GTK version but I rather wanted to have a native version. I have no idea what the current state is with GTK on MacOSX. This Pidgin build is obviously very outdated now (from 2009), and probably does not run on recent MacOSX versions (they are frequently breaking backward compatibility...).
I worked on Pidgin (Gaim, at the time), and was the original author of libpurple (now libgaim). Adium was a sister project that was originally completely different, but utilized some of our Protocol Plugins (aka prpls — basis for the name "libpurple"). It later utilized libgaim when it reached a certain level of maturity.
I don't know whether Adium eventually moved fully onto libgaim. I seem to recall it only used it selectively, but I stopped working on those projects years ago.
Been very happy to Pidgin's maintenance resume. Gary Kramlich's been doing a fantastic job reviving it, and I'm hoping the same will be done for Adium in time. We really need a modern multi-chat/IM client for the modern era.
GTK on macOS is completely fine, unless newer versions of GTK have borked it. We use GTK2 for Ardour (cross platform DAW) and there are almost no issues. I did contribute numerous important patches for the quartz backend along the way.
Gtk3 has a Quartz backend and Pidgin 3 will be native on Mac OS. It builds and runs now, but packaging has been a pain so I haven't worked that into our CI yet.
But as I understand it, Adium can't just use the same plugins as Pidgin, they're very similar but need to be modified a bit.
I ran into this ~ 6 months ago when I was trying to make Slack work in Adium. The plugin for Slack was outdated. There was a newer libpurple Slack plugin, but it wasn't compiled for Adium. I attempted to recompile it, but I couldn't seem to manage it, all of the tutorials on how to do it were super confusing...
(If anyone knows how to make Slack work in Adium in 2021, please let me know!)
I had friends of MSN Messenger, Yahoo Messenger, GTalk and for a very limited time ICQ (Actually it was the same guys on all networks :) ). There weren't any network effort, people were willing to try out different IMs for their uniqueness.
Lots of companies were trying to produce integrated chat clients - Pidgin, Meebo, Trillian, Digsby and a whole lot of guys on Mobile targeting Symbian OS (could recollect only Nimbuzz though.) I loved Digsby because it acted as a POP client too.
I even worked for a company that forked Ignite Realtime Spark and tried adding Gtalk and MSN support. When I was freelancing one guy asked me to clone meebo for $500 .. and I accepted :facepalm.
It remains something of a testament to human stupidity and avarice that chat to most of the world in most languages with pretty good security and even some video support was basically a solved problem in like 2008 and a complete clusterfuck again by 2016.
And probably soon enough again with the crap being pulled by FB to turn away from the WhatsApp monopoly.
I hope this time people will understand that the app isn't what matters, but the protocol is (with providers coming and going without that meaning to have to restart over and over again somewhere else and losing everything and everyone in the process).
I wish for open and federated protocols to gain recognition and adoption up to a point where we could just move on with the drama, ah!
I'm not aware of how good the clients worked at the time, but I believe there still are some features that were developped in the meantime that were not there:
- privacy in general, with asynchronous e2ee with forward secrecy and minimization of metadata
- reactions. They might sound childish but they're a good way of acknowledging something without polluting the chat itself
- proper support of files, including easy display of all media and search
- probably the biggest: voice/video calls. "Some support" clearly wasn't good enough.
Now it's a really hard place for Pidgin to sit in, because it can only follow what the protocols do, not push them to do more or to standardize.
I used Digsby for so long, once they stopped developing was about the time I moved off those chat clients to Skype.
Meebo too, back in high school we'd play cat and mouse with Meebo Repeater, and a few other fun sites (an image board for our school, a really rough freeware proxy) with the IT guys. All run out of old pcs we had in our closests. Highlight was when they redirected the free url we were using to Barney.com
Oh man, this brings me back. I'm sitting a block away from the old Meebo office right now. I'm still bitter about Google buying out and killing the app.
> When I was freelancing one guy asked me to clone meebo for $500 .. and I accepted :facepalm.
We've all said yes to those kinds of deals at least once. I once did a website for a company full-stack from setting up the backend to design and frontend JS for ~$600. I wasn't as experienced so I didn't value my work as much as I should have.
Does nobody remember Pidgin? It was one of the first things a lot of people installed on their machines 15 years ago along with Firefox. We used it as an alternative client to AOL Instant Messenger and Yahoo Messenger. It used to be called GAIM.
Mate, the general population increasingly don’t even use desktops or laptops for personal usage anymore let alone a desktop OS specific IM client from the early 2000s.
when steam engines were replaced with the otto motor and cars became available to the general population, people were able to repair and understand the engines themselves. they had an understanding of mechanical principles. a few generations later, and only car nerds understand cars.
everyone else has to go to a mechanic to understand why their car's engine won't start or why it sounds so strange. and those weird mechanics will fix the car for them.
nowadays people are mechanically illiterate.
/s
my point is, when a technology becomes convenient enough so we don't have to think about it while it fulfills it's purpose, then you don't have to understand it to use it.
this creates the need for specialists. is that a bad thing? i say no. who defines what should be basic knowledge and what not? we don't all need to be a mechanic, a chemist, a doctor and an ITC pro.
I don't think the point of that "Kids can't use computers" article is that everyone should be technically proficient with computers. Rather, it's an argument against the common misconception that kids have a natural technical proficiency with computers because they grew up with them.
The author makes his point pretty clear here:
> Not really knowing how to use a computer is deemed acceptable if you're twenty-five or over. It's something that some people are even perversely proud of, but the prevailing wisdom is that all under eighteens are technical wizards, and this is simply not true.
He then offers some suggestions for how to help kids become more technically proficient with computers because he thinks it's a useful skill to have.
Okay but people who aren't mechanics, but drive, still know how to do things like turn the car on, and understand that if they turn the steering wheel right, the wheels point to the right. They understand that the car needs gas, even if they don't really know why it needs gas.
People who don't know how to use computers treat them like a magic box that may or may not do what they want to, if they use the right magical incantation.
Computers inexplicably don't do what you want them to do all the time, though. Modern cars, by contrast, are incredibly reliable even with extremely insufficient maintenance.
I beg to differ: my Mazda MX-5 has a lane departure warning system that flatly gets it wrong all the time. My prior car, a Scion iA, mis-triggered the "smart city breaking" on the freeway and nearly caused an accident. The infotainment system fails bluetooth connections inexplicably, and flatly refuses at accept CarPlay or Android Auto connections periodically. And I keep my cars clean and current with maintenance.
I think you’d be surprised just how much new car owners/drivers do not know about how to work a car. The number of people I’ve seen confused by how to fill a gas tank — let alone what type of gas to use, is massive. And it’ll only get worse as we move to electric and self-driving cars.
And then there is the stuff that is often different car to car, like where lights are, how to adjust certain settings. Want to pair the Bluetooth in your Mercedes to your phone? I consider myself extremely proficient at computers and absolutely know how to use one in almost any capacity and even I’ve struggled with its lunacy (which is much more a reflection on Mercedes bad in-car systems that vary model year to model year and can differ based on what options your dealer ordered).
Maybe in Oregon. Everywhere I've lived people haven't panicked over filling up their gas tank? As a matter of fact I've never encountered a single person ever wandering around the gas station parking lot asking other for help on filling their tank....
Perhaps tangential - but what Mercedes models are you referring to? I've driven multiple recent Mercedes, A220, C300, CLA250, and have never had a real problem connecting the bluetooth on my phone. I believe all of these models have had a spin-dial media interface though - I can't stand touchscreen interfaces in cars - totally unintuitive and inconvenient while you're driving.
> when a technology becomes convenient enough so we don't have to think about it while it fulfills it's purpose,
Is a tragically limited view of what computers are.
Programmable computers are fundamentally different from steam engines. A steam engine will never be anything except a steam engine. Most of the manufactured objects we encounter in everyday life are similar: single- (or occasionally multi-) purpose goods that do what they were designed to do.
A general-purpose computer is not like this. It can be made to serve virtually infinite purposes. It can be made to do things the manufacturers never imagined anyone doing, and things the manufacturers wished it couldn't do.[0] Almost nothing else has that kind of raw potential for human expression. Perhaps a blank notepad and pen might be analogous.
On the contrary, the analogy is very good. The steam engine represents power. Power can be used for a limitless number of applications. The steam engine is the CPU. You input energy (pressure/electricity) and extract work (mechanical/computational).
I don't think it's the same. A steam engine is more like a wagon or a truck. The steam engine can power many things; a truck can haul many different sorts of goods, but they're still fundamentally single-purpose. The engine powers, the wagon hauls.
I guess you could say a computer computes, but that's using an overly broad term to deliberately elide the point.
Nope. A computer can only do what the apps installed on it let you do, unless you're an IT person.
The things is that you don't need to be an IT person to use applications, as it used to be. So fewer people learn IT skills just so they can play a game or layout a document.
I know very little about cars but drive one daily. I can see how other people don't bother learning about computers just so they can write up a report for their job or order stuff on Amazon.
I like your poetic description of general-purpose computers. But I'm wondering why you think less of general-purpose machinery.
The difference is scarcity and readily available tools to retarget the steam engine for a different workload. A steam engine requires tools made of matter to make it provide mechanical power to another system. In essence, a steam engine is just a power supply.
A general purpose computer, on the other hand, includes a power supply, and generally doesnt need tools that change matter to retarget it for another application; the tools needed to do so are made of information, and are thus readily available.
Granted: we as CS folks and business folks are choking off our own sources of talent by hiding the tools and keys needed to truly examine our systems, all in the name of "user-friendlines", but its still possible to use what is exposed to learn computing basics like how wifi works, or what a proxy server are.
To be frank, I think this distinction is precisely why I get frustrated at computing incompetence: a PC at home isn't locked down and has access to these tools. Anyone can learn -- even using a web browser and notepad to write JS.
In contrast, learning how an engine works requires mass-based tools that are big and expensive and require careful knowledge of how to not harm yourself when disassembling or working on the engine.
This distinction is massive, and yet we still use analogies to cars. Shops with tools are not plentiful and readily accessible to average people, the engines can't be examined from the inside out, coils and springs are dangerous physically. I can't just go looking to take a class, either: not all schools have shops!
> A computer can only do what the apps installed on it let you do, unless you're an IT person.
As recently as the early 2000s, ordinary users were comfortable searching out and installing new software. I remember Napster becoming absolutely massive, and it wasn't because the IT folks installed it for users.
A computer is something you can use to consume content or produce content.
A tablet is something you can only really use to consume content. (Regular tablet, not artist tablet obviously, and those generally have to talk to a computer)
Your own remark about tablets undermine your argument though. iPads and MS Surfaces have been arguably the best 'artist tablets' and they don't need to be hooked up to another computer.
I know. I think that for many people an iPad (or a surface) are better drawing tablets than Wacoms (cheaper, lighter, better screens) and can very well be used for other things than content consumption. (of course Wacom tablets have their benefits too)
Here's the difference: I don't think that being unable to repair your own car engine makes a car less useful. Sure, if your car breaks down in the middle of nowhere, you might be stuck there for a while until you can get it towed, but that doesn't happen too often, and besides, what are the chances you'd be able to repair your car on the side of the road without special equipment or replacement parts?
But the number of things you can do with a computer expands enormously when you know just a little bit of bash scripting, or python, or even Excel!
But smartphone is a computer, personal computer with telephony hardware. And Android is Linux with different userspace, mainline Linux can boot quite a lot of smartphones. Terminology is so wrong.
There is a general purpose computer under there but most people don't interact with it like that. The fact that it can does not mean that it will.
A lot of this has to do with the ecosystem and how a device is presented and what the UX is like. Manufacturers increasingly want to lock things down and hide them away.
> There is a general purpose computer under there but most people don't interact with it like that.
The same could be said about 90% of laptops and desktops purchased for home use. How many people actually use "computers" for tasks they couldn't do on a phone or tablet if those devices had larger screens and keyboard support.
That's been true since 1984 (and whenever Windows caught up ;) ). The enthusiast/hobbyist sector has long been a small minority of the computer buying public.
Windows wasn't really that bad until recently. Sure, it didn't go out of its way to give you tools to command your computer, but it didn't get in the way either.
The true dumbification of computers started with smartphones. iOS and Android are the primary drivers of this change, of treating computers as appliances. Microsoft unfortunately embraced this trend in recent years, they quite openly say Windows is an OS-as-a-Service now[0]. Still leaves plenty of control points to exploit[1], but it starts getting in the way.
Thank you for linking this. I couldn't remember the link but was talking to my partner about this recently now that we're almost a year into distance learning with our son. She remarked how quickly he's picking up on using the computer. (He's using her old Macbook Air.)
I remarked that UI/UX is so simple nowadays that kids aren't gonna have the wherewithal to do their own troubleshooting for bigger issues and how irreparable a lot of devices are now the insides of computers are gonna be completely foreign to them.
It is sad that the original article was written in 2013. I would argue that not much has changed (few more Linux phones were added to the list, but that does not affect the outcome ).
I'm not sure I share the concern. They really expect people to understand or care about things like proxy settings? Everyone doesn't share these interests.
Yeah kids can't use computers, because they don't come with knowledge pre-installed, but the ones who are interested will figure it out. It's not like there's a shortage of resources. And if you're concerned about your own kids, then teach them and they'll have a nice advantage in school.
There has got to be a better way to provide feedback or criticism than just insults like this. Imagine that someone who identifies with what was written reads what you wrote, how would they feel? How would that contribute to constructive discussion? I think it would be more likely to promote flamewars, bad feelings, and general conversational degeneracy.
I think a better comment would isolate what you think is wrong and explain why you think so. Ideally, I think that could be done without referencing the frequency with which people you disagree with have sex.
if you're going to shit on someone and their opinion at least give them the data they need to remediate the situation that you're unhappy about.
The author can't just say to themselves "Oh, apparently someone on the internet thinks that i'm acting too 'incel', let me just tune that down for the next essay." -- incel is too vague to pin down societies meaning of at any given time.
It's like booing someone off stage; it's rude and utterly useless except to express dismay.
It's about as useful to discourse as just saying "tl;dr 0/10"
Experiment i've been having fun with during the recent over-loaded word trend: Any time I hear 'cuck', 'beta', 'incel', or 'based' I ask the person to define it with context to how they used it.
So, my question : What did you mean? Can you define your usage of incel? What about the person made you relate them to the word?
Probably, but I'd say it's not far off from reality for many behavior and perspective wise. I think it unnecessarily transfers the behavior to misogyny (could easily be anyone/any sex), but that's the perspective many hold for those in tech: a means to an end. The addition of sex in the description definitely wasn't needed.
Many use i pads with keyboard cases or chrome books instead. These allow typing with a physical keyboard but a set of capabilities and an interface akin to that of a cellular phone.
I think they probably could get by with an ipad pro but they could do the same thing on a chromebook for a fraction of the price. The ipad pro is only really worth it if you need the pencil.
I would suggest they never knew how to use computers. Computers are general purpose devices, which is lost on the general population who only ever need to check emails and post on social media. Smart phones fit this perfectly.
Let's leave the general computing devices for people who actually need that power, just like the early days.
> Let's leave the general computing devices for people who actually need that power, just like the early days.
With that attitude, eventually the impact of economies of scale will end up denying us the ability to afford those devices or to use them how we see fit.
That was on the rising edge of the wave of "computers are awesome and will change everyone's life". We're on the falling edge now.
The problem GP refers to is this: making computers is expensive, gets cheaper with economies of scale. But economies of scale are capital-intensive, so they exist only where there's a market for it. The market for people requiring general-purpose computation is small and getting smaller, while the market for constrained computing is only ever bigger. Which means at some point the capital-wielding companies will just leave the market, and the prices of new general-purpose computers will go way, way up.
On top of that, computers today gain most of their value interacting with other computers. Once the mainstream usage - like your e-mail or your bank - gets neatly packaged in sandboxed, trust-computing-enabled environments, the utility of your general-purpose platform will plummet. A dark but entirely possible scenario is that it eventually becomes illegal to use general-purpose computers to connect to such services, because "security".
I could picture a CPU design that had a boot key or other restricted features set by blowing fuses (or similar tricks) during packaging. The "developer" unit leaves them unblown.
If they're selling 10M "regular" units per year, and 5000 "developer" models over the product lifetime, you have to amortize the cost of special-casing the production line for a short run, and stocking and supporting a second SKU, over a relatively small sales volume. It could well be more expensive than the few cents of electricity per unit to blow the fuses in a standard unit.
Already now, high-end general purpose computer parts can be more expensive than an embedded, restricted package. The embedded market can operate at a loss because their revenue is based on subscription services. The recent releases of new NVidia and AMD parts is a perfect example: AMD's share of TSMC's capacity was allocated mostly to produce the PS 5 and the Xbox Series X/S, while Samsung (NVidia's fab) clearly couldn't handle the sheer demand for the RTX 3000 series. Fortunately there are several OEM PC manufacturers still, but in the long term they will follow where the market forces blow too.
amusing how it is nearly always someone in the in-group making this decision, that everyone else does not need or deserve access to something but i do as a member of this group. tale as old as plato “discovering” the ideal form of government was a bunch of philosophers telling everyone else what to do.
We did, it resulted in smartphones and tablets, so what the OP is saying applies still. I would argue that's "general" computing now. They finished what the webTV started, providing a basic platform for people who had only very basic needs.
Smartphones and tablets are trying pretty hard not to be general-purpose computers. iOS devices don't run arbitrary user-specified code unless hacked, and many Android devices are designed not to let the user have real admin rights (i.e. root).
This seems to be getting worse, for example Google and its financial institution partners have decided that general-purpose computing and payments aren't safe together. Google Pay suddenly started refusing to do contactless payments on my rooted phone.
iOS devices can _run_ arbitrary code without being hacked. It just stops working 3 days after being compiled so its good enough for kids to develop on but not good enough to distribute.
> How about making _general_ computing devices more accessible via UI/UX to the _general_ public?
While I agree with the sentiment, and some of the complexity is not essential, the adage still applies: "everything should be made as simple as possible, but no simpler". At some point, "general computing" means there's some irreductible complexity that cannot be made simpler without the device ceasing to be general purpose.
> How about making _general_ computing devices more accessible via UI/UX to the _general_ public?
That's pretty much what the iPad is. A general purpose computing device but easier to use and with tighter security than a PC. At some point you end up sacrificing versatility for accessibility to the masses.
the ironic thing is that I program computers for a living yet I cannot achieve the basic functional level of a 5 year old with an Android device...that's not even counting the deliberate dark patterns. I see young ones automatically pinch-zooming stuff right out of the womb, however, so I suspect that it's "just me" having the issues...
15 years ago I had ONE messaging app that logged me into MSN, ICQ, QQ, Zephyr, Gtalk, Yahoo, AIM, Facebook, and Renren.
On that one messaging app I had either written or downloaded plugins for:
* End-to-end encryption (receiver needed the plugin as well)
* Automatic two-way human language translation via online translation APIs so I could have a conversation with someone who didn't share a common language with me
* Automatic two-way conversion between simplified and traditional Chinese. (I can read both, but traditional is faster for me, so I had it auto-translate all simplified to traditional for me, as well as auto-translate all of my outgoing traditional to simplified on a per-user basis for the receiver's convenience.)
* Ability to create conversation groups across networks, with my account serving as a gateway.
* Automatic rendering of in-line LaTeX math equations.
* Controlling of IOT devices, and allowing access to my dorm room for guests by having them send me an instant message with a certain secret word.
* Cloud-based logs of all of my messages.
* Online gateway that allowed me to access all my message logs from anywhere on any device and any OS with a web browser.
I feel like we've gone backwards. I now have a dozen different closed-protocol, walled-garden messaging apps, some of them even actively try to PUNISH you for trying to decompile and edit them, translation is not automatic, cloud logs only exist on Facebook messenger, E2E encryption is skeptically touted and paraded as some new thing even though I personally had real open-source E2E encryption 15 years ago on ALL my messengers, and everyone is siloed into their own apps and there is no way to send messages across networks.
Sigh. Tech in 2021 sucks. I honestly felt my messaging was way more advanced 15 years ago.
Pidgin was an excellent IM tool particularly on Linux desktops, but there were numerous times when I'm at someone else's computer and a web-based IM client like Meebo came in handy.
Most of my friends are on stovepiped chat systems now. It's really annoying because chat providers have pretty much stopped providing third party APIs anymore so you have friends spread across Signal, Telegram, Whatsapp, Tencent, WeChat, iMessage, and whichever chat system Google is using this month.
I seriously miss the days when all of them would be in the same app no matter what service they were connected through.
So, aside from Jabber, IRC, and the AIM TOC protocol (which was the weaker version — we used OSCAR, which was not open), we had to reverse-engineer most of the protocols, and keep up-to-date with changes. Often these services actively tried to block us, and we would spend weeks or months working around their changes. Yahoo was notorious for this.
It's not entirely different than the current situation, in that regard, but there was also less security baked in on the older services, and much of the protocols were in plain text.
While I'm out of the IM game (gaim?) these days, I'd be very interested in any modern attempts to reverse-engineer these modern services, and whether the pushback from companies would be any different.
Well, sadly there's the fact that Discord has finally pulled out the official laser beams for the alternative client scene, such that Cordless recently called it quits: https://github.com/Bios-Marcel/cordless
Ripcord (https://cancel.fm/ripcord/) doesn't seem to be giving any indications that it no longer works, but ¯\_(ツ)_/¯ (and probably for fairly large values of ¯\_(ツ)_/¯ too)
My computer is generally only able to handle one Chromium-based HI I EAT ALL YOUR RAM AND GPU, so I basically treat Discord like email as a result of the no-3rd-party-app policy. Given that the Discord "app" is just Electron, it'll get in a fight with the poor thermal design of my laptop in exactly the same way on the website does.
This being said, it's very difficult for me to argue loudly against the position they're, because it's complicated.
Discord has scaled to the point where "13 year old skiddies who like pulling legs off spiders will use any alternate clients they find [which don't include anti-spam protection] to send a {server,reputation}-destroying level of spam" is having a more measurable impact than "we need to maintain equality of access". I suspect that extremely strong management vision+competence would be necessary to prioritize this - as things stand right now, it's incredibly easy to deprioritize because the vast majority of people using Discord either have minimally-viably decent machines appropriate for playing games or completing actual day jobs.
> It's really annoying because chat providers have pretty much stopped providing third party APIs
They never provided third party APIs. The work of developing a unified messaging client was in getting around the ways in which they tried to stop you from interfacing with their system, and responding quickly when their countermeasures updated.
We haven't seen a change in the behavior of chat providers; we've seen developers give up on trying.
Not true. Many protocols were open (even one of the AOL protocols), and also security basically didn't exist back then, almost everything was based on trust and obscurity.
I was surprised to find many of the newer chat systems supported by Pidgin plugins: Discord, Facebook, LINE, Signal, Skype, Slack, Telegram, WeChat, WhatsApp.
There’s different limitations for some. Facebook Messenger is only one on one. I’m in as many group chats as one on one so it doesn’t help. I’ll have to check the WhatsApp one. If that works well, that would be pretty nice.
you could literally be critiquing any of 10 onion-layers of dialog allegedly about an extinct PM client, but it turned into a "no one uses computers anymore, just phones" tale.
I cannot tell if you are pro-AIM or a paid Slack user
What? The OP said they’re surprised not everyone uses Pidgin. That’s incredibly out of touch. I would expect that to be a joke otherwise. It sounds too crazy to think that’s the case now or ever.
Everyone I know stopped using AIM over a decade ago and by even 5 years ago Google Chat and everything else emptied out in favor of iMessage, Whatsapp, Signal etc...
I wouldn't be surprised that is how they lost the majority of their user base. Everyone I know was on it, myself included, but once support was hampered around the time the AIM protocol died, most people around me left for Telegram and Signal.
It's amazing how much spinning happens in current media. The only people in the world who truly know how much this is are those who get the headlines before the stories are written and talked about, like day traders, who get it for speed reasons. It's cool, but it sucks it costs so much to get an unfiltered news source.
I used it a lot way back. No complaints back then. Came back 6-12 months ago and both the Skype and Signal bridges were somewhat functional but silently stopped being connected and receiving messages very often.
Obv these kinds of things with unsupported potentially hostile APIs put high requirements of diligent maintenance.
IRC kept dropping connection and requiring new nickserv sign-in.
I thought libpurple/pidgin were mostly abandoned and that this would not be likely to improve , but it’s great to see that there’s hope and I might have been dismissing it prematurely.
It used to do XMPP federation too; they might still be exposing XMPP C2S but federation is long gone.
Fun fact: if you were on a non-Google server talking to someone on Google Talk and they clicked the button to "upgrade" to Hangouts, on your end they would show up as perpetually "away" and any messages you sent them would be blackholed. Yes, that was as frustrating as it sounds.
- Google used to support XMPP federation, and they pulled the plug on that years ago.
- Any new features introduced as part of Hangouts haven't been backported to XMPP, and so there may be random breakage when XMPP users talk to Hangouts users.
Me too, right now using pidgin to communicate with coworkers via Hangouts. Tried everything to set it up with KDE Telepathy (I know, I know - it's just my personal account is still working with it) to no avail.
I'd argue the official name de facto doesn't matter when there's been 5+ names for it in the last decade and nobody can keep track of it. Vast majority use it via their phones or in-browser GMail, I suspect.
(On topic: I use it with pidgin still though for the one-on-one chats with a few people!)
It was released as a standalone app in 2006 (after having a labs beta period prior) as Google Talk, and integrated into Gmail in 2007. While the widget in Gmail (which was only removed very recently to replace it with a Meet widget!) was labelled Chats, the service itself never was.
> chat integrated into Gmail before it was branded Google Talk.
Hangouts chat came wayyyy after Google Talk or even its integration into gmail (I know, it's hard to keep track of the chronology of these Google services, they release 2 new ones a year)
I literally haven’t used Adium in five years. Whenever Google deprecated XMPP from gchat and Apple killed iChat, there went my decade plus of daily Adium usage (and Gaim before that).
I stopped using it once ICQ stopped working with it. By that time, I only had 1 friend that was still using it, and we just switched to Discord anyways.
Yeah, that's why I asked, because if you use only 1 chat protocol, a dedicated client is almost always better (now that ICQ and AIM are dead). Pidgin really shines if you need to aggregate multiple protocols in a single client.
That's been my experience with developing with libpurple unfortunately. The APIs are very inflexible for advanced chat features, and theres little documentation for making your own plugin.
On-topic, Pidgin remains great, I still install it on every new desktop, but I haven't fired it up in years. I suppose it's been displaced by Slack, more's the pity.
15 years ago I had ONE messaging app that logged me into MSN, ICQ, QQ, Zephyr, Gtalk, Yahoo, AIM, Facebook, and Renren.
On that one messaging app I had either written or downloaded plugins for:
* End-to-end encryption (receiver needed the plugin as well)
* Automatic two-way human language translation via online translation APIs so I could have a conversation with someone who didn't share a common language with me
* Automatic two-way conversion between simplified and traditional Chinese. (I can read both, but traditional is faster for me, so I had it auto-translate all simplified to traditional for me, as well as auto-translate all of my outgoing traditional to simplified on a per-user basis for the receiver's convenience.)
* Ability to create conversation groups across networks, with my account serving as a gateway.
* Automatic rendering of in-line LaTeX math equations.
* Controlling of IOT devices, and allowing access to my dorm room for guests by having them send me an instant message with a certain secret word.
* Cloud-based logs of all of my messages.
* Online gateway that allowed me to access all my message logs from anywhere on any device and any OS with a web browser.
I feel like we've gone backwards. I now have a dozen different closed-protocol, walled-garden messaging apps, some of them even actively try to PUNISH you for trying to decompile and edit them, translation is not automatic, cloud logs only exist on Facebook messenger, E2E encryption is skeptically touted and paraded as some new thing even though I personally had real open-source E2E encryption 15 years ago on ALL my messengers, and everyone is siloed into their own apps and there is no way to send messages across networks.
Sigh. Tech in 2021 sucks. I honestly felt my messaging was way more advanced 15 years ago.
I believe Trillian still continued to support other networks (as long as they could) after introducing "Astra" or whatever they called their own chat network. Most of them have died off over time or locked out 3rd party clients (AIM, Google, Yahoo, MSN, etc.).
i mean, I'm typing this message from Firefox which has pretty much a direct lineage to Netscape (1994), on an OS from 1991, using an instruction set which mostly comes from the 1970s
That's really not a great comparison, especially since browser-based social media and browser-based chat services (e.g. Facebook and its chat) are what killed services like AOL/ICQ, before later moving into mobile apps. Pigdin was fairly niche even back in the early 2000s. Facebook is bigger than any of those services ever were, because Facebook did a way better job or attracting the average person. My family used email before Facebook, for example.
Given all those things with hindsight, it makes perfect sense for browsers to have long lineages and it makes perfect sense why standalone chat services mostly died out.
And you assumed everyone who wanted a desktop chat app used pidgin and nothing else? Because there were plenty of "multi-service" apps. It's just that Pidgin was the more popular among Linux users.
Yeah, Trillian was, by far, most common among the general public (the non-programming, non-techy types). Honestly, Pidgin was pretty niche, I don't know of any non-techies that used it.
Multi-chat clients had limited appeal by design because non-techies were more likely to just pick whatever service was the most convenient to them. Seems expected that it would be the techie folks consolidating all their friends because they were more willing to use multiple services than the average non-tech user. Even Trillian was fairly niche by comparison, just far less so than Pidgin.
Pidgin's psychic mode plugin was great fun, though.
Don't forget the numerous add-ons, skins if I remember correctly end-to-end encryption was just a PGP add-on away and you're right pidgin was one of the first things I installed on Linux machines and it's clone Adium for Mac OSX[1].
Sadly I don't do real-time communication anymore and even if I do I don't think any of my pidgin/adium (XMPP) contacts still use them.
I didn't even know Pidgin had skins. The big attraction for me was that I didn't have to pick an obnoxious skin like Trillian. It just used whatever your system theme was, and the default GTK skin looked like it belonged in Windows XP.
Just a heads up, at least several of those are supported to varying degrees. Looks like WhatsApp is supported through its web API, and slack and telegram's protocols are supported. Facebook messenger is no go, though.
That doesn't really answer why it's called purple. As I recall, there used to be something about it being named for the PRogram PLugins (prpl) that (then) Gaim used.
I miss those days. The issues with a modern client for something like this is that companies are much more hostile to being cut out of the user experience these days. No more is it just passive aggressive protocol changes to break third party clients, they're more happy to ban end users for using unofficial clients (e.g. discord, whatsapp) or require secrets/tokens they can go after third party apps for including.
Miranda was (is) awesome, I love that it is styled after the original ICQ client. It still worked with Google Chat and FB Messenger the last time I tried it (<2 years), but the list of people I know who actively use gchat has declined from dozens to 5 or fewer.
As gaim it was indepensible to someone like me at the time, a late 90s american teenager exploring Linux.
But new, younger people are coming up every day and not all of them are up on the old hits. AIM is totally dead, and even some of the other protocols you might use pidgin for, like standard xmpp, as I used to do with pidgin and gtalk, are not as relevant as they were before.
I haven’t used it since yesterday. We still have lync/Skype for business at work and it plugs into that.
Audio never seems to work, fortunatly in the rare occasion someone calls it also rings my phone. Most of my chat for work is on slack or WhatsApp, just some real old school people that use the Skype protocol.
I feel so old seeing this. I was using GAIM very shortly after it was publicly released, and basically continued with Pidgin up until AIM died a few years back. I don't use any equivalent nowadays.
I don't think so - I believe the original GAIM client used the open TOC protocol, e.g. from TiK which was the official Tk-based AIM client, some years before Gamera.
You are correct. At the time, AOL had released TiK and documented the TOC protocol but TiK was a bit slow and clunky, so Mark Spencer, the original author of GAIM, implemented faster client in C using GTK for the UI. OSCAR support came later because OSCAR supported some additional presence features (I think?? It's been a while...) and because ICQ also used OSCAR.
Pidgin and libpurple also have roots in another project called Everybuddy which was one of the first multi-protocol integrated free software chat clients. As I recall, Torrey Searle started Everybuddy because he was having a hard time getting traction on adding multiple protocols to GAIM at the time for a variety of reasons my hazy memory doesn't really remember.
For a couple of years after GAIM started to get plugin and multiple protocol support, much code was shared between GAIM and Everybuddy, and then eventually effort centered around just one of the code bases which eventually became Pidgin and libpurple.
Source: I was involved in GAIM early on and Torrey is a friend from those days.
I remember when they shut down TOC. I think that was close to the time it was renamed gaim to pidgin. My whole college career surrounded aol away messages.
One time I put an away message of “Dave Matthew’s coming to play at our school. Click here for tickets” and directed them to goatse. Yeah I was super cool.
yep. I used it when I had to talk to all my friends on msn messanger etc.. one app to talk to everyone no matter what they where using. Now I have to have 10 different apps to talk to just 10 friends.
Considering this is open source (which I'm assuming includes the plugins), wouldn't this be a much better alternative to the native apps on mobile? Curious as to why this hasn't been ported to Android/iOS. I'd much prefer this over apps that need permission to my blood type to function.
Pidgin was great back in the day for convenience, but there is a legitimate argument to be made for privacy here too.
EDIT: It just occurred to me that this would probably work on linux phones. Anyone with a Pinephone or Librem 5 tried this?
Not sure if this has changed, but at least on why it's not on iOS [1]:
> In a nutshell, the Apple Developer Agreement is the biggest "problem" preventing a Pidgin build for iOS devices. We won't quote the exact text here, but the Agreement requires that developers allow Apple to impose additional restrictions on applications above and beyond the application's own license. Among these additional restrictions are the well-known "5-device limit" and a prohibition on redistribution of the application. It is also quite clear from the terms of the Agreement that the developer of an application is not the distributor of the application in the App Store--Apple is.
> The additional restrictions required by Apple directly violate the GPL Pidgin is licensed under (Pidgin is licensed as "GPLv2 or later," and cannot transition to GPLv3 for a number of reasons not suited for this topic). GPLv2 forbids adding restrictions above and beyond those included in the GPL's own text, thus any distribution via Apple's App Store is a direct violation of the GPL. This is the root of the problem.
I can find no information about what limit they’re claiming. You can use a maximum of 5 different Apple ID simultaneously on a device but that’s pretty obscure.
it is 5 devices that you can use personally with an Apple ID (so, you as a single person can own 5 devices that can receive things you've paid for on the app store, like music and programs.).
Distribution restrictions on top of GPL and they don't own the copyright on all the code without a CLA which prevents licensing under something other than GPL for the App Store.
I don't understand the logic where releasing something under GPL + a restrictive license is considered worse than releasing under GPL only.
What is lost when they make Pidgin available on the App Store (under the restrictive App Store license) + under GPL (on their website) as opposed to not having an App Store version in the first place and releasing under the GPL only?
I don't see how the presence of a second, more restrictive license invalidates the GPL given that anyone willing to take advantage of something not allowed under the more restrictive license can still do so under GPL?
The maintainers likely don't own the copyright on the entire codebase, and so likely cannot license it under anything other than the GPL. Incorporating GPL code into an app on the app store is not possible without breaking either the app store's rules or the GPL's rules (most likely the GPL, which would effectively remove the maintainer's rights to distribute that code).
If they don't have the ability to change the license (which it sounds like they might not; most likely some of the code is owned by others?), they can't distribute it under GPL + more restrictive terms, because what would be lost is their license to distribute the code.
But my point is that if the code itself remains under the GPL, how does publishing an alternate version of it "undo" the GPL considering all the rights restricted by the second license would still be available under the GPL?
I think your argument is: sure, I'm distributing over here with way fewer rights than normal, but it's also available over there with all the rights, and it's the exact same stuff and so that's good enough. And I see why you'd think that, it's not completely unreasonable, but it's just not how the license is worded.
It's either GPL with all the rights that entails, or you can't (legally) redistribute it at all.
Now, if you own the copyright you can give out as many parallel licenses as you want. But pidgin & libpurple have been around for 20 or more years and have had many, many contributors, and they have to explicitly give up their copyright or consent to the license change to do what you propose. That's theoretically not impossible, but it's a lot of work.
This is why some projects require you to sign copyright-assignment agreement before they will take your patches—it gives the project more flexibility to change the license in the future.
There’s an easy way to fix this. The Pidgin iOS app could be forked into a different licensing model. It also need not be open source, just demonstrate feature parity. Another way is to modularize the core messaging layer under a BSD license, and have the desktop app and iOS app both implement the front-end (and OS specific functionality) under distinct licenses.
libpurple (the actual messaging library) is already modularised, many different people mantain[ed] different modules, it's been used my many third party messaging clients including Adium and multi-IM browser clients from those days like Meebo or imo.
It's not a commercial project with a CLA, it doesn't have a single owner, many of the people who contributed major parts have moved on or would object to a license change from copyleft to permissive, so it's not a matter of "just change" the license. And libpurple is the real meat of the project.
Anyone can build and run their own software on Windows, so distributing software for Windows is not a GPL violation, whereas distributing iOS apps via the app store runs afoul of the anti-tivo clauses in GPL3
No, it's not ironic. Windows imposes no such limitation on developers. Microsoft certainly doesn't assume exclusive rights to distribution of every piece of software that can be installed on Windows.
iOS applications aren't allowed to stay awake constantly talking to a bunch of different network services.
For iOS IM to work, a centralized server (and corresponding developer ID) has to send a notification to you, sent first to Apple to be proxied via Apple's push notification service (APNS) to which each iOS device maintains a persistent connection.
This means that some third party service has to know when you get a message (and thus needs to proxy your connections to the IM services, and know your credentials and see your message contents) to be able to know when to send that notification.
This (and Signal now replacing the cryptographically shattered iMessage) is probably the main reason I'm switching to Android; truly decentralized/private notifications aren't really possible on iOS. They have to come from the app developer's own 24/7 online servers, sent from them to you via Apple servers, which means that federated stuff is basically out without providing your login details to the developer (which of course lets them see all your messages). This is also why almost no ActivityPub/fediverse clients can notify you of DMs on iOS either if you run your own instance.
I know there's Background App Refresh now that lets apps wake up periodically to download stuff; I'm not sure if such polling can fire off notifications from the local app. It's probably too much latency for IM, however, due to the fact that Background App Refresh isn't (last I looked) allowed to run continuously (for battery reasons).
You don’t have to put an entire message text into APNS notification. Apple (and google GCM, and webpush) notifications only deliver a structured event to the application (which may or may not contain any text), and once the app is activated (if not yet), it has to connect to its own server to get a full representation of what was sent, update vv-status, etc. APNS/GCM are not instant messengers on their own, though may be used as such in simple cases.
Likely, iOS version of Signal uses the same “empty ping” technique, so you don’t have to worry about Apple reading your texts, unless you’re concerned with metadata leak. But unless they’re spoofing a websocket with fake packets, it will leak anyway.
Sure, but there still needs to be a server somewhere that has the app developer's client certificate, connected to Apple, that knows when you get a DM and can send that zero-content "wake up and check your DMs" packet to your phone via APNS, which means it needs (given current apps permissions models) access to your DMs without you.
There is no need for this “server somewhere”, and APNS can’t have your message, mainly for two reasons:
First, that “server” is Signal server itself. When a message arrives at it, it simply commands Apple to wake up your app, for it to call home, and that’s it. It is preconfigured to do that (and GCM as well).
Second, all Signal messages are end to end encrypted and neither of Apple, Signal, Google, your ISP, any server on the route of it NEVER know its content, because the only mean of decrypting it resides in a memory of your client app. There is basically no way to see the contents before your client receives the message, by design. Even if that were not the case, various IM servers don’t have to send your texts to Apple, only if they want the text to be shown on a notification itself.
The only theoretical concern here may be that Apple can somehow pick the decryption key out of the app’s memory (because ios is a supervisor, obviously). But that can’t be the main reason someone swithces to android, which is a supervisor itself, and where the same issue exists.
We're talking about federated/decentralized protocols that Pidgin serves as the type of client for, in a thread about why we don't see things like Pidgin on iOS.
In a centralized system where the mobile app is made by the same people as the IM server, of course the IM server can send a notification to the app (such as is done in e2e stuff like Signal, or in non-e2e such as Telegram).
That falls apart when you're talking about, say, ActivityPub on an instance you run yourself, or one not operated by the vendor of the IM app. The developer's server can't know when to send you a notification without having some knowledge, from your own e.g. IRC, ActivityPub, or Matrix server, that you have received a new DM.
The Matrix/Element people have addressed this by running one centralized notification service for every single client of the Matrix/Element iOS app.
We're talking about federated/decentralized protocols that Pidgin serves as the type of client for, in a thread about why we don't see things like Pidgin on iOS.
Sure, but it needs to know that there are new messages. I don't think that's a separate permission on any (e.g.) ActivityPub/XMPP/IRC server implementation today.
On all XMPP server implementations I've worked with, the push notifications mechanism supports (and usually defaults to) not including any message body in the API call to the push server. Usually it's also possible to leave out the sender name/JID, e.g. with prosody's mod_cloud_notify.
You can create local notifications any time your app is active, which includes the background. AFAIK signal does empty APNS push to wake and then pulls data with it's own connection and then displays text content with a local notification.
The main reason for the restriction to apple-only for notification services is battery life, and they've been proven right by bad behavior demonstrated on android.
Interestingly, if your a VOIP app you can actually circumvent a lot of the background networking restrictions, but it's still hard to do when you don't have an active call in place. You also have to be an actual VOIP app to get approved with that entitlement. Which wouldn't be hard to get approval for if you made a fork of signal for example, since it does have real VOIP capabilities inside.
Either way the battery life of your device would be worse with your custom VOIP app always keeping a connection open vs. apple's native OS notification system.
> Interestingly, if your a VOIP app you can actually circumvent a lot of the background networking restrictions
These APIs were removed a while ago. As an example, pure SIP clients (without a SIP<->APNs proxy operated by the app developer) are no longer possible for iOS.
> This (and Signal now replacing the cryptographically shattered iMessage) is probably the main reason I'm switching to Android
Android seems to be headed the opposite direction from Apple when it comes to background service execution and network connectivity. I wouldn't be surprised if background network connections are the next thing to go.
> which means that federated stuff is basically out without providing your login details to the developer
It's definitely possible to support federated push, although it's admittedly more work for app/protocol developers: The app developer would have to set up a "push proxy" server that accepts push notifications addressed to a specific iOS device.
It would be nice if Apple was to allow optional sourcing of "anonymous" pushes for such use cases, but that doesn't seem to be in line with their desired level of control.
Exactly, maybe I was unclear: Apple has been adding more and more background execution modes to iOS over the years, while Google has been steadily removing them from Android (and nudging developers towards GCM instead).
Background execution restrictions mean you would not be able to be online except when the app was in the foreground for the most part on iOS; on Android, you have inconsistent access to cpu and network in the background.
You really need push notifications, but AFAIK, push tokens are tied to the app developer; you can't give an random server a token from your app, because they won't be able to push to you.
Yeah that would be expensive for the pidgin maintainers, if the other message services had a way to do that via oauth or some such that would be different but entirely not in their interests.
Have you seen the latest review of the Librem 5 from Linus Tech Tips? The phone seems to run Linux apps fine... it doesn’t have working camera drivers a year after release though...
Hell, I still don't have my damn order and I placed it in Oct. 2017. Their last post said early orders would be completed by EOY, but my last email to support they said another two months.
I want to be supportive but holy hell am I frustrated.
Pidgin's libpurple library was a core part of Palm's WebOS. They were really focused on integrating different chat services like that. For Librem 5, they're using Telepathy quite heavily, which is similar but designed more as an OS component (and full of XML).
Chatty, from librem uses libpurple, which pidgin is built on, for its sms app so it also supports xmpp, i dont think itd be hard to support the other services libpurple supports, i found it pretty easy to add purple-facebook support
I've kept an eye on other phones throughout the years, but nothing quite ticks the same boxes (and by far most things aren't even remotely close).
There are some other interesting phones on the horizon (Librem, PinePhone), but then again things like Maemo Leste are ready to breathe new life into the N900, so I might be using it for very long time yet!
For whatever reason I kind of remember Gaim/Adium/Pidgin/libpurple had a run of security issues back in the day too.. I assume that stuff got fixed up by now... but I think at the time that accounted for its decline. Oh, now that I think of it wasn't XMPP (streaming XML) originally invented for Jabber which Pidgin supported?
If it were ported to Android/iOS, it'd need to adhere to the relevant standards from Google/Apple. If it did (and that's a hard task itself, see every other 'Google/Apple blocked my app' thread on HN) then it'd quickly be squashed by the other major competitors.
Can't have a non-monetised, FOSS, universal application available in the app stores! That's like ... that's like COMMUNISM, or something! /s
I build a MacOSX app bundle for the original Pidgin long time ago (https://sourceforge.net/projects/pidgin-macosx/). At that point in time, this was not so trivial, as the GTK support for native MacOSX was experimental (http://www.gtk-osx.org/). You could simply use the X11 GTK version but I rather wanted to have a native version. I have no idea what the current state is with GTK on MacOSX. This Pidgin build is obviously very outdated now (from 2009), and probably does not run on recent MacOSX versions (they are frequently breaking backward compatibility...).