# IRCv3 capabilities

Clients negotiate capabilities with `CAP LS` / `CAP REQ`. echoIRCd advertises the following.
`draft/multiline`, `sasl`, and `draft/account-registration` carry `=`-value parameters (limits, the
SASL mechanism list, enabled sub-features) to CAP-302 clients.

## Ratified

| Capability | Meaning |
| --- | --- |
| `sasl` | SASL authentication (mechanism list attached for CAP 302) |
| `server-time` | A `time=` tag with each message's server timestamp |
| `message-tags` | Generic message-tag support, including relaying client `+` tags |
| `multi-prefix` | Show all of a member's status prefixes in NAMES/WHO |
| `away-notify` | Real-time AWAY / back notifications |
| `account-notify` | Notify when a user logs in/out of an account |
| `extended-join` | JOIN carries the account name and realname |
| `chghost` | Real-time host/ident change notifications |
| `userhost-in-names` | Full `nick!user@host` in NAMES |
| `echo-message` | Echo the sender's own PRIVMSG/NOTICE back |
| `invite-notify` | Notify channel ops when a user is invited |
| `setname` | Real-time realname change notifications |
| `extended-monitor` | MONITOR reflects extended state changes |
| `account-tag` | An `account=` tag identifying the sender's account |
| `standard-replies` | Structured `FAIL` / `WARN` / `NOTE` replies |
| `labeled-response` | Correlate a command with its response via `label` |
| `batch` | Group related messages into a `BATCH` |
| `cap-notify` | Tell the client when caps are added/removed |

## Draft & vendor

| Capability | Meaning |
| --- | --- |
| `draft/chathistory` | Request replay of past channel/DM messages |
| `draft/event-playback` | Include channel events (JOIN/PART/QUIT/NICK/MODE/TOPIC/KICK) in history |
| `draft/message-redaction` | `REDACT` a previously-sent message |
| `draft/pre-away` | Set AWAY during registration |
| `draft/metadata-2` | Per-user/channel arbitrary metadata |
| `draft/multiline` | Send one logical message across multiple lines |
| `draft/account-registration` | In-band account `REGISTER` / `VERIFY` |
| `draft/json-log` | Structured JSON tag on server notices (opers) |
| `draft/extended-isupport` | Re-request ISUPPORT (005) tokens on demand |
| `draft/relaymsg` | Send channel messages under a spoofed relay nick (bridges) |
| `draft/channel-rename` | Rename a channel in place (`RENAME`) |
| `draft/read-marker` | Per-conversation read-marker sync across devices |
| `draft/webpush` | Web Push subscription for backgrounded/away notifications |
| `draft/filehost` | Advertise an external file-host + signed upload links |
| `no-implicit-names` | Suppress the automatic NAMES burst on JOIN |

## Notable capabilities

A few of these do more than the one-line table can show.

### Channel rename

The `draft/channel-rename` capability lets a channel **operator** rename a channel in place, keeping
its membership, modes, topic, bans and timestamp:

```text
RENAME <#old> <#new> [<reason>]
```

Members whose client negotiated the capability get a single `RENAME` message and stay in the channel
seamlessly. Members without it are moved with an automatic **PART + JOIN** (topic and names
preserved), so their client follows the channel too. A change that only alters the *case* of the name
needs no move at all.

The server enforces a few rules:

- you must be a channel **operator** (or an IRC operator);
- the channel **prefix** can't change (`#foo` → `&foo` is refused);
- the new name must be valid and **not already in use**, and can't be `CBAN`'d (operators bypass that);
- a **registered (`+r`) channel** is owned by services — a client can't rename it; ask ChanServ
  (`/msg ChanServ RENAME <#channel> <#newname>`), which does it over the server link. Operators may
  rename registered channels directly.

Failures come back as standard replies, e.g. `FAIL RENAME CANNOT_RENAME …` or
`FAIL RENAME CHANNEL_NAME_IN_USE …`.

### Message history

`draft/chathistory` replays a channel's or DM's recent messages from the server's per-conversation
store (the `CHATHISTORY` command). With `draft/event-playback` the replay also carries
JOIN/PART/QUIT/NICK/MODE/TOPIC/KICK events, so a reconnecting client rebuilds the whole picture.

### Multiline messages

`draft/multiline` sends a message that spans several lines as one logical message, wrapped in a
`BATCH`; the advertised `max-bytes` / `max-lines` limits are configurable.

### Web Push

`draft/webpush` registers an RFC 8291 / 8292 subscription (the `WEBPUSH` command) so a highlight or
private message reaches a client whose tab is backgrounded or away — even when it isn't connected.

### STS

`sts` advertises a strict-transport-security policy on the plaintext port so capable clients upgrade
to TLS and pin it for a configured duration.

For SASL mechanisms, see [Accounts & SASL](/docs/accounts).