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