I'm considering hosting soju
in a setting where all users entitled to use the soju
instance, would also be entitled to use a local IRCnet.
As both would use the same IdP (via OAuth) it should be possible to leverate authentication-to-soju
, so into soju
authenticating to the IRCnet.
Would that be an upstreamable feature ?
It seems like this issue is about both connecting new users to the network and adding some authentication mechanism between soju and an upstream server to automatically log in users?
There are multiple ways to implement the former:
- Add some kind of "new user" event to the soju admin IPC so that a third-party daemon can configure the new user accordingly. This solution is the most flexible (the external daemon can do anything), but is somewhat racy (the external daemon can be out-of-sync) and new users aren't initially set up with the right configuration (the external daemon handles the event asynchronously).
- Add a bouncer-wide mechanism to define the default configuration for a new user. Could be specified in the config file (but would duplicate a lot of the DB schema) or as a template user (a real, disabled user, duplicated when creating a new user).
- Add a concept of "builtin" network: when no network is specified when connecting to the bouncer, the connection is bound to this network. The network cannot be disabled/removed by users.
The latter, I haven't thought about yet. I would be concerned about the security implications of forwarding automatically bouncer credentials to a server (option 1 could do it on its own, would be less of a concern with option 3).