ServerlessIRCd — Extensions Plan (post-v1)

Plan for the IRC features that v1 deliberately left out: the remaining IRCv3 client-server extensions and IRC services (NickServ / ChanServ / OperServ / HostServ / MemoServ). Each section is scoped, mapped onto the existing hexagonal architecture, and proposed as tickets for tickets.md / progress.md once ratified.

Status: planning. Nothing here has landed. Ticket numbers below start at TICKET-110 (next free id per todo.md). When this plan is ratified the tickets get appended to tickets.md / progress.md under two new phase headings (Phase 12 — IRCv3 extensions, Phase 13 — IRC services) and the corresponding sections here are superseded.

1. Goals & non-goals

Goals

• Close the gap between the v1 cap set and what mainstream clients (IRCCloud, TheLounge, Textual, gamja) actually negotiate today.
• Add the IRCv3 features that compose with work already shipped: account-tag is meaningless without account-notify; message-tags without msgid / labeled-response leaves clients correlating by content.
• Provide a services story (NickServ/ChanServ) that fits the pure-reducer + location-of-authority architecture instead of bolting on a pseudo-server.
• Stay serverless-native: every new persistence need is behind a port (MessageStore, AccountStore, ServicesStore) so the same core runs on Cloudflare and AWS unchanged.

Non-goals (this plan)

• Server-to-server linking (TS6, IRCv3 S2S, SALR). Remains a non-goal, same as v1 (PLAN.md §1). A ServerLink seam is the documented design-for-later; no S2S work is proposed here.
• Atheme / Anope compatibility. Services are integrated into the daemon, not implemented as a separate pseudo-server speaking a link protocol. See §6 architecture decision.
• Full services suite parity. BotServ and StatServ are explicitly out of scope; OperServ ships a minimal AKILL/JUPE set only.
• Plaintext :6667 support. Still TLS-only (ADR-009).

2. Current cap set (baseline)

packages/irc-core/src/caps/capabilities.ts:28 advertises:

account-tag, away-notify, batch, chghost, draft/chathistory,
echo-message, extended-join, invite-notify, message-tags,
multi-prefix, safelist, sasl=PLAIN[,EXTERNAL], server-time

What follows fills in the missing pieces, grouped by spec maturity.

3. Missing IRCv3 extensions

3.1 Stable spec extensions (high-value, low-risk)

Notes:

• account-notify is the cheapest win and unblocks the account-tag/extended-join/account-notify triple that modern clients render fully.
• msgid is mostly there: the chathistory work (TICKET-063) already produces stable msgids via IdFactory.nonce(). This ticket is the cap advertisement + emitting the tag on every PRIVMSG/NOTICE/TAGMSG, not just recorded ones.
• labeled-response is the largest item because the request→reply correlation touches every reducer that emits a client-facing reply; the BATCH wrapper already exists (TICKET-025), so the work is in plumbing a per-request label through ctx.
• sts is config-driven only (no protocol state); the value is advertising the right TLS port for the deployed adapter.

3.2 Draft / spec-pending extensions

Notes:

• The draft/ prefix caps stay namespaced until the spec stabilizes, matching the existing draft/chathistory precedent.
• draft/typing is a near-trivial follow-on from TAGMSG (TICKET-076 ✅): just whitelist the +draft/typing=… client tag and broadcast.

3.3 Already-shipped caps blocked on adapter wiring

Worth calling out explicitly so they are not re-implemented by mistake:

4. Missing ISUPPORT tokens

packages/irc-core/src/commands/isupport.ts should grow:

• MONITOR=<n> — maximum entries per connection (TICKET for monitor).
• ACCOUNTEXTBAN / EXTBAN=~,acc — extended ban by account (services +r work).
• STATUSMSG=@+ — prefixes that map to status-msg delivery (ships with any STATUSMSG-aware PRIVMSG change).
• TYPING — draft advertisement when draft/typing lands.

5. Channel + user modes that arrive with services

The v1 mode set (o v b i k l t n m s p channel, i o w s user) gains:

S is a near-freebie — the transport already knows whether TLS is in use (ConnectionActor accepts a transportMeta); surfacing it as a user mode costs one reducer branch.

6. IRC services

6.1 Architecture decision: integrated services (not pseudo-servers)

Two designs exist in the wild:

A. Pseudo-client services (Atheme / Anope model). A separate process connects as one or more virtual IRC clients named NickServ etc.; users interact via PRIVMSG NickServ :REGISTER hunter2 email. The link between ircd and services speaks a server-to-server protocol (TS6 / P10 / IRCv3 S2S).

B. Integrated services. Service names are reserved nicks recognized by the daemon at PRIVMSG time and routed to dedicated reducers backed by a ServicesStore port. No S2S, no separate process, no pseudo-client connection.

Decision: B — integrated services. Rationale:

