adam/znc
1
0 Fork 0
mirror of https://github.com/znc/znc.git synced 2026-10-31 01:32:02 +01:00
Code Issues 362 Packages Projects Releases Wiki Activity

userhost-in-names provides inconsistent replies if unsupported by the server #669

New Issue
Open
opened 2026-10-05 04:37:26 +02:00 by adam · 4 comments
adam commented 2026-10-05 04:37:26 +02:00
Owner
Copy link
Copy source

Version: ZNC 1.7.x-git-536-0268f6d

An example:

CAP LS
:irc.znc.in CAP unknown-nick LS :batch cap-notify echo-message multi-prefix server-time userhost-in-names znc.in/batch znc.in/self-message znc.in/server-time-iso
CAP REQ :userhost-in-names
:irc.znc.in CAP unknown-nick ACK :userhost-in-names
CAP END

PASS _______
NICK captest
USER captest/freenode - - :captest

[welcome message, modes]

On a channel automatically joined the response is partially in the new form, however only for the current user.

:captest!~captest@macleod.io JOIN :#alexendoo
:holmes.freenode.net 353 captest @ #alexendoo :@Alexendoo captest!~captest@macleod.io
:holmes.freenode.net 366 captest #alexendoo :End of /NAMES list.

However for a normal use of NAMES #channel it appears to not work

NAMES #alexendoo
:holmes.freenode.net 353 captest @ #alexendoo :captest @Alexendoo
:holmes.freenode.net 366 captest #alexendoo :End of /NAMES list.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/29551137-userhost-in-names-provides-inconsistent-replies-if-unsupported-by-the-server?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).
Version: `ZNC 1.7.x-git-536-0268f6d` An example: ``` CAP LS :irc.znc.in CAP unknown-nick LS :batch cap-notify echo-message multi-prefix server-time userhost-in-names znc.in/batch znc.in/self-message znc.in/server-time-iso CAP REQ :userhost-in-names :irc.znc.in CAP unknown-nick ACK :userhost-in-names CAP END PASS _______ NICK captest USER captest/freenode - - :captest [welcome message, modes] ``` On a channel automatically joined the response is partially in the new form, however only for the current user. ``` :captest!~captest@macleod.io JOIN :#alexendoo :holmes.freenode.net 353 captest @ #alexendoo :@Alexendoo captest!~captest@macleod.io :holmes.freenode.net 366 captest #alexendoo :End of /NAMES list. ``` However for a normal use of NAMES #channel it appears to not work ``` NAMES #alexendoo :holmes.freenode.net 353 captest @ #alexendoo :captest @Alexendoo :holmes.freenode.net 366 captest #alexendoo :End of /NAMES list. ``` ## <bountysource-plugin> --- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/29551137-userhost-in-names-provides-inconsistent-replies-if-unsupported-by-the-server?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github). </bountysource-plugin> <!-- github-sync-id:124647746 -->
adam commented 2026-10-05 04:37:27 +02:00
Author
Owner
Copy link
Copy source

Is ZNC doesn't know the hostmask for the nick there isn't really much else it could do. What do you suggest that ZNC does instead @Alexendoo?

Is ZNC doesn't know the hostmask for the nick there isn't really much else it could do. What do you suggest that ZNC does instead @Alexendoo? <!-- github-comment-id:271186470 -->
adam commented 2026-10-05 04:37:28 +02:00
Author
Owner
Copy link
Copy source

I would suggest having it not advertise the capability if it isn't able to provide it, and to use cap-notify if that changes

I would suggest having it not advertise the capability if it isn't able to provide it, and to use cap-notify if that changes <!-- github-comment-id:271278204 -->
adam commented 2026-10-05 04:37:28 +02:00
Author
Owner
Copy link
Copy source

An alternative solution could be for ZNC to make use of the WHO command to get the missing information before forwarding the NAMES replies on to the client. It's pretty reliable that the WHO command will list all users in the specified channel regardless of user mode +i so long as the issuing user is also in the channel.

An alternative solution could be for ZNC to make use of the WHO command to get the missing information before forwarding the NAMES replies on to the client. It's pretty reliable that the WHO command will list all users in the specified channel regardless of user mode +i so long as the issuing user is also in the channel. <!-- github-comment-id:460109313 -->
adam commented 2026-10-05 04:37:29 +02:00
Author
Owner
Copy link
Copy source

ACKing userhost-in-names but omitting the hostmask from some entries in the replies looks like a pretty clear spec violation. The spec says "the full hostmask (nick!user@host) of every user listed". ZNC does not always include the hostmask for every user, therefore it is not following the spec.

ACKing `userhost-in-names` but omitting the hostmask from some entries in the replies looks like a pretty clear spec violation. [The spec](https://ircv3.net/specs/extensions/userhost-in-names) says "the full hostmask (nick!user@host) of every user listed". ZNC does not always include the hostmask for every user, therefore it is not following the spec. <!-- github-comment-id:1166065361 -->
Sign in to join this conversation.
No Branch/Tag Specified
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/znc#669