Bondy Connect

Appearance

Bondy Edge (Bridge Relay) ​

A bridge relay connects one Bondy node, as a client, to a remote Bondy router — sharing a subset of a realm's procedures and topics over a single dedicated connection, without the two joining the same cluster. Running in this mode is what Bondy calls Bondy Edge: a node placed at a network boundary (an office, a factory floor, a home) that extends a subset of a core deployment's routing to wherever it sits, while remaining administratively and operationally its own node.

Why not just join the cluster? ​

Clustering and a bridge relay solve different problems, and Bondy keeps them as two entirely separate mechanisms rather than variations on one:

  • Cluster peers are equals. Every node in a Partisan cluster holds (a share of) the same realms, replicates the same state, and is expected to stay reachable on a trusted network.
  • A bridge relay connects two independent deployments — often across an untrusted network, and often with the edge side having no fixed address or public port at all. It shares only what's explicitly configured, in one connection, rather than merging the two into one routing domain.

The bridge is always the one that dials out. An edge node behind a NAT, a home router, or a corporate firewall never needs an inbound port open — it connects outward to the remote router's bridge relay listener the same way any WAMP client dials a router. This is the same problem — and the same solution — described in What is an Application Network as the "reverse VPN problem": no VPN client, no exposed port, no reachability requirement on the edge side at all.

A node can run several named bridges to several remote routers at once, each configured and reconnected independently — see the Configuration Reference for the connection, TLS, and reconnection-backoff settings.

Authenticating without shipping a private key ​

The edge authenticates to the remote router as a normal WAMP client, using cryptosign — a public-key challenge, not a shared secret sent over the wire. What's distinctive is where the corresponding private key lives: rather than embedding it in the edge's bondy.conf (an option that exists, but is explicitly documented as testing-only), signing can be delegated to a callee registered locally on the edge, or to an external executable invoked with the public key and challenge as arguments. Either way, the private key stays wherever it was provisioned — a Secure Element, an HSM, a secrets manager — and never has to pass through, or be stored by, Bondy's own configuration. See Delegated signing for the exact keys.

What happens when a realm mapping connects ​

Each bridge.$name.realm.$id mapping opens its own WAMP session on the shared connection, and that session's opening triggers two things:

The realm's security model is synced from the remote to the edge. The remote router ships its copy of the realm record, its groups, users, sources, and grants — everything RBAC needs to authorize a session locally on the edge without a round-trip to the remote for every check. If the realm has a prototype, the prototype realm is synced first, since the target realm's groups/sources/grants may be inherited from it. The remote router strips secret material before it ships the records:

  • The realm's private signing and encryption keys. The edge gets the public keys it needs to verify locally.
  • Each user's password. A synced user therefore cannot authenticate on the edge with a password-based method. Users who connect to the edge authenticate with a method that does not depend on a password, such as cryptosign.

SSO realms are not synced automatically

If the bridged realm authenticates through an SSO realm, that SSO realm's own users, groups, and grants are not pulled in as part of this sync — only the bridged realm's own security tables are. Request the SSO realm explicitly (as its own realm mapping) if the edge needs to authenticate against it directly.

The local registrations and subscriptions on the realm are proxied to the remote router. When the bridge session opens, the edge sends every existing registration and subscription. While the session stays open, the edge also sends each registration or subscription that a client adds or removes. A caller on the remote router can therefore reach a procedure registered on the edge, whether the procedure was registered before or after the bridge connected. Events published on the edge reach subscribers on the remote router for the topics configured with direction: out. Events published on the remote router do not reach subscribers on the edge, and callers on the edge cannot reach procedures registered only on the remote router.

Sharing entries are not an access control

The bridge validates the procedure.$pid match-spec entries but does not apply them: it proxies every registration, whatever the entries say. The topic.$tid entries apply only with direction: out, where the bridge subscribes locally and forwards the events to the remote router. The schema accepts direction: in, but the bridge does not subscribe on the remote router and logs a warning instead; both therefore acts as out. Neither kind of entry limits what the edge exposes.

Running a bridge in a cluster ​

The manager process that reads bondy.conf and starts the configured bridges does not coordinate with other nodes. When every node of a cluster has the same bondy.conf with a bridge in it, every node starts its own copy of that bridge, and each copy opens its own connection to the remote router. A cluster usually needs exactly one bridge for a given remote router.

To run one bridge per cluster, an operator creates it at runtime instead of in bondy.conf. bondy.router.bridge.add starts the bridge only on the node that receives the call, so the choice of node decides where the single bridge runs.

The other side: accepting bridges ​

A remote router doesn't need to be told about each edge that bridges to it — it just needs its bridge relay listener enabled, and it accepts any edge that authenticates successfully for a realm it hosts. Managing bridges at runtime — adding, removing, starting, stopping, checking status — is a WAMP API, so either side of a bridge can be operated the same way you operate anything else in Bondy.

See also ​