• S2S is an explicit non-goal (PLAN.md §1). Model A requires it.
• The pure-reducer + location-of-authority architecture already has the right seam: a new ServicesStore port (packages/irc-core/src/ports.ts, mirroring AccountStore / MessageStore) absorbs the side effects, and reducers stay pure.
• One storage layer is shared with the existing SASL AccountStore (TICKET-071 ✅) — a NickServ registration is a SASL account, so the services work composes with auth rather than duplicating it.
• The serverless substrates (Durable Objects, DynamoDB) handle persistence natively; spinning up a separate long-running services process would defeat the deployment model.

Trade-off documented: integrated services are not binary-compatible with existing Atheme/Anope modules. Operators migrating from a services-aware network should expect to re-register nicks and channels. This is called out in docs/ when the work ships.

6.2 The ServicesStore port

/** Persists services-owned state. Mirrors the AccountStore/MessageStore pattern. */
export interface ServicesStore {
  // NickServ
  registerNick(account: string, passwordHash: string, email?: string): Promise<void>;
  verifyNick(account: string, password: string): Promise<boolean>;
  dropNick(account: string): Promise<void>;
  isRegisteredNick(account: string): Promise<boolean>;
  setNickEnforce(account: string, mode: 'none' | 'kill' | 'ghost'): Promise<void>;

  // ChanServ
  registerChannel(chan: string, founder: string): Promise<void>;
  dropChannel(chan: string): Promise<void>;
  getChannelFounder(chan: string): Promise<string | null>;
  setChannelAccess(chan: string, account: string, level: AccessLevel): Promise<void>;

  // HostServ
  setVhost(account: string, vhost: string): Promise<void>;
  getVhost(account: string): Promise<string | null>;

  // MemoServ
  recordMemo(to: string, from: string, body: string): Promise<void>;
  listMemos(account: string): Promise<Memo[]>;
  markMemoRead(account: string, id: string): Promise<void>;
}

Adapter implementations:

6.3 Services scope

6.4 Nick enforcement policy

NickServ SET ENFORCE <mode> decides what happens when an unidentified client uses a registered nick:

• none (default): warning notice only.
• ghost: kick the existing unidentified client off after a grace period (default 30s); connection is force-disconnected via the existing disconnect(conn, reason) runtime method.
• kill: same as ghost but immediately.

Implemented as a new EnforceNick effect emitted from the registration reducer when the chosen nick matches a registered account the connection is not identified as. The dispatch layer resolves it against runtime.disconnect(...).

6.5 Services ↔ daemon hooks

Already-present seams the services reuse:

• AccountStore.verify('PLAIN', ...) (TICKET-026 ✅) → a successful NickServ IDENTIFY, a SASL PLAIN login, and a PASS-based account login (TICKET-152 ✅) all reduce to "this connection is now account X". The shared applyAccountSuccess(state, ctx, account) helper stamps the account, sets the +r user mode, restores per-account state (read markers, persisted away, queued memos), and emits 900 RPL_LOGGEDIN + 903 RPL_SASLSUCCESS plus the ACCOUNT broadcast to account-notify-capable peers.
• PASS-based account auth (TICKET-152 ✅) — a third account-login entry point alongside SASL and NickServ IDENTIFY. A client that sends NICK <nick> then PASS <nick>:<password> (then USER) is identified to ctx.accounts at registration completion without speaking SASL. The <nick>:<password> literal matches the SASL_ACCOUNTS seed format. The payload nick (left of the first :) is the account name and MUST equal state.nick at registration completion. Order of precedence at registration is: (1) already identified (SASL/PASS-auth) → gate satisfied; (2) <nick>:<password> verifies against ctx.accounts → account set; (3) bare PASS matches serverPassword → gate satisfied; (4) else 464 ERR_PASSWDMISMATCH + disconnect. A bare PASS <value> (no colon) is always a server-password candidate, never an account credential; when ctx.accounts is unbound the <nick>:<password> form is ignored and behaviour collapses to the server-password gate. Like SASL, PASS-auth runs through applyAccountSuccess and therefore stamps +r; a failed verify reveals nothing — unknown nick and wrong password are indistinguishable (a fixed dummy verify equalises the failure path).
• MessageStore (TICKET-063 ✅) → MemoServ's SEND is a record into a per-account memo queue; delivery is a fanout at identify time.
• clock / IdFactory ports → memo ids, enforcement grace timers.

7. Proposed tickets

Ticket numbers are placeholders starting at TICKET-110 (next free id per todo.md). Final ids assigned at ratification. Each ticket follows strict TDD (Red → Green → Refactor) per CLAUDE.md / AGENTS.md.

Phase 12 — IRCv3 extensions

TICKET-110 — IRCv3 account-notify (push ACCOUNT on login/logout)

