Architecture Overview

Video Introduction

Armada Architecture

The Armada network is comprised of two different node types: Domain Node and Content Node. There's also a browser-based sandbox to communicate securely with Domain and Content Nodes called the Secure Enclave.

This information is a high-level overview of the Armada Architecture. For even more information please check out the whitepaper.

Secure Enclave

A service worker in the web browser that runs a set of static HTML and JS files returned by the Domain Node. These files are project specific and have a list of Content Nodes for the project based on the browser's location.

This Secure Enclave is also responsible for fetching the correct content bundle from Content Nodes and verifying that each file in the bundle matches the expected checksum.

Domain Node

A server that is responsible for maintaining SSL for a project's domain, but hosting none of the website content. Its primary role is to handle HTTPS connections and returning the Secure Enclave code to the browser.

Since this node provides SSL, a domain node is specific to a project and it must be a node trusted by the project. It's possible to run multiple Domain Nodes for redundancy by setting multivariate A records on the DNS for different nodes.

Content Node

An Armada content node is essentially an HTTP static file server, acting on behalf of a project that has paid to reserve it. The project dictates what content should be served recording the URL of a tarball containing the project website (and its checksum) onto the Armada Smart Contracts. Content nodes that have been reserved will fetch their project's tarball from its origin, verify it, and serve its file contents when requested.

In addition to serving static files for a project, content nodes also participate in a distributed monitoring system whereby peer nodes are assessed for uptime and performance. This data is collected over time and stored in a local database, where it eventually gets retrieved by the Armada network reconciliation process.

The requirements for running a content node are outlined in the Content Node Setup page, but generally follow from its responsibility as a basic HTTP server: it must be reachable via HTTPS, needs a modest amount of dedicated CPU/memory, persistent storage, and a high quality network link.