0-RRC: Introduction to Reticulum Relay Chat

What This Is

Reticulum Relay Chat, abbreviated RRC, is a live chat system built on top of the Reticulum Network Stack. It exists to let people talk to each other in real time over Reticulum without dragging in message databases, synchronization engines, or architectural commitments they did not ask for.

RRC is closer in spirit to IRC than to modern “everything platforms.” You connect, you join a room, you talk, and then you leave. If you were present, you saw the conversation. If you were not, the conversation did not wait for you.

This is not an accident. This is the entire design.

Why RRC Exists

Reticulum already provides secure identities, encrypted links, and flexible transport. What it does not provide out of the box is a simple, low-friction way for groups of people to talk to each other live without committing to long-term storage or guaranteed delivery semantics.

Many messaging systems assume that every message must be preserved, indexed, replicated, and retrievable forever. This assumption leads to complexity, resource usage, and social expectations that are not always desirable. RRC deliberately rejects that assumption.

RRC exists for conversations that are ephemeral, contextual, and situational. It is for coordination, discussion, collaboration, and presence. It is for “are you there right now” rather than “please archive my thoughts for future archaeology.”

What RRC Is Not Trying to Be

RRC is not email. It is not a mailbox. It is not a distributed ledger of human thought.

It does not guarantee delivery to offline clients. It does not provide message replay. It does not synchronize history between devices. If you disconnect, you miss things. If you reconnect, you start fresh.

RRC is also not a federation protocol. Hubs do not synchronize state with each other. There is no global namespace. Each hub is its own local universe, and that is considered a feature.

RRC does not attempt to solve moderation at a global scale, identity recovery, or social trust. Those problems are real, but they are not free, and they are not forced on everyone by this protocol.

The Core Idea

The core idea behind RRC is embarrassingly simple.

A hub exists. Clients connect to it using Reticulum Links. Clients join rooms. Messages sent to a room are forwarded to other clients currently in that room. Once forwarded, messages are forgotten.

There is no hidden machinery behind this. The hub is a router, not a historian.

This simplicity allows hubs to run on very small systems, including single-board computers. It allows the protocol to be implemented in a small amount of code. It allows failures to be obvious instead of subtle.

Why Reticulum Is a Good Fit

Reticulum already solves the hard problems RRC would otherwise need to solve badly.

Identity is handled by cryptographic keys. Authentication is implicit in the Link. Encryption is built in. Routing exists independently of application concerns. Presence can be inferred from Link state.

RRC builds on these guarantees instead of reimplementing them. The protocol does not attempt to layer additional security theater on top of what Reticulum already provides.

Design Values

RRC values clarity over cleverness. If something can be explained in one paragraph instead of a diagram, the paragraph wins.

RRC values local control. Each hub decides how it operates, who it accepts, and how it enforces behavior. There is no central authority.

RRC values failure modes that are obvious. Messages may be lost. Connections may drop. When that happens, the system becomes quiet instead of corrupt.

RRC values extensibility without obligation. You can add features on top, but the base protocol does not require them.

What This Specification Set Covers

The RRC specification documents define a simple, yet complete protocol stack for live chat over Reticulum.

They describe the message format, message types, session behavior, and optional conventions. They do not prescribe user interfaces, visual layout, or community rules. Those choices are left to implementers and operators.

A reference implementation exists to demonstrate correctness and provide a starting point, not to declare a single “official” way of doing things.

Who This Is For

RRC is for developers who want a chat system that respects the nature of networks instead of pretending they are always online and perfectly synchronized.

It is for communities that want live interaction without the overhead of permanence.

It is for people who understand that sometimes missing a message is better than building an infrastructure that never forgets anything.

Final Warning

RRC will feel incomplete to people who expect guarantees, history, and permanence by default. That discomfort is intentional.

If you want a system that remembers everything, there are many options available. RRC is for people who want something lighter, simpler, and more honest about what networks can and cannot promise.