"Client ID" concept to make using multiple clients at the same time easier [$270 awarded] #229

New Issue

2026-10-05T04:06:24+02:00

adam commented

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

The current solution to deliver all messages to all clients regardless of if others are connected is outlined in the FAQ here, and basically boils down to creating multiple users, one for each client.

It works great, except keeping configurations in-sync between client devices, or user accounts to be specific, can get annoying.

My suggestion is to keep a single user but adding support for some unique client identifier that can be specified as part of the username. And then playback buffers are stored on a per user and client ID basis, rather than just based on the user. For the sake of simplicity, I'd personally like the client ID only to effect the buffer playback, as in module settings are still stored on a purely per user basis.

I'd suggest a IRC password string format of something like this:

username[@client_id][/network_name]:password

A few examples would be:

jimeh@macbookair/QuakeNet:mypassword
jimeh@iphone/QuakeNet:mypassword
jimeh@Nexus_4/QuakeNet:mypassword
jimeh@XChat/QuakeNet:mypassword

I think you get the idea :)

--- The **[$270 bounty](https://www.bountysource.com/issues/315409-client-id-concept-to-make-using-multiple-clients-at-the-same-time-easier?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** on this issue has been claimed at [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).

The current solution to deliver all messages to all clients regardless of if others are connected is outlined in the FAQ [here](http://wiki.znc.in/FAQ#How_to_store_private_messages_even_when_user_is_attached.2C_so_other_clients_can_see_them.3F), and basically boils down to creating multiple users, one for each client. It works great, except keeping configurations in-sync between client devices, or user accounts to be specific, can get annoying. My suggestion is to keep a single user but adding support for some unique client identifier that can be specified as part of the username. And then playback buffers are stored on a per user and client ID basis, rather than just based on the user. For the sake of simplicity, I'd personally like the client ID only to effect the buffer playback, as in module settings are still stored on a purely per user basis. I'd suggest a IRC password string format of something like this: ``` username[@client_id][/network_name]:password ``` A few examples would be: ``` jimeh@macbookair/QuakeNet:mypassword jimeh@iphone/QuakeNet:mypassword jimeh@Nexus_4/QuakeNet:mypassword jimeh@XChat/QuakeNet:mypassword ``` I think you get the idea :) ## <bountysource-plugin> --- The **[$270 bounty](https://www.bountysource.com/issues/315409-client-id-concept-to-make-using-multiple-clients-at-the-same-time-easier?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** on this issue has been claimed at [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github). </bountysource-plugin>

adam closed this issue

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

adam commented

2026-10-05 04:06:25 +02:00

Soon our poor password will look like user@client/net#foo%bar&baz:pass :(

Soon our poor password will look like `user@client/net#foo%bar&baz:pass` :(

adam commented

2026-10-05 04:06:25 +02:00

+1 for the concept. Would really like to have client-aware buffers for both channels and queries. Though shouldn't it be possible to generate a "fingerprint" for an individual client based on getting the client software version mixed with the IP address, rather than needing to "name" each client via the password?

+1 for the concept. Would really like to have client-aware buffers for both channels and queries. Though shouldn't it be possible to generate a "fingerprint" for an individual client based on getting the client software version mixed with the IP address, rather than needing to "name" each client via the password?

adam commented

2026-10-05 04:06:26 +02:00

@DarthGandalf So are you suggesting to add a generic key-value-mapping to the passwords which can easily be extended in the future? user=foo:network=bar:clientid=42;password=NoWay! duck

@DarthGandalf So are you suggesting to add a generic key-value-mapping to the passwords which can easily be extended in the future? user=foo:network=bar:clientid=42;password=NoWay! _duck_

adam commented

2026-10-05 04:06:26 +02:00

Oh and this also requires some new limit: NumberOfAllowedClients. Otherwise, if one can register an unlimited number of clients with znc, at some point of time we will surely run out of memory...

Oh and this also requires some new limit: NumberOfAllowedClients. Otherwise, if one can register an unlimited number of clients with znc, at some point of time we will surely run out of memory...

adam commented

2026-10-05 04:06:27 +02:00

@jreese I agree a client fingerprint of some kind would be quite nice. I don't know enough about the IRC protocol to know if clients identify themselves in a similar way to web browsers for example though.

Personally though I'd say if fingerprinting can be used, have it as an option, cause if you update your client to a new version, or switch client app on a device you'd potentially lose buffered messages.

@jreese I agree a client fingerprint of some kind would be quite nice. I don't know enough about the IRC protocol to know if clients identify themselves in a similar way to web browsers for example though. Personally though I'd say if fingerprinting can be used, have it as an option, cause if you update your client to a new version, or switch client app on a device you'd potentially lose buffered messages.

adam commented

2026-10-05 04:06:28 +02:00

I think it would be far simpler for the clients to store the last timestamp it was online. Then ZNC could provide the clients with the buffer since that timestamp.

I think it would be far simpler for the clients to store the last timestamp it was online. Then ZNC could provide the clients with the buffer since that timestamp.

adam commented

2026-10-05 04:06:28 +02:00

@psychon A limit would only be needed if fingerprinting can be done, and if so I'd imagine options relating to it, including something like "Allow Dynamic Client Registration".

@psychon A limit would only be needed if fingerprinting can be done, and if so I'd imagine options relating to it, including something like "Allow Dynamic Client Registration".

adam commented

2026-10-05 04:06:29 +02:00

@kylef Like I've previously stated, I don't know much about the IRC protocol, but wouldn't that require IRC clients to specifically add support for ZNC's buffer playback feature? I mean, it'd be awesome if IRC worked more like Campfire, but it does :(

@kylef Like I've previously stated, I don't know much about the IRC protocol, but wouldn't that require IRC clients to specifically add support for ZNC's buffer playback feature? I mean, it'd be awesome if IRC worked more like Campfire, but it does :(

adam commented

2026-10-05 04:06:30 +02:00

@jimeh you will only get nice buffers if your client supports it anyway.

http://ircv3.atheme.org/extensions/server-time-3.2

@jimeh you will only get nice buffers if your client supports it anyway. http://ircv3.atheme.org/extensions/server-time-3.2

adam commented

2026-10-05 04:06:30 +02:00

@kylef It sounds like that's what Textual does. However that seems to cover altering the time stamp, it doesn't help much with ZNC knowing what to deliver to clients if they don't supporting telling ZNC when they were last online.

@kylef It sounds like that's what Textual does. However that seems to cover altering the time stamp, it doesn't help much with ZNC knowing what to deliver to clients if they don't supporting telling ZNC when they were last online.

adam commented

2026-10-05 04:06:31 +02:00

When I've thought about this issue in the past, I've assumed we'd use the real name field, not jam it into the password.

When I've thought about this issue in the past, I've assumed we'd use the real name field, not jam it into the password.

adam commented

2026-10-05 04:06:32 +02:00

@ldamman It's only a suggestion for a feature, no need to stick to my specific technical example :)

@ldamman It's only a suggestion for a feature, no need to stick to my specific technical example :)

adam commented

2026-10-05 04:06:32 +02:00

+999999999999999999999 for the concept.

+999999999999999999999 for the concept.

adam commented

2026-10-05 04:06:33 +02:00

no news ?
+1

no news ? +1

adam commented

2026-10-05 04:06:34 +02:00

+1! I REALLY need this!

+1! I REALLY need this!

adam commented

2026-10-05 04:06:34 +02:00

To extend the idea with using the Realname, you could use the whole NICK/USER registration messages to identify the client, they are dropped anyways. And maybe add "client" as module scope.

I would not recommend to pack that much of complex information into the pass field.

To extend the idea with using the Realname, you could use the whole NICK/USER registration messages to identify the client, they are dropped anyways. And maybe add "client" as module scope. I would not recommend to pack that much of complex information into the pass field.

adam commented

2026-10-05 04:06:35 +02:00

+1

+1

adam commented

2026-10-05 04:06:36 +02:00

I like the idea of this the best:
username[@client_id][/network_name]:password

Am I to surmise that since the Client ID is optional, that any current setups, if imported into a ZNC instance with support for this, will use "default" as the client ID?

This would preserve the ability to import older configuration files, as well as not completely break current IRC client configurations (that may still be configured to auto connect with "username/network_name:password").

Ben (Ben @ most places, MrC @ Freenode)

I like the idea of this the best: username[@client_id][/network_name]:password Am I to surmise that since the Client ID is optional, that any current setups, if imported into a ZNC instance with support for this, will use "default" as the client ID? This would preserve the ability to import older configuration files, as well as not completely break current IRC client configurations (that may still be configured to auto connect with "username/network_name:password"). Ben (Ben @ most places, MrC @ Freenode)

adam commented

2026-10-05 04:06:36 +02:00

@MrBenC Back-compatibility is even more important than this feature ;)
So if it gets implemented at some point, it must be compatible with old configurations

@MrBenC Back-compatibility is even more important than this feature ;) So if it gets implemented at some point, it must be compatible with old configurations

adam commented

2026-10-05 04:06:37 +02:00

FYI, an alternative solution exists already: http://wiki.znc.in/Playback. All timestamps are based on server-time. Works with query buffers too: http://wiki.znc.in/Query_buffers.

FYI, an alternative solution exists already: http://wiki.znc.in/Playback. All timestamps are based on server-time. Works with query buffers too: http://wiki.znc.in/Query_buffers.

adam commented

2026-10-05 04:06:38 +02:00

Query buffers are nice, but they are still not as flexible as separate user per client. For example, clients can be attached to different set of channels (use only the most interesting channels from mobile, but bigger number of channels from desktop).
Which means that... What exactly features are wanted from such Client ID? Full replication of current possibilities via separate users? But also with automatic creation of new clients when new client connects?
In other words, what is the criteria for closing the bug? Or @jpnurmi 's work is already enough for it?
Probably it's the question to whoever posted the bounty...

Query buffers are nice, but they are still not as flexible as separate user per client. For example, clients can be attached to different set of channels (use only the most interesting channels from mobile, but bigger number of channels from desktop). Which means that... What exactly features are wanted from such Client ID? Full replication of current possibilities via separate users? But also with automatic creation of new clients when new client connects? In other words, what is the criteria for closing the bug? Or @jpnurmi 's work is already enough for it? Probably it's the question to whoever posted the bounty...

adam commented

2026-10-05 04:06:38 +02:00

Ok, the Bountysource thing is new to me. I guess it says I made the changes since I started the issue... lol

@jpnurmi The server-time playback thing is nice, but client support is very thin on the ground. Currently I have a main user that connects to the IRC servers, and for each client I use (laptop, Android phone, iOS phone, Android tablet) I have separate users with identical settings, only they connect to ZNC as the first user. This gives each client (regardless of Playback support) separate lists of buffered messages, so all messages always go to all devices.

It works, but any changes to IRC server/channel config is annoying, since I have to apply to same set of changes the main user, and the four client users too.

Hence I'd like to have a clientID feature which effectively keeps separate buffer lists for each registered/saved/setup clientID. So changing user settings only needs to be done in one place, while still ensuring all different clients always see all the messages regardless of support for the Playback module.

Of course if all clients supported Playback I wouldn't care about ZNC supporting clientIDs, but currently among the clients I use it's only Textual on OSX that supports Playback. My Android and iOS clients don't :(

Ok, the Bountysource thing is new to me. I guess it says I made the changes since I started the issue... lol @jpnurmi The server-time playback thing is nice, but client support is very thin on the ground. Currently I have a main user that connects to the IRC servers, and for each client I use (laptop, Android phone, iOS phone, Android tablet) I have separate users with identical settings, only they connect to ZNC as the first user. This gives each client (regardless of Playback support) separate lists of buffered messages, so all messages always go to all devices. It works, but any changes to IRC server/channel config is annoying, since I have to apply to same set of changes the main user, and the four client users too. Hence I'd like to have a clientID feature which effectively keeps separate buffer lists for each registered/saved/setup clientID. So changing user settings only needs to be done in one place, while still ensuring all different clients always see all the messages regardless of support for the Playback module. Of course if all clients supported Playback I wouldn't care about ZNC supporting clientIDs, but currently among the clients I use it's only Textual on OSX that supports Playback. My Android and iOS clients don't :(

adam commented

2026-10-05 04:06:39 +02:00

First of all, I'm not here for fishing the bounty. Just trying to raise awareness of "the other solution". :)

Of course if all clients supported Playback I wouldn't care about ZNC supporting clientIDs, but currently among the clients I use it's only Textual on OSX that supports Playback. My Android and iOS clients don't :(

Whilst the requirements and implementation details of client IDs seem to be still a bit fuzzy, the playback support is at least easy to add. I've opened a feature request for HoloIRC: https://github.com/tilal6991/HoloIRC/issues/92. Spreading the word would be much appreciated.

</thread hijack>

First of all, I'm not here for fishing the bounty. Just trying to raise awareness of "the other solution". :) > Of course if all clients supported Playback I wouldn't care about ZNC supporting clientIDs, but currently among the clients I use it's only Textual on OSX that supports Playback. My Android and iOS clients don't :( Whilst the requirements and implementation details of client IDs seem to be still a bit fuzzy, the playback support is at least easy to add. I've opened a feature request for HoloIRC: https://github.com/tilal6991/HoloIRC/issues/92. Spreading the word would be much appreciated. </thread hijack>

adam commented

2026-10-05 04:06:40 +02:00

I just realized that '@' is reserved. It's a valid character in usernames. Using email addresses as usernames makes perfect sense. What a pity... "@work" looked so nice. I don't want to use some other random weird special character. Does anyone have better ideas?

I just realized that '@' is reserved. It's a valid character in usernames. Using email addresses as usernames makes perfect sense. What a pity... "@work" looked so nice. I don't want to use some other random weird special character. Does anyone have better ideas?

adam commented

2026-10-05 04:06:40 +02:00

client specific channel lists: chanfilter
client specific buffers: clientbuffer

- client specific channel lists: [chanfilter](http://wiki.znc.in/Chanfilter) - client specific buffers: [clientbuffer](http://wiki.znc.in/Clientbuffer)

adam commented

2026-10-05 04:06:41 +02:00

@jpnurmi I just tested it on freenode, and USER a@b * * :test results in the username being ~a.

@jpnurmi I just tested it on freenode, and `USER a@b * * :test` results in the username being `~a`.

adam commented

2026-10-05 04:06:42 +02:00

@nyuszika7h Yes, that's intentional. Is it causing troubles? See the commit message of https://github.com/znc/znc/commit/8d77faa260d2a3eb0de7e6a78e7baad0d6cb7b62 for reasoning.

@nyuszika7h Yes, that's intentional. Is it causing troubles? See the commit message of https://github.com/znc/znc/commit/8d77faa260d2a3eb0de7e6a78e7baad0d6cb7b62 for reasoning.

adam commented

2026-10-05 04:06:43 +02:00

No, I haven't even tried the new changes yet, I just mentioned it as a matter of fact.

No, I haven't even tried the new changes yet, I just mentioned it as a matter of fact.

adam commented

2026-10-05 04:06:43 +02:00

Is this not implemented yet? ZNC 1.6.0 supports specifying client IDs.

Is this not implemented yet? ZNC 1.6.0 supports specifying client IDs.

adam commented

2026-10-05 04:06:44 +02:00

This is implemented, but nothing uses this yet with the exception of chanfilter third party module.

This is implemented, but nothing uses this yet with the exception of [chanfilter third party module.](http://wiki.znc.in/Chanfilter)

adam commented

2026-10-05 04:06:45 +02:00

Shall we close this?

https://github.com/znc/znc/commit/8d77faa260d2a3eb0de7e6a78e7baad0d6cb7b62 made it possible for clients to specify an ID via PASS or USER
chanfilter maintains client specific channel lists for identified clients
clientbuffer maintains client specific buffers for identified clients

Shall we close this? - https://github.com/znc/znc/commit/8d77faa260d2a3eb0de7e6a78e7baad0d6cb7b62 made it possible for clients to specify an ID via PASS or USER - [chanfilter](http://wiki.znc.in/Chanfilter) maintains client specific channel lists for identified clients - [clientbuffer](http://wiki.znc.in/Clientbuffer) maintains client specific buffers for identified clients

adam commented

2026-10-05 04:06:45 +02:00

It could probably be argued than chanfilter and clientbuffer are external modules.

It could probably be argued than chanfilter and clientbuffer are external modules.

adam commented

2026-10-05 04:06:46 +02:00

Who says external modules are not good enough solution? It was an intentional decision to leave them as external for now, to get some feedback and let them mature first. See #749 and #750.

Who says external modules are not good enough solution? It was an intentional decision to leave them as external for now, to get some feedback and let them mature first. See #749 and #750.

adam commented

2026-10-05 04:06:47 +02:00

Maybe this can be closed then

Maybe this can be closed then

adam commented

2026-10-05 04:06:47 +02:00

Maybe this can be closed then

I think so too, but I let someone else to do that because of the bounty.

> Maybe this can be closed then I think so too, but I let someone else to do that because of the bounty.

adam commented

2026-10-05 04:06:48 +02:00

They had chance to comment on it since March.

They had chance to comment on it since March.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#229