Merge branch 'main' into 2025-review

src/_blog/2026-01-fleek-migration.md

@@ -0,0 +1,82 @@
+---
+title: "How to Migrate IPFS Websites from Fleek to Modular Infrastructure"
+description: "A how-to guide for future-proofing your content-addressed website hosting."
+author: Marcin Rataj
+date: 2026-01-06
+permalink: '/2026-fleek-migration/'
+canonicalUrl: https://ipshipyard.com/blog/2026-ipfs-self-hosting-migration/
+header_image: '/2022-ipfs-gateways-1.png'
+tags:
+  - kubo
+  - gateways
+  - fleek
+  - websites
+---
+
+_Cross-posted from the [Shipyard blog](https://ipshipyard.com/blog/2026-ipfs-self-hosting-migration/)._
+
+This is a practical guide to hosting websites on both HTTP and IPFS using modular, swappable components. When Fleek announced it was discontinuing hosting, we migrated 15+ IPFS Project websites to a setup designed to survive any single provider shutting down. Whether you're moving off Fleek or just want more resilient hosting, this guide covers the approach and the tools we used.
+
+## What Changed
+
+Sites including [ipfs.tech](https://ipfs.tech), [docs.ipfs.tech](https://docs.ipfs.tech), [blog.ipfs.tech](https://blog.ipfs.tech), and [specs.ipfs.tech](https://specs.ipfs.tech) now use:
+
+- **[GitHub Pages](https://docs.github.com/en/pages)** for Web2 HTTPS hosting (we already use GitHub for code, so no new third-party dependencies)
+- **[Kubo](https://github.com/ipfs/kubo)** for CID and CAR creation (we control [content-addressing](https://docs.ipfs.tech/concepts/content-addressing/), making content portable across any provider)
+- **[IPFS Cluster](https://ipfscluster.io/)** for long-term pinning and serving content to IPFS network (self-hosted by Shipyard; [pinning services](https://docs.ipfs.tech/how-to/work-with-pinning-services/) work equally well)
+- **[DNSLink](https://docs.ipfs.tech/concepts/dnslink/)** for mapping CIDs to human-readable URLs (decouples naming from content location; automated via [dnslink-action](https://github.com/ipshipyard/dnslink-action))
+
+All sites now have redundant hosting: traditional HTTP via GitHub Pages and content-addressed access via [IPFS Desktop](https://docs.ipfs.tech/install/ipfs-desktop/) with [IPFS Companion](https://docs.ipfs.tech/install/ipfs-companion/) and third-party [public IPFS gateways](https://ipfs.github.io/public-gateway-checker/).
+
+## Third-Party Services Come and Go
+
+Fleek Hosting was a turn-key solution that combined HTTP CDN with TLS, IPFS pinning, IPFS gateway, DNSLink, IPNS, ENS, and GitHub Actions CI integration in one platform. [Fleek is pivoting to AI](https://web.archive.org/web/20260108212232/https://www.fleek.sh/blog/2026-outlook) and [discontinuing its hosting services on January 31, 2026](https://github.com/ipshipyard/waterworks-community/issues/23).
+
+The IPFS service landscape is always evolving. Some providers have shut down or changed focus: [nft.storage transitioned operations](https://web.archive.org/web/20250915005638/https://nft.storage/blog/nft-storage-operation-transitions-in-2025), [Infura deprecated its IPFS public API and gateway](https://web.archive.org/web/20230206190257/blog.infura.io/post/ipfs-public-api-and-gateway-deprecation), and [Scaleway shut down IPFS pinning](https://web.archive.org/web/20251130221548/https://labs.scaleway.com/en/ipfs-pinning/). At the same time, new options have emerged: [Storacha](https://storacha.network/) launched as a successor to web3.storage, Shipyard [took over Cloudflare's public IPFS gateways](https://web.archive.org/web/20251112005234/https://blog.cloudflare.com/cloudflares-public-ipfs-gateways-and-supporting-interplanetary-shipyard/), and pinning services like [Pinata](https://pinata.cloud/) and [Filebase](https://filebase.com/) continue to grow. This isn't a criticism of any particular service. Commercial offerings evolve based on business realities. The lesson: design your setup so that no single provider change requires starting over.
+
+## Modularity as the Future-Proof Approach
+
+IPFS is [built for robustness](https://specs.ipfs.tech/architecture/principles/#robustness): strict about verification outcomes, tolerant about methods. A hosting strategy should follow the same principle.
+
+Decouple Web2 hosting from IPFS content-addressing. Keep each component independent:
+
+- **HTTP**: GitHub Pages, Cloudflare Pages, or a self-hosted server
+- **IPFS**: pinning/storage service, self-hosted Kubo/IPFS Cluster, or both
+- **DNS**: Cloudflare, Gandi, DNSimple, Route53, or any provider with a management API
+
+DNS serves both layers: HTTP needs A/AAAA records and TLS certificates, IPFS needs TXT records for DNSLink to map domains to CIDs.
+
+The key: control CID and CAR creation. Creating the CAR locally means no lock-in to any provider. Pick content providers that accept the CAR. If one shuts down, upload the same CAR elsewhere. HTTP hosting and DNS stay untouched.
+
+Compare this to an all-in-one platform. When it shuts down, everything needs rebuilding.
+
+Two standards make this work: [CAR files](https://docs.ipfs.tech/concepts/glossary/#car) for portable content and [DNSLink](https://docs.ipfs.tech/concepts/dnslink/) for human-readable addressing. Switching providers requires no pipeline changes.
+
+## Our Setup
+
+We use our own [IPFS Cluster](https://ipfscluster.io/) instance since Shipyard already runs IPFS infrastructure. For most projects, a [third-party pinning service](https://docs.ipfs.tech/how-to/work-with-pinning-services/#use-a-third-party-pinning-service) works just as well with less operational overhead.
+
+Our CI/CD uses two GitHub Actions:
+
+- [ipshipyard/ipfs-deploy-action](https://github.com/ipshipyard/ipfs-deploy-action) creates a CID, exports the website DAG as a CAR file, uploads to IPFS Cluster or other pinning services, and provides PR preview links
+- [ipshipyard/dnslink-action](https://github.com/ipshipyard/dnslink-action) automatically updates DNSLink TXT records when the CID changes
+
+![ipshipyard/ipfs-deploy-action posts a comment on each PR with gateway preview links and CID commit status](../assets/2026-fleek-migration-pr-comment.jpg)
+
+For security, we use a sandboxed DNS zone pattern: CI credentials can only modify DNSLink TXT records, not other DNS entries. If credentials leak, the blast radius is limited to the `_dnslink` subdomain. See the [dnslink-action security documentation](https://github.com/ipshipyard/dnslink-action?tab=readme-ov-file#security-sandboxed-dnslink-domain) for details.
+
+## Getting Started
+
+Already have HTTP hosting? Just add IPFS and DNSLink. Migrating from Fleek? Pick all three.
+
+1. **HTTP**: [GitHub Pages](https://docs.github.com/en/pages) and [Cloudflare Pages](https://pages.cloudflare.com/) are simple and maintenance free. For all-in-one self-hosted HTTP+IPFS, see [Setup a DNSLink Gateway with Kubo and Caddy](https://docs.ipfs.tech/how-to/websites-on-ipfs/dnslink-gateway/)
+2. **IPFS**: Choose a [pinning service](https://docs.ipfs.tech/how-to/work-with-pinning-services/#use-a-third-party-pinning-service) or run your own node. Follow [Deploy static apps to IPFS with GitHub Actions](https://docs.ipfs.tech/how-to/websites-on-ipfs/deploy-github-action/)
+3. **DNS**: See [Automate DNSLink updates with GitHub Actions](https://docs.ipfs.tech/how-to/websites-on-ipfs/dnslink-action/) for TXT record automation, or use [OctoDNS](https://github.com/octodns/octodns) for more providers
+
+The [ipfs-deploy-action](https://github.com/marketplace/actions/deploy-to-ipfs) creates the CID and exports the site as a CAR file. This makes content portable across any provider that accepts CARs. The [dnslink-action](https://github.com/marketplace/actions/dnslink-action) links CID to DNS, allowing [IPFS-enabled browsers](https://docs.ipfs.tech/install/ipfs-companion/) to load content over IPFS.
+
+## Conclusion
+
+Third-party services will continue to come and go. The takeaway: separate your concerns and use standards-based tooling. Keep HTTP hosting independent from IPFS content-addressing, create CARs in your own CI rather than someone else's cloud service so you can switch providers, and automate DNSLink updates so they're not tied to any particular service. When one component needs replacing, swap it out without rebuilding everything. This modularity is the robustness that IPFS enables.
+
+All the tools we used are open source and documented. If you have questions, open an issue in the respective repositories or reach out in the [IPFS community forums](https://discuss.ipfs.tech/).

src/_blog/2026-01-ipld-2025-review.md

@@ -0,0 +1,65 @@
+---
+title: "IPLD 2025 Review: From Monoliths to Modules"
+description: "The year that brought us modular Rust libraries, faster DAG-CBOR, stable multiformats, and a simpler on-ramp with DASL."
+author: Volker Mische
+date: 2026-01-19
+permalink: '/2026-01-ipld-2025-review/'
+header_image: '/2026-01-rusted-facade.jpg'
+tags:
+  - ipld
+  - dasl
+---
+
+# IPLD 2025 Review: From Monoliths to Modules
+
+_Cross-posted from the [IPFS Foundation blog](https://ipfsfoundation.org/ipld-2025-in-review/)._
+
+Whether you're building on [IPFS](https://ipfs.tech/), [Filecoin](https://filecoin.io/), or [ATProto](https://atproto.com/), [IPLD](https://ipld.io/) (InterPlanetary Linked Data) — a shared data model for the self-certifying, content-addressable web — ensures your data is portable and verifiable across platforms. This post covers the past year's progress in the IPLD ecosystem and a preview of what to expect in 2026, with a focus on Rust IPLD.
+
+## Rust IPLD: From Monolith to Modules
+
+Following the [JavaScript implementation's](https://ipld.io/libraries/javascript/) lead, we recognized that most projects only need specific IPLD components rather than the full stack. Earlier this year, we successfully migrated the `libipld` functionality into separate, focused crates and [officially deprecated](https://github.com/ipld/libipld/commit/6f0028519d60078f062b1fad403e2c783ce3fb2c) the Rust implementation [`libipld`](https://crates.io/crates/libipld). This modular architecture is now the standard across all IPLD implementations.
+
+Over the past few months, we helped migrate all actively maintained projects that had updates in the past two years. Many projects had already made the switch on their own.
+
+**Performance win:** Moving the Python [DAG-CBOR](https://ipld.io/docs/codecs/known/dag-cbor/) library [`python-libipld`](https://github.com/MarshalX/python-libipld) to [`cbor4ii`](https://crates.io/crates/cbor4ii) and the latest [Rust `cid`](https://crates.io/crates/cid) version made [Bluesky custom feeds in Python ~2x faster](https://bsky.app/profile/marshal.dev/post/3m6wqrij2es2v).
+
+## Migration Guide: What Replaces What
+
+If you're a Rust developer still using `libipld`, here's your upgrade path:
+
+### For IPLD Data Model work
+
+**Use:** [`ipld-core`](https://crates.io/crates/ipld-core), which is similar to the deprecated [`libipld-core`](https://crates.io/crates/libipld-core).
+
+### For encoding/decoding
+
+**Old way:** Custom `libipld` traits for [DAG-CBOR](https://ipld.io/docs/codecs/known/dag-cbor/), [DAG-JSON](https://ipld.io/docs/codecs/known/dag-json/), and [DAG-PB](https://ipld.io/docs/codecs/known/dag-pb/). [`libipld-cbor-derive`](https://crates.io/crates/libipld-cbor-derive) for IPLD Schema-like transformations.
+
+**New way:** Serde-based crates that go directly from serialization to native Rust types without the IPLD Data Model conversion in between:
+
+- [`serde_ipld_dagcbor`](https://crates.io/crates/serde_ipld_dagcbor/) for DAG-CBOR
+- [`serde_ipld_dagjson`](https://crates.io/crates/serde_ipld_dagjson/) for DAG-JSON
+- [`ipld-dagpb`](https://crates.io/crates/ipld-dagpb) for DAG-PB (not Serde-based since DAG-PB doesn't support the full IPLD Data Model)
+
+[IPLD Schema-like transformations](https://ipld.io/docs/schemas/features/representation-strategies/) can now be done directly with [Serde attributes](https://serde.rs/attributes.html).
+
+**Adoption in the wild:** `serde_ipld_dagcbor` is now widely used in the Rust ATProto community, including [rsky](https://github.com/blacksky-algorithms/rsky) (AT Protocol implementation in Rust), [ATrium](https://github.com/atrium-rs/atrium), and [jacquard](https://tangled.org/nonbinary.computer/jacquard) (ATProto/Bluesky libraries).
+
+## IPLD Schemas
+
+[@rvagg](https://github.com/rvagg/) made a [big upgrade to the code generation of IPLD Schemas](https://github.com/ipld/js-ipld-schema/pull/135). When you define a schema, you can now generate code for Go, Rust, and TypeScript.
+
+## Multiformats
+
+The Rust [multiformats](https://multiformats.io/) implementations are under active maintenance and all actionable items on [`cid`](https://crates.io/crates/cid), [`multihash`](https://github.com/multiformats/rust-multihash), and [`multibase`](https://crates.io/crates/multibase) have been resolved.
+
+Rust multiformats now joins Go and JS in being stable and production-ready, and you can expect mostly minor dependency updates in 2026.
+
+## DASL: Starting Simple, Staying Compatible
+
+Not every project needs IPLD's full flexibility. [DASL (Data Addressable Structures and Links)](https://dasl.ing/) offers a streamlined subset: fewer decisions, fewer dependencies, easier to implement. We worked to ensure the DASL specifications remained a strict subset of IPLD, so data created with DASL tools remain seamlessly compatible with the broader IPLD ecosystem.
+
+## Thank You
+
+Special thanks to [@Stebalien](https://github.com/Stebalien/) and [@rvagg](https://github.com/rvagg/) for their countless hours helping maintain various IPLD and multiformats libraries.

src/_blog/bybit-hack.md

@@ -1,6 +1,7 @@
 ---
 date: 2025-02-28
 permalink: /2025-could-ipfs-prevent-bybit-hack/
+canonicalUrl: https://ipshipyard.com/blog/2025-could-ipfs-prevent-bybit-hack/
 title: 'Could IPFS Have Prevented the Bybit Hack?'
 description: 'The Bybit hack revealed several security failures, this post examines whether IPFS could have helped prevent the hack and practical solutions for dapp developers.'
 author: Daniel Norman, Marcin Rataj

src/_blog/shipyard-2024.md

@@ -1,6 +1,7 @@
 ---
 date: 2024-11-25
 permalink: /2024-shipyard-improving-ipfs-on-the-web/
+canonicalUrl: https://ipshipyard.com/blog/2024-shipyard-improving-ipfs-on-the-web/
 title: 'IPFS on the Web in 2024: Update From Interplanetary Shipyard'
 description: 'Update from Interplanetary Shipyard on our efforts to make IPFS work on the Web.'
 author: Daniel Norman

src/_blog/shipyard-hello-world.md

@@ -6,6 +6,7 @@ author: Adin Schmahmann
 
 date: 2024-04-08
 permalink: '/shipyard-hello-world/'
+canonicalUrl: https://ipshipyard.com/blog/shipyard-hello-world/
 header_image: '/shipyard-hello-world.png'
 tags:
   - 'ipfs'