• Phase: 12
• Points: 2
• Dependencies: TICKET-071 (AccountStore wiring, ✅)
• Description: Advertise account-notify; emit ACCOUNT <name|*> to peers in shared channels (excluding sender unless echo-message) on SASL success, NickServ IDENTIFY (services), and LOGOUT. Reuses the extended-join/chghost broadcast helper.
• Acceptance Criteria:
  • CAP LS includes account-notify.
  • A login by peer A visible to peer B (sharing a channel, cap negotiated) produces :A ACCOUNT alice.
  • A logout produces :A ACCOUNT *.
  • No ACCOUNT messages to clients without the cap.
  • 100% coverage on the new broadcast branch.
• TDD Outline: Red on "B sees ACCOUNT after A's SASL success"; green via the broadcast helper; then cap-gating + echo-message path.

TICKET-111 — IRCv3 msgid (emit msgid tag on every message)

• Phase: 12
• Points: 2
• Dependencies: TICKET-063 (chathistory msgid plumbing, ✅)
• Description: Advertise msgid as a standalone cap. Every PRIVMSG/NOTICE/TAGMSG emitted to cap-enabled clients carries a +msgid=<id> tag from IdFactory.nonce(). The chathistory reducer already records the msgid; this ticket surfaces it on the live fanout line, not just on replay.
• Acceptance Criteria:
  • CAP LS includes msgid.
  • Live PRIVMSG to a cap-enabled peer carries @+msgid=<id>.
  • The msgid on the live line and on the chathistory replay line match for the same recorded message.
  • Clients without the cap see no msgid tag (existing behavior).
  • 100% coverage on the tag-emission branch.
• TDD Outline: Red on "peer with msgid cap sees @+msgid=… on a PRIVMSG"; green; then assert parity with the recorded msgid.

TICKET-112 — IRCv3 standard-replies (FAIL/WARN/NOTE)

• Phase: 12
• Points: 3
• Dependencies: —
• Description: Advertise standard-replies. For cap-enabled clients, replace a curated subset of bare numeric error replies (461 ERR_NEEDMOREPARAMS, 403 ERR_NOSUCHCHANNEL, 432/433 registration errors, SASL failures) with the structured FAIL COMMAND code context :description form. The code-path branches that should not change (numeric-only replies like MOTD lines, NAMES) are left on the numeric form.
• Acceptance Criteria:
  • CAP LS includes standard-replies.
  • For each curated numeric, a cap-enabled client receives a FAIL/WARN/NOTE line; a legacy client receives the unchanged numeric.
  • The mapping is data-driven (a numericToStandardReply table), not scattered if (hasCap) checks.
  • 100% coverage on the table + dispatch helper.
• TDD Outline: Red on 461→FAIL for cap-enabled client; green via the table; then each curated code; then the legacy fallback.

TICKET-113 — IRCv3 MONITOR (modern ISON replacement)

• Phase: 12
• Points: 5
• Dependencies: —
• Description: Advertise MONITOR=<n> (configurable max, default 30). Implement the MONITOR + nick{,nick} / - / C / L / S subcommands and the 730 RPL_MONONLINE / 731 RPL_MONOFFLINE / 732 RPL_MONLIST / 734 ERR_MONLISTFULL numerics. Online/offline transitions push 730/731 asynchronously via the Registry's nick reserve/release hooks.
• Acceptance Criteria:
  • 005 advertises MONITOR=30.
  • MONITOR +alice while alice is offline → 731.
  • Alice connects → 730 pushed to the watcher.
  • MONITOR L lists the watchlist; MONITOR C clears it.
  • Over-limit → 734 with the rejected nick.
  • 100% coverage on the reducer and the async push hook.
• TDD Outline: Red on the offline→731 path; green; then the online push; then list/clear/over-limit.

TICKET-114 — IRCv3 labeled-response (correlate request→reply via BATCH)

• Phase: 12
• Points: 8
• Dependencies: TICKET-025 (batch, ✅)
• Description: Advertise labeled-response. A client sends a message with +label=<id>; the server wraps every reply caused by that message in a BATCH +id labeled-response … BATCH -id. If the request produces no reply, the server emits an empty batch. The label is plumbed through ctx so every reducer's emitted effects inherit it.
• Acceptance Criteria:
  • CAP LS includes labeled-response.
  • A PRIVMSG carrying +label=foo produces a BATCH +foo labeled-response (echo + any numerics) BATCH -foo for cap-enabled clients.
  • A command that produces no reply (e.g. a no-op PING already covered by PONG is not empty; a JOIN to a nonexistent channel that 403s still wraps the 403) — spec edge cases enumerated.
  • 100% coverage on the label plumbing + wrapping helper.
• TDD Outline: Red on "PRIVMSG with +label=foo wraps echo in BATCH"; green; then the no-reply case; then the multi-reply case.

TICKET-115 — IRCv3 sts (Strict Transport Security policy)

