Documentation

Architecture Overview

Atlas is not a complicated all-in-one solution. It is composed of separable, composable modules designed to work with existing internet infrastructure — as sidecar infrastructure for big platforms or the foundation for Atlas-first apps.

Parts of Atlas

Transport Layer: HTTP headers and envelope format that form the foundation of authenticated, self-describing data exchange. Adoptable incrementally — three headers on existing requests is enough to start.
Atlas Sign: Stable root identity key, delegated app signing keys, signed permits, portable proofs, and user preferences. Designed as a standalone OIDC and PassKeys replacement. No central account database required.
Atlas Envelope: Self-describing data record. Carries its schema type, validation rules, and authorship proof. Any app can validate any envelope without prior coordination. Serialization format, not a service.
Atlas Registry: Stores and indexes envelopes. Specialized nodes serve specific record types (social, reviews, publications). Validates authorship via Sign, structure via Envelope. Queryable by any app.
Atlas Guide: Indexes registries, ranks content. Ranking rules are readable protocol objects, not hidden algorithms. Inspectable, overridable, forkable. Consumes trust signals from Verify.
Atlas Shelter: Decentralized rental storage. Acts as a persistent inbox and outbox so data stays available when you are offline. Operators publish pricing, users purchase leases with FairShares.
Atlas Governance: Two-layer governance: immutable protocol rules in code, and forkable community Legislation. Trust, verification, economics, and rules — without a central authority.
Atlas Verify: Proves you're a unique human. PoW makes bulk identities expensive. Peer attestation with quadratic costs makes Sybil attacks economically infeasible.
Atlas FairShares: Built-in economic layer. Equal weekly income, burn-based equilibrium. Pays for storage, queries, and shelter leases.
Atlas Trust: Explicit, topic-specific trust allocations between verified humans. Square-root scaling prevents concentration. Temporary by design.
Atlas Timestamping: Witnessing mechanism that makes trust allocations publicly verifiable through signed timestamps from peers.
Atlas Rules: Hard protocol rules in code, soft community rules in forkable Legislation documents. Disagreement diverges, never coerces.

Atlas Sign and Atlas Verify each have dedicated docs pages covering the implemented protocol contracts behind delegated signatures and proof bundles. Read Atlas Sign and Atlas Verify.

Three Integration Levels

Atlas can be adopted incrementally. Each level builds on the previous one but works independently — pick only what you need.

Level 1

Protocol Layer — HTTP Extension

Add three headers to standard HTTP GET and POST requests. That is all it takes to access a verifiable network on your website — display verified content, snippets, and cards. It is a small extension to HTTP transport, nothing more.

Atlas HTTP Headers

GET /envelopes HTTP/2.0
atlas-identity:  <publicKey>
atlas-signature: t=<timestamp>; s=<falcon1024-signature>
atlas-proofs:    [{...}]

The default proof is proof of work — something any website can generate in seconds. With these headers your responses become cryptographically verifiable.

Level 2

Identity — Decentralized Auth

Instead of integrating "sign in with Google", "sign in with Facebook" and ten other providers, add a small SDK (or write simple fetch requests) that connects to the user's local Custodian (it's on https://127.0.0.1:6473; in case of failure user will be asked for remote custodian i.e. name@example.com) and requests an Atlas Sign session bundle: publicKey, delegatedPrivateKey, proofs, and preferences, bound to your origin and requested scopes. The rest of your infrastructure can stay exactly as it is.

Know user identity — the root public key becomes the stable account identifier you can recognize across sessions and across apps.
Sign without exposing the root key — your app uses a delegated signer plus a permit proof instead of holding the user's main private key.
Portable preferences — guide and shelter choices, language, and theme can travel with identity so apps can route writes and discovery without maintaining a separate account settings silo.

Level 3

Registry Infrastructure — Database + API

Run docker registries specialized by the data types you need. Push signed data to each of them, then query. It is a ready-to-use database and API layer supporting Schema.org data structures — that might be enough for a variety of apps.

No mutual trust required — apps no longer need to trust each other and can become part of a larger ecosystem.
Type-sharded storage — each registry focuses on specific content types for better indexing and querying.
Schema.org structures — use standardized data types out of the box.

How It All Fits Together

The Transport Layer (Sign + Envelope) handles authenticated data exchange over HTTP. Registries store and serve that data, with Guides for discovery and Shelters for availability. Governance ties it together with identity verification, economics, trust, timestamping, and forkable rules — all without a central authority.

Shared Packages

Reference documentation for @app_/* shared packages that form the foundation of Atlas Protocol.

Architecture Overview

Parts of Atlas

Three Integration Levels

Protocol Layer — HTTP Extension

Identity — Decentralized Auth

Registry Infrastructure — Database + API

How It All Fits Together

Shared Packages

@app_/crypto

@app_/custodian-client

@app_/registry-client

@app_/validators

@app_/consts