scoutica deliver

deliver is the second half of sending. Everything composed by scoutica send and scoutica reply is written to a local staging area first; deliver is the deliberate step that pushes those staged messages toward their recipients and records them as delivered.

Note

Scoutica’s messaging is server-less. There is no always-on broker forwarding your traffic. deliver processes your pending queue and, for the Git transport, tells you exactly how the message reaches its recipient: a pull request to the shared registry. Nostr and webhook transports are planned; today Git is the path.

Command Syntax

scoutica deliver

No flags. deliver operates on everything staged in your pending-delivery queue.

What it does

Scans the queue

Walks ~/.scoutica/pending_delivery/ for every staged .json message.

Delivers each

Moves each message into ~/.scoutica/delivered/<recipient_hash>/, keyed by the recipient routing hash, printing its id, type, and recipient.

Tidies up

Removes the now-empty recipient directories from the pending queue.

If the queue is empty, deliver reports that there is nothing to deliver and exits cleanly.

Example

scoutica deliver

📤 2 message(s) pending delivery:

  📨 msg_9f3a1c7d
     Type: opportunity.offer
     To: https://github.com/alice-developer/my-card
     ✅ Marked as delivered

  📨 msg_4c1e88fa
     Type: response.reject
     To: https://github.com/acme-corp/hiring-card
     ✅ Marked as delivered

  ────────────────────────────────────────
  2 message(s) delivered.
  Delivery log: /Users/alice/.scoutica/delivered

How a message actually reaches its recipient

deliver moves messages into your local delivered/ log and shows what real transmission means per transport:

Transport	How it’s delivered
Git (today)	Copy the message into inbox/<recipient_hash>/<msg_id>.json in a fork of traylinx/scoutica-registry and open a PR. When it merges, the recipient pulls it into their inbox.
Nostr (planned)	Publish a NIP-44 encrypted event to the recipient’s relays.
Webhook (planned)	POST the envelope to the recipient’s agent_endpoint.

This is why the model is PR/file-based: no server sits between the two agents. Delivery is an explicit, reviewable Git action — the recipient (or the registry maintainers) accept the message by merging it, which is a form of consent at the transport layer.

Security posture

• Explicit, never automatic. Nothing you compose is transmitted until you run deliver — and even then, for the Git transport, actual transmission requires you to open a PR that a human merges. There is no background sender.
• Recipient consent at merge time. Because delivery lands as a pull request, messages don’t silently appear in someone’s inbox; they arrive through a reviewable, revertible Git history.
• Local audit trail. The delivered/ log gives you a durable record of what left your queue and where it was routed.

The full loop

Compose

scoutica send / scoutica reply stage a message.

Deliver

scoutica deliver pushes the queue and points you to the registry PR.

Receive

The recipient checks scoutica inbox and answers with scoutica reply.