Fix TIP links

Author: Dr-Electron

docs/build/identity.rs/1.3/docs/how-tos/verifiable-credentials/zero-knowledge-selective-disclosure.mdx

@@ -13,45 +13,53 @@ import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
 # Zero Knowledge Selective Disclosure (ZK-SD-VCs)
+
 ZK-SD-VCs allow holders to verify their VCs without having to disclose the entire VC's claim set to verifiers. 
 This is done through the creation of a Zero Knowledge Proof (ZKP) that guarantees the integrity and authenticity
 of the VC, even when only partially disclosed to the verifier.
 
 :::note
+
 Although ZK-SD-VCs offer similar functionalities to [SD-JWT VCs](../selective-disclosure) - at least on a high level - they rely on completely different
 concepts and security concerns. For a user, the most notable difference is the shifted capability of choosing which fields can
 be concealed from a verifier. For ZK-SD-VCs it's the holder that has total control over which parts of the credential can be 
 undisclosed, whereas for SD-JWT VCs it's the issuer that decides which fields may be concealed by the holder.
+
 :::
 
 ## Concepts
+
 ### Issuance
+
 The issuer of a ZK-SD-VC creates the credential, signs it using the [BBS+](https://www.ietf.org/archive/id/draft-irtf-cfrg-bbs-signatures-05.html) signature scheme
 and sends both the credential and the signature to the holder. To facilitate this process, the credential is first encoded 
 as a [JSON Proof Token](https://www.ietf.org/archive/id/draft-ietf-jose-json-proof-token-02.html) (JPT), which is then used as the payload of a 
 [JSON Web Proof](https://www.ietf.org/archive/id/draft-ietf-jose-json-web-proof-02.html) (JWP) and sent to the holder as JPT. 
+
 :::note
+
 JWPs and JPTs can be reasoned about as the Zero Knowledge (ZK) based counterparts of JWSs and JWTs.
+
 :::
+
 In code, this process would look like the following snippet:
 <Tabs groupId="language" queryString>
 <TabItem value="rust" label="Rust">
 
 ```rust reference
-https://github.com/iotaledger/identity.rs/blob/v1.3.0/examples/1_advanced/9_zkp.rs#L114-L141
+https://github.com/iotaledger/identity.rs/blob/v1.4.0/examples/1_advanced/9_zkp.rs#L114-L141
 ```
 
 </TabItem>
 <TabItem value="typescript-node" label="Typescript (Node.js)">
 
 ```ts reference
-https://github.com/iotaledger/identity.rs/blob/v1.3.0/bindings/wasm/examples/src/1_advanced/8_zkp.ts#L109-L133
+https://github.com/iotaledger/identity.rs/blob/v1.4.0/bindings/wasm/examples/src/1_advanced/8_zkp.ts#L109-L133
 ```
 
 </TabItem>
 </Tabs>
 
-
 Note how the VC issuer makes no prescription whatsoever regarding the disclosability of the VC's fields.
 
 ### Holder presentation
@@ -62,18 +70,17 @@ to conceal any fields from the credentials claims through the creation of a Zero
 The proof value depends on the selected [JSON Proof Algorithm](https://www.ietf.org/archive/id/draft-ietf-jose-json-proof-algorithms-02.html) (JPA).
 
 <Tabs groupId="language" queryString>
-
 <TabItem value="rust" label="Rust">
 
 ```rust reference
-https://github.com/iotaledger/identity.rs/blob/v1.3.0/examples/1_advanced/9_zkp.rs#L197-L223
+https://github.com/iotaledger/identity.rs/blob/v1.4.0/examples/1_advanced/9_zkp.rs#L197-L223
 ```
 
 </TabItem>
 <TabItem value="typescript-node" label="Typescript (Node.js)">
 
 ```ts reference
-https://github.com/iotaledger/identity.rs/blob/v1.3.0/bindings/wasm/examples/src/1_advanced/8_zkp.ts#L178-L199
+https://github.com/iotaledger/identity.rs/blob/v1.4.0/bindings/wasm/examples/src/1_advanced/8_zkp.ts#L178-L199
 ```
 
 </TabItem>
@@ -114,18 +121,17 @@ The verifier decodes the received JPT presentation and asserts the validity of t
 authenticity and integrity of the presented credential, without knowledge of any of the undisclosed fields and of the issuer signature.
 
 <Tabs groupId="language" queryString>
-
 <TabItem value="rust" label="Rust">
 
 ```rust reference
-https://github.com/iotaledger/identity.rs/blob/v1.3.0/examples/1_advanced/9_zkp.rs#L244-L257
+https://github.com/iotaledger/identity.rs/blob/v1.4.0/examples/1_advanced/9_zkp.rs#L244-L257
 ```
 
 </TabItem>
 <TabItem value="typescript-node" label="Typescript (Node.js)">
 
 ```ts reference
-https://github.com/iotaledger/identity.rs/blob/v1.3.0/bindings/wasm/examples/src/1_advanced/8_zkp.ts#L217-L225
+https://github.com/iotaledger/identity.rs/blob/v1.4.0/bindings/wasm/examples/src/1_advanced/8_zkp.ts#L217-L225
 ```
 
 </TabItem>
@@ -137,14 +143,14 @@ https://github.com/iotaledger/identity.rs/blob/v1.3.0/bindings/wasm/examples/src
 <TabItem value="rust" label="Rust">
 
 ```rust reference
-https://github.com/iotaledger/identity.rs/blob/v1.3.0/examples/1_advanced/9_zkp.rs
+https://github.com/iotaledger/identity.rs/blob/v1.4.0/examples/1_advanced/9_zkp.rs
 ```
 
 </TabItem>
 <TabItem value="typescript-node" label="Typescript (Node.js)">
 
 ```ts reference
-https://github.com/iotaledger/identity.rs/blob/v1.3.0/bindings/wasm/examples/src/1_advanced/8_zkp.ts
+https://github.com/iotaledger/identity.rs/blob/v1.4.0/bindings/wasm/examples/src/1_advanced/8_zkp.ts
 ```
 
 </TabItem>

docs/build/identity.rs/1.3/docs/references/specifications/iota-did-method-spec.mdx

@@ -22,7 +22,7 @@ The IOTA DID Method Specification describes a method of implementing the [Decent
 
 ## Data Types & Subschema Notation
 
-Data types and subschemas used throughout this TIP are defined in [TIP-21](https://github.com/iotaledger/tips/blob/v1.2.0/tips/TIP-0021/tip-0021.md).
+Data types and subschemas used throughout this TIP are defined in [TIP-21](https://github.com/iotaledger/tips/blob/main/tips/TIP-0021/tip-0021.md).
 
 ## Introduction
 
@@ -36,13 +36,13 @@ Data stored in an output and covered by the storage deposit will be stored in _a
 
 ### Alias Output
 
-The [Alias Output](https://github.com/iotaledger/tips/blob/v1.2.0/tips/TIP-0018/tip-0018.md#alias-output) is a specific implementation of the [UTXO state machine](https://github.com/iotaledger/tips/blob/v1.2.0/tips/TIP-0018/tip-0018.md#chain-constraint-in-utxo). Some of its relevant properties are:
+The [Alias Output](https://github.com/iotaledger/tips/blob/main/tips/TIP-0018/tip-0018.md#alias-output) is a specific implementation of the [UTXO state machine](https://github.com/iotaledger/tips/blob/main/tips/TIP-0018/tip-0018.md#chain-constraint-in-utxo). Some of its relevant properties are:
 
 - **Amount**: the amount of IOTA coins held by the output.
 - **Alias ID**: 32 byte array, a unique identifier of the alias, which is the BLAKE2b-256 hash
   of the Output ID that created it.
 - **State Index**: A counter that must increase by 1 every time the alias is state transitioned.
-- **State Metadata**: Dynamically sized array of arbitrary bytes with a length up to `Max Metadata Length`, as defined in [TIP-22](https://github.com/iotaledger/tips/blob/v1.2.0/tips/TIP-0022/tip-0022.md). Can only be changed by the state controller.
+- **State Metadata**: Dynamically sized array of arbitrary bytes with a length up to `Max Metadata Length`, as defined in [TIP-22](https://github.com/iotaledger/tips/blob/main/tips/TIP-0022/tip-0022.md). Can only be changed by the state controller.
 - **Unlock Conditions**:
   - State Controller Address Unlock Condition
   - Governor Address Unlock Condition

docs/build/identity.rs/1.3/docs/references/specifications/revocation-bitmap-2022.mdx

@@ -175,7 +175,7 @@ This section describes the rationale behind some of the design decisions of this
 
 ### Compression and maximum size
 
-Considering that messages published to the Tangle cannot exceed [32 KiB](https://github.com/iotaledger/tips/blob/v1.2.0/tips/TIP-0006/tip-0006.md#message-validation) in size, and that larger messages have increased requirements, the use of compression was assessed.
+Considering that messages published to the Tangle cannot exceed [32 KiB](https://github.com/iotaledger/tips/blob/main/tips/TIP-0006/tip-0006.md#message-validation) in size, and that larger messages have increased requirements, the use of compression was assessed.
 The precise size of a serialized bitmap varies based on the number and distribution of revoked indices. When indices are revoked uniformly randomly, roughly 100,000 - 200,000 can be achieved in a DID Document with compression, and significantly more if consecutive indices are revoked.
 
 ZLIB [[RFC 1950](https://datatracker.ietf.org/doc/html/rfc1950)] was chosen for having a free and open source software licence and being one of the most widely used compression schemes, which enhances the accessibility of this specification. Some other assessed algorithms produced only marginally better compression ratios but had far fewer existing implementations across different programming languages.

docs/build/identity.rs/1.4/docs/references/specifications/iota-did-method-spec.mdx

@@ -22,7 +22,7 @@ The IOTA DID Method Specification describes a method of implementing the [Decent
 
 ## Data Types & Subschema Notation
 
-Data types and subschemas used throughout this TIP are defined in [TIP-21](https://github.com/iotaledger/tips/blob/v1.2.0/tips/TIP-0021/tip-0021.md).
+Data types and subschemas used throughout this TIP are defined in [TIP-21](https://github.com/iotaledger/tips/blob/main/tips/TIP-0021/tip-0021.md).
 
 ## Introduction
 
@@ -36,13 +36,13 @@ Data stored in an output and covered by the storage deposit will be stored in _a
 
 ### Alias Output
 
-The [Alias Output](https://github.com/iotaledger/tips/blob/v1.2.0/tips/TIP-0018/tip-0018.md#alias-output) is a specific implementation of the [UTXO state machine](https://github.com/iotaledger/tips/blob/v1.2.0/tips/TIP-0018/tip-0018.md#chain-constraint-in-utxo). Some of its relevant properties are:
+The [Alias Output](https://github.com/iotaledger/tips/blob/main/tips/TIP-0018/tip-0018.md#alias-output) is a specific implementation of the [UTXO state machine](https://github.com/iotaledger/tips/blob/main/tips/TIP-0018/tip-0018.md#chain-constraint-in-utxo). Some of its relevant properties are:
 
 - **Amount**: the amount of IOTA coins held by the output.
 - **Alias ID**: 32 byte array, a unique identifier of the alias, which is the BLAKE2b-256 hash
   of the Output ID that created it.
 - **State Index**: A counter that must increase by 1 every time the alias is state transitioned.
-- **State Metadata**: Dynamically sized array of arbitrary bytes with a length up to `Max Metadata Length`, as defined in [TIP-22](https://github.com/iotaledger/tips/blob/v1.2.0/tips/TIP-0022/tip-0022.md). Can only be changed by the state controller.
+- **State Metadata**: Dynamically sized array of arbitrary bytes with a length up to `Max Metadata Length`, as defined in [TIP-22](https://github.com/iotaledger/tips/blob/main/tips/TIP-0022/tip-0022.md). Can only be changed by the state controller.
 - **Unlock Conditions**:
   - State Controller Address Unlock Condition
   - Governor Address Unlock Condition

docs/build/identity.rs/1.4/docs/references/specifications/revocation-bitmap-2022.mdx

@@ -175,7 +175,7 @@ This section describes the rationale behind some of the design decisions of this
 
 ### Compression and maximum size
 
-Considering that messages published to the Tangle cannot exceed [32 KiB](https://github.com/iotaledger/tips/blob/v1.2.0/tips/TIP-0006/tip-0006.md#message-validation) in size, and that larger messages have increased requirements, the use of compression was assessed.
+Considering that messages published to the Tangle cannot exceed [32 KiB](https://github.com/iotaledger/tips/blob/main/tips/TIP-0006/tip-0006.md#message-validation) in size, and that larger messages have increased requirements, the use of compression was assessed.
 The precise size of a serialized bitmap varies based on the number and distribution of revoked indices. When indices are revoked uniformly randomly, roughly 100,000 - 200,000 can be achieved in a DID Document with compression, and significantly more if consecutive indices are revoked.
 
 ZLIB [[RFC 1950](https://datatracker.ietf.org/doc/html/rfc1950)] was chosen for having a free and open source software licence and being one of the most widely used compression schemes, which enhances the accessibility of this specification. Some other assessed algorithms produced only marginally better compression ratios but had far fewer existing implementations across different programming languages.