IRCv3 Capabilities we support
UnitedChat, thanks to the use of the latest InspIRCd 3 software, uses alot of the new IRCv3 capabilities that are being created by the IRCv3 Working Group. These capabilities are designed to improve the IRC protocol which was initially release in 1988.
| Capability | Description |
|---|---|
| CAP | Client Capability Negotiation allows IRC clients and servers to negotiate new features in a backwards-compatible way – even features that change how the protocol works in deep and extensive ways. |
| CAP 302 | As above, but the client also implicitly supports cap-notify and additional data for for capabilties. |
| account-notify | The account-notify client capability allows a client to be notified when another client’s accountname changes. |
| account-tag | The account-tag capability causes the server to add a message-tag containing the command sender’s services account to commands sent to the client that has requested this capability. It supersedes the identify-msg extension. |
| away-notify | The away-notify client capability allows a client to specify that it would like to be notified when users are marked/unmarked as away. This capability is referred to as ‘away-notify’ at capability negotiation time. |
| batch | This extension describes a capability which causes a new verb to be sent to clients when the IRC server wishes to designate that a series of events are related to each other. |
| cap-notify | The cap-notify capability indicates support for the NEW and DEL messages listed above. This capability MUST be implicitly enabled if the client requests CAP LS with a version of 302 or newer (CAP LS 302), as described in the CAP LS section above. |
| chghost | The chghost client capability allows a server to directly inform clients about a host or user change without having to send a fake quit and join. This capability MUST be referred to as chghost at capability negotiation time. |
| echo-message | If enabled, servers MUST send PRIVMSG and NOTICE messages back to the client that sent them. If servers apply any modifications to these messages, they MUST send the final version of the message back to the originating client. |
| extended-join | The extended-join capability extends the JOIN message to include the account name, or a placeholder if the user hasn’t identified with services. This capability MUST be referred to as ‘extended-join’ at capability negotiation time. |
| invite-notify | The invite-notify client capability allows a client to specify that it would like to be notified when users are invited to channels. |
| message-tags | Message tags are a mechanism for adding additional metadata on a per-message basis. This is achieved via an extension to the protocol message format, enabled via capability negotiation. |
| Monitor | Currently, ISON requests by clients use a large amount of bandwidth. It is expected that it is more efficient for this to be done by the server at the expense of cpu cycles. This specification deprecates both the ISON and legacy WATCH extensions. |
| multi-prefix | When requested, the multi-prefix client capability will cause the IRC server to send all possible prefixes which apply to a user in NAMES and WHO output. |
| sasl v3.1 | Description |
| sasl v3.2 | Description |
| server-time | When enabled, the server-time extension enables optional time message tag which can be used in messages from server to client. |
| sts | Strict Transport Security (STS) is a mechanism which allows servers to advertise a policy that clients should only connect to them over a secure connection. |
| tls | Deprecated |
| userhost-in-names | The userhost-in-names capability extends the NAMES reply messages (RPL_NAMREPLY) to contain the full hostmask (nick!user@host) of every user listed. |