Earlier quoted context omitted.
> The area inside the chat window is HTML rendered via WebKit and you can change the theme easily KDE's Kopete (and after that, the now defunct KDE Telepathy) could that too. Maybe GNOME's Empathy client could that too. I agree all of that was really cool. I sorely miss those all-in-one messengers completely integrated to the desktop.
In Kopete we even had Latex rendering plugins and auto-away plugins using motion detection :-) (I started that project decades ago and still grateful to it, as it was the start of my career in tech)
Pidgin: The Universal Chat Client
111–120 of 181 posts
Re: Pidgin: The Universal Chat Client
#112I really miss Adium ( https://adium.im ) which was based on Pidgin's libpurple. Adium had such a great user experience. It was built with native widgets and also incorporated chat themes that were implemented using WebKit's rendering ( https://www.adiumxtras.com/index.php?a=search&cat_id=5&sort=... ). It was fast and memory friendly given that it was a native app and the themes were just small templates offering a di…
> Instead, I now have FB Messenger, WhatsApp, iMessage, Discord, and Signal all running and taking up space in my dock. Why don’t you use a matrix client with bridges? I use telegram, WhatsApp and signal over Element. The bridges are not as great as the individual clients, but it’s definitely miles ahead of using five messaging apps.
Re: Pidgin: The Universal Chat Client
#113Weechat is pidgin for terminal. Check it out also if you pull together disparate systems.
Re: Pidgin: The Universal Chat Client
#114Earlier quoted context omitted.
it was for sure called gaim. one of the only usable aim clients that worked on linux in the 90s.
You can pretend it's the 90's and 00's if you like at https://gaim.pidgin.im/
Nowadays I use Zukitre, Tango and Go fonts to make something close-ish.
Re: Pidgin: The Universal Chat Client
#115I really miss Adium ( https://adium.im ) which was based on Pidgin's libpurple. Adium had such a great user experience. It was built with native widgets and also incorporated chat themes that were implemented using WebKit's rendering ( https://www.adiumxtras.com/index.php?a=search&cat_id=5&sort=... ). It was fast and memory friendly given that it was a native app and the themes were just small templates offering a di…
Re: Pidgin: The Universal Chat Client
#116Earlier quoted context omitted.
Stage 2 evokes warm memories. The clients were featureful enough but very far from being resource hogs. The UIs were workable and hid plenty of options in their menus. The webcam features on MSN messenger landed at the same time as broadband internet became widespread in my country, when I was at school, so everyone was in on the novelty. Some of it is certainly the cynicism of age and work life, but I'm certain some…
Thats probably more to do with your perspective rather than anything to do with the clients. I find discord to be very exciting and it’s always a joy to use. The idea of persistent voice channels might not have been invented by discord but it’s where the average person really first discovered them. Getting home and seeing a few friends on discord and joining in has always been a magic experience for me.
Re: Pidgin: The Universal Chat Client
#117Re: Pidgin: The Universal Chat Client
#118Re: Pidgin: The Universal Chat Client
#119Earlier quoted context omitted.
> Instead, I now have FB Messenger, WhatsApp, iMessage, Discord, and Signal all running and taking up space in my dock. Why don’t you use a matrix client with bridges? I use telegram, WhatsApp and signal over Element. The bridges are not as great as the individual clients, but it’s definitely miles ahead of using five messaging apps.
Honest question: when registering for those bridges is it just as simple as putting in your username/password or do you have to do other gyrations to make it work? Do you have to upgrade continually to avoid the services playing whack-a-mole with your bridges? I ask because I’d like to set up Matrix bridges like that locally, but if I have to create a Discord bot account or fish out an API key then that’s asking a bi…
EDIT: If you can do without Discord DMs, you don't even need to run the bridge yourself or supply discord credentials - just invite a bot to a discord server if it isn't already
(Obviously if you're concerned of privacy you wouldn't be having those conversations on Discord in the first place)
Re: Pidgin: The Universal Chat Client
#120Earlier quoted context omitted.
> Instead, I now have FB Messenger, WhatsApp, iMessage, Discord, and Signal all running and taking up space in my dock. Why don’t you use a matrix client with bridges? I use telegram, WhatsApp and signal over Element. The bridges are not as great as the individual clients, but it’s definitely miles ahead of using five messaging apps.
Maybe I'll look into it more, but it feels messy and complicated at first glance. Portal rooms, plumbed rooms, bridgebot bridges, Bot-API bridges, puppeted bridges, double-puppeted bridges, server-to-server briding, and sidecar bridges. I haven't used it so some of this may be wrong and I'm happy to accept corrections. It seems like a puppeted bridge requires me to send the messages to the Matrix server who then has…
This is kind of how it's done today but also not exactly. The bridge (which is what has access to your account and messages) is its own process and could in principle be run on a separate host (like your own device for a single-user bridge). However, most (all?) public homeservers access for connecting puppeting bridges (meaning "virtual" Matrix identities for each identity on the bridged network, rather than just having a single "botuser" for all conversations through the bridge) and the API for access is rather coarse.
Also, last time I checked most bridges do not implement E2EE and signing properly, which means that the homeserver it connects to both gets read-access to bridged messages and can impersonate. This is mostly a matter of implementation not being prioritized highly in bridge projects. Currently that can be worked around to get E2EE even for cleartext bridges by running a protocol-specific proxy called pantalaimon which sits between the bridge and the homeserver and terminates encryption.
There are tradeoffs that can be made, which can be seen in the different alternatives for IRC bridges. For example, matterbridge is more of a typical bot (supporting loads of protocols!) and can be run towards a remote homeserver as a normal user.
https://github.com/hifi/heisenbridge#comparison
https://github.com/42wim/matterbridge/wiki/Section-Matrix-%2...
I am certain we will see better interfaces to allow people to run local personal IM bridges without the requirements and overhead involved today. Thinking out loud here, I could imagine a minimal per-user homeserver baked into a client, that only does bridging for that user and only federates with the homeserver of that users' accounts. That could tick all the boxes even before P2P matrix I think.
The benefit of this approach over pidgin or a purely local single-user homeserver (which are viable and it sounds like you kind of want) would be all the conveniences people have gotten used to with centralized platforms... E.g. if you have the bridged rooms on a remote homeserver, seamless retention of histories across all your devices, without needing to be simultaneously online. But you'd also only need to keep credentials local, and message content in cleartext would only ever be acessible on your client(s).