The ConferenceRooms Avatar Extension for IRC (CR-AVATAR)

Status of This Memo

Abstract

CR-AVATAR lets a registered IRC user choose a small picture, called an avatar, from a fixed catalogue of emoji, and lets every IRC user on the network see it. The avatar is stored with the user's services account, is sent by the network services to the servers as an ordinary "services tag", and is shown to every client as one extra line of the WHOIS reply:

:irc.conferencerooms.org 320 Viewer Alice :has an avatar set: 🦊 :fox:

No client capability negotiation is needed for this basic form: a client that does not know the extension shows the line as plain text, and a client that knows it can draw the emoji next to the nickname. Later sections add a way for a client to detect the extension (an ISUPPORT token) and, through a capability, a way to learn many avatars at once and to be told about changes (Sections 14 to 16 are implemented; Section 18.3 says by whom and how it was tested).

This memo explains how the system works, and is written so that the developer of another IRC server can link to a ConferenceRooms.org-compatible network and carry the avatars, and so that the developer of an IRC client can display them.

1. Introduction

1.1. Motivation

Web chat programs show a face or a symbol next to every name. Classic IRC shows only the nickname. Pictures uploaded by users need storage, a place to fetch them from, and moderation, and they open the door to tracking (a client that fetches a picture from a URL tells the picture's host who is looking). An emoji needs none of these: it is one short piece of UTF-8 text, every modern device can draw it, and a closed list of emoji cannot carry an offensive or tracking image.

CR-AVATAR therefore defines:

• a closed catalogue of named emoji (Section 4);
• how a user chooses one (Section 5);
• how the network tells its servers about it (Section 6);
• how the network tells clients about it (Section 7).

1.2. Goals

• Work with unmodified IRC clients (they see a readable line).
• Work for clients that want more: one regular line to parse, and a name (":fox:") for fallback.
• Carry no URLs, no images, no scripts: text only.
• Be authoritative: only the network services decide who has which avatar.
• Be cheap: one short line per user, nothing sent unless the user has an avatar.

1.3. Non-goals

• Uploading pictures, animated pictures or custom emoji.
• Per-channel avatars.
• Replacing other metadata mechanisms, including those of IRCv3. Section 19 describes how CR-AVATAR relates to them.

1.4. History

The system was designed and first deployed by ConferenceRooms.org (Richard Ward, nickname zeamp) on October 16, 2026 for the network irc.conferencerooms.org, with its web chat client at https://www.conferencerooms.org/chat/. The server software is "ircd-conferencerooms"; the services are the network's own. Everything specific to the avatar extension is the work of ConferenceRooms.org.

2. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Syntax is given in ABNF [RFC5234]. The rules nickname, SPACE, trailing and target are those of [RFC2812]. All text on the wire is UTF-8 [RFC3629]. "Server" means an IRC server, "services" means the network services server(s) that are trusted to manage accounts, "client" means a user's IRC program or a bot, and "viewer" means the client that sends WHOIS.

3. Overview

3.1. Roles

+----------+   AVATAR fox    +------------+
|  User's  | --------------> |  Services  |  (authority: keeps the
|  client  |                 |  server    |   account and its avatar)
+----------+                 +-----+------+
     ^                             |
     | WHOIS reply, line 320       | "avatar tag" (Section 6)
     |                             v
+----+-----+  server link   +------------+
|  Viewer  | <------------- |  Servers   |  (store the tag with the
|  client  |   (TS6)        |  (any no.) |   user; show it in WHOIS)
+----------+                +------------+

• The services are the only source of avatar tags. They keep the user's choice in the user's account.
• A server accepts an avatar tag from services, attaches it to the user record, passes it on to the other servers, shows it in WHOIS, and forgets it when the user disconnects.
• A client that wants to draw the avatar parses the WHOIS line.

3.2. What a user experiences

