ZNC doesn't send all channel statuses to client. #72

New Issue

2026-10-05T03:57:14+02:00

adam commented

2026-10-05 03:57:14 +02:00

When you detach channel and later attach it and you are opped and voiced, when you attach again, if you deop yourself, you appear as devoiced to client even if you are voiced.

Originally reported at WeeChat issue tracker, https://savannah.nongnu.org/bugs/?35175 , but according to them it's more like ZNC issue.

When you detach channel and later attach it and you are opped and voiced, when you attach again, if you deop yourself, you appear as devoiced to client even if you are voiced. Originally reported at WeeChat issue tracker, https://savannah.nongnu.org/bugs/?35175 , but according to them it's more like ZNC issue.

adam closed this issue

2026-10-05 03:57:14 +02:00

adam commented

2026-10-05 03:57:15 +02:00

16.02.2012 19:53, Mikaela Suomalainen пишет:

When you detach channel and later attach it and you are opped and voiced, when you attach again, if you deop yourself, you appear as devoiced to client even if you are voiced.

Originally reported at WeeChat issue tracker, https://savannah.nongnu.org/bugs/?35175 , but according to them it's more like ZNC issue.

Reply to this email directly or view it on GitHub:
https://github.com/znc/znc/issues/134
ZNC sends @+#channel only if client told ZNC that it supports such
syntax via "CAP REQ :multi-prefix" or via old "NAMESX"...
If client didn't say that, ZNC sends only the "oppest" permission.

16.02.2012 19:53, Mikaela Suomalainen пишет: > When you detach channel and later attach it and you are opped and voiced, when you attach again, if you deop yourself, you appear as devoiced to client even if you are voiced. > > Originally reported at WeeChat issue tracker, https://savannah.nongnu.org/bugs/?35175 , but according to them it's more like ZNC issue. > > --- > > Reply to this email directly or view it on GitHub: > https://github.com/znc/znc/issues/134 > ZNC sends @+#channel only if client told ZNC that it supports such > syntax via "CAP REQ :multi-prefix" or via old "NAMESX"... > If client didn't say that, ZNC sends only the "oppest" permission.

adam commented

2026-10-05 03:57:16 +02:00

As comment #3 on the savannah bug says:

 But by the way, I'm not sure if many modes are supported in this list of names (on join of a channel). So I'm not even sure that znc can do something for that problem.

This is correct. IRC only allows a single mode character in a NAMES reply. So only the highest mode can be sent out.
This bug in the IRC protocol was worked around with the NAMESX PROTOCTL (which is also available as a capability, but I forgot its name).

So IMHO znc is doing as much as it can do.

As comment #3 on the savannah bug says: ``` But by the way, I'm not sure if many modes are supported in this list of names (on join of a channel). So I'm not even sure that znc can do something for that problem. ``` This is correct. IRC only allows a single mode character in a NAMES reply. So only the highest mode can be sent out. This bug in the IRC protocol was worked around with the NAMESX PROTOCTL (which is also available as a capability, but I forgot its name). So IMHO znc is doing as much as it can do.

adam commented

2026-10-05 03:57:16 +02:00

Urgh. Github, that looks awful!

Anyway: Yes of course it could. But that's ugly, because it would mean that extra MODE changes are visible in the client.
A client has to figure out all the modes for everyone when it joins a channel anyway (even if it isn't connected via znc), so shouldn't this then be an issue with the client instead? Or does znc do something wrong which stops the client from correctly getting this data?

Urgh. Github, that looks awful! Anyway: Yes of course it could. But that's ugly, because it would mean that extra MODE changes are visible in the client. A client has to figure out all the modes for everyone when it joins a channel anyway (even if it isn't connected via znc), so shouldn't this then be an issue with the client instead? Or does znc do something wrong which stops the client from correctly getting this data?

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#72