Skip to main content

Domain

Synced from the repository

This page mirrors core/domain/README.md in the posemesh repo (branch main). The repository is the source of truth.

The domain package is a core component of the Posemesh system, designed to facilitate secure and private data exchange within domain clusters.

Getting Started​

We will have a new discovery service to manage domain managers/servers soon. Before that, feel free to contact us on Discord if you want to use our domain manager for trying out the examples below.

  • examples/client: A Rust client for downloading and uploading domain data.
  • domain/examples/browser: A web application using this module to download and upload domain data.

Domain Data Storage​

The datastore module provides mechanisms for both remote and in-house data storage solutions.

  • Remote Storage (remote.rs): This module handles data storage in remote locations, allowing for distributed data management across the domain cluster, ensuring rapid access and scalability.
  • Local Storage (fs.rs, metadata.rs): These modules manage local data storage, ensuring that data is persisted efficiently and securely within the local environment.

Uploading data supports streaming by default, enabling fast and efficient data transfer. Each piece of domain data is chunked into 7KB segments and organized into a Merkle tree. Both the sender and receiver construct the tree to serve as proof of data transfer, ensuring integrity and speed in distributed environments.

Capabilities​

The capabilities modules define the functionalities that a node within the domain cluster can perform.

  • /load/v1: Provides an endpoint to serve domain data.
  • /store/v1: Offers an endpoint to accept domain data and store it in a data repository.
  • /public-key/v1: Supplies the public key for JWT verification.

Protobuf​

The protobuf modules contain all the protocol buffers used in peer communication. These are auto-generated by build.rs. Protobuf provides a language-neutral, platform-neutral, and extensible mechanism for serializing structured data, ensuring efficient and reliable data exchange between peers in the domain cluster.

Domain Cluster​

The cluster module serves as the cluster client, enabling peers to communicate with the domain manager.

The domain cluster is designed to be a secure, private peer network that allows participants to collaborate and exchange data while maintaining privacy. It is built on a distributed hash table that lists participants and their capabilities, enabling seamless peer awareness and collaboration without a central authority. While our current implementation is not fully decentralized, we are actively working towards achieving this goal.

Job vs Task​

A job is a collection of tasks, with each job containing at least one task. It allows for the configuration of dependencies between tasks, ensuring that they are executed in the correct order. The structure of a task and job is defined in protobuf/task.proto. Jobs are essential for organizing and executing tasks within the domain cluster, facilitating efficient task management and execution.

Peer vs Node​

A peer refers to any libp2p instance within the domain cluster. These are the basic units of the network, capable of participating in communication and data exchange.

A node, on the other hand, is a peer that possesses specific capabilities. Nodes are responsible for executing tasks, managing data, and performing other specialized functions within the cluster. To verify their capability registration, nodes need to register with the discovery service. Not all peers are nodes, but all nodes are peers with additional roles and responsibilities.

Domain Manager​

The domain manager is a special node within the domain cluster, responsible for managing tasks, accepting data uploads, and serving domain public keys. It needs to be publicly accessible and online 24/7, allowing other nodes in the domain cluster to use it as a bootstrap node to access the Kademlia DHT. The domain manager also stores one key pair for each domain. Peers who want to collaborate in the domain need to submit jobs to the domain manager, which issues a time-limited and scope-limited JWT token signed by the domain's private key.

Currently, the domain manager also functions as a relay due to its public accessibility. However, this capability will be transitioned to the standalone Relay service once it is integrated with the Posemesh SDK. The Relay service, as described in the AUKI Posemesh Whitepaper, is designed to handle real-time, low-latency communication, leveraging decentralized infrastructure to enhance performance and scalability.

Trustless Domain Cluster​

The domain manager is a critical component of the domain cluster, yet it presents several challenges that must be addressed to ensure robust and secure operations:

  • Local Key Storage: Storing key pairs locally poses significant security risks. Unauthorized access could lead to a complete compromise of the domain.

  • Single Point of Failure: As the central authority, the domain manager represents a single point of failure. Any downtime can render all managed domains inoperative.

  • Trust Dependency: Domain owners are required to place significant trust in the domain manager's ability to operate securely and reliably. Any negligence or malicious behavior could jeopardize domain security.

