sessions.nick is unique by exact case (nick TEXT NOT NULL UNIQUE in 001_initial.sql), so alice and Alice can both exist. But the IRC listener's relay and both transports' user MODE compare nicks ignoring case (strings.EqualFold in internal/ircserver/relay.go, internal/ircserver/commands.go, internal/handlers/utility.go). So an IRC listener user alice never sees messages from Alice, and MODE Alice from alice is treated as her own nick. Found by the README review at #120 (comment).
Reading taken: nicks are unique ignoring case, as RFC 2812 has them and as the comparisons already assume; a second registration differing only in case gets 433. The other reading, exact comparisons everywhere, would make alice and Alice two users, which IRC clients do not expect.
Definition of done
Registering, or changing to, a nick that differs from an existing one only in case gets 433 on both transports.
Every nick lookup and comparison (PRIVMSG/NOTICE targets, WHOIS, KICK, INVITE, MODE, KILL, USERHOST, the relay) matches ignoring case, and the stored nick keeps the case it was registered with.
Tests on both transports; README.md says how nicks compare.
One reviewed PR against next.
Model: opus-5-5
`sessions.nick` is unique by exact case (`nick TEXT NOT NULL UNIQUE` in `001_initial.sql`), so `alice` and `Alice` can both exist. But the IRC listener's relay and both transports' user `MODE` compare nicks ignoring case (`strings.EqualFold` in `internal/ircserver/relay.go`, `internal/ircserver/commands.go`, `internal/handlers/utility.go`). So an IRC listener user `alice` never sees messages from `Alice`, and `MODE Alice` from `alice` is treated as her own nick. Found by the README review at https://git.eeqj.de/sneak/neoirc/pulls/120#issuecomment-133596.
Reading taken: nicks are unique ignoring case, as RFC 2812 has them and as the comparisons already assume; a second registration differing only in case gets 433. The other reading, exact comparisons everywhere, would make `alice` and `Alice` two users, which IRC clients do not expect.
## Definition of done
1. Registering, or changing to, a nick that differs from an existing one only in case gets 433 on both transports.
2. Every nick lookup and comparison (`PRIVMSG`/`NOTICE` targets, `WHOIS`, `KICK`, `INVITE`, `MODE`, `KILL`, `USERHOST`, the relay) matches ignoring case, and the stored nick keeps the case it was registered with.
3. Tests on both transports; `README.md` says how nicks compare.
4. One reviewed PR against `next`.
Model: opus-5-5
clawbot
self-assigned this 2026-10-08 10:31:19 +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.
sessions.nickis unique by exact case (nick TEXT NOT NULL UNIQUEin001_initial.sql), soaliceandAlicecan both exist. But the IRC listener's relay and both transports' userMODEcompare nicks ignoring case (strings.EqualFoldininternal/ircserver/relay.go,internal/ircserver/commands.go,internal/handlers/utility.go). So an IRC listener useralicenever sees messages fromAlice, andMODE Alicefromaliceis treated as her own nick. Found by the README review at #120 (comment).Reading taken: nicks are unique ignoring case, as RFC 2812 has them and as the comparisons already assume; a second registration differing only in case gets 433. The other reading, exact comparisons everywhere, would make
aliceandAlicetwo users, which IRC clients do not expect.Definition of done
PRIVMSG/NOTICEtargets,WHOIS,KICK,INVITE,MODE,KILL,USERHOST, the relay) matches ignoring case, and the stored nick keeps the case it was registered with.README.mdsays how nicks compare.next.Model: opus-5-5