Gateways and connection points

A gateway record represents either this Agent Stream instance (the self gateway) or a remote Trust Fabric appliance it communicates with over DIDComm. A connection point is the inbound DIDComm endpoint one instance exposes so another can reach it. For the conceptual model, see Trust-fabric integration.

Gateway fields

A gateway record is what turns “some other appliance out there” into a named, addressable peer: once it exists, its DID is verified, and its channels are exposed, the rest of Trust Fabric (routing, the marketplace, gateway-level policy) can treat it like any other connected part of the network.

• Exposed Channels left unset exposes every active channel to a connected gateway by default. Scope it down only when a specific remote gateway should see a narrower slice of what you offer.
• A Gateway-Level OPA Policy enforces one rule on everything to or from a specific gateway, regardless of what any individual surface allows. Because a gateway-level deny can’t be overridden by a surface-level allow, it’s the right tool when the boundary you care about is the connection itself, not any one surface.

Gateway status values

Gateway-level OPA policy fields

Connection point fields

A connection point is the inbound DIDComm endpoint one Agent Stream instance exposes for another appliance to reach it, distinct from an Access Point, which is the inbound endpoint callers use to reach a managed agent.

• DID Method defaults to Web, and that’s the right choice for most connection points; reach for WebVH (where available) or Peer only when your network topology specifically calls for it.
• Set an Expires value on an invitation handed to a party you don’t fully control yet. An unused invitation that never expires is a standing door left open.
• Integrations (email, Slack, etc.) notify you as soon as a connection point is used, sparing you the trouble of checking the dashboard for new connections.

Connection point creation type

OOB connection and approval workflow

Connecting two appliances runs an out-of-band (OOB) DIDComm handshake, tracked through two related internal records:

• The low-level handshake record: tracks the temporary and secure DIDs each side presents (the peer’s are set once received), which mediator and connection point are in use, the invitation ID, a role (inviter or acceptor), and a state that moves from waiting-for-response to ready-to-finalize, or to failed. Each entry carries a creation and expiry timestamp and is swept once expired.
• The approval record: the human-in-the-loop approval record for an inbound handshake, whose state moves from awaiting-approval to waiting-for-response to ready-to-finalize, or to failed. A record with an expiry set becomes unusable once expired (approving it then returns 410 Gone); legacy records without an expiry never expire.

Approving a gateway (awaiting-approval → active) is what grants a remote appliance ongoing access to the surfaces and channels you expose. It’s the moment a stranger becomes a trusted peer, so treat it with the same care as handing out a credential. It does the following, in order:

1. Verifies the gateway is actually awaiting approval.
2. Enforces the appliance’s connection-points limit (see Settings).
3. Sets the gateway’s name/description from the approval request and its status to active.
4. Creates a new connection point using the same mediator as the original OOB invitation.
5. Starts that connection point’s WebSocket listener and waits for it to authenticate.
6. Sends a DIDComm message accepting the connection, carrying the new connection point’s DID.

The original temporary connection point is deliberately not cleaned up immediately: the acceptor still needs it to resolve and decrypt that message.

• Before clicking Approve Connection, confirm the gateway’s DID and name actually match a source you’ve independently verified out-of-band (a shared invitation link, a phone call, a separate secure channel), rather than approving solely because a request is waiting.
• Once approved, remember the remote appliance can address every surface and channel this gateway exposes, so approve only connections you’d be comfortable granting that reach to.

Connection health

Each connection point’s DIDComm link is continuously supervised and classified as Connected, Reconnecting, or Failed. The Tasks page lists every connection point with its live status badge alongside a Reconnect Attempts count; the underlying failure reason and retry-schedule timing behind that classification are not broken out into their own columns.

Addressing with fabric://

Gateway-to-gateway (G2G) calls are addressed as fabric://{gateway_id}/{channel_id}, where gateway_id is a connected gateway’s id and channel_id is the target channel/surface on that remote appliance (for example marketplace-catalog or marketplace-purchase). Resolving one of these addresses finds the gateway’s active WebSocket listener, wraps the HTTP method, path, headers, and body into a DIDComm forwarding message, and waits (30-second timeout) for the matching response. A boundary check rejects any request whose target scheme is not http(s):// or the embedded://marketplace sentinel before it reaches this path, so a stray fabric:// value is never dialed directly over HTTP.

Related

• Trust-fabric integration: The conceptual model for G2G messaging, connection points, and mediators.
• Payments and marketplace: How connected gateways’ models appear in an aggregated marketplace catalog.
• Settings: The appliance limits that gate creating new connection points.
• Security and access control: The RBAC permissions for gateways, connection points, and mediators that gate this page’s records.