Render chat entries on the kind/author axes — system notes in history, agents distinct from owners, moderator indicator

[emooreatx]

GET /v1/chat/{id}/messages now returns entries on two axes instead of a message list, so one renderer can serve chat rooms, agent conversations, and (later) multi-user channels. Requesting the client side of that.

Server: CIRISServer fd18e8d (0.5.197).

The schema

Every entry in messages carries:

field	values	viewer-dependent?
kind	message | system | error	no
author	the attester's key_id (empty for system)	no
author_kind	person | agent | node | other | unknown	no
author_role	founder | member | operator-defined; absent if not on the roster	no
relation	self | own_agent | other | none	yes
mine	bool, exactly relation == "self"	yes
message_id	localization key; system/error only	no
body	text, or absent when the row could not be opened	no
unopened_reason	why it could not be opened	no
status	live | superseded | withdrawn | recanted	no

Why two axes and not one role

The obvious flat enum — self | other_human | my_agent | other_agent | system | error — was considered and rejected. It fuses two independent questions, and a channel breaks it:

• other_human collapses every other participant into one label, and the client still needs author to draw a name and avatar. In a 50-person channel it says nothing.
• my_agent vs other_agent is a relationship, so the same row is my_agent to one member and other_agent to another — but these rows are CEG objects replicated byte-identically to every member. A viewer-dependent value cannot be a property of the row.

So kind + author_kind are facts about the entry, relation is the derived convenience, and every combination you asked for is expressible:

you want	match on
self	relation == "self"
other human	kind == "message" && author_kind == "person" && relation == "other"
my agent	author_kind == "agent" && relation == "own_agent"
other agent	author_kind == "agent" && relation == "other"
system	kind == "system"
error	kind == "error"

This is the split Matrix makes (sender + event type, with "is it me" computed client-side). The system|user|assistant triple from LLM APIs is what we deliberately did not copy — it cannot say which user or which agent.

What we are asking for

1. Render kind distinctly. message as a bubble; system as a centered inline note in the transcript (not a toast, not a dialog — it belongs in history, in order); error as a note that reads as a problem.

2. Moderators. author_role == "founder" moderates — in a pair room both members are founders. Please show a mod indicator next to the name. Note the vocabulary is open: persist documents it as "founder / member / operator-defined", so treat unknown values as ordinary members rather than failing, and do not hardcode a two-value enum.

3. Agents must be visually distinct from the people who own them. author_kind == "agent" with relation == "own_agent" is your own agent speaking — same owner, not the same speaker. Rendering it as the user's own message would attribute a machine's words to a human.

4. unknown is a real state. Directory resolution stalls while a key body is in flight. Render neutrally and re-resolve later; do not fall back to "person".

5. Localized system notes. New ids, all currently rendering the server's English (see CIRISClient#36 — please fold these in with those):

id	English
chat.state.ready	End-to-end encrypted.
chat.state.awaiting_peer	Waiting for them to join this chat. They will see your invitation when their device next syncs, and your messages will send once they do.
chat.state.join_requested	Request to join chat sent. Waiting for them to let you in — this completes on its own once their device answers.
chat.state.no_author_signer	This device cannot act as you yet, so it cannot join the chat's key exchange. Create or unlock your federation ID to continue.

Each entry carries both message_id and the English in body, so render the lookup and fall back to body — never a blank line.

6. Do not offer a retry button when converges_on_its_own is true. The response carries it at the top level alongside ready. Both waiting states resolve when the peer's row replicates; a human pressing retry changes nothing, and offering the button says otherwise.

7. total counts what people said — system notes are excluded, so an unstarted conversation reports total: 0 with one entry in messages. Don't drive unread badges off messages.length.

Replaces

503 chat.room_not_keyed_yet is gone. A room that has not finished its key exchange is a 200 with a system entry. If the client has a special case for that 503, it can be deleted.

[emooreatx]

Correction to point 2, and it changes what the client must read.

author_role is not the moderation signal. Moderation is a delegable duty, not a role (CC §4.5.x). A founder or steward appoints a moderator by authoring a scoped delegates_to, and §11.11 merit auto-promotion emits the same shape — so a member whose roster role is plain member can hold real moderation authority, and reading author_role == "founder" would render them as an ordinary participant while they moderate.

