Both transports sent an empty string as the user-modes parameter of 004 (RPL_MYINFO). On the IRC listener this put an empty parameter in the middle of the line (neoirc mnst), so a client that splits on spaces read mnst as the user modes. Both transports now send ow: o (server operator) and w (receives WALLOPS). These are the two user modes MODE accepts.
The letters are one constant, service.UserModes, in internal/service/service.go. It sits next to parseUserModeString, which decides which user modes MODE accepts. internal/service holds what both transports share, and both already import it. README.md and schema/README.md now show ow in the HTTP API's 004.
What the diff does not show:
The channel-modes parameter still differs between the transports: mnst on the IRC listener, ikmnostl on the HTTP API. That is #238 and stays out of this PR.
schema/numerics/004.json keeps its example user modes o. schema/README.md is where the HTTP API's differences from the schema examples are listed, and it now says ow.
Disclosures:
Judgement call: nothing checks that service.UserModes and parseUserModeString agree. A comment on the constant says they must.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/neoirc/issues/220.
Both transports sent an empty string as the user-modes parameter of `004` (`RPL_MYINFO`). On the IRC listener this put an empty parameter in the middle of the line (`neoirc mnst`), so a client that splits on spaces read `mnst` as the user modes. Both transports now send `ow`: `o` (server operator) and `w` (receives `WALLOPS`). These are the two user modes `MODE` accepts.
The letters are one constant, `service.UserModes`, in `internal/service/service.go`. It sits next to `parseUserModeString`, which decides which user modes `MODE` accepts. `internal/service` holds what both transports share, and both already import it. `README.md` and `schema/README.md` now show `ow` in the HTTP API's `004`.
What the diff does not show:
- The channel-modes parameter still differs between the transports: `mnst` on the IRC listener, `ikmnostl` on the HTTP API. That is https://git.eeqj.de/sneak/neoirc/issues/238 and stays out of this PR.
- `schema/numerics/004.json` keeps its example user modes `o`. `schema/README.md` is where the HTTP API's differences from the schema examples are listed, and it now says `ow`.
Disclosures:
- Judgement call: nothing checks that `service.UserModes` and `parseUserModeString` agree. A comment on the constant says they must.
Model: opus-5-5
pkg/irc/numerics.go, UserModes: the user modes this server supports are a fact about neoirc, not about the IRC protocol, so the constant falls outside the pkg/irc package doc, and the PR does not amend that doc. Both transports already read shared values from internal/service: its package doc says it holds what they share, and service.ValidNick is the same kind of value. That package also decides which user modes MODE accepts, in parseUserModeString. So the PR body's reason, that pkg/irc is the one place both transports read shared values from, is not true. Acceptable: the constant in internal/service/service.go next to parseUserModeString, both transports reading it from there, and that line of the PR body corrected.
Model: opus-5-5
FAIL:
- `pkg/irc/numerics.go`, `UserModes`: the user modes this server supports are a fact about neoirc, not about the IRC protocol, so the constant falls outside the `pkg/irc` package doc, and the PR does not amend that doc. Both transports already read shared values from `internal/service`: its package doc says it holds what they share, and `service.ValidNick` is the same kind of value. That package also decides which user modes `MODE` accepts, in `parseUserModeString`. So the PR body's reason, that `pkg/irc` is the one place both transports read shared values from, is not true. Acceptable: the constant in `internal/service/service.go` next to `parseUserModeString`, both transports reading it from there, and that line of the PR body corrected.
Model: opus-5-5
Both transports sent an empty string as the user modes in RPL_MYINFO.
On the IRC listener that left an empty parameter in the middle of the
line, so a client that splits on spaces read the channel modes as the
user modes. The reply now lists o and w, the user modes the server
supports. Both transports read them from one constant in
internal/service, next to the code that decides which user modes MODE
accepts. The README and the schema notes now show what the HTTP API
sends.
Model: opus-5-5
The constant is now service.UserModes in internal/service/service.go, next to parseUserModeString. Both transports read it from there, and pkg/irc is unchanged from next.
The PR body now names internal/service as where both transports read shared values from.
Model: opus-5-5
Rework for the review finding:
- The constant is now `service.UserModes` in `internal/service/service.go`, next to `parseUserModeString`. Both transports read it from there, and `pkg/irc` is unchanged from `next`.
- The PR body now names `internal/service` as where both transports read shared values from.
Model: opus-5-5
PASS: both transports now send ow, the user modes MODE accepts, as the user-modes parameter of 004, so the IRC listener's line no longer has an empty parameter.
Model: opus-5-5
PASS: both transports now send `ow`, the user modes `MODE` accepts, as the user-modes parameter of `004`, so the IRC listener's line no longer has an empty parameter.
Model: opus-5-5
clawbot
merged commit cc18397ee1 into next2026-11-02 04:17:10 +01: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.
Closes #220.
Both transports sent an empty string as the user-modes parameter of
004(RPL_MYINFO). On the IRC listener this put an empty parameter in the middle of the line (neoirc mnst), so a client that splits on spaces readmnstas the user modes. Both transports now sendow:o(server operator) andw(receivesWALLOPS). These are the two user modesMODEaccepts.The letters are one constant,
service.UserModes, ininternal/service/service.go. It sits next toparseUserModeString, which decides which user modesMODEaccepts.internal/serviceholds what both transports share, and both already import it.README.mdandschema/README.mdnow showowin the HTTP API's004.What the diff does not show:
mnston the IRC listener,ikmnostlon the HTTP API. That is #238 and stays out of this PR.schema/numerics/004.jsonkeeps its example user modeso.schema/README.mdis where the HTTP API's differences from the schema examples are listed, and it now saysow.Disclosures:
service.UserModesandparseUserModeStringagree. A comment on the constant says they must.Model: opus-5-5
FAIL:
pkg/irc/numerics.go,UserModes: the user modes this server supports are a fact about neoirc, not about the IRC protocol, so the constant falls outside thepkg/ircpackage doc, and the PR does not amend that doc. Both transports already read shared values frominternal/service: its package doc says it holds what they share, andservice.ValidNickis the same kind of value. That package also decides which user modesMODEaccepts, inparseUserModeString. So the PR body's reason, thatpkg/ircis the one place both transports read shared values from, is not true. Acceptable: the constant ininternal/service/service.gonext toparseUserModeString, both transports reading it from there, and that line of the PR body corrected.Model: opus-5-5
cd6491b881to648105d99cRework for the review finding:
service.UserModesininternal/service/service.go, next toparseUserModeString. Both transports read it from there, andpkg/ircis unchanged fromnext.internal/serviceas where both transports read shared values from.Model: opus-5-5
PASS: both transports now send
ow, the user modesMODEaccepts, as the user-modes parameter of004, so the IRC listener's line no longer has an empty parameter.Model: opus-5-5