← Proposals

DIP-002

Opt-in encrypted storage + decentralized resilience

Draft   Status: For review — not approved, not built.   2026-06-15

1 · Motivation

• Demand: users want their generated images + long histories to persist across devices. Today images are streamed and never stored; history is text-only.
• Cost discipline: storage isn't free, so it should be paid for by those who use it — not socialized into everyone's inference price.
• Resilience: a single SQLite file + local disk on one box is a single point of seizure/failure — directly at odds with "cannot be shut down." Persisting more data makes solving this urgent.
• Revenue + retention: metered storage is sticky, high-margin recurring balance burn, and deepens the reason a user's data lives here.

2 · The product

• Opt-in. Default stays ephemeral (no image persistence, capped history). The user elects into storage — privacy by default, persistence by choice.
• Metered from balance. Pay per GB-month deducted from credit (usage, not a rigid subscription — consistent with dLLM's no-subscription model). Tiers (e.g. 1 / 10 / 50 GB) are UX simplification over the meter.
• Client-encrypted — "S3 we can't read." Bytes are encrypted in the browser (key derived from the user's 12 words) before they ever leave the device. dLLM and any storage provider hold only ciphertext.
• The honest trade: lose your 12 words → lose the data, same as your balance and history today. No backdoor, by design.

3 · Architecture — split by layer (they have opposite needs)

3.1 Blobs (images, large history) → decentralized object storage

Client-encrypt, then store on a decentralized network; the DB holds only the locator (content hash / object key), never the bytes. Backend options, on a decentralization spectrum:

• Storj — S3-compatible (near-zero integration), client-side encryption + erasure-coding across thousands of nodes. Fastest path. Tradeoff: a company account/satellite billing dependency (decentralized nodes, centralized account layer).
• Filecoin / IPFS — content-addressed, permissionless; pay the network in FIL via storage deals. More on-mission, more integration + retrieval engineering.
• Arweave — pay-once in AR for permanent storage; no company, no monthly bill. Best fit for "store forever," passed through as a one-time fee.

3.2 How the storage backend is paid (the billing flow)

Same pass-through-plus-margin shape as the Venice resale:

• User pays the storage fee from their credit balance → dLLM treasury.
• Treasury pays the backend for the actual GB-months: Storj in fiat or STORJ token; Filecoin/Arweave directly in FIL/AR. Paying in crypto from treasury removes any card/bank rail that could be cut — more "cannot be shut down."
• Margin = user fee − backend cost. Indicative backend rates (directional, verify live): Filecoin ~$0.19/TB-mo, Storj ~$4/TB-mo + egress, Arweave ~$10/GB one-time (permanent). At image scale (~200KB each) all are cheap: a generated image costs ~$0.00004/mo on Filecoin, ~$0.0008/mo on Storj, or ~$0.002 once-forever on Arweave. A dime-ish retail fee is a fat, honest markup on any of them.
• Two SKUs fall out naturally: cheap ongoing storage (Storj/Filecoin, metered per GB-month) + a premium "permanent archive" option (Arweave, one-time fee — store this forever). Both pass-through-plus-margin from balance.

3.3 Coordinator DB (state) → replicate, don't fake "blockchain it"

Accounts, balances, usage, chat ciphertext, registry. Full coordinator decentralization is a research-grade lift most projects fake (centralized coordinator, "decentralized" workers). The honest, shippable resilience:

• Replicate across jurisdictions — Litestream (continuous SQLite → object-storage backup/DR) now; rqlite / LiteFS (Raft-replicated multi-node failover) later. One seizure or failure is not fatal.
• Lean on the ZK model — every node holds only ciphertext, so seizing a box yields nothing readable. Encryption is the censorship resistance.
• Keep the protocol forkable — open code + token + DAO + published/replicated state mean a dead coordinator is replaced from the replica. A seizure becomes a recoverable event, not a death.

4 · What "cannot be shut down" actually means here

Not perfect decentralized consensus (nobody's solved that for a coordinator) — but the combination that genuinely resists shutdown: (a) data that's useless when seized (client encryption), (b) supply that's already permissionless (anyone runs a worker), (c) heavy data on a decentralized storage network (blobs), and (d) a replicated, open, forkable coordinator. Decentralize the heavy data fully; replicate the transactional state; let encryption do the rest.

5 · Honest limits

• Decentralized storage has higher latency + retrieval complexity than local disk — fine for images (not latency-critical), which is why the hot transactional DB stays replicated-SQLite, not on IPFS.
• Storj keeps a company/billing dependency; Filecoin/Arweave remove it at the cost of integration effort. Pick per how much "no middleman" matters vs time-to-ship.
• Coordinator "decentralization" here is replication + forkability, not trustless consensus — stated plainly so the claim is honest.
• Charging for storage creates a durability obligation: once paid, losing user data is a real failure — which is the whole reason replication + a serious backend matter.

6 · Decision points for the DAO

• Approve an opt-in, metered-from-balance encrypted storage tier (vs keeping everything ephemeral).
• Pick the blob backend to start: Storj (fast/S3) vs Arweave/Filecoin (more decentralized, crypto-paid) — or Storj now, migrate to permissionless later.
• Approve treasury paying the backend in crypto (STORJ/FIL/AR) over fiat where possible, for rail-independence.
• Approve coordinator-state replication across jurisdictions (Litestream → rqlite/LiteFS) as the resilience baseline.
• Confirm pricing approach (per-GB-month meter + tier UX) once live backend rates are verified.

Draft for review; confers no commitment until approved by the DAO. Backend pricing figures are order-of-magnitude and must be verified live before pricing. Not financial advice.