stoa

Substrate for real-time experiences between one host and N participants. Each participant's AI runs in their own context. No central server sees the conversation, the streams, or the AI calls.

Architectural commitments

• BYO-AI. Each participant connects their own model. In-browser WebGPU, personal API key, or a local proxy (e.g., ai-bridge). The substrate carries envelopes between peers; it does not carry AI calls. App developers do not host inference.
• Peer-to-peer. WebRTC between participants. The substrate routes pairing through a lobby, then traffic flows directly between peers. No central server sees the conversation.
• Multi-topology. Same envelope contract across 1:1 (consultation), 1:N (presentation), and future M:N patterns. Pattern instances ship as their own packages.

This is the architectural alternative to centralized multi-participant AI products (e.g., Microsoft Copilot Cowork): no vendor lock to a single AI provider, no central app server with content visibility, no inference cost on the developer's books.

What it is

A stoa in ancient Greek architecture was a covered walkway where one person addressed others who had gathered. This library names the substrate beneath that pattern: WebRTC peer-to-peer transport, lobby pairing, structured envelopes, and a role contract for host/visitors.

Pattern instances built on stoa:

• pip-relay — 1:1 operator-mediated AI chat
• agora (planned rebuild) — 1:N presentation with AI moderation
• future patterns — group/mesh topologies as they emerge

The privacy story

Three modes for AI participation, all privacy-preserving by architecture:

1. In-browser AI — WebGPU-loaded model in the participant's tab. Strongest privacy. Limited model size today, improving fast.
2. Personal API key — participant's browser talks to Anthropic/OpenAI/etc. with their own key. Data goes to one company they chose, not through a central app server.
3. Local proxy (ai-bridge) — participant's machine proxies to whatever backend they want.

In all three modes, the participant's AI never crosses the peer channel as a service. It generates output that the participant chooses to share through envelopes. The substrate does not see AI calls.

Honest qualifications

• TURN relay: ~20% of connections need TURN due to NAT restrictions. TURN packets are encrypted at the WebRTC layer; the relay sees metadata (peer IPs, packet sizes, timing) but not decrypted content. Self-hostable.
• Signaling: the lobby is currently centralized (signal.neevs.io). It sees room IDs and pair-request envelopes, nothing else. Self-hostable.
• Bring your own AI: stoa does not ship an AI. Each participant connects whatever they trust.

Architecture

stoa (substrate)
├─ transport      WebRTC pairing + TURN + data channel
├─ envelope       Structured message format
├─ signal client  Pairing protocol
├─ role contract  Host / visitor semantics
└─ AI contract    Where each participant's AI plugs in

pattern instances (built on stoa, shipped as separate packages):
├─ pip-relay      1:1 chat (operator-mediated)
├─ agora          1:N presentation (planned)
└─ ...            future patterns

The substrate is small and stable. New features go into pattern instances, not into the substrate.

Status

Early. The substrate code currently lives inside pip-relay and is being migrated here incrementally. See MIGRATION.md.

License

MIT