# 0061 — Messages get a node-scoped short-ID that is also their served URL

Status: accepted (2026-09-06 WEBSERVE grill round 2, releases#272 / #147 / #148)

## Context

#147 wants a message to be referable — in a chat line, from the CLI, and as a link that opens
a rendered view of it. The choice was between a globally unique id (long, or coordinated) and
a short id that is unique per node and rides the node prefix for global meaning.

## Decision

**A message's short-ID is 8 characters of base32 over the message's existing hash, scoped to
the node that holds it.** Its served URL is `/<node>/m/<short-id>` (ADR-0056, Q7 grammar), so the
same token is both the thing you say in chat and the thing you click. The CLI reads and answers
it: `spt msg show <id>` renders one message with its attachment links; `spt send --reply-to
<id>` carries the parent id in the envelope so adapters may render a thread. The id appears in
the delivery envelope and in the `MSG_IN` / `MSG_OUT` IO events, so an adapter never has to
derive it.

## Alternatives rejected

- **Globally unique ids.** Either long enough to be unsayable or coordinated across nodes.
  Rejected: the node prefix already exists and already makes URLs global.
- **Sequential per-node counters.** Short, but they leak volume and collide across a store
  rebuild. Rejected in favour of a hash-derived token that is stable across rebuilds.

## Consequences

- #148's outbound ledger keys on the same id; nothing mints a second identifier later.
- Eight base32 characters over a hash is not collision-proof in principle; a collision on one
  node is detectable at mint time and resolved by lengthening that one id, which the grammar
  permits since the id is opaque to readers.