API for clients to get ZNC info #972

New Issue

2026-10-05T04:56:21+02:00

adam commented

2026-10-05 04:56:21 +02:00

It would be awesome if ZNC had some way to query all of the user's networks, including credentials to connect to them. (Probably ZNC would have to generate and keep track of a token that could be handed out to clients, unless it stores user passwords in plaintext? Which hopefully it doesn't.)

This would allow clients to have a "sign in with ZNC" button or something like that so users wouldn't have to type in all their network details again. I'm thinking maybe this could be a *api virtual user that clients could PM or something? That way they could use their existing IRC stack and not have to vendor in an HTTP library or anything like that. Having the API run over IRC would also allow pushing events to the client in realtime, e.g. "the user deleted/added a network" or whatever, so the client could update its UI immediately without having to regularly poll. Whatever this looks like should be extensible in case we end up wanting to expose more meta-information in the future.

It would be awesome if ZNC had some way to query all of the user's networks, including credentials to connect to them. (Probably ZNC would have to generate and keep track of a token that could be handed out to clients, unless it stores user passwords in plaintext? Which hopefully it doesn't.) This would allow clients to have a "sign in with ZNC" button or something like that so users wouldn't have to type in all their network details again. I'm thinking maybe this could be a `*api` virtual user that clients could PM or something? That way they could use their existing IRC stack and not have to vendor in an HTTP library or anything like that. Having the API run over IRC would also allow pushing events to the client in realtime, e.g. "the user deleted/added a network" or whatever, so the client could update its UI immediately without having to regularly poll. Whatever this looks like should be extensible in case we end up wanting to expose more meta-information in the future.

adam commented

2026-10-05 04:56:22 +02:00

This is an alternative to #515

Sending such events from *api is easy, subject to deciding how the protocol should look like, of course. But managing such tokens - not so. Where would they be stored? What happens to them if ZNC is configured to use an external auth provider (e.g. via Cyrus SASL), and user changes the password there? Should clients logging in via the token have access to change the ZNC password?

I think limiting the token to a single time login only would be acceptable answer to these questions, where client needs to login using usual password to one network to be able to login to other networks next.

This is an alternative to #515 Sending such events from `*api` is easy, subject to deciding how the protocol should look like, of course. But managing such tokens - not so. Where would they be stored? What happens to them if ZNC is configured to use an external auth provider (e.g. via Cyrus SASL), and user changes the password there? Should clients logging in via the token have access to change the ZNC password? I think limiting the token to a single time login only would be acceptable answer to these questions, where client needs to login using usual password to one network to be able to login to other networks next.

adam commented

2026-10-05 04:56:23 +02:00

I think limiting the token to a single time login only would be acceptable answer to these questions, where client needs to login using usual password to one network to be able to login to other networks next.

This makes sense to me. Long-term I think it would be great to store the token persistently somewhere because it would move ZNC closer to a model more like modern webapps, where 3rd-party clients don't have to save the user's password and users can review the list of authorized clients and revoke individual clients if they want. But the devil's in the details and there are a lot of sticky details, as you note. And we can always add that persistence later.

I wonder if it would make sense to have a well-known virtual network too, so clients wouldn't have to know any of the user's network names? I.e. they'd connect to a "network" called api or whatever and that network would only have the *api user on it, so the client could perform network discovery. Does that make sense/seem like a reasonable idea to you?

If I find some time today I might try to hack up a prototype of this in a module, though my C++ is a little rusty... so no promises :P

> I think limiting the token to a single time login only would be acceptable answer to these questions, where client needs to login using usual password to one network to be able to login to other networks next. This makes sense to me. Long-term I think it would be great to store the token persistently somewhere because it would move ZNC closer to a model more like modern webapps, where 3rd-party clients don't have to save the user's password and users can review the list of authorized clients and revoke individual clients if they want. But the devil's in the details and there are a _lot_ of sticky details, as you note. And we can always add that persistence later. I wonder if it would make sense to have a well-known virtual network too, so clients wouldn't have to know _any_ of the user's network names? I.e. they'd connect to a "network" called `api` or whatever and that network would _only_ have the `*api` user on it, so the client could perform network discovery. Does that make sense/seem like a reasonable idea to you? If I find some time today I might try to hack up a prototype of this in a module, though my C++ is a little rusty... so no promises :P

adam commented

2026-10-05 04:56:24 +02:00

they'd connect to a "network" called api or whatever and that network

If I not mistake, if the requested network doesn't exist, the client will connect with no network. So choose some random name

though my C++ is a little rusty

Perl or Python maybe?

> they'd connect to a "network" called api or whatever and that network If I not mistake, if the requested network doesn't exist, the client will connect with no network. So choose some random name > though my C++ is a little rusty Perl or Python maybe?

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#972