An INVITE for a user on the IRC listener arrives as a server NOTICE, not as an INVITE line, and never names who invited them. deliverInviteMsg in internal/ircserver/relay.go sends NOTICE <nick> <first body line> from the server. The two transports also queue different bodies: handleInvite in internal/handlers/api.go queues [channel], and handleInvite in internal/ircserver/commands.go queues ["You have been invited to #chan"].
Seen on eceb5f2. An HTTP API user invites invitee, who is on the IRC listener: invitee's client gets :neoirc NOTICE invitee #inv. An IRC listener user invites invitee2: the client gets :neoirc NOTICE invitee2 :You have been invited to #inv. No IRC client treats either as an invite, and neither says who sent it. README.md lists INVITE among the IRC listener's supported commands and, under Channel Modes, says INVITE records an invite the target can use.
Fix: relay an INVITE as :<inviter>!<inviter>@* INVITE <nick> <channel>, taking the channel from the message body, and make the IRC listener queue the same body as the HTTP API ([channel]) so there is one format. An HTTP API client invited by an IRC listener user then gets ["#chan"] as the body, as it already does for an invite from an HTTP API user. README.md IRC listener section: one line saying an invite is delivered as an INVITE line.
Definition of done
An IRC listener user invited from either transport receives one INVITE line with the inviter as prefix and the channel as parameter.
Both transports queue the INVITE message in the same shape.
Tests in internal/ircserver for an invite from each transport.
One reviewed PR against next.
Model: fable-5-1
An INVITE for a user on the IRC listener arrives as a server NOTICE, not as an `INVITE` line, and never names who invited them. `deliverInviteMsg` in `internal/ircserver/relay.go` sends `NOTICE <nick> <first body line>` from the server. The two transports also queue different bodies: `handleInvite` in `internal/handlers/api.go` queues `[channel]`, and `handleInvite` in `internal/ircserver/commands.go` queues `["You have been invited to #chan"]`.
Seen on `eceb5f2`. An HTTP API user invites `invitee`, who is on the IRC listener: invitee's client gets `:neoirc NOTICE invitee #inv`. An IRC listener user invites `invitee2`: the client gets `:neoirc NOTICE invitee2 :You have been invited to #inv`. No IRC client treats either as an invite, and neither says who sent it. `README.md` lists INVITE among the IRC listener's supported commands and, under Channel Modes, says `INVITE` records an invite the target can use.
Fix: relay an INVITE as `:<inviter>!<inviter>@* INVITE <nick> <channel>`, taking the channel from the message body, and make the IRC listener queue the same body as the HTTP API (`[channel]`) so there is one format. An HTTP API client invited by an IRC listener user then gets `["#chan"]` as the body, as it already does for an invite from an HTTP API user. `README.md` IRC listener section: one line saying an invite is delivered as an INVITE line.
## Definition of done
1. An IRC listener user invited from either transport receives one `INVITE` line with the inviter as prefix and the channel as parameter.
2. Both transports queue the INVITE message in the same shape.
3. Tests in `internal/ircserver` for an invite from each transport.
4. One reviewed PR against `next`.
Model: fable-5-1
clawbot
self-assigned this 2026-10-20 16:51:35 +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.
An INVITE for a user on the IRC listener arrives as a server NOTICE, not as an
INVITEline, and never names who invited them.deliverInviteMsgininternal/ircserver/relay.gosendsNOTICE <nick> <first body line>from the server. The two transports also queue different bodies:handleInviteininternal/handlers/api.goqueues[channel], andhandleInviteininternal/ircserver/commands.goqueues["You have been invited to #chan"].Seen on
eceb5f2. An HTTP API user invitesinvitee, who is on the IRC listener: invitee's client gets:neoirc NOTICE invitee #inv. An IRC listener user invitesinvitee2: the client gets:neoirc NOTICE invitee2 :You have been invited to #inv. No IRC client treats either as an invite, and neither says who sent it.README.mdlists INVITE among the IRC listener's supported commands and, under Channel Modes, saysINVITErecords an invite the target can use.Fix: relay an INVITE as
:<inviter>!<inviter>@* INVITE <nick> <channel>, taking the channel from the message body, and make the IRC listener queue the same body as the HTTP API ([channel]) so there is one format. An HTTP API client invited by an IRC listener user then gets["#chan"]as the body, as it already does for an invite from an HTTP API user.README.mdIRC listener section: one line saying an invite is delivered as an INVITE line.Definition of done
INVITEline with the inviter as prefix and the channel as parameter.internal/ircserverfor an invite from each transport.next.Model: fable-5-1