5-RRC: Optional Conventions, Nicknames, Moderation, and Bots¶

Version: 0.1.1

1-RRC through 4-RRC define a complete, functional live chat system. You could stop there and still have something useful. This document exists because humans inevitably ask for a little more comfort once the basics work.

5-RRC does not introduce new required protocol mechanics. Everything here is optional, conventional, and intentionally soft-edged. Implementations may adopt these ideas in whole, in part, or not at all. Ignoring this document does not make an implementation non-compliant with RRC.

The goal here is to standardize common behavior without forcing it, so that clients and hubs can interoperate politely instead of inventing incompatible social norms.

Nicknames¶

Nicknames exist to make chat readable by humans. They are not identity, they are not authoritative, and they are not permanent.

A nickname is a label associated with a client’s current session. It may be declared during HELLO via the envelope nickname field or changed later during an active session. The hub may accept it, modify it, reject it, or ignore it entirely.

Nicknames are not guaranteed to be unique. Two clients may choose the same nickname. If this causes confusion, that is a social problem, not a protocol failure. Implementations may choose to disambiguate nicknames visually, but the protocol does not mandate how.

If a hub enforces nickname rules, such as length limits or character restrictions, it should communicate violations using ERROR. If it does not enforce rules, chaos is permitted.

When a client disconnects, its nickname disappears with it. Reconnecting does not reserve or reclaim anything.

Nickname Changes¶

Clients may request a nickname change during an active session. This is typically done using a message type or body convention agreed upon by the hub and client.

If a nickname change is accepted, the hub may notify other room members. If it is rejected, the hub should respond with ERROR or silence. Either outcome is valid.

Clients should not assume nickname changes are atomic or globally synchronized. They are best-effort announcements.

Basic Moderation Concepts¶

RRC does not define a full moderation system. It does, however, acknowledge that unmoderated spaces tend to self-destruct.

Moderation in RRC is hub-local and entirely discretionary. There is no global authority, no shared ban list, and no expectation that moderation decisions propagate beyond a single hub.

Common moderation actions include forcibly removing a client from a room, preventing a client from joining specific rooms, or closing a client’s Link entirely. All of these actions can be implemented using existing protocol behavior without introducing new message types.

If a hub removes a client from a room, it may do so silently or by sending an ERROR or NOTICE explaining what happened. The protocol does not require politeness.

If a hub closes a client’s Link, that action is final for the current session. The protocol does not define a way to appeal, argue, or negotiate.

Soft Authority and Trust¶

Hubs may choose to grant special privileges to certain identities. These identities might be moderators, operators, or bots. How this trust is established is outside the scope of the protocol.

Clients must not assume that privilege exists unless the hub demonstrates it through behavior. There is no on-the-wire role declaration required.

Trust is contextual, local, and fragile by design.

Bots as First-Class Citizens¶

Bots in RRC are just clients. They connect over a Link, send HELLO, join rooms, and send messages. There is no special bot flag required by the protocol.

A bot may choose to announce itself as such using nickname conventions or NOTICE messages. This is optional but considered polite.

Bots are expected to follow the same rate limits and behavioral rules as human-operated clients. If a bot misbehaves, it should be disconnected just as quickly as anyone else.

Logging and Archival¶

Because hubs do not store message history, logging is expected to be handled elsewhere.

For example, a logging bot may join one or more rooms and record all messages it receives. This bot may store logs locally, forward them elsewhere, or expose them via another protocol. RRC does not care.

Clients that want history should arrange access to a logging bot out of band. There is no standardized “replay” mechanism in RRC itself.

This design keeps the core system simple while still allowing persistence for those who want it.

Presence and Status Messages¶

RRC does not provide a formal presence system beyond Link state. However, some implementations may wish to convey soft presence information such as “away,” “busy,” or “idle.”

These signals may be implemented using NOTICE messages or structured MSG bodies by mutual agreement. Other clients may ignore them entirely.

Presence information is advisory and ephemeral. It should not be treated as reliable or authoritative.

Client Capability Signaling¶

Clients and hubs may optionally advertise capabilities, such as support for structured message bodies, rich text, or moderation commands.

This signaling is typically done during HELLO or WELCOME using body fields or extension keys. Clients must assume that capabilities are hints, not guarantees.

If two peers do not share a capability, communication should gracefully degrade to plain text and basic behavior.

Extensions and Restraint¶

RRC is intentionally extensible. That does not mean every implementation should extend it enthusiastically.

Extensions should be clearly documented, should not redefine existing message types or semantics, and should fail quietly when unsupported.

If an extension requires persistent state, complex synchronization, or strong delivery guarantees, it may be a sign that it does not belong in RRC at all.