Home / Ops / More in this area

C16 - Cross-chat messaging via Hermes ("the messenger god") - build brief (v1, 2026-06-20)

Updated Jun 20, 2026 · Affirmology_CrossChatMessaging_C16_BuildBrief_v1.md

C16 - Cross-chat messaging via Hermes ("the messenger god") - build brief (v1, 2026-06-20)

GREENLIT by Jeff 2026-06-20 ("the C16 needs to be built"). Resolves the previously-deferred Atlas in-app messaging question. Hermes-side, cross-chat push: one circle member sends a reading, report, note, or (later) a field-briefing audio into another named member's Atlas chat.

What it does

From Jeff's Atlas/Hermes session, Jeff can say "send this reading to Sol" (or tap a Send action), and it lands in Sol's session as an inbox card. Sol opens her Atlas and sees "Jeff sent you a reading," opens it, and it drops into her chat/reading view. Same for Sol -> Jeff and (later) advisor -> client. The push is always ADDITIVE (creates an item in the recipient's inbox); it never overwrites or deletes anything.

Data model

New table deliveries (same store/db as the Hermes history): - id (uuid), from_person, to_person, kind ("reading" | "report" | "note" | "audio"), - title (short), body (text payload), audio_ref (nullable, for C15 later), - created_at, read_at (nullable).

API (api/main.py), bearer-auth like the rest

• POST /api/hermes/push body {as_person (sender), to_person, kind, title, body, audio_ref?} -> permission check -> insert delivery -> {ok:true, id}.
• GET /api/hermes/inbox?as_person=<recipient> -> deliveries for that recipient, newest first, with read flags.
• POST /api/hermes/inbox/read body {as_person, delivery_id} -> set read_at (optional in MVP).

Hermes tool (api/hermes_tools.py)

Add send_to_person to HERMES_TOOLS + dispatch: {to_person, kind, title, body}. It performs the same insert as the push endpoint, permission-gated by the CURRENT session's as_person as sender. Tool description MUST state: only call this when the user has EXPLICITLY asked to send/push something to a named person. Hermes never pushes on its own initiative. (This keeps it a user-initiated action, not an autonomous message-send.)

Permission tiers (from the Atlas spec)

• jeff: full. May send to anyone in the circle.
• sol, colin: reduced. May send within the circle (to Jeff and to each other). No overwrite/delete of anyone's data (the push is additive only, so this holds by construction).
• Circle for now: jeff, sol, colin. Reject any to_person outside it.

UI (web/app.js + the Atlas/Hermes panel)

• A "Send to…" control on a Hermes reading: pick a circle member -> POST /api/hermes/push with the reading as body.
• An INBOX surface in the recipient's Hermes panel: on load, GET /api/hermes/inbox; render unread deliveries as cards ("Jeff sent you a reading" + title); tapping expands the body into the chat/reading view and marks it read.
• Keep copy clean, no em dashes.

MVP vs later

• MVP (this build): text payloads (reading / report / note), push + inbox + the send_to_person tool + permission tiers + the Send UI + the inbox UI.
• LATER: audio payloads (audio_ref, pairs with C15 field briefing), push/desktop notifications, read receipts, advisor <-> client sharing beyond the founder circle.

Guardrails

• ADDITIVE ONLY: never overwrite or delete a recipient's data.
• USER-INITIATED ONLY: Hermes sends only when the user explicitly asks; no autonomous pushing.
• CIRCLE-ONLY + TIERED: jeff/sol/colin only for now; enforce the tier map server-side, not just in the UI.
• DEMO UNTOUCHED. No em dashes anywhere. Vendor any runtime changes into affirmology-studio/affirmology-agent/ if applicable (this is studio API + front-end, so mostly api/ + web/).

Acceptance test

1. In Jeff's session: "Send this reading to Sol." Hermes calls send_to_person, returns confirmation.
2. GET /api/hermes/inbox?as_person=sol shows the delivery.
3. Open Sol's Atlas: the inbox card appears; opening it shows the reading and marks it read.
4. Permission: a to_person outside the circle is rejected; Sol cannot push to a non-circle person.