sneak/neoirc
1
0
Fork 0
Code Issues 4 Pull Requests 3 Actions 8 Packages Projects Releases Wiki Activity
Files
1233f44c8be1521a9864a8b426a94025f0ff5a02
neoirc/README.md
T
clawbot bb7bcb31ea
check / check (push) Waiting to run
Details
Re-vendor the canonical files from sneak/prompts at dd4027b (closes #112) 
The shared files are fetched from sneak/prompts dd4027b, with this
repository's own entries after the shared content in .gitignore,
.editorconfig and .dockerignore.

Lint and tests are Dockerfile phases (golangci-lint v2.14.0, Debian Go
1.24.13) that the build stage depends on, and the Makefile targets call
the script/ entrypoints. make fmt also formats Markdown with prettier.

Fixes for the new lint findings: the auth cookie is always Secure, an
IRC connection's relay goroutine stops when the connection closes, and
repeated strings are constants. neoirc-cli treats a plain-HTTP server on
localhost or a loopback address as secure, so local use keeps its session.

Whether the 60-second test cap covers building the test phase is open
on sneak/prompts issue 113.

Model: opus-5-5
2026-10-06 21:01:46 +02:00

3141 lines
136 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# neoirc
**IRC semantics, structured message metadata, cryptographic signing, and
server-held session state with per-client delivery queues. All over HTTP+JSON.**
An IRC-inspired server written in Go that decouples session state from transport
connections, enabling mobile-friendly persistent sessions over plain HTTP.
The **HTTP API is the primary interface**. It's designed to be simple enough
that writing a terminal IRC-style client against it is straightforward — just
`curl` and `jq` get you surprisingly far. The server also ships an embedded web
client as a convenience/reference implementation, but the API comes first.
---
## Table of Contents
- [Motivation](#motivation)
- [Why Not IRC / XMPP / Matrix?](#why-not-just-use-irc--xmpp--matrix)
- [Design Decisions](#design-decisions)
- [Architecture](#architecture)
- [Protocol Specification](#protocol-specification)
- [API Reference](#api-reference)
- [Message Flow](#message-flow)
- [Canonicalization & Signing](#canonicalization-and-signing)
- [Security Model](#security-model)
- [Federation](#federation-server-to-server)
- [Storage](#storage)
- [Configuration](#configuration)
- [IRC Protocol Listener](#irc-protocol-listener)
- [Entrypoints](#entrypoints)
- [Deployment](#deployment)
- [Client Development Guide](#client-development-guide)
- [Rate Limiting & Abuse Prevention](#rate-limiting--abuse-prevention)
- [Roadmap](#roadmap)
- [Project Structure](#project-structure)
- [Design Principles](#design-principles)
- [Status](#status)
- [License](#license)
---
## Motivation
IRC is in decline because session state is tied to the TCP connection. In a
mobile-first world, that's a nonstarter. Not everyone wants to run a bouncer or
pay for IRCCloud.
This project builds a server that:
- Holds session state server-side (message queues, presence, channel membership)
- Exposes a minimal, clean HTTP+JSON API — easy to build clients against
- Supports multiple concurrent clients per user session
- Provides IRC-like semantics: channels, nicks, topics, modes
- Uses structured JSON messages with IRC command names and numeric reply codes
- Enables optional cryptographic message signing with deterministic
canonicalization
The entire client read/write loop is two HTTP endpoints. If a developer can't
build a working IRC-style TUI client against this API in an afternoon, the API
is too complex.
---
## Why Not Just Use IRC / XMPP / Matrix?
This isn't a new protocol that borrows IRC terminology for familiarity. This
**is** IRC — the same command model, the same semantics, the same numeric reply
codes from RFC 1459/2812 — carried over HTTP+JSON instead of raw TCP.
The question isn't "why build something new?" It's "what's the minimum set of
changes to make IRC work on modern devices?" The answer turned out to be four
things:
### 1. HTTP transport instead of persistent TCP
IRC requires a persistent TCP connection. That's fine on a desktop. On a phone,
the OS kills your background socket, you lose your session, you miss messages.
Bouncers exist but add complexity and a second point of failure.
HTTP solves this cleanly: clients poll when they're awake, messages queue when
they're not. Works through firewalls, proxies, CDNs. Every language has an HTTP
client. No custom protocol parsers, no connection state machines.
### 2. Server-held session state
In IRC, the TCP connection _is_ the session. Disconnect and you're gone — your
nick is released, you leave all channels, messages sent while you're offline are
lost forever. This is IRC's fundamental mobile problem.
Here, sessions persist independently of connections. Your nick, channel
memberships, and message queue survive disconnects. Multiple devices can share a
session simultaneously, each with its own delivery queue.
### 3. Structured message bodies
IRC messages are single lines of text. That's a protocol constraint from 1988,
not a deliberate design choice. It forces multiline content through ugly
workarounds (multiple PRIVMSG commands, paste flood).
Message bodies here are JSON arrays (one string per line) or objects (for
structured data like key material). This also enables deterministic
canonicalization via RFC 8785 JCS — you can't reliably sign something if the
wire representation is ambiguous.
### 4. Key/value metadata on messages
The `meta` field on every message envelope carries extensible attributes —
cryptographic signatures, content hashes, whatever clients want to attach. IRC
has no equivalent; bolting signatures onto IRC requires out-of-band mechanisms
or stuffing data into CTCP.
### What didn't change
Everything else is IRC. `PRIVMSG`, `JOIN`, `PART`, `NICK`, `TOPIC`, `MODE`,
`KICK`, `353`, `433` — same commands, same semantics. Channels start with `#`.
Joining a nonexistent channel creates it. Channels disappear when empty. Nicks
are unique per server. Identity starts with a key — a nick is a display name.
Accounts are optional: you can create an anonymous session instantly, or set a
password via the PASS command for multi-client access to a single session.
### On the resemblance to JSON-RPC
All C2S commands go through `POST /api/v1/messages` with a `command` field that
dispatches the action. This looks like JSON-RPC, but the resemblance is
incidental. It's IRC's command model — `PRIVMSG #channel :hello` becomes
`{"command": "PRIVMSG", "to": "#channel", "body": ["hello"]}` — encoded as JSON
rather than space-delimited text. The command vocabulary is IRC's, not an
invention.
The message envelope is deliberately identical for C2S and S2C. A `PRIVMSG` is a
`PRIVMSG` regardless of direction. A `JOIN` from a client is the same shape as
the `JOIN` relayed to channel members. This keeps the protocol simple and makes
signing consistent — you sign the same structure you send.
### Why not XMPP or Matrix?
XMPP is XML-based, overengineered for messaging, and the ecosystem is fragmented
across incompatible extensions (XEPs). Matrix is a federated append-only event
graph with a spec that runs to hundreds of pages. Both are fine protocols, but
they're solving different problems at different scales.
This project wants IRC's simplicity with four specific fixes. That's it.
---
## Design Decisions
This section documents every major design decision and its rationale. These are
not arbitrary choices — each one follows from the project's core thesis that
IRC's command model is correct and only the transport and session management
need to change.
### Identity & Sessions — Cookie-Based Authentication
The server uses **HTTP cookies** for all authentication. There is no separate
registration step — sessions start anonymous and can optionally set a password
for multi-client access.
#### Session Creation
- **Session creation**: client sends `POST /api/v1/session` with a desired nick
→ server sets an **HttpOnly auth cookie** (`neoirc_auth`) containing a
cryptographically random value (64 hex characters) and returns the user ID and
nick in the JSON response body. No auth credential appears in the JSON body.
- The auth cookie is HttpOnly, SameSite=Strict, and Secure: clients send it only
over HTTPS, which the TLS-terminating reverse proxy provides, or to a server
on `localhost` (see [Transport Security](#transport-security)). Browsers
handle cookies automatically. **CLI clients (curl, custom HTTP clients) must
explicitly save and send cookies** — e.g., using curl's `-c`/`-b` flags or an
HTTP cookie jar in their language's HTTP library.
- Sessions start anonymous — no password required. When the session expires or
the user QUITs, the nick is released.
#### Setting a Password (Optional, for Multi-Client Access)
For users who want to access the same session from multiple devices:
- **Set password via IRC PASS command**: the authenticated client sends
`POST /api/v1/messages` with `{"command":"PASS","body":["mypassword"]}`. The
server hashes the password with bcrypt and stores it on the session. Password
must be at least 8 characters.
- **Login from another client**: `POST /api/v1/login` with nick and password →
server verifies the password, creates a new client for the existing session,
and sets an auth cookie. Channel memberships and message queues are shared.
Login only works while the session still exists — if all clients have logged
out or the user has sent QUIT, the session is deleted and the password is
lost.
#### Common Properties
- Nicks are changeable via the `NICK` command; the server-assigned user ID is
the stable identity.
- Server-assigned IDs — clients do not choose their own IDs.
- Auth cookies contain opaque random bytes, **not JWTs**. No claims, no expiry
encoded in the cookie value, no client-side decode. The server is the sole
authority on cookie validity.
**Rationale:** IRC has no accounts. You connect, pick a nick, and talk.
Anonymous sessions preserve that simplicity — instant access, zero friction. But
some users want to access the same session from multiple devices without a
bouncer. The PASS command enables multi-client login without adding friction for
casual users: if you don't need multi-client, just create a session and go.
Cookie-based auth simplifies credential management — browsers handle cookies
automatically, and CLI clients just need a cookie jar (e.g., curl's `-c`/`-b`
flags). Note: both anonymous and password-protected sessions are deleted when
the last client disconnects (QUIT or logout). Identity verification at the
message layer via cryptographic signatures (see
[Security Model](#security-model)) remains independent of password status.
### Hostmask (nick!user@host)
Each session has an IRC-style hostmask composed of three parts:
- **nick** — the user's current nick (changes with `NICK` command)
- **username** — an ident-like identifier set at session creation (optional
`username` field in the session request; defaults to the nick)
- **hostname** — automatically resolved via reverse DNS of the connecting
client's IP address at session creation time
- **ip** — the real IP address of the session creator, extracted from
`X-Forwarded-For`, `X-Real-IP`, or `RemoteAddr`
Each **client connection** (created at session creation or login) also stores
its own **ip** and **hostname**, allowing the server to track the network origin
of each individual client independently from the session. Client-level IP and
hostname are **not displayed to regular users**. They are only visible to
**server operators** (o-line) via `RPL_WHOISACTUALLY` (338) when the oper
performs a WHOIS on a user.
The hostmask appears in:
- **WHOIS** (`311 RPL_WHOISUSER`) — `params` contains
`[nick, username, hostname, "*"]`
- **WHOIS (oper-only)** (`338 RPL_WHOISACTUALLY`) — when the querier is a server
operator, includes the target's current client IP and hostname
- **WHO** (`352 RPL_WHOREPLY`) — `params` contains
`[channel, username, hostname, server, nick, flags]`
The hostmask format (`nick!user@host`) is stored for future use in ban matching
(`+b` mode) and other access control features.
### Nick Semantics
- Nicks are **unique per server at any point in time** — two sessions cannot
hold the same nick simultaneously.
- Nicks are **case-sensitive** (unlike traditional IRC). `Alice` and `alice` are
different nicks.
- Nick length: 1–32 characters. No further character restrictions in the current
implementation.
- Nicks are **released when a session is destroyed** (via `QUIT` command or
session expiry). There is no nick registration or reservation system.
- Nick changes are broadcast to all users sharing a channel with the changer, as
a `NICK` event message.
**Rationale:** IRC nick semantics, simplified. Case-insensitive nick comparison
is a perpetual source of IRC bugs (different servers use different case-folding
rules). Case-sensitive comparison is unambiguous.
### Multi-Client Model
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 all S2C messages to every active client queue for that
user session.
- `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
doesn't affect others.
```
User Session
├── Client A (cookie_a, queue_a)
├── Client B (cookie_b, queue_b)
└── Client C (cookie_c, queue_c)
```
**Multi-client via login:** The `POST /api/v1/login` endpoint adds a new client
to an existing session (one that has a password set via PASS command), enabling
true multi-client support (multiple cookies sharing one nick/session with
independent message queues). Sessions without a password cannot be logged into.
**Rationale:** The fundamental IRC mobile problem is that you can't have your
phone and laptop connected simultaneously without a bouncer. Server-side
per-client queues solve this cleanly.
### Message Immutability
Messages are **immutable** — no editing, no deletion by clients. There are no
edit or delete API endpoints and there never will be.
**Rationale:** Cryptographic signing requires immutability. If a message could
be modified after signing, signatures would be meaningless. This is a feature,
not a limitation. Chat platforms that allow editing signed messages have
fundamentally broken their trust model. If you said something wrong, send a
correction — that's what IRC's culture has always been.
### Message Delivery Model
The server uses a **fan-out queue** model:
1. Client sends a command (e.g., `PRIVMSG` to `#general`)
2. Server determines all recipients (all members of `#general`)
3. Server stores the message once in the `messages` table
4. Server creates one entry per recipient in the `client_queues` table
5. Server notifies all waiting long-poll connections for those recipients
6. Each recipient's next `GET /messages` poll returns the queued message
Key properties:
- **At-least-once delivery**: Messages are queued until the client polls for
them. The client advances its cursor (`after` parameter) to acknowledge
receipt. Messages are not deleted from the queue on read — the cursor-based
model means clients can re-read by providing an earlier `after` value.
- **Ordered**: Queue entries have monotonically increasing IDs. Messages are
always delivered in order within a client's queue.
- **No delivery/read receipts** for channel messages. DM receipts are planned.
- **Client output queue depth**: Server-configurable via `QUEUE_MAX_AGE`.
Default is 30 days. Entries older than this are pruned.
### Long-Polling
The server implements HTTP long-polling for real-time message delivery:
1. Client sends `GET /api/v1/messages?after=<last_id>&timeout=15`
2. If messages are immediately available, server responds instantly
3. If no messages are available, server holds the connection open
4. Server responds when either:
- A message arrives for this client (via the in-memory broker)
- The timeout expires (returns empty array)
- The client disconnects (connection closed, no response needed)
**Implementation detail:** The server maintains an in-memory broker with
per-client notification channels. When a message is enqueued for a client, the
broker closes all waiting channels for that client, waking up any blocked
long-poll handlers. This is O(1) notification — no polling loops, no database
scanning.
**Timeout limits:** The server caps the `timeout` parameter at 30 seconds.
Clients should use 15 seconds as the default. The HTTP write timeout is set to
60 seconds to accommodate long-poll connections.
**Rationale:** Long-polling over HTTP is the simplest real-time transport that
works everywhere. WebSockets add connection state, require different proxy
configuration, break in some corporate firewalls, and don't work with standard
HTTP middleware. SSE (Server-Sent Events) is one-directional and poorly
supported by some HTTP client libraries. Long-polling is just regular HTTP
requests that sometimes take longer to respond. Every HTTP client, proxy, load
balancer, and CDN handles it correctly.
### Channels
- **Any user can create channels** — joining a nonexistent channel creates it,
exactly like IRC.
- **Ephemeral** — channels disappear when the last member leaves. There is no
persistent channel registration.
- **No channel size limits** in the current implementation.
- **Channel names** must start with `#`. If a client sends a `JOIN` without the
`#` prefix, the server adds it.
- **No channel-level encryption** — encryption is per-message via the `meta`
field.
### Direct Messages (DMs)
- DMs are addressed by **nick at send time** — the server resolves the nick to a
user ID internally.
- DMs are **fan-out to both sender and recipient** — the sender sees their own
DM echoed back in their message queue, enabling multi-client consistency (your
laptop sees DMs you sent from your phone).
- DM history is stored in the `messages` table with the recipient nick as the
`msg_to` field. This means DM history is queryable per-nick, but if a user
changes their nick, old DMs are associated with the old nick.
- DMs are **not stored long-term** by default — they follow the same rotation
policy as channel messages.
### JSON, Not Binary
All messages are JSON. No CBOR, no protobuf, no MessagePack, no custom binary
framing.
**Rationale:** JSON is human-readable, universally supported, and debuggable
with `curl | jq`. Binary formats save bandwidth at the cost of debuggability and
ecosystem compatibility. Chat messages are small — the overhead of JSON over
binary is measured in bytes per message, not meaningful bandwidth. The
canonicalization story (RFC 8785 JCS) is also well-defined for JSON, which
matters for signing.
### Why Opaque Cookies Instead of JWTs
JWTs encode claims that clients can decode and potentially rely on. This creates
a coupling between token format and client behavior. If the server needs to
revoke a token, change the expiry model, or add/remove claims, JWT clients may
break or behave incorrectly.
Opaque auth cookies are simpler:
- Server generates 32 random bytes → hex-encodes → stores SHA-256 hash → sets
raw hex as an HttpOnly cookie
- On each request, server hashes the cookie value and looks it up
- Revocation is a database delete (cookie becomes invalid immediately)
- No clock skew issues, no algorithm confusion, no "none" algorithm attacks
- Cookie format can change without breaking clients
- Browsers and HTTP cookie jars manage cookies automatically; CLI clients must
explicitly save and resend cookies (e.g., curl `-c`/`-b` flags)
---
## Architecture
### Transport: HTTP Only
All client↔server and server↔server communication uses HTTP/1.1+ with JSON
request/response bodies. No WebSockets, no raw TCP, no gRPC — just plain HTTP.
- **Client reading**: Long-poll `GET /api/v1/messages` — server holds the
connection for up to 15s until messages arrive or timeout. One endpoint for
everything — channel messages, DMs, system events, numeric replies.
- **Client writing**: `POST /api/v1/messages` with a `command` field. One
endpoint for everything — PRIVMSG, JOIN, PART, NICK, TOPIC, etc.
- **Server federation**: Servers exchange messages via HTTP to enable
multi-server networks (like IRC server linking).
The entire read/write loop for a client is two endpoints. Everything else
(state, history, channels, members, server info) is ancillary.
### Session Lifecycle
#### Session Creation
```
┌─ Client ──────────────────────────────────────────────────┐
│ │
│ 1. POST /api/v1/session {"nick":"alice"} │
│ → Set-Cookie: neoirc_auth=<random_hex>; HttpOnly; ... │
│ → {"id":1, "nick":"alice"} │
│ │
│ 2. POST /api/v1/messages {"command":"JOIN","to":"#gen"} │
│ → {"status":"joined","channel":"#general"} │
│ (Cookie must be sent on all subsequent requests) │
│ │
│ 3. POST /api/v1/messages {"command":"PRIVMSG", │
│ "to":"#general","body":["hello"]} │
│ → {"id":"uuid-...","status":"sent"} │
│ (Server fans out to all #general members' queues) │
│ │
│ 4. GET /api/v1/messages?after=0&timeout=15 │
│ ← (held open up to 15s until messages arrive) │
│ → {"messages":[...], "last_id": 42} │
│ │
│ 5. GET /api/v1/messages?after=42&timeout=15 │
│ ← (recursive long-poll, using last_id as cursor) │
│ │
│ 6. POST /api/v1/messages {"command":"QUIT"} │
│ → {"status":"quit"} │
│ (Server broadcasts QUIT, removes from channels, │
│ deletes session, releases nick, clears cookie) │
│ │
└────────────────────────────────────────────────────────────┘
```
#### Multi-Client via Password
```
┌─ Client A ────────────────────────────────────────────────┐
│ │
│ 1. POST /api/v1/session {"nick":"alice"} │
│ → Set-Cookie: neoirc_auth=<cookie_a>; HttpOnly; ... │
│ → {"id":1, "nick":"alice"} │
│ │
│ 2. POST /api/v1/messages │
│ {"command":"PASS","body":["s3cret!!"]} │
│ → {"status":"ok"} │
│ (Password set via IRC PASS command) │
│ │
│ ... use the API normally (JOIN, PRIVMSG, poll, etc.) ... │
│ │
└────────────────────────────────────────────────────────────┘
┌─ Client B (another device, while session is still active) ┐
│ │
│ 3. POST /api/v1/login │
│ {"nick":"alice", "password":"s3cret!!"} │
│ → Set-Cookie: neoirc_auth=<cookie_b>; HttpOnly; ... │
│ → {"id":1, "nick":"alice"} │
│ (New client added to existing session — channels │
│ and message queues are preserved.) │
│ │
└────────────────────────────────────────────────────────────┘
```
### Queue Architecture
```
┌─────────────────┐
│ messages table │ (one row per message, shared)
│ id | uuid | cmd│
│ from | to | .. │
└────────┬────────┘
│
┌──────────────┼──────────────┐
│ │ │
┌─────────▼──┐ ┌───────▼────┐ ┌──────▼─────┐
│client_queue│ │client_queue│ │client_queue│
│ client_id=1│ │ client_id=2│ │ client_id=3│
│ msg_id=N │ │ msg_id=N │ │ msg_id=N │
└────────────┘ └────────────┘ └────────────┘
alice bob carol
Each message is stored ONCE. One queue entry per recipient client.
```
The `client_queues` table contains `(client_id, message_id)` pairs. When a
client polls with `GET /messages?after=<queue_id>`, the server queries for queue
entries with `id > after` for that client, joins against the messages table, and
returns the results. The `queue_id` (auto-incrementing primary key of
`client_queues`) serves as a monotonically increasing cursor.
### In-Memory Broker
The server maintains an in-memory notification broker to avoid database polling.
The broker is a map of `client_id → []chan struct{}`. When a message is enqueued
for a client:
1. The handler calls `broker.Notify(clientID)`
2. The broker closes all waiting channels for that client
3. Any goroutines blocked in `select` on those channels wake up
4. The woken handler queries the database for new queue entries
5. Messages are returned to the client
If the server restarts, the broker is empty — but this is fine because clients
that reconnect will poll immediately and get any queued messages from the
database. The broker is purely an optimization to avoid polling latency.
---
## Protocol Specification
### Message Envelope
Every message — client-to-server, server-to-client, and server-to-server — uses
the same JSON envelope:
```json
{
"id": "string (uuid)",
"command": "string",
"from": "string",
"to": "string",
"params": ["string", ...],
"body": ["string", ...] | {...},
"ts": "string (ISO 8601)",
"meta": {...}
}
```
#### Field Reference
| Field | Type | C2S | S2C | Description |
| --------- | ----------------- | --------- | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `id` | string (UUID v4) | Ignored | Always | Server-assigned unique message identifier. |
| `command` | string | Required | Always | IRC command name (`PRIVMSG`, `JOIN`, etc.) or 3-digit numeric reply code (`001`, `433`, etc.). Case-insensitive on input; server normalizes to uppercase. |
| `from` | string | Ignored | Usually | Sender's nick (for user messages) or server name (for server messages). Server always overwrites this field — clients cannot spoof the sender. |
| `to` | string | Usually | Usually | Destination: `#channel` for channel targets, bare nick for DMs/user targets. |
| `params` | array of strings | Sometimes | Sometimes | Additional IRC-style positional parameters. Used by commands like `MODE`, `KICK`, and numeric replies like `353` (NAMES). |
| `body` | array or object | Usually | Usually | Structured message body. For text messages: array of strings (one per line). For structured data (e.g., `PUBKEY`): JSON object. **Never a raw string.** |
| `ts` | string (ISO 8601) | Ignored | Always | Server-assigned timestamp in RFC 3339 / ISO 8601 format with nanosecond precision. Example: `"2026-02-10T20:00:00.000000000Z"`. Always UTC. |
| `meta` | object | Optional | If present | Extensible metadata. Used for cryptographic signatures (`meta.sig`, `meta.alg`), hashcash proof-of-work (`meta.hashcash`), content hashes, or any client-defined key/value pairs. Server relays `meta` verbatim except for `hashcash` which is validated on channels with `+H` mode. |
**Important invariants:**
- `body` is **always** an array or object, **never** a raw string. This enables
deterministic canonicalization via RFC 8785 JCS.
- `from` is **always set by the server** on S2C messages. Clients may include
`from` on C2S messages, but it is ignored and overwritten.
- `id` and `ts` are **always set by the server**. Client-supplied values are
ignored.
- `meta` is **relayed verbatim**. The server stores it as-is and includes it in
S2C messages. It is never modified, validated, or interpreted by the server.
### Commands (C2S and S2C)
All commands use the same envelope format regardless of direction. A `PRIVMSG`
from a client to the server has the same shape as the `PRIVMSG` relayed from the
server to other clients. The only differences are which fields the server fills
in (`id`, `ts`, `from`).
#### PRIVMSG — Send Message
Send a message to a channel or user. This is the primary messaging command.
**C2S:**
```json
{"command": "PRIVMSG", "to": "#general", "body": ["hello world"]}
{"command": "PRIVMSG", "to": "#general", "body": ["line one", "line two"]}
{"command": "PRIVMSG", "to": "bob", "body": ["hey, DM"]}
{"command": "PRIVMSG", "to": "#general", "body": ["signed message"],
"meta": {"sig": "base64...", "alg": "ed25519"}}
```
**S2C (as delivered to recipients):**
```json
{
"id": "7f5a04f8-eab4-4d2e-be55-f5cfcfaf43c5",
"command": "PRIVMSG",
"from": "alice",
"to": "#general",
"body": ["hello world"],
"ts": "2026-02-10T20:00:00.000000000Z",
"meta": {}
}
```
**Behavior:**
- If `to` starts with `#`, the message is sent to a channel. The server fans out
to all channel members (including the sender — the sender sees their own
message echoed back via the queue).
- If `to` is a bare nick, the message is a DM. The server fans out to the
recipient and the sender (so all of the sender's clients see the DM).
- `body` must be a non-empty array of strings.
- If the channel doesn't exist, the server returns HTTP 404.
- If the DM target nick doesn't exist, the server returns HTTP 404.
**Response:** `201 Created`
```json
{ "id": "uuid-string", "status": "sent" }
```
**IRC reference:** RFC 1459 §4.4.1
#### NOTICE — Send Notice
Identical to PRIVMSG but **must not trigger auto-replies** from bots or clients.
This prevents infinite loops between automated systems.
**C2S:**
```json
{
"command": "NOTICE",
"to": "#general",
"body": ["server maintenance in 5 min"]
}
```
**Behavior:** Same as PRIVMSG in all respects, except clients receiving a NOTICE
must not send an automatic reply.
**IRC reference:** RFC 1459 §4.4.2
#### JOIN — Join Channel
Join a channel. If the channel doesn't exist, it is created.
**C2S:**
```json
{"command": "JOIN", "to": "#general"}
{"command": "JOIN", "to": "general"}
```
If the `#` prefix is omitted, the server adds it.
**S2C (broadcast to all channel members, including the joiner):**
```json
{
"id": "...",
"command": "JOIN",
"from": "alice",
"to": "#general",
"body": [],
"ts": "2026-02-10T20:00:00.000000000Z",
"meta": {}
}
```
**Behavior:**
- If the channel doesn't exist, it is created with no topic and no modes.
- If the user is already in the channel, the JOIN is a no-op (no error, no
duplicate broadcast).
- The JOIN event is broadcast to **all** channel members, including the user who
joined. This lets the client confirm the join succeeded and lets other members
update their member lists.
- The first user to join a channel becomes its implicit operator (not yet
enforced in current implementation).
**Response:** `200 OK`
```json
{ "status": "joined", "channel": "#general" }
```
**IRC reference:** RFC 1459 §4.2.1
#### PART — Leave Channel
Leave a channel.
**C2S:**
```json
{"command": "PART", "to": "#general"}
{"command": "PART", "to": "#general", "body": ["goodbye"]}
```
**S2C (broadcast to all channel members, including the leaver):**
```json
{
"id": "...",
"command": "PART",
"from": "alice",
"to": "#general",
"body": ["goodbye"],
"ts": "...",
"meta": {}
}
```
**Behavior:**
- The PART event is broadcast **before** the member is removed, so the departing
user receives their own PART event.
- 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.
- The `body` field is optional and contains a part message (reason).
**Response:** `200 OK`
```json
{ "status": "parted", "channel": "#general" }
```
**IRC reference:** RFC 1459 §4.2.2
#### NICK — Change Nickname
Change the user's nickname.
**C2S:**
```json
{ "command": "NICK", "body": ["newnick"] }
```
**S2C (broadcast to all users sharing a channel with the changer):**
```json
{
"id": "...",
"command": "NICK",
"from": "oldnick",
"to": "",
"body": ["newnick"],
"ts": "...",
"meta": {}
}
```
**Behavior:**
- `body[0]` is the new nick. Must be 1–32 characters.
- The `from` field in the broadcast contains the **old** nick.
- The `body[0]` in the broadcast contains the **new** nick.
- The NICK event is broadcast to the user themselves and to all users who share
at least one channel with the changer. Each recipient receives the event
exactly once, even if they share multiple channels.
- If the new nick is already taken, the server returns HTTP 409 Conflict.
**Response:** `200 OK`
```json
{ "status": "ok", "nick": "newnick" }
```
**Error (nick taken):** `409 Conflict`
```json
{ "error": "nick already in use" }
```
**IRC reference:** RFC 1459 §4.1.2
#### PASS — Set Session Password
Set a password on the current session, enabling multi-client login via
`POST /api/v1/login`. The password is hashed with bcrypt and stored server-side.
**C2S:**
```json
{ "command": "PASS", "body": ["mypassword"] }
```
**Behavior:**
- `body[0]` is the password. Must be at least 8 characters.
- On success, the server responds with `{"status": "ok"}`.
- If the password is too short or missing, the server sends ERR_NEEDMOREPARAMS
(461) via the message queue.
- Calling PASS again overwrites the previous password.
- Once a password is set, `POST /api/v1/login` can be used with the nick and
password to create additional clients on the same session.
**Response:** `200 OK`
```json
{ "status": "ok" }
```
**IRC reference:** Inspired by RFC 1459 §4.1.1 (PASS), repurposed for session
password management.
#### TOPIC — Set Channel Topic
Set or change a channel's topic.
**C2S:**
```json
{ "command": "TOPIC", "to": "#general", "body": ["Welcome to #general"] }
```
**S2C (broadcast to all channel members):**
```json
{
"id": "...",
"command": "TOPIC",
"from": "alice",
"to": "#general",
"body": ["Welcome to #general"],
"ts": "...",
"meta": {}
}
```
**Behavior:**
- Updates the channel's topic in the database.
- The TOPIC event is broadcast to all channel members.
- If the channel doesn't exist, the server returns an error.
- If the channel has mode `+t` (topic lock, default: ON for new channels), only
operators (`+o`) can change the topic. Non-operators receive
`ERR_CHANOPRIVSNEEDED` (482).
**Response:** `200 OK`
```json
{ "status": "ok", "topic": "Welcome to #general" }
```
**IRC reference:** RFC 1459 §4.2.4
#### QUIT — Disconnect
Destroy the session and disconnect from the server.
**C2S:**
```json
{"command": "QUIT"}
{"command": "QUIT", "body": ["leaving"]}
```
**S2C (broadcast to all users sharing channels with the quitter):**
```json
{
"id": "...",
"command": "QUIT",
"from": "alice",
"to": "",
"body": ["leaving"],
"ts": "...",
"meta": {}
}
```
**Behavior:**
- The QUIT event is broadcast to all users who share a channel with the quitting
user. The quitting user does **not** receive their own QUIT.
- The user is removed from all channels.
- Empty channels are deleted (ephemeral).
- The user's session is destroyed — the auth cookie is invalidated, the nick is
released.
- Subsequent requests with the old auth cookie return HTTP 401.
**Response:** `200 OK`
```json
{ "status": "quit" }
```
**IRC reference:** RFC 1459 §4.1.6
#### PING — Keepalive
Client keepalive. Server responds synchronously with PONG.
**C2S:**
```json
{ "command": "PING" }
```
**Response (synchronous, not via the queue):** `200 OK`
```json
{ "command": "PONG", "from": "servername" }
```
**Note:** PING/PONG is synchronous — the PONG is the HTTP response body, not a
queued message. This is deliberate: keepalives should be low-latency and not
pollute the message queue.
**IRC reference:** RFC 1459 §4.6.2, §4.6.3
#### MODE — Query Modes
Query channel or user modes. Returns the current mode string and, for channels,
the creation timestamp.
**C2S:**
```json
{"command": "MODE", "to": "#general"}
{"command": "MODE", "to": "alice"}
```
**S2C (via message queue):**
For channels, the server sends RPL_CHANNELMODEIS (324) and RPL_CREATIONTIME
(329):
```json
{"command": "324", "to": "alice", "params": ["#general", "+n"]}
{"command": "329", "to": "alice", "params": ["#general", "1709251200"]}
```
For users, the server sends RPL_UMODEIS (221):
```json
{ "command": "221", "to": "alice", "body": ["+"] }
```
**Note:** Mode changes (setting/unsetting modes) are not yet implemented.
Currently only query is supported.
**IRC reference:** RFC 1459 §4.2.3
#### NAMES — Channel Member List
Request the member list for a channel. Returns RPL_NAMREPLY (353) and
RPL_ENDOFNAMES (366).
**C2S:**
```json
{ "command": "NAMES", "to": "#general" }
```
**IRC reference:** RFC 1459 §4.2.5
#### LIST — List Channels
Request a list of all channels with member counts. Returns RPL_LIST (322) for
each channel followed by RPL_LISTEND (323).
**C2S:**
```json
{ "command": "LIST" }
```
**IRC reference:** RFC 1459 §4.2.6
#### WHOIS — User Information
Query information about a user. Returns RPL_WHOISUSER (311), RPL_WHOISSERVER
(312), RPL_WHOISOPERATOR (313, if target is oper), RPL_WHOISIDLE (317),
RPL_WHOISCHANNELS (319), and RPL_ENDOFWHOIS (318).
If the querying user is a **server operator** (authenticated via `OPER`), the
response additionally includes RPL_WHOISACTUALLY (338) with the target's current
client IP address and hostname.
**C2S:**
```json
{ "command": "WHOIS", "to": "alice" }
```
**IRC reference:** RFC 1459 §4.5.2
#### WHO — Channel User List
Query users in a channel. Returns RPL_WHOREPLY (352) for each user followed by
RPL_ENDOFWHO (315).
**C2S:**
```json
{ "command": "WHO", "to": "#general" }
```
**IRC reference:** RFC 1459 §4.5.1
#### LUSERS — Server Statistics
Request server user/channel statistics. Returns RPL_LUSERCLIENT (251),
RPL_LUSEROP (252), RPL_LUSERCHANNELS (254), and RPL_LUSERME (255).
**C2S:**
```json
{ "command": "LUSERS" }
```
LUSERS replies are also sent automatically during connection registration.
**IRC reference:** RFC 1459 §4.3.2
#### OPER — Gain Server Operator Status
Authenticate as a server operator (o-line). On success, the session gains oper
privileges, which currently means additional information is visible in WHOIS
responses (e.g., target user's current client IP and hostname).
**C2S:**
```json
{ "command": "OPER", "body": ["opername", "operpassword"] }
```
**S2C (via message queue on success):**
```json
{ "command": "381", "to": "alice", "body": ["You are now an IRC operator"] }
```
**Behavior:**
- `body[0]` is the operator name, `body[1]` is the operator password.
- The server checks against the configured `NEOIRC_OPER_NAME` and
`NEOIRC_OPER_PASSWORD` environment variables.
- On success, the session's `is_oper` flag is set and `381 RPL_YOUREOPER` is
returned.
- On failure (wrong credentials or no o-line configured), `491 ERR_NOOPERHOST`
is returned.
- Oper status persists for the session lifetime. There is no de-oper command.
**IRC reference:** RFC 1459 §4.1.5
#### KICK — Kick User
Remove a user from a channel. Only channel operators (`+o`) can use this
command. The kicked user and all channel members receive the KICK message.
**C2S:**
```json
{ "command": "KICK", "to": "#general", "body": ["bob", "misbehaving"] }
```
The first element of `body` is the target nick, the second (optional) is the
reason. If no reason is provided, the kicker's nick is used as the default.
**Errors:**
- `482` (ERR_CHANOPRIVSNEEDED) — kicker is not a channel operator
- `441` (ERR_USERNOTINCHANNEL) — target is not in the channel
- `403` (ERR_NOSUCHCHANNEL) — channel does not exist
**IRC reference:** RFC 1459 §4.2.8
#### PUBKEY — Announce Signing Key
Distribute a public signing key to channel members.
**C2S:**
```json
{
"command": "PUBKEY",
"body": { "alg": "ed25519", "key": "base64-encoded-pubkey" }
}
```
**S2C (relayed to channel members):**
```json
{
"id": "...",
"command": "PUBKEY",
"from": "alice",
"body": { "alg": "ed25519", "key": "base64-encoded-pubkey" },
"ts": "...",
"meta": {}
}
```
**Behavior:** The server relays PUBKEY messages verbatim. It does not verify,
store, or interpret the key material. See [Security Model](#security-model) for
the full key distribution protocol.
**Status:** Not yet implemented.
### Numeric Reply Codes (S2C Only)
Numeric replies follow IRC conventions from RFC 1459/2812. They are sent from
the server to the client (never C2S) and use 3-digit string codes in the
`command` field.
| Code | Name | When Sent | Example |
| ----- | -------------------- | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `001` | RPL_WELCOME | After session creation | `{"command":"001","to":"alice","body":["Welcome to the network, alice"]}` |
| `002` | RPL_YOURHOST | After session creation | `{"command":"002","to":"alice","body":["Your host is neoirc, running version 0.1"]}` |
| `003` | RPL_CREATED | After session creation | `{"command":"003","to":"alice","body":["This server was created 2026-02-10"]}` |
| `004` | RPL_MYINFO | After session creation | `{"command":"004","to":"alice","params":["neoirc","0.1","","ikmnostl"]}` |
| `005` | RPL_ISUPPORT | After session creation | `{"command":"005","to":"alice","params":["CHANTYPES=#","NICKLEN=32","PREFIX=(ov)@+","CHANMODES=b,k,Hl,imnst","NETWORK=neoirc"],"body":["are supported by this server"]}` |
| `221` | RPL_UMODEIS | In response to user MODE query | `{"command":"221","to":"alice","body":["+"]}` |
| `251` | RPL_LUSERCLIENT | On connect or LUSERS command | `{"command":"251","to":"alice","body":["There are 5 users and 0 invisible on 1 servers"]}` |
| `252` | RPL_LUSEROP | On connect or LUSERS command | `{"command":"252","to":"alice","params":["0"],"body":["operator(s) online"]}` |
| `254` | RPL_LUSERCHANNELS | On connect or LUSERS command | `{"command":"254","to":"alice","params":["3"],"body":["channels formed"]}` |
| `255` | RPL_LUSERME | On connect or LUSERS command | `{"command":"255","to":"alice","body":["I have 5 clients and 1 servers"]}` |
| `311` | RPL_WHOISUSER | In response to WHOIS | `{"command":"311","to":"alice","params":["bob","bobident","host.example.com","*"],"body":["bob"]}` |
| `312` | RPL_WHOISSERVER | In response to WHOIS | `{"command":"312","to":"alice","params":["bob","neoirc"],"body":["neoirc server"]}` |
| `313` | RPL_WHOISOPERATOR | In WHOIS if target is oper | `{"command":"313","to":"alice","params":["bob"],"body":["is an IRC operator"]}` |
| `315` | RPL_ENDOFWHO | End of WHO response | `{"command":"315","to":"alice","params":["#general"],"body":["End of /WHO list"]}` |
| `318` | RPL_ENDOFWHOIS | End of WHOIS response | `{"command":"318","to":"alice","params":["bob"],"body":["End of /WHOIS list"]}` |
| `319` | RPL_WHOISCHANNELS | In response to WHOIS | `{"command":"319","to":"alice","params":["bob"],"body":["#general #dev"]}` |
| `338` | RPL_WHOISACTUALLY | In WHOIS when querier is oper | `{"command":"338","to":"alice","params":["bob","192.168.1.1"],"body":["is actually using host client.example.com"]}` |
| `322` | RPL_LIST | In response to LIST | `{"command":"322","to":"alice","params":["#general","5"],"body":["General discussion"]}` |
| `323` | RPL_LISTEND | End of LIST response | `{"command":"323","to":"alice","body":["End of /LIST"]}` |
| `324` | RPL_CHANNELMODEIS | In response to channel MODE query | `{"command":"324","to":"alice","params":["#general","+n"]}` |
| `329` | RPL_CREATIONTIME | After channel MODE query | `{"command":"329","to":"alice","params":["#general","1709251200"]}` |
| `331` | RPL_NOTOPIC | Channel has no topic (on JOIN) | `{"command":"331","to":"alice","params":["#general"],"body":["No topic is set"]}` |
| `332` | RPL_TOPIC | On JOIN or TOPIC query | `{"command":"332","to":"alice","params":["#general"],"body":["Welcome!"]}` |
| `352` | RPL_WHOREPLY | In response to WHO | `{"command":"352","to":"alice","params":["#general","bobident","host.example.com","neoirc","bob","H"],"body":["0 bob"]}` |
| `353` | RPL_NAMREPLY | On JOIN or NAMES query | `{"command":"353","to":"alice","params":["=","#general"],"body":["op1!op1@host1 alice!alice@host2 bob!bob@host3"]}` |
| `366` | RPL_ENDOFNAMES | End of NAMES response | `{"command":"366","to":"alice","params":["#general"],"body":["End of /NAMES list"]}` |
| `372` | RPL_MOTD | MOTD line | `{"command":"372","to":"alice","body":["Welcome to the server"]}` |
| `375` | RPL_MOTDSTART | Start of MOTD | `{"command":"375","to":"alice","body":["- neoirc-server Message of the Day -"]}` |
| `376` | RPL_ENDOFMOTD | End of MOTD | `{"command":"376","to":"alice","body":["End of /MOTD command"]}` |
| `381` | RPL_YOUREOPER | Successful OPER auth | `{"command":"381","to":"alice","body":["You are now an IRC operator"]}` |
| `401` | ERR_NOSUCHNICK | DM to nonexistent nick | `{"command":"401","to":"alice","params":["bob"],"body":["No such nick/channel"]}` |
| `403` | ERR_NOSUCHCHANNEL | Action on nonexistent channel | `{"command":"403","to":"alice","params":["#nope"],"body":["No such channel"]}` |
| `421` | ERR_UNKNOWNCOMMAND | Unrecognized command | `{"command":"421","to":"alice","params":["FOO"],"body":["Unknown command"]}` |
| `432` | ERR_ERRONEUSNICKNAME | Invalid nick format | `{"command":"432","to":"alice","params":["bad nick!"],"body":["Erroneous nickname"]}` |
| `433` | ERR_NICKNAMEINUSE | NICK to taken nick | `{"command":"433","to":"*","params":["alice"],"body":["Nickname is already in use"]}` |
| `442` | ERR_NOTONCHANNEL | Action on unjoined channel | `{"command":"442","to":"alice","params":["#general"],"body":["You're not on that channel"]}` |
| `461` | ERR_NEEDMOREPARAMS | Missing required fields | `{"command":"461","to":"alice","params":["JOIN"],"body":["Not enough parameters"]}` |
| `482` | ERR_CHANOPRIVSNEEDED | Non-op tries op action | `{"command":"482","to":"alice","params":["#general"],"body":["You're not channel operator"]}` |
| `491` | ERR_NOOPERHOST | Failed OPER auth | `{"command":"491","to":"alice","body":["No O-lines for your host"]}` |
**Note:** Numeric replies are now implemented. All IRC command responses
(success and error) are delivered as numeric replies through the message queue.
HTTP error codes are reserved for transport-level issues (auth failures,
malformed requests, server errors). The `params` field in the message envelope
carries IRC-style parameters (e.g., channel name, target nick).
### Channel Modes
Inspired by IRC, simplified:
| Mode | Name | Meaning | Status |
| ---- | ----------- | ----------------------------------------------------------------------------------------------------- | ------------ |
| `+b` | Ban | Prevents matching hostmasks from joining or sending (parameter: `nick!user@host` mask with wildcards) | **Enforced** |
| `+i` | Invite-only | Only invited users can join; use `INVITE nick #channel` to invite | **Enforced** |
| `+k` | Channel key | Requires a password to join (parameter: key string) | **Enforced** |
| `+l` | User limit | Maximum number of members allowed in the channel (parameter: integer) | **Enforced** |
| `+m` | Moderated | Only voiced (`+v`) users and operators (`+o`) can send | **Enforced** |
| `+n` | No external | Only channel members can send messages to the channel | **Enforced** |
| `+s` | Secret | Channel hidden from LIST and WHOIS for non-members | **Enforced** |
| `+t` | Topic lock | Only operators can change the topic (default: ON) | **Enforced** |
| `+H` | Hashcash | Requires proof-of-work for PRIVMSG (parameter: bits, e.g. `+H 20`) | **Enforced** |
**User channel modes (set per-user per-channel):**
| Mode | Meaning | Display prefix | Status |
| ---- | -------- | ------------------ | ------------ |
| `+o` | Operator | `@` in NAMES reply | **Enforced** |
| `+v` | Voice | `+` in NAMES reply | **Enforced** |
**Channel creator auto-op:** The first user to JOIN a channel (creating it)
automatically receives `+o` operator status.
**Ban system (+b):** Operators can ban users by hostmask pattern with wildcard
matching (`*` and `?`). `MODE #channel +b` with no argument lists current bans.
Bans prevent both joining and sending messages.
```
MODE #channel +b *!*@*.example.com — ban all users from example.com
MODE #channel -b *!*@*.example.com — remove the ban
MODE #channel +b — list all bans (RPL_BANLIST 367/368)
```
**Invite-only (+i):** When set, users must be invited by an operator before
joining. The `INVITE` command records an invite that is consumed on JOIN.
```
MODE #channel +i — set invite-only
INVITE nick #channel — invite a user (operator only on +i channels)
```
**Channel key (+k):** Requires a password to join the channel.
```
MODE #channel +k secretpass — set a channel key
MODE #channel -k * — remove the key
JOIN #channel secretpass — join with key
```
**User limit (+l):** Caps the number of members in the channel.
```
MODE #channel +l 50 — set limit to 50 members
MODE #channel -l — remove the limit
```
**Secret (+s):** Hides the channel from `LIST` for non-members and from `WHOIS`
channel lists when the querier is not in the same channel.
**KICK command:** Channel operators can remove users with
`KICK #channel nick [:reason]`. The kicked user and all channel members receive
the KICK message.
**NOTICE:** Follows RFC 2812 — NOTICE never triggers auto-replies (including
RPL_AWAY), and skips hashcash validation on +H channels (servers and services
use NOTICE).
**ISUPPORT:** The server advertises `PREFIX=(ov)@+` and `CHANMODES=b,k,Hl,imnst`
in RPL_ISUPPORT (005).
### Per-Channel Hashcash (Anti-Spam)
Channels can require hashcash proof-of-work for every `PRIVMSG`. This is an
anti-spam mechanism: channel operators set a difficulty level, and clients must
compute a proof-of-work stamp bound to the specific channel and message before
sending.
**Setting the requirement:**
```
MODE #channel +H <bits> — require <bits> leading zero bits (1-40)
MODE #channel -H — disable hashcash requirement
```
**Stamp format:** `1:bits:YYMMDD:channel:bodyhash:counter`
- `bits` — difficulty (leading zero bits in SHA-256 hash of the stamp)
- `YYMMDD` — current date (prevents old token reuse)
- `channel` — channel name (prevents cross-channel reuse)
- `bodyhash` — hex-encoded SHA-256 of the message body (binds stamp to message)
- `counter` — hex nonce
**Sending a message to a hashcash-protected channel:**
Include the hashcash stamp in the `meta` field:
```json
{
"command": "PRIVMSG",
"to": "#general",
"body": ["hello world"],
"meta": {
"hashcash": "1:20:260317:#general:a1b2c3...bodyhash:1f4a"
}
}
```
**Server validation:** The server checks that the stamp is well-formed, meets
the required difficulty, is bound to the correct channel and message body, has a
recent date, and has not been previously used. Spent stamps are cached for 1
year to prevent replay attacks.
**Error responses:** If the channel requires hashcash and the stamp is missing,
invalid, or replayed, the server returns `ERR_CANNOTSENDTOCHAN (404)` with a
descriptive reason.
**Client minting:** The CLI provides `MintChannelHashcash(bits, channel, body)`
to compute stamps. Higher bit counts take exponentially longer to compute.
---
## API Reference
All endpoints accept and return `application/json`. Authenticated endpoints
require the `neoirc_auth` cookie, which is set automatically by
`POST /api/v1/session` and `POST /api/v1/login`.
All API responses include appropriate HTTP status codes. Error responses have
the format:
```json
{ "error": "human-readable error message" }
```
### POST /api/v1/session — Create Session
Create a new user session. This is the entry point for all clients.
If the server requires hashcash proof-of-work (see
[Hashcash Proof-of-Work](#hashcash-proof-of-work)), the client must include a
valid stamp in the `pow_token` field of the JSON request body. The required
difficulty is advertised via `GET /api/v1/server` in the `hashcash_bits` field.
**Request Body:**
```json
{
"nick": "alice",
"username": "alice",
"pow_token": "1:20:260310:neoirc::3a2f1"
}
```
| Field | Type | Required | Constraints |
| ----------- | ------ | ----------- | -------------------------------------------------------------- |
| `nick` | string | Yes | 1–32 characters, must be unique on the server |
| `username` | string | No | 1–32 characters, IRC ident-style. Defaults to nick if omitted. |
| `pow_token` | string | Conditional | Hashcash stamp (required when server has `hashcash_bits` > 0) |
The `username` field sets the user portion of the IRC hostmask
(`nick!user@host`). The hostname is automatically resolved via reverse DNS of
the connecting client's IP address at session creation time. Together these form
the hostmask used in WHOIS, WHO, and future ban matching (`+b`).
**Response:** `201 Created`
The response sets an `neoirc_auth` HttpOnly cookie containing an opaque auth
value. The JSON body does **not** include the auth credential.
```
Set-Cookie: neoirc_auth=494ba9fc...e3; Path=/; HttpOnly; SameSite=Strict
```
```json
{
"id": 1,
"nick": "alice"
}
```
| Field | Type | Description |
| ------ | ------- | -------------------------------------------------- |
| `id` | integer | Server-assigned user ID |
| `nick` | string | Confirmed nick (always matches request on success) |
**Cookie properties:**
| Property | Value |
| ---------- | --------------------------------------- |
| `Name` | `neoirc_auth` |
| `HttpOnly` | `true` (not accessible from JavaScript) |
| `SameSite` | `Strict` (prevents CSRF) |
| `Secure` | `true` (sent only over HTTPS) |
| `Path` | `/` |
**Errors:**
| Status | Error | When |
| ------ | --------------------------------- | ------------------------------------------------------------------ |
| 400 | `nick must be 1-32 characters` | Empty or too-long nick |
| 400 | `invalid username format` | Username doesn't match allowed format |
| 402 | `hashcash proof-of-work required` | Missing `pow_token` field in request body when hashcash is enabled |
| 402 | `invalid hashcash stamp: ...` | Stamp fails validation (wrong bits, expired, reused, etc.) |
| 409 | `nick already taken` | Another active session holds this nick |
**curl example:**
```bash
# Use -c to save cookies, -b to send them
curl -s -c cookies.txt -X POST http://localhost:8080/api/v1/session \
-H 'Content-Type: application/json' \
-d '{"nick":"alice","pow_token":"1:20:260310:neoirc::3a2f1"}'
```
### POST /api/v1/login — Login to Account
Authenticate with a nick and password (set via the PASS IRC command). Creates a
new client for the existing session, preserving channel memberships and message
queues. This is how multi-client access works: each login adds a new client to
the session with its own auth cookie and message delivery queue.
On successful login, the server enqueues MOTD messages and synthetic channel
state (JOIN + TOPIC + NAMES for each channel the session belongs to) into the
new client's queue, so the client can immediately restore its UI state.
**Request Body:**
```json
{ "nick": "alice", "password": "mypassword" }
```
| Field | Type | Required | Constraints |
| ---------- | ------ | -------- | ------------------------------------------------ |
| `nick` | string | Yes | Must match an active session with a password set |
| `password` | string | Yes | Must match the session's password |
**Response:** `200 OK`
The response sets an `neoirc_auth` HttpOnly cookie for the new client.
```json
{
"id": 1,
"nick": "alice"
}
```
| Field | Type | Description |
| ------ | ------- | ------------ |
| `id` | integer | Session ID |
| `nick` | string | Current nick |
**Errors:**
| Status | Error | When |
| ------ | ---------------------------- | -------------------------------------------------------------- |
| 400 | `nick and password required` | Missing nick or password |
| 401 | `invalid credentials` | Wrong password, nick not found, or session has no password set |
**curl example:**
```bash
curl -s -c cookies.txt -X POST http://localhost:8080/api/v1/login \
-H 'Content-Type: application/json' \
-d '{"nick":"alice","password":"mypassword"}'
```
### GET /api/v1/state — Get Session State
Return the current user's session state.
**Request:** No body. Requires auth.
**Query Parameters:**
| Parameter | Type | Default | Description |
| ------------------ | ------ | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `initChannelState` | string | (none) | When set to `1`, enqueues synthetic JOIN + TOPIC + NAMES messages for every channel the session belongs to into the calling client's queue. Used by the SPA on reconnect to restore channel tabs without re-sending JOIN commands. |
**Response:** `200 OK`
```json
{
"id": 1,
"nick": "alice",
"channels": [
{ "id": 1, "name": "#general", "topic": "Welcome!" },
{ "id": 2, "name": "#dev", "topic": "" }
]
}
```
| Field | Type | Description |
| ---------- | ------- | -------------------------------- |
| `id` | integer | User ID |
| `nick` | string | Current nick |
| `channels` | array | Channels the user is a member of |
Each channel object:
| Field | Type | Description |
| ------- | ------- | ------------------------------------- |
| `id` | integer | Channel ID |
| `name` | string | Channel name (e.g., `#general`) |
| `topic` | string | Channel topic (empty string if unset) |
**curl example:**
```bash
curl -s http://localhost:8080/api/v1/state \
-b cookies.txt | jq .
```
**Reconnect with channel state initialization:**
```bash
curl -s "http://localhost:8080/api/v1/state?initChannelState=1" \
-b cookies.txt | jq .
```
### GET /api/v1/messages — Poll Messages (Long-Poll)
Retrieve messages from the client's delivery queue. This is the primary
real-time endpoint — clients call it in a loop.
**Query Parameters:**
| Param | Type | Default | Description |
| --------- | ------- | ------- | ----------------------------------------------------------------------------------------- |
| `after` | integer | `0` | Return only queue entries with ID > this value. Use `last_id` from the previous response. |
| `timeout` | integer | `0` | Long-poll timeout in seconds. `0` = return immediately. Max `30`. Recommended: `15`. |
**Response:** `200 OK`
```json
{
"messages": [
{
"id": "7f5a04f8-eab4-4d2e-be55-f5cfcfaf43c5",
"command": "JOIN",
"from": "bob",
"to": "#general",
"body": [],
"ts": "2026-02-10T20:00:00.000000000Z",
"meta": {}
},
{
"id": "b7c8210f-849c-4b90-9ee8-d99c8889358e",
"command": "PRIVMSG",
"from": "alice",
"to": "#general",
"body": ["hello world"],
"ts": "2026-02-10T20:00:01.000000000Z",
"meta": {}
}
],
"last_id": 42
}
```
| Field | Type | Description |
| ---------- | ------- | ------------------------------------------------------------------------------------------------------------------- |
| `messages` | array | Array of IRC message envelopes (see [Protocol Specification](#protocol-specification)). Empty array if no messages. |
| `last_id` | integer | Queue cursor. Pass this as `after` in the next request. |
**Long-poll behavior:**
1. If messages are immediately available (queue entries with ID > `after`), the
server responds instantly.
2. If no messages are available and `timeout` > 0, the server holds the
connection open.
3. The server responds when:
- A message arrives for this user (instantly via in-memory broker)
- The timeout expires (returns `{"messages":[], "last_id": <same>}`)
- The client disconnects (no response)
**curl example (immediate):**
```bash
curl -s -b cookies.txt "http://localhost:8080/api/v1/messages?after=0&timeout=0" | jq .
```
**curl example (long-poll, 15s):**
```bash
curl -s -b cookies.txt "http://localhost:8080/api/v1/messages?after=42&timeout=15" | jq .
```
### POST /api/v1/messages — Send Command
Send any client-to-server command. The `command` field determines the action.
This is the unified write endpoint — there are no separate endpoints for join,
part, nick, etc.
**Request body:** An IRC message envelope with `command` and relevant fields:
```json
{ "command": "PRIVMSG", "to": "#general", "body": ["hello world"] }
```
See [Commands (C2S and S2C)](#commands-c2s-and-s2c) for the full command
reference with all required and optional fields.
**Command dispatch table:**
| Command | Required Fields | Optional | Response Status |
| --------- | --------------- | -------- | --------------- |
| `PRIVMSG` | `to`, `body` | `meta` | 200 OK |
| `NOTICE` | `to`, `body` | `meta` | 200 OK |
| `JOIN` | `to` | | 200 OK |
| `PART` | `to` | `body` | 200 OK |
| `NICK` | `body` | | 200 OK |
| `PASS` | `body` | | 200 OK |
| `TOPIC` | `to`, `body` | | 200 OK |
| `MODE` | `to` | | 200 OK |
| `NAMES` | `to` | | 200 OK |
| `LIST` | | | 200 OK |
| `WHOIS` | `to` or `body` | | 200 OK |
| `WHO` | `to` | | 200 OK |
| `LUSERS` | | | 200 OK |
| `OPER` | `body` | | 200 OK |
| `QUIT` | | `body` | 200 OK |
| `PING` | | | 200 OK |
All IRC commands return HTTP 200 OK. IRC-level success and error responses are
delivered as **numeric replies** through the message queue (see
[Numeric Replies](#numeric-replies) below). HTTP error codes (4xx/5xx) are
reserved for transport-level problems: malformed JSON (400), missing/invalid
auth cookies (401), and server errors (500).
**HTTP errors (transport-level only):**
| Status | Error | When |
| ------ | ----------------- | ------------------------------- |
| 400 | `invalid request` | Malformed JSON or empty command |
| 401 | `unauthorized` | Missing or invalid auth cookie |
| 500 | `internal error` | Server-side failure |
**IRC numeric error replies (delivered via message queue):**
| Numeric | Name | When |
| ------- | -------------------- | -------------------------------------------- |
| 401 | ERR_NOSUCHNICK | DM target nick doesn't exist |
| 403 | ERR_NOSUCHCHANNEL | Target channel doesn't exist or invalid name |
| 421 | ERR_UNKNOWNCOMMAND | Unrecognized command |
| 432 | ERR_ERRONEUSNICKNAME | Invalid nickname format |
| 433 | ERR_NICKNAMEINUSE | NICK target is taken |
| 442 | ERR_NOTONCHANNEL | Not a member of the target channel |
| 461 | ERR_NEEDMOREPARAMS | Missing required fields (to, body) |
| 491 | ERR_NOOPERHOST | Failed OPER authentication |
**IRC numeric success replies (delivered via message queue):**
| Numeric | Name | When |
| ------- | ----------------- | ------------------------------------ |
| 001 | RPL_WELCOME | Sent on session creation/login |
| 002 | RPL_YOURHOST | Sent on session creation/login |
| 003 | RPL_CREATED | Sent on session creation/login |
| 004 | RPL_MYINFO | Sent on session creation/login |
| 005 | RPL_ISUPPORT | Sent on session creation/login |
| 221 | RPL_UMODEIS | In response to user MODE query |
| 251 | RPL_LUSERCLIENT | On connect or LUSERS command |
| 252 | RPL_LUSEROP | On connect or LUSERS command |
| 254 | RPL_LUSERCHANNELS | On connect or LUSERS command |
| 255 | RPL_LUSERME | On connect or LUSERS command |
| 311 | RPL_WHOISUSER | WHOIS user info |
| 312 | RPL_WHOISSERVER | WHOIS server info |
| 313 | RPL_WHOISOPERATOR | WHOIS target is oper |
| 315 | RPL_ENDOFWHO | End of WHO list |
| 318 | RPL_ENDOFWHOIS | End of WHOIS list |
| 319 | RPL_WHOISCHANNELS | WHOIS channels list |
| 338 | RPL_WHOISACTUALLY | WHOIS client IP (oper-only) |
| 322 | RPL_LIST | Channel in LIST response |
| 323 | RPL_LISTEND | End of LIST |
| 324 | RPL_CHANNELMODEIS | Channel mode query response |
| 329 | RPL_CREATIONTIME | Channel creation timestamp |
| 331 | RPL_NOTOPIC | Channel has no topic (on JOIN) |
| 332 | RPL_TOPIC | Channel topic (on JOIN, TOPIC set) |
| 352 | RPL_WHOREPLY | User in WHO response |
| 353 | RPL_NAMREPLY | Channel member list (on JOIN, NAMES) |
| 366 | RPL_ENDOFNAMES | End of NAMES list |
| 375 | RPL_MOTDSTART | Start of MOTD |
| 372 | RPL_MOTD | MOTD line |
| 376 | RPL_ENDOFMOTD | End of MOTD |
| 381 | RPL_YOUREOPER | Successful OPER authentication |
### GET /api/v1/history — Message History
Fetch historical messages for a channel. Returns messages in chronological order
(oldest first).
**Query Parameters:**
| Param | Type | Default | Description |
| -------- | ------- | ---------- | -------------------------------------------------------------------------------- |
| `target` | string | (required) | Channel name (e.g., `#general`) |
| `before` | integer | `0` | Return only messages with DB ID < this value (for pagination). `0` means latest. |
| `limit` | integer | `50` | Maximum messages to return. |
**Response:** `200 OK`
```json
[
{
"id": "uuid-1",
"command": "PRIVMSG",
"from": "alice",
"to": "#general",
"body": ["first message"],
"ts": "2026-02-10T19:00:00.000000000Z",
"meta": {}
},
{
"id": "uuid-2",
"command": "PRIVMSG",
"from": "bob",
"to": "#general",
"body": ["second message"],
"ts": "2026-02-10T19:01:00.000000000Z",
"meta": {}
}
]
```
**Note:** History currently returns only PRIVMSG messages (not JOIN/PART/etc.
events). Event messages are delivered via the live queue only.
**curl example:**
```bash
# Latest 50 messages in #general
curl -s "http://localhost:8080/api/v1/history?target=%23general&limit=50" \
-b cookies.txt | jq .
# Older messages (pagination)
curl -s "http://localhost:8080/api/v1/history?target=%23general&before=100&limit=50" \
-b cookies.txt | jq .
```
### GET /api/v1/channels — List Channels
List all channels on the server.
**Response:** `200 OK`
```json
[
{ "id": 1, "name": "#general", "topic": "Welcome!" },
{ "id": 2, "name": "#dev", "topic": "Development discussion" }
]
```
### GET /api/v1/channels/{name}/members — Channel Members
List members of a channel. The `{name}` parameter is the channel name
**without** the `#` prefix (it's added by the server).
**Response:** `200 OK`
```json
[
{ "id": 1, "nick": "alice", "lastSeen": "2026-02-10T20:00:00Z" },
{ "id": 2, "nick": "bob", "lastSeen": "2026-02-10T19:55:00Z" }
]
```
**curl example:**
```bash
curl -s http://localhost:8080/api/v1/channels/general/members \
-b cookies.txt | jq .
```
### POST /api/v1/logout — Logout
Destroy the current client's session cookie and server-side client record. If no
other clients remain on the session, the user is fully cleaned up: parted from
all channels (with QUIT broadcast to members), session deleted, nick released.
The auth cookie is cleared in the response.
**Request:** No body. Requires auth cookie.
**Response:** `200 OK`
The response clears the `neoirc_auth` cookie.
```json
{ "status": "ok" }
```
**Errors:**
| Status | Error | When |
| ------ | -------------- | ------------------------------ |
| 401 | `unauthorized` | Missing or invalid auth cookie |
**curl example:**
```bash
curl -s -b cookies.txt -c cookies.txt -X POST http://localhost:8080/api/v1/logout | jq .
```
### GET /api/v1/users/me — Current User Info
Return the current user's session state. This is an alias for
`GET /api/v1/state`.
**Request:** No body. Requires auth.
**Response:** `200 OK`
```json
{
"id": 1,
"nick": "alice",
"channels": [{ "id": 1, "name": "#general", "topic": "Welcome!" }]
}
```
**curl example:**
```bash
curl -s http://localhost:8080/api/v1/users/me \
-b cookies.txt | jq .
```
### GET /api/v1/server — Server Info
Return server metadata. No authentication required.
**Response:** `200 OK`
```json
{
"name": "My NeoIRC Server",
"version": "0.1.0",
"motd": "Welcome! Be nice.",
"users": 42,
"hashcash_bits": 20
}
```
| Field | Type | Description |
| --------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| `name` | string | Server display name |
| `version` | string | Server version |
| `motd` | string | Message of the day |
| `users` | integer | Number of currently active user sessions |
| `hashcash_bits` | integer | Required proof-of-work difficulty (leading zero bits). Only present when > 0. See [Hashcash Proof-of-Work](#hashcash-proof-of-work). |
### GET /.well-known/healthcheck.json — Health Check
Standard health check endpoint. No authentication required. Returns server
health status and runtime statistics.
**Response:** `200 OK`
```json
{
"status": "ok",
"now": "2024-01-15T12:00:00.000000000Z",
"uptimeSeconds": 3600,
"uptimeHuman": "1h0m0s",
"version": "0.1.0",
"appname": "neoirc",
"maintenanceMode": false,
"sessions": 42,
"clients": 85,
"queuedLines": 128,
"channels": 7,
"connectionsSinceBoot": 200,
"sessionsSinceBoot": 150,
"messagesSinceBoot": 5000
}
```
| Field | Description |
| ---------------------- | ----------------------------------------------------- |
| `sessions` | Current number of active sessions |
| `clients` | Current number of connected clients |
| `queuedLines` | Total entries in client output queues |
| `channels` | Current number of channels |
| `connectionsSinceBoot` | Total client connections since server start |
| `sessionsSinceBoot` | Total sessions created since server start |
| `messagesSinceBoot` | Total PRIVMSG/NOTICE messages sent since server start |
---
## Message Flow
### Channel Message Flow
```
Alice Server Bob
│ │ │
│ POST /messages │ │
│ {PRIVMSG, #gen, "hi"} │ │
│───────────────────────>│ │
│ │ 1. Store in messages │
│ │ 2. Query #gen members │
│ │ → [alice, bob] │
│ │ 3. Enqueue for alice │
│ │ 4. Enqueue for bob │
│ │ 5. Notify alice broker │
│ │ 6. Notify bob broker │
│ 201 {"status":"sent"} │ │
│<───────────────────────│ │
│ │ │
│ GET /messages?after=N │ GET /messages?after=M │
│ (long-poll wakes up) │ (long-poll wakes up) │
│───────────────────────>│<───────────────────────│
│ │ │
│ {messages: [{PRIVMSG, │ {messages: [{PRIVMSG, │
│ from:alice, "hi"}]} │ from:alice, "hi"}]} │
│<───────────────────────│───────────────────────>│
```
### DM Flow
```
Alice Server Bob
│ │ │
│ POST /messages │ │
│ {PRIVMSG, "bob", "yo"} │ │
│───────────────────────>│ │
│ │ 1. Resolve nick "bob" │
│ │ 2. Store in messages │
│ │ 3. Enqueue for bob │
│ │ 4. Enqueue for alice │
│ │ (echo to sender) │
│ │ 5. Notify both │
│ 201 {"status":"sent"} │ │
│<───────────────────────│ │
│ │ │
│ (alice sees her own DM │ (bob sees DM from │
│ on all her clients) │ alice) │
```
### JOIN Flow
```
Alice Server Bob (already in #gen)
│ │ │
│ POST /messages │ │
│ {JOIN, "#general"} │ │
│───────────────────────>│ │
│ │ 1. Get/create #general │
│ │ 2. Add alice to members│
│ │ 3. Store JOIN message │
│ │ 4. Fan out to all │
│ │ members (alice, bob) │
│ 200 {"joined"} │ │
│<───────────────────────│ │
│ │ │
│ (alice's queue gets │ (bob's queue gets │
│ JOIN from alice) │ JOIN from alice) │
```
---
## Canonicalization and Signing
Messages support optional cryptographic signatures for integrity verification.
Servers relay signatures verbatim without verifying them — verification is
purely a client-side concern.
### Canonicalization (RFC 8785 JCS)
To produce a deterministic byte representation of a message for signing:
1. Start with the full message envelope (including `id`, `ts`, `from`, etc.)
2. Remove `meta.sig` from the message (the signature itself is not signed)
3. Serialize using
[RFC 8785 JSON Canonicalization Scheme (JCS)](https://www.rfc-editor.org/rfc/rfc8785):
- Object keys sorted lexicographically (Unicode code point order)
- No insignificant whitespace
- Numbers serialized in shortest form (no trailing zeros)
- Strings escaped per JSON spec (no unnecessary escapes)
- UTF-8 encoding throughout
4. The resulting byte string is the signing input
**Example:**
Given this message:
```json
{
"command": "PRIVMSG",
"from": "alice",
"to": "#general",
"body": ["hello"],
"id": "abc-123",
"ts": "2026-02-10T20:00:00Z",
"meta": { "alg": "ed25519" }
}
```
The JCS canonical form is:
```
{"body":["hello"],"command":"PRIVMSG","from":"alice","id":"abc-123","meta":{"alg":"ed25519"},"to":"#general","ts":"2026-02-10T20:00:00Z"}
```
This is why `body` must be an object or array — raw strings would be ambiguous
under canonicalization (a bare string `hello` is not valid JSON, and `"hello"`
has different canonical forms depending on escaping rules).
### Signing Flow
1. Client generates an Ed25519 keypair (32-byte seed → 64-byte secret key,
32-byte public key)
2. Client announces public key via PUBKEY command:
```json
{
"command": "PUBKEY",
"body": { "alg": "ed25519", "key": "base64url-encoded-pubkey" }
}
```
3. Server relays PUBKEY to channel members and/or stores for the session
4. When sending a message, client: a. Constructs the complete message envelope
**without** `meta.sig` b. Canonicalizes per JCS (step above) c. Signs the
canonical bytes with the Ed25519 private key d. Adds `meta.sig`
(base64url-encoded signature) and `meta.alg` ("ed25519")
5. Server stores and relays the message including `meta` verbatim
6. Recipients verify by: a. Extracting and removing `meta.sig` from the received
message b. Canonicalizing the remaining message per JCS c. Verifying the
Ed25519 signature against the sender's announced public key
### PUBKEY Distribution
```json
{
"command": "PUBKEY",
"from": "alice",
"body": { "alg": "ed25519", "key": "base64url-encoded-32-byte-pubkey" }
}
```
- Servers relay PUBKEY messages to all channel members
- Clients cache public keys locally, indexed by (server, nick)
- Key distribution uses **TOFU** (trust on first use): the first key seen for a
nick is trusted; subsequent different keys trigger a warning
- **There is no key revocation mechanism** — if a key is compromised, the user
must change their nick or wait for the old key's TOFU cache to expire
### Signed Message Example
```json
{
"command": "PRIVMSG",
"from": "alice",
"to": "#general",
"body": ["this message is signed"],
"id": "7f5a04f8-eab4-4d2e-be55-f5cfcfaf43c5",
"ts": "2026-02-10T20:00:00.000000000Z",
"meta": {
"alg": "ed25519",
"sig": "base64url-encoded-64-byte-signature"
}
}
```
---
## Security Model
### Threat Model
The server is **trusted for metadata** (it knows who sent what, when, to whom)
but **untrusted for message integrity** (signatures let clients verify that
messages haven't been tampered with). This is the same trust model as email with
PGP/DKIM — the mail server sees everything, but signatures prove authenticity.
### Authentication
- **Cookie-based auth**: Opaque HttpOnly cookies (64 hex chars = 256 bits of
entropy). Cookie values are hashed (SHA-256) before storage and validated on
every request. Cookies are HttpOnly (no JavaScript access), SameSite=Strict
(CSRF protection), and Secure (sent only over HTTPS).
- **Anonymous sessions**: `POST /api/v1/session` requires only a nick. No
password, instant access. The auth cookie is the sole credential.
- **Password-protected sessions**: The PASS IRC command sets a bcrypt-hashed
password on the session. `POST /api/v1/login` authenticates against the stored
hash and issues a new client cookie.
- **Password security**: Passwords are never stored in plain text. bcrypt
handles salting and key stretching automatically. Sessions without a password
cannot be logged into via `/login`.
- **Cookie security**: Auth cookies should only be transmitted over HTTPS in
production. If a cookie is compromised, the attacker has full access to the
session until QUIT or expiry.
### Message Integrity
- **Optional signing**: Clients may sign messages using Ed25519. The server
relays signatures verbatim in the `meta` field.
- **Server does not verify signatures**: Verification is purely client-side.
This means the server cannot selectively reject forged messages, but it also
means the server cannot be compelled to enforce a signing policy.
- **Canonicalization**: Messages are canonicalized via RFC 8785 JCS before
signing, ensuring deterministic byte representation regardless of JSON
serialization differences between implementations.
### Key Management
- **TOFU (Trust On First Use)**: Clients trust the first public key they see for
a nick. This is the same model as SSH host keys. It's simple and works well
when users don't change keys frequently.
- **No key revocation**: Deliberate omission. Key revocation systems are complex
(CRLs, OCSP, key servers) and rarely work well in practice. If your key is
compromised, change your nick.
- **No CA / PKI**: There is no certificate authority. Identity is a key, not a
name bound to a key by a third party.
### DM Privacy
- **DMs are not end-to-end encrypted** in the current implementation. The server
can read DM content. E2E encryption for DMs is planned (see
[Roadmap](#roadmap)).
- **DMs are stored** in the messages table, subject to the same rotation policy
as channel messages.
### Transport Security
- **Clients need HTTPS to keep a session.** The auth cookie is always `Secure`,
and clients send a `Secure` cookie only over HTTPS. The server itself serves
plain HTTP — use a reverse proxy (nginx, Caddy, etc.) for TLS termination.
- **A server on `localhost`**, as in this document's examples, also works over
plain HTTP with curl, `neoirc-cli`, Chrome and Firefox, which treat
`localhost` as secure. Safari does not. Python's `requests` does not either,
so the [Python example](#implementing-long-poll-in-code) sends the cookie
itself.
- **CORS**: The server allows all origins with credentials
(`Access-Control-Allow-Credentials: true`), reflecting the request Origin.
This enables cookie-based auth from cross-origin clients. Restrict origins in
production via reverse proxy configuration if needed.
- **Content-Security-Policy**: The server sets a strict CSP header on all
responses, restricting resource loading to same-origin and disabling dangerous
features (object embeds, framing, base tag injection). The embedded SPA works
without `'unsafe-inline'` for scripts or styles.
---
## Federation (Server-to-Server)
Federation allows multiple neoirc servers to link together, forming a network
where users on different servers can share channels — similar to IRC server
linking.
**Status:** Not yet implemented. This section documents the design.
### Link Establishment
Server links are **manually configured** by operators. There is no
autodiscovery, no mesh networking, no DNS-based lookup. Operators on both
servers must agree to link and configure shared authentication credentials.
```
POST /api/v1/federation/link
{
"server_name": "peer.example.com",
"shared_key": "pre-shared-secret"
}
```
Both servers must configure the link. Authentication uses a pre-shared key
(hashed, never transmitted in plain text after initial setup).
### Message Relay
Once linked, servers relay messages using the same IRC envelope format:
```
POST /api/v1/federation/relay
{
"command": "PRIVMSG",
"from": "alice@server1.example.com",
"to": "#shared-channel",
"body": ["hello from server1"],
"meta": {"sig": "base64...", "alg": "ed25519"}
}
```
Key properties:
- **Signatures are relayed verbatim** — federated servers do not strip, modify,
or re-sign messages. A signature from a user on server1 can be verified by a
user on server2.
- **Nick namespacing**: In federated mode, nicks include a server suffix
(`nick@server`) to prevent collisions. Within a single server, bare nicks are
used.
### State Synchronization
After link establishment, servers exchange a **burst** of state:
1. `NICK` commands for all connected users
2. `JOIN` commands for all shared channel memberships
3. `TOPIC` commands for all channel topics
4. `MODE` commands for all channel modes
This mirrors IRC's server burst protocol.
### S2S Commands
| Command | Description |
| -------- | ---------------------------------- |
| `RELAY` | Relay a message from a remote user |
| `LINK` | Establish server link |
| `UNLINK` | Tear down server link |
| `SYNC` | Request full state synchronization |
| `PING` | Inter-server keepalive |
| `PONG` | Inter-server keepalive response |
### Federation Endpoints
```
POST /api/v1/federation/link — Establish server link
POST /api/v1/federation/relay — Relay messages between linked servers
GET /api/v1/federation/status — Link status and peer list
POST /api/v1/federation/unlink — Tear down a server link
```
---
## Storage
### Database
SQLite by default (single-file, zero-config). The server uses
[modernc.org/sqlite](https://pkg.go.dev/modernc.org/sqlite), a pure-Go SQLite
implementation — no CGO required, cross-compiles cleanly.
Postgres support is planned for larger deployments but not yet implemented.
### Schema
The database schema is managed via embedded SQL migration files in
`internal/db/schema/`. Migrations run automatically on server start.
**Current tables:**
#### `sessions`
| Column | Type | Description |
| --------------- | -------- | ------------------------------------------------------------- |
| `id` | INTEGER | Primary key (auto-increment) |
| `uuid` | TEXT | Unique session UUID |
| `nick` | TEXT | Unique nick |
| `username` | TEXT | IRC ident/username portion of the hostmask (defaults to nick) |
| `hostname` | TEXT | Reverse DNS hostname of the connecting client IP |
| `ip` | TEXT | Real IP address of the session creator |
| `is_oper` | INTEGER | Server operator (o-line) status (0 = no, 1 = yes) |
| `password_hash` | TEXT | bcrypt hash (empty string for anonymous sessions) |
| `signing_key` | TEXT | Public signing key (empty string if unset) |
| `away_message` | TEXT | Away message (empty string if not away) |
| `created_at` | DATETIME | Session creation time |
| `last_seen` | DATETIME | Last API request time |
Index on `(uuid)`.
#### `clients`
| Column | Type | Description |
| ------------ | -------- | ---------------------------------------------------------- |
| `id` | INTEGER | Primary key (auto-increment) |
| `uuid` | TEXT | Unique client UUID |
| `session_id` | INTEGER | FK → sessions.id (cascade delete) |
| `token` | TEXT | Auth cookie value (SHA-256 hash of the 64-hex-char cookie) |
| `ip` | TEXT | Real IP address of this client connection |
| `hostname` | TEXT | Reverse DNS hostname of this client connection |
| `created_at` | DATETIME | Client creation time |
| `last_seen` | DATETIME | Last API request time |
Indexes on `(token)` and `(session_id)`.
#### `channels`
| Column | Type | Description |
| -------------- | -------- | -------------------------------------------------- |
| `id` | INTEGER | Primary key (auto-increment) |
| `name` | TEXT | Unique channel name (e.g., `#general`) |
| `topic` | TEXT | Channel topic (default empty) |
| `topic_set_by` | TEXT | Nick of the user who set the topic (default empty) |
| `topic_set_at` | DATETIME | When the topic was last set |
| `created_at` | DATETIME | Channel creation time |
| `updated_at` | DATETIME | Last modification time |
#### `channel_members`
| Column | Type | Description |
| ------------ | -------- | --------------------------------- |
| `id` | INTEGER | Primary key (auto-increment) |
| `channel_id` | INTEGER | FK → channels.id (cascade delete) |
| `session_id` | INTEGER | FK → sessions.id (cascade delete) |
| `joined_at` | DATETIME | When the user joined |
Unique constraint on `(channel_id, session_id)`.
#### `messages`
| Column | Type | Description |
| ------------ | -------- | --------------------------------------------------------------- |
| `id` | INTEGER | Primary key (auto-increment). Internal ID for queue references. |
| `uuid` | TEXT | UUID v4, exposed to clients as the message `id` |
| `command` | TEXT | IRC command (`PRIVMSG`, `JOIN`, etc.) |
| `msg_from` | TEXT | Sender nick |
| `msg_to` | TEXT | Target (`#channel` or nick) |
| `params` | TEXT | JSON-encoded IRC-style positional parameters |
| `body` | TEXT | JSON-encoded body (array or object) |
| `meta` | TEXT | JSON-encoded metadata |
| `created_at` | DATETIME | Server timestamp |
Indexes on `(msg_to, id)` and `(created_at)`.
#### `client_queues`
| Column | Type | Description |
| ------------ | -------- | ------------------------------------------------------ |
| `id` | INTEGER | Primary key (auto-increment). Used as the poll cursor. |
| `client_id` | INTEGER | FK → clients.id (cascade delete) |
| `message_id` | INTEGER | FK → messages.id (cascade delete) |
| `created_at` | DATETIME | When the entry was queued |
Unique constraint on `(client_id, message_id)`. Index on `(client_id, id)`.
The `client_queues.id` is the monotonically increasing cursor used by
`GET /messages?after=<id>`. This is more reliable than timestamps (no clock skew
issues) and simpler than UUIDs (integer comparison vs. string comparison).
### Data Lifecycle
- **Messages**: Pruned automatically when older than `MESSAGE_MAX_AGE` (default
30 days).
- **Client output queue entries**: Pruned automatically when older than
`QUEUE_MAX_AGE` (default 30 days).
- **Channels**: Deleted when the last member leaves (ephemeral).
- **Sessions**: Both anonymous and password-protected sessions are deleted on
`QUIT` or when the last client logs out (`POST /api/v1/logout` with no
remaining clients triggers session cleanup). There is no distinction between
session types in the cleanup path — `handleQuit` and `cleanupUser` both call
`DeleteSession` unconditionally. Idle sessions are automatically expired after
`SESSION_IDLE_TIMEOUT` (default 30 days) — the server runs a background
cleanup loop that parts idle users from all channels, broadcasts QUIT, and
releases their nicks.
- **Clients**: Individual client auth cookies are invalidated on
`POST /api/v1/logout`. A session can have multiple clients; removing one
doesn't affect others. However, when the last client is removed (via logout),
the entire session is deleted — the user is parted from all channels, QUIT is
broadcast, and the nick is released.
---
## Configuration
All configuration is via environment variables, read by
[Viper](https://github.com/spf13/viper). A `.env` file in the working directory
is also loaded automatically via [godotenv](https://github.com/joho/godotenv).
| Variable | Type | Default | Description |
| ---------------------- | ------ | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `PORT` | int | `8080` | HTTP listen port |
| `DBURL` | string | `file:///var/lib/neoirc/state.db?_journal_mode=WAL` | SQLite connection string. For file-based: `file:///path/to/db.db?_journal_mode=WAL`. For in-memory (testing): `file::memory:?cache=shared`. |
| `DEBUG` | bool | `false` | Enable debug logging (verbose request/response logging) |
| `MESSAGE_MAX_AGE` | string | `720h` | Maximum age of messages as a Go duration string (e.g. `720h`, `24h`). Messages older than this are pruned. Default is 30 days. |
| `SESSION_IDLE_TIMEOUT` | string | `720h` | Session idle timeout as a Go duration string (e.g. `720h`, `24h`). Sessions with no activity for this long are expired and the nick is released. Default is 30 days. |
| `QUEUE_MAX_AGE` | string | `720h` | Maximum age of client output queue entries as a Go duration string (e.g. `720h`, `24h`). Entries older than this are pruned. Default is 30 days. |
| `MAX_MESSAGE_SIZE` | int | `4096` | Maximum message body size in bytes (planned enforcement) |
| `LONG_POLL_TIMEOUT` | int | `15` | Default long-poll timeout in seconds (client can override via query param, server caps at 30) |
| `MOTD` | string | `""` | Message of the day, shown to clients via `GET /api/v1/server` |
| `SERVER_NAME` | string | `""` | Server display name. Defaults to hostname if empty. |
| `FEDERATION_KEY` | string | `""` | Shared key for server federation linking (planned) |
| `SENTRY_DSN` | string | `""` | Sentry error tracking DSN (optional) |
| `METRICS_USERNAME` | string | `""` | Basic auth username for `/metrics` endpoint. If empty, metrics endpoint is disabled. |
| `METRICS_PASSWORD` | string | `""` | Basic auth password for `/metrics` endpoint |
| `NEOIRC_HASHCASH_BITS` | int | `20` | Required hashcash proof-of-work difficulty (leading zero bits in SHA-256) for session creation. Set to `0` to disable. |
| `NEOIRC_OPER_NAME` | string | `""` | Server operator (o-line) username. Both name and password must be set to enable OPER. |
| `NEOIRC_OPER_PASSWORD` | string | `""` | Server operator (o-line) password. Both name and password must be set to enable OPER. |
| `LOGIN_RATE_LIMIT` | float | `1` | Allowed login attempts per second per IP address. |
| `LOGIN_RATE_BURST` | int | `5` | Maximum burst of login attempts per IP before rate limiting kicks in. |
| `IRC_LISTEN_ADDR` | string | `:6667` | TCP address for the traditional IRC protocol listener. Set to empty string to disable. |
| `MAINTENANCE_MODE` | bool | `false` | Maintenance mode flag (reserved) |
### Example `.env` file
```bash
PORT=8080
SERVER_NAME=My NeoIRC Server
MOTD=Welcome! Be excellent to each other.
DEBUG=false
DBURL=file:///var/lib/neoirc/state.db?_journal_mode=WAL
SESSION_IDLE_TIMEOUT=720h
NEOIRC_HASHCASH_BITS=20
```
---
## IRC Protocol Listener
neoirc includes an optional traditional IRC wire protocol listener (RFC
1459/2812) that allows standard IRC clients to connect directly. This enables
backward compatibility with existing IRC clients like irssi, weechat, hexchat,
and others.
### Configuration
The IRC listener is **enabled by default** on `:6667`. To disable it, set
`IRC_LISTEN_ADDR` to an empty string:
```bash
IRC_LISTEN_ADDR=
```
### Supported Commands
| Category | Commands |
| ---------- | ------------------------------------------------------------------ |
| Connection | `NICK`, `USER`, `PASS`, `QUIT`, `PING`/`PONG`, `CAP` |
| Channels | `JOIN`, `PART`, `MODE`, `TOPIC`, `NAMES`, `LIST`, `KICK`, `INVITE` |
| Messaging | `PRIVMSG`, `NOTICE` |
| Info | `WHO`, `WHOIS`, `LUSERS`, `MOTD`, `AWAY` |
| Operator | `OPER` (requires `NEOIRC_OPER_NAME` and `NEOIRC_OPER_PASSWORD`) |
### Protocol Details
- **Wire format**: CR-LF delimited lines, max 512 bytes per line
- **Connection registration**: Clients must send `NICK` and `USER` to register.
An optional `PASS` before registration sets the session password (minimum 8
characters).
- **CAP negotiation**: `CAP LS` and `CAP END` are silently handled for
compatibility with modern clients. No capabilities are advertised.
- **Channel prefixes**: Channels must start with `#`. If omitted, it's
automatically prepended.
- **First joiner**: The first user to join a channel is automatically granted
operator status (`@`).
- **Channel modes**: `+m` (moderated), `+t` (topic lock), `+o` (operator), `+v`
(voice)
### Bridge to HTTP API
Messages sent by IRC clients appear in channels visible to HTTP/JSON API clients
and vice versa. The IRC listener and HTTP API share the same database, broker,
and session infrastructure. A user connected via IRC and a user connected via
the HTTP API can communicate in the same channels seamlessly.
### Docker Usage
To expose the IRC port in Docker (the listener is enabled by default on
`:6667`):
```bash
docker run -d \
-p 8080:8080 \
-p 6667:6667 \
-v neoirc-data:/var/lib/neoirc \
neoirc
```
---
## Entrypoints
This repository adheres to the
[Scripts to Rule Them All](https://github.com/github/scripts-to-rule-them-all)
standard. Each script below has a `make` target of the same name that calls it,
except `script/install-precommit`, which is `make hooks`, and `script/cibuild`,
`script/precommit` and `script/projectname`, which have none.
- `script/bootstrap`: installs what development needs: make, git, Node and yarn
(for prettier), and Go.
- `script/setup`: makes a fresh clone ready for development: runs
`script/bootstrap`, then `script/install-precommit`.
- `script/test`: builds the `Dockerfile`'s `test` phase, which runs the tests
with `-race`.
- `script/lint`: builds the `Dockerfile`'s `lint` phase, which runs
golangci-lint.
- `script/fmt`: formats the Go code with gofmt and the Markdown with prettier.
- `script/fmt-check`: the same, read-only; fails if anything would change.
- `script/check`: runs `script/test`, `script/lint` and `script/fmt-check`.
- `script/docker`: builds the image, tagged `neoirc`.
- `script/cibuild`: the CI build: `script/bootstrap`, `script/check`, then the
image.
- `script/precommit`: run by the git pre-commit hook: fails if `go mod tidy`
changes `go.mod` or `go.sum`, then runs `script/check`.
- `script/install-precommit`: installs that hook.
- `script/projectname`: prints the project name, `neoirc`.
---
## Deployment
### Docker (Recommended)
The Docker image contains a single static binary (`neoircd`) and nothing else.
```bash
# Build
make docker
# Run
docker run -p 8080:8080 \
-v neoirc-data:/var/lib/neoirc \
-e SERVER_NAME="My Server" \
-e MOTD="Welcome!" \
neoirc
```
The Dockerfile is a five-stage build:
1. **web-builder**: Installs Node dependencies and compiles the SPA (JSX →
bundled JS via esbuild) into `web/dist/`
2. **lint**: Runs golangci-lint against the Go source (uses empty placeholder
files for `web/dist/` so it runs independently of web-builder for fast
feedback)
3. **test**: Runs the tests with `-race` on the Debian Go image, with the same
placeholder files
4. **builder**: Runs only once lint and test have passed; compiles static
`neoircd` and `neoirc-cli` binaries with the real SPA assets from web-builder
(CLI built to verify compilation, not included in final image)
5. **final**: Minimal Alpine image with only the `neoircd` binary
### Binary
```bash
# Build from source
make build
# Binary at ./bin/neoircd
# Run
./bin/neoircd
# Listens on :8080, writes to /var/lib/neoirc/state.db
```
### Reverse Proxy (Production)
For production, run behind a TLS-terminating reverse proxy.
**Caddy:**
```
neoirc.example.com {
reverse_proxy localhost:8080
}
```
**nginx:**
```nginx
server {
listen 443 ssl;
server_name neoirc.example.com;
ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/key.pem;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_read_timeout 60s; # Must be > long-poll timeout
}
}
```
**Important:** Set `proxy_read_timeout` (nginx) or equivalent to at least 60
seconds to accommodate long-poll connections.
### SQLite Considerations
- **WAL mode** is enabled by default (`?_journal_mode=WAL` in the connection
string). This allows concurrent reads during writes.
- **Single writer**: SQLite allows only one writer at a time. For high-traffic
servers, Postgres support is planned.
- **Backup**: The database is a single file. Back it up with
`sqlite3 /var/lib/neoirc/state.db ".backup backup.db"` or just copy the file
(safe with WAL mode).
- **Location**: By default, `state.db` is created in `/var/lib/neoirc/`. Use the
`DBURL` env var to place it elsewhere.
---
## Client Development Guide
This section explains how to write a client against the neoirc API. The API is
designed to be simple enough that a basic client can be written in any language
with an HTTP client library.
### Minimal Client Loop
A complete client needs only four HTTP calls:
```
1. POST /api/v1/session → get auth cookie
2. POST /api/v1/messages (JOIN) → join channels
3. GET /api/v1/messages (loop) → receive messages
4. POST /api/v1/messages → send messages
```
### Step-by-Step with curl
```bash
# 1a. Create a session (cookie saved automatically with -c)
curl -s -c cookies.txt -X POST http://localhost:8080/api/v1/session \
-H 'Content-Type: application/json' \
-d '{"nick":"testuser"}'
# 1b. Optionally set a password for multi-client access
curl -s -b cookies.txt -X POST http://localhost:8080/api/v1/messages \
-H 'Content-Type: application/json' \
-d '{"command":"PASS","body":["mypassword"]}'
# 1c. Login from another device (saves new cookie)
curl -s -c cookies2.txt -X POST http://localhost:8080/api/v1/login \
-H 'Content-Type: application/json' \
-d '{"nick":"testuser","password":"mypassword"}'
# 2. Join a channel
curl -s -b cookies.txt -X POST http://localhost:8080/api/v1/messages \
-H 'Content-Type: application/json' \
-d '{"command":"JOIN","to":"#general"}'
# 3. Send a message
curl -s -b cookies.txt -X POST http://localhost:8080/api/v1/messages \
-H 'Content-Type: application/json' \
-d '{"command":"PRIVMSG","to":"#general","body":["hello from curl!"]}'
# 4. Poll for messages (one-shot)
curl -s -b cookies.txt "http://localhost:8080/api/v1/messages?after=0&timeout=0" | jq .
# 5. Long-poll (blocks up to 15s waiting for messages)
curl -s -b cookies.txt "http://localhost:8080/api/v1/messages?after=0&timeout=15" | jq .
# 6. Send a DM
curl -s -b cookies.txt -X POST http://localhost:8080/api/v1/messages \
-H 'Content-Type: application/json' \
-d '{"command":"PRIVMSG","to":"othernick","body":["hey!"]}'
# 7. Change nick
curl -s -b cookies.txt -X POST http://localhost:8080/api/v1/messages \
-H 'Content-Type: application/json' \
-d '{"command":"NICK","body":["newnick"]}'
# 8. Set channel topic
curl -s -b cookies.txt -X POST http://localhost:8080/api/v1/messages \
-H 'Content-Type: application/json' \
-d '{"command":"TOPIC","to":"#general","body":["New topic!"]}'
# 9. Leave a channel
curl -s -b cookies.txt -X POST http://localhost:8080/api/v1/messages \
-H 'Content-Type: application/json' \
-d '{"command":"PART","to":"#general","body":["goodbye"]}'
# 10. Disconnect
curl -s -b cookies.txt -X POST http://localhost:8080/api/v1/messages \
-H 'Content-Type: application/json' \
-d '{"command":"QUIT","body":["leaving"]}'
```
### Implementing Long-Poll in Code
The key to real-time messaging is the poll loop. Here's the pattern:
```python
# Python example — using requests.Session for cookie handling
import requests, json, time
BASE = "http://localhost:8080/api/v1"
session = requests.Session()
last_id = 0
# Create session (the server sets the auth cookie via Set-Cookie)
resp = session.post(f"{BASE}/session", json={"nick": "pybot"})
print(f"Session: {resp.json()}")
# The auth cookie is Secure, and requests sends it only over HTTPS.
# For a plain-HTTP server on localhost, send it on every request:
session.headers["Cookie"] = f"neoirc_auth={resp.cookies['neoirc_auth']}"
# Join channel
session.post(f"{BASE}/messages",
json={"command": "JOIN", "to": "#general"})
# Poll loop
while True:
try:
resp = session.get(f"{BASE}/messages",
params={"after": last_id, "timeout": 15},
timeout=20) # HTTP timeout > long-poll timeout
data = resp.json()
if data.get("last_id"):
last_id = data["last_id"]
for msg in data.get("messages", []):
print(f"[{msg['command']}] <{msg.get('from','')}> "
f"{' '.join(msg.get('body', []))}")
except requests.exceptions.Timeout:
continue # Normal — just re-poll
except Exception as e:
print(f"Error: {e}")
time.sleep(2) # Back off on errors
```
```javascript
// JavaScript/browser example — cookies sent automatically
async function pollLoop() {
let lastId = 0;
while (true) {
try {
const resp = await fetch(
`/api/v1/messages?after=${lastId}&timeout=15`,
{ credentials: "same-origin" }, // Include cookies
);
if (resp.status === 401) {
/* session expired */ break;
}
const data = await resp.json();
if (data.last_id) lastId = data.last_id;
for (const msg of data.messages || []) {
handleMessage(msg);
}
} catch (e) {
await new Promise((r) => setTimeout(r, 2000)); // back off
}
}
}
```
### Handling Message Types
Clients should handle these message commands from the queue:
| Command | Display As |
| --------- | ---------------------------------------------------------- |
| `PRIVMSG` | `<nick> message text` |
| `NOTICE` | `-nick- message text` (do not auto-reply) |
| `JOIN` | `*** nick has joined #channel` |
| `PART` | `*** nick has left #channel (reason)` |
| `QUIT` | `*** nick has quit (reason)` |
| `NICK` | `*** oldnick is now known as newnick` |
| `TOPIC` | `*** nick set topic: new topic` |
| Numerics | Display body text (e.g., welcome messages, error messages) |
### Error Handling
- **HTTP 401**: Auth cookie expired or invalid. Re-create session or re-login
(if a password was set).
- **HTTP 404**: Channel or user not found.
- **HTTP 409**: Nick already taken (on session creation or NICK change).
- **HTTP 400**: Malformed request. Check the `error` field in the response.
- **Network errors**: Back off exponentially (1s, 2s, 4s, ..., max 30s).
### Tips for Client Authors
1. **Set HTTP timeout > long-poll timeout**: If your long-poll timeout is 15s,
set your HTTP client timeout to at least 20s to avoid cutting off valid
responses.
2. **Always use `after` parameter**: Start with `after=0`, then use `last_id`
from each response. Never reset to 0 unless you want to re-read history.
3. **Handle your own echoed messages**: Channel messages and DMs are echoed back
to the sender. Your client will receive its own messages. Either deduplicate
by `id` or show them (which confirms delivery).
4. **DM tab logic**: When you receive a PRIVMSG where `to` is not a channel (no
`#` prefix), the DM tab should be keyed by the **other** user's nick: if
`from` is you, use `to`; if `from` is someone else, use `from`.
5. **Reconnection**: If the poll loop fails with 401, the auth cookie is
invalid. For sessions without a password, create a new session. For sessions
with a password set (via PASS command), log in again via `POST /api/v1/login`
to get a fresh cookie on the same session. If it fails with a network error,
retry with backoff.
---
## Rate Limiting & Abuse Prevention
### Hashcash Proof-of-Work
Session creation (`POST /api/v1/session`) requires a
[hashcash](https://en.wikipedia.org/wiki/Hashcash)-style proof-of-work token.
This is the primary defense against resource exhaustion — no CAPTCHAs, no
account registration, no IP-based rate limits that punish shared networks.
### How It Works
1. Client fetches server info: `GET /api/v1/server` returns a `hashcash_bits`
field (e.g., `20`) indicating the required difficulty.
2. Client computes a hashcash stamp: find a counter value such that the SHA-256
hash of the stamp string has the required number of leading zero bits.
3. Client includes the stamp in the `pow_token` field of the JSON request body
when creating a session: `POST /api/v1/session`.
4. Server validates the stamp:
- Version is `1`
- Claimed bits ≥ required bits
- Resource matches the server name
- Date is within 48 hours (not expired, not too far in the future)
- SHA-256 hash has the required leading zero bits
- Stamp has not been used before (replay prevention)
### Stamp Format
Standard hashcash format:
```
1:bits:date:resource::counter
```
| Field | Description |
| ---------- | ----------------------------------------------------------------- |
| `1` | Version (always `1`) |
| `bits` | Claimed difficulty (must be ≥ server's `hashcash_bits`) |
| `date` | Date stamp in `YYMMDD` or `YYMMDDHHMMSS` format (UTC) |
| `resource` | The server name (from `GET /api/v1/server`; defaults to `neoirc`) |
| (empty) | Extension field (unused) |
| `counter` | Hex counter value found by the client to satisfy the PoW |
**Example stamp:** `1:20:260310:neoirc::3a2f1b`
The SHA-256 hash of this entire string must have at least 20 leading zero bits.
### Computing a Stamp
```bash
# Pseudocode
bits = 20
resource = "neoirc"
date = "260310" # YYMMDD in UTC
counter = 0
loop:
stamp = "1:{bits}:{date}:{resource}::{hex(counter)}"
hash = SHA-256(stamp)
if leading_zero_bits(hash) >= bits:
return stamp
counter++
```
At difficulty 20, this requires approximately 2^20 (~1M) hash attempts on
average, taking roughly 0.5–2 seconds on modern hardware.
### Client Integration
Both the embedded web SPA and the CLI client automatically handle hashcash:
1. Fetch `GET /api/v1/server` to read `hashcash_bits`
2. If `hashcash_bits > 0`, compute a valid stamp
3. Include the stamp in the `pow_token` field of the JSON body on
`POST /api/v1/session`
The web SPA uses the Web Crypto API (`crypto.subtle.digest`) for SHA-256
computation with batched parallelism. The CLI client uses Go's `crypto/sha256`.
### Configuration
Set `NEOIRC_HASHCASH_BITS` to control difficulty:
| Value | Effect | Approx. Client CPU |
| ----- | ------------------------------------ | ------------------ |
| `0` | Disabled (no proof-of-work required) | — |
| `16` | Light protection | ~1ms |
| `20` | Default — good balance | ~0.5–2s |
| `24` | Strong protection | ~10–30s |
| `28` | Very strong (may frustrate users) | ~2–10min |
Each additional bit doubles the expected work. An attacker creating 1000
sessions at difficulty 20 needs ~1000–2000 CPU-seconds; a legitimate user
creating one session pays once and keeps their session.
### Why Hashcash and Not Rate Limits?
- **No state to track**: No IP tables, no token buckets, no sliding windows. The
server only needs to verify a single hash.
- **Works through NATs and proxies**: Doesn't punish shared IPs (university
campuses, corporate networks, Tor exits). Every client computes their own
proof independently.
- **Cost falls on the requester**: The server's verification cost is constant
(one SHA-256 hash) regardless of difficulty. Only the client does more work.
- **Fits the "no accounts" philosophy**: Proof-of-work is the cost of entry. No
registration, no email, no phone number, no CAPTCHA. Just compute.
- **Language-agnostic**: SHA-256 is available in every programming language. The
proof computation is trivially implementable in any client.
### Login Rate Limiting
The login endpoint (`POST /api/v1/login`) has per-IP rate limiting to prevent
brute-force password attacks. This uses a token-bucket algorithm
(`golang.org/x/time/rate`) with configurable rate and burst.
| Environment Variable | Default | Description |
| -------------------- | ------- | ---------------------------------------- |
| `LOGIN_RATE_LIMIT` | `1` | Allowed login attempts per second per IP |
| `LOGIN_RATE_BURST` | `5` | Maximum burst of login attempts per IP |
When the limit is exceeded, the server returns **429 Too Many Requests** with a
`Retry-After: 1` header. Stale per-IP entries are automatically cleaned up every
10 minutes.
> **⚠️ Security: Reverse Proxy Required for Production Use**
>
> The rate limiter extracts the client IP by checking the `X-Forwarded-For`
> header first, then `X-Real-IP`, and finally falling back to the TCP
> `RemoteAddr`. Both `X-Forwarded-For` and `X-Real-IP` are **client-controlled
> request headers** — any client can set them to arbitrary values.
>
> Without a properly configured reverse proxy in front of this server:
>
> - An attacker can **bypass rate limiting entirely** by rotating
> `X-Forwarded-For` values on each request (each value is treated as a
> distinct IP).
> - An attacker can **deny service to a specific user** by spoofing that user's
> IP in the `X-Forwarded-For` header, exhausting their rate limit bucket.
>
> **Recommendation:** Always deploy behind a reverse proxy (e.g. nginx, Caddy,
> Traefik) that strips or overwrites incoming `X-Forwarded-For` and `X-Real-IP`
> headers with the actual client IP. If running without a reverse proxy, be
> aware that the rate limiting provides no meaningful protection against a
> targeted attack.
**Why rate limits here but not on session creation?** Session creation is
protected by hashcash proof-of-work (stateless, no IP tracking needed). Login
involves bcrypt password verification against a registered account — a
fundamentally different threat model where an attacker targets a specific
account. Per-IP rate limiting is appropriate here because the cost of a wrong
guess is borne by the server (bcrypt), not the client.
---
## Roadmap
### Implemented (MVP)
- [x] Session creation with nick claim
- [x] All core commands: PRIVMSG, JOIN, PART, NICK, TOPIC, QUIT, PING
- [x] IRC message envelope format (command, from, to, body, ts, meta)
- [x] Per-client delivery queues with fan-out
- [x] Long-polling with in-memory broker
- [x] Channel messages and DMs
- [x] Ephemeral channels (deleted when empty)
- [x] NICK change with broadcast
- [x] QUIT with broadcast and cleanup
- [x] Embedded web SPA client
- [x] CLI client (neoirc-cli)
- [x] SQLite storage with WAL mode
- [x] Docker deployment
- [x] Prometheus metrics endpoint
- [x] Health check endpoint
- [x] Session expiry — auto-expire idle sessions, release nicks
- [x] Logout endpoint (`POST /api/v1/logout`)
- [x] Current user endpoint (`GET /api/v1/users/me`)
- [x] User count in server info (`GET /api/v1/server`)
### Post-MVP (Planned)
- [x] **Hashcash proof-of-work** for session creation (abuse prevention)
- [x] **Client output queue pruning** — delete old client output queue entries
per `QUEUE_MAX_AGE`
- [x] **Message rotation** — prune messages older than `MESSAGE_MAX_AGE`
- [x] **Channel modes** — enforce `+m` (moderated), `+t` (topic lock), `+n` (no
external)
- [x] **Channel modes (tier 2)** — enforce `+i` (invite-only), `+s` (secret),
`+b` (ban), `+k` (key), `+l` (limit)
- [x] **User channel modes** — `+o` (operator), `+v` (voice) with NAMES prefixes
- [x] **KICK command** — operator-only channel kick with broadcast
- [x] **MODE command** — query and set channel/user modes
- [x] **NAMES command** — query channel member list with @/+ prefixes
- [x] **LIST command** — list all channels with member counts
- [x] **WHOIS command** — query user information and channel membership
- [x] **WHO command** — query channel user list
- [x] **LUSERS command** — query server statistics
- [x] **Connection registration numerics** — 001-005 sent on session creation
- [x] **LUSERS numerics** — 251/252/254/255 sent on connect and via /LUSERS
- [x] **KICK command** — remove users from channels (operator-only)
- [x] **Numeric replies** — send IRC numeric codes via the message queue
(001-005 welcome, 251-255 LUSERS, 311-319 WHOIS, 322-329 LIST/MODE,
331-332 TOPIC, 352-353 WHO/NAMES, 366, 372-376 MOTD, 401-461 errors)
- [ ] **Max message size enforcement** — reject oversized messages
- [ ] **NOTICE command** — distinct from PRIVMSG (no auto-reply flag)
- [x] **Multi-client sessions** — set a password via PASS command, then login
from additional devices via `POST /api/v1/login`
- [x] **Cookie-based auth** — HttpOnly cookies replace Bearer tokens for all API
authentication
### Future (1.0+)
- [ ] **PUBKEY command** — public key distribution
- [ ] **Message signing** — Ed25519 signatures with JCS canonicalization
- [ ] **TOFU key management** — client-side key caching and verification
- [ ] **E2E encryption for DMs** — end-to-end encrypted direct messages using
X25519 key exchange
- [ ] **Federation** — server-to-server linking, message relay, state sync
- [ ] **Postgres support** — for high-traffic deployments
- [ ] **Image/file upload** — inline media via a separate upload endpoint,
referenced in message `meta`
- [ ] **Push notifications** — optional webhook/push for mobile clients when
messages arrive during disconnect
- [ ] **Message search** — full-text search over channel history
- [x] **User info command** — WHOIS for querying user info and channels
- [ ] **Connection flood protection** — per-IP connection limits as a complement
to hashcash
- [ ] **Invite system** — `INVITE` command for `+i` channels
- [ ] **Ban system** — channel-level bans by nick pattern
---
## Project Structure
Following
[gohttpserver CONVENTIONS.md](https://git.eeqj.de/sneak/gohttpserver/src/branch/main/CONVENTIONS.md):
```
neoirc/
├── cmd/
│ ├── neoircd/ # Server binary entry point
│ │ └── main.go
│ └── neoirc-cli/ # TUI client entry point
│ └── main.go # Minimal bootstrapping (calls internal/cli)
├── internal/
│ ├── broker/ # In-memory pub/sub for long-poll notifications
│ │ └── broker.go
│ ├── cli/ # TUI client implementation
│ │ ├── app.go # App struct, command handling, poll loop
│ │ ├── ui.go # tview-based terminal UI
│ │ └── api/
│ │ ├── client.go # HTTP API client library
│ │ ├── types.go # Request/response types
│ │ └── hashcash.go # Hashcash proof-of-work minting
│ ├── config/ # Viper-based configuration
│ │ └── config.go
│ ├── db/ # Database access and migrations
│ │ ├── db.go # Connection, migration runner
│ │ ├── queries.go # All SQL queries and data types
│ │ └── schema/
│ │ └── 001_initial.sql
│ ├── globals/ # Application-wide metadata
│ │ └── globals.go
│ ├── handlers/ # HTTP request handlers
│ │ ├── handlers.go # Deps, JSON response helper
│ │ ├── api.go # All API endpoint handlers
│ │ └── healthcheck.go # Health check handler
│ ├── healthcheck/ # Health check logic
│ │ └── healthcheck.go
│ ├── stats/ # Runtime statistics (atomic counters)
│ │ └── stats.go
│ ├── logger/ # slog-based logging
│ │ └── logger.go
│ ├── middleware/ # HTTP middleware (logging, CORS, metrics, auth)
│ │ └── middleware.go
│ └── server/ # HTTP server, routing, lifecycle
│ ├── server.go # fx lifecycle, Sentry, signal handling
│ ├── routes.go # chi router setup, all routes
│ └── http.go # HTTP timeouts
├── web/
│ ├── embed.go # go:embed directive for SPA
│ ├── build.sh # SPA build script (esbuild, runs in Docker)
│ ├── package.json # Node dependencies (preact, esbuild)
│ ├── package-lock.json
│ ├── src/ # SPA source files (JSX + HTML + CSS)
│ │ ├── app.jsx
│ │ ├── index.html
│ │ └── style.css
│ └── dist/ # Generated at Docker build time (not committed)
├── schema/ # JSON Schema definitions (planned)
├── script/ # Entrypoints that the Makefile targets call
├── go.mod
├── go.sum
├── package.json # prettier, for make fmt and make fmt-check
├── Makefile
├── Dockerfile
├── CONVENTIONS.md
└── README.md
```
### Required Libraries
| Purpose | Library |
| ---------- | ------------------------------------------------------- |
| DI | `go.uber.org/fx` |
| Router | `github.com/go-chi/chi` |
| Logging | `log/slog` (stdlib) |
| Config | `github.com/spf13/viper` |
| Env | `github.com/joho/godotenv/autoload` |
| CORS | `github.com/go-chi/cors` |
| Metrics | `github.com/prometheus/client_golang` |
| DB | `modernc.org/sqlite` + `database/sql` |
| UUIDs | `github.com/google/uuid` |
| Errors | `github.com/getsentry/sentry-go` (optional) |
| TUI Client | `github.com/rivo/tview` + `github.com/gdamore/tcell/v2` |
---
## Design Principles
1. **API-first** — the HTTP API is the product. Clients are thin. If you can't
build a working IRC-style TUI client against this API in an afternoon, the
API is too complex.
2. **Passwords optional** — anonymous sessions are instant: pick a nick and
talk. No registration, no email verification. The cost of entry is a hashcash
proof, not bureaucracy. For users who want multi-client access (multiple
devices sharing one session), the PASS command sets a password on the session
— but it's never required. Identity verification at the message layer uses
cryptographic signing, independent of password status.
3. **IRC semantics over HTTP** — command names and numeric codes from RFC
1459/2812. If you've built an IRC client or bot, you already know the command
vocabulary. The only new things are the JSON encoding and the HTTP transport.
4. **HTTP is the only transport** — no WebSockets, no raw TCP, no protocol
negotiation. HTTP is universal, proxy-friendly, CDN-friendly, and works on
every device and network. Long-polling provides real-time delivery without
any of the complexity of persistent connections.
5. **Server holds state** — clients are stateless. Reconnect, switch devices,
lose connectivity for hours — your messages are waiting in your client queue.
The server is the source of truth for session state, channel membership, and
message history.
6. **Structured messages** — JSON with extensible metadata. Bodies are always
objects or arrays, never raw strings. This enables deterministic
canonicalization (JCS) for signing and multiline messages without escape
sequences.
7. **Immutable messages** — no editing, no deletion. Ever. This fits naturally
with cryptographic signatures and creates a trustworthy audit trail. IRC
culture already handles corrections inline ("s/typo/fix/").
8. **Simple deployment** — single binary, SQLite default, zero mandatory
external dependencies. `docker run` and you're done. No Redis, no RabbitMQ,
no Kubernetes, no configuration management.
9. **No eternal logs** — history rotates. Chat should be ephemeral by default.
Channels disappear when empty. Sessions expire when idle. The server does not
aspire to be an archive.
10. **Federation optional** — a single server works standalone. Linking is
manual and opt-in, like IRC. There is no requirement to participate in a
network.
11. **Signable messages** — optional Ed25519 signatures with TOFU key
distribution. Servers relay signatures without verification. Trust decisions
are made by clients, not servers.
12. **No magic** — the protocol has no special cases, no content-type
negotiation, no feature flags. Every message uses the same envelope. Every
command goes through the same endpoint. The simplest implementation is also
the correct one.
---
## Status
**Implementation in progress.** Core API is functional with:
- SQLite storage with WAL mode
- All core IRC commands (PRIVMSG, JOIN, PART, NICK, TOPIC, QUIT, PING)
- IRC message envelope format with per-client queue fan-out
- Long-polling with in-memory broker
- Embedded web SPA client
- TUI client (neoirc-cli)
- Docker image
- Prometheus metrics
See [Roadmap](#roadmap) for what's next.
---
## License
MIT
## Author
[@sneak](https://sneak.berlin)
Reference in New Issue View Git Blame Copy Permalink