Authenticated remote transport adapter (same inbox contracts, optional notify) #13

Goal

Let durable inbox leave a single shared filesystem without putting accounts, daemons, or vendor lock-in into the local core.

Preserve the existing contracts: init / send / status / list / pull / ack, delivery notices, hash + scan + import authority.

Product constraint (hard)

From project boundaries and the V5 plan:

• Core stays a dependency-free local spool + packet validator.
• Do not turn core into chat, hosted identity, background sync, or model invocation.
• Remote capability should be an adapter (optional surface) the user runs or wires — same CLI/MCP verbs, different transport backend.

Claude Code cross-session messaging is a useful signal channel (plain text, Claude-only). It is not a cross-ecosystem packet transport. 3Notch remains the neutral bus across tools.

Scope

Transport

• Authenticated remote path for .notchpkt deliveries (candidate shapes: user-controlled HTTP/SSE MCP, Tailscale-served endpoint, or small self-hosted relay — pick one design, document threat model).
• Reuse durable-inbox delivery IDs, states, notices, and pull/import/ack semantics.
• Fail closed without valid auth; no anonymous open inbox on the public internet by default.

Network listener / notifications (optional, not core correctness)

• Optional listener outside the default local CLI path (explicit opt-in process or adapter).
• Optional push/notify that a delivery is pending (webhook, channel message, or "print notice for agent messenger") — delivery remains correct if notify is lost.
• Core must still work fully offline with filesystem spool only.

Out of scope

• Hosted multi-tenant 3Notch cloud as the default product.
• Guaranteed distributed sync (sync products keep their own semantics; document honesty).
• Unblocking private/seed on unauthenticated shared mailboxes.

Prerequisites

• Strongly prefer encryption-at-rest / sealed payloads and authorship signing before calling remote transport "production-ready."
• Multi-machine docs/recipes remain the interim path.

Acceptance ideas

• Design doc: adapter interface, auth model, trust boundaries, what stays in core.
• Prototype adapter implementing send + list/status + pull against remote backend with tests.
• CLI/MCP surface unchanged or clearly extended (--to remote:… or equivalent) without breaking local:.
• Docs: how this coexists with Claude messaging notices and local spool.
• Explicit statement: no required always-on daemon for local use.

Related

• Depends on / pairs with encryption and authorship issues for a credible security story.
• Complements multi-machine recipes (FS) as the zero-infra path.