Autonomi Stores Immutable Chunks — Public Address vs Private DataMap

Cloud object storage trained a generation of builders to treat a path as editable furniture: overwrite the blob, keep the same key, renew the lease. Autonomi 2.0’s documentation describes a different contract. At the network level the storage primitive is not a mutable file. It is an immutable, content-addressed chunk. Change the bytes and you change the address. Public versus private is mostly a question of where the DataMap lives — not two separate low-level stores.

This note sits beside the earlier CryptoDecentral walkthrough of self-encryption and the Data Map. That piece covers chunking, ChaCha20-Poly1305, and XOR placement. Here the thesis is narrower and more operational: immutability is the product, the public-address and private-DataMap interfaces are how apps find those chunks again, and live mutable collaboration belongs (per Autonomi’s own framing) to a complementary layer — not to “edit this chunk in place.”

Educational only. No token pitch, no migration coaching, no claim that permanence is metaphysics.

One primitive underneath

Autonomi’s data-types docs are blunt. All data stored on the network is permanent and unchangeable. That immutability is described as foundational to the pay-once economic model: you pay when content is written; you do not rent an editable room that the operator can quietly rewrite.

When content is uploaded:

1. Self-encryption turns bytes into encrypted chunks (each up to roughly 4MB; large files become many chunks).
2. A DataMap records network addresses of those chunks plus the hash material needed to decrypt and reassemble.
3. Chunk addresses are derived from hashes of encrypted content — content-addressing under encryption.

A “file” on Autonomi is therefore a recipe: instructions for finding immutable parts and assembling them, plus metadata about what comes back when you do. The DataMap is retrieval metadata, not a second storage primitive competing with chunks.

Developer docs map higher-level surfaces onto that same substrate:

Interface	Under the hood	Typical use
Public data	Chunks plus a published DataMap address	Shared payloads, public content
Private data	Chunks plus a client-held DataMap	Content you keep retrieval-private
Chunk	A single chunk stored directly	Low-level tooling
File	Self-encrypted chunks plus a file-oriented DataMap flow	Disk upload/download paths
DataMap	Retrieval metadata	Later downloads, private reassembly

Public and private are not two different DHT machines. In public workflows the DataMap is stored or published so content can be retrieved by address. In private workflows the DataMap stays with you (or encrypted under your control) and is not stored publicly. Daemon APIs make the difference visible: POST /v1/data/public returns a public address; POST /v1/data returns a serialized DataMap without publishing it. In both cases the underlying content is still chunks.

Keys, addresses, and DataMaps are three jobs

A recurring confusion in decentralized storage is collapsing payment, publication, and private retrieval into one “master key.” Autonomi’s keys-addresses-DataMaps docs separate them on purpose:

• Wallet private key — pays for uploads (AUTONOMI_WALLET_KEY for antd, SECRET_KEY / attached Wallet for ant / ant-core). Payment material, not private-data decryption.
• Public address — returned after a public upload or public DataMap store. Share or store it; use it to retrieve published content. If content changes, the address changes, because storage is content-addressed and immutable.
• DataMap — private retrieval material that ties uploaded content back to encrypted chunks. Chunks may still live on the network; without the DataMap you lose practical ability to retrieve private content. That is a data-access concern, not a payment concern.

Treat those as one all-purpose secret and you will mis-design backups, multi-device access, and sharing. Treat them as three jobs and the public/private split becomes mechanical rather than mystical.

Why immutability forces “new upload” thinking

Content-addressing has a practical consequence builders often under-specify: there is no honest “overwrite at this path.” A new version is a new upload that produces new chunk addresses (and, for public content, a new address). Old chunks remain as previously written, subject to the network’s replication and churn behaviour documented elsewhere.

That is a feature for integrity and pay-once accounting, and a constraint for application design:

• Versioned archives, signed releases, and civic records map cleanly onto immutable chunks plus published addresses or carefully held DataMaps.
• Collaborative docs, live presence, and conflict-prone shared state do not map onto “mutate the chunk.” Autonomi’s introduction and data-types pages point mutable shared state, real-time interaction, and collaboration to x0x — a complementary post-quantum gossip network sharing transport and cryptography, not a second object store with the same immutability rules.

x0x’s own conceptual guide frames the split plainly: Autonomi handles permanent immutable storage; x0x handles live ephemeral coordination between peers (gossip, CRDT-backed structures, direct messaging). Same family of transport and post-quantum cryptography; different shapes of work. Naming that fence early saves projects from forcing editable UX onto a store that refuses silent overwrite.

Pay-once writes without turning this into a market note

Developer payment-model docs describe Autonomi as pay-once on upload: payment is tied to writes (data, chunks, files); downloads are not framed as a separate recurring storage lease or retrieval fee in that model. Writes need wallet context. Nodes verify payment proofs before accepting chunks. Payment modes include auto, merkle (batch), and single (per-chunk), with Merkle preferred above a documented chunk threshold in ant-core.

FSCA fence, stated once: naming the mechanism (pay-once write; wallet-backed upload; node verification of proofs) is protocol literacy. It is not a recommendation to acquire, hold, or trade any network token, not a price commentary, and not yield or return language. For costs and markets, read primary docs yourself — this site does not advise.

Civil autonomy without a single geography

Immutable, content-addressed storage changes the shape of dependency for people and groups who cannot assume a friendly corporate account forever: independent journalists, diaspora archives, clinics and cooperatives under platform or payment pressure, and communities that need bit-level integrity rather than “trust the bucket UI.” Recurring cloud rent, unilateral account death, and opaque overwrite all fail in ways that are not abstract when power is uneven.

Autonomi’s documented answer is client-side encryption before upload, chunks that do not edit in place, and a clear split between public addresses and private DataMaps. That is one architecture among several honest options (content-addressed IPFS-class systems, local encrypted archives, offline roots of trust). The civil-liberty question to keep asking is concrete: who can unilaterally make your bytes disappear or mutate under the same name, and what material must you hold to reassemble them?

What this note deliberately does not do

It does not promote network tokens, quote prices, or suggest buy/sell timing. It does not rank Autonomi against competitors or claim the network is finished, nation-state-proof, or immune to client bugs, lost DataMaps, thin node diversity, or physical seizure of disks. It does not give personalised custody advice, product setup framed as financial guidance, or “migrate off Big Tech this weekend” coaching. It does not treat “permanent” as metaphysics — immutable content-addressed storage is a protocol design; physical reality still includes disk failure, legal compulsion, and software defects. It does not rewrite the companion note on self-encryption mechanics; use that for ChaCha20-Poly1305, Brotli, and close-group XOR placement.

Educational takeaway: if you can name the chunk as the only network storage primitive, explain why public address and private DataMap are two retrieval stories over the same substrate, and say out loud that updates are new content-addressed uploads — with live mutable work pointed elsewhere — you are evaluating Autonomi’s claims as documentation, not as slogans.

Related on CryptoDecentral

• Autonomi pillar
• Self-encryption & Data Map note
• Self-custody & wallets pillar
• Privacy pillar
• Network metrics

Further reading (primary)

• Data types (how it works)
• Data types (developer)
• Keys, addresses, and DataMaps
• Payment model
• Self-encryption
• Content-addressable storage
• What is Autonomi?
• x0x conceptual guide (complementary gossip/CRDT layer)