Myota Admin Guide — bZa (Myota Command)

The Myota Command is the admin interface used to configure Myota Edges, Shard Repositories, and monitor overall system health.

Overview

The Myota Command (formerly bZa) is a secure, web-based admin interface designed to configure and manage the Myota platform. It simplifies the process of connecting storage repositories, configuring shard pools, creating buckets, and managing access credentials—all without storing sensitive data or credentials. This eliminates administrative interfaces as attack vectors, enabling your team to securely and efficiently deploy Myota's Shard and Spread™ storage architecture.

---

Core Myota Concepts

• Full Copy
  A logically complete copy of user data. In configurations like N=4, T=2, it delivers fault tolerance equivalent to three full data copies, but with significantly lower storage overhead.

• Shard
  An encrypted, non-usable data fragment created by Myota’s encoding engine. Shards contain mathematically zero reconstructable data on their own and are protected by Shamir’s Secret Sharing and erasure coding, making unauthorized reconstruction computationally impossible.

• Durability
  The long-term guarantee that your data remains recoverable from the distributed shard set, even in the event of partial repository failure.

• Myota Immutability
  A multi-layered immutability model enforced by design—not just policy. Data cannot be altered or deleted once written, even if credentials are compromised, thanks to object lock, versioning, software airgaps, and lack of direct shard interfaces.

• System Resilience (N–T)
  Indicates how many shard repositories (N) can lose functionality while still enabling full data recovery with T. System resilience is measured by the minimum N–T across all data types.

---

Shard and Spread™ Model

Myota’s patented Shard and Spread™ process transforms and distributes encrypted data into N shards, stored across multiple independent storage repositories. Any T out of N shards can reconstruct the original data, providing fault tolerance and cryptographic protection. No single shard provides meaningful data, and immutability ensures protection from deletion or tampering.

• Required Repositories (T): Minimum number of repositories needed to recover data

• Total Repositories (N): Total number of repositories across which data is distributed

• Reconstruction: Process of rebuilding data from T valid shards

---

Infrastructure & Components

• Myota Mesh
  The end-to-end system architecture comprising the Edge, Command, Cortex, Shard Pool, and all connected repositories.

• Myota Edge
  The user-facing front end of the Myota Mesh, providing storage interfaces (buckets) to applications and managing all ingress/egress data flows.

• Myota Bucket
  An abstract storage container that appears as a standard object storage endpoint. Data sent to a Myota Bucket is encrypted, sharded, and spread across the Shard Pool.

• Shard Repository
  A physical or virtual storage backend (e.g., AWS S3, Azure Blob, on-premises storage). Each repository stores fragments (shards) of data and collectively forms the Shard Pool.

• Myota Shard Pool (formerly Shard Cluster)
  The collective set of Shard Repositories used to distribute and protect data. The Shard Pool enforces redundancy, reconstruction thresholds, and immutability policies.

• Myota Command (formerly bZa)
  The admin interface for configuring Edges, Shard Repositories, Shard Pools, and Buckets. It separates configuration from data processing to eliminate credential exposure.

• Myota Cortex (formerly bZs)
  The secure data processing layer of the Edge. It performs encryption, sharding, policy enforcement, and storage operations—completely isolated from admin interfaces.

---

Quick Start: Deploying Myota

When you first sign in to the Myota Command interface, you’ll begin the process of configuring your secure, distributed storage environment. Setup starts on the Buckets page, where you’ll connect a minimum of three shard repositories to enable data redundancy and resilience. From there, you’ll configure a Shard Cluster to define how data is split, stored, and recovered across repositories—tailored to your organization’s governance and compliance needs. Once the cluster is in place, you’ll create a bucket to logically organize and manage your data, followed by generating access credentials that allow secure data access without storing any secrets in the console. This streamlined process ensures your system is securely configured and ready to launch Myota Cortex (bZs) for robust, fault-tolerant storage operations.

Step 1: Connect Shard Repositories

The initial step involves connecting shard repositories. To ensure the system operates effectively, a minimum of three repositories must be established, facilitating adequate data distribution and resilience across diverse storage locations. Prior to initiating the connection process, ensure that your object storage resources are properly prepared for integration. It’s essential to verify that all connections are successfully established.

Make sure you have at least three object storage resources ready for configuration. The available repository options include:

• AWS S3 / Compatible: Bucket Name, Region, Endpoint

• Google Cloud Storage: Bucket Name, Region

• Azure Blob Storage: Container Name, Location

Steps:

1. Go to Shard Repositories

2. Click New Connection

