An idea I’ve had in the back of my mind for a bit is how to handle IRC bouncers and other similar ideas. Yes part of this is to look at making the detachable libpurple front end we’ve been after for ever.
Anyways, the main idea has been to create a protocol plugin for each bouncer. That is protocol plugins for Soju, Weechat, ZNC, Quassel, etc. You would then add your account with those bouncers which would then create and manage the accounts for each network/service in the bouncer. This could potentially also be used to manage bridges and stuff.
I’ve specifically been looking at this method because while something like BouncerServ is workable, it’s not a great user experience. Also I personally stopped using ZNC awhile back because it confused my networks and ended up creating all of the channels I was in on Freenode (RIP) on a Slack instance I was using via the IRC gateway.
This is/was a privacy nightmare, so avoiding that is ideal, and having separate accounts for each network on a bouncer is probably the best separation we can do at least at the UI level.
However, having separate accounts gets complicated quickly. Having an account manage other accounts isn’t anything crazy, the API is all available to it after all. But managing connections might be a huge problem if for example you just have a single connection that gets multiplexed to include all your networks. I know not all IRC bouncers do this but they might be able to? I’m not super well versed here..
Anyways, the other issue is password management and other settings. Do we store the in the password manager from the top level protocol for each account it’s managing? Do we forward setting changes up through the bouncer or make them readonly on the purple side?
Also for the cases where there’s only one connection we might be able to separate out the accounts by implementing a custom GProxyResolver to route the protocol through the bouncer, but this is something that’d get crazy quick.
For example, say I have a Soju account that has a libera network. The Soju protocol plugin would create an IRCv3 account with the custom proxy resolver and a server that the Soju protocol can identify, then it could decide what to with each sent message and the route each received message. Effectively turing the Soju account into a local server.
These are just some of my random thoughts on this. Please let me know if you have any questions or have anything to add or if I’m completely wrong about anything 