• Phase: 12
• Points: 2
• Dependencies: dual transport (Phase 7 ✅)
• Description: Advertise sts with a deployment-configurable policy (duration, port for the TLS listener, optional preload). On a plaintext/WebSocket connection (when one exists), the server emits the STS policy so compliant clients upgrade; on the TLS connection the policy is still sent to lock in the duration.
• Acceptance Criteria:
  • CAP LS includes sts=duration=…,port=6697.
  • Values come from ServerConfig, not literals.
  • A wss / irc+tls connection advertises the duration.
  • 100% coverage on the policy builder.
• TDD Outline: Red on cap advertisement; green; then override via config.

TICKET-116 — IRCv3 draft/typing (typing indicator broadcast)

• Phase: 12
• Points: 2
• Dependencies: TICKET-076 (TAGMSG, ✅)
• Description: Advertise draft/typing. A client sends TAGMSG <target> +draft/typing=active|paused|done; the server broadcasts to channel members (or routes to a user target), excluding the sender unless echo-message is negotiated. No state is kept server-side.
• Acceptance Criteria:
  • CAP LS includes draft/typing.
  • Channel typing TAGMSG fans out to cap-enabled members.
  • The +draft/typing=* client tag is whitelisted for clients without message-tags (per the spec's client-tag exception).
  • 100% coverage on the whitelist + broadcast.
• TDD Outline: Red on channel typing fanout; green; then echo-message path; then user-target path.

TICKET-117 — IRCv3 draft/multiline (multi-line BATCH)

• Phase: 12
• Points: 5
• Dependencies: TICKET-025 (batch, ✅)
• Description: Advertise draft/multiline with a configurable byte budget (default 4096). A cap-enabled client sends BATCH +id draft/multiline :target followed by N PRIVMSG/NOTICE lines, then BATCH -id. The server concatenates per spec (with \n), enforces the byte cap, and broadcasts as a single PRIVMSG carrying a +draft/multiline tag plus the joined body (or a batched replay to other multiline-capable peers — spec calls for the joined form to legacy peers and the batch form to cap peers).
• Acceptance Criteria:
  • CAP LS includes draft/multiline=35615 (or configured max).
  • Multi-line batch from a cap-enabled client is delivered to cap-enabled peers as a draft/multiline BATCH.
  • Legacy peers receive the joined single PRIVMSG.
  • Over-budget batch is rejected with FAIL.
  • 100% coverage on the reducer + byte-budget enforcement.
• TDD Outline: Red on a 2-line batch delivered as joined PRIVMSG to a legacy peer; green; then the cap-peer batched delivery; then budget enforcement.

TICKET-118 — IRCv3 draft/read-marker (persistent last-read)

• Phase: 12

• Points: 5

• Dependencies: TICKET-063 (chathistory, ✅), services UserStore (TICKET-122)

• Description: Advertise draft/read-marker. The chathistory work already keeps a per-(connection, channel) last-read marker in ConnectionState. This ticket persists the marker per (account, channel) in ServicesStore, propagates updates via +draft/read-marker=<msgid> tags on relevant messages, and seeds a fresh connection's marker from the persisted value at identify time.

• Acceptance Criteria:

  • CAP LS includes draft/read-marker.
  • Marking a message read updates the persisted marker.
  • Reconnect restores the marker.
  • CHATHISTORY BEFORE honours the marker in the absence of an explicit pivot.
  • 100% coverage on the persistence + tag emission.

• TDD Outline: Red on reconnect-restore; green via the store; then tag emission; then CHATHISTORY integration.

• Implementation notes (shipped): Landed as a focused ReadMarkerStore port (get / set / forAccount) plus an InMemoryReadMarkerStore reference impl in irc-core/ports.ts, rather than waiting on the full services UserStore (TICKET-122). The mark is delivered as a TAGMSG carrying +draft/read-marker=<msgid> (msgid-based, composing with the chathistory marker plumbing, diverging from the work-in-progress ircv3 draft's timestamped MARKREAD verb). A mark TAGMSG is persisted via persistReadMarker, fanned out to message-tags OR draft/read-marker peers (mirroring the draft/typing precedent), and +draft/read-marker is whitelisted in filterClientTags so draft-only peers keep the tag. SASL identify seeds lastReadMarkers via seedReadMarkers; CHATHISTORY BEFORE with no pivot falls back to the connection's marker. TICKET-122 should fold this store into the unified services UserStore when it lands.

• Divergence vs. spec compliance (TICKET-150 follow-up, shipped): TICKET-118 shipped channel-wide mark TAGMSG fanout for pragmatic parity with the draft/typing precedent — every message-tags OR draft/read-marker peer in the channel received the mark. The ircv3 draft/read-marker spec, however, mandates that a read marker MUST NOT be disclosed to other users: a client's own mark is private to its account. The Phase 14 follow-up (account-scoped draft/read-marker fanout) restored spec compliance with two behaviour changes:

  1. Identified originator → account-scoped fanout. The tagmsgChannelReducer now annotates the mark TAGMSG Broadcast effect with the originator's account. The dispatch layer's cap-aware broadcast() restricts the recipient set to channel members authenticated as that same account (RFC 1459 case-folded comparison), still honouring except (originator skip) and the OR-semantics caps filter (message-tags OR draft/read-marker). Other accounts in the channel never receive the mark; the originator's other live sessions on the same account (multi-device sync, when they share the channel) receive it. filterClientTags and its +draft/read-marker whitelist are unchanged — only the recipient set changes.
  2. Unidentified originator → no fanout (session-local). An unidentified connection (no account) emits no Broadcast for a read- marker mark. Its mark stays session-local (the in-memory lastReadMarkers still advances; persistence is a no-op without an account, unchanged from TICKET-118). The originator's own client still observes its mark via the echo-message self-echo. This matches the spec's privacy default: a read marker never reaches other users, and an unidentified connection has no account to share a mark with.

  Recipient-resolution primitive ("or equivalent" index). The ticket's description floated an AccountConnections index on the runtime. The shipped implementation takes the spec-permitted "(or equivalent)" path: there is no separate index structure. The recipient set is resolved at dispatch time by walking the channel roster and consulting each member's live ConnectionState.account via the existing getConnectionInfo port method (the same per-recipient resolution already used for cap gating). This is always fresh by construction — disconnected connections leave the roster, and account changes are live references — so the staleness concerns an explicit index would need (re-sync on ACCOUNT/SASL/ disconnect) do not apply. Global cross-channel account fanout (reaching an account's sessions that are not in the marked channel) is a documented follow-up, not needed for spec privacy: the mark is channel-specific, and the persistence layer (ServicesStore.setLastReadMarker) already syncs a session's marker on reconnect/rejoin via seedReadMarkers. 100% coverage on the account-scoped fanout + dispatch filter (irc-core and irc-server both enforce a 100% gate).

TICKET-119 — IRCv3 draft/pre-away (persist away status)

• Phase: 12
• Points: 3
• Dependencies: TICKET-061 (AWAY, ✅), services UserStore (TICKET-122)
• Description: Advertise draft/pre-away. Persist away reason in ServicesStore keyed by account. On identify (or SASL login), the server re-applies the away state and emits the AWAY line + 306 RPL_NOWAWAY as if the user had sent AWAY :reason themselves. Noted out-of-scope in TICKET-063.
• Acceptance Criteria:
  • CAP LS includes draft/pre-away.
  • An identified user who previously went AWAY :brb and reconnects is auto-marked away.
  • AWAY (unset) clears the persisted reason.
  • 100% coverage on the persistence + replay.
• TDD Outline: Red on reconnect auto-away; green; then the unset path.
• Implementation notes (shipped): Landed as a focused AwayStore port (get / set / clear) plus an InMemoryAwayStore reference impl in irc-core/ports.ts, rather than waiting on the full services UserStore (TICKET-122) — same shape as the TICKET-118 ReadMarkerStore precedent. The awayReducer calls persistAway on set and clearPersistedAway on unset (gated on a bound store AND an identified connection, so unidentified sessions still track their own in-memory away for the duration of the connection). SASL identify calls replayPersistedAway to copy a stored reason onto the fresh connection's ConnectionState.away and emits a single 306 RPL_NOWAWAY so the user sees they are still away. The companion away-notify broadcast is intentionally NOT emitted at identify time — the connection has not joined any channels yet, so it would have no audience; peers learn the away state through the normal WHO / WHOIS / AWAY queries once the user joins. TICKET-122 should fold this store into the unified services UserStore when it lands.

TICKET-120 — ISUPPORT tokens for new caps + modes

• Phase: 12
• Points: 2
• Dependencies: the cap tickets above + services modes (TICKET-122)
• Description: Add MONITOR=<n>, STATUSMSG=@+, EXTBAN=~,q, ACCOUNTEXTBAN=a, draft tokens for draft/typing/draft/multiline to generateIsupport. Tokens are config-derived where applicable (max monitor count, extban prefix).
• Acceptance Criteria:
  • Each token advertises the configured value.
  • Tokens only appear when the relevant cap/mode is supported (e.g. ACCOUNTEXTBAN only once services ship).
  • 100% coverage on the new branches.
• TDD Outline: Red on each missing token; green by adding it.

TICKET-121 — User mode S (TLS connected)

• Phase: 12
• Points: 1
• Dependencies: dual transport (Phase 7 ✅)
• Description: When the connection is over TLS (wss or irc+tls), set user mode S read-only on the connection at registration. The mode is not settable via MODE (parse rejects +S with 501). Surface in WHOIS (:server 276 nick target :is using a secure connection) for clients that advertise the RPL_WHOISSECURE cap.
• Acceptance Criteria:
  • TLS connection → +S user mode visible in WHO/WHOIS.
  • MODE nick +S rejected with 501 ERR_UMODEUNKNOWNFLAG.
  • 100% coverage on the mode-set + parse rejection.
• TDD Outline: Red on TLS registration setting +S; green; then the parse rejection.

Phase 13 — IRC services

TICKET-122 — ServicesStore port + in-memory reference impl

• Phase: 13
• Points: 5
• Dependencies: TICKET-029 (IrcRuntime port, ✅), TICKET-071 (AccountStore, ✅)
• Description: Define ServicesStore (§6.2) in packages/irc-core/src/ports.ts. Ship InMemoryServicesStore (in-memory-runtime) covering NickServ/ChanServ/HostServ/MemoServ primitives. Adapter backends (D1, DynamoDB) ship in dedicated follow-on tickets.
• Acceptance Criteria:
  • Port interface compiles under strict mode.
  • InMemoryServicesStore implements every method; 100% coverage.
  • Reused by local-cli and unit tests.
• TDD Outline: Red on registerNick/verifyNick round-trip; green; then each method.

TICKET-123 — NickServ: REGISTER / IDENTIFY / DROP / INFO + +r

• Phase: 13
• Points: 8
• Dependencies: TICKET-122
• Description: Wire PRIVMSG NickServ :<command> to a NickServ reducer. REGISTER password email creates a SASL account (reuses the existing AccountStore so SASL PLAIN works immediately after registration). IDENTIFY password logs the current connection in (sets +r user mode, emits ACCOUNT to account-notify peers). DROP removes the registration. INFO [nick] queries it. Successful IDENTIFY triggers MemoServ delivery of queued memos.
• Acceptance Criteria:
  • REGISTER hunter2 alice@example.com followed by SASL PLAIN with alice:hunter2 succeeds.
  • IDENTIFY hunter2 from an unidentified connection sets +r and emits ACCOUNT.
  • DROP alice requires re-identify.
  • 100% coverage on the reducer + state transitions.
• TDD Outline: Red on REGISTER→SASL round-trip; green; then IDENTIFY; then DROP; then INFO.

TICKET-124 — NickServ: nick enforcement (SET ENFORCE)

• Phase: 13
• Points: 5
• Dependencies: TICKET-123
• Description: Implement NickServ SET ENFORCE none|ghost|kill plus the EnforceNick effect. When a client registers (NICK) with a nick that is registered to an account they are not identified as, the policy fires after the configured grace period. ghost force- disconnects; kill force-disconnects immediately. Default policy per registered account is none.
• Acceptance Criteria:
  • SET ENFORCE ghost + unidentified use of the nick → grace period → disconnect("Nick enforced by NickServ").
  • SET ENFORCE kill → immediate disconnect.
  • SET ENFORCE none → warning notice only.
  • 100% coverage on the effect + dispatch integration.
• TDD Outline: Red on grace-period disconnect; green; then each policy.

TICKET-125 — ChanServ: REGISTER / DROP / SET + +r/+R/+M

• Phase: 13

• Points: 8

• Dependencies: TICKET-123, TICKET-011 (MODE, ✅)

• Description: Wire PRIVMSG ChanServ :<command>. REGISTER records the channel founder; sets channel mode +r. SET FOUNDER/MLOCK/RESTRICTED/KEEPTOPIC updates the persisted channel record. New channel modes: +r (registered, settable only by ChanServ), +R (block join/message from unidentified), +M (mod speak requires identification). KEEPTOPIC persists the topic and restores it on the first join after the channel becomes empty.

• Acceptance Criteria:

  • REGISTER #chan by an identified founder sets +r.
  • +R blocks join from unidentified (519 ERR_ALLMUSTREGISTER, server-specific numeric) and PRIVMSG (404).
  • KEEPTOPIC round-trips a topic across empty-recreate.
  • MLOCK reapplies the locked modes if an op tries to unset them.
  • 100% coverage on the reducer + mode interactions.

• TDD Outline: Red on REGISTER→+r; green; then +R/+M; then KEEPTOPIC; then MLOCK.

  Implementation notes (post-land):

  • Three new boolean channel modes added to ChannelModes: registered (+r), blockUnidentified (+R), moderatedIdent (+M). They appear in the 324 RPL_CHANNELMODEIS reply when set, but channelModeReducer rejects +r/+R/+M via MODE with 472 ERR_UNKNOWNMODE — only ChanServ may toggle them via ApplyChannelDelta effects.
  • 519 ERR_ALLMUSTREGISTER added to Numerics for the +R JOIN gate.
  • ServicesStore extended: getChannel, setChannelFounder, setChannelMlock/getChannelMlock, setChannelRestricted, setChannelKeepTopic, setChannelTopic/getChannelTopic. The RegisteredChannel record now carries mlock / restricted / keepTopic / topic?. The in-memory store returns defensive copies (callers cannot mutate the store by editing returned records).
  • chanservReducer (new, commands/chanserv.ts) handles PRIVMSG ChanServ :<command>. Subcommands: REGISTER, DROP, INFO, SET FOUNDER/MLOCK/RESTRICTED/KEEPTOPIC. Channel mutations are emitted as ApplyChannelDelta effects so the actor applies them to the authoritative ChannelState.
  • SET RESTRICTED ON|OFF toggles the +R channel mode (and stores the preference). SET KEEPTOPIC ON|OFF toggles topic persistence and drops any previously-stored snapshot when turned off.
  • JOIN reducer consults services on the first join after empty-recreate to restore a KEEPTOPIC snapshot (emits 332/333 to the joiner). +R JOIN gate rejects unidentified clients with 519.
  • TOPIC reducer persists the snapshot on every change (set or clear) when KEEPTOPIC is on.
  • PRIVMSG/NOTICE channel reducers enforce +M (op/voice/identified pass) and +R (identified pass) with 404; NOTICE is silent.
  • channelModeReducer reapplies MLOCK after every applied MODE: any positively-locked boolean mode that ended up unset (whether by this MODE or by prior state) is re-asserted via a ChanServ-emitted ApplyChannelDelta + Broadcast (:ChanServ!ChanServ@services MODE #chan +…). Defence in depth — services-only modes (+r) are also defended, so the registered mark survives even if a future code path applies an ApplyChannelDelta clearing it.
  • Actor routes PRIVMSG ChanServ (case-insensitive) to reducers.chanserv; NOTICE and unbound-services cases fall through to the normal user-target reducer (RFC: NOTICE is silent).
  • 100% coverage on chanserv.ts, mode.ts (reapply branch), and the new join/privmsg/topic branches.

TICKET-126 — ChanServ: ACCESS / LEVELS (SOP/AOP/VOP/HOP)

• Phase: 13
• Points: 5
• Dependencies: TICKET-125
• Description: ChanServ ACCESS #chan ADD nick level and the shorthand SOP/AOP/VOP/HOP variants map an account to a privilege level. On JOIN, ChanServ applies the matching channel prefix (@, +) automatically. LEVELS lets the founder redefine what numeric level each command requires.
• Acceptance Criteria:
  • AOP alice ADD → alice auto-opped on JOIN.
  • VOP bob ADD → bob auto-voiced.
  • ACCESS #chan DEL alice removes.
  • LEVELS SET AUTOOP 5 redefines the threshold.
  • 100% coverage on the access reducer + JOIN hook.
• TDD Outline: Red on AOP→auto-op; green; then DEL; then LEVELS.

TICKET-127 — HostServ: ON / OFF / REQUEST / SET (oper)

• Phase: 13
• Points: 3
• Dependencies: TICKET-122, cloaking (Phase 5 ✅)
• Description: Wire PRIVMSG HostServ :<command>. REQUEST vhost queues a request for oper approval (or auto-approves if configured). SET account vhost (oper-only) sets it directly. ON/OFF toggles the cloak at runtime; the cloak machinery already exists, this ticket wires it to per-account state and emits CHGHOST (TICKET-022 ✅) on toggle.
• Acceptance Criteria:
  • SET alice example.net + ON → CHGHOST emitted to peers; WHOIS shows the vhost.
  • OFF restores the real (cloaked) host.
  • 100% coverage on the reducer + CHGHOST emission.
• TDD Outline: Red on ON→CHGHOST; green; then OFF; then REQUEST/SET approval path.

TICKET-128 — OperServ: AKILL / JUPE / RAW

• Phase: 13
• Points: 5
• Dependencies: TICKET-075 (OPER, ✅), TICKET-122
• Description: Wire PRIVMSG OperServ :<command> (oper-only; rejected with a services notice otherwise). AKILL ADD mask reason records a network-wide ban persisted in ServicesStore; the $connect/$default admission path checks it on every new connection and on every PRIVMSG, force-disconnecting on match. JUPE nick blocks a nick/server name locally (NICK collision reducer returns 432 for the jupe'd nick). RAW <line> is oper- only and emits a raw IRC line (useful for recovery; logged).
• Acceptance Criteria:
  • AKILL ADD *!*@bad.example.net flooding → next matching connection is disconnected at $connect.
  • JUPE moo → NICK moo returns 432 ERR_ERRONEUSNICKNAME.
  • Non-oper → service notice rejection, no state change.
  • 100% coverage on each reducer + the admission hook.
• TDD Outline: Red on AKILL disconnect; green; then JUPE; then RAW; then non-oper rejection.

TICKET-129 — MemoServ: SEND / LIST / READ / DEL + queue delivery

• Phase: 13
• Points: 5
• Dependencies: TICKET-123, TICKET-122 (MessageStore pattern, ✅)
• Description: Wire PRIVMSG MemoServ :<command>. SEND nick body records a memo against the recipient's account. On successful NickServ IDENTIFY or SASL login, queued memos are delivered (via the existing MemoServ pseudo-client notice format). LIST/READ/ DEL/FORWARD round out the surface.
• Acceptance Criteria:
  • SEND alice Hi while alice is offline → alice receives the memo on next IDENTIFY.
  • LIST enumerates unread.
  • READ n delivers memo #n; DEL n removes.
  • 100% coverage on the reducer + delivery hook.
• TDD Outline: Red on offline-send→identify-delivery; green; then list/read/del.

TICKET-130 — Adapter backends for ServicesStore

• Phase: 13
• Points: 8
• Dependencies: TICKET-122, all of TICKET-123..129 (reducers landed against the in-memory store first)
• Description: Ship persistent ServicesStore implementations:
  • CF: D1 (share the database from TICKET-093 ✅), new tables nickserv_accounts, chanserv_channels, chanserv_access, hostserv_vhosts, memoserv_memos.
  • AWS: DynamoDB, extending the existing Accounts table (TICKET-072 ✅) and adding Channels, ChannelAccess, Vhosts, Memos.
  • Both adapters wire the store into ConnectionActorOptions.services.
• Acceptance Criteria:
  • Each adapter: end-to-end NickServ register→identify→SASL PLAIN.
  • Channel registration survives a deploy (state persisted).
  • Memos delivered on reconnect after identify.
  • 100% coverage on the new store implementations.
• TDD Outline: Red per adapter on REGISTER→survive-restart; green via the persistent store.

TICKET-131 — Docs: services reference + admin tooling

• Phase: 13
• Points: 2
• Dependencies: TICKET-130
• Description: docs/Services.md covering: integrated-services architecture decision (§6.1), per-service command reference, admin tooling (tools/seed-nickserv-accounts.ts mirroring the existing seed-{aws,cf}-accounts.ts scripts), migration notes for operators coming from Atheme/Anope.
• Acceptance Criteria:
  • A new contributor can register a NickServ account and a ChanServ channel end-to-end following only the doc.
  • The migration caveat (no Atheme/Anope compatibility) is called out up front.
• TDD Outline: N/A (documentation). Reviewed by walking the steps from a clean checkout.

8. Sequencing

Recommended landing order, respecting dependencies:

1. Cheap IRCv3 wins first. TICKET-110 (account-notify), TICKET-111 (msgid), TICKET-115 (sts), TICKET-121 (+S mode), TICKET-116 (draft/typing). All small, all compose with shipped work, all unblock better client UX.
2. MONITOR + standard-replies. TICKET-113, TICKET-112.
3. labeled-response. TICKET-114 — largest IRCv3 item, do last among the stable caps; touches every reducer that emits a reply.
4. Services foundation. TICKET-122 (port + in-memory store).
5. NickServ core. TICKET-123, TICKET-124 — needed before ChanServ because every other service keys off the identified account.
6. ChanServ. TICKET-125, TICKET-126.
7. HostServ / OperServ / MemoServ. TICKET-127, TICKET-128, TICKET-129 (parallelizable).
8. Persistent adapter backends. TICKET-130 (unblocks any production use of services).
9. Draft caps that depend on services. TICKET-118 (draft/read- marker), TICKET-119 (draft/pre-away).
10. draft/multiline. TICKET-117 — independent, can land anywhere after the IRCv3 cheap wins.
11. Docs + ISUPPORT catch-up. TICKET-131, TICKET-120.

9. Risks

10. Definition of done (per phase)

Phase 12 — IRCv3 extensions is done when:

• Every stable IRCv3 cap in §3.1 is advertised and exercised by the parametrized contract suite on the in-memory runtime.
• The draft caps in §3.2 are advertised under draft/ namespace and exercised; they can be flipped off via config without code changes.
• 005 RPL_ISUPPORT advertises every new token.
• Client compat sweep (TICKET-050 ⬜) passes against ≥3 clients with the new caps negotiated.

Phase 13 — IRC services is done when:

• NickServ/ChanServ/HostServ/OperServ/MemoServ reducers ship at 100% coverage against InMemoryServicesStore.
• Both adapters ship persistent ServicesStore backends; the parametrized contract suite is green on both.
• End-to-end: register → identify → SASL PLAIN → ChanServ REGISTER → KEEPTOPIC round-trip survives a deploy restart.
• docs/Services.md is complete and reviewer-validated.

11. Open questions

• Account name vs. nick. Should NickServ register an account (multiple nicks group to it, Atheme-style) or register a single nick? Default proposal: account-per-registration with nick grouping as a follow-up, matching SASL's existing account model.
• Memo size + retention. Default cap (256 bytes? 2 KiB?) and TTL (30 days?). Default proposal: 2 KiB per memo, 30-day TTL, both config-tunable.
• +R/+M numerics. Server-specific 519 ERR_ALLMUSTREGISTER vs. reusing 473 ERR_INVITEONLYCHAN semantics. Default proposal: introduce the spec-recognized numerics where they exist, document server-specific ones in isupport.
• AKILL scope. Network-wide (persisted) vs. per-listener (edge only). Default proposal: persisted at the ServicesStore, enforced in the admission path of every adapter — true network-wide on a single-server deployment.