Powered by eniston
  1. Overview
  2. Autheo DCS
  3. Autheo Decentralized Storage: Technical Document

Autheo Decentralized Storage: Technical Document

Autheo decentralized cloud storage: Technical document

This document serves as the primary technical specification for the Autheo Decentralized Cloud Storage (ADCS) platform. It details the underlying architectural design, core protocols, data management, and operational mechanics that enable the platform's distributed storage capabilities, providing a comprehensive guide for developers and engineers.

Table of contents

  1. Introduction

  2. Core principles of Autheo DCS

    2.1 Content addressing

    2.2 Merkle DAG file structure

  3. Networking stack: Powered by libp2p

  4. Peer discovery and routing: Distributed Hash Table (DHT)

  5. Data exchange protocol: Bitswap

  6. File lifecycle in Autheo DCS

  7. Implementation overview

    7.1. Custom network identity

    7.2. Dedicated bootstrap infrastructure

    7.3. Isolated DHT routing table

    7.4. Independent gateways

    7.5. Modified configuration and branding

    7.6. Open participation

  8. Developer integration and gateways

  9. References

1. Introduction

Autheo’s Decentralized Cloud Storage (DCS) is a distributed, content-addressable storage network designed to provide robust, fault-tolerant, and censorship-resistant cloud infrastructure. Built on foundational technologies used in decentralized networks, Autheo DCS allows users to store, retrieve, and serve content across a public peer-to-peer system without relying on centralized service providers.

Autheo DCS is not a private or gated system. Instead, it operates as a fully public, open, and independently governed decentralized storage network, engineered for performance, transparency, and modular growth.

 

 

2. Core principles of Autheo DCS

2.1 Content addressing

Autheo DCS uniquely identifies all data with a Content Identifier (CID), which is a cryptographic hash of the content itself. This approach ensures the following:

  • Immutability: Data cannot be altered without changing its CID.

  • Global deduplication: Identical content is stored only once.

  • Permanent linking: Files can be reliably referenced forever, assuming they are hosted.

2.2 Merkle DAG file structure

Autheo DCS structures files and directories using Merkle Directed Acyclic Graphs (DAGs):

  • Large files are split into chunks, each hashed and linked.

  • The root node of the DAG is the file’s CID.

  • This structure allows partial downloads, resumable transfers, and content validation.

  • It also enables efficient versioning and file composition (e.g., directories).

3. Networking stack: Powered by libp2p

Autheo DCS builds its networking layer using the libp2p framework, which supports:

  • Transport layer: Works over TCP.

  • Peer identity: Nodes use cryptographic keypairs for unique identities.

  • Secure communication: All communication is end-to-end encrypted.

This modular network stack allows Autheo DCS to adapt to diverse environments and scale globally.

4. Peer discovery and routing: Distributed Hash Table (DHT)

Autheo DCS uses a custom implementation of a Kademlia-based DHT for decentralized lookup of content and peers:

  • Each node stores a portion of the routing table and responds to lookup requests.

  • When a node adds content, it announces its availability to the DHT.

  • When another node needs the content, it queries the DHT to find the peers hosting it.

This process eliminates the need for centralized directories and ensures high fault tolerance.

5. Data exchange protocol: Bitswap

Bitswap is the protocol used by Autheo DCS nodes to exchange blocks of data:

  • Nodes maintain a want list (blocks they need) and a have list (blocks they can offer).

  • Peers negotiate and exchange blocks based on their needs.

  • This efficient, block-level exchange reduces redundancy and increases transfer speed.

 

6. File lifecycle in Autheo DCS

The typical flow of a file in the Autheo network is as follows:

  1. Add a file

    • The file is chunked, hashed, and converted into a Merkle DAG.

    • A unique CID is generated from the DAG root.

  2. Announce to the network

    • The node advertises the CID via the DHT.

  3. Discovery & retrieval

    • Any node can locate and download the file by querying the DHT and initiating Bitswap transfers.

  4. Pinning

    • Nodes can pin content to ensure its long-term persistence and availability.

7. Implementation overview

Autheo DCS is implemented as a public, standalone decentralized network based on core dcs architecture, but with critical modifications that distinguish it as its own self-contained ecosystem.

Key technical steps

7.1. Custom network identity

  • All Autheo DCS nodes use custom libp2p protocol ID namespaces (e.g., /autheo/kad/1.0.0) to prevent interaction with other networks.

  • Peer IDs and agent strings are scoped to Autheo for clean peer filtering.

7.2. Dedicated bootstrap infrastructure

  • Autheo will operate its own globally available bootstrap nodes to facilitate peer discovery within the DCS network.

  • These nodes are public, high-availability endpoints pre-configured in node software.

7.3. Isolated DHT routing table

  • A new DHT keyspace ensures Autheo DCS nodes only route and discover content within their own network.

  • The Kademlia routing table is isolated from any external dcs DHT.

7.4. Independent gateways

  • Public gateways hosted by Autheo serve HTTP access for the DCS network.

  • These gateways are distinct and will not proxy content from the dcs mainnet.

7.5. Modified configuration and branding

  • The node CLI (autheo daemon) and config files are customized for DCS.

  • Branding, telemetry, and network defaults are clearly separated from dcs.

7.6. Open participation

  • Despite being separate, Autheo DCS is an open network.

  • Any node running Autheo-compatible software and configs can join, contribute storage, and access content.

8. Developer integration and gateways

Autheo DCS provides multiple access points for users and developers:

  • Public HTTP gateways: Access content via links like https://gateway.autheo.network/dcs/<CID>

  • Developer APIs: Upload files, pin content, query metadata, and manage nodes.

  • Client libraries & SDKs: Enable integration into applications, services, and storage clients.

These components ensure ease of use while maintaining full decentralization behind the scenes.

9. References

  • go-libp2p-kad-dht and libp2p

  • Bitswap Protocol

  • Merkle DAGs

  • Kademlia DHT

Was this article helpful?
© 2025 AUTHEO Internal Documentation