IRCv3 support Last revised: November 27, 2021

IRCv3 support

This document provides information about IRCv3 capabilities, as defined via specifications documented by the IRCv3 working group (https://ircv3.net/). Support for some of these specifications was added starting with version 1.9.0, and more capabilities are added as possible with new versions.

About

As more and more IRC servers began to develop and implement their own versions of the IRC protocol (generally defined in RFC1459 and RFC2812), a working group comprised of server, client, and bot developers decided to work together to document these features to make their implementation defined and standardized across servers. What emerged was the IRCv3 set of standards. The specifications developed by the IRCv3 working group was designed to be backwards compatible and are generally implemented via a CAP (capability) request sent at the initialization of an IRC session. A client can optinoally request these “extra” capabilities be enabled through the CAP request, with the assumption that the client can then support the capability requested and enabled. Not all servers or clients support the same capabilities, a general support list can be via the appropriate support table link at https://ircv3.net/.

Usage

Within eggdrop.conf, several common IRCv3-defined capabilities are enabled simply changing their setting to ‘1’. Other capabilities without explicit settings in eggdrop.conf may be requested by adding them in a space-separated list to the cap-request setting. For more information on what a specific IRCv3-defined capability does, please consult https://ircv3.net/irc/.

Supported CAP capabilities

The following capabilities are supported by Eggdrop:

  • CAP/CAP 302 requests

  • SASL 3.2

  • account-notify

  • account-tag

  • away-notify

  • BOT 005 mode

  • cap-notify

  • chghost

  • echo-message

  • extended-join

  • invite-notify

  • message-tags

  • Monitor

  • server-time

  • setname

  • userhost-in-names

  • +typing

Errata

  • Enabling echo-message will cause Eggdrop to trigger PUB/PUBM binds on its own messages (because now it can actually see them). This may cause unintentional functionality with some scripts

  • Enabling userhost-in-names will cause Eggdrop’s internal mechanisms to mark a channel’s userlist as synch’d upon receiving the NAMES list after a join, instead of waiting for a full WHO listing. This is done because the assumption is that userhost-in-names was enabled as a response to WHO queries being disabled on a server, which prevents Eggdrop from populating its userlist. To avoid unintended functionality, it is suggested that this capability only be enabled on servers that disable WHO queries.

Copyright (C) 2010 - 2024 Eggheads Development Team