diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
index 1dac2f82fd1..89f171156a9 100644
--- a/.github/workflows/test.yml
+++ b/.github/workflows/test.yml
@@ -19,6 +19,10 @@ jobs:
uses: ./.github/actions/prepare/
- name: Lint Wiki
run: yarn lint:check
+ # - name: Build Cli
+ # run: yarn ./cli build
+ # - name: Lint IOTA Markdown
+ # run: yarn lint:md:check
- name: Format Wiki
run: yarn format:check
build:
diff --git a/.prettierignore b/.prettierignore
index dfe05fa4577..5054f9428b2 100644
--- a/.prettierignore
+++ b/.prettierignore
@@ -1,6 +1,10 @@
# Dependencies
/node_modules
+# Markdown files
+**/*.md
+**/*.mdx
+
# External documentation
/docs/external
diff --git a/cli/package.json b/cli/package.json
index fa646036319..b6819d3d94d 100644
--- a/cli/package.json
+++ b/cli/package.json
@@ -35,6 +35,7 @@
"ink-text-input": "^4.0.3",
"isomorphic-git": "^1.17.2",
"link-check": "^5.2.0",
+ "markdownlint-cli2": "^0.8.1",
"node-html-parser": "^6.1.10",
"prettier": "2.8.8",
"remark": "^14.0.2",
diff --git a/cli/src/commands/lint.tsx b/cli/src/commands/lint.tsx
new file mode 100644
index 00000000000..b3277c7a66c
--- /dev/null
+++ b/cli/src/commands/lint.tsx
@@ -0,0 +1,25 @@
+import { Command, Option } from 'clipanion';
+import { execute as shell } from '@yarnpkg/shell';
+
+const internalConfig = require.resolve(
+ '../markdownlint-cli2/default.markdownlint-cli2.cjs',
+);
+
+export class Lint extends Command {
+ static paths = [[`lint`]];
+ config = Option.String(`-c,--config`);
+ args = Option.Proxy();
+
+ async execute() {
+ return await shell(
+ 'npx markdownlint-cli2 --config ' + internalConfig + ' ',
+ this.args,
+ {
+ env: {
+ CUSTOM_CONFIG: this.config,
+ ...process.env,
+ },
+ },
+ );
+ }
+}
diff --git a/cli/src/index.tsx b/cli/src/index.tsx
index 055a46c2302..bd2db8f447e 100644
--- a/cli/src/index.tsx
+++ b/cli/src/index.tsx
@@ -5,6 +5,7 @@ import { Builtins, Cli } from 'clipanion';
import { Start } from './commands/start';
import { Build } from './commands/build';
import { Check } from './commands/check';
+import { Lint } from './commands/lint';
import { Setup } from './commands/tutorial/configure';
import { Default } from './commands/default';
@@ -21,6 +22,7 @@ cli.register(Builtins.VersionCommand);
cli.register(Start);
cli.register(Build);
cli.register(Check);
+cli.register(Lint);
cli.register(Setup);
cli.register(Default);
cli.runExit(args);
diff --git a/cli/src/markdownlint-cli2/default.markdownlint-cli2.cjs b/cli/src/markdownlint-cli2/default.markdownlint-cli2.cjs
new file mode 100644
index 00000000000..d8988e9ea83
--- /dev/null
+++ b/cli/src/markdownlint-cli2/default.markdownlint-cli2.cjs
@@ -0,0 +1,30 @@
+// @ts-check
+const _ = require('lodash');
+
+('use strict');
+
+const { env } = require('process');
+var custom_config = null;
+if (env.CUSTOM_CONFIG) {
+ custom_config = require(env.PWD + '/' + env.CUSTOM_CONFIG);
+}
+
+const default_config = {
+ config: {
+ MD007: {
+ indent: 2,
+ },
+ MD010: {
+ code_blocks: false,
+ },
+ MD013: false,
+ MD033: false,
+ MD034: false,
+ MD041: false,
+ },
+};
+
+const config = custom_config
+ ? _.defaultsDeep(custom_config, default_config)
+ : default_config;
+module.exports = config;
diff --git a/cli/test/markdownlint-cli2/custom.markdownlint-cli2.cjs b/cli/test/markdownlint-cli2/custom.markdownlint-cli2.cjs
new file mode 100644
index 00000000000..7da4455a302
--- /dev/null
+++ b/cli/test/markdownlint-cli2/custom.markdownlint-cli2.cjs
@@ -0,0 +1,10 @@
+module.exports = {
+ "fix": true,
+ "config": {
+ "MD003": {
+ "style": "atx"
+ },
+ // "MD032": true,
+ // "MD047": false,
+ }
+};
\ No newline at end of file
diff --git a/cli/test/markdownlint-cli2/markdown.md b/cli/test/markdownlint-cli2/markdown.md
new file mode 100644
index 00000000000..5fa90e634ba
--- /dev/null
+++ b/cli/test/markdownlint-cli2/markdown.md
@@ -0,0 +1,20 @@
+# tHis-iS-A-wEiRd-hEaDeR
+
+Something something
+
+# ATX style H1
+
+## Closed ATX style H2 ##
+
+Setext style H1
+===============
+
+* Item 1
++ Item 2
+- Item 3
+
+```
+$ ls
+$ cat foo
+$ less bar
+```
\ No newline at end of file
diff --git a/cli/test/tutorial/docs/tutorial-basics/markdown-features.mdx b/cli/test/tutorial/docs/tutorial-basics/markdown-features.mdx
index d994988fe46..5d8e8960aec 100644
--- a/cli/test/tutorial/docs/tutorial-basics/markdown-features.mdx
+++ b/cli/test/tutorial/docs/tutorial-basics/markdown-features.mdx
@@ -152,4 +152,4 @@ This is Facebook blue !
## AddToMetaMaskButton
-
\ No newline at end of file
+
diff --git a/docs/build/identity.rs/0.6/docs/concepts/decentralized_identifiers/resolve.mdx b/docs/build/identity.rs/0.6/docs/concepts/decentralized_identifiers/resolve.mdx
index a1633820faf..fe2809d8663 100644
--- a/docs/build/identity.rs/0.6/docs/concepts/decentralized_identifiers/resolve.mdx
+++ b/docs/build/identity.rs/0.6/docs/concepts/decentralized_identifiers/resolve.mdx
@@ -112,7 +112,7 @@ advanced use cases where more control is desired. To accommodate for such situat
- resolving all DID Documents of the distinct issuers of the credentials contained in the presentation
- resolving the issuer's DID Document for a given verifiable credential
-## Resolving the history of a DID Document.
+## Resolving the history of a DID Document
The fact that a DID Document [can be updated](./update.mdx) implies that the state of the DID Document can change over time, or in other words the result of resolving a DID
also depends on when this operation was carried out. The `Resolver` provides a way to view the entire history of a DID Document (up to the time when the method is called).
diff --git a/docs/build/identity.rs/0.6/docs/decentralized_identity.mdx b/docs/build/identity.rs/0.6/docs/decentralized_identity.mdx
index 23193fb2126..4bd0b50c958 100644
--- a/docs/build/identity.rs/0.6/docs/decentralized_identity.mdx
+++ b/docs/build/identity.rs/0.6/docs/decentralized_identity.mdx
@@ -77,7 +77,7 @@ There is a growth in applications that generate Digital Twins for physical devic
Security is a major barrier in advancing technologies that use IoT. Whether it is the smart devices in our own homes, or at a larger scale, the critical infrastructure of organizations and cities, security must be at the core. It is central to any globally-unifying identity solution. By integrating advanced research in cryptography and digital ledgers, and combining it with a scalable access and management system, security will become a core functionality of the systems we build. By using scalable device DIDs, integrating verification and reputation schemes, and allowing for transparent tamper-proof accountability, we begin to understand how we can future-proof the security of our systems, allowing us to start trusting the process, and not the patch.
-## One Framework. Any Identity.
+## One Framework. Any Identity
:::note Framework
diff --git a/docs/build/identity.rs/0.6/docs/libraries/wasm/api_reference.mdx b/docs/build/identity.rs/0.6/docs/libraries/wasm/api_reference.mdx
index 1add6775a29..af35c9b6787 100644
--- a/docs/build/identity.rs/0.6/docs/libraries/wasm/api_reference.mdx
+++ b/docs/build/identity.rs/0.6/docs/libraries/wasm/api_reference.mdx
@@ -4381,7 +4381,7 @@ The lack of an error returned from this method is in of itself not enough to con
trusted. This section contains more information on additional checks that should be carried out before and after
calling this method.
-#### The state of the supplied DID Documents.
+#### The state of the supplied DID Documents
The caller must ensure that the DID Documents in `holder` and `issuers` are up-to-date. The convenience methods
`Resolver::resolve_presentation_holder` and `Resolver::resolve_presentation_issuers`
diff --git a/docs/build/identity.rs/0.6/docs/libraries/wasm/getting_started.mdx b/docs/build/identity.rs/0.6/docs/libraries/wasm/getting_started.mdx
index d244184d421..6e8373c265e 100644
--- a/docs/build/identity.rs/0.6/docs/libraries/wasm/getting_started.mdx
+++ b/docs/build/identity.rs/0.6/docs/libraries/wasm/getting_started.mdx
@@ -23,7 +23,7 @@ keywords:
## [Low-Level Examples](https://github.com/iotaledger/identity.rs/blob/support/v0.6/bindings/wasm/examples/README.md)
-## Install the library:
+## Install the library
Latest Release: this version matches the main branch of this repository, is stable and will have changelogs.
@@ -116,7 +116,7 @@ The library loads the WASM file with an HTTP GET request, so the .wasm file must
- Install `rollup-plugin-copy`:
```bash
-$ npm install rollup-plugin-copy --save-dev
+npm install rollup-plugin-copy --save-dev
```
- Add the copy plugin usage to the `plugins` array under `rollup.config.js`:
@@ -142,7 +142,7 @@ copy({
- Install `copy-webpack-plugin`:
```bash
-$ npm install copy-webpack-plugin --save-dev
+npm install copy-webpack-plugin --save-dev
```
```js
diff --git a/docs/build/identity.rs/0.6/docs/specs/didcomm/overview.mdx b/docs/build/identity.rs/0.6/docs/specs/didcomm/overview.mdx
index a6b618b6458..404006fe824 100644
--- a/docs/build/identity.rs/0.6/docs/specs/didcomm/overview.mdx
+++ b/docs/build/identity.rs/0.6/docs/specs/didcomm/overview.mdx
@@ -28,7 +28,8 @@ The specification itself is technology agnostic. Much like the [DIDComm Messagin
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this specification are to be interpreted as described in
-[BCP 14](https://www.rfc-editor.org/info/bcp14)[[RFC 2119]](https://www.rfc-editor.org/rfc/rfc2119.txt).
+
+[BCP 14](https://www.rfc-editor.org/info/bcp14)[(RFC 2119)]](https://www.rfc-editor.org/rfc/rfc2119.txt).
## Versioning
diff --git a/docs/build/identity.rs/0.6/docs/specs/didcomm/protocols/connection.mdx b/docs/build/identity.rs/0.6/docs/specs/didcomm/protocols/connection.mdx
index ba6d556caae..11fc3499189 100644
--- a/docs/build/identity.rs/0.6/docs/specs/didcomm/protocols/connection.mdx
+++ b/docs/build/identity.rs/0.6/docs/specs/didcomm/protocols/connection.mdx
@@ -196,7 +196,7 @@ Following a successful connection, the [invitee](#roles) sends its public keys n
The `id` of the preceding [invitation](#invitation) message MUST be used as the `pthid` header property on this message. Both the `thid` and `pthid` properties MUST be omitted in the case of an implicit invitation when connecting to a public service endpoint of an [inviter](#roles). See [DIDComm Message Headers](https://identity.foundation/didcomm-messaging/spec/#message-headers) for more information.
-[^1] If present, the `recipientKey` sent by the [`invitee`](#roles) MUST match the key type (e.g. Ed25519, X25519) of one of the `recipientKeys` in the [invitation](#invitation) message, or of a `keyAgreement` public key attached to the [inviter`s](#roles) DID document in the case of an implicit invitation. The `recipientKey` should be omitted if no `recipientKeys` or `keyAgreement` sections are present, or if the [invitee](#roles) does not wish to use [anonymous encryption][anoncrypt] for the connection. An [inviter](#roles) may choose to reject connection messages that omit a `recipientKey`, terminating the connection.
+[^1] If present, the `recipientKey` sent by the [`invitee`](#roles) MUST match the key type (e.g. Ed25519, X25519) of one of the `recipientKeys` in the [invitation](#invitation) message, or of a `keyAgreement` public key attached to the [inviter's](#roles) DID document in the case of an implicit invitation. The `recipientKey` should be omitted if no `recipientKeys` or `keyAgreement` sections are present, or if the [invitee](#roles) does not wish to use [anonymous encryption][anoncrypt] for the connection. An [inviter](#roles) may choose to reject connection messages that omit a `recipientKey`, terminating the connection.
[^2] Similar to the considerations for the [invitation](#invitation) message, implementors should avoid using a `DIDUrl` for the `recipientKey` or `routingKeys` as it may reveal the identity of the [invitee](#roles) to eavesdroppers prior to encryption being established. Using a `DIDUrl` for key rotation is less of a concern for a [connection](#connection) message as, unlike an [invitation](#invitation), the message is intended to be transient and should not persist beyond a single connection attempt.
diff --git a/docs/build/identity.rs/0.6/docs/workflow.mdx b/docs/build/identity.rs/0.6/docs/workflow.mdx
index 99235c45a19..1952b19f7ad 100644
--- a/docs/build/identity.rs/0.6/docs/workflow.mdx
+++ b/docs/build/identity.rs/0.6/docs/workflow.mdx
@@ -16,7 +16,7 @@ In this article you will learn about the software development process for the IO
## Issues
-Issues are opened when a certain task or problem is noted but cannot immediately be fixed. Issues may contain bug reports, requests, or larger topics. Please use the correct GitHub issue template for your issue type. Only IOTA Foundation members should use the task templates flagged for maintainers. You should make sure to [label](#issue-Labels) the issue correctly. As a contributor, you may also add issues to a certain [project](https://github.com/iotaledger/identity.rs/projects/).
+Issues are opened when a certain task or problem is noted but cannot immediately be fixed. Issues may contain bug reports, requests, or larger topics. Please use the correct GitHub issue template for your issue type. Only IOTA Foundation members should use the task templates flagged for maintainers. You should make sure to [label](#issue-labels) the issue correctly. As a contributor, you may also add issues to a certain [project](https://github.com/iotaledger/identity.rs/projects/).
## Git
@@ -59,7 +59,7 @@ We recommend integrating `dev` or `epic` regularly, depending on where the branc
#### Epic (epic/)
-Long-lived `epic` branches should be created as soon as a feature is expected to require more than one PR. The `epic` branch should be branched from `dev` and should only accept merges that are related to the feature being developed. A PR should be opened as soon as the branch is created to publicly notify contributors about the development, the goals and requirements of the feature, and the existence of the branch. It is recommended you integrate `dev` often to reduce the possibility and potential size of merge conflicts. Epic branches must not be squash-merged, otherwise the [changelog generator](#Changelog) will not detect its constituent PRs.
+Long-lived `epic` branches should be created as soon as a feature is expected to require more than one PR. The `epic` branch should be branched from `dev` and should only accept merges that are related to the feature being developed. A PR should be opened as soon as the branch is created to publicly notify contributors about the development, the goals and requirements of the feature, and the existence of the branch. It is recommended you integrate `dev` often to reduce the possibility and potential size of merge conflicts. Epic branches must not be squash-merged, otherwise the [changelog generator](#changelog) will not detect its constituent PRs.
### Semantic Versioning
@@ -71,11 +71,11 @@ For more detailed information and an overview of advanced features, see [Semanti
### Changelog
-A changelog is a file describing a software project for humans to grasp the type and content of changes from version to version. Changelogs are closely related to the versioning of software, since individual changes are grouped into versions that are, in our case, referenced by a [SemVer string](#Semantic-Versioning). We generally follow the recommendations from [keepachangelog](https://keepachangelog.com/en/1.0.0/). The changelog in this project is generated from the titles and [labels](#PR-Labels) of [pull requests](#Pull-Requests).
+A changelog is a file describing a software project for humans to grasp the type and content of changes from version to version. Changelogs are closely related to the versioning of software, since individual changes are grouped into versions that are, in our case, referenced by a [SemVer string](#semantic-versioning). We generally follow the recommendations from [keepachangelog](https://keepachangelog.com/en/1.0.0/). The changelog in this project is generated from the titles and [labels](#pr-labels) of [pull requests](#pull-requests).
#### PR labels
-Labels are used to categorize changes in [pull requests](#Pull-Requests). Adding a label will include the labeled [PR](#Pull-Requests) title in the related section of the generated [changelog](#Changelog).
+Labels are used to categorize changes in [pull requests](#pull-requests). Adding a label will include the labeled [PR](#pull-requests) title in the related section of the generated [changelog](#changelog).
Changelogs are generated for the core Rust library and each binding separately. To attach a PR to a specific changelog, use the following labels:
@@ -91,17 +91,17 @@ It is also necessary to add an appropriate label for the type of change in the P
##### Changed
-Maps to the major version of [Semantic Versioning](#Semantic-Versioning).
+Maps to the major version of [Semantic Versioning](#semantic-versioning).
labels: `Breaking change`
##### Added
-Maps to the minor version of [Semantic Versioning](#Semantic-Versioning).
+Maps to the minor version of [Semantic Versioning](#semantic-versioning).
labels: `Added`
##### Patch
-Maps to the patch version of [Semantic Versioning](#Semantic-Versioning).
+Maps to the patch version of [Semantic Versioning](#semantic-versioning).
labels: `Patch`
##### Deprecated
@@ -111,7 +111,7 @@ labels: `Deprecated`
##### Removed
-Marks features as being removed. Typically the features should have been deprecated in the previous version. This maps to the major version of [Semantic Versioning](#Semantic-Versioning).
+Marks features as being removed. Typically the features should have been deprecated in the previous version. This maps to the major version of [Semantic Versioning](#semantic-versioning).
labels: `Removed`
##### Excluded tags
@@ -133,7 +133,7 @@ The following labels are used to categorize issues but do not have any effect on
With the release process, we can deliver versions of our software to the community. We use sensible automation where it helps to remove tedium. However, some steps that require active decision-making remain manual.
-The final list of changes from the [changelog](#Changelog) informs the version of the release. If at least one change mapping to a major version is included, the major version needs to be incremented. In that case, the minor and patch versions are set to `0`. If there are no changes related to a major version, but changes related to a minor version are present, the minor version needs to be incremented while the patch version is set to `0`. Otherwise, only the patch version is incremented. Determining the version of the release is the responsibility of the person performing the release.
+The final list of changes from the [changelog](#changelog) informs the version of the release. If at least one change mapping to a major version is included, the major version needs to be incremented. In that case, the minor and patch versions are set to `0`. If there are no changes related to a major version, but changes related to a minor version are present, the minor version needs to be incremented while the patch version is set to `0`. Otherwise, only the patch version is incremented. Determining the version of the release is the responsibility of the person performing the release.
The determined version of the release is used to create the [hotfix](#hotfix) or [release](#release) branch. For example, a major release from the previous version `v2.3.1` will create the `release/v3.0.0` branch.
@@ -149,9 +149,9 @@ You should follow these steps to create a release:
2.2. Determine the next version string.
2.3. Run the workflow. The workflow will create a PR from `dev` targeting `dev` with release related changes.
3. Review the PR.
- 3.1. The PR will update the changelog, check that it has all expected entries in the appropriate sections and the determined version matches the changelog according to [SemVer](#Semantic-Versioning).
+ 3.1. The PR will update the changelog, check that it has all expected entries in the appropriate sections and the determined version matches the changelog according to [SemVer](#semantic-versioning).
3.2. The PR will update project version strings, ensure these are correct and match the expected version.
- 3.3. Refer to [Troubleshooting](#Troubleshooting) if anything is incorrect.
+ 3.3. Refer to [Troubleshooting](#troubleshooting) if anything is incorrect.
4. Merge the PR.
4.1. On merging to `dev`, an automatic workflow is triggered that builds and publishes artifacts to the appropriate package manager (`crates.io` for Rust, `npm` for the WASM bindings), and creates a GitHub Release (only for `main` version releases of the core Rust library).
5. For `main` version releases, merge the `dev` branch into the `main` branch.
@@ -162,13 +162,13 @@ You should follow these steps to create a release:
Update the titles of the relevant PRs, then re-run the workflow with the same parameters. The release PR will be updated with the new changelog.
-#### The changelog in the release PR is missing entries, has unrelated entries, or entries in the wrong section.
+#### The changelog in the release PR is missing entries, has unrelated entries, or entries in the wrong section
-Fix the [labels](#PR-Labels) on the relevant PRs, then re-run the workflow with the same parameters. The release PR will be updated with the new changelog.
+Fix the [labels](#pr-labels) on the relevant PRs, then re-run the workflow with the same parameters. The release PR will be updated with the new changelog.
#### The release description in the release PR is missing or wrong
-Fix the issue description, milestone, and label according to the [release summaries guide](#Release-Summary) and re-run the workflow with the same parameters. The release PR will be updated with the new changelog.
+Fix the issue description, milestone, and label according to the [release summaries guide](#release-summary) and re-run the workflow with the same parameters. The release PR will be updated with the new changelog.
#### Features or code are missing from the release
diff --git a/docs/build/identity.rs/1.0-rc.1/docs/decentralized_identity.mdx b/docs/build/identity.rs/1.0-rc.1/docs/decentralized_identity.mdx
index 23193fb2126..4bd0b50c958 100644
--- a/docs/build/identity.rs/1.0-rc.1/docs/decentralized_identity.mdx
+++ b/docs/build/identity.rs/1.0-rc.1/docs/decentralized_identity.mdx
@@ -77,7 +77,7 @@ There is a growth in applications that generate Digital Twins for physical devic
Security is a major barrier in advancing technologies that use IoT. Whether it is the smart devices in our own homes, or at a larger scale, the critical infrastructure of organizations and cities, security must be at the core. It is central to any globally-unifying identity solution. By integrating advanced research in cryptography and digital ledgers, and combining it with a scalable access and management system, security will become a core functionality of the systems we build. By using scalable device DIDs, integrating verification and reputation schemes, and allowing for transparent tamper-proof accountability, we begin to understand how we can future-proof the security of our systems, allowing us to start trusting the process, and not the patch.
-## One Framework. Any Identity.
+## One Framework. Any Identity
:::note Framework
diff --git a/docs/build/identity.rs/1.0-rc.1/docs/libraries/wasm/api_reference.mdx b/docs/build/identity.rs/1.0-rc.1/docs/libraries/wasm/api_reference.mdx
index 549e293dea0..49759b579e5 100644
--- a/docs/build/identity.rs/1.0-rc.1/docs/libraries/wasm/api_reference.mdx
+++ b/docs/build/identity.rs/1.0-rc.1/docs/libraries/wasm/api_reference.mdx
@@ -1918,6 +1918,76 @@ Deserializes an instance from a JSON object.
| ----- | ---------------- |
| json | any |
+
+
+## DomainLinkageValidator
+
+A validator for a Domain Linkage Configuration and Credentials.
+
+**Kind**: global class
+
+- [DomainLinkageValidator](#DomainLinkageValidator)
+ - [new DomainLinkageValidator(signatureVerifier)](#new_DomainLinkageValidator_new)
+ - [.validateLinkage(issuer, configuration, domain, options)](#DomainLinkageValidator+validateLinkage)
+ - [.validateCredential(issuer, credentialJwt, domain, options)](#DomainLinkageValidator+validateCredential)
+
+
+
+### new DomainLinkageValidator(signatureVerifier)
+
+Creates a new `DomainLinkageValidator`. If a `signatureVerifier` is provided it will be used when
+verifying decoded JWS signatures, otherwise the default which is only capable of handling the `EdDSA`
+algorithm will be used.
+
+| Param | Type |
+| ----------------- | --------------------------------------------------- |
+| signatureVerifier | IJwsVerifier \| undefined |
+
+
+
+### domainLinkageValidator.validateLinkage(issuer, configuration, domain, options)
+
+Validates the linkage between a domain and a DID.
+[`DomainLinkageConfiguration`] is validated according to [DID Configuration Resource Verification](https://identity.foundation/.well-known/resources/did-configuration/#did-configuration-resource-verification).
+
+Linkage is valid if no error is thrown.
+
+# Note
+
+- Only the [JSON Web Token Proof Format](https://identity.foundation/.well-known/resources/did-configuration/#json-web-token-proof-format)
+- Only the Credential issued by `issuer` is verified.
+
+# Errors
+
+- Semantic structure of `configuration` is invalid.
+- `configuration` includes multiple credentials issued by `issuer`.
+- Validation of the matched Domain Linkage Credential fails.
+
+**Kind**: instance method of [DomainLinkageValidator](#DomainLinkageValidator)
+
+| Param | Type |
+| ------------- | ------------------------------------------------------------------------------ |
+| issuer | [CoreDocument](#CoreDocument) \| IToCoreDocument |
+| configuration | [DomainLinkageConfiguration](#DomainLinkageConfiguration) |
+| domain | string |
+| options | [JwtCredentialValidationOptions](#JwtCredentialValidationOptions) |
+
+
+
+### domainLinkageValidator.validateCredential(issuer, credentialJwt, domain, options)
+
+Validates a [Domain Linkage Credential](https://identity.foundation/.well-known/resources/did-configuration/#domain-linkage-credential).
+Error will be thrown in case the validation fails.
+
+**Kind**: instance method of [DomainLinkageValidator](#DomainLinkageValidator)
+
+| Param | Type |
+| ------------- | ------------------------------------------------------------------------------ |
+| issuer | [CoreDocument](#CoreDocument) \| IToCoreDocument |
+| credentialJwt | [Jwt](#Jwt) |
+| domain | string |
+| options | [JwtCredentialValidationOptions](#JwtCredentialValidationOptions) |
+
## Duration
@@ -4640,7 +4710,7 @@ Validation is done with respect to the properties set in `options`.
be trusted. This section contains more information on additional checks that should be carried out before and
after calling this method.
-## The state of the supplied DID Documents.
+## The state of the supplied DID Documents
The caller must ensure that the DID Documents in `holder` are up-to-date.
@@ -4674,7 +4744,7 @@ Validates the semantic structure of the [Presentation](#Presentation).
Attempt to extract the holder of the presentation.
-# Errors:
+# Errors
- If deserialization/decoding of the presentation fails.
- If the holder can't be parsed as DIDs.
diff --git a/docs/build/identity.rs/1.0-rc.1/docs/libraries/wasm/getting_started.mdx b/docs/build/identity.rs/1.0-rc.1/docs/libraries/wasm/getting_started.mdx
index 0cc1d6f7238..3eb11b831eb 100644
--- a/docs/build/identity.rs/1.0-rc.1/docs/libraries/wasm/getting_started.mdx
+++ b/docs/build/identity.rs/1.0-rc.1/docs/libraries/wasm/getting_started.mdx
@@ -21,7 +21,7 @@ keywords:
## [Examples](https://github.com/iotaledger/identity.rs/blob/main/bindings/wasm/examples/README.md)
-## Install the library:
+## Install the library
Latest Release: this version matches the `main` branch of this repository.
@@ -181,7 +181,7 @@ The library loads the WASM file with an HTTP GET request, so the .wasm file must
- Install `rollup-plugin-copy`:
```bash
-$ npm install rollup-plugin-copy --save-dev
+npm install rollup-plugin-copy --save-dev
```
- Add the copy plugin usage to the `plugins` array under `rollup.config.js`:
@@ -212,7 +212,7 @@ copy({
- Install `copy-webpack-plugin`:
```bash
-$ npm install copy-webpack-plugin --save-dev
+npm install copy-webpack-plugin --save-dev
```
```js
diff --git a/docs/build/identity.rs/1.0-rc.1/docs/workflow.mdx b/docs/build/identity.rs/1.0-rc.1/docs/workflow.mdx
index 99235c45a19..1952b19f7ad 100644
--- a/docs/build/identity.rs/1.0-rc.1/docs/workflow.mdx
+++ b/docs/build/identity.rs/1.0-rc.1/docs/workflow.mdx
@@ -16,7 +16,7 @@ In this article you will learn about the software development process for the IO
## Issues
-Issues are opened when a certain task or problem is noted but cannot immediately be fixed. Issues may contain bug reports, requests, or larger topics. Please use the correct GitHub issue template for your issue type. Only IOTA Foundation members should use the task templates flagged for maintainers. You should make sure to [label](#issue-Labels) the issue correctly. As a contributor, you may also add issues to a certain [project](https://github.com/iotaledger/identity.rs/projects/).
+Issues are opened when a certain task or problem is noted but cannot immediately be fixed. Issues may contain bug reports, requests, or larger topics. Please use the correct GitHub issue template for your issue type. Only IOTA Foundation members should use the task templates flagged for maintainers. You should make sure to [label](#issue-labels) the issue correctly. As a contributor, you may also add issues to a certain [project](https://github.com/iotaledger/identity.rs/projects/).
## Git
@@ -59,7 +59,7 @@ We recommend integrating `dev` or `epic` regularly, depending on where the branc
#### Epic (epic/)
-Long-lived `epic` branches should be created as soon as a feature is expected to require more than one PR. The `epic` branch should be branched from `dev` and should only accept merges that are related to the feature being developed. A PR should be opened as soon as the branch is created to publicly notify contributors about the development, the goals and requirements of the feature, and the existence of the branch. It is recommended you integrate `dev` often to reduce the possibility and potential size of merge conflicts. Epic branches must not be squash-merged, otherwise the [changelog generator](#Changelog) will not detect its constituent PRs.
+Long-lived `epic` branches should be created as soon as a feature is expected to require more than one PR. The `epic` branch should be branched from `dev` and should only accept merges that are related to the feature being developed. A PR should be opened as soon as the branch is created to publicly notify contributors about the development, the goals and requirements of the feature, and the existence of the branch. It is recommended you integrate `dev` often to reduce the possibility and potential size of merge conflicts. Epic branches must not be squash-merged, otherwise the [changelog generator](#changelog) will not detect its constituent PRs.
### Semantic Versioning
@@ -71,11 +71,11 @@ For more detailed information and an overview of advanced features, see [Semanti
### Changelog
-A changelog is a file describing a software project for humans to grasp the type and content of changes from version to version. Changelogs are closely related to the versioning of software, since individual changes are grouped into versions that are, in our case, referenced by a [SemVer string](#Semantic-Versioning). We generally follow the recommendations from [keepachangelog](https://keepachangelog.com/en/1.0.0/). The changelog in this project is generated from the titles and [labels](#PR-Labels) of [pull requests](#Pull-Requests).
+A changelog is a file describing a software project for humans to grasp the type and content of changes from version to version. Changelogs are closely related to the versioning of software, since individual changes are grouped into versions that are, in our case, referenced by a [SemVer string](#semantic-versioning). We generally follow the recommendations from [keepachangelog](https://keepachangelog.com/en/1.0.0/). The changelog in this project is generated from the titles and [labels](#pr-labels) of [pull requests](#pull-requests).
#### PR labels
-Labels are used to categorize changes in [pull requests](#Pull-Requests). Adding a label will include the labeled [PR](#Pull-Requests) title in the related section of the generated [changelog](#Changelog).
+Labels are used to categorize changes in [pull requests](#pull-requests). Adding a label will include the labeled [PR](#pull-requests) title in the related section of the generated [changelog](#changelog).
Changelogs are generated for the core Rust library and each binding separately. To attach a PR to a specific changelog, use the following labels:
@@ -91,17 +91,17 @@ It is also necessary to add an appropriate label for the type of change in the P
##### Changed
-Maps to the major version of [Semantic Versioning](#Semantic-Versioning).
+Maps to the major version of [Semantic Versioning](#semantic-versioning).
labels: `Breaking change`
##### Added
-Maps to the minor version of [Semantic Versioning](#Semantic-Versioning).
+Maps to the minor version of [Semantic Versioning](#semantic-versioning).
labels: `Added`
##### Patch
-Maps to the patch version of [Semantic Versioning](#Semantic-Versioning).
+Maps to the patch version of [Semantic Versioning](#semantic-versioning).
labels: `Patch`
##### Deprecated
@@ -111,7 +111,7 @@ labels: `Deprecated`
##### Removed
-Marks features as being removed. Typically the features should have been deprecated in the previous version. This maps to the major version of [Semantic Versioning](#Semantic-Versioning).
+Marks features as being removed. Typically the features should have been deprecated in the previous version. This maps to the major version of [Semantic Versioning](#semantic-versioning).
labels: `Removed`
##### Excluded tags
@@ -133,7 +133,7 @@ The following labels are used to categorize issues but do not have any effect on
With the release process, we can deliver versions of our software to the community. We use sensible automation where it helps to remove tedium. However, some steps that require active decision-making remain manual.
-The final list of changes from the [changelog](#Changelog) informs the version of the release. If at least one change mapping to a major version is included, the major version needs to be incremented. In that case, the minor and patch versions are set to `0`. If there are no changes related to a major version, but changes related to a minor version are present, the minor version needs to be incremented while the patch version is set to `0`. Otherwise, only the patch version is incremented. Determining the version of the release is the responsibility of the person performing the release.
+The final list of changes from the [changelog](#changelog) informs the version of the release. If at least one change mapping to a major version is included, the major version needs to be incremented. In that case, the minor and patch versions are set to `0`. If there are no changes related to a major version, but changes related to a minor version are present, the minor version needs to be incremented while the patch version is set to `0`. Otherwise, only the patch version is incremented. Determining the version of the release is the responsibility of the person performing the release.
The determined version of the release is used to create the [hotfix](#hotfix) or [release](#release) branch. For example, a major release from the previous version `v2.3.1` will create the `release/v3.0.0` branch.
@@ -149,9 +149,9 @@ You should follow these steps to create a release:
2.2. Determine the next version string.
2.3. Run the workflow. The workflow will create a PR from `dev` targeting `dev` with release related changes.
3. Review the PR.
- 3.1. The PR will update the changelog, check that it has all expected entries in the appropriate sections and the determined version matches the changelog according to [SemVer](#Semantic-Versioning).
+ 3.1. The PR will update the changelog, check that it has all expected entries in the appropriate sections and the determined version matches the changelog according to [SemVer](#semantic-versioning).
3.2. The PR will update project version strings, ensure these are correct and match the expected version.
- 3.3. Refer to [Troubleshooting](#Troubleshooting) if anything is incorrect.
+ 3.3. Refer to [Troubleshooting](#troubleshooting) if anything is incorrect.
4. Merge the PR.
4.1. On merging to `dev`, an automatic workflow is triggered that builds and publishes artifacts to the appropriate package manager (`crates.io` for Rust, `npm` for the WASM bindings), and creates a GitHub Release (only for `main` version releases of the core Rust library).
5. For `main` version releases, merge the `dev` branch into the `main` branch.
@@ -162,13 +162,13 @@ You should follow these steps to create a release:
Update the titles of the relevant PRs, then re-run the workflow with the same parameters. The release PR will be updated with the new changelog.
-#### The changelog in the release PR is missing entries, has unrelated entries, or entries in the wrong section.
+#### The changelog in the release PR is missing entries, has unrelated entries, or entries in the wrong section
-Fix the [labels](#PR-Labels) on the relevant PRs, then re-run the workflow with the same parameters. The release PR will be updated with the new changelog.
+Fix the [labels](#pr-labels) on the relevant PRs, then re-run the workflow with the same parameters. The release PR will be updated with the new changelog.
#### The release description in the release PR is missing or wrong
-Fix the issue description, milestone, and label according to the [release summaries guide](#Release-Summary) and re-run the workflow with the same parameters. The release PR will be updated with the new changelog.
+Fix the issue description, milestone, and label according to the [release summaries guide](#release-summary) and re-run the workflow with the same parameters. The release PR will be updated with the new changelog.
#### Features or code are missing from the release
diff --git a/docs/build/introduction-docs/chrysalis/docs/how_tos/migration/snapshot_validation_bootstrapping.md b/docs/build/introduction-docs/chrysalis/docs/how_tos/migration/snapshot_validation_bootstrapping.md
index 0734e519569..234263cc80b 100644
--- a/docs/build/introduction-docs/chrysalis/docs/how_tos/migration/snapshot_validation_bootstrapping.md
+++ b/docs/build/introduction-docs/chrysalis/docs/how_tos/migration/snapshot_validation_bootstrapping.md
@@ -60,7 +60,7 @@ Make sure you have Go installed by issuing `go version` on your command line.
```
6. Generate the sha256 hashes of the generated snapshot.
- files: `sha256sum genesis_snapshot.bin genesis_snapshot_alt.bin global_snapshot.csv `; Example output:
+ files: `sha256sum genesis_snapshot.bin genesis_snapshot_alt.bin global_snapshot.csv`; Example output:
```
$ sha256sum genesis_snapshot.bin genesis_snapshot_alt.bin global_snapshot.csv
diff --git a/docs/build/iota-sdk/1.0/docs/contribute.md b/docs/build/iota-sdk/1.0/docs/contribute.md
index 1db06121036..1ccdc05608c 100644
--- a/docs/build/iota-sdk/1.0/docs/contribute.md
+++ b/docs/build/iota-sdk/1.0/docs/contribute.md
@@ -43,7 +43,7 @@ the [contribution guidelines](https://github.com/iotaledger/documentation/blob/d
Helping others is a crucial aspect of any open source ecosystem. By sharing your knowledge with the community, you can
provide immense value and potentially inspire others to learn and contribute. Join the ongoing discussions in the
-#libraries channel on [Discord](https://discord.iota.org).
+`#libraries` channel on [Discord](https://discord.iota.org).
Your contributions play a vital role in shaping and improving the project. We appreciate your interest and look forward
to your valuable contributions!
diff --git a/docs/build/iota-sdk/1.0/docs/getting-started/nodejs.mdx b/docs/build/iota-sdk/1.0/docs/getting-started/nodejs.mdx
index 84f30438c6c..117e5f447cf 100644
--- a/docs/build/iota-sdk/1.0/docs/getting-started/nodejs.mdx
+++ b/docs/build/iota-sdk/1.0/docs/getting-started/nodejs.mdx
@@ -61,19 +61,19 @@ If you use [Chocolatey](https://chocolatey.org) you can install LLVM by executin
You can build the IOTA SDK from source by doing the following:
-1. Download the repository to any directory you choose:
+1. Download the repository to any directory you choose:
```shell
git clone https://github.com/iotaledger/iota-sdk
```
-2. Move to the Node.js binding directory:
+2. Move to the Node.js binding directory:
```shell
cd iota-sdk/bindings/nodejs
```
-3. Install the necessary dependencies with either of the following commands:
+3. Install the necessary dependencies with either of the following commands:
@@ -92,7 +92,7 @@ yarn install
-4. Build the SDK:
+4. Build the SDK:
diff --git a/docs/build/iota-sdk/1.0/docs/getting-started/python.mdx b/docs/build/iota-sdk/1.0/docs/getting-started/python.mdx
index d1f0e07a908..40173357ff7 100644
--- a/docs/build/iota-sdk/1.0/docs/getting-started/python.mdx
+++ b/docs/build/iota-sdk/1.0/docs/getting-started/python.mdx
@@ -45,7 +45,7 @@ pip install iota-sdk
cd iota-sdk/bindings/python
```
-2. (optional) You can run the following commands create a virtual environment and use it:
+2. (optional) You can run the following commands create a virtual environment and use it:
@@ -73,14 +73,14 @@ source iota_sdk_venv/bin/activate
-3. Install the required dependencies and build the wheel by running the following commands:
+3. Install the required dependencies and build the wheel by running the following commands:
```bash
pip install -r requirements-dev.txt
pip install .
```
-4. (optional) If you want to deactivate the virtual environment, run the following command:
+4. (optional) If you want to deactivate the virtual environment, run the following command:
```bash
deactivate
diff --git a/docs/build/iota.rs/1.4/docs/libraries/java/examples/_09_transaction.mdx b/docs/build/iota.rs/1.4/docs/libraries/java/examples/_09_transaction.mdx
index 3c0980e3048..39373a07c98 100644
--- a/docs/build/iota.rs/1.4/docs/libraries/java/examples/_09_transaction.mdx
+++ b/docs/build/iota.rs/1.4/docs/libraries/java/examples/_09_transaction.mdx
@@ -1,5 +1,5 @@
Sending value-based messages is a very straightforward process if you use the
-[`ClientMessageBuilder` ](./../api_reference.md#clientmessagebuilder) helper class. You will only need to
+[`ClientMessageBuilder`](./../api_reference.md#clientmessagebuilder) helper class. You will only need to
provide a valid seed by chaining a call to
[`.withSeed(seed: String)`](./../api_reference.md#withseedseed-clientmessagebuilder), and output addresses
and amount by chaining a call to
diff --git a/docs/build/iota.rs/1.4/docs/libraries/nodejs/api_reference.md b/docs/build/iota.rs/1.4/docs/libraries/nodejs/api_reference.md
index 4b67b1f1c0a..faccda711bb 100644
--- a/docs/build/iota.rs/1.4/docs/libraries/nodejs/api_reference.md
+++ b/docs/build/iota.rs/1.4/docs/libraries/nodejs/api_reference.md
@@ -18,13 +18,13 @@ Node.js binding to the IOTA client library.
- Using NPM:
```bash
-$ npm i @iota/client
+npm i @iota/client
```
- Using yarn:
```bash
-$ yarn add @iota/client
+yarn add @iota/client
```
## Requirements
@@ -480,13 +480,13 @@ Gets the utxo changes by the given milestone index.
| ----- | -------- | -------------------------- |
| index | `number` | The index of the milestone |
-**Returns** a promise resolving to the [MilestoneUTXOChanges](#MilestoneUTXOChanges).
+**Returns** a promise resolving to the [MilestoneUTXOChanges](#milestoneutxochanges).
#### getReceipts(): Promise
Get all receipts.
-**Returns** a promise resolving to the [Receipts](#Receipts).
+**Returns** a promise resolving to the [Receipts](#receipts).
#### getReceiptsMigratedAt(index): Promise
@@ -496,13 +496,13 @@ Get all receipts for a given milestone index
| ----- | -------- | -------------------------- |
| index | `number` | The index of the milestone |
-**Returns** a promise resolving to the [Receipts](#Receipts).
+**Returns** a promise resolving to the [Receipts](#receipts).
#### getTreasury(): Promise
Get the treasury amount.
-**Returns** a promise resolving to the [Treasury](#Treasury).
+**Returns** a promise resolving to the [Treasury](#treasury).
#### getIncludedMessage(): Promise
diff --git a/docs/build/iota.rs/1.4/docs/libraries/python/api_reference.md b/docs/build/iota.rs/1.4/docs/libraries/python/api_reference.md
index 39d32198b39..5b65a636d65 100644
--- a/docs/build/iota.rs/1.4/docs/libraries/python/api_reference.md
+++ b/docs/build/iota.rs/1.4/docs/libraries/python/api_reference.md
@@ -95,7 +95,7 @@ Gets the balance in the address.
| --------- | ----------- | ----------- | ------------------------- |
| [address] | `list[str]` | `undefined` | The address Bech32 string |
-**Returns** the [BalanceAddressResponse](#BalanceAddressResponse).
+**Returns** the [BalanceAddressResponse](#balanceaddressresponse).
#### get_address_outputs(address, options (optional)): list[UtxoInput]
@@ -106,7 +106,7 @@ Gets the UTXO outputs associated with the given address.
| [address] | `str` | `undefined` | The address Bech32 string |
| [options] | `[[AddressOutputsOptions](#addressoutputsoptions)]` | `undefined` | The query filters |
-**Returns** the list of [UtxoInput](#UtxoInput).
+**Returns** the list of [UtxoInput](#utxoinput).
#### find_outputs(output_ids (optional), addresses (optional)): list[OutputResponse]
@@ -143,7 +143,7 @@ Gets the utxo changes by the given milestone index.
Get all receipts.
-**Returns** the [ReceiptDto](#ReceiptDto).
+**Returns** the [ReceiptDto](#receiptdto).
#### get_receipts_migrated_at(index): Vec
@@ -153,13 +153,13 @@ Get all receipts for a given milestone index.
| ------- | ----- | ----------- | -------------------------- |
| [index] | `int` | `undefined` | The index of the milestone |
-**Returns** the [ReceiptDto](#ReceiptDto).
+**Returns** the [ReceiptDto](#receiptdto).
#### get_treasury(): TreasuryResponse
Get the treasury amount.
-**Returns** the [TreasuryResponse](#TreasuryResponse).
+**Returns** the [TreasuryResponse](#treasuryresponse).
#### get_included_message(): Message
@@ -609,7 +609,7 @@ output_dto = {
}
```
-Please refer to [TreasuryOutputDto](#treasuryoutputdto), [SignatureLockedSingleOutputDto](#signaturelockedsingleoutputdto), and [SignatureLockedDustAllowanceOutputDto](#signaturelockedDustallowanceoutputdto) for the details of these types.
+Please refer to [TreasuryOutputDto](#treasuryoutputdto), [SignatureLockedSingleOutputDto](#signaturelockedsingleoutputdto), and [SignatureLockedDustAllowanceOutputDto](#signaturelockeddustallowanceoutputdto) for the details of these types.
#### SignatureLockedSingleOutputDto
@@ -803,7 +803,7 @@ unlock_block = {
}
```
-Please refer to [Ed25519Signature](#ed25519Signature) for the details of this type.
+Please refer to [Ed25519Signature](#ed25519signature) for the details of this type.
#### Ed25519Signature
diff --git a/docs/build/iota.rs/1.4/docs/libraries/python/examples/_04_get_balance.mdx b/docs/build/iota.rs/1.4/docs/libraries/python/examples/_04_get_balance.mdx
index 43c399930e4..2948c2767c6 100644
--- a/docs/build/iota.rs/1.4/docs/libraries/python/examples/_04_get_balance.mdx
+++ b/docs/build/iota.rs/1.4/docs/libraries/python/examples/_04_get_balance.mdx
@@ -4,7 +4,7 @@ There are three common API calls you can use to get a balance:
Expects a single address in Bech32 format and returns `dict` with a balance for the address.
-## [`Client.get_address_balances(addresses: list[str])`](./../api_reference.md#get_address_balancesaddresses-listaddressbalancepair):
+## [`Client.get_address_balances(addresses: list[str])`](./../api_reference.md#get_address_balancesaddresses-listaddressbalancepair)
A convenient function that expects `list` of addresses in Bech32 format and returns list of `dict` with balances for all given addresses
diff --git a/docs/build/iota.rs/1.4/docs/libraries/rust/examples/_01_get_info.mdx b/docs/build/iota.rs/1.4/docs/libraries/rust/examples/_01_get_info.mdx
index f5570ea1a07..7215e501b3c 100644
--- a/docs/build/iota.rs/1.4/docs/libraries/rust/examples/_01_get_info.mdx
+++ b/docs/build/iota.rs/1.4/docs/libraries/rust/examples/_01_get_info.mdx
@@ -20,7 +20,7 @@ The most common ones are:
the library whether to automatically select devnet nodes or mainnet nodes.
- `.with_node.(self, url: &str)`: Specify address of actual running IOTA node that should be used
to communicate with in the format `https://node:port`). For example: `https://api.lb-0.h.chrysalis-devnet.iota.cafe:443`.
-- `.with_node_pool_urls(self, node_pool_urls: &[String]) `: The library also supports managing a pool of
+- `.with_node_pool_urls(self, node_pool_urls: &[String])`: The library also supports managing a pool of
nodes. You can provide a list of nodes and the library manages the access to them automatically by selecting them based
on their sync status. If you provide `.node_pool_urls(urls)`, then the library periodically will periodically check whether node is in sync or
not by calling `.with_node_sync_interval(self, node_sync_interval: Duration)`.
diff --git a/docs/build/iota.rs/1.4/docs/libraries/rust/examples/_04_get_balance.mdx b/docs/build/iota.rs/1.4/docs/libraries/rust/examples/_04_get_balance.mdx
index ad7d615049f..853ae4958bf 100644
--- a/docs/build/iota.rs/1.4/docs/libraries/rust/examples/_04_get_balance.mdx
+++ b/docs/build/iota.rs/1.4/docs/libraries/rust/examples/_04_get_balance.mdx
@@ -14,7 +14,7 @@ and
[`Client.get_address_balances(addresses: &[String])`](https://docs.rs/iota-client/latest/iota_client/client/struct.Client.html#method.get_address_balances)
api calls. It returns a combined balance for the provided `seed` and optional chaining calls
[`.with_account_index(account_index: usize)`](https://docs.rs/iota-client/latest/iota_client/api/struct.GetBalanceBuilder.html#method.with_account_index),
-[`.with_initial_address_index(initial_address_index: usize)` ](https://docs.rs/iota-client/latest/iota_client/api/struct.GetBalanceBuilder.html#method.with_initial_address_index)
+[`.with_initial_address_index(initial_address_index: usize)`](https://docs.rs/iota-client/latest/iota_client/api/struct.GetBalanceBuilder.html#method.with_initial_address_index)
and
[`.with_gap_limit(gap_limit: usize)`](https://docs.rs/iota-client/latest/iota_client/api/struct.GetBalanceBuilder.html#method.with_gap_limit).
diff --git a/docs/build/iota.rs/1.4/docs/libraries/wasm/examples/_03_generate_addresses.mdx b/docs/build/iota.rs/1.4/docs/libraries/wasm/examples/_03_generate_addresses.mdx
index f0a0dcdb41a..45b9cc700f1 100644
--- a/docs/build/iota.rs/1.4/docs/libraries/wasm/examples/_03_generate_addresses.mdx
+++ b/docs/build/iota.rs/1.4/docs/libraries/wasm/examples/_03_generate_addresses.mdx
@@ -31,7 +31,7 @@ parts relevant to this example:
Addresses can be also represented in a hex format and `iota.rs` provides some convenient functions to convert addresses:
[`Client.bech32ToHex(address)`](./../api_reference.md#clientbech32tohexaddress--string) and
-[`Client.hexToBech32(address, bech32) `](./../api_reference.md#clienthextobech32address-bech32--promiseany).
+[`Client.hexToBech32(address, bech32)`](./../api_reference.md#clienthextobech32address-bech32--promiseany).
If you want to quickly validate any IOTA address, you can use the
[`Client.isAddressValid()`](./../api_reference.md#clientisaddressvalidaddress--boolean) function that
diff --git a/docs/build/iota.rs/1.4/docs/specs.mdx b/docs/build/iota.rs/1.4/docs/specs.mdx
index ace6cf2803f..f598d95945d 100644
--- a/docs/build/iota.rs/1.4/docs/specs.mdx
+++ b/docs/build/iota.rs/1.4/docs/specs.mdx
@@ -139,7 +139,7 @@ starting a new interaction with the library.
| Required | Default Value | Type | Definition |
| -------- | --------------------------------------------- | ------------------------------- | ---------------------------------------------- |
-| ✘ | True,
Duration::from_secs(30),
True | [BrokerOptions](#BrokerOptions) | If not defined the default values will be used |
+| ✘ | True,
Duration::from_secs(30),
True | [BrokerOptions](#brokeroptions) | If not defined the default values will be used |
@@ -455,7 +455,7 @@ only checking and already know the addresses.
A list of tuples with value of [AddressBalancePair](#addressbalancepair). The usize is the balance of the address.
-#### Implementation details:
+#### Implementation details
Please make sure to follow these steps when implementing this method:
@@ -835,7 +835,7 @@ only be retrieved for outputs which are part of a confirmed transaction.
#### Returns
-An [OutputMetadata](#OutputMetadata) that contains information about the output.
+An [OutputMetadata](#outputmetadata) that contains information about the output.
### get_address()
@@ -876,7 +876,7 @@ Find all outputs based on the requests criteria.
#### Returns
-A vector of [OutputMetadata](#OutputMetadata).
+A vector of [OutputMetadata](#outputmetadata).
### get_milestone()
diff --git a/docs/build/iota.rs/2.0-rc.7/docs/getting_started/java.mdx b/docs/build/iota.rs/2.0-rc.7/docs/getting_started/java.mdx
index 4e03ca2856f..4108b0bc44d 100644
--- a/docs/build/iota.rs/2.0-rc.7/docs/getting_started/java.mdx
+++ b/docs/build/iota.rs/2.0-rc.7/docs/getting_started/java.mdx
@@ -105,11 +105,11 @@ Now that you are up and running, you can get acquainted with the library using
its [how-to guides](../how_tos/00_run_how_tos.mdx) and the
repository's [code examples](https://github.com/iotaledger/iota.rs/tree/develop/client/bindings/java/examples/src).
-## Instead, build everything from scratch yourself:
+## Instead, build everything from scratch yourself
If you don't like to use the provided libraries and instead want to build everything yourself from scratch:
-### Build for Android:
+### Build for Android
Requirements:
@@ -308,11 +308,11 @@ Now that you are up and running, you can get acquainted with the library using
its [how-to guides](../how_tos/00_run_how_tos.mdx) and the
repository's [code examples](https://github.com/iotaledger/iota.rs/tree/develop/client/bindings/java/examples/src).
-## Instead, build everything from scratch yourself:
+## Instead, build everything from scratch yourself
If you don't like to use the provided libraries and instead want to build everything yourself from scratch:
-### Build for Android:
+### Build for Android
Requirements:
diff --git a/docs/build/iota.rs/2.0-rc.7/docs/libraries/python/how_to/_run_how_tos.md b/docs/build/iota.rs/2.0-rc.7/docs/libraries/python/how_to/_run_how_tos.md
index bd4ddf3401e..119ae300515 100644
--- a/docs/build/iota.rs/2.0-rc.7/docs/libraries/python/how_to/_run_how_tos.md
+++ b/docs/build/iota.rs/2.0-rc.7/docs/libraries/python/how_to/_run_how_tos.md
@@ -18,7 +18,7 @@ Where [example file name] is one of the
[examples](https://github.com/iotaledger/iota.rs/tree/develop/bindings/python/examples).
For instance, to run
-[`00_get_info.py` ](https://github.com/iotaledger/iota.rs/blob/develop/bindings/python/examples/00_get_info.py),
+[`00_get_info.py`](https://github.com/iotaledger/iota.rs/blob/develop/bindings/python/examples/00_get_info.py),
you should run:
```bash
diff --git a/docs/build/stronghold.rs/1.1/docs/reference/specs/engineering.md b/docs/build/stronghold.rs/1.1/docs/reference/specs/engineering.md
index 6d71bf6f555..ea7f2c8e6bc 100644
--- a/docs/build/stronghold.rs/1.1/docs/reference/specs/engineering.md
+++ b/docs/build/stronghold.rs/1.1/docs/reference/specs/engineering.md
@@ -11,12 +11,8 @@ keywords:
# Stronghold Engineering Specification {#engineering-spec}
-[engineering-spec]: #engineering-spec
-
## Frontmatter
-[frontmatter]: #frontmatter
-
```yaml
title: Stronghold
stub: stronghold
@@ -37,14 +33,10 @@ updated: 2021-Apr-27
## Summary {#summary}
-[summary]: #summary
-
This document introduces the High-Level Specification of the Stronghold.
## Logical System Design {#system-design}
-[system-design]: #system-design
-
### Low Level
A Stronghold is composed of several interacting systems at a low level:
diff --git a/docs/build/stronghold.rs/1.1/docs/reference/specs/requirements.md b/docs/build/stronghold.rs/1.1/docs/reference/specs/requirements.md
index ee507aa6d24..ba30c9a5e28 100644
--- a/docs/build/stronghold.rs/1.1/docs/reference/specs/requirements.md
+++ b/docs/build/stronghold.rs/1.1/docs/reference/specs/requirements.md
@@ -2,12 +2,8 @@
# Requirements Specification
-[requirements]: #requirements
-
## Frontmatter
-[frontmatter]: #frontmatter
-
```yaml
title: Project
stub: project
@@ -45,40 +41,30 @@ Guidelines for Requirements:
## Summary
-[summary]: #summary
-
## Conceptual Model
-[conceptual-model]: #conceptual-model
-
## Structural Model
-[structural-model]: #structural-model
-
## Behavioral Model
-[behavioral-model]: #behavioral-model
-
## Components
-[components]: #components
-
## Non-functional Requirements
-[nonfunctionalrequirements]: #nonfunctionalrequirements
-
@@ -50,8 +44,6 @@ All code is licensed under the Apache-2 license, all text and images are license
## Language
-[language]: #language
-
@@ -60,8 +52,6 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
## Versioning
-[versioning]: #versioning
-
@@ -72,8 +62,6 @@ Software releases will follow [strict semantic versioning](https://semver.org/).
## Hierarchy
-[hierarchy]: #hierarchy
-
@@ -82,8 +70,6 @@ All documents in this specification are understood to flow from this document an
## Summary
-[summary]: #summary
-
Stronghold is a secure software implementation (often used in conjunction with - or existing purely on - specialist hardware) with the
sole purpose of isolating the seed, private keys, personally identifiable information (PII) and policy records from exposure
to the genuinely hostile environment of user devices. It uses snapshotting and internal mechanisms for threshold signature
@@ -101,8 +87,6 @@ that devices on different networks can collaborate cryptographically.
## Motivation
-[motivation]: #motivation
-
### Research
Coming on the heels of the Trinity attack, it became clear that a new method for securing secrets needed to be manufactured and made
@@ -126,8 +110,6 @@ available to the pantheon of IOTA Products.
## Product Introduction{#product}
-[product]: #product
-
### Business Application Benefits
- Enhance the security posture of critical IOTA Products
@@ -148,15 +130,11 @@ available to the pantheon of IOTA Products.
## Stakeholders
-[stakeholders]: #stakeholders
-
A number of IOTA foundation stakeholders have been involved in the design process, ranging
from Engineering to Product and developer outreach.
## Guide-level explanation
-[guide-level-explanation]: #guide-level-explanation
-
Stronghold itself has several core components:
### 1. Low level libraries (engine.rs)
@@ -194,8 +172,6 @@ This work will be undertaken in house by IOTA developers.
## Prior art
-[prior-art]: #prior-art
-
There is a massive amount of prior art.
### Trinity
@@ -387,8 +363,6 @@ https://keycard.tech/
## Unresolved questions
-[unresolved-questions]: #unresolved-questions
-