chore(docs): add TF API references and examples (#8283)

Author: itsyaasir

docs/content/developer/iota-hierarchies/getting-started/wasm.mdx

@@ -87,3 +87,12 @@ export async function createFederation(): Promise<void> {
 </Tabs>
 
 See [utils](https://github.com/iotaledger/hierarchies/tree/v0.1/bindings/wasm/hierarchies_wasm/examples/src/util.ts) for details about the implementations about the helper functions used here.
+
+
+## API Reference
+
+For complete API documentation, see the [WASM API Reference](../references/wasm/api_ref.md).
+
+## Examples
+
+You can find more usage examples and tutorials in the [hierarchies examples repository](https://github.com/iotaledger/hierarchies/tree/v0.1/bindings/wasm/hierarchies_wasm/examples).

docs/content/developer/iota-hierarchies/index.mdx

@@ -9,7 +9,7 @@ tags:
 
 # Hierarchies
 
-![Hierarchies](/img/banner/banner_hierarchies.svg)
+![Hierarchies](/img/banner/banner_hierarchies.png)
 
 ## Introduction
 

docs/content/developer/iota-identity/explanations/decentralized-identifiers.mdx

@@ -28,7 +28,7 @@ while facilitating encrypted communication.
 A DID is a unique identifier that can be resolved to a DID Document. This document contains data such as public keys, enabling the holder to prove ownership over their personal data, but also URIs that link to public information about the identity. DIDs are the fundamental building blocks of decentralized digital identity.
 This implementation complies with the [DID specifications v1.0](https://www.w3.org/TR/did-core//) from the World Wide Web Consortium (W3C).
 
-In the IOTA Identity framework, we have implemented the DID standard according to the `iota` [DID Method Specification](../references/iota-did-method-spec.mdx). Other implementations of DID on IOTA must follow the `iota` DID Method Specification if they want to use the `iota` method name. Libraries implementing the `iota` DID Method Specification are provided for [Rust](../getting-started/rust.mdx) and [WASM](../getting-started/wasm.mdx).
+In the IOTA Identity library, we have implemented the DID standard according to the `iota` [DID Method Specification](../references/iota-did-method-spec.mdx). Other implementations of DID on IOTA must follow the `iota` DID Method Specification if they want to use the `iota` method name. Libraries implementing the `iota` DID Method Specification are provided for [Rust](../getting-started/rust.mdx) and [WASM](../getting-started/wasm.mdx).
 
 ## Decentralized Identifiers
 
@@ -113,8 +113,8 @@ while making the data much more trustworthy as it has become verifiable.
 
 ## Why Use IOTA Identity Over Other Implementations?
 
-IOTA Identity is a framework to implement Self-Sovereign Identities on IOTA.
-Inherently, IOTA provides some unique features that have a major impact on the usability of the framework.
+IOTA Identity is a library to implement Self-Sovereign Identities on IOTA.
+Inherently, IOTA provides some unique features that have a major impact on the usability of the solution.
 
 ### Availability and Accessibility
 

docs/content/developer/iota-identity/explanations/verifiable-credentials.mdx

@@ -15,7 +15,7 @@ tags:
 Verifiable credentials (VCs) are digital statements that can be cryptographically proven, like a digital passport,
 and are used within systems to assert certain properties or capabilities of an entity.
 
-In the IOTA Identity framework, this is managed with decentralized identifiers (DIDs) on the IOTA network.
+In IOTA Identity, this is managed with decentralized identifiers (DIDs) on the IOTA network.
 Subjects and issuers use their DIDs for the creation and verification of credentials.
 
 :::
@@ -56,7 +56,7 @@ See the [Verifiable Credentials Data Model 1.0 Specification](https://w3c.github
 
 ## Verifiable Credentials in IOTA
 
-In the IOTA Identity framework, instead of a physical passport being given to Alice and its information written
+In IOTA Identity, instead of a physical passport being given to Alice and its information written
 into a centralized database owned by the government, Alice receives a digital verifiable credential,
 and the information required for verification in the future is written to the network.
 

docs/content/developer/iota-identity/getting-started/universal-resolver.mdx

@@ -14,7 +14,7 @@ tags:
 
 # Universal Resolver for IOTA DIDs
 
-The IOTA Identity framework includes a Universal Resolver driver that supports the `did:iota` method. This driver is part of the [Universal Resolver](https://github.com/decentralized-identity/universal-resolver/) infrastructure, which provides a unified interface for resolving DIDs across different methods.
+IOTA Identity includes a Universal Resolver driver that supports the `did:iota` method. This driver is part of the [Universal Resolver](https://github.com/decentralized-identity/universal-resolver/) infrastructure, which provides a unified interface for resolving DIDs across different methods.
 
 ## Example DIDs
 

docs/content/developer/iota-identity/getting-started/wasm.mdx

@@ -32,7 +32,7 @@ npm install @iota/identity-wasm@beta
 
 ## Build the Library
 
-Alternatively, you can build the bindings to work with currently unreleased features. You can find instructions for this in the [`identity.rs` repository](https://github.com/iotaledger/identity.rs/blob/v1.6.0-beta/bindings/wasm/identity_wasm#build).
+Alternatively, you can build the bindings to work with currently unreleased features. You can find instructions for this in the [`identity.rs` repository](https://github.com/iotaledger/identity.rs/tree/v1.6.0-beta/bindings/wasm/identity_wasm#build).
 
 ## Usage in Node.js and Web
 
@@ -58,7 +58,7 @@ import { ... } from '@iota/identity/web';
 
 
 ```ts reference
-https://github.com/iotaledger/identity.rs/blob/v1.6.0-beta/bindings/wasm/identity_wasm/examples/src/0_basic/0_create_did.ts
+https://github.com/iotaledger/identity.rs/tree/v1.6.0-beta/bindings/wasm/identity_wasm/examples/src/0_basic/0_create_did.ts
 ```
 
 </TabItem>
@@ -101,7 +101,7 @@ export async function createIdentity(): Promise<void> {
 </TabItem>
 </Tabs>
 
-See [utils](https://github.com/iotaledger/identity.rs/blob/v1.6.0-beta/bindings/wasm/identity_wasm/examples/src/util.ts) for details about the implementations about the helper functions used here.
+See [utils](https://github.com/iotaledger/identity.rs/tree/v1.6.0-beta/bindings/wasm/identity_wasm/examples/src/util.ts) for details about the implementations about the helper functions used here.
 
 ### Expected Output
 
@@ -274,6 +274,10 @@ because of that **it will only be slow for the first time**.
 
 */}
 
-## [API Reference](../references/wasm/api_ref.md)
+## API Reference
 
-## [Examples](https://github.com/iotaledger/identity.rs/blob/v1.6.0-beta/bindings/wasm/identity_wasm/examples/README.md)
+For complete API documentation, see the [WASM API Reference](../references/wasm/api_ref.md).
+
+## Examples
+
+You can find more usage examples and tutorials in the [identity examples repository](https://github.com/iotaledger/identity.rs/tree/v1.6.0-beta/bindings/wasm/identity_wasm/examples/README.md).

docs/content/developer/iota-identity/how-tos/decentralized-identifiers/create.mdx

@@ -18,7 +18,7 @@ This identity consists of many parts that have different functions.
 
 :::note DID method Specification
 
-Note that the IOTA Identity Framework follows [IOTA DID Method Specification](../../references/iota-did-method-spec.mdx).
+Note that the IOTA Identity library follows [IOTA DID Method Specification](../../references/iota-did-method-spec.mdx).
 
 :::
 

docs/content/developer/iota-identity/how-tos/decentralized-identifiers/resolve.mdx

@@ -13,13 +13,13 @@ tags:
 
 
 DID resolution is the process of fetching and decoding a [DID Document](https://www.w3.org/TR/did-core/#dfn-did-documents) corresponding to a given [DID](https://www.w3.org/TR/did-core/#dfn-decentralized-identifiers).
-The [IOTA Identity framework](https://github.com/iotaledger/identity.rs) supports resolving DID Documents that are
+The [IOTA Identity library](https://github.com/iotaledger/identity.rs) supports resolving DID Documents that are
 stored on an IOTA network and enables users to plug in handlers for additional methods.
 
 This is similar to, but not to be confused with,
 the [W3C DID Resolution specification](https://w3c-ccg.github.io/did-resolution/),
 which defines function signatures for resolution in the context of web or REST APIs,
-whereas the IOTA Identity framework provides strongly-typed resolution for a better developer experience.
+whereas the IOTA Identity library provides strongly-typed resolution for a better developer experience.
 
 This functionality is primarily provided by the `Resolver`, which can:
 

docs/content/developer/iota-identity/how-tos/decentralized-identifiers/update.mdx

@@ -19,16 +19,16 @@ while a service can provide metadata around the identity via URIs.
 
 ## Verification Methods
 
-As demonstrated by the [example](#full-example-code) below, the IOTA Identity framework offers easy-to-use methods for adding
+As demonstrated by the [example](#full-example-code) below, the IOTA Identity library offers easy-to-use methods for adding
 [verification methods](https://www.w3.org/TR/did-core/#verification-methods).
 
 ### Properties
 
 You can specify the following properties for a verification method:
 
 -   **id**: A [DID URL](https://www.w3.org/TR/did-core/#did-url-syntax) for the verification method. You can specify it by setting the [fragment](https://www.w3.org/TR/did-core/#fragment).
--   **type**: Specifies the type of the verification method. The framework supports `Ed25519` and `X25519` key types. This property is automatically filled by the framework when specifying the verification material.
--   **publicKeyMultibase**: A multi-base encoded public key which concludes the [verification material](https://www.w3.org/TR/did-core/#verification-material). This can be automatically generated by the framework or manually provided by users.
+-   **type**: Specifies the type of the verification method. The library supports `Ed25519` and `X25519` key types. This property is automatically filled by the library when specifying the verification material.
+-   **publicKeyMultibase**: A multi-base encoded public key which concludes the [verification material](https://www.w3.org/TR/did-core/#verification-material). This can be automatically generated by the library or manually provided by users.
 
 ## Verification Relationships
 
@@ -37,7 +37,7 @@ You can use it to specify the purpose of the verification method.
 
 ### Relationships
 
-The Identity Framework supports the following relationships:
+The Identity Library supports the following relationships:
 
 -   **[Authentication](https://www.w3.org/TR/did-core/#authentication)**: Used to specify authentication methods for the DID subject.
 -   **[Assertion](https://www.w3.org/TR/did-core/#assertion)**: Used to verify verifiable credentials.
@@ -47,7 +47,7 @@ The Identity Framework supports the following relationships:
 
 Verification methods can be either [embedded or referenced](https://www.w3.org/TR/did-core/#referring-to-verification-methods). Referencing verification
 methods allows them to be used by more than one verification relationship.
-When you create a verification method using the Identity Framework, specifying the `MethodScope` option will result in an embedded verification method.
+When you create a verification method using the Identity library, specifying the `MethodScope` option will result in an embedded verification method.
 Leaving that option unset will create the verification method as a map entry of the `verificationMethod` property.
 You can also add verification relationships afterward using references.
 
@@ -70,7 +70,7 @@ like authentication, communicating, and discovery.
 You can specify the following properties for a service:
 
 -   **id**: A [DID URL](https://www.w3.org/TR/did-core/#did-url-syntax) for referencing the service in the DID document. You can specify it by setting the [fragment](https://www.w3.org/TR/did-core/#fragment).
--   **type**: A string used to maximize interoperability between services. The framework does not perform any checks on the content of this string.
+-   **type**: A string used to maximize interoperability between services. The library does not perform any checks on the content of this string.
 -   **serviceEndpoint**: A URL that points to the service endpoint.
 
 ## Create Identity

docs/content/developer/iota-identity/how-tos/key-storage.mdx

@@ -97,7 +97,7 @@ However, the recommended default used by IOTA Identity is the `EdDSA` algorithm
 
 ## Implementation
 
-The IOTA Identity library ships two implementations of key storage.
+IOTA Identity ships two implementations of key storage.
 The `JwkMemStore` and `KeyIdMemstore` are insecure in-memory implementations
 intended as example implementations and for testing.