rw_grim

We (Pidgin/Gaim/Finch/libpurple) have never been TOS compliant.

The project is still alive and we're trying to finish our next major version to be able to better support modern protocols and features.

We do monthly updates on the status of the project that we call State of the Bird and they can be found here https://discourse.imfreedom.org/tag/state-of-the-bird.

Most went to libera, some went to OFTC[1], and a few moved to matrix as well.

[1] https://www.oftc.net/

We're working on not needing patches.. We have an installer in the works, but in the mean time check out https://github.com/pidgin/retro-prpl

There are binaries in the action artifacts, but like I said an installer is coming soon (tm)

There's plugins for most of the modern stuff at https://pidgin.im/plugins

Some of them, yes. See https://pidgin.im/plugins/?publisher=all&query=&type=Protoco... for a list of third party protocol plugins.

We’re live on Flathub Beta now!! Flathub Beta means it won’t show up on the site, but it’ll show up in GNOME Software and other app stores after you add the Flathub Beta remote. You can find instructions on how to do so here https://discourse.imfreedom.org/t/pidgin-3-on-flathub-beta/2...

Just an update that we missed some bugs that were affecting new users so we've released 2.90.1 which fixes them. The linked posted has been updated with this information as well.

We haven't started tackling ee2e yet, but we'll have extension points to add custom stuff because of xmpp has 3 e2ee methods, gpg, otr, and, omemeo with a new one on the way as well.

This is about complex data and accessing it later for display and search in the application. There is a command line tool we're putting together to make searching from the command line possible though.

While there have been clipboard bugs, we've never used those keystrokes in the UI. However, GTK2 did have a way to let users change the menu shortcuts by hovering over the menu item and hitting a new keystroke and I suspect that's what happened here.

Maybe, as others have noted here, signal doesn't allow third party clients on their networks... That said, neither did AIM, MSN, Yahoo, and ICQ...

But we're trying to fix the thing you're always complaining about...?

I cleaned up the language on the irc bit in the post as it was confusing people. But we are very much aiming to support everything including all the big chat networks. That's why so much of our internal API had to change.

This release is to get something out there even with limited functionality rather than not releasing until it's at feature parity with Pidgin 2.x which is going to take a long time on our current trajectory.

So to put this very simply, there is no way in pidgin 2 without breaking API to address a message after it's been displayed. Eion has been hacking around this for years via commands in protocols and then replaying messages and stuff. While this works, it's not a great user experience.

So at a bare minimum we needed to totally change the way messages work. Which inside of a chat client, is a pretty big change. That obviously led to other changes and so on and so on.

As for the other protocols... We needed something to prove out most of the abstractions and trying to prove out abstractions while implementing multiple protocols is a ton of work. But on our radar are new XMPP, Bonjour, and even a Matrix plugin. All of these will be coming from us and will be in tree.

That said, there will not be any proprietary protocols in our official source tree. If you want more information on that, check out this post [1].

As for Eion's plugins, I've been talking to him through much of this as you would expect. Obviously his time is precious and we didn't make this changes to spite him or anything, but we (me specifically) have offered to start porting his protocols for him.

[1] https://dev.to/grim/in-tree-protocols-15ne

I hope so? :-D

there's basic text support for most of those in pidgin 2 right now https://pidgin.im/plugins/

Fwiw, meebo was based on libpurple. They employed Mark Doliner, aka Kingant, who was also a Pidgin developer and eventual lead developer.

Yes this 100%. As the post says, nearly all of the API in libpurple and pidgin has changed. So we have to rewrite all of the protocols yet.

Well fwiw, all of those people are no longer involved in the project.

yes all the other protocols will eventually be supported. we're a small team of open source developers and these things take time..

Yep, libsercret/kwallet on linux, wincred on windows, and keychain access on mac.

You might be surprised how modern irc is nowadays... https://ircv3.net/

more specifically https://docs.modernxmpp.org/

You should look at the matrix specs, include the new matrix 2 stuff...

My point is, this argument is a bad one as it expects people to get the protocols right on the first try and that's never going to happen.

Sorry Mattj, but thank you for saying these things kindly :)

It's true Pidgin 2's XMPP support sucks, there's no denying that. That said we can't easily fix that with the current API which is why Pidgin3/Purple3 is the only path forward.

That said, I'm pushing to have an experimental release of Pidgin 3 out by the end of the year. However it's only going to have IRC support right now because well there's only so many hours in the day especially when Open Source is your passion project and not your day job.

We're still here and we're getting close to finally getting a pre alpha Pidgin 3 out the door. In the mean time check out https://pidgin.im/plugins for third party plugins that provide at least basic support most of the modern protocols.

> Develop open-source software (OSS) that is interoperable with QNX software, provided you make the resulting OSS publicly available at no charge.

Even the GPL doesn't have this restriction...

libolm was not using battle tested crypto. That's one of their main reasons for abandoning it. Our plan is to use gcrypto for it which is battle tested.

As far as vodozemac goes, we're not pulling rust into our build system.

That plugin was abandoned and we (the pidgin team) are unlikely to pick it up as we're planning our own implementation.

We have been planning a new from scratch version that'll be in tree, but with the retirement of libolm which is for good reasons, it means we're going to have to write our own OLM implementation at some point as well.

https://matrix.org/blog/2024/08/libolm-deprecation/

TL;DR it's on the list, going to be a bit before we get to it.