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

[Alexendoo]

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.

:[email protected] JOIN :#alexendoo
:holmes.freenode.net 353 captest @ #alexendoo :@Alexendoo [email protected]
: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).

[kylef]

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?

[Alexendoo]

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

[jobe1986]

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.

[dgw]

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.