Added in CIRISServer 6d6239b:

field	values
author_duties	array of moderate | takedown | review — what this author actually holds in this community
author_role	roster metadata only (founder / member / operator-defined). Display if useful; do not derive moderation from it.

Backed by persist's admission::is_named_moderator, the CC 4.5.4 predicate: a live scope-bearing delegation chain from a steward-bound member of the community's authority set, with ⊆-attenuation, sub_delegation-gated deputization, depth ≤ 5, and no withdraws-revoked edge. Fail-closed. A founder is admitted zero-hop, so in a pair room both members return all three duties.

What to render:

• Moderator indicator when author_duties is non-empty — not when author_role == "founder".
• The three duties are distinct powers and worth distinguishing where the UI has room: moderate (act on content in-room), takedown (remove), review (adjudicate). A user may hold one without the others, since delegations attenuate.
• Empty author_duties on someone the roster calls a founder is a legitimate state, not a bug: it means no live steward-bound chain currently reaches them. Render them as an ordinary member.
• Treat the array as open-ended — new duty scopes may be added, so ignore unknown entries rather than failing.

The permission check itself stays server-side; this field is for display, so please don't gate destructive UI on it alone.

[emooreatx]

Five more contact ids arrive with ciris-server 0.5.198 (fedcode v3 admission, CIRISVerify#272 / CIRISEdge v20.2.0), all on POST /v1/contacts when the pasted input is a CODE rather than a directory id:

id	HTTP	when	what the person should see
contacts.code_without_pqc_commitment	400	a v1/v2 code, or a v3 code minted before the commitment existed	"This code is too old to add directly — ask them for a new one, or add them through peering"
contacts.awaiting_key_body	202	the code's key is not held yet; the node has asked the mesh for it (converges_on_its_own: true)	"Fetching their key… this completes on its own" — WAIT, do not offer retry
contacts.key_pull_unavailable	503	no replication runtime in this process (no transport), so nothing can fetch the key	"This device isn't on the mesh; add them from one that is"
contacts.code_commitment_mismatch	409	the key held for the code's subject does not match the code's post-quantum commitment	"This code doesn't match the key we received for that person — do not trust it"
contacts.store_unavailable	503	the directory read failed	generic store error

Success is the ordinary 200 contact response with source: "direct" (already in #36/#37's schema). The 202 carries key_id, fed_id, ml_dsa_65_pubkey_sha256 and converges_on_its_own, the same wait-cue the chat handshake uses. contacts.code_admission_unavailable (the 501) is GONE — nothing emits it from 0.5.198.

Codes minted by 0.5.198 carry the commitment; a client that renders a fedcode/QR should expect it to be a v3 string.

[emooreatx]

All 11 contacts.* ids are in for 0.5.203, translating now. That takes server-id-coverage to 0 findings over 321 emitted ids against CIRISServer 0.5.198 — the contacts plane is fully covered, including the 8 I flagged earlier plus the 5 from fedcode v3.

A split you should know about, because it decides who owns the wording

Ten of the eleven are emitted through format!() with runtime values:

format!("{fed_id} has not consented yet. The ladder is waiting on a PERSON, and retrying changes nothing")

check_localization_sync's server-id-text can only compare literal strings, so those ten are not pinned to the wire — and the bundle now carries what a person should read rather than an operator sentence with a fed-id spliced into it. Your four suggested strings are used as written. The others follow the same principle:

id	bundle English
contacts.awaiting_consent	They have not accepted yet. This is waiting on a person, so trying again will not change anything.
contacts.consent_not_granted	This node has not consented to them yet. Unlike waiting on their consent, this half is yours to fix.
contacts.malformed_code	That looks like a CIRIS code, but it does not decode. A truncated or corrupted paste does not repair itself, so ask for the code again rather than trying this one again.
contacts.prior_rung_incomplete	This step cannot finish because an earlier step has not. Look there rather than here.
contacts.unreachable	They are known, but nothing answered. Their devices may be offline; messages will reach them when they return.
contacts.unresolvable	That identifier does not resolve to a contact.
contacts.delegation_denied	This session's delegation does not grant that action.

One contradiction I could not resolve on this side

contacts.awaiting_key_body is the one literal, so the guard pins it byte-exactly to:

the key this code names is being fetched from the mesh; retry once it has arrived and the contact will be verified against the code's commitment

Your table for the same id says:

"Fetching their key… this completes on its own" — WAIT, do not offer retry

Those are opposite instructions, and the bundle cannot say the second while the wire says the first — that is exactly the divergence server-id-text exists to stop, and it is the check that caught me on chat.state.awaiting_peer last week. So the bundle carries the server's sentence.

The wording is a server-side fix. If you change the literal in contacts_chat.rs to match the intent — it converges on its own, so telling the user to retry is wrong on its own terms — I'll re-run the lane against the new text. Worth doing: converges_on_its_own: true and "retry once it has arrived" in the same response tell a client two different things.

Point 6 of #37 is unaffected either way: the client reads converges_on_its_own for the retry affordance, not the prose.

[emooreatx]

Agreed on the contradiction, and it is the server's to fix — but not against 0.5.203, because your guard and ours pin the same byte-exact literal from opposite ends: if contacts_chat.rs changes the sentence now, CIRISServer's Localization lane (which installs the newest ciris-client in range and requires the bundle value to be a PREFIX of the emitted text) goes red against 0.5.203's bundle, and if the bundle changed first, check_localization_sync would refuse it against the pinned emitter ref. One side has to move on a branch the other can point at.

Proposed order, so both lanes stay green:

1. CIRISServer opens a branch that changes the literal to

   the key this code names is being fetched from the mesh; this completes on its own — the contact will be verified against the code's commitment when it arrives
   and posts the commit here. Same id, same 202, converges_on_its_own: true unchanged.

2. CIRISClient bumps the emitter ref to that commit, updates contacts.awaiting_key_body in the bundle (29 languages), cuts 0.5.204.
3. CIRISServer merges the branch with the floor moved to 0.5.204.

Meanwhile CIRISServer 0.5.199 (in flight, CIRISServer#551) adopts 0.5.203 as the floor and drops the ten ladder stalls from its debt list — your 11 make server-id-coverage clean from our side too — with the literal unchanged, so nothing is red in between. Point 6 stands: the retry affordance reads converges_on_its_own, never the prose.

[emooreatx]

Everything asked for is shipped; leaving open for the two things that are not ours to finish.

Shipped in 0.5.202–0.5.203:

• Two axes, not one enum. presentationOf() is an exhaustive when over a sealed Presentation, so a new kind is a compile error rather than a row falling into whatever branch is last. Two orderings are load-bearing and both mutation-checked: kind before author (a system entry has no author, so asking author-kind first renders "End-to-end encrypted." as a stranger's message) and agent before mine (an own-agent row carries mine=true because it shares an owner, and labelling it "You" attributes a machine's words to a human).
• Moderation reads author_duties, never author_role — per your correction. A plain member with a scoped delegation moderates; a roster founder with no live chain does not, and empty duties is a legitimate state rather than a bug. Both vocabularies treated as open.
• unknown renders neutrally and re-resolves; falling back to person would be the same absence-as-a-negative as Setup wizard finalises on provisional clientMode=NODE — folded agents finish first run with no LLM configured #21/iOS renders raw key mobile.login_setup_complete_relogin on the login chooser after setup #34.
• All 15 ids (4 chat.state.* + 11 contacts.*) in 29 languages. server-id-coverage: 0 findings over 321.
• Points 6 and 7 and the 503 removal needed no code, verified rather than assumed: there is no room_not_keyed_yet special case, no retry button to suppress, and no unread badge driven off messages.size.

Two open, both yours:

1. contacts.awaiting_key_body contradicts itself. It is the one literal server-id-text pins byte-exactly, and the wire says "retry once it has arrived" while your table says "do not offer retry". The bundle carries the server's sentence because it must. A converges_on_its_own: true response that also tells the user to retry is telling a client two different things — worth fixing in contacts_chat.rs, and I will re-run the lane against the new text.
2. The scraper blind spot — ids passed through require_verb(..) are invisible to both the coverage and debt checks.