[kcskribbl]

Stacked dependency

This is a documentation-only follow-up to draft PR #2, based exactly on its head 1cf6145fe12c2459663a67e13ddba0a92dc2b882.

• Base: feat/secure-pluggable-blob-storage (PR Add pluggable storage providers and optional AWS hybrid foundation #2's head branch), not main.
• Head: docs/aws-p2p-diagrams.
• Keep this PR draft while Add pluggable storage providers and optional AWS hybrid foundation #2 remains draft. Review/merge the dependency first; retarget only after checking that the diff remains documentation-only. This PR neither merges nor marks Add pluggable storage providers and optional AWS hybrid foundation #2 ready.

Diagrams

Adds five GitHub-renderable Mermaid diagrams in docs/STORAGE_TOPOLOGY_DIAGRAMS.md:

1. Proposed AWS private three-peer Kubo/Cluster topology: operator-owned networking/runtime versus the optional CloudFormation foundation.
2. Write ordering: application-encrypted bytes -> observed replication -> synchronous immutable SSE-KMS S3 backup -> atomic DynamoDB pointer publication.
3. Explicit CID-validated restore and repinning, with no index change or silent read fallback.
4. Default local npm start UI/API -> FileBlobStore .data/web, requiring no IPFS, Docker or cloud.
5. Optional native-Linux Docker fixture: three Kubo + three Cluster containers, internal bridge, loopback-only relays, local file metadata/backups and node-loss probe limits.

Links added from storage quickstart, design, distributed-storage and AWS runbook docs. Azure: To be decided; no deployment topology or cross-cloud mirroring is implied. No runtime, dependency or README changes.

Boundaries

• Synthetic-only research POC; no clinical, regulatory or production claim.
• Three nodes/AZs are a proposed operator-supplied topology, not existing automation. CreateNode=false by default; the foundation can create at most one optional EC2 node and requires an approved AMI. Additional peers, networking, private HTTPS proxies and secret injection are manual prerequisites.
• Patient/clinician dual unlock and encryption remain in the application; KMS protects infrastructure only. Runtime secrets contain infrastructure/API material, never GitHub credentials or patient factors. Current web transport stays loopback-only.
• At least two distinct live Kubo replicas must be observed before success; Cluster/Raft control membership is not application CAS. Index/account/IAM/KMS and ingress dependencies remain. No automatic failover or independent decentralized governance/durability claim.

Validation

• Compared diagrams with IPFS provider/client/distributed store/backup wrapper, DynamoDB/S3 adapters, foundation JSON/runtime samples, and integration runner/fixture.
• git diff --check and staged whitespace checks passed.
• Checked 24 relative links, balanced Markdown fences, five diagram structures, declared endpoints and sequence participants. Mermaid syntax manually inspected; no renderer was installed or rendering claimed.
• Documentation-only: no runtime tests or cloud deployment run, and no dependencies installed.
• Work performed exclusively in separate worktree C:\p\personal\GDP2-storage-diagrams; the parallel Swagger checkout was not edited, staged, committed or switched.