Name registration for serve-led sessions

What it does

Lets a session led by ganja serve register its name the way an interactive lead does (D527), so other sessions can address it by name. The record's lifecycle is the one the TUI already follows: one writer per record, removal before the socket stops answering, and a collision notice shown wherever serve shows notices.

Source

ganja-code-kwf (name registration for serve-led sessions).

The bead is closed when this issue is published, with its external reference pointing here (#38).

File and line references in this issue are to main as of 75a7a92.

Against the three criteria

• Direction (README): The README's Design section puts ganja's direction in the cloud with ganja as the control plane (README.md:16-18). serve and attach are the one road that exists today for running the engine away from the terminal.
• Today's terminal users: A serve-led session registers nothing today and cannot be addressed by name from another session.
• Evidence: The gap is known from the code. The bead records why registration alone would be wrong: a bound inbox that nothing drains tells the sender a message arrived that nobody will read, which is worse than an honest refusal.

Depends on

It presupposes giving ganja serve a peer drain and a way to review held messages; neither exists yet.

Verdict

• Verdict: do
• Size: M — it also presupposes a peer drain and a held-message review surface in ganja serve.
• Exception to the probe rule: no.
• Date: 2026-09-19
• Verdict ticket: #46

Theme: #52

Start with the Design section of README.md and compare the existing ganja serve and interactive-session name-registration paths. Before implementing registration, review how a peer drain and held-message review surface would work; done means serve-led sessions can be addressed by name, follow the stated record lifecycle, and show collision notices.