To mitigate these risks, we are exploring several alternatives:

  • Decentralized Key Management: Utilize smart contracts specifically for the management of domain keys, reducing reliance on centralized entities and enhancing cryptographic security.

  • Distributed Network Architecture: Implementing a distributed network of domain managers will ensure high availability and fault tolerance, reducing the risk of downtime.

  • Trustless Systems and Reputation Mechanisms: Establish a framework where domain managers actively witness and validate each other's actions. This mutual validation process ensures system integrity and security. Additionally, domain owners can select domain managers based on their reliability and performance history, fostering a more secure and trustworthy environment.

Cluster Security​

Data security within the domain cluster is ensured through several mechanisms:

Authentication and Encryption​

Using libp2p's security features, such as secure channels and peer authentication, we ensure that communication between nodes is encrypted and authenticated.

  • Noise Protocol: We utilize the Noise Protocol Framework to encrypt data between nodes, providing forward secrecy and secure communication. Noise is used to establish a secure channel by exchanging keys and encrypting traffic during the libp2p handshake process. More information can be found in the Noise documentation.

  • QUIC: QUIC is employed as a transport protocol to provide an always-encrypted, stream-multiplexed connection built on top of UDP. It ensures security by using TLS 1.3 for encryption and authentication, reducing latency and preventing head-of-line blocking. For more details, refer to the QUIC documentation.

  • WebRTC: For browser-to-peer communication, we use WebRTC, which allows secure, real-time communication between browsers and public peers. WebRTC is designed to work seamlessly with NAT traversal and provides encrypted data channels. More information can be found in the WebRTC documentation.

Initially, the design involved the domain manager sending a PSK to each peer upon joining the cluster, creating a private libp2p network for each domain cluster. However, this approach presented several challenges:

  • Frequent Peer Changes: With peers frequently joining and leaving the cluster, managing preshared keys became cumbersome. Rotating the preshared key every time a peer leaves would require all peers to reboot, disrupting ongoing connections and affecting network stability.

  • Network Stability: The need for frequent key rotations could lead to significant disruptions, making it difficult to maintain stable and continuous network operations.

Due to these challenges, we are exploring more dynamic and flexible authentication mechanisms, such as Task Tokens, which can accommodate frequent peer changes without compromising network stability.

Task Tokens​

A task token is a JWT issued by the domain manager, ensuring that only authorized peers can execute tasks within the cluster. This mechanism maintains the integrity and security of the domain.

Challenges​

Limitations of WebRTC​

  • STUN and TURN Support: Rust libp2p WebRTC supports STUN, which allows traversal of basic NAT setups. However, TURN support may not be fully integrated yet, which is necessary for more restrictive NAT scenarios.

  • Signaling Server Requirement: A WebRTC signaling server (such as WebRTC "star" or a custom signaling server) is needed to facilitate connection negotiation, adding an additional component to the network setup.

DHT​

We initially considered leveraging the Distributed Hash Table (DHT) for storing nodes and their capabilities. However, there are significant limitations that have led us to reconsider this approach:

  • Complex Queries: DHTs are not well-suited for complex queries, such as those based on node capabilities or more descriptive queries. This limitation makes it challenging to efficiently retrieve and manage node information.

  • Security Concerns: Ensuring that only authorized peers can update the DHT is difficult. The open nature of DHTs can expose the network to unauthorized updates and potential security vulnerabilities, as highlighted in libp2p's security considerations.

  • Scalability Issues: As the network grows, maintaining the DHT can become increasingly complex and resource-intensive, impacting performance and reliability.

Currently, we are using the DHT in the domain cluster primarily for peer discovery. Given these limitations, we are actively exploring alternative solutions that provide better support for complex queries and enhanced security.