Skip to main content

Federation

Federation allows independent systems to communicate using a common standard to exchange data while maintaining their own autonomy. In the Paranet ecosystem, data is shared without requiring a centralized authority or a single point of failure, ensuring that your infrastructure remains distributed and resilient.

Federation & The Paranet​

Federation is a core pillar of the Paranet. Think of it as a digital handshake between sovereign entities—allowing them to collaborate on complex or sensitive workflows without surrendering control of their internal data.

Trust and the Otonoma Certificate​

To federate with other nodes in a production environment, each node must possess an Otonoma Certificate. This certificate-based trust allows our distributed-first network to maintain:

  • Data Integrity: Guarantees that the information exchanged hasn't been tampered with.
  • Privacy: Encrypts communication channels between federated peers.
  • Autonomy: Enables independent systems to collaborate while remaining sovereign entities.

Important: Federation in production environments is strictly enforced via Otonoma Certificates. Ensure your node's identity is verified before attempting to establish a link.

CLI Reference: para docker federate​

The para docker federate command is used to establish a link between nodes within a Docker-based environment.

Usage​

para docker federate [OPTIONS]

Example​

para docker federate --from painter --to red --bidirectional

Node Requirements​

Federation between two nodes allows skill requests from one node to the other. The communication happens at the node level. Currently, all exported skill sets in a federated node are shared and accessible on the other node. In the future, our tooling will enable more fine-grained control on which skills are shared between nodes.

Directionality​

Two federated nodes communicate over grpc. The --from node connects to the --to node, with the --to node acting as a server and the --from node acting as a client. By default, only the --to node replicates its skill definitions to the --from node, and not the other way around. This means that skill requests can flow from the --from node to the --to node, and responses can flow back, but skill requests cannot be initated to go the other direction. If you need skills to be replicated both ways you can use the --bidirectional flag.

If new skills are added to a node which is federating its skills, they are automatically propagated to the federated nodes.