Revisit layered architecture/design

Motivation

L0 – Bucket system
L1 – Filesystem support, S3 support
L2 – SDKs, APIs, UIs, …

The main question is what can or should be implemented on-chain and what not. Do we want or
need pallets to support L1 features (filesystem, S3), or should these be implemented only at the
provider level (off-chain)?

The ratified design is explicit about the chain's role (docs/design/scalable-web3-storage.md):

"The chain exists as a credible threat, not the hot path—normal operations happen directly
between clients and providers. The chain is only needed for setup, checkpoints and disputes."

"The chain is touched only for: Bucket creation: Once. Agreement setup: Per provider.
Checkpoints: Can be made infrequent. Sync confirmations. Disputes: Rare, expensive,
avoided by rational actors."

"Filecoin: O(storage × time) chain load. This design: O(disputes) chain load—with rational
actors, approaches zero."

What we built for L1 does not fit that, and the two L1 interfaces went in opposite directions —
neither position was ever ratified. This needs to be canonicalized in docs/design/.

Current state

pallet-drive-registry — per-drive only (create_drive, delete_drive, share_drive,
unshare_drive). DriveInfo carries no root CID and there is no root-update extrinsic; the
filesystem metadata root lives only in provider memory (#261).

pallet-s3-registry — three of its five extrinsics are per-object (put_object_metadata,
delete_object_metadata, copy_object_metadata), and Objects holds full metadata for every
object on-chain, permanently. S3Client::put_object calls it on every PUT.

Reads are affected too: S3Client::get_object does two chain reads (bucket, then object metadata)
before contacting the provider; list_buckets is N+1; list_objects would mean iterating on-chain
state.

Scale: 10k accounts creating a drive or an S3 bucket = ≥10k extrinsics before a byte is stored.

Deployment assumption

The expected deployment is Polkadot AssetHub, directly — that is the one deployment. These are
not meant as reusable pallets other chains adopt (possible, but not expected). Whatever L1 keeps
on-chain occupies AssetHub state and block space.

TODO

• Decide the L1 on-chain surface — pure off-chain, or what exactly is allowed to touch the chain
  and at what cadence
• Canonicalize it in docs/design/ (CODEOWNERS-gated); promote or rewrite
  docs/drafts/L1_design_implementation.md (split out in #305) to match
• Reconcile the two L1 pallets to the decision — they currently disagree
• Decide whether L1 clients may read chain state on read paths at all

Related issues

• #40 — Design/Architecture of provider node
• #261 — Move filesystem metadata root on-chain
• #290 — Change filesystem metadata root to a patricia merkle trie root
• #228 — Address L0/L1 mismatch for api endpoints
• Relates to: https://github.com/paritytech/web3-storage/pull/26
• Design discussion: https://docs.google.com/document/d/1AJyQPBwgZgEQL5HThfQtnc3J34_8exDXDXyjGzx3v5M/edit?tab=t.82mrnlgm1z9f#heading=h.d62gxp6uxkpd

Start with docs/design/scalable-web3-storage.md and docs/drafts/L1_design_implementation.md, then inspect pallet-drive-registry, pallet-s3-registry, and the S3Client read and write paths described here. Done means the L1 on-chain surface and read-path policy are decided, canonicalized in docs/design/, and the two pallets are reconciled to that decision.