whox is ratified and unrequested, and there is no WHO anywhere in nobilis/src/backend/irc/ at all. The only way a hostmask ever arrives is an explicit
WHOIS for one person.
That matters more here than it looks. Ignoring somebody and banning somebody both want
a hostmask — an ignore keyed on a nick is undone by a nick change, and /ban without
one bans a name rather than a person. Right now the client has neither unless somebody
happens to have run a WHOIS.
What is needed
Request whox, and send WHO <channel> %tcuhnfar,<token> on join, which is the
whole point of WHOX: one reply per user with exactly the fields wanted, rather than
the RFC's fixed shape.
Fold the answers into the member list beside what NAMREPLY already gives.
Fall back to plain WHO where the server does not offer WHOX.
Done looks like: a hostmask is known for everybody in the channel without anybody
having asked for one.
Found by the 2026-09-10 coverage review, which measured IRC against the IRCv3
capability registry rather than against a feature list. moho requests 12 capabilities
plus SASL, covering 15 of the 25 client-relevant ratified extensions — WeeChat
supports around 35. This is one of the ten missing ones, filed separately because each
is independently doable.
`whox` is ratified and unrequested, and there is no `WHO` anywhere in
`nobilis/src/backend/irc/` at all. The only way a hostmask ever arrives is an explicit
WHOIS for one person.
That matters more here than it looks. Ignoring somebody and banning somebody both want
a hostmask — an ignore keyed on a nick is undone by a nick change, and `/ban` without
one bans a name rather than a person. Right now the client has neither unless somebody
happens to have run a WHOIS.
**What is needed**
- Request `whox`, and send `WHO <channel> %tcuhnfar,<token>` on join, which is the
whole point of WHOX: one reply per user with exactly the fields wanted, rather than
the RFC's fixed shape.
- Fold the answers into the member list beside what NAMREPLY already gives.
- Fall back to plain `WHO` where the server does not offer WHOX.
**Done looks like:** a hostmask is known for everybody in the channel without anybody
having asked for one.
Found by the 2026-09-10 coverage review, which measured IRC against the IRCv3
capability registry rather than against a feature list. moho requests 12 capabilities
plus SASL, covering **15 of the 25 client-relevant ratified extensions** — WeeChat
supports around 35. This is one of the ten missing ones, filed separately because each
is independently doable.
Done in nobilis de0ad86, with the client half in moho 4fd3bc6.
There is a WHO now, where there was none anywhere in the backend. WHOX (%tcuhnfa, with a fixed token so a reply to something a person typed is not folded into a roster) where the server advertises it, plain WHO everywhere else. Asked once per channel on arrival rather than per person on demand.
WHOX turned out to need one thing the ticket did not anticipate: it is the ratified extension with no capability of its own, advertised only in RPL_ISUPPORT - so ISUPPORT is now parsed and kept rather than only displayed as banner text.
Verified against Libera. A roster entry came back carrying [email protected], learned from the WHO rather than from any WHOIS.
Done in nobilis [de0ad86](https://git.salastil.com/Salastil/nobilis/commit/de0ad86), with the client half in moho [4fd3bc6](https://git.salastil.com/Salastil/moho/commit/4fd3bc6).
There is a WHO now, where there was none anywhere in the backend. WHOX (`%tcuhnfa`, with a fixed token so a reply to something a person typed is not folded into a roster) where the server advertises it, plain WHO everywhere else. Asked once per channel on arrival rather than per person on demand.
WHOX turned out to need one thing the ticket did not anticipate: it is the ratified extension with **no capability of its own**, advertised only in RPL_ISUPPORT - so ISUPPORT is now parsed and kept rather than only displayed as banner text.
**Verified against Libera.** A roster entry came back carrying `[email protected]`, learned from the WHO rather than from any WHOIS.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
whoxis ratified and unrequested, and there is noWHOanywhere innobilis/src/backend/irc/at all. The only way a hostmask ever arrives is an explicitWHOIS for one person.
That matters more here than it looks. Ignoring somebody and banning somebody both want
a hostmask — an ignore keyed on a nick is undone by a nick change, and
/banwithoutone bans a name rather than a person. Right now the client has neither unless somebody
happens to have run a WHOIS.
What is needed
whox, and sendWHO <channel> %tcuhnfar,<token>on join, which is thewhole point of WHOX: one reply per user with exactly the fields wanted, rather than
the RFC's fixed shape.
WHOwhere the server does not offer WHOX.Done looks like: a hostmask is known for everybody in the channel without anybody
having asked for one.
Found by the 2026-09-10 coverage review, which measured IRC against the IRCv3
capability registry rather than against a feature list. moho requests 12 capabilities
plus SASL, covering 15 of the 25 client-relevant ratified extensions — WeeChat
supports around 35. This is one of the ten missing ones, filed separately because each
is independently doable.
Done in nobilis de0ad86, with the client half in moho 4fd3bc6.
There is a WHO now, where there was none anywhere in the backend. WHOX (
%tcuhnfa, with a fixed token so a reply to something a person typed is not folded into a roster) where the server advertises it, plain WHO everywhere else. Asked once per channel on arrival rather than per person on demand.WHOX turned out to need one thing the ticket did not anticipate: it is the ratified extension with no capability of its own, advertised only in RPL_ISUPPORT - so ISUPPORT is now parsed and kept rather than only displayed as banner text.
Verified against Libera. A roster entry came back carrying
[email protected], learned from the WHO rather than from any WHOIS.