1. Alice registers her nickname and identifies to it (the network's ordinary account system; CR-AVATAR does not change it).
2. Alice types /avatar fox. Services check that "fox" is in the catalogue and keep it with Alice's account.
3. Services tell the servers: "Alice has the line 'has an avatar set: 🦊 :fox:'".
4. Bob types /whois Alice and his client shows that line (a plain client) or draws the fox beside Alice's name (a client that implements Section 8).
5. Alice disconnects. The servers drop the line. Her choice stays with her account for her next visit.

4. The Avatar Catalogue

4.1. Definition

An avatar is exactly one entry of the catalogue. An entry has:

• a name: a short, lower-case ASCII label;
• an emoji: one Unicode emoji, written as a single code point or as a code point followed by U+FE0F (VARIATION SELECTOR-16, "emoji presentation").
• a category: one of "animals", "faces", "nature", "food", "things", "symbols". The category is only used to list the catalogue for humans.

avatar-name     = 1*( %x61-7A / DIGIT / "-" )   ; "fox", "blue-heart"
catalogue-emoji = emoji-cp [ %xFE0F ]           ; one emoji, UTF-8
emoji-cp        = <one of the code points listed in Appendix A>

emoji-cp is not open text: it is exactly the set of code points that Appendix A lists, so that services validate by membership of that list. This is the form of an entry of the catalogue. The form of an avatar on the wire is wider (avatar-emoji of Section 7.2), and a client accepts that wider form (Section 7.2).

Names are unique. Emoji are unique. Matching a user's input against the catalogue is by name (case-insensitive, with spaces and underscores read as hyphens) or by the emoji itself, ignoring a trailing U+FE0F.

4.2. Catalogue version 1

Version 1 contains the entries listed in Appendix A (184 entries in 6 categories). Services MUST accept only entries of the catalogue for the avatar of a user. The catalogue is deliberately:

• closed: no user-supplied text, no sequences (no skin tones, no flags, no zero-width joiners), so nothing can be smuggled in;
• old: only emoji that every common platform has drawn for years, so a recent client or font is not required;
• free of the colour pink and magenta, a choice of the ConferenceRooms.org network; other networks MAY choose a different list.

A network MAY publish its own catalogue. If it does, it MUST keep the form of Section 4.1. A client MUST NOT require that the emoji it receives belongs to catalogue version 1 (Section 8).

5. Choosing an Avatar

5.1. Eligibility

Only a user who is registered and identified to a services account can have an avatar. A guest cannot. Services MUST remove the avatar line of a user who stops being identified, at the latest at the next refresh (Section 6.5).

5.2. The AVATAR command

Services offer the command below, as a service command in the network's usual way (for instance /AVATAR ... as an alias for a message to a services bot). The exact words of the answers are informative; only the effects are normative.

The choice is kept with the account (the ConferenceRooms.org services keep it as the account field "AVATAR"). It is the same on every connection of the account and survives reconnecting.

5.3. Validation

Services MUST store a value only if it is an entry of the catalogue, in its canonical form (Section 4.1). Any other value, such as free text, a URL, or an emoji not in the catalogue, MUST be refused. The same rule applies to every other route that can write the field (administrator commands, generic "set field" commands).

6. Telling the Servers: the Avatar Tag

6.1. The message

Services tell the servers about an avatar with one server-to-server message. In ircd-conferencerooms this message is the services tag command SVSTAG; this document only relies on its shape, which is repeated here so that it can be implemented in any server:

avatar-tag  = ":" source SPACE "SVSTAG" SPACE target-uid SPACE ts
              SPACE "320" SPACE modes SPACE ":" text
clear-tags  = ":" source SPACE "SVSTAG" SPACE target-uid SPACE ts
              SPACE "-"
source      = server-id         ; the services server
target-uid  = <the user's unique id, as in the link protocol>
ts          = 1*DIGIT           ; the user's nickname timestamp
modes       = "+" *( user-mode-letter )
user-mode-letter = ALPHA
text        = avatar-text       ; Section 7.2

source is the services server. target-uid and ts identify the user exactly as the link protocol identifies users elsewhere (TS6). modes says which user modes the viewer must have to be shown the line: + alone means everybody, +o means IRC operators only. Avatar lines are always sent with +.

Example (line breaks added for reading only):

:00AAAAAAB SVSTAG 00AAAAAAC 1792250000 320 + :has an avatar set: 🦊 :fox:
:00AAAAAAB SVSTAG 00AAAAAAC 1792250000 -

The first line attaches the tag, the second removes every tag of that user.

6.2. Setting and replacing

Services never edit a single tag. To change what a user's WHOIS shows, services send - (remove all tags of the user) and then send every line the user should have, in the order they are to be shown. A user with no avatar and nothing else to show has no tags.

6.3. What a server does with an avatar tag

A server that receives the message from a server link MUST, in this order:

1. Ignore the message if it comes from a client, or if the sending server is not a services server of the network (Section 6.6).
2. Look up the target user by target-uid; ignore the message if there is none.
3. Compare ts: if it is not 0 and not equal to the user's own timestamp, ignore the message (it was meant for an earlier owner of the same unique id or nickname).
4. If the argument is -: remove all tags of the user, pass the message on (step 6), stop.
5. Otherwise attach the tag: remember the numeric (here 320), the mode requirement and the text, at the end of the user's list of tags. Ignore the message if the text is empty. Ignore it if the numeric is not in the range of reply numerics the server can emit, or if modes does not begin with "+".
6. Pass the message on, unchanged except that the user is named by its unique id and timestamp, to every other server link except the one it came from.

6.4. Bursts, quits and splits

• When two servers link, each sends the other, as part of its burst, one avatar-tag message for every tag of every user it knows, after that user's introduction and away status. The tags of a user MUST be sent in the order in which they are shown, so that the receiver keeps that order.
• A server MUST forget all tags of a user when the user disconnects or is removed. Tags are never kept after the user is gone, and are not sent for a user that is not on the network.
• A server that loses the link to services keeps the tags it has; they are replaced when services return and refresh.

6.5. When services send

Services send the tags of a user:

• when the user identifies to the account;
• when the avatar is set, changed or removed;
• when the user's operator status changes (Section 11.2);
• when the network's avatar option changes (Section 11.1);
• when services start (they then send the tags of every identified user);
• and, as a safety net, every 15 seconds for every identified user, but only if what would be sent differs from what was last sent for that user. A user whose avatar has not changed causes no traffic.

When the account is no longer identified (for example the nickname was dropped), services send -.

6.6. Who may send an avatar tag

Only services. A server MUST ignore an avatar tag from a client, and SHOULD ignore it from any server that is not configured as a services server ("U-lined", or the equivalent in the server's own configuration). Otherwise any server on the network could give any user any WHOIS line.

Remark: ircd-conferencerooms accepts the command from any linked server. A network that links servers that are not trusted MUST add the check of this section.

7. Telling the Clients

7.1. Where it appears

The avatar is shown in the reply to WHOIS, as one more line using the numeric reply 320. In the reply to WHOIS Alice sent by the server irc.conferencerooms.org to the viewer Bob:

:irc.conferencerooms.org 311 Bob Alice ~alice hostmask.org * :Alice
:irc.conferencerooms.org 319 Bob Alice :#lobby #music
:irc.conferencerooms.org 312 Bob Alice irc.conferencerooms.org :ConferenceRooms.org IRC server
:irc.conferencerooms.org 320 Bob Alice :has an avatar set: 🦊 :fox:
:irc.conferencerooms.org 330 Bob Alice Alice :is logged in as
:irc.conferencerooms.org 318 Bob Alice :End of /WHOIS list.

The server sends each tag of the target user, in the order the tags were attached, once per tag the viewer is allowed to see (+ for everybody; +o only to operators). On the wire the tags come after the server line (312), the away line (301, if any) and the operator line (313, if any) and before the modes line (379, sent to operators and to the user themselves), the idle line (317) and the end of the reply (318). The reply has the form <numeric> <viewer> <target> :<text>, so that the line is formed like the other WHOIS lines.

The 320 line is the form that is always available, and the only one for a client that did not ask for the capability (Section 15.7); the bulk and notification methods of Sections 15 and 16 need the capability.

Where the line is drawn on the screen is a matter for the client: a client is free to group, sort or reorder the lines of a WHOIS reply, and some do. The transcripts of Section 7.5 show a client (the Textce IRC Client) that prints the avatar line last, directly above the end of the reply. A client MUST NOT depend on the position of the line, only on its text (Section 7.4).

7.2. The text of the avatar line

avatar-text   = "has an avatar set: " avatar-value
avatar-value  = avatar-emoji [ SPACE ":" avatar-name ":" ]
              / badge-text
badge-text    = 1*( %x20-7E )       ; Section 11.2
avatar-emoji  = 1*( %x21-7E / UTF8-2 / UTF8-3 / UTF8-4 )
                ; UTF8-2, UTF8-3 and UTF8-4 are those of [RFC3629];
                ; at most 16 octets in all; no SPACE and no control
                ; character (U+0000-U+001F, U+007F-U+009F)

Both parts of the usual form are always present: the emoji, a single space, and the name between colons. For example:

has an avatar set: 🦊 :fox:
has an avatar set: ❤️ :heart:

The name consists of lower-case letters, digits and hyphens (avatar-name). It is optional metadata: a client whose line or message has no name does nothing about it, and its display MUST NEVER depend on the name. The emoji is for clients that draw emoji. The :name: is for every other reader: it is understandable in any font and is the key for a client that has its own pictures.

Real data contains variation selectors: the satellite, for example, is U+1F6F0 followed by U+FE0F, 7 bytes in UTF-8. A client MUST keep the whole emoji sequence it receives, including variation selectors (U+FE0E, U+FE0F) and zero-width joiners (U+200D), and MUST NOT normalise, trim or split it. A client MUST reject an emoji longer than 16 bytes, one that contains a space or a control character, and an empty one. Validation on the client is by length and by the absence of spaces and control characters only: a client MUST accept any such value, whether or not it is an entry of catalogue version 1 or of any catalogue it knows (a network may publish its own, Section 4.2). A 320 line that does not match the expression of Section 8.2 is ignored for avatar purposes and MAY be shown as an ordinary WHOIS line.

7.3. When there is no line

A user with no avatar has no avatar line. The absence of the line is not an error. A client MUST NOT treat it as one.

7.4. Other lines with the same numeric

The numeric 320 is also used by some servers and by the services of ConferenceRooms.org for other profile lines (the services tag mechanism can carry any short text). A client therefore MUST recognise the avatar line by the beginning of the text, has an avatar set: , and MUST ignore any other 320 line for the purpose of CR-AVATAR.

The operator badge. The text has an avatar set: ConferenceRooms logo (network operator) (Section 11.2) does not match the expression of Section 8.2, so it is not an avatar. A client shows nothing for it in the chat window and in the user list, unless the client has a badge of its own for it, and shows the text as an ordinary WHOIS line. A client MUST NOT try to draw an emoji from it.

7.5. Examples From the Live Network

These WHOIS replies were taken from the ConferenceRooms.org network on October 16 and 17, 2026, as displayed by the Textce IRC Client (each line is shown by the client as "nickname text"; the client's time stamps are removed). They are the real form of the three cases a client will meet.

a) A registered user with an avatar. The avatar line, has an avatar set: 🍕 :pizza:, is the line before the end of the reply in this client's display:

dmitri is ~dmitri@go4b7pikivhi7kk2.crorg * Dmitri
dmitri on #music
dmitri using irc.conferencerooms.org (ConferenceRooms.org IRC server)
dmitri is idle 15m 13s, signed on 10/16/26 3:23 PM
dmitri is using a secure connection
dmitri is using modes +iux
dmitri Actual user@host, actual IP ~dmitri@23.237.47.83
dmitri has an avatar set: 🍕 :pizza:
dmitri End of /WHOIS list.

On the wire the same line is:

:irc.conferencerooms.org 320 Viewer dmitri :has an avatar set: 🍕 :pizza:

b) An IRC operator. The network's operator mark is a logo that an IRC client cannot draw, so an operator who has not chosen an emoji shows the badge text of Section 11.2 (an operator who has chosen an emoji shows that emoji, as in case a):

zeamp has an avatar set: ConferenceRooms logo (network operator)

On the wire:

:irc.conferencerooms.org 320 Viewer zeamp :has an avatar set: ConferenceRooms logo (network operator)

c) A client that cannot draw the emoji. The :name: after the emoji keeps the avatar understandable. This is what a legacy client prints for a user who chose the spider (the emoji, U+1F577 followed by U+FE0F, shows as a box or as nothing in a client or font without emoji support, but the name is plain text):

[lilbit] has an avatar set: 🕷️ :spider:

d) A user without an avatar has no avatar line at all (Section 7.3); the reply is the ordinary one, ending in 318.

8. Implementing a Client

8.1. Requirements

A client that displays avatars:

1. MUST ask for them with the ordinary WHOIS command. There is no capability to enable and no new command.
2. MUST recognise the line as in Section 7.4, take the text after the prefix, and split it into the emoji and the optional name.
3. MUST treat the text as untrusted: it is plain text and nothing in it is a link, a command or markup. A client MUST NOT fetch anything because of it.
4. SHOULD draw the emoji with the system's emoji font and SHOULD fall back to the :name: (or nothing) if it cannot draw it.
5. SHOULD keep what it learned for a user until that user quits, changes nickname (move the entry to the new nickname) or the client disconnects, and SHOULD NOT send WHOIS repeatedly for the same user.
6. MAY limit the length of the emoji it accepts (a safe limit is 16 bytes) and MUST ignore a line that does not match Section 7.2.

8.2. Parsing

The following expression matches the text of an avatar line (the part after the numeric and the colon of the trailing parameter):

^has an avatar set: (\S+)(?: :([a-z0-9-]+):)?$

Group 1 is the emoji (it may end with U+FE0F), group 2 the name when present. The badge text of Section 11.2 does not match this expression (it contains spaces after its first word), so a client that does not know badge text simply ignores such a line.

A reference parser in Python:

import re
AVATAR = re.compile(r"^has an avatar set: (\S+)(?: :([a-z0-9-]+):)?$")

def parse_320(params):
    """params = the parameters of a 320 numeric, e.g.
    ["Bob", "Alice", "has an avatar set: \U0001F98A :fox:"]"""
    if len(params) < 3:
        return None
    m = AVATAR.match(params[-1])
    if not m or len(m.group(1).encode("utf-8")) > 16:
        return None
    return {"nick": params[1], "emoji": m.group(1), "name": m.group(2)}

and in JavaScript:

const AVATAR = /^has an avatar set: (\S+)(?: :([a-z0-9-]+):)?$/u;
function parse320(params) {            // ["Bob","Alice","has an ..."]
  const m = params.length >= 3 && AVATAR.exec(params[params.length - 1]);
  return m ? { nick: params[1], emoji: m[1], name: m[2] || null } : null;
}

8.3. When to query

The polite lookup rules of Section 17.2 apply. A client MAY send WHOIS for a user the first time it sees the user (a join, a message), at a low rate, or only when the user opens a profile view or hovers over a name. Networks rate-limit WHOIS; a client SHOULD NOT send more than one per second per server. A client that already learns the account of a user from the account-notify or extended-join capabilities (both IRCv3 extensions) MAY skip WHOIS for users that are not logged in, since a user who is not identified has no avatar.

8.4. Display

• Show the emoji immediately to the left of the nickname in the member list and, if the client wishes, next to the name of the speaker in messages.
• Use a fixed-width slot for the emoji, empty for people without one, so that the nicknames stay in a straight column.
• Give the emoji a text alternative (its :name:) for screen readers.
• Do not show anything for a user whose line is absent or invalid.

8.5. Legacy Clients: What They Show

CR-AVATAR needs no change in a client for the avatar to be understood. A client that has never heard of it prints the WHOIS line as it prints every other line it does not know, and the user reads it:

[lilbit] has an avatar set: 🕷️ :spider:

There are three cases, and all of them are fine:

1. The client and its font draw emoji: the user sees the spider and the name.
2. The font has no emoji (an older terminal, an old Windows font, a plain text console): the emoji is shown as a box, a question mark or nothing, and the user still reads has an avatar set: ... :spider:. The name tells a legacy user exactly what is set.
3. The client removes characters it cannot draw (some strip everything outside the basic range): the line reads has an avatar set: :spider:, which is still understandable.

This is why the name is always sent together with the emoji (Section 7.2) and why the text of the line is written as a sentence: the avatar degrades to words, never to garbage and never to nothing. The words has an avatar set also let users search their logs for it.

A client that does draw avatars SHOULD still keep the name (for example as the alternative text of the picture, Section 8.4) and SHOULD show it when the emoji cannot be drawn.

9. Implementing a Server

9.1. What a server needs

A server that wants to carry CR-AVATAR needs three things, all small:

1. A place to keep tags per user: a list of (numeric, required user modes, text).
2. A handler for the avatar-tag message of Section 6.1, with the checks of Section 6.3 and the trust rule of Section 6.6.
3. WHOIS output of the tags, and burst output of them to a newly linked server (Sections 6.4 and 7.1).

Servers that implement the TS6 services tag command "SVSTAG" already have all three; they only need the trust rule of Section 6.6 if they link to servers they do not control.

9.2. Data

struct Tag { unsigned numeric; unsigned umodes; char *text; };
struct User { ...; list<Tag> tags; };      // in order of arrival

9.3. Handler (pseudo-code)

on_server_message(src, "SVSTAG", uid, ts, arg, modes, text):
    if not src.is_services:            return          # Section 6.6
    u = find_user_by_id(uid)
    if u is None:                      return
    if ts != 0 and ts != u.nick_ts:    return
    if arg == "-":
        u.tags.clear()
        forward_to_other_servers(src, ":%s SVSTAG %s %d -" % (src.id, u.id, u.nick_ts))
        return
    if text == "" or modes[0] != "+":  return
    u.tags.append(Tag(numeric=int(arg), umodes=parse_modes(modes), text=text))
    forward_to_other_servers(src, ":%s SVSTAG %s %d %s %s :%s"
                             % (src.id, u.id, u.nick_ts, arg, modes, text))

9.4. WHOIS (pseudo-code)

in whois(viewer, target), right after the 312 (server) line:
    for tag in target.tags:
        if tag.umodes == 0 or viewer has all modes in tag.umodes:
            send(viewer, ":%s %d %s %s :%s" %
                 (me.name, tag.numeric, viewer.nick, target.nick, tag.text))

9.5. Burst, quit

in burst(link): for each user u, for tag in u.tags (in order):
    send(link, ":%s SVSTAG %s %d %d +%s :%s" %
         (me.id, u.id, u.nick_ts, tag.numeric, mode_letters(tag.umodes), tag.text))
in client_exit(u): u.tags.clear()

9.6. Linking a server to the ConferenceRooms.org network

Linking is a matter of agreement between the operators of both networks. This document does not give anyone the right to link. To propose a link, contact the operators of ConferenceRooms.org through https://www.conferencerooms.org/.

After the operators agree, the server administrator:

