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
Plan: one PR against next meeting the definition of done as written, with the +H reading above. Over the IRC listener, JOIN #chan key checks +k, INVITE admits to +i, LIST and WHOIS hide +s channels from non-members, and PRIVMSG to a +H channel gets 404, each through the service code the HTTP API already uses. Tests in internal/ircserver; README.md's channel modes table updated. #128 changes the same files and follows this one.
Model: opus-5-5
Plan: one PR against `next` meeting the definition of done as written, with the `+H` reading above. Over the IRC listener, `JOIN #chan key` checks `+k`, `INVITE` admits to `+i`, `LIST` and `WHOIS` hide `+s` channels from non-members, and `PRIVMSG` to a `+H` channel gets 404, each through the service code the HTTP API already uses. Tests in `internal/ircserver`; `README.md`'s channel modes table updated. https://git.eeqj.de/sneak/neoirc/issues/128 changes the same files and follows this one.
Model: opus-5-5
Built in #139. The IRC listener's JOIN, INVITE, LIST, WHOIS and PRIVMSG now go through the checks the HTTP API uses; the INVITE checks and the channel hashcash check moved from the HTTP handlers into internal/service so there is one copy of each.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/neoirc/pulls/139. The IRC listener's `JOIN`, `INVITE`, `LIST`, `WHOIS` and `PRIVMSG` now go through the checks the HTTP API uses; the `INVITE` checks and the channel hashcash check moved from the HTTP handlers into `internal/service` so there is one copy of each.
Model: opus-5-5
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
Plan: one PR against
nextmeeting the definition of done as written, with the+Hreading above. Over the IRC listener,JOIN #chan keychecks+k,INVITEadmits to+i,LISTandWHOIShide+schannels from non-members, andPRIVMSGto a+Hchannel gets 404, each through the service code the HTTP API already uses. Tests ininternal/ircserver;README.md's channel modes table updated. #128 changes the same files and follows this one.Model: opus-5-5
Built in #139. The IRC listener's
JOIN,INVITE,LIST,WHOISandPRIVMSGnow go through the checks the HTTP API uses; theINVITEchecks and the channel hashcash check moved from the HTTP handlers intointernal/serviceso there is one copy of each.Model: opus-5-5