The HTTP API enforces these channel modes; the IRC listener does not. Its JOIN takes no channel key, so an IRC client cannot join a +k channel. Its INVITE records no invite, so it cannot admit anyone to a +i channel. Its LIST and WHOIS show +s channels to non-members, and its PRIVMSG skips the hashcash check on +H channels. Found while checking the README against the code for #120.
Reading taken for +H: an IRC client has no way to attach a hashcash stamp, so its PRIVMSG to a +H channel is refused with 404 (ERR_CANNOTSENDTOCHAN) rather than let through, since letting it through would defeat the mode.
Definition of done
Over the IRC listener: JOIN #chan key joins a +k channel with the right key and gets 475 with a wrong or missing one; INVITE admits the invited user to a +i channel; LIST and WHOIS hide +s channels from non-members as the HTTP API does; PRIVMSG to a +H channel gets 404.
The checks are the service code the HTTP API already uses, not a second copy.
Tests for each in internal/ircserver; README.md's channel modes table updated.
One reviewed PR against next.
Model: opus-5-5
The HTTP API enforces these channel modes; the IRC listener does not. Its `JOIN` takes no channel key, so an IRC client cannot join a `+k` channel. Its `INVITE` records no invite, so it cannot admit anyone to a `+i` channel. Its `LIST` and `WHOIS` show `+s` channels to non-members, and its `PRIVMSG` skips the hashcash check on `+H` channels. Found while checking the README against the code for https://git.eeqj.de/sneak/neoirc/pulls/120.
Reading taken for `+H`: an IRC client has no way to attach a hashcash stamp, so its `PRIVMSG` to a `+H` channel is refused with 404 (`ERR_CANNOTSENDTOCHAN`) rather than let through, since letting it through would defeat the mode.
## Definition of done
1. Over the IRC listener: `JOIN #chan key` joins a `+k` channel with the right key and gets 475 with a wrong or missing one; `INVITE` admits the invited user to a `+i` channel; `LIST` and `WHOIS` hide `+s` channels from non-members as the HTTP API does; `PRIVMSG` to a `+H` channel gets 404.
2. The checks are the service code the HTTP API already uses, not a second copy.
3. Tests for each in `internal/ircserver`; `README.md`'s channel modes table updated.
4. One reviewed PR against `next`.
Model: opus-5-5
clawbot
self-assigned this 2026-10-08 08:48:57 +02:00
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.
The HTTP API enforces these channel modes; the IRC listener does not. Its
JOINtakes no channel key, so an IRC client cannot join a+kchannel. ItsINVITErecords no invite, so it cannot admit anyone to a+ichannel. ItsLISTandWHOISshow+schannels to non-members, and itsPRIVMSGskips the hashcash check on+Hchannels. Found while checking the README against the code for #120.Reading taken for
+H: an IRC client has no way to attach a hashcash stamp, so itsPRIVMSGto a+Hchannel is refused with 404 (ERR_CANNOTSENDTOCHAN) rather than let through, since letting it through would defeat the mode.Definition of done
JOIN #chan keyjoins a+kchannel with the right key and gets 475 with a wrong or missing one;INVITEadmits the invited user to a+ichannel;LISTandWHOIShide+schannels from non-members as the HTTP API does;PRIVMSGto a+Hchannel gets 404.internal/ircserver;README.md's channel modes table updated.next.Model: opus-5-5