1. Enter required details and click Add Shard Repository

Supported Storage Types and Required Information

S3-Compatible (e.g., AWS S3):

• Bucket Name

• Region or Custom Region Name

• Endpoint URL

Google Cloud Storage:

• Bucket Name

• Region

• Region Name

Azure Blob Storage:

• Container Name

• Location

• Custom Location Name

Tip: Ensure at least 3 repositories are connected for full system functionality.

---

Step 2: Configure Shard Pool (formerly Shard Cluster)

Before establishing connections to shard repositories, it's crucial to create a minimum of three object storage buckets. The process of setting up these buckets is typically straightforward across various object storage services; you simply need to assign a name to each bucket, select the preferred storage region, and configure any necessary access permissions. These buckets will serve as the designated storage locations for your data shards, allowing for the distribution of information across multiple sites to enhance both security and resilience. This configuration also provides the opportunity to specify essential data resiliency parameters, such as redundancy levels and recovery thresholds, which determine the number of shard repositories that must remain operational to successfully restore your data after a failure. Furthermore, the Shard Pool configuration defines the storage locations for different shard types—such as content, key, and metadata shards—ensuring alignment with your organization's data governance and compliance standards. Proper configuration of the Shard Pool is vital for enabling your system to effectively manage failures while safeguarding data security and availability.

The Shard Pool establishes the settings for data resiliency and recovery thresholds.

1. Navigate to the Shard Clusters section to view all existing shard clusters.

2. Click “New Cluster” to begin creating a new cluster. You’ll be prompted to enter a Cluster Name and Add Shard Repositories.

   • 
     

     Note: At least three shard repositories are required to create a cluster.

3. Enter a unique Cluster Name.

4. Click “Add Shard Repositories”. Myota requires a minimum of three repositories for redundancy.

5. Select “Select Shard Repository” to choose from your existing repositories or create new ones.

   • 
     

6. Choose at least three shard repositories from the list.

7. Click “Select” to confirm your selections. The Data Reconstruction section will now appear for configuration.

   • 

     • Tip: For guidance on choosing repositories, refer to the bZa 2.0 Admin Guide – Best Practices for Selecting Shard Repositories.

8. Once all required information is filled out, click “Save” to finalize your Shard Cluster.

Step 3: Create a Bucket

A bucket functions as a specialized storage container that organizes and manages the different shards within a Shard Pool. It brings together related objects—such as files, metadata, and other content—into a well-structured and easily accessible environment. By creating a bucket, you can establish access controls, oversee object metadata, and ensure compliance with your organization’s data governance policies. This step is crucial for laying the groundwork of your data architecture, facilitating secure, efficient, and compliant storage within the system.

Buckets act as the logical data containers utilized by applications.

Steps:

1. Go to Buckets

2. Click Create

   • 
     

3. Name your bucket (follows AWS S3 naming rules)

4. Select a Shard Pool

   • 

5. Assign shard storage settings

6. Click Save

---

Step 4: Create Access Credentials

To finalize your setup, it's essential to create access credentials, a key step in ensuring secure access to your data. This process requires you to input the access key and secret linked to your connected shard repositories. Notably, the admin console is designed to not retain these credentials, thereby minimizing the risk of a single point of vulnerability. Once you have created the credentials, you can generate the configuration package necessary to launch Myota Cortex (formerly bZs), thereby completing the setup for a secure, resilient, and efficient data storage environment.

Ensure that you create secure credentials to facilitate your applications' access to the bucket.

Steps:

1. Navigate to the Access Credentials section to view all existing configuration files.

2. Click “Create” to begin the process.

   • 
     

3. Enter a Credential Name.

4. Select an existing Bucket, or create a new one directly from this screen.

5. Click “Next” to proceed.

   • 

6. For each connected shard repository, click its name to enter the Access Key ID and Secret Access Key.

   • Use the “Test Connection” option to confirm connectivity.
     

   • If the test is successful, click “Done.”

Download the config file and store it securely.

The admin console does not retain any credentials. This design choice is intentional and crucial for maintaining the security of your data access. By not storing credentials within the admin console, the potential risk of exposure is significantly minimized. Users are encouraged to generate and securely store their access keys and secrets in a safe location, such as a password manager or a secure vault. This practice not only protects sensitive information but also ensures that access to your data remains tightly controlled and monitored. Always remember to handle your credentials with care and to follow best security practices when managing access to your Myota environment.

---

Best Practices for Shard Repository Selection

---

Launching and Monitoring Myota Cortex (formerly bZs)