Show an IRC listener user what their session sends from other clients (closes #179)
check / check (push) Waiting to run

The relay dropped every PRIVMSG, NOTICE, JOIN, PART, NICK, QUIT, TOPIC,
MODE and KICK sent under the connection's own nick, so an IRC listener
connection never saw what its session did from another client. The
relay now drops nothing by nick. Instead, the service methods that fan
out a user's own command take the client whose queue to skip: the IRC
listener passes its own client, which has already written the echo, and
the HTTP API passes 0. Channel messages and PARTs now also go to the
sender's own session, so the HTTP handler no longer queues the
channel-message echo itself and SendChannelMessage no longer returns
the message's row ID.

Model: opus-5-5
This commit is contained in:
2026-10-21 11:24:32 +00:00
parent d539b4c558
commit 083d2073bb
11 changed files with 385 additions and 243 deletions
+8 -7
View File
@@ -268,10 +268,12 @@ rules). Case-sensitive comparison is unambiguous.
A single user session can have multiple clients (phone, laptop, terminal).
- Each client gets a **separate server-to-client (S2C) message queue**.
- The server fans out messages and events from other users, and the user's own
DMs and the channel messages it sends over the HTTP API, to every client queue
for that user session. Replies to a command (numerics) go only to the client
that sent it.
- The server fans out messages and events from other users, and those the user
sends from any of its clients, to every client queue for that user session.
The one exception is an IRC listener connection, which gets nothing queued for
a command it sent itself: it has already sent its user the echo, or, for
`PRIVMSG` and `NOTICE`, IRC sends none. Replies to a command (numerics) go
only to the client that sent it.
- `GET /api/v1/messages` delivers from the calling client's specific queue,
identified by the auth cookie.
- Client queues have **independent expiry/pruning** — one client going offline
@@ -760,9 +762,8 @@ Leave a channel.
**Behavior:**
- The PART event goes to the other channel members, not to the departing user;
the HTTP response confirms the part. (The IRC listener echoes the PART to its
own connection.)
- The PART event goes to every channel member, the departing user's own clients
included. (An IRC listener connection that sends a PART echoes it itself.)
- If the channel is empty after the user leaves, the channel is **deleted**
(ephemeral channels).
- If the user is not in the channel, the server returns an error.