userhost-in-names is ratified and unrequested. With it, RPL_NAMREPLY carries nick!user@host instead of a bare nick, so the member list is populated with real
hostmasks the moment a channel is joined — no WHO, no round trip.
Sibling to the WHOX issue and cheaper: this one is a capability request and a change to
the NAMREPLY parser (backend/irc/incoming.rs:489), which already strips prefixes.
Done looks like: joining a channel fills in who everybody is, not just what they
are called.
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.
`userhost-in-names` is ratified and unrequested. With it, `RPL_NAMREPLY` carries
`nick!user@host` instead of a bare nick, so the member list is populated with real
hostmasks the moment a channel is joined — no WHO, no round trip.
Sibling to the WHOX issue and cheaper: this one is a capability request and a change to
the NAMREPLY parser (`backend/irc/incoming.rs:489`), which already strips prefixes.
**Done looks like:** joining a channel fills in who everybody is, not just what they
are called.
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.
userhost-in-names is requested where offered, and NAMREPLY now splits nick!user@host before using the name as a key - which is the part that would have been a silent bug: filed under the full mask, every member would have been a stranger nothing else ever matched.
Libera does not advertise this one (solanum has no such cap), so on that network the hostmasks come from the WHO in #148 instead. Both paths feed the same record.
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).
`userhost-in-names` is requested where offered, and NAMREPLY now splits `nick!user@host` before using the name as a key - which is the part that would have been a silent bug: filed under the full mask, every member would have been a stranger nothing else ever matched.
Libera does not advertise this one (solanum has no such cap), so on that network the hostmasks come from the WHO in #148 instead. Both paths feed the same record.
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.
userhost-in-namesis ratified and unrequested. With it,RPL_NAMREPLYcarriesnick!user@hostinstead of a bare nick, so the member list is populated with realhostmasks the moment a channel is joined — no WHO, no round trip.
Sibling to the WHOX issue and cheaper: this one is a capability request and a change to
the NAMREPLY parser (
backend/irc/incoming.rs:489), which already strips prefixes.Done looks like: joining a channel fills in who everybody is, not just what they
are called.
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.
userhost-in-namesis requested where offered, and NAMREPLY now splitsnick!user@hostbefore using the name as a key - which is the part that would have been a silent bug: filed under the full mask, every member would have been a stranger nothing else ever matched.Libera does not advertise this one (solanum has no such cap), so on that network the hostmasks come from the WHO in #148 instead. Both paths feed the same record.