1-RRC: The Reticulum Relay Chat Protocol

Version: 0.1.1

Purpose

Reticulum Relay Chat, abbreviated RRC, is a live chat system built on top of the Reticulum Network Stack. It exists to provide near real-time group communication without dragging in message history databases, federation machinery, or architectural guilt.

RRC is intentionally simple. It does not pretend to be email, a mailbox, or a distributed archive. It behaves more like a conversation in a room. If you were there, you heard it. If you were not, you did not. That is not a bug, that is the point.

The hub’s job is to accept connected clients, keep track of which rooms they are currently in, and forward messages between them. Once a message has been forwarded, the hub forgets it ever existed. If someone wants logs, statistics, or archives, they can run a bot and record traffic themselves. This keeps hubs lightweight and cheap to operate, even on very small hardware.

Design Philosophy

RRC is built around the idea that infrastructure should do the minimum amount of work required to keep people talking. Anything more becomes fragile, expensive, or both.

Live chat is treated as a first-class concept. Clients maintain an active connection to a hub using a Reticulum Link. While that Link exists, messages flow reliably and in order. When the Link goes away, so does the conversation for that client. There is no attempt to fake presence or resurrect missed messages later.

Encoding is handled using CBOR. This is not because CBOR is trendy, but because it is compact, binary-friendly, and does not encourage the kind of deeply nested text structures that turn debugging into an archaeological expedition. CBOR maps with numeric keys keep messages small and parsing predictable.

The hub does not store messages. It does not buffer them for later delivery. It does not maintain a backlog. The hub forwards messages to connected room members and immediately discards them. This dramatically simplifies the implementation and removes entire classes of failure modes.

Non-Goals

RRC is deliberately not a universal messaging solution. It does not attempt to provide offline delivery guarantees, message replay, or long-term persistence. It does not attempt to federate hubs across networks, synchronize state between them, or resolve conflicts between competing room histories. It does not provide voice, video, or general media transport. It does not implement its own cryptography beyond what Reticulum already provides.

These omissions are intentional. Each one keeps the protocol smaller, easier to reason about, and easier to implement correctly. Other Reticulum protocols already exist to solve some of these problems, and RRC does not try to replace them.

System Model

RRC uses a hub-and-spoke model. Clients connect directly to a hub. All room membership and message routing happens at that hub. Clients do not talk directly to each other for chat purposes.

A client is any application that establishes a Link to a hub and speaks the RRC protocol. A hub is a server application that exposes a Reticulum Destination and accepts incoming Links from clients. A room is a named logical grouping that exists only as long as at least one client is interested in it.

Rooms are defined by name and current membership. They do not have an inherent lifetime, persistent state, or message history. If all clients leave a room, it effectively ceases to exist until someone joins it again.

Identity

RRC relies entirely on Reticulum identities. Every client is identified by its Reticulum Identity, and the canonical identifier used in protocol messages is the identity hash. There is no separate account system, no passwords, and no secondary authentication layer.

Human-readable nicknames may exist as a convenience feature, but they are not identity. They are advisory labels attached to a Link session and can change or collide without breaking the protocol. The identity hash remains the authoritative identifier at all times.

Transport

All RRC communication happens over a Reticulum Link established between a client and a hub. This Link provides reliable, ordered delivery, encryption, and authentication. RRC does not attempt to re-implement any of these properties.

If the Link drops, the client is considered disconnected. The hub immediately stops sending messages to that client and removes it from any rooms it was a member of. Reconnecting creates a new session with no implicit relationship to the previous one.

Hubs expose a Reticulum Destination specifically for RRC. The recommended naming convention for this Destination is rrc.hub, optionally followed by an instance tag if multiple hubs are operating in the same environment. How clients discover this Destination is outside the scope of the protocol, but once discovered, the Destination name is stable.

Encoding and Framing

All protocol messages are encoded as CBOR maps. Numeric keys are used instead of strings to keep frames compact and unambiguous. Clients and hubs must ignore unknown keys to allow forward-compatible extensions without breaking older implementations.

Every message uses the same basic envelope structure. The envelope includes a protocol version, a message type identifier, a sender-defined message ID, a timestamp, the sender’s identity hash, an optional room name, and a payload field whose meaning depends on the message type.

Messages may also include an optional nickname field. It is advisory only. Treat it like a sticky note, not a credential.

The protocol version allows incompatible changes to be introduced deliberately rather than accidentally. Version 1 is intended for the first public release. Experimental builds may use version 0 and are free to break without apology.

Rooms and Membership

Room names are human-readable strings, typically following IRC-style conventions such as #general or #radio. Hubs should treat room names as case-insensitive and normalize them internally to avoid confusion.

Membership is entirely ephemeral. The hub maintains a mapping of connected Links to rooms for as long as those Links exist. There is no persistence across disconnects, restarts, or crashes. If a hub restarts, all clients must reconnect and rejoin rooms manually.

When a client sends a chat message to a room, the hub forwards that message to all currently connected members of that room. Clients that are not connected at that moment will not receive the message. No attempt is made to compensate for this.

Reliability and Ordering

Within a single Link session, messages are delivered reliably and in order, as provided by Reticulum. RRC assumes this property and builds on it.

Across Link disconnects, no guarantees are made. Messages sent while a client is offline are lost to that client. This behavior is explicit and intentional. Any application that requires stronger delivery guarantees must implement them as an additional layer on top of RRC or use a different protocol entirely.

Security Considerations

RRC depends on Reticulum to provide encryption, peer authentication, and integrity protection. The protocol does not add an additional cryptographic layer and does not attempt to manage keys beyond what Reticulum already handles.

There is no account recovery mechanism, no password reset, and no identity escrow. Losing a private key means losing that identity. This is considered acceptable for the intended use case and avoids introducing centralized trust structures.