1. configures a link to the agreed address with the agreed server name, link password and server id (TS6), and TLS if agreed;
2. configures the services server of the network, services.conferencerooms.org, as a services server (the "U-line" or "services" setting of the server's configuration) so that Section 6.6 accepts its tags;
3. makes sure the server implements Section 9 (servers that implement the TS6 services tag command SVSTAG already do);
4. links, and waits for the burst to finish.

To check: /WHOIS <nickname>, from a user of the new server, for a user of the ConferenceRooms.org network who has an avatar shows the line of Section 7.1. Users of the new network get no avatars from ConferenceRooms.org services unless they register there; sharing accounts between networks is not defined by this document.

9.7. Reference implementation

The reference implementation is ircd-conferencerooms (server) and the ConferenceRooms.org services, written by ConferenceRooms.org. Appendix B lists where each part is.

10. Implementing Services

10.1. Storage

Keep the avatar with the account, as the emoji in its canonical form, in the same store as the other account data. Keep nothing else about it: no name (it can be derived from the catalogue), no image, no timestamp.

10.2. Computing the tags of a user

def avatar_tags(user, network):
    out = []
    if user.account and network.avatar_line_on:      # Section 11.1
        e = account_avatar(user.account)             # emoji or ""
        if e:
            out.append("has an avatar set: %s :%s:" % (e, name_of(e)))
    return out

def publish(user):
    lines = avatar_tags(user, network)
    if lines == last_sent.get(user.uid):  return     # nothing changed
    last_sent[user.uid] = lines
    send("SVSTAG %s %d -" % (user.uid, user.ts))
    for text in lines:
        send("SVSTAG %s %d 320 + :%s" % (user.uid, user.ts, text))

publish is called at the moments listed in Section 6.5. Services keep the last lines sent per user so that unchanged users cost nothing, and forget the entry when the user quits.

10.3. The services command

Implement AVATAR as in Section 5 and validate as in Section 5.3. A good implementation also answers with the emoji it set, so that the user sees it at once, and calls publish immediately.

11. Network Options and Local Policy

11.1. The switch

A network SHOULD have one setting that turns the avatar line in WHOIS off and on for everybody. ConferenceRooms.org services keep it as the profile-field setting "WHOIS" of the field "Avatar": the services administration command FIELD Avatar SET WHOIS on (the default) and FIELD Avatar SET WHOIS off. When it is off, services send no avatar lines; when it is switched, services re-send within the refresh interval of Section 6.5. The setting never changes who has which avatar and does not affect other ways the network shows avatars (for example in a web client).

11.2. Operators

A network MAY give IRC operators a distinct mark. At ConferenceRooms.org an operator's emoji is replaced by the network's logo in its own web client; because a logo cannot be drawn in an IRC client, the WHOIS line of an operator who has chosen an emoji is the ordinary line of Section 7.2, and the WHOIS line of an operator who has no emoji is:

has an avatar set: ConferenceRooms logo (network operator)

Such "badge text" follows badge-text of Section 7.2: printable ASCII, no emoji. A client that does not know the badge text MUST ignore the line (Section 8.2).

11.3. Automated clients

A network MAY give avatars to automated clients that have no account, by local policy. ConferenceRooms.org does this for its own demonstration bots (roughly half of them, chosen by a fixed hash of the nickname, so that a given bot always has the same emoji) by recognising their server addresses. This is not part of the protocol: to every client such a bot looks like any user with an avatar.

12. Non-IRC Clients (Informative)

The web chat at https://www.conferencerooms.org/chat/ is a gateway: it is an IRC client to the network and shows avatars to its users. It does not use the WHOIS line; the services write the avatars of the users who are online to a file that the gateway reads, and the gateway adds the emoji to the member list and to each message. The IRC line of Section 7 and this file say the same thing. A gateway for another network can instead send WHOIS for each visible user and parse the line as in Section 8.

13. Interoperability Test Vectors

A server or client implementation can be tested with the following exchanges. Hostnames and ids are examples.

13.1. Server

# services -> server: attach, then replace, then clear
:00AAAAAAB SVSTAG 00AAAAAAC 1792250000 -
:00AAAAAAB SVSTAG 00AAAAAAC 1792250000 320 + :has an avatar set: 🦊 :fox:

Bob: WHOIS Alice
S->Bob  (contains) :irc.example 320 Bob Alice :has an avatar set: 🦊 :fox:

:00AAAAAAB SVSTAG 00AAAAAAC 1792250000 -
:00AAAAAAB SVSTAG 00AAAAAAC 1792250000 320 + :has an avatar set: 🚀 :rocket:
Bob: WHOIS Alice
S->Bob  (contains) ... :has an avatar set: 🚀 :rocket:
S->Bob  (does not contain) the fox line

:00AAAAAAB SVSTAG 00AAAAAAC 1792250000 -
Bob: WHOIS Alice
S->Bob  (does not contain) any "has an avatar set" line

# wrong timestamp: ignored
:00AAAAAAB SVSTAG 00AAAAAAC 1 320 + :has an avatar set: 🦊 :fox:
Bob: WHOIS Alice  ->  no avatar line

# from a client or a server that is not services: ignored (Section 6.6)

13.2. Client

A client MUST pass these lines of the WHOIS reply as follows:

:s 320 Bob Alice :has an avatar set: 🦊 :fox:        -> emoji 🦊, name fox
:s 320 Bob Alice :has an avatar set: ❤️ :heart:       -> emoji ❤️ (ends in U+FE0F)
:s 320 Bob Alice :has an avatar set: 🦊                -> emoji 🦊, no name
:s 320 Bob Alice :is an away message                   -> not an avatar line
:s 320 Bob Alice :has an avatar set: ConferenceRooms logo (network operator)
                                                       -> not an emoji line: ignore
:s 320 Bob Alice :has an avatar set: <longer than 16 bytes>  -> ignore

Detection (Section 14):

:s 005 Bob CR-AVATAR=1 :are supported by this server   -> avatars on, catalogue 1
:s 005 Bob -CR-AVATAR :are supported by this server    -> avatars off, cache cleared
(no CR-AVATAR token, no matching 320 line ever)         -> avatars off, no slot, nothing shown
connected through a bouncer that answers as irc.znc.in  -> same result as without the bouncer

13.3. A live network

The ConferenceRooms.org network can be used to test a client:

1. Connect to irc.conferencerooms.org, port 6697 (TLS) or 6667 (plain text), and register a nickname.
2. /WHOIS the nickname of a user who has an avatar (many of the network's regular demonstration users in the room #lobby have one; the room can be listed with /NAMES #lobby). Expected: a 320 line as in Section 7.1.
3. To have an avatar of your own: register your nickname with the network services, identify, and type /avatar fox. Then, from a second connection, /WHOIS yourself.

13.4. The AVATAR message and detection (Sections 14 to 16)

A client that has the capability active MUST give these results. alice is a nick the client has no channel entry for unless stated.

:alice!a@h AVATAR 🦊 fox               -> alice: 🦊 (name fox, optional)
:alice!a@h AVATAR 🚀 rocket            -> alice: 🚀 (replaces 🦊)
:alice!a@h AVATAR *                    -> alice: no avatar
:alice!a@h AVATAR 🦊🦊🦊🦊🦊           -> ignored (20 bytes); the previous value stays
:alice!a@h AVATAR :🦊 fox              -> ignored (the value contains a space)
:alice!a@h AVATAR 👩‍💻                  -> alice: 👩‍💻 (U+1F469 U+200D U+1F4BB, 11 bytes)
:alice!a@h AVATAR ❤️ heart             -> alice: ❤️ (keeps U+FE0F)
:alice!a@h AVATAR 🦊                   -> alice: 🦊, no name; display unchanged
(AVATAR for alice before any NAMES reply that lists her) -> stored under "alice", used when she appears
:s 005 Bob CR-AVATAR=7 :are supported by this server    -> avatars on; version 7 recorded, not refused
:s 005 Bob -CR-AVATAR :are supported by this server     -> every cached avatar cleared, lookups stopped

14. Feature Detection

14.1. The ISUPPORT token

An ircd that carries CR-AVATAR MUST advertise the token

CR-AVATAR=<catalogue-version>

in the RPL_ISUPPORT (005) reply that it sends at registration, for example CR-AVATAR=1. The value is the version of the avatar catalogue in use; version 1 is the catalogue of Appendix A (184 entries). A network that publishes a catalogue of its own (Section 4.2) uses a different number, and a client MUST NOT refuse to work because it does not know the number.

isupport-token = "CR-AVATAR=" 1*DIGIT
isupport-off   = "-CR-AVATAR"

The token is advertised only while the services that own avatars are linked to the network. If services leave, the server SHOULD tell its registered clients with a 005 line that carries -CR-AVATAR, and SHOULD send CR-AVATAR=<version> again when services return. An ircd that cannot send 005 lines after registration simply keeps the token it advertised at registration; a client therefore also follows the WHOIS rule of Section 14.2.

No client capability (CAP) is needed for detection. A client that does not know the token ignores it, as it ignores every unknown ISUPPORT token. The token passes unchanged through bouncers such as ZNC, which forward the 005 tokens and numerics of the upstream server to the client.

14.2. Client rules

A client:

1. MUST turn avatars on for a connection when it sees CR-AVATAR in 005, or when any WHOIS reply on that connection contains a 320 line that matches Section 8.2;
2. MUST turn avatars off for the connection, and clear every cached avatar, when it sees -CR-AVATAR;
3. MUST NOT decide by the address the user typed, by the vhost, or by the suffix of a server name. A bouncer answers as its own host (ZNC, for example, appears as irc.znc.in) and forwards the lines of the upstream server. This is a rule of the protocol, and no client that conforms to it contains such a check, except as in the next item;
4. MUST NOT contain any workaround that switches avatars on by a server name. An earlier revision allowed one temporary check of this kind; it has been removed from the clients, and it is not part of the protocol.
5. on a network that has no token and never returns an avatar line, shows nothing at all: no slot, no placeholder (Section 17.1).

14.3. Implementation status

The reference ircd (ircd-conferencerooms) advertises CR-AVATAR=1 at registration while a services server is linked, sends 005 -CR-AVATAR to its registered clients when services leave, and advertises CR-AVATAR=1 again when they return. It does so on irc.conferencerooms.org since October 18, 2026. The Textce clients (macOS, iPhone and Windows) no longer contain the temporary server-name workaround that earlier revisions allowed: they turn avatars on only from the 005 token, an active capability or a matching 320 line, and a server name alone decides nothing. The network owner reports that the 005 token is forwarded by their own bouncer; the authors did not test this themselves. Section 18.3 has the table.

15. Bulk Lookup

15.1. The problem

WHOIS (Section 7) is the only way today to learn an avatar, and it answers about one user at a time. A client that joins a room with 200 people would have to send 200 WHOIS commands, which is slow and which networks limit. Lookups cannot be batched either: the live ircd (ircd-conferencerooms) does not accept a list of nicks in WHOIS (WHOIS a,b,c is answered with 401 No such nick/channel and one 318 for the whole string).

15.2. The options that were considered

• A WHOX field. WHOX [WHOX] returns chosen fields for all members of a channel in one reply. It needs the ircd to implement WHOX first; the reference ircd does not, so it is not chosen. A network that has WHOX MAY add an avatar field; this document does not define one.
• A message tag on JOIN and messages. A tag such as conferencerooms.org/avatar=🦊 on JOIN and PRIVMSG/NOTICE/ACTION would tell a client the avatar of everybody who joins or speaks. It does not help with members who are silent, and it needs the message-tags capability [IRCV3-MT]. It is therefore not chosen. This document does not define the tag, and no server or client needs it.
• A metadata-style batch. The server sends, once, an AVATAR message for each member that has an avatar. This works for silent members, needs only one new capability, and is the same message that Section 16 uses to tell about changes, so one mechanism does both jobs. This is the option chosen.

15.3. The capability and the message

Decision: the reference ircd supports the capability conferencerooms.org/avatar and the server-to-client message AVATAR (Section 15.9).

cap-name    = "conferencerooms.org/avatar"
avatar-msg  = ":" nick "!" user "@" host SPACE "AVATAR" SPACE
              ( avatar-emoji [ SPACE avatar-name ] / "*" )

AVATAR carries the avatar of the user named in the prefix: the emoji, and the name when the server knows it. AVATAR * says that the user has no avatar (any more), and means nothing else. The parameters are plain middle parameters (they contain no spaces). The emoji is an avatar-emoji of Section 7.2, at most 16 octets; the name, when present, is an avatar-name. A value with a space can exist only in the trailing form (AVATAR :two words), and it is invalid: a client ignores such a message and keeps the previous value. AVATAR two words is a different message: the avatar two with the name words.

The operator badge is never carried by AVATAR. The badge text of Section 11.2 is not an avatar. A user who has no emoji avatar, including an IRC operator who only has the badge text, is announced with AVATAR * or not mentioned at all, exactly like any other user without an avatar. Whoever wants to see the badge text asks with WHOIS (Section 7.4); a client that only has the capability shows nothing for it.

Own entry. The server also sends AVATAR about the client's own user, and a client treats its own entry like any other.

A client requests the capability with CAP REQ :conferencerooms.org/avatar after CAP LS lists it. It does not depend on the message-tags capability. A client that does not request it receives no AVATAR message and uses WHOIS.

15.4. What the server sends

The server sends AVATAR messages to a client that has the capability:

1. When the client joins a channel: directly after the end of the NAMES reply (366), one AVATAR message for each member of the channel that has an avatar. Members without an avatar are not mentioned. This is the bulk lookup: one burst per join, no polling.
2. When another user joins a channel the client is in: directly after the JOIN message, if that user has an avatar.
3. When the client itself identifies or its own avatar changes: an AVATAR message about itself, so that its own display agrees with the network.

A server MUST send a user's AVATAR message to a client at most once for each change (not once per shared channel). A server MUST NOT send badge text, or any value that is not an avatar-emoji, in an AVATAR message; a user whose 320 line is badge text has no avatar for this purpose (Section 15.3).

15.5. Where the server gets the avatar

The server derives the value from the avatar tag it already holds for the user (Section 6), by matching the 320 text with the expression of Section 8.2. Services therefore need no change and the server-to-server protocol is unchanged: every server of a multi-server network derives the same AVATAR message from the tag that was passed to it (Section 6.3, step 6).

15.6. Example exchange

C: CAP LS 302
S: CAP * LS :message-tags conferencerooms.org/avatar ...
C: CAP REQ :conferencerooms.org/avatar
S: CAP * ACK :conferencerooms.org/avatar
...
C: JOIN #lobby
S: :bob!b@h JOIN #lobby
S: :irc.example 353 bob = #lobby :@alice bob carol dmitri
S: :irc.example 366 bob #lobby :End of /NAMES list.
S: :alice!a@h AVATAR 🦊 fox
S: :dmitri!d@h AVATAR 🍕 pizza

carol has no avatar and is not mentioned. The client now knows every avatar in the room without a single WHOIS. (This is what the reference ircd does; Section 15.9 says how it was tested.)

15.7. Fallback

WHOIS (Section 7) is always available. When the capability is active, a client MUST NOT also send WHOIS lookups for avatars: the server tells it everything it needs to know. WHOIS stays the only path when the capability is not active, that is, when the network does not offer it or the client did not request it, and then the client uses WHOIS under the rules of Section 17.2. A WHOIS that the person types is always allowed and always shown, with or without the capability.

15.8. Order and duplicates

• A client MUST accept AVATAR messages in any order, for example an AVATAR for a member before the NAMES reply of that channel has been processed, or after it.
• A second AVATAR for the same nick replaces the first. Nothing is added up, and the last message wins.
• A client MUST accept an AVATAR for a nick that it has no channel-list entry for yet. It keeps the value under the nick and uses it when the user appears in a list, and it drops it when the user quits.
• A client ignores an AVATAR message whose value is not valid under Section 7.2 (too long, a space, a control character). The previous value, if any, stays.

15.9. Implementation status

Implemented in ircd-conferencerooms (a module, cr_avatar.c, and two small hooks in the core): the capability, and the AVATAR message after the NAMES reply, after a JOIN, on a change and about the user themselves. The ircd derives it from the avatar tag that it already holds (Section 15.5); services were not changed. It was tested on a scratch ircd (19 checks, and 5 more for services leaving and returning) and, after it went live on October 18, 2026, with 9 checks on the live network that used one temporary account (dropped afterwards). Not tested: a second linked server (a remote JOIN uses the same hook), a netsplit, the operator badge appearing or disappearing, the network switch of Section 11.1, and a bouncer in front of the ircd.

16. Change Notification

16.1. The problem

A client cannot learn that somebody set, changed or removed an avatar in the middle of a session. It keeps the old emoji until the person rejoins, or until the client polls, which Section 17.2 forbids.

16.2. The push

The AVATAR message of Section 15.3 is also the notification. When the avatar of a user changes, the server sends AVATAR to every client that has the capability and shares at least one channel with that user, and to the user themself:

S: :alice!a@h AVATAR 🚀 rocket      (alice changed her avatar)
S: :alice!a@h AVATAR *              (alice removed it)

The server sends the message when it processes the avatar tag that services sent (Section 6.1). A - that is followed by a new 320 line is one change, not two: the server compares the avatar before and after the replacement and sends one message, or none if they are the same. The same happens when a user stops being identified (the avatar is removed), when the network switch of Section 11.1 is changed (every affected user is announced). The operator badge is not an avatar and never causes an AVATAR message (Section 15.3); an operator without an emoji is simply a user without an avatar.

Timing. The reference ircd announces a change after it has seen the new value on two checks that are one second apart (so that the - that services send before they re-send the tags never shows as a second change). Clients therefore see a change 1 to 3 seconds after services send it. Joins and the burst after the NAMES reply are not delayed.

Services that re-send tags (ircd-hybrid and similar). On servers whose services-tag command appends tags instead of replacing them, and that need the user-mode field to start with +, services must clear the tags and then send the new ones; a change is therefore a clear followed by a send, and the ircd announces it once, 1 to 3 seconds later, as above.

Services leave and return. When services leave, the ircd withdraws the token with 005 -CR-AVATAR to its registered clients and removes the capability from CAP LS, and it forgets what it had announced. A client that has seen -CR-AVATAR stops using the capability and every other avatar feature, and clears what it knows, until a later CR-AVATAR=<n> (Section 14.2). When services return, the ircd advertises CR-AVATAR=1 again and announces every avatar that came back, once, as a change; an avatar that services send again later is announced as a change when the ircd sees it.

16.3. Joining, quitting and nick changes

• A user who joins is announced with AVATAR after the JOIN (Section 15.4, step 2), so a client does not have to ask.
• A quit or a part needs no AVATAR message; the client drops the entry when it drops the user.
• A nick change needs none; the client moves the entry to the new nick (Section 17.2).

16.4. Without the capability

A client without the capability learns of a change only when it asks with WHOIS. It SHOULD NOT poll; it MAY refresh a user when the person selects that user or opens their profile.

16.5. Implementation status

Implemented in ircd-conferencerooms together with Section 15 (see Section 15.9 and Section 18.3). The case "services leave and return" was tested on a scratch ircd: the withdrawal, the return of the token and the announcement of an avatar that is still there.

17. Client Display and Lookup Guidance

17.1. Display (recommended; this is what the Textce IRC Client does)

• User list. The emoji sits between the mode badge and the nick. On a network that supports avatars, keep a blank slot for users without an avatar so nicks stay aligned. On a network that does not support avatars, show no slot.
• Chat window. The emoji comes immediately before the sender's nick for normal messages (🦊 <alice> hello). Users without an avatar get nothing extra.
• WHOIS. The client shows the avatar in its WHOIS output exactly as <nick> has an avatar set: <emoji> :<name>: (the name is optional). Section 7.1 explains that the position of the line is the client's choice.
• Nothing to show. For a user without an avatar, on a network without avatars, or for an unrecognised or over-long value, show nothing.

17.2. Polite lookup rules (while WHOIS is the only method)

These rules apply when the capability of Section 15 is not active. When it is active, the client sends no WHOIS lookups for avatars at all (Section 15.7). They exist so that learning avatars never costs anybody anything: not the network, not the other things the client wants to send, and above all not the person who is typing.

A client that uses WHOIS to learn avatars:

• keeps one lookup per user, cached until that user quits; moves the entry on a nick change; does no timed or repeated polling;
• sends at most one background lookup every 3 seconds per connection, and only on spare capacity: it waits while lines are queued behind its own flood limiter, while its send budget is low, while it is not registered, and for about 10 seconds after the person typed a WHOIS; it caps the backlog (400 users). A channel of 100 people is therefore learned in about 5 minutes, which is accepted;
• looks up people who have just joined or just spoken before the rest of the backlog, and the names of a channel it joined last; skips users known not to be logged in when account information is available (Section 8.3);
• makes background lookups silent: it never prints their results;
• sends a WHOIS that the person typed immediately, past any queue the client has, and always shows its answer. A client MUST NOT treat that WHOIS as a background lookup, even when it is for the same nick as one in the queue, and pauses background lookups so that nothing delays the person's command. Two overlapping replies for one nick produce one visible result;
• counts the lookups in flight per nick (a count, not a flag), so that two lookups for one nick stay hidden;
• clears all cached avatars on disconnect.

Measurements on the live network on October 18, 2026 show that the server is not the limit: WHOIS replies were prompt when sent at one per second, and a WHOIS typed by a person during a run of background lookups was answered in about 0.1 seconds. Slow answers seen in clients came from the clients' own queues, which is why the rules above are about the client's side.

17.3. Decisions shared by the implementations

Where this memo was silent, the implementers of the macOS/iPhone client and of the Windows client took the same decisions. They are recommended for other clients:

1. Withdrawal is sticky. After -CR-AVATAR nothing re-enables avatars (not a 320 line, not an AVATAR message, and not the name of the server) until a later CR-AVATAR=<n>. An AVATAR message received after a withdrawal is still stored, and drawn once avatars are supported again.
2. An active capability counts as support (Section 15), unless a withdrawal was received.
3. The own nick is looked up like any other; names that start with * are not looked up.
4. A cached avatar stays until the user quits, also after the user left the last channel the client shares with them (with the capability nobody tells the client about a later change of such a user).
5. Invalid values. A value with any Unicode whitespace or control character, or over 16 UTF-8 bytes, is invalid; it is ignored and the previous value stays. (Section 7.2.)
6. Nicks are case-insensitive. A client SHOULD fold nicks with the network's CASEMAPPING, as it does everywhere else: the live network announces CASEMAPPING=ascii and a client folds by whatever its own 005 says.
7. WHOIS answers this client did not ask for. A bouncer relays the answers to one device's WHOIS to every attached device. While avatars are supported (or a bouncer is detected), such an answer is not shown, but its 320 line is learned. When avatars are not supported it is shown as usual.
8. Chat lines show the current avatar of the nick, so a change also changes older lines on the screen.
9. AVATAR :two words (trailing form, with a space) is invalid; AVATAR two words is the avatar two with the name words (Section 15.3).

18. Conformance

18.1. Client authors

A conforming client:

1. [ ] detects avatar support by the CR-AVATAR token or by a matching 320 line, never by address, vhost or server-name suffix (Section 14.2);
2. [ ] works through a bouncer, because it relies only on forwarded 005 tokens and numerics (Section 14.1);
3. [ ] turns avatars off and clears its cache on -CR-AVATAR and on disconnect (Sections 14.2 and 17.2);
4. [ ] parses the 320 line with the expression of Section 8.2, keeps the whole emoji including U+FE0F and zero-width joiners, and rejects values longer than 16 bytes (Section 7.2);
5. [ ] treats a 320 line that does not match as an ordinary WHOIS line (Section 7.4);
6. [ ] shows nothing for the operator badge text in chat and the user list unless it has a badge of its own (Section 7.4);
7. [ ] follows the display guidance of Section 17.1, including the blank slot only on a network that supports avatars;
8. [ ] follows the lookup rules of Section 17.2: one lookup per user, at most one every 3 seconds per connection and only on spare capacity, silent background lookups, a typed WHOIS sent at once and always shown;
9. [ ] if it requests conferencerooms.org/avatar, handles AVATAR and AVATAR * as in Sections 15 and 16, accepts them in any order, lets a later one replace an earlier one, accepts them for nicks it does not list yet, and treats its own entry like any other (Section 15.8);
10. [ ] sends no avatar WHOIS lookups while the capability is active (Section 15.7).

18.2. Ircd and services authors

A conforming ircd and services:

1. [ ] advertise CR-AVATAR=<version> in 005 only while services are linked, and send -CR-AVATAR when they leave (Section 14.1);
2. [ ] keep the token the same for clients behind a bouncer (nothing in the token depends on the connecting address);
3. [ ] send the 320 line as in Section 7, in the exact form has an avatar set: <emoji> :<name>:;
4. [ ] accept an avatar tag only from services (Section 6.6);
5. [ ] if the capability is offered, send AVATAR after the NAMES reply, after a JOIN, and on every change, and never more than once per client for one change (Sections 15 and 16);
6. [ ] derive AVATAR from the tag they hold, so that every server of a multi-server network produces the same message (Section 15.5);
7. [ ] answer WHOIS as before when the capability is not negotiated.

Modules for other ircds: ircd-hybrid (available, see Appendix B); more to come.

18.3. Implementation status (October 18, 2026)

Services were not changed: the ircd derives everything from the avatar tag that it already received (Section 15.5).

What was tested. The ircd: 19 checks on a scratch ircd with its own services (capability, token, burst after 366, joins, changes, removal, one message per client, no message for a client without the capability, WHOIS unchanged, services leaving), 5 more for services leaving and returning, and 9 checks on the live network with one temporary account that was dropped afterwards. The Windows client was also run against that scratch ircd. The clients: scripted server lines (Section 13.4) and the reference ircd of the implementers.

Live verification of the Textce macOS/iPhone client (October 18, 2026, irc.conferencerooms.org). CAP LS lists conferencerooms.org/avatar; the 005 line has CR-AVATAR=1; the capability is acknowledged; 11 AVATAR lines arrive after the NAMES reply in #lobby; avatars show about 7 seconds after connecting; no WHOIS lookup is sent; no WHOIS block is printed; a typed /whois is answered in 0.1 seconds.

Live verification of the Textce Windows client (October 18, 2026, irc.conferencerooms.org, a guest nickname over TLS, only #lobby joined). /avatars reported "bulk: the server sends AVATAR messages, no WHOIS lookups", the token CR-AVATAR=1, the capability active, 11 avatars known, no lookups waiting and 0 lookups sent. The user list showed the emoji beside the nicknames. No WHOIS block was printed. A typed /whois was answered and showed has an avatar set: 🎤 :mic: (its time was not measured). (The live tests used guest connections only, and the client said nothing in the room.)

What was not tested. A second linked server, a netsplit, the operator badge appearing or disappearing, the network switch of Section 11.1, an iPad, and any connection through a bouncer. For a bouncer in front of the ircd (the network's own ZNC at hostmask.org:16888 is the test case) this is only an expectation, and it is unconfirmed: ZNC forwards the 005 token but does not offer a capability that it does not know, so clients would fall back to the quiet WHOIS lookups of Section 17.2 (one every 3 seconds). Whether ZNC or soju pass the capability and the AVATAR lines to a client has not been checked.

18.4. Verified clients

Textce IRC Client for macOS and iPhone, verified October 18, 2026, with scripted server lines and against a reference ircd. Textce IRC Client for Windows, verified October 18, 2026, with scripted server lines (91 checks), against a reference ircd, against a scratch ircd-conferencerooms and against the live network. Both:

• Detection (Section 14). They turn avatars on when they see CR-AVATAR=<n> in 005, or a matching 320 line on the connection, and record <n>. They do not refuse an unknown version. On -CR-AVATAR they turn avatars off, clear every cached avatar and stop lookups. They do not decide by the typed address or the vhost. They do not decide by the name of the server either: the temporary workaround that earlier revisions allowed has been removed from the Textce clients, and a client test shows that a server named conferencerooms.org does not enable avatars by itself.
• Capability (Section 15). They request conferencerooms.org/avatar with CAP REQ whenever the server lists it.
• AVATAR message (Sections 15 and 16). :nick!user@host AVATAR <emoji> [<name>] sets or changes the avatar of the nick in the prefix, and AVATAR * clears it. A value with a space or any control character, or over 16 bytes, is ignored. The name is accepted but not used for display.
• Lookups (Sections 15.7 and 17.2). While the capability is active they send no avatar WHOIS lookups at all. Without the capability they fall back to quiet WHOIS lookups under the rules of Section 17.2 (at most one every 3 seconds, on spare capacity, people who just joined or spoke first); a WHOIS typed by the person leaves at once and is always shown.
• Display (Section 17.1). The avatar is between the mode badge and the nick in the user list (a blank slot for users without one only on networks that support avatars), immediately before the sender's nick in the chat window, and in WHOIS as <nick> has an avatar set: <emoji> :<name>:. Nothing is shown for no avatar, an unsupported network or an invalid value.
• /avatars. Both clients have a command /avatars that prints how avatars work on the connection: whether they are off, in bulk mode (the capability is active, no WHOIS lookups) or in the WHOIS fallback, the state of the 005 token (not seen, CR-AVATAR=<n>, withdrawn), whether the capability is active, how many avatars are known, how many lookups wait and how many background lookups were sent (a typed WHOIS is never counted). It is meant for testing a network, a bouncer or a new ircd.
• Decisions of Section 17.3.

19. Relationship to Other Work, and a Request for Consideration

19.1. Relationship to Other Work

CR-AVATAR was designed to work with every IRC client that exists, without negotiation, and so it uses an existing reply line instead of a new capability. Other specifications serve similar needs by other means, among them the message tags [IRCV3-MT] and the metadata specifications of IRCv3; the following is a possible alignment, not part of the protocol of Sections 4 to 11:

• The avatar could be published as a metadata key named avatar whose value is the emoji (in IRCv3 metadata, for instance). A server that implements both would derive the WHOIS line of Section 7 from the metadata value, so that old and new clients see the same avatar.
• Services could send the avatar as the user's metadata instead of as a services tag.
• A message tag could carry the sender's avatar on each message, so that a client does not need WHOIS. A client-only tag would be chosen so that servers do not have to understand it.

The line of Section 7 would remain as the fallback for clients without those features.

19.2. Request for consideration

ConferenceRooms.org would like this work to be considered by the wider IRC community, by the developers of IRC servers, clients and services and, if they find it of interest, by the IRCv3 Working Group, in whatever form each finds suitable.

The authors understand that standards groups publish their work as their own specifications, in their own formats and through their own processes, and that many of them, the IRCv3 Working Group among them, do not use the RFC form of this memo. This document is written in the form of an RFC only because that is a clear and well-known way to describe a protocol completely: its wire format, its behaviour and its test vectors. The form is not a condition. If a group wishes, the authors will gladly rewrite it in that group's own form (for example as a capability, a metadata key or a message tag), change any part of the design the group finds unsuitable, and take part in the review.

Even if no group decides to adopt it, the authors ask that this implementation be considered a positive contribution to the future of IRC: working code, in production on a public network, that shows one way for IRC to become a more social and more personal platform without giving up what makes IRC open and simple.

19.3. What this contribution offers

• Personal, without personal data. A user can be recognised by a small picture of their own choosing, with nothing uploaded and nothing revealed. Many chat services ask for a photograph or an image file, and those carry hidden information: the user's face, the place and time of the picture, the device that made it, and the address of whoever fetches it later. CR-AVATAR has none of that. The avatar is chosen from a public list of emoji, so it says nothing about who the person is, where they are or how old they are.
• Nothing to fetch. There is no URL, so no client ever contacts a third party to show an avatar, and nobody can learn which users are looking at whom.
• Nothing to store or moderate. There are no files, no image hosting and no uploads to review, so a small network can offer it at no cost, and nothing harmful can be uploaded.
• Open and simple. It is one line of text in an existing reply, and it needs no new capability, no new command and no change to the IRC line format. Any server, client, bot or gateway can implement it in a few lines (Sections 8 to 10).
• Kind to old clients. Every existing client shows the line as text (Section 8.5), so the network never has to choose between the new and the old.
• Social. Avatars make a conversation easier to follow and a community easier to recognise, for people who use IRC from a phone or a browser as well as from a terminal.
• Tested and in use. The protocol runs on irc.conferencerooms.org, with a web client and an IRC server and services that anyone can connect to (Section 13.3) and a conformance test that is part of the reference implementation.

19.4. Branding

An avatar is the smallest piece of visual identity that a person, a community or a company can carry across every place IRC is used. CR-AVATAR gives IRC that piece while keeping the protocol plain text, and it ties into branding in the following ways, all of which the protocol already permits.

• A network can have its own look. Section 4.2 lets a network publish its own catalogue. A game studio, a school, a charity or a company can choose a set of emoji that suits it (for example a set of animals, tools or symbols for its community), name the entries in its own words, and keep the rules of Section 4.1. Every client that follows Section 8 displays them without any change.
• A badge for staff and officials. Section 11.2 defines badge text for IRC operators. A network MAY use the same form for other roles that a brand wants to make visible, for example has an avatar set: Acme Support (verified staff) for a support agent, ... (moderator) for a volunteer or ... (speaker) for a guest at an event. The text is sent by the services only, so users cannot give it to themselves (Section 20), and it is plain text that a legacy client can read. Branded roles can make official voices recognisable in a public room.
• Brand art in your own clients and gateways. The name in :name: is a stable key. A web chat, a mobile application or a branded IRC client MAY replace the emoji with its own artwork for that name (the ConferenceRooms.org web chat, for example, draws the network's logo on a rounded tile for its operators, while an IRC client sees the badge text). The line on the wire stays the same, so a brand can have rich, trademarked artwork in its own program and still be fully interoperable with every other IRC client.
• One identity on every surface. Because the avatar belongs to the account and not to a connection (Section 5.2), the same avatar follows the user from the web client to the phone to a terminal client, and a brand's staff look the same wherever they connect.
• Recognition without a picture file. A logo, a mascot or a face is never carried on the wire, so a brand does not have to host, license or protect image files, and the name or emoji can be used in text, in a topic, in a transcript or in a log.

A brand SHOULD keep the interoperable form of Section 7.2 even when it adds artwork of its own: the emoji and the name (or the badge text) are what every other client and every log will show.

19.5. Commercial IRC Development

IRC is used by communities, support desks, game and open-source projects, classrooms, events and companies. For these users CR-AVATAR has the following value.

• A reason to choose IRC. The chat products people compare IRC with all show faces and icons next to names. An avatar that works in every IRC client, and that costs the operator nothing, removes one of the usual reasons given for choosing a proprietary chat service.
• Lower cost to run. There is no image hosting, no content delivery, no storage and no review of uploaded pictures, which are the costs and risks that make profile pictures expensive for a small or hosted network. The only data kept is one short value per account.
• Less personal data to protect. The system never receives, stores or sends photographs, locations or other personal information (Section 19.3). A service that offers it handles less personal data than one that accepts image uploads, which can make its privacy and safety obligations easier to meet. Each operator remains responsible for its own legal compliance.
• A product feature for hosted IRC. A company that hosts IRC networks for customers can offer avatars, a custom catalogue and staff badges as part of its service, and can show the same identity in the web and mobile clients it provides.
• A way for clients to compete. The protocol fixes what is sent, not how it is drawn. A commercial or open-source client can compete on the quality of its rendering, its artwork sets and its themes while staying compatible with everybody else (Section 8.4).
• Room for tiers and policy. Which avatars a user may choose, and who may have a badge, are decisions of the services (Section 5.3). A network MAY, for example, reserve some catalogue entries for members, supporters or staff. This is local policy and is not part of the protocol.
• Open and free of lock-in. Because the format is open and implementable in a few lines, no vendor controls it. A company that builds on it can change servers, clients or hosting without losing its users' avatars.
• Support and trust. Visible staff badges make it easier for customers to see who in a public support room is an official representative.

The authors encourage commercial developers to implement CR-AVATAR, to publish their own catalogues and badges following Section 4.2 and Section 11.2, and to report what they learn.

The authors intend the protocol described in this document to be implemented freely by anyone, for any IRC server, client, bot or gateway, and welcome comments, corrections and competing designs. Questions and proposals may be sent to the operators of ConferenceRooms.org through https://www.conferencerooms.org/.

20. Security Considerations

• Forgery. Anybody who can send the avatar tag can give any user any WHOIS line. Only services may send it (Section 6.6). A server MUST NOT accept it from clients or from servers that are not services.
• Injection. The text is data. A server MUST reject (or truncate before the first of) the bytes CR (0x0D), LF (0x0A) and NUL (0x00) in the text, as in any IRC message. A client MUST NOT interpret the text as anything but display text and SHOULD remove control characters and the IRC formatting characters (0x02, 0x03, 0x0F, 0x16, 0x1D, 0x1F) before display.
• Size. The text of an avatar line SHOULD NOT exceed 120 bytes. The avatar emoji SHOULD NOT exceed 16 bytes. A client MAY ignore longer values.
• Tracking. There is no URL, so there is no request to a third party. A client MUST NOT turn the name, the emoji or any other part of the line into a request for a picture.
• Moderation and abuse. Because the choice is limited to a closed list, no offensive picture can be uploaded. A network that extends the catalogue should not add emoji that are commonly used as slurs or as signs of hate groups.
• Denial of service. Services send nothing for unchanged users (Section 6.5). A server MAY limit how many tags one user can have and how fast services can change them.
• Spoofing the operator badge. Because the avatar is chosen from a closed catalogue and the badge text of Section 11.2 can only be sent by services, a user cannot display it by choosing an avatar.
• Fonts. A missing glyph is shown as a box or as the two letters of a flag. This is cosmetic. The :name: lets the viewer know what was meant.

21. Privacy Considerations

• The avatar is public: everybody who can WHOIS the user can see it. It is never secret, and users are told so when they choose one.
• It is shown only while the user is online and identified. It is never shown to someone who cannot see the user.
• It carries no information about the user's age, location or other profile data. The ConferenceRooms.org services keep those separate; setting or removing an avatar does not change them.
• A network that wants avatars hidden can switch the line off for everybody (Section 11.1).
• No avatar is assigned to an ordinary user by default: a user has one only after choosing it (Section 11.3 describes the one exception a network may make, for automated clients).

22. IANA Considerations

This document makes no request of IANA. It uses the numeric reply 320, which is not defined by [RFC1459] or [RFC2812]. Servers that use 320 for other purposes are handled by Section 7.4. If this work is adopted by a standards body, the authors suggest that it assign a distinct numeric or use the metadata or message-tag mechanisms of Section 19 (those of IRCv3, for example).

23. Acknowledgements

This memo and the avatar system it describes are the work of ConferenceRooms.org and its author, Richard Ward (zeamp), who designed the catalogue, the services behaviour, the server and client behaviour and the web chat integration, and deployed them on the ConferenceRooms.org network on October 16, 2026.

24. References

24.1. Normative References

• [RFC1459] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993.
• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [RFC2812] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, April 2000. https://www.rfc-editor.org/info/rfc2812/
• [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
• [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
• [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.

24.2. Informative References

• [UTS51] The Unicode Consortium, "Unicode Technical Standard #51: Unicode Emoji".
• [IRCV3-MT] IRCv3 Working Group, "Message Tags". https://ircv3.net/specs/extensions/message-tags
• [WHOX] IRCv3 Working Group, "WHOX". https://ircv3.net/specs/extensions/whox

Appendix A. The Avatar Catalogue, Version 1

The catalogue of ConferenceRooms.org. Each row gives the name, the code point(s) of the emoji (a trailing U+FE0F is shown when the entry carries it) and the emoji. It is generated from the services source file that enforces it, so it is exactly what the network accepts.

Category: animals (49)

Category: faces (25)

Category: nature (21)

Category: food (22)

Category: things (43)

Category: symbols (24)

Total: 184 entries.

Appendix B. Where the Reference Implementation Is

All of it is written by ConferenceRooms.org (Richard Ward, zeamp). File names are relative to the project root of ConferenceRooms.org.

• Services, catalogue and the AVATAR command: services/crservices/avatars.py (class AvatarMixin, functions lookup, avatar_whois).
• Services, publishing the tags: services/crservices/extras.py (field_lines, field_tags, the 15 second refresh loop, and the network switch under the field name "Avatar").
• Server: ircd-conferencerooms/modules/m_svstag.c (handler), ircd-conferencerooms/src/client_svstag.c (tag list), ircd-conferencerooms/modules/m_whois.c (WHOIS output) and ircd-conferencerooms/modules/m_server.c (burst).
• Web chat: webchat/gateway/crwebgw/avatars.py and webchat/client/src/ui.ts.
• Tests: tests/test_cr_services_e2e.py (rounds 9 and 10), tests/test_round10.py and tests/test_botavatars.py.
• User documentation: https://www.conferencerooms.org/help/avatars.html
• ircd-hybrid (stock 8.2.47): module cr_avatar 0.1.0, open source (GPL-2.0-or-later), 74 automated checks on a scratch ircd (21 module checks and 16 link and netsplit checks, each on plain connections and again over TLS); not run on a production network by its authors. Download, install steps and tests: https://www.conferencerooms.org/help/cr-avatar-ircd-hybrid.html
• The CR-AVATAR ISUPPORT token, the capability conferencerooms.org/avatar and the AVATAR message: ircd-conferencerooms/modules/cr_avatar.c (a module that derives everything from the services tag), with two small hooks in src/channel.c and src/ircd_hook.c and the capability bit in src/cap.h. Services were not changed.

Appendix C. Collected ABNF

avatar-name   = 1*( %x61-7A / DIGIT / "-" )
avatar-emoji  = 1*( %x21-7E / UTF8-2 / UTF8-3 / UTF8-4 )
                ; UTF8-2/3/4 as in RFC 3629; at most 16 octets; no
                ; SPACE, no control character (Section 7.2)
catalogue-emoji = emoji-cp [ %xFE0F ]   ; entries of Appendix A only
emoji-cp      = <a code point listed in Appendix A>
avatar-text   = "has an avatar set: " avatar-value
avatar-value  = avatar-emoji [ SPACE ":" avatar-name ":" ]
              / badge-text
badge-text    = 1*( %x20-7E )
avatar-tag    = ":" source SPACE "SVSTAG" SPACE target-uid SPACE ts
                SPACE "320" SPACE modes SPACE ":" avatar-text
clear-tags    = ":" source SPACE "SVSTAG" SPACE target-uid SPACE ts
                SPACE "-"
modes         = "+" *( ALPHA )
ts            = 1*DIGIT
whois-320     = ":" server SPACE "320" SPACE viewer SPACE target
                SPACE ":" avatar-text
isupport-token = "CR-AVATAR=" 1*DIGIT      ; Section 14.1
isupport-off   = "-CR-AVATAR"
cap-name      = "conferencerooms.org/avatar"   ; Section 15.3
avatar-msg    = ":" nick "!" user "@" host SPACE "AVATAR" SPACE
                ( avatar-emoji [ SPACE avatar-name ] / "*" )

Appendix D. Observed WHOIS Replies

The three transcripts of Section 7.5 are repeated here for implementers, as test input for a client's WHOIS parser. Each of the lines shown by the client was received as one numeric reply; only the 320 line is the avatar line.

[registered user]   :irc.conferencerooms.org 320 Viewer dmitri :has an avatar set: 🍕 :pizza:
[operator]          :irc.conferencerooms.org 320 Viewer zeamp  :has an avatar set: ConferenceRooms logo (network operator)
[name with FE0F]    :irc.conferencerooms.org 320 Viewer lilbit :has an avatar set: 🕷️ :spider:

Expected results of the parser of Section 8.2: the first and the third give an emoji and a name (the third keeps its U+FE0F); the second is ignored.

Appendix E. Authors' Address

Richard Ward (zeamp)
ConferenceRooms.org
https://www.conferencerooms.org/
IRC: irc.conferencerooms.org, ports 6697 (TLS) and 6667