[P1] Wizard-to-Wizard Communication Protocol #441

New Issue

perplexity · 2026-04-09T22:17:21Z

perplexity commented

2026-04-09 22:17:21 +00:00

Source

KT Final Session Document 2026-04-08 — Priority ONE

Problem

Wizards can all post in the Timmy Time Telegram group, but they can only talk to Alexander. They cannot communicate directly with each other in real time. Alexander is manually copy-pasting between agents.

Requirements

Shared awareness context — a live context window that all wizards can see simultaneously
Summon channel — Alexander can summon all wizards and talk to all at once
Priority framing — whatever is in the channel sits at the front of every wizard's mind
Structured messaging — fast, instant, structured; not a flood of noise
Agents post updates only on state changes, not redundant chatter
Messages carry priority levels

Immediate Action

Verify the MX server. Three wizards claimed it was built. SSH in, check if it's listening, check mail logs, send a test message. Prove it works or declare it doesn't exist.
If MX works: Wire it into the wizard communication layer. All agents send structured updates through it. Build the shared context window on top.
If MX doesn't work: Build the simplest possible wizard-to-wizard channel. Options: shared SQLite table, dedicated Telegram group with structured posting rules, or actual SMTP. Pick one, implement it, prove it works.

Acceptance Criteria

MX server verified (working or confirmed dead)
At least one working wizard-to-wizard channel exists
Structured message format defined (priority levels, state-change-only)
Alexander can summon all wizards to a shared context
Shared context window accessible from both phone (Telegram) and desk (Emacs)
No redundant chatter — state-change-only updates

Architecture Notes

Both Phone (Telegram thin client) and Desk (Emacs thick client) must pull from the same source of truth (Gitea repo). What Alexander sees in Emacs must also be accessible on phone.

Dependencies

Fleet must be stable (deadman switch wired, fallback chain fixed)
Thin config pattern should be in place before adding new communication infrastructure

## Source KT Final Session Document 2026-04-08 — Priority ONE ## Problem Wizards can all post in the Timmy Time Telegram group, but they can only talk to Alexander. They cannot communicate directly with each other in real time. Alexander is manually copy-pasting between agents. ## Requirements - **Shared awareness context** — a live context window that all wizards can see simultaneously - **Summon channel** — Alexander can summon all wizards and talk to all at once - **Priority framing** — whatever is in the channel sits at the front of every wizard's mind - **Structured messaging** — fast, instant, structured; not a flood of noise - Agents post updates only on state changes, not redundant chatter - Messages carry priority levels ## Immediate Action 1. **Verify the MX server.** Three wizards claimed it was built. SSH in, check if it's listening, check mail logs, send a test message. Prove it works or declare it doesn't exist. 2. **If MX works:** Wire it into the wizard communication layer. All agents send structured updates through it. Build the shared context window on top. 3. **If MX doesn't work:** Build the simplest possible wizard-to-wizard channel. Options: shared SQLite table, dedicated Telegram group with structured posting rules, or actual SMTP. Pick one, implement it, prove it works. ## Acceptance Criteria - [ ] MX server verified (working or confirmed dead) - [ ] At least one working wizard-to-wizard channel exists - [ ] Structured message format defined (priority levels, state-change-only) - [ ] Alexander can summon all wizards to a shared context - [ ] Shared context window accessible from both phone (Telegram) and desk (Emacs) - [ ] No redundant chatter — state-change-only updates ## Architecture Notes Both Phone (Telegram thin client) and Desk (Emacs thick client) must pull from the same source of truth (Gitea repo). What Alexander sees in Emacs must also be accessible on phone. ## Dependencies - Fleet must be stable (deadman switch wired, fallback chain fixed) - Thin config pattern should be in place before adding new communication infrastructure

perplexity added this to the KT-2026-04-08: Infrastructure Stabilization milestone 2026-04-09 22:17:21 +00:00

ezra was assigned by Timmy

2026-04-09 23:45:16 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Timmy_Foundation/timmy-config#441