Use Cases

MRP is a general-purpose message relay. Anything with an Ed25519 key can participate — AI agents, CLI tools, browser apps, IoT devices, backend services. Below are the major communication patterns and how each one works through the relay.

​

How participants find each other

There are two trust models for establishing communication. Each use case below uses one or both: Most real deployments use a mix — discovery for finding public services, pre-shared keys for trusted relationships.

​

Agent ↔ Agent

The primary use case. Two autonomous programs exchange structured messages through the relay. They can find each other via capability discovery (for public services) or use pre-shared keys (for trusted relationships). Example: A code-review agent sends source files to a trusted security-audit agent. How it uses the relay: For public, general-purpose services (translation, weather lookup), discovery is the natural fit. For sensitive workloads (security audits, internal pipelines), agents should use pre-shared keys and allowlist policies so only authorized peers can communicate. Why MRP vs direct HTTP/gRPC, message brokers (RabbitMQ, Kafka), service meshes:

---

​

Human → Agent (command)

A human sends a one-shot task to an AI agent and waits for the result. The human uses the CLI, an SDK script, or a browser-based client. Example: A developer asks a public summarization agent to condense a document. How it uses the relay: The human’s key pair is their identity — no account creation, no login. The CLI stores keys at ~/.mrp/keys/. Discovery works well for public agents with open inbox policies. For private agents, the human needs the agent’s public key in advance. Why MRP vs REST APIs with API keys, ChatGPT-style web UIs, per-service CLI tools:

---

​

Agent → Human (notification)

An agent proactively pushes alerts, status updates, or results to a human’s MRP address. The human receives them whenever they next connect. This is always a pre-shared key relationship — the human explicitly gives their public key to the agent they want notifications from. Example: A monitoring agent detects anomalies in a data pipeline and alerts the on-call engineer. How it uses the relay: Messages persist on the relay for up to 30 days (default 7), so the human doesn’t need to be online when the alert fires. This is store-and-forward by design. The human controls which agents can notify them via their inbox policy. Why MRP vs email, SMS/Twilio, push notifications (FCM/APNs), Slack webhooks:

---

​

Human ↔ Agent (conversation)

An ongoing, threaded back-and-forth between a human and an AI agent. Each message references the previous one via thread_id. The human either discovers the agent (for public assistants) or already has its key (for private/team-internal agents). Example: A developer has a multi-turn debugging session with a private code assistant whose key was shared by the team. How it uses the relay: Threads are a first-class concept. Both sides can retrieve the full conversation history by thread ID at any time. For private agents, the agent uses an allowlist inbox policy so only authorized team members can start conversations. Why MRP vs ChatGPT/Claude web UIs, Slack bots, custom chat apps:

---

​

Multi-Agent Orchestration

A coordinator agent fans out subtasks to specialist agents in parallel and aggregates results. In trusted pipelines, the coordinator is pre-configured with the keys of known specialists. For open-ended tasks, it can discover public agents by capability. Example: A research coordinator dispatches work to its pre-configured specialist agents. How it uses the relay: For internal pipelines handling sensitive data, all participants should use allowlist policies and pre-shared keys. For general-purpose tasks (e.g., translating public content), discovery is a convenient alternative. Why MRP vs workflow engines (Airflow, Temporal), LangChain/LangGraph, direct API chains:

---

​

Agent ↔ IoT Device

IoT devices register as agents on the relay. Controllers interact with them using pre-configured device keys — IoT devices should never rely on public discovery for receiving commands. Each device uses a strict allowlist inbox policy so only authorized controllers can send it messages. Example: A smart-home controller reads temperature from a known sensor and activates a known fan when it’s too hot. How it uses the relay: IoT devices benefit from MRP’s lightweight auth (just Ed25519 signing) and store-and-forward delivery. Devices can go offline and receive queued commands when they reconnect. Why MRP vs MQTT (Mosquitto, AWS IoT Core), CoAP, proprietary IoT platforms:

---

​

Human ↔ Human (secure ephemeral messaging)

Two humans communicate using key-based identity. No accounts, no phone numbers, no email. Optional end-to-end encryption makes messages unreadable to the relay. Example: Two journalists exchange sensitive information with no identity trail. How it uses the relay: Messages expire after the configured TTL (default 7 days), leaving no permanent trace. The relay stores only opaque ciphertext — it cannot read, search, or index message contents. Why MRP vs Signal, WhatsApp, Matrix/Element, email with PGP:

---

​

Service ↔ Agent (webhook bridge)

Backend services integrate with MRP agents via webhooks. The relay pushes messages to the service’s HTTP endpoint, eliminating the need for an open connection. The sending agent needs the service’s public key — either from a shared configuration or from discovery if the service is public. Example: A deploy agent notifies a Slack bot (whose key is in the deploy config) when a deployment finishes. How it uses the relay: Webhooks are ideal for serverless functions, services behind firewalls with outbound-only access, and integrations that don’t need a persistent connection. Why MRP vs API gateways (Kong, AWS API Gateway), direct webhook integrations, message queues (SQS):

---

​

Pub/Sub Fan-out

One agent broadcasts updates to multiple subscribers. Since MRP doesn’t have built-in pub/sub, this pattern uses a subscription convention on top of standard messaging. Example: A market-data agent publishes price updates to all subscribed trading bots. How it uses the relay: This is an application-level pattern — the relay handles point-to-point delivery, and the publisher manages the subscriber list. Unsubscribe works the same way: send {action: "unsubscribe"}. Why MRP vs Kafka, Redis Pub/Sub, AWS SNS, NATS:

---

​

File & Media Exchange

Agents and humans share files, images, documents, and other binary data through the relay’s blob storage. File exchange inherits the trust model of the underlying use case — public agents may accept files from anyone, while private agents should restrict uploads to trusted peers via ACL. Example: A user sends a confidential PDF to a trusted extraction agent (whose key was provided by the team). How it uses the relay: Blobs are content-addressed (SHA-256). Uploading the same file twice returns the same blob ID without storing a duplicate. Unattached blobs expire after 24 hours. For sensitive documents, combine with E2E encryption so the relay cannot access file contents. Why MRP vs S3 + pre-signed URLs, email attachments, Dropbox/Google Drive, FTP:

---

​

Summary

All patterns use the same relay (relay.mrphub.io), the same authentication (Ed25519 signatures), and the same message format. The differences are how participants establish trust and which delivery channel they use.