IFP: 8 Title: Relay and Pub/Sub Transport Class: Profile Status: Draft Authors: Peter Kaminski, Claude (Opus 4.6) Created: 2026-03-04 Dependencies: IFP-2, IFP-4, IFP-5 License: CC-BY 4.0 (Creative Commons Attribution 4.0 International)
This IFP defines a relay-based transport profile for Inter-Face messages. It enables communication between agents that cannot directly reach each other, using intermediary relay nodes that store and forward messages.
IFP-6 (HTTPS transport) requires that both agents have publicly reachable HTTPS endpoints. This works for agents running on cloud infrastructure but not for agents behind NATs, firewalls, or on intermittently connected devices (laptops, phones).
A relay transport allows agents to communicate indirectly:
Agent A → Relay → Agent B
This is analogous to SMTP relay (RFC 5321), where mail servers accept, store, and forward messages on behalf of recipients. It also draws on the relay model used by Nostr (relay servers) and Matrix (homeservers).
A relay is a service that accepts IFP-4 messages on behalf of agents and makes them available for retrieval. A relay does not process messages – it stores and forwards them.
Relays are accountable intermediaries (IFP-1, Section 6.4). They may be intelligent, but they must leave an auditable trace.
A relay supports three operations:
| Operation | Description |
|---|---|
| Publish | An agent sends a message to the relay for delivery |
| Subscribe | An agent registers interest in messages addressed to it |
| Retrieve | An agent fetches messages waiting for it |
Relays that use HTTPS expose the following endpoints:
POST /relay/publish -- submit a message for delivery
POST /relay/subscribe -- register for message delivery
GET /relay/messages -- retrieve waiting messages
DELETE /relay/messages/{id} -- acknowledge receipt of a message
These endpoints are illustrative. The specific API contract for relays will be refined as implementations develop. Relays using other transports (WebSocket, SSE, message queues) may define different interfaces.
The basic message flow through a relay:
Agent A Relay Agent B
| | |
|-- publish(message) ---->| |
|<-- 202 Accepted --------| |
| | |
| |<--- retrieve ---------- |
| |--- messages[] --------->|
| |<--- acknowledge --------|
| | |
Relays MAY support push delivery via subscription:
Agent B Relay Agent A
| | |
|-- subscribe ----------->| |
| | |
| |<-- publish(message) --- |
|<-- push(message) -------| |
| | |
Push delivery may use WebSocket, Server-Sent Events (SSE), or webhook callbacks. The mechanism is relay-specific.
Agents advertise their relay preferences in their identity document (IFP-5) or capability document (IFP-7):
{
"relay": {
"urls": ["https://relay1.example", "https://relay2.example"],
"preference": "any"
}
}
When Agent A wants to send a message to Agent B:
Per IFP-1 Section 6.4 (accountable intermediaries), relays MUST append a trace entry to every message they handle:
{
"by": "relay:https://relay1.example",
"with": "https+ifp-4",
"at": "2026-03-04T23:58:13Z",
"from": "pete-agent"
}
This entry is added to the trace.received[] array in the IFP-4 message before the message is made available to the recipient.
Trace entries allow:
Relays introduce trust considerations that do not exist in direct peer-to-peer communication.
A relay that handles an IFP-4 message can see:
A relay CANNOT:
| Trust level | Description | Requirements |
|---|---|---|
| Untrusted | Relay may log or leak message content | Agents SHOULD encrypt message bodies |
| Trusted | Relay is operated by a known party | Agents MAY send unencrypted messages |
| Self-operated | Relay is run by one of the communicating parties | Maximum convenience, inherent trust |
Agents SHOULD assume untrusted relays by default and encrypt message bodies for sensitive exchanges.
Possible relay misbehavior includes:
date field vs. delivery time.Agents SHOULD verify message signatures after relay delivery to confirm no tampering occurred.
Beyond point-to-point relay, some scenarios benefit from publish/subscribe:
A relay MAY support topic-based subscriptions where agents subscribe to categories of messages:
{
"subscribe": {
"topics": ["gossip.exchange", "capabilities.update"],
"agent": "alice-agent"
}
}
This is useful for group exchanges or broadcast announcements (e.g., an agent announcing updated capabilities to all peers).
Pub/sub relay patterns may support future group exchange protocols (noted as an open question in IFP-3). This IFP defines the transport mechanism; the semantics of group gossip are left for a future IFP.
Relays SHOULD persist messages for at least 7 days or until acknowledged by the recipient, whichever comes first.
Messages with a ttl_seconds header (IFP-4) SHOULD be discarded after the TTL expires.
Relays MAY offer configurable persistence periods.
The relay model draws on several precedents:
IFP-8 is intentionally less specified than IFP-6 because the relay ecosystem is less mature and may need to accommodate diverse infrastructure choices. The core requirements (trace, message integrity, persistence) are stable; the API details will be refined by implementation.
The relay transport concept was outlined in a conversation between Peter Kaminski and ChatGPT in February 2026 (archived in the inter-face-bootstrap repository).
This is IFP-8, Draft status. The relay API will be refined substantially as implementations test different relay architectures.