This is exciting! I thought Pidgin had died off, but with the sheer number of chat platforms out there I'd much rather install a single Pidgin client to keep up with them.
Can it work effectively with the more closed system clients that exist today though?
I use finch (the curses version of pidgen) to keep up with people on discord from tmux.
The only closed platform it doesn't seem to work with that I use is imessage.
I'm glad to see Pidgin still alive and well. I remember ages ago moving to it from Trillian, and I don't think there's any other software around like it.
Not sure that’s the right place to look for up to date code. I believe it is self hosted somewhere. The lead developer streams on twitch[0]. Last stream was about a day ago.
The nice thing about modular, open source software, is that instead of using the 5 year old client, you can use the one that was last updated two months ago:
You are likely to be banned by WhatsApp even if it works for a couple of weeks; they are quite trigger happy if the client is suspect (which has happened with the pidgin plugin before)
I can remember how I was able to chat with my Facebook friends with Pidgin, those were the days.
I don't think Facebook will allow any client to support chat like they used to do back in the days, unless you do some wired bridging hacks like you have to do in Matrix
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...).
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 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.
There's been such an enormous amount of churn in the IM client market for an industry that hasn't seen significant innovation since the days of dial-up.
Of course, and we'll new dominant players in 5 years. My point is just that none of these do anything radically different from IRC. Channel-based as the primary mode (as opposed to direct) is a bit of paradigm shift in terms of UX, but it's just a veneer on group chats that have existed forever. And obviously, they've all been adapted to web/smartphones as opposed to terminal. But in terms of what kind of communication they enable, it's absolutely nothing new. I could do this kind of thing on Quantum Link on my Commodore.
The big obstacle to sending video back in those days was one of bandwidth and storage space - it's not difficult to add to the protocols. IRC is a pretty well-known client for easily sending files - it's purely a design decision not to display them in-line like Discord and Slack.
>My point is just that none of these do anything radically different from IRC.
This is such an IRC user take. On the same level as not understanding what the point of dropbox is when FTP exists.
The failure of FOSS to understand what users actually want is the reason proprietary platforms took off. Matrix is the first attempt to create something similar to what users use and want.
I thought about writing a list of all the things I use on discord which IRC doesn't support but it would be a waste of time because its almost everything discord does. Even basic sending and receiving messages is close to impossible with irc on mobile unless you use a 3rd party service to translate the protocol in to something mobile friendly.
it's semantics without slavish adherence to syntax. it's really not that much of a stretch to see that the imbuing of ambiguity is a net positive to some people in some circumstances, and is a natural evolution of formalized language systems in a non-optimally constrained environment.
Stickers are such an underrated feature, especially platforms that allow user generated sticker packs. Its the number one feature on Telegram imo and the primary reason a lot of people I know use it over discord.
The big revolution in IM clients/protocol was the move to mobile. All the old protocols require a constant connection to the server to receive new messages. They were not designed with push notifications in mind.
I remember some early IM clients for the iPhone that you had to keep open to be alerted to a new message. Not fun.
I'd say the thing that makes Pidgin more attractive is the fact it's free, whereas Beeper is $10/mo (unless you host the entire stack yourself, and at that point you can't use the Beeper app). Granted, Beeper has mobile apps going for it.
Pidgin is basically dead. When all the big messengers closed off their protocols, keeping compatibility became very labor intensive. It doesn't look like any FOSS has been able to do it, so I'm optimistic about Beeper.
When XMPP was quite widespread and lots of my friends used it Pidgin was my trusted software. I'm very happy it's still being maintained and to see lots of plugin for new IM protocols/services (Telegram for instance).
It's a pity that the font on the new website is too thin for me and very hard to read :\",
I used it back in the days with MSN, AIM, and ICQ. But it didn't work as good with the switch of communication to mobile and the rise of WhatsApp and FB Messenger.
I used Meebo a lot, and I'm only just now realizing the shutdown was because of Google. They bought out the company to assign the staff to Google+. What a waste.
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
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?
Wow great to see Pidgin still going. libpurple was a fantastic idea, and its great to see there is bitlbee integration [1]. Need to update my Emacs setup to use this! [2]
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 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).
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.
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.
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.
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.
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.
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 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.).
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.
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?
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.
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).
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.
It would be cool if they had compiled mac binaries available on their downloads page. They instead recommend Adium, which hasn't had a commit on master in five years.
On pidgin, I used to use it and have been considering using it again, but right now I lean more towards WeeChat because I like having the ability to CLI it off a vps but I guess I could proxy my pidgin stuff too which is half of the reason I like doing that. (friends don't let friends irc from home, especially without cloaks!)
None of the most popular package managers, such as those included in Ubuntu, Debian, or CentOS, include spyware by default. ("opt-out", aka "assume consent even if you don't have it".)
There are things like popcon that you can opt in to, but those are optional ("opt in"), and aren't on by default.
Even just on macOS, neither nixpkgs nor macports will transmit your activities to anyone.
This is entirely false. Debian not only doesn't do this, it patches out such tomfoolery in anything they distribute.
It's a recent trend, but it's nowhere near ubiquitous, and it's still a major violation of consent to exfiltrate a user's data without asking, even if every piece of software in the world did it (as you erroneously claimed).
When software spies on you without permission, there's a name for that type of software.
Pointing out Debian as your counter example is so silly.
Yes, HackerNews community member, but we’re talking about software in aggregate amongst products people out in the world use not just your favorite Linux distros.
Analytics are very common now, carry no malice, and are not spyware.
The term has implications that aren’t satisfied here but hey, it’s HN and YOLO. Everything is spyware everyone should use Debian, eat Arby’s etc
It isn't a fact, because you keep saying that. It's reasonable to ask what constitutes spyware, and categorize analytics either in or out of that category.
In any reasonable definition of spyware (it spies on you to the creator's benefit and not yours) then analytics goes in that category.
Try to give comments the most generous interpretation. That's what silly HackerNews community members agree to in the rules.
Nor are your assertions facts because you keep repeating them.
It appears we are at an impasse.
In the meantime, I and the vast majority of people will carry on using Homebrew without labeling it as loaded with “spyware” - whether you agree with it or not.
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.
454 comments
[ 2.8 ms ] story [ 330 ms ] threadCan it work effectively with the more closed system clients that exist today though?
No MS Teams, though.
https://github.com/davidgfnet/whatsapp-purple/
[0]: https://twitch.tv/rw_grim
[0] Technically it's a Google Talk client, but it seems to be able to communicate fine with Hangouts users for now.
[1] Yes we use Hangouts at work for intradepartmental chat.
https://github.com/hoehermann/purple-gowhatsapp/
https://adium.im
I don't think Facebook will allow any client to support chat like they used to do back in the days, unless you do some wired bridging hacks like you have to do in Matrix
Edit - fixed typo
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 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 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.
If it wasn't obvious, libgaim became libpurple, not the other way around. Too late to edit the parent comment, but felt I should clear that up.
It has limitations, especially on media.
The big obstacle to sending video back in those days was one of bandwidth and storage space - it's not difficult to add to the protocols. IRC is a pretty well-known client for easily sending files - it's purely a design decision not to display them in-line like Discord and Slack.
This is such an IRC user take. On the same level as not understanding what the point of dropbox is when FTP exists.
The failure of FOSS to understand what users actually want is the reason proprietary platforms took off. Matrix is the first attempt to create something similar to what users use and want.
I thought about writing a list of all the things I use on discord which IRC doesn't support but it would be a waste of time because its almost everything discord does. Even basic sending and receiving messages is close to impossible with irc on mobile unless you use a 3rd party service to translate the protocol in to something mobile friendly.
My past self never would have predicted the world has moved to a form of hieroglyphics of fuzzy animals to talk to each other.
I remember some early IM clients for the iPhone that you had to keep open to be alerted to a new message. Not fun.
It's a pity that the font on the new website is too thin for me and very hard to read :\",
Anyone got fresh experience?
Can't have a non-monetised, FOSS, universal application available in the app stores! That's like ... that's like COMMUNISM, or something! /s
[1] https://wiki.bitlbee.org/HowtoPurple [2] https://200ok.ch/posts/2019-11-01_irc_and_emacs_all_the_thin...
Like literally nothing to add just
"the main maintainer livestreams his work on pidgin on twitch"
"One of the main developers of pidgin streams on twitch"
Edit: of course I got downvoted when I pointed this out. Astroturfing is prevalent on HN as well.
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).
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.
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.
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.
the main reason I'm switching to Android
You may be interested in reading this comment then: https://www.reddit.com/r/signal/comments/ap9lin/comment/eg7v...
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.
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.
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.
Sorry, I misunderstood that.
Could you expand on this? I did a quick search but I don't see anything relevant that's more recent than 2016.
It's still relevant.
> 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.
https://developer.pidgin.im/wiki/WhyNoiOSVersion
Sorry, but I'm not familiar with this – could you share more please?
TIL it's now 10 devices...
I think the idea is that you don't tie all your friends' devices to your account to share apps etc., but I am just guessing.
It has subsequently been increased to 10.
Quick search reveals that up to 5 devices can be tied to the same Apple account: https://discussions.apple.com/thread/8030144
There are many ways to skin this cat.
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.
I followed a few of the developers for a bit as I really wanted to work there. I believed they got aquired into the g+ team (gchat? maybe?).
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?
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.
On pidgin, I used to use it and have been considering using it again, but right now I lean more towards WeeChat because I like having the ability to CLI it off a vps but I guess I could proxy my pidgin stuff too which is half of the reason I like doing that. (friends don't let friends irc from home, especially without cloaks!)
There are things like popcon that you can opt in to, but those are optional ("opt in"), and aren't on by default.
Even just on macOS, neither nixpkgs nor macports will transmit your activities to anyone.
I think your "most" claim is inaccurate.
Remove the tinfoil hat, dude.
Everyone. Tracks behaviors to improve the product. It’s table stakes.
Often without a disclaimer!
Welcome to the internet.
Be upset about it if you must but it is not equivalent to “spyware.”
At the very least, they're doing a customer survey without compensation. Even if they have no more malicious intent.
Upset? More like resigned. This is just about calling a spade a spade.
It's a recent trend, but it's nowhere near ubiquitous, and it's still a major violation of consent to exfiltrate a user's data without asking, even if every piece of software in the world did it (as you erroneously claimed).
When software spies on you without permission, there's a name for that type of software.
Yes, HackerNews community member, but we’re talking about software in aggregate amongst products people out in the world use not just your favorite Linux distros.
Analytics are very common now, carry no malice, and are not spyware.
The term has implications that aren’t satisfied here but hey, it’s HN and YOLO. Everything is spyware everyone should use Debian, eat Arby’s etc
In any reasonable definition of spyware (it spies on you to the creator's benefit and not yours) then analytics goes in that category.
Try to give comments the most generous interpretation. That's what silly HackerNews community members agree to in the rules.
It appears we are at an impasse.
In the meantime, I and the vast majority of people will carry on using Homebrew without labeling it as loaded with “spyware” - whether you agree with it or not.
https://youtu.be/BH8DRyKUZDg
So Pidgin (gaim for those of us old enough to remember those days) should run fine without a port.
The problem is the lack of SoC documentation. There is some progress for the camera though: https://source.puri.sm/Librem5/linux-next/-/issues/44#note_1....
Sure. Was saying that this should work out of the box (at least for the most part) on a linux phone. No port necessary.
I want to be supportive but holy hell am I frustrated.