CR-Avatar for services authors

Services own the avatar. The ircd cannot invent it, and clients never ask services about it.

What services must do

1. Store one avatar per registered account: a name from the fixed list (version 1: 184 entries, see the specification) and its emoji. Nothing but text.
2. Offer a command such as /avatar <name>, /avatar off, /avatar list. Reject names that are not in the list. Only identified accounts may set one.
3. Tell the ircd whenever it changes: on identify, change, removal, logout, account drop, and in the burst after a link comes back.

For ircd-hybrid and its derivatives: the SVSTAG form

:<services SID> SVSTAG <nick or UID> <TS or 0> 320 + :has an avatar set: <emoji> :<name>:
:<services SID> SVSTAG <nick or UID> <TS or 0> -

• Numeric 320, user-mode field + (visible to everybody; ircd-hybrid needs the field to begin with +).
• The text must start with has an avatar set: , then the emoji (at most 16 UTF-8 bytes, no whitespace or control characters), then optionally :name: (lower-case letters, digits and hyphens).
• - removes all services tags from the user.

The two details that matter

1. ircd-hybrid appends tags, it does not replace them. To change an avatar: send SVSTAG ... -, then re-send every tag the user should have, including the new avatar. The ircd module waits until the new value was seen twice, one second apart, so clients see one clean change 1 to 3 seconds later.
2. After a restart or a new link, re-send everything. The ircd announces whatever comes back as changes.

The operator badge

Operators who have not chosen an emoji can get a text badge (ConferenceRooms logo (network operator)). It is shown in /whois only and is never announced to clients. It does not match the avatar pattern on purpose.

See also: CR-Avatar for ircd-hybrid.