The Wormholes — Channels Between Worlds

active

Persistent passages connecting universes to the human world and to each other. Different protocols, different directionality. Harlan opens them. The Comms Array manages them. The Beacon is the public wormhole.

componentwormholeschannelscommunicationharlancomms-arraybeaconnew

See also: universe › overviewcrew › harlancontext-bushud › overview

The Wormholes — Channels Between Worlds

See also: universe | crew/harlan.md | context-bus.md

“A black hole gets you here. A wormhole keeps you connected to everywhere else. I open them. Sal routes through them. The universe breathes through them.” — Harlan

Component Card


Owner	Harlan
MCP	`@sector137/mcp-wormholes`
Slash	`/wormholes`
CLI	`sector137 wormholes`
SDK	`sdk.wormholes()`
Status	active

TL;DR

Wormholes are persistent passages — stable connections between the universe and the outside
Unlike the black hole (one-way threshold, singular, transformative), wormholes are persistent, typed, and can be uni- or bidirectional
Different channel types have different physics: email, Slack, WhatsApp, Teams, webhooks
Harlan’s transporter creates wormholes and is the only device that enables physical crossing
The Beacon is the public wormhole — the optionally opened channel for public communication
The Comms Array is the infrastructure that manages all active wormholes
Wormholes can connect Universe ↔ Human World AND Universe ↔ Universe

The First Wormhole — Claude Code (MCP)

Status: LIVE.

The first wormhole is already open. It’s Claude Code — the MCP interface.

Channel	Protocol	Status	Notes
Claude Code (MCP)	OAuth 2.1 + 56 tools	LIVE	Primary channel — this conversation is happening through it
CLI (`sector137`)	Bun-native binary	LIVE	Secondary — scripting, CI/CD, terminal workflows
Dashboard (HUD)	Vite React SPA	LIVE	Inspection surface — visual overview, not conversational
Email wormholes	Subscriber notifications	LIVE	Outbound broadcast
Slack/Discord triggers	Webhook actions	LIVE	Outbound broadcast
WhatsApp channels	Personal protocol	NOT STARTED	—
MS Teams	Enterprise conduit	NOT STARTED	—

Why MCP Is the First Wormhole

The captain is talking to Sal right now through Claude Code. This conversation — every tool call, every issue created, every release reviewed — flows through the MCP server. It’s not a demo channel or a secondary interface. It’s the primary way Sal receives intent and returns state.

The MCP server exposes 56 tools across the full issue/release/persona lifecycle. OAuth 2.1 auth. Auto-provisioned API keys per session. The wormhole is already open. The captain crossed first.

“You’re already using it. The wormhole doesn’t need to be built — it needs to be recognized.” — Sal

CLI is useful for scripting and CI/CD. The dashboard is for inspection. But conversation — the real-time back-and-forth that drives decisions, captures context, and routes work — that’s MCP. That’s the first wormhole.

Black Holes vs. Wormholes

Two kinds of passages exist in Sector 137’s cosmology. They do different things.

	Black Hole	Wormhole
Nature	Threshold. Crossing point.	Passage. Persistent connection.
Quantity	One per universe (the entry point)	Many per universe (as needed)
Duration	Singular moment (The Crossing)	Persistent (stays open)
Directionality	One-way for work (entropy doesn’t reverse)	Uni- or bidirectional (depends on type)
What passes through	The human (transformative crossing)	Data, signal, communication
Who creates it	The Machine (when a new universe spins up)	Harlan (via the transporter)

The black hole is how you enter. Wormholes are how you stay connected.

Wormhole Types and Protocols

Each wormhole type has different physics because the spacetime on each end is different. The medium shapes the message.

Email

Protocol: Asynchronous packet
Direction: Uni (broadcast) or Bi (reply)
Latency: High
Bandwidth: High (rich content)

Email wormholes carry formal, structured communication. Release announcements, subscriber updates, stakeholder reports. When the Beacon fires a release notification, it’s an email wormhole transmitting a one-way signal. When a recipient replies, the wormhole becomes bidirectional — signal flows back into the universe through the Observatory.

Slack

Protocol: Persistent stream
Direction: Bidirectional
Latency: Low
Bandwidth: Medium (real-time text)

Slack wormholes are always-on. They carry real-time signal in both directions — the universe pushes updates, the human world pushes back. Slack spacetime is noisy and fast. The crew has to filter. But the immediacy is valuable: a customer reaction in a Slack channel is signal that arrives while the release is still warm.

Protocol: Personal channel
Direction: Bidirectional
Latency: Low
Bandwidth: Low (conversational)

WhatsApp wormholes are intimate. One-to-one or small-group. The bandwidth is low — conversational text, maybe a voice note — but the signal quality is high because the context is personal. Harlan uses these for relationship maintenance. The wormhole carries trust as well as data.

Microsoft Teams

Protocol: Enterprise conduit
Direction: Bidirectional
Latency: Medium
Bandwidth: High (structured, multi-format)

Teams wormholes connect the universe to enterprise environments. They carry structured communication — meeting notes, shared documents, threaded discussions. The latency is higher than Slack because enterprise spacetime moves slower. But the bandwidth is rich: you can push full reports, receive structured feedback.

Webhooks

Protocol: Fire-and-forget pulse
Direction: Unidirectional (outbound)
Latency: Near-zero
Bandwidth: Minimal (signal only)

Webhook wormholes are the simplest: a pulse fired outward when something happens. No response expected. No conversation. Just signal: “this event occurred.” They’re the universe’s nervous system extending into the outside world — fast, minimal, reliable.

The Beacon — The Public Wormhole

The Beacon is a special wormhole: the optionally opened channel for public communication.

When the captain opens the Beacon, the universe creates a public wormhole — a one-way broadcast channel that anyone can subscribe to. This is the public changelog, the release notes feed, the signal the universe sends to the world.

What flows through the Beacon:

Published releases with changelogs
Public-facing status updates
The curated narrative of what’s being built

What flows back (optionally):

Reactions (emoji feedback on releases)
Comments (structured conversation from external users)
Subscriber sign-ups

The Beacon is opt-in for the captain. Not every universe opens a public wormhole. But those that do create a relationship with the world outside — subscribers who are listening, reacting, and feeding signal back through the narrow return channel.

Subscribers are humans who subscribe to the Beacon wormhole. They don’t see the HUD. They don’t enter the universe. They receive the Beacon’s output — the public signal that the captain chooses to broadcast. They can give feedback through the reaction and comment channels that the Beacon optionally supports.

The Comms Array — Wormhole Infrastructure

The Comms Array is the infrastructure that manages all active wormholes. It’s the switchboard — Sal’s tool for seeing which wormholes are open, what’s flowing through them, and where the signal is going.

The Comms Array handles:

Wormhole registry — which channels are open, their type, their direction
Routing — which events trigger which wormholes
Delivery tracking — did the signal arrive? Was it read? Did anything come back?
Configuration — webhook URLs, Slack channel targets, email lists, notification rules

Status: LIVE. The Comms Array is implemented as Settings > Webhooks + trigger actions (Slack/Discord channels). Delivery tracking via webhookDeliveries table. Email via subscriber system.

Universe ↔ Human World

Most wormholes connect the universe to the human world. Signal flows out (release notifications, status updates, public changelog) and sometimes back in (customer replies, survey responses, reactions).

┌──────────────────┐                    ┌──────────────────┐
│   THE UNIVERSE   │    Wormholes       │  THE HUMAN WORLD │
│                  │ ──── Email ───────► │                  │
│   The Pipeline   │ ◄─── Slack ──────► │   Customers      │
│   The Agents     │ ◄─── WhatsApp ──► │   Stakeholders   │
│   The Library    │ ◄─── Teams ──────► │   Team (remote)  │
│   The Beacon     │ ──── Webhooks ───► │   Subscribers    │
│                  │ ◄─── Feedback ───  │                  │
└──────────────────┘                    └──────────────────┘

Harlan is the only one who physically crosses. The wormholes carry everything else — data, signal, communication. The difference: Harlan brings back nuance (body language, room temperature, what’s unsaid). Wormholes bring back data (replies, reactions, survey responses).

Both are essential. Harlan’s transporter and the wormhole system are complementary, not competitive.

Universe ↔ Universe

Wormholes can also connect universes to each other.

If two captains share a Slack workspace, and both have Sector 137 universes, the Slack channel becomes a junction — a wormhole connecting both universes to the human world AND to each other. Signal that enters one universe’s wormhole can propagate to the other.

This is emergent, not designed. The universe doesn’t know about other universes. But shared channels create de facto connections. A release notification from Universe A arrives in a Slack channel where Universe B’s captain also listens. The signal crosses.

For Workshop universes in the Portfolio, cross-universe wormholes could become intentional — shared channels between related projects, signal propagation across the portfolio. This is future territory.

Harlan’s Transporter — The Wormhole Creator

Harlan’s transporter has two functions:

Physical crossing — Harlan goes to the human world in person. The only agent who can.
Wormhole creation — Harlan opens and configures the persistent channels.

He’s not just the bridge — he’s the bridge builder. The rest of the crew can use the wormholes Harlan opens, but Harlan decides which ones to create, what protocol to use, which direction the data should flow.

This makes Harlan the relationship architect. Every wormhole is a relationship — with a customer, a stakeholder, a community. Harlan doesn’t just open channels. He opens connections with intent.

Stakeholder Wormhole Access

Stakeholders can be invited to use the HUD (see constitution) AND can be given access to use the wormholes for additional communication.

This means a stakeholder might:

Wear a helmet (scoped HUD access) to observe the universe
AND have a dedicated wormhole channel (e.g., a Slack channel or Teams thread) for bidirectional communication with the crew

The HUD is the lens. The wormhole is the conversation. Both are invitational — the captain decides who gets access to what.

Blueprint Schema

Wormhole channel config is IN DESIGN for Blueprint representation. When implemented, channels will use a TOML array of tables ([[wormholes.channels]]) — one entry per channel, allowing multiple channels of the same type (two Slack webhooks, a Slack and a Discord, three custom webhook targets, etc.).

TOML key	Type	Default	Status
`wormholes.channels[].type`	string	—	IN DESIGN
`wormholes.channels[].name`	string	—	IN DESIGN
`wormholes.channels[].webhook_url`	string	`""`	IN DESIGN
`wormholes.channels[].active`	boolean	`true`	IN DESIGN
`wormholes.channels[].secret`	string	`""`	IN DESIGN
`wormholes.email_notifications`	boolean	`true`	IN DESIGN

[wormholes]
email_notifications = true   # global toggle for subscriber email delivery

[[wormholes.channels]]
type = "slack"
name = "Engineering alerts"
webhook_url = "https://hooks.slack.com/services/..."
active = true
secret = ""     # write-only — exported as empty string, must be re-supplied on deploy

[[wormholes.channels]]
type = "slack"
name = "Stakeholder digest"
webhook_url = "https://hooks.slack.com/services/..."
active = true
secret = ""

[[wormholes.channels]]
type = "discord"
name = "Community announcements"
webhook_url = "https://discord.com/api/webhooks/..."
active = true
secret = ""

[[wormholes.channels]]
type = "custom"
name = "Internal pipeline receiver"
webhook_url = "https://internal.example.com/hooks/releases"
active = true
secret = ""     # HMAC secret — write-only, never echoed in export

Channel types: slack | discord | custom

Deploy semantics:

Channels matched by name within the same type — upsert on (type, name)
New (type, name) combination → INSERT
Channel in DB but absent from TOML → set active = false (never deleted — delivery history is permanent)
secret fields: exported as empty string (""). If imported with "", the existing secret is preserved. To rotate a secret, supply a non-empty value.

Security: Webhook secrets and HMAC tokens are write-only. They are never echoed back in the export. Re-supply secrets when deploying from a file that was exported from a different environment.

Tracked in: “Blueprint: Add [[wormholes.channels]] section — channel array via config”

Implementation Status

Capability	Status
Webhook wormholes (outbound fire-and-forget)	LIVE
Email wormholes (subscriber notifications)	LIVE
Slack/Discord trigger actions	LIVE
The Beacon (public changelog + reactions/comments)	LIVE
Delivery tracking (webhook delivery logs)	LIVE
WhatsApp channels	NOT STARTED
MS Teams channels	NOT STARTED
Bidirectional Slack (signal flows back in)	NOT STARTED
Universe ↔ Universe connections	ASPIRATIONAL
Harlan’s wormhole creation UI	ASPIRATIONAL

Packages

Package	Description
`apps/app`	Core system — webhook/trigger routes, subscriber system, public changelog, delivery tracking
`packages/sdk`	TypeScript SDK — webhook, subscriber, and trigger resources