docs: use specs.ipfs.tech links for merged IPIPs (#11228)

- point to canonical URLs instead of github PR links
- only updated active docs and v0.40 changelog
- left old changelogs and unmerged IPIPs as-is

Author: lidel

config/profile.go

@@ -327,7 +327,7 @@ fetching may be degraded.
 		Description: `Legacy UnixFS import profile for backward-compatible CID generation.
 Produces CIDv0 with no raw leaves, sha2-256, 256 KiB chunks, and
 link-based HAMT size estimation. Use only when legacy CIDs are required.
-See https://github.com/ipfs/specs/pull/499. Alias: legacy-cid-v0`,
+See https://specs.ipfs.tech/ipips/ipip-0499/. Alias: legacy-cid-v0`,
 		Transform: applyUnixFSv02015,
 	},
 	"legacy-cid-v0": {
@@ -338,7 +338,7 @@ See https://github.com/ipfs/specs/pull/499. Alias: legacy-cid-v0`,
 		Description: `Recommended UnixFS import profile for cross-implementation CID determinism.
 Uses CIDv1, raw leaves, sha2-256, 1 MiB chunks, 1024 links per file node,
 256 HAMT fanout, and block-based size estimation for HAMT threshold.
-See https://github.com/ipfs/specs/pull/499`,
+See https://specs.ipfs.tech/ipips/ipip-0499/`,
 		Transform: func(c *Config) error {
 			c.Import.CidVersion = *NewOptionalInteger(1)
 			c.Import.UnixFSRawLeaves = True

docs/changelogs/v0.40.md

@@ -49,7 +49,7 @@ This release brings reproducible file imports (CID Profiles), automatic cleanup
 
 #### 🔢 IPIP-499: UnixFS CID Profiles
 
-CID Profiles are presets that pin down how files get split into blocks and organized into directories, so you get the same CID for the same data across different software or versions. Defined in [IPIP-499](https://github.com/ipfs/specs/pull/499).
+CID Profiles are presets that pin down how files get split into blocks and organized into directories, so you get the same CID for the same data across different software or versions. Defined in [IPIP-499](https://specs.ipfs.tech/ipips/ipip-0499/).
 
 **New configuration [profiles](https://github.com/ipfs/kubo/blob/master/docs/config.md#profiles)**
 
@@ -94,7 +94,7 @@ Under the hood, the block storage layer (flatfs) was rewritten to use atomic bat
 
 #### 🌍 Light clients can now use your node for delegated routing
 
-The [Routing V1 HTTP API](https://specs.ipfs.tech/routing/http-routing-v1/) is now exposed by default at `http://127.0.0.1:8080/routing/v1`. This allows light clients in browsers to use Kubo Gateway as a delegated routing backend instead of running a full DHT client. Support for [IPIP-476: Delegated Routing DHT Closest Peers API](https://github.com/ipfs/specs/pull/476) is included. Can be disabled via [`Gateway.ExposeRoutingAPI`](https://github.com/ipfs/kubo/blob/master/docs/config.md#gatewayexposeroutingapi).
+The [Routing V1 HTTP API](https://specs.ipfs.tech/routing/http-routing-v1/) is now exposed by default at `http://127.0.0.1:8080/routing/v1`. This allows light clients in browsers to use Kubo Gateway as a delegated routing backend instead of running a full DHT client. Support for [IPIP-476: Delegated Routing DHT Closest Peers API](https://specs.ipfs.tech/ipips/ipip-0476/) is included. Can be disabled via [`Gateway.ExposeRoutingAPI`](https://github.com/ipfs/kubo/blob/master/docs/config.md#gatewayexposeroutingapi).
 
 #### 📊 See total size when pinning
 
@@ -108,13 +108,13 @@ Fetched/Processed 336 nodes (83 MB)
 
 #### 🔀 IPIP-523: `?format=` takes precedence over `Accept` header
 
-The `?format=` URL query parameter now always wins over the `Accept` header ([IPIP-523](https://github.com/ipfs/specs/pull/523)), giving you deterministic HTTP caching and protecting against CDN cache-key collisions. Browsers can also use `?format=` reliably even when they send `Accept` headers with specific content types.
+The `?format=` URL query parameter now always wins over the `Accept` header ([IPIP-523](https://specs.ipfs.tech/ipips/ipip-0523/)), giving you deterministic HTTP caching and protecting against CDN cache-key collisions. Browsers can also use `?format=` reliably even when they send `Accept` headers with specific content types.
 
 The only breaking change is for edge cases where a client sends both a specific `Accept` header and a different `?format=` value for an explicitly supported format (`tar`, `raw`, `car`, `dag-json`, `dag-cbor`, etc.). Previously `Accept` would win. Now `?format=` always wins.
 
 #### 🚫 IPIP-524: Gateway codec conversion disabled by default
 
-Gateways no longer convert between codecs by default ([IPIP-524](https://github.com/ipfs/specs/pull/524)). This removes gateways from a gatekeeping role: clients can adopt new codecs immediately without waiting for gateway operator updates. Requests for a format that differs from the block's codec now return `406 Not Acceptable`.
+Gateways no longer convert between codecs by default ([IPIP-524](https://specs.ipfs.tech/ipips/ipip-0524/)). This removes gateways from a gatekeeping role: clients can adopt new codecs immediately without waiting for gateway operator updates. Requests for a format that differs from the block's codec now return `406 Not Acceptable`.
 
 **Migration**: Clients should fetch raw blocks (`?format=raw` or `Accept: application/vnd.ipld.raw`)
 and convert client-side using libraries like [@helia/verified-fetch](https://www.npmjs.com/package/@helia/verified-fetch).

docs/config.md

@@ -1158,7 +1158,7 @@ dag-pb or dag-cbor to dag-json).
 
 When disabled (the default), the gateway returns `406 Not Acceptable` for
 codec mismatches, following behavior specified in
-[IPIP-524](https://github.com/ipfs/specs/pull/524).
+[IPIP-524](https://specs.ipfs.tech/ipips/ipip-0524/).
 
 Most users should keep this disabled unless legacy
 [IPLD Logical Format](https://web.archive.org/web/20260204204727/https://ipld.io/specs/codecs/dag-pb/spec/#logical-format)
@@ -2829,7 +2829,7 @@ It specifies the routing type that will be created.
 
 Currently supported types:
 
-- `http` simple delegated routing based on HTTP protocol from [IPIP-337](https://github.com/ipfs/specs/pull/337)
+- `http` simple delegated routing based on HTTP protocol from [IPIP-337](https://specs.ipfs.tech/ipips/ipip-0337/)
 - `dht` provides decentralized routing based on [libp2p's kad-dht](https://github.com/libp2p/specs/tree/master/kad-dht)
 - `parallel` and `sequential`: Helpers that can be used to run several routers sequentially or in parallel.
 
@@ -3695,7 +3695,7 @@ Type: `flag`
 
 Options to configure the default parameters used for ingesting data, in commands such as `ipfs add` or `ipfs block put`. All affected commands are detailed per option.
 
-These options implement [IPIP-499: UnixFS CID Profiles](https://github.com/ipfs/specs/pull/499) for reproducible CID generation across IPFS implementations. Instead of configuring individual options, you can apply a predefined profile with `ipfs config profile apply <profile-name>`. See [Profiles](#profiles) for available options like `unixfs-v1-2025`.
+These options implement [IPIP-499: UnixFS CID Profiles](https://specs.ipfs.tech/ipips/ipip-0499/) for reproducible CID generation across IPFS implementations. Instead of configuring individual options, you can apply a predefined profile with `ipfs config profile apply <profile-name>`. See [Profiles](#profiles) for available options like `unixfs-v1-2025`.
 
 Note that using CLI flags will override the options defined here.
 
@@ -3902,7 +3902,7 @@ Accepted values:
 
 The `block` estimation is recommended for new profiles as it provides more
 accurate threshold decisions and better cross-implementation consistency.
-See [IPIP-499](https://github.com/ipfs/specs/pull/499) for more details.
+See [IPIP-499](https://specs.ipfs.tech/ipips/ipip-0499/) for more details.
 
 Commands affected: `ipfs add`
 
@@ -4147,7 +4147,7 @@ See <https://github.com/ipfs/kubo/blob/master/config/profile.go> for exact [`Imp
 > [!NOTE]
 > Use only when legacy CIDs are required. For new projects, use [`unixfs-v1-2025`](#unixfs-v1-2025-profile).
 >
-> See [IPIP-499](https://github.com/ipfs/specs/pull/499) for more details.
+> See [IPIP-499](https://specs.ipfs.tech/ipips/ipip-0499/) for more details.
 
 ### `legacy-cid-v0` profile
 
@@ -4164,7 +4164,7 @@ See <https://github.com/ipfs/kubo/blob/master/config/profile.go> for exact [`Imp
 > [!NOTE]
 > This profile ensures CID consistency across different IPFS implementations.
 >
-> See [IPIP-499](https://github.com/ipfs/specs/pull/499) for more details.
+> See [IPIP-499](https://specs.ipfs.tech/ipips/ipip-0499/) for more details.
 
 ## Security
 

docs/content-blocking.md

@@ -6,7 +6,7 @@
   <br>
 </h1>
 
-Kubo ships with built-in support for denylist format from [IPIP-383](https://github.com/ipfs/specs/pull/383).
+Kubo ships with built-in support for denylist format from [IPIP-383](https://specs.ipfs.tech/ipips/ipip-0383/).
 
 ## Default behavior
 
@@ -41,7 +41,7 @@ caused the request to be blocked.
 
 ## Denylist file format
 
-[NOpfs](https://github.com/ipfs-shipyard/nopfs) supports the format from [IPIP-383](https://github.com/ipfs/specs/pull/383).
+[NOpfs](https://github.com/ipfs-shipyard/nopfs) supports the format from [IPIP-383](https://specs.ipfs.tech/ipips/ipip-0383/).
 
 Clear-text rules are simple: just put content paths to block, one per line.
 Paths with unicode and whitespace need to be percent-encoded:
@@ -54,7 +54,7 @@ Paths with unicode and whitespace need to be percent-encoded:
 Sensitive content paths can be double-hashed to block without revealing them.
 Double-hashed list example: https://badbits.dwebops.pub/badbits.deny
 
-See [IPIP-383](https://github.com/ipfs/specs/pull/383) for detailed format specification and more examples.
+See [IPIP-383](https://specs.ipfs.tech/ipips/ipip-0383/) for detailed format specification and more examples.
 
 ## How to suspend blocking without removing denylists
 

docs/experimental-features.md

@@ -599,7 +599,7 @@ ipfs config --json Experimental.GatewayOverLibp2p true
 - [ ] Needs more people to use and report on how well it works
 - [ ] Needs UX work for exposing non-recursive "HTTP transport" (NoFetch) over both libp2p and plain TCP (and sharing the configuration)
 - [ ] Needs a mechanism for HTTP handler to signal supported features ([IPIP-425](https://github.com/ipfs/specs/pull/425))
-- [ ] Needs an option for Kubo to detect peers that have it enabled and prefer HTTP transport before falling back to bitswap (and use CAR if peer supports dag-scope=entity from [IPIP-402](https://github.com/ipfs/specs/pull/402))
+- [ ] Needs an option for Kubo to detect peers that have it enabled and prefer HTTP transport before falling back to bitswap (and use CAR if peer supports dag-scope=entity from [IPIP-402](https://specs.ipfs.tech/ipips/ipip-0402/))
 
 ## Accelerated DHT Client