CAP

What is CAP?

CAP is an abbreviation for "capability". Capabilities are extensions to the original IRC protocol that are available for ircd server distributions to implement and enable. This came about because it was difficult for the major server developers to come to a consensus on a single standard for all IRC servers to adhere to, so the solution was to create a series of smaller extensions that each server distribution could build into their code if they chose, but if they did, there was a single standardized protocol that all servers implementing it would adhere to. This set of extensions is commonly referred to as "IRCv3"

How does Eggdrop enable CAP requests?

A CAP is generally negotiated when Eggdrop connect to an IRC server via a "CAP request", but it can be done later as well. Eggdrop sets up these requests in the CAP section of the config file. Some common CAP requests are on/off settings in the config, and for any others you may wish to enable you add them to the "cap-request" string. If an IRC server does not support a specific CAP, Eggdrop will not attempt to request it (and obviously, that capability will not work).

Supported CAPs

Eggdrop is CAP v3.02 compliant. Eggdrop supports the following capabilities:

• account-notify: The account-notify client capability allows a client to be notified when a client’s account name changes. This capability MUST be referred to as ‘account-notify’ at capability negotiation time. When enabled, clients will get the ACCOUNT message to designate the account name changes for clients on common channels with them, including themselves.
• 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.
• 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. This capability is designed to replace polling of WHO as a more efficient method of tracking the away state of users in a channel. The away-notify capability both conserves bandwidth as WHO requests are not continually sent and allows the client to be notified immediately upon a user setting, changing or removing their away state (as opposed to when WHO is next polled). When this capability is enabled, clients will be sent an AWAY message when a user sharing a channel with them sets, changes or removes their away state, as well as when a user joins and has an away message set. (Note that AWAY will not be sent for joining users with no away message set.)
• chghost: The chghost capability allows servers to send a notification when clients change their username or host. This mechanism avoids simulating a reconnect of the client. This is useful for servers that implement virtual hosts or cloaks, and helps to reduce clutter in client UI.
• echo-message: PRIVMSG and NOTICE messages are sent back to the client that sent them.
• 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. When enabled, the JOIN message will designate the account name of the user when they join a channel.
• 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. This capability is designed to replace the traditional “X has invited Y to #chan” server notices, and to provide a standard way that allows clients to learn when another client does an /INVITE.
• 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: A protocol for notification of when clients become online/offline
• SASL: A pre-connection authentication protocol. Eggdrop supports PLAIN, ECDSA-NIST256P-CHALLENGE, and EXTERNAL authentication mechanisms.
• server-time: Enables time message tag which can be used in messages from server to client. It represents a calendar date and time of day in UTC using extended format
• setname: The setname client capability allows clients to change their realname (GECOS) on an active connection. It also allows servers to directly inform clients about such a change. This avoids a client reconnect when updating this value.
• WHOX: Allows clients to request additional fields in the WHO response (e.g. account name) or omit default fields (e.g. username and hostname).

How do I see what capabilities a server supports?

From your client, you can send /quote cap ls and it will return you a list. From Eggdrop, either via a Tcl script or the .tcl command on the partyline, send cap ls to see available capabilities, and cap enabled to see what capabilities the Eggdrop has negotiated.