relaydmessage accountability
The life of an ID
Read from live source

One msg_id, minted once, carried the whole way

A message's identity is stamped once at ingress and rides inside the message's Meta across every boundary. Each stage writes one append-only ledger line keyed on that id — so grep <msg_id> relay-events.jsonl reconstructs the message's entire life. The blue rail is the id's journey; the grey cards below it are the ledger lines it leaves behind.

The ID as a spine, the ledger as its shadow

id carried in Meta ledger line (keyed on id) terminal outcome reply — its own id
IngressTelegram / Discord msg_id = a1b2c3… ✦ minted Gate chainin relayd rides in Meta → Cross the socketIPC Frame.Meta same id in the frame → Model turn<channel msg_id=…> visible to the model → Replygets a NEW msg_id msg_id = d4e5f6… ✦ new receivedaccepted inbound gate_blockedrefused before model injected / bufferedto session, or queued replymodel produced output send_ok / send_failedfrontend confirmed / not in_reply_to → links the reply back to the inbound msg_id it answers reply_id: a 2nd id, confirms THIS send

Minted once, never re-issued

Six random bytes at ingress (NewMsgID), stamped into Meta. Even the error fallback returns a weak-but-present id — an empty id "breaks traceability," so it's never allowed.

Carried, not looked up

The id lives inside the message's Meta, which flows into the IPC frame and becomes a <channel> tag attribute — so the message and its id can never be separated.

Body never logged

Every ledger line carries the id, chat/from ids, and a byte count — but not the content. The audit trail can be kept and shared without leaking conversation.

Two ids, two jobs

msg_id answers "what happened to this message?" forever; the reply's reply_id correlation id answers "did this one send succeed?" right now — refusing to report a false "sent."