This post is mainly geared towards pidgin and protocol developers, but as I keep getting reminded, Pidgin 2’s days on Wayland are getting shorter and shorter and we need to get Pidgin 3 usable.
So I would like to know, what are you’re absolute required features to start using Pidgin 3 as soon as possible. I know I’ve been heads down and in the weeds a bit about making things work long term, but I’m certain I’m overlooking some simple stuff that would be easy wins.
This list will help me decide what to focus on, but please be reasonable. We’re trying to find a way to an MVP, so if you’re like Voice and Video with NAT traversal, realize that that’s not what I’m asking for here
The biggest issue for me right now is that accounts disconnect after a while. But I think that’s already point number one on your list. Also Zulip channels would be number two for me.
I think my list will be not be helpful. I think I have already seen every single point somewhere – I just did not come around to try them in my plug-ins, yet.
message persisting mechanism – I use Pidgin not only for the conversation, but conservation of the chat history is actually more important to me (I do not care whether that is plain files or an unencrypted database)
file transfers – receiving and sending attachments in channels and DMs (whether images are embedded into the conversation view or not is secondary to me)
signal for "this message has (probably) been displayed and read (the user interacted with the conversation in some way) – requested by an early user
message persisting mechanism – I use Pidgin not only for the conversation, but conservation of the chat history is actually more important to me (I do not care whether that is plain files or an unencrypted database)
Working on it, but that’s still a beta or rc feature, not an mvp one.
file transfers – receiving and sending attachments in channels and DMs (whether images are embedded into the conversation view or not is secondary to me)
We call these attachments in purple 3. Everything is there for them except persistence and the ui doesn’t display or give you an option to add them yet.
File transfers are peer 2 peer file transfers like DCC in IRC for example.
signal for "this message has (probably) been displayed and read (the user interacted with the conversation in some way) – requested by an early user
Another feature important to me is to be able to use the chat.sr.ht bouncer. Connecting to the bouncer already works but there seem to be problems when trying to connect to a specific network. This is probably not the right place to go into detail, if I can identify the problem more closely I’ll open an issue on YouTrack.
If you’ve been using it quite a bit I’d like to pick your brain a bit. I was thinking it might make sense for there to be a separate protocol plugin for bouncers that could manage the accounts and stuff, but the issue there is it’d have to re-implement IRCv3 or maybe we could create a custom proxy or something to route the traffic through the bouncer.
I’ve used the bouncer with purple2 for quite some time. There’s a soju.im/bouncer-networks spec that would probably need to be implemented in ibis.
It looks like that spec covers the configuration you can also do via querying the BouncerServ user on chat.sr.ht.
Maybe we could have a soju plugin (and plugins for other bouncers) that act like a meta account, help you set up your desired networks on the bouncer, and create regular IRCv3 accounts in pidgin to connect to those.
Maybe we could have a soju plugin that acts like a meta account and helps you set up your desired networks on the bouncer and creates regular IRCv3 accounts in pidgin to connect to those.
Ok, sorry for the repetition But would that involve that much re-implementation of the IRCv3 plugin? Wouldn’t the soju/bouncer plugin just need to implement the parts necessary to set up the bouncer through ibis?