diff --git a/assets/img/filebase delivery.png b/assets/img/filebase delivery.png
new file mode 100644
index 0000000..f9f60bb
Binary files /dev/null and b/assets/img/filebase delivery.png differ
diff --git a/pages/data.md b/pages/data.md
index ffb016c..aa1781a 100644
--- a/pages/data.md
+++ b/pages/data.md
@@ -122,6 +122,25 @@ Instead of files living on one server in one massive data center:
This makes our archive highly resistant to deletion or takedown, and ensures files remain accessible even if a node in the network goes down. That also means if this website were to shutdown, the archive would still be accessible!
+
+
+
+
+
+ A graphic illustrating how files are delivered via IPFS. ('IPFS Concepts,' Filebase Docs)
+
+
+
+
+### How files actually reach you
+
+IPFS itself is a peer-to-peer communication protocol–to load files in a regular web browser, requests go through an **IPFS gateway**: a bridge between the standard web (HTTP) and the IPFS network. {B/qKC} currently uses a dedicated gateway provided by [Filebase](https://filebase.com/), an open infrastructure pinning service. This means files are served quickly via CDN rather than through a slow public relay.
+
+- Filebase is a third-party company, and using their gateway is a pragmatic tradeoff we've made for speed and reliability while our infrastructure matures.
+- Critically, the files themselves remain content-addressed on IPFS: their CIDs are permanent identifiers that work through *any* gateway, not just Filebase's. Our archive is also pinned independently through [Storacha](https://storacha.network/) (a Filecoin Foundation-backed service) and managed locally through IPFS Desktop, meaning no single service controls access to our files.
+
+**Our long-term goal is to serve files directly from our own self-hosted IPFS node, removing the need for any third-party gateway entirely.**
+
---
## 3. The Cloud – We run our own digital space