Most active commenters
  • rw_grim(3)

←back to thread

89 points rw_grim | 19 comments | | HN request time: 0.41s | source | bottom
1. relyks ◴[] No.42211603[source]
Am I reading this right? Is the only protocol being supported now the most recent version of IRC? Are there plans for others? Part of Pidgin's "calling card" has been its ability to support many different chat protocols. However, that's become difficult since most protocols have become walled gardens and harder to reverse engineer. I'd imagine supporting Matrix, XMPP, Signal, other protocols with open specifications, etc. would be a good idea
replies(4): >>42211609 #>>42211624 #>>42211652 #>>42211827 #
2. weikju ◴[] No.42211609[source]
I'm guessing at the time of this experimental alpha "don't use it full time but alongside pidgin 2.x to test things, all plugins are incompatible", only IRCv3 is supported.
3. rw_grim ◴[] No.42211624[source]
yes all the other protocols will eventually be supported. we're a small team of open source developers and these things take time..
replies(2): >>42212017 #>>42212890 #
4. factormeta ◴[] No.42211652[source]
Would be good for Matrix to have more stable client than Element or Flutter based apps.
replies(1): >>42212269 #
5. yaomtc ◴[] No.42211827[source]
Signal is open source but they only let the official builds connect to the official Signal servers
replies(1): >>42211953 #
6. Katzenmann ◴[] No.42211953[source]
That's not correct. Alternative signal clients do exist. Axolotl: https://github.com/axolotl-chat/axolotl Flare: https://gitlab.com/schmiddi-on-mobile/flare
replies(2): >>42211984 #>>42212215 #
7. lmm ◴[] No.42211984{3}[source]
Alternative clients do exist but OWS has a history of taking them down and/or making protocol changes to block them, similar to AIM back in the original days of Pidgin.
8. johnisgood ◴[] No.42212017[source]
Not sure if my memory deceives me, but did not Pidgin support XMPP?

I suppose for now I may stick to Gajim (and Conversations on Android).

replies(2): >>42212124 #>>42212144 #
9. jpk ◴[] No.42212124{3}[source]
Pidgin supports lots of protocols, including xmpp, via plugins. It just sounds like they choose to make breaking changes to the plugin API for v3. I'd expect popular protocols to get ported at some point before GA.
replies(1): >>42212182 #
10. usr1106 ◴[] No.42212144{3}[source]
Sure it did. Our company chat was XMPP 10 years ago and pidgin was one of the most widely used clients. I assume it's just the experimental version that doesn't support it yet.

Nowadays we use zulip at work which has a better model (topics). For IRC I use quassel because I can have the backend running on a server and when I connect using the frontend I see the channel history and messages I might have received weeks ago...

11. rw_grim ◴[] No.42212182{4}[source]
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.
12. HeatrayEnjoyer ◴[] No.42212215{3}[source]
Those are unsanctioned
replies(1): >>42212892 #
13. Arathorn ◴[] No.42212269[source]
pidgin 3 looks very exciting. it’s worth noting that Element X already provides an spectacularly more stable Matrix client than classic Element.
14. dig1 ◴[] No.42212890[source]
The last time I followed Pidgin development was a while ago, but I'm actively using it for various protocols (slack, discord, googlechat, skype), so I'm curious about the decision to break the API.

I understand that the Pidgin community is small, so claiming that "the other protocols will eventually be supported" seems unrealistic. This change requires the community to take on unnecessary porting work and we are already dealing with constant protocol changes, playing whack-a-mole with protocol providers.

For instance, this guy [1] is doing incredible work, but I doubt he will want to invest his time in unnecessary rewrites unless someone steps in to assist with each plugin.

[1] https://github.com/EionRobb/purple-discord.git

replies(2): >>42213447 #>>42216372 #
15. actionfromafar ◴[] No.42212892{4}[source]
Such an inflammable statement, let's sanction those then. :)
replies(1): >>42213460 #
16. arghwhat ◴[] No.42213447{3}[source]
Presumably because the old API was broken/lacking/etc. Calling the resulting porting work "unnecessary" without even considering why the API might have been changed is not fair.

The pidgin project is 25 years old, and libpurple is 17 years old. It's entirely fair that a rework is required, and much appreciated that this work is continuing.

17. arghwhat ◴[] No.42213460{5}[source]
Unfortunately, whether or not a client is sanctioned for use on Signal-owned infrastructure is entirely up to the Signal organization, and they have been rather hostile to such clients.
replies(1): >>42213596 #
18. actionfromafar ◴[] No.42213596{6}[source]
Sorry I was just making a joke about how sanction has a double meaning. :-)
19. rw_grim ◴[] No.42216372{3}[source]
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