From b421b7ad5f1d32e7f2d6449a7e52e783cb30aa3d Mon Sep 17 00:00:00 2001 From: Dr-Electron Date: Sun, 13 Aug 2023 23:22:22 +0200 Subject: [PATCH] Fix fixable --- .../tutorial-basics/markdown-features.mdx | 2 +- iota/develop/network-token-migration.md | 2 +- .../deployment-and-testing.md | 2 +- iota/docs/chronicle/docs/getting_started.md | 2 +- .../docs/goshimmer/docs/apis/communication.md | 2 +- iota/docs/goshimmer/docs/apis/ledgerstate.md | 6 +- .../implementation_design/object_storage.md | 3 + .../components/autopeering.md | 6 +- .../components/consensus_mechanism.md | 10 +- .../protocol_specification/components/mana.md | 32 ++--- .../components/overview.md | 4 +- .../goshimmer/docs/tooling/evil_spammer.md | 4 +- .../goshimmer/docs/tutorials/monitoring.md | 128 ++++++++++++------ iota/docs/goshimmer/docs/tutorials/setup.md | 2 +- .../docs/tutorials/wallet_library.md | 3 +- .../hornet/docs/references/configuration.md | 4 +- .../decentralized_identifiers/resolve.mdx | 2 +- .../v0.5.0/docs/decentralized_identity.mdx | 2 +- .../docs/libraries/wasm/api_reference.mdx | 2 +- .../docs/libraries/wasm/getting_started.mdx | 6 +- .../v0.5.0/docs/specs/didcomm/overview.mdx | 3 +- .../specs/didcomm/protocols/connection.mdx | 2 +- .../tutorials/validate_university_degree.mdx | 10 +- .../docs/identity.rs/v0.5.0/docs/workflow.mdx | 28 ++-- .../decentralized_identifiers/resolve.mdx | 2 +- .../v0.6.0/docs/decentralized_identity.mdx | 2 +- .../docs/libraries/wasm/api_reference.mdx | 2 +- .../docs/libraries/wasm/getting_started.mdx | 6 +- .../v0.6.0/docs/specs/didcomm/overview.mdx | 1 + .../specs/didcomm/protocols/connection.mdx | 2 +- .../docs/identity.rs/v0.6.0/docs/workflow.mdx | 28 ++-- .../services/SSI-bridge/use-cases.md | 2 +- .../installation/java/local_setup.md | 2 + .../installation/kubernetes/expose_apis.md | 2 +- .../audit_trail_gw_api_reference.md | 88 ++++++------ .../references/ssi_bridge_api_reference.md | 76 +++++------ .../snapshot_validation_bootstrapping.md | 2 +- .../2.3_standard_payloads_layout.md | 2 +- .../3.4_neighbor_selection.md | 8 +- .../4.7_markers.md | 8 +- .../5.3_mana.md | 3 +- .../6.2_opinion_setting.md | 2 +- .../6.3_fast_probabilistic_consensus.md | 2 +- .../java/examples/_09_transaction.mdx | 2 +- .../docs/libraries/nodejs/api_reference.md | 12 +- .../docs/libraries/python/api_reference.md | 14 +- .../python/examples/_04_get_balance.mdx | 2 +- .../libraries/rust/examples/_01_get_info.mdx | 2 +- .../rust/examples/_04_get_balance.mdx | 2 +- .../wasm/examples/_03_generate_addresses.mdx | 2 +- iota/docs/iota.rs/docs/specs.mdx | 8 +- .../docs/reference/specs/engineering.md | 8 -- .../docs/reference/specs/requirements.md | 24 ---- .../docs/reference/specs/scope.md | 28 ---- .../docs/reference/specs/threat-modeling.md | 2 +- .../docs/reference/structure/client.md | 4 +- .../docs/reference/structure/derive.md | 2 +- iota/docs/stronghold.rs/docs/welcome.md | 2 +- iota/docs/wallet.rs/docs/examples/nodejs.mdx | 4 +- iota/docs/wallet.rs/docs/examples/python.mdx | 2 +- .../docs/reference/specifications.md | 2 +- .../track-trace-ledger-api-tutorial-101.md | 2 +- .../track-trace-ledger-api-tutorial-102.md | 32 ++--- .../zebra-iota-edge-sdk-101-tutorial.md | 2 +- .../zebra-iota-edge-sdk-102-tutorial.md | 2 +- iota/learn/about-iota/messages.md | 2 +- .../firefly/faq-and-troubleshooting.md | 6 +- iota/use/wallets/firefly/user-guide.md | 2 +- .../docs/goshimmer/docs/apis/communication.md | 2 +- next/docs/goshimmer/docs/apis/ledgerstate.md | 6 +- .../implementation_design/object_storage.md | 3 + .../components/autopeering.md | 6 +- .../components/consensus_mechanism.md | 10 +- .../protocol_specification/components/mana.md | 32 ++--- .../components/overview.md | 4 +- .../goshimmer/docs/tooling/evil_spammer.md | 4 +- .../goshimmer/docs/tutorials/monitoring.md | 128 ++++++++++++------ next/docs/goshimmer/docs/tutorials/setup.md | 2 +- .../docs/tutorials/wallet_library.md | 3 +- .../0.7-alpha/docs/decentralized_identity.mdx | 2 +- .../docs/libraries/wasm/api_reference.mdx | 6 +- .../docs/libraries/wasm/getting_started.mdx | 6 +- .../identity.rs/0.7-alpha/docs/workflow.mdx | 28 ++-- .../2.3_standard_payloads_layout.md | 2 +- .../3.4_neighbor_selection.md | 8 +- .../4.7_markers.md | 8 +- .../5.3_mana.md | 3 +- .../6.2_opinion_setting.md | 2 +- .../6.3_fast_probabilistic_consensus.md | 2 +- next/docs/iota-sdk/docs/contribute.md | 2 +- .../iota-sdk/docs/getting-started/nodejs.mdx | 8 +- .../iota-sdk/docs/getting-started/python.mdx | 6 +- .../docs/reference/specs/engineering.md | 8 -- .../docs/reference/specs/requirements.md | 24 ---- .../docs/reference/specs/scope.md | 28 ---- .../docs/reference/specs/threat-modeling.md | 2 +- .../docs/reference/structure/client.md | 4 +- .../docs/reference/structure/derive.md | 2 +- next/docs/stronghold.rs/docs/welcome.md | 2 +- .../core_contracts/governance.md | 2 +- .../core_concepts/core_contracts/xfer.md | 2 +- .../wasp/docs/guide/evm/examples/ERC20.md | 2 +- .../wasp/docs/guide/evm/examples/ERC721.md | 2 +- next/docs/wasp/docs/guide/evm/quickstart.mdx | 8 +- .../guide/example_projects/fair_roulette.md | 2 + next/docs/wasp/docs/guide/wasm_vm/spec.mdx | 2 +- .../shimmer-community-grant-committee.md | 20 +-- .../the-shimmer-governance-framework.md | 8 +- .../firefly/faq-and-troubleshooting.md | 4 +- next/use/wallets/firefly/user-guide.md | 2 +- .../docs/goshimmer/docs/apis/communication.md | 2 +- .../docs/goshimmer/docs/apis/ledgerstate.md | 6 +- .../implementation_design/object_storage.md | 23 ++-- .../components/autopeering.md | 6 +- .../components/consensus_mechanism.md | 10 +- .../protocol_specification/components/mana.md | 32 ++--- .../components/overview.md | 4 +- .../goshimmer/docs/tooling/evil_spammer.md | 4 +- .../goshimmer/docs/tutorials/monitoring.md | 128 ++++++++++++------ .../docs/goshimmer/docs/tutorials/setup.md | 2 +- .../docs/tutorials/wallet_library.md | 3 +- .../0.7-alpha/docs/decentralized_identity.mdx | 2 +- .../docs/libraries/wasm/api_reference.mdx | 2 +- .../docs/libraries/wasm/getting_started.mdx | 6 +- .../identity.rs/0.7-alpha/docs/workflow.mdx | 28 ++-- .../2.3_standard_payloads_layout.md | 2 +- .../3.4_neighbor_selection.md | 8 +- .../4.7_markers.md | 8 +- .../5.3_mana.md | 3 +- .../6.2_opinion_setting.md | 2 +- .../6.3_fast_probabilistic_consensus.md | 2 +- shimmer/docs/iota-sdk/docs/contribute.md | 2 +- .../iota-sdk/docs/getting-started/nodejs.mdx | 8 +- .../iota-sdk/docs/getting-started/python.mdx | 6 +- .../iota.rs/docs/getting_started/java.mdx | 8 +- .../libraries/python/how_to/_run_how_tos.md | 2 +- .../docs/reference/specs/engineering.md | 8 -- .../docs/reference/specs/requirements.md | 24 ---- .../docs/reference/specs/scope.md | 28 ---- .../docs/reference/specs/threat-modeling.md | 2 +- .../docs/reference/structure/client.md | 4 +- .../docs/reference/structure/derive.md | 2 +- shimmer/docs/stronghold.rs/docs/welcome.md | 2 +- .../wallet.rs/docs/getting_started/java.mdx | 4 +- .../libraries/python/how_to/_run_how_tos.md | 2 +- .../core_contracts/governance.md | 2 +- .../core_concepts/core_contracts/xfer.md | 2 +- .../wasp/docs/guide/evm/examples/ERC20.md | 2 +- .../wasp/docs/guide/evm/examples/ERC721.md | 2 +- .../docs/wasp/docs/guide/evm/quickstart.mdx | 8 +- .../guide/example_projects/fair_roulette.md | 2 + shimmer/docs/wasp/docs/guide/wasm_vm/spec.mdx | 2 +- .../shimmer-community-grant-committee.md | 20 +-- .../the-shimmer-governance-framework.md | 8 +- .../firefly/faq-and-troubleshooting.md | 4 +- shimmer/use/wallets/firefly/user-guide.md | 2 +- theme/README.md | 2 +- tutorials/pages/hornet-inx-interaction.md | 12 +- tutorials/pages/proof-inclusion-of-a-block.md | 2 +- .../pages/send-iota-tokens-with-javascript.md | 10 +- tutorials/pages/shimmerevm-dapp-voting.md | 2 +- 161 files changed, 766 insertions(+), 785 deletions(-) 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/iota/develop/network-token-migration.md b/iota/develop/network-token-migration.md index b3a50e13fe5..9efa0e0bffa 100644 --- a/iota/develop/network-token-migration.md +++ b/iota/develop/network-token-migration.md @@ -5,7 +5,7 @@ description: into the new Chrysalis network --- -# Network Token migration: +# Network Token migration ## Why does IOTA migrate tokens? diff --git a/iota/docs/blueprints/data-marketplace/deployment-and-testing.md b/iota/docs/blueprints/data-marketplace/deployment-and-testing.md index 3a18747fd21..9bddac901f4 100644 --- a/iota/docs/blueprints/data-marketplace/deployment-and-testing.md +++ b/iota/docs/blueprints/data-marketplace/deployment-and-testing.md @@ -100,7 +100,7 @@ Instead of deploying your own data marketplace, you can test our demo app by add 5. Extract the content of the archive, and open the folder in a code editor such as [Visual Studio Code](https://code.visualstudio.com/Download) to start working with the script :::info: - Read the` README.md` file before you start using the script. + Read the `README.md` file before you start using the script. ::: The script is pre-configured to publish data for the selected device. You’ll find the sensor ID and its secret key in the `config.json` file. diff --git a/iota/docs/chronicle/docs/getting_started.md b/iota/docs/chronicle/docs/getting_started.md index 836237d1591..1bae6d1eedc 100644 --- a/iota/docs/chronicle/docs/getting_started.md +++ b/iota/docs/chronicle/docs/getting_started.md @@ -68,7 +68,7 @@ Chronicle uses a [RON](https://github.com/ron-rs/ron) file to store configuratio ### Running Chronicle -See [Building Chronicle](#Building-Chronicle). +See [Building Chronicle](#building-chronicle). ```bash cd target/release && cp /path/to/your/config.ron ./ diff --git a/iota/docs/goshimmer/docs/apis/communication.md b/iota/docs/goshimmer/docs/apis/communication.md index d9d8afd3ccb..08f7742ba49 100644 --- a/iota/docs/goshimmer/docs/apis/communication.md +++ b/iota/docs/goshimmer/docs/apis/communication.md @@ -52,7 +52,7 @@ where `:blockID` is the base58 encoded block ID, e.g. 4MSkwAPzGwnjCJmTfbpW4z4GRC #### Client lib - `GetBlock` -Blocks can be retrieved via `GetBlock(base58EncodedID string) (*jsonmodels.Block, error) ` +Blocks can be retrieved via `GetBlock(base58EncodedID string) (*jsonmodels.Block, error)` ```go block, err := goshimAPI.GetBlock(base58EncodedBlockID) diff --git a/iota/docs/goshimmer/docs/apis/ledgerstate.md b/iota/docs/goshimmer/docs/apis/ledgerstate.md index 693bee57937..af14ff8ecee 100644 --- a/iota/docs/goshimmer/docs/apis/ledgerstate.md +++ b/iota/docs/goshimmer/docs/apis/ledgerstate.md @@ -14,7 +14,7 @@ keywords: # Ledgerstate API Methods -## HTTP APIs: +## HTTP APIs - [/ledgerstate/addresses/:address](#ledgerstateaddressesaddress) - [/ledgerstate/addresses/:address/unspentOutputs](#ledgerstateaddressesaddressunspentoutputs) @@ -31,7 +31,7 @@ keywords: - [/ledgerstate/transactions](#ledgerstatetransactions) - [/ledgerstate/addresses/unspentOutputs](#ledgerstateaddressesunspentoutputs) -## Client Lib APIs: +## Client Lib APIs - [GetAddressOutputs()](#client-lib---getaddressoutputs) - [GetAddressUnspentOutputs()](#client-lib---getaddressunspentoutputs) @@ -851,7 +851,7 @@ fmt.Println("consensus mana pledgeID:", resp.ConsensusPledgeID) | `unlockBlocks` | []UnlockBlock | The unlock block containing signatures unlocking the inputs or references to previous unlock blocks. | | `dataPayload` | []byte | The raw data payload that can be attached to the transaction. | -#### Type `Input ` +#### Type `Input` | Field | Type | Description | | :------------------- | :----------------- | :---------------------------------------------------------- | diff --git a/iota/docs/goshimmer/docs/implementation_design/object_storage.md b/iota/docs/goshimmer/docs/implementation_design/object_storage.md index 2615ffc2aec..dda51c0b224 100644 --- a/iota/docs/goshimmer/docs/implementation_design/object_storage.md +++ b/iota/docs/goshimmer/docs/implementation_design/object_storage.md @@ -189,6 +189,7 @@ we can start using it for its sole purpose, to actually store and read the parti - `ForEach` - allows to apply a `Consumer` function for every object residing within the cache and the underlying persistence layer. For example, this is how we can count the number of blocks. + ```Go blockCount := 0 blockStorage.ForEach(func(key []byte, cachedObject generic.CachedObject) bool { @@ -197,9 +198,11 @@ we can start using it for its sole purpose, to actually store and read the parti }) } ``` + - `Store` - storing an object in the objectStorage. An extended version is method `StoreIfAbsent` that stores an object only if it was not stored before and returns boolean indication if the object was stored. `ComputeIfAbsent` works similarly but does not access the value log. + ```Go cachedBlock := blockStorage.Store(newBlock) cachedBlock, stored := blockStorage.StoreIfAbsent(newBlock) diff --git a/iota/docs/goshimmer/docs/protocol_specification/components/autopeering.md b/iota/docs/goshimmer/docs/protocol_specification/components/autopeering.md index 83aa1d2a576..c7a941e69ac 100644 --- a/iota/docs/goshimmer/docs/protocol_specification/components/autopeering.md +++ b/iota/docs/goshimmer/docs/protocol_specification/components/autopeering.md @@ -159,9 +159,9 @@ The maximum number of neighbors is a parameter of the gossip protocol. This sect The operations involved during neighbor selection are listed in the following: -1. Get an up-to-date list of verified and known peers from the _Peer Discovery_ protocol. -2. Use [mana rank](#Mana_rank) to filter the previous list to obtain a list of peers to be potential neighbors. -3. Use the score function to request/accept neighbors. +1. Get an up-to-date list of verified and known peers from the _Peer Discovery_ protocol. +2. Use [mana rank](#Mana_rank) to filter the previous list to obtain a list of peers to be potential neighbors. +3. Use the score function to request/accept neighbors. The score between two nodes is measured through the score function _s_, defined by: diff --git a/iota/docs/goshimmer/docs/protocol_specification/components/consensus_mechanism.md b/iota/docs/goshimmer/docs/protocol_specification/components/consensus_mechanism.md index b4771e64fa7..dfc6bede7bf 100644 --- a/iota/docs/goshimmer/docs/protocol_specification/components/consensus_mechanism.md +++ b/iota/docs/goshimmer/docs/protocol_specification/components/consensus_mechanism.md @@ -15,18 +15,18 @@ keywords: The consensus mechanism is necessary to achieve agreement among the nodes of the network. In case of a double spend, one way to decide which transaction should be considered valid would be to order them and pick the oldest one. However, the Tangle is only partially ordered. To tackle this problem in the context of the Tangle, we have designed an open and leaderless consensus mechanism that utilizes the Tangle as a medium to exchange votes. Any node can add a block to the Tangle, and each block added to the Tangle represents a virtual vote (i.e. there is no additional overhead to communicate votes) to its entire past. -The consensus mechanism can broadly be devided into consensus on two separate entities. On the one hand, we need to resolve any conflicts on the underlying UTXO ledger to prevent double spends. On the other hand, we need to make sure that blocks within the Tangle are not orphaned. Both are simply derived by observing the Tangle and objectively keeping track of [Approval Weight (AW)](#Approval-Weight-AW) with cMana (more specifically [active cMana](#Active-cMana)) as a Sibyl protection. Once a [conflict](ledgerstate.md#conflicts) (or block) reaches a certain AW threshold, an application can consider it as _confirmed_. To simplify this notion we introduce [Grades of Finality (GoF)](#Grades-of-Finality-GoF) where a higher GoF represents a higher confidence. +The consensus mechanism can broadly be devided into consensus on two separate entities. On the one hand, we need to resolve any conflicts on the underlying UTXO ledger to prevent double spends. On the other hand, we need to make sure that blocks within the Tangle are not orphaned. Both are simply derived by observing the Tangle and objectively keeping track of [Approval Weight (AW)](#approval-weight-aw) with cMana (more specifically [active cMana](#active-cmana)) as a Sibyl protection. Once a [conflict](ledgerstate.md#conflicts) (or block) reaches a certain AW threshold, an application can consider it as _confirmed_. To simplify this notion we introduce [Grades of Finality (GoF)](#grades-of-finality-gof) where a higher GoF represents a higher confidence. | Name | Component | Initial/local opinion | Consensus | Comparable blockchain mechanism for voting/finality | | ------------------- | ----------- | --------------------------------- | -------------- | --------------------------------------------------- | | voting on conflicts | UTXO ledger | OTV/FPCS | conflict/tx AW | longest chain rule | | finality of blocks | Tangle | inclusion score via tip selection | block AW | x block rule | -On an abstract level, a node can be seen as a replicated state machine, just following whatever it receives through the Tangle, and, in case of blocks containing transactions, modifying the UTXO ledger. Only when a node wants to issue a block (read as: _cast a vote_) it needs to evaluate its own local opinion via [modular conflict selection function](#Modular-Conflict-Selection-Function). This decoupling of coming to consensus and setting the initial opinion allows for great flexibility and separation of concerns. +On an abstract level, a node can be seen as a replicated state machine, just following whatever it receives through the Tangle, and, in case of blocks containing transactions, modifying the UTXO ledger. Only when a node wants to issue a block (read as: _cast a vote_) it needs to evaluate its own local opinion via [modular conflict selection function](#modular-conflict-selection-function). This decoupling of coming to consensus and setting the initial opinion allows for great flexibility and separation of concerns. ## Approval Weight (AW) -Approval weight represents the [weight](#active-consensus-mana) of conflicts (and blocks), similar to the longest chain rule in Nakamoto consensus. However, instead of selecting a leader based on a puzzle (PoW) or stake (PoS), it allows every node to express its opinion by simply issuing any block and attaching it in a part of the Tangle it _likes_ (based on its initial opinion on blocks and possibly utilizing the [like switch](#Like-Switch) to express its opinion on conflicts). +Approval weight represents the [weight](#active-consensus-mana) of conflicts (and blocks), similar to the longest chain rule in Nakamoto consensus. However, instead of selecting a leader based on a puzzle (PoW) or stake (PoS), it allows every node to express its opinion by simply issuing any block and attaching it in a part of the Tangle it _likes_ (based on its initial opinion on blocks and possibly utilizing the [like switch](#like-switch) to express its opinion on conflicts). It is important to note that tracking of AW for conflicts and markers/blocks is orthogonal. Thus, a block can reach a high AW whereas its contained payload, e.g., a transaction being a double spend, does not reach any AW on conflict/UTXO level. @@ -42,7 +42,7 @@ Approval weight AW increases because of voters (nodes) that cast votes for confl #### Conflicts -Tracking voters of [conflicts](ledgerstate.md#conflicts) is an effective way of objective virtual voting. It allows nodes to express their opinion simply by attaching a statement to a conflict they like (see [like switch](#Like-Switch)). This statement needs to propagate down the conflict DAG, adding support to each of the conflict's parents. In case a voter changes their opinion, support needs to be revoked from all conflicting conflicts and their children. Thus, a node can only support one conflict of a conflict set. +Tracking voters of [conflicts](ledgerstate.md#conflicts) is an effective way of objective virtual voting. It allows nodes to express their opinion simply by attaching a statement to a conflict they like (see [like switch](#like-switch)). This statement needs to propagate down the conflict DAG, adding support to each of the conflict's parents. In case a voter changes their opinion, support needs to be revoked from all conflicting conflicts and their children. Thus, a node can only support one conflict of a conflict set. To make this more clear consider the following example: @@ -123,7 +123,7 @@ GoF | AW 2 | >= 0.45 3 | >= 0.67 -These thresholds play a curcial role in the safety vs. liveness of the protocol, together with the exact workings of [active cMana](#Active-cMana). We are currently investigating them with in-depth simulations. +These thresholds play a curcial role in the safety vs. liveness of the protocol, together with the exact workings of [active cMana](#active-cmana). We are currently investigating them with in-depth simulations. - The higher the AW threshold the more voters a conflict or block will need to reach a certain GoF -> more secure but higher confirmation time. - As a consequence of the above point, TangleTime will be tougher to advance; making the cMana window more likely to get stuck and confirmations to halt forever. diff --git a/iota/docs/goshimmer/docs/protocol_specification/components/mana.md b/iota/docs/goshimmer/docs/protocol_specification/components/mana.md index 708a091ebdd..87a093272cb 100644 --- a/iota/docs/goshimmer/docs/protocol_specification/components/mana.md +++ b/iota/docs/goshimmer/docs/protocol_specification/components/mana.md @@ -49,10 +49,10 @@ From the pledged mana of a transaction, a node can calculate locally the `Base M A `Base Mana Vector` consists of Base Mana 1 and Base Mana 2 and their respective `Effective Base Mana`. Given a value transaction, Base Mana 1 and Base Mana 2 are determined as follows: -1. Base Mana 1 is revoked from the node that created the output(s) used as input(s) in the transaction, and is pledged to +1. Base Mana 1 is revoked from the node that created the output(s) used as input(s) in the transaction, and is pledged to the node creating the new output(s). The amount of `Base Mana 1` revoked and pledged is equal to the balance of the input. -2. Base Mana 2 is freshly created at the issuance time of the transaction, awarded to the node, but decays with time. +2. Base Mana 2 is freshly created at the issuance time of the transaction, awarded to the node, but decays with time. The amount of `Base Mana 2` pledged is determined with `Pending Mana` concept: funds sitting at an address generate `pending mana` that grows over time, but bounded. - `Mana_pending = (alpha*S)/gamma*(1-e^(-gamma*t))`, where `alpha` and `gamma` are chosen parameters, `S` is the amount @@ -121,17 +121,17 @@ The first implementation of mana in GoShimmer will: In this section, detailed GoShimmer implementation design considerations will be outlined about the mana module. In short, changes can be classified into 3 categories: -1. Transaction related changes, -2. Mana module functionality, -3. and related tools/utilities, such as API, visualization, analytics. +1. Transaction related changes, +2. Mana module functionality, +3. and related tools/utilities, such as API, visualization, analytics. ### Transaction As described above, 3 new fields will be added to the transaction layout: -1. `Timestamp` time.time -2. `AccessManaNodeID` []bytes -3. `ConsensusManaNodeID` []bytes +1. `Timestamp` time.time +2. `AccessManaNodeID` []bytes +3. `ConsensusManaNodeID` []bytes By adding these fields to the signed transaction, `valuetransfers/packages/transaction` should be modified. @@ -153,13 +153,13 @@ Node owners are free to choose to whom they pledge mana to with the transaction, lets the client know, what `AccessManaNodeID` and `ConsensusManaNodeID` are allowed. This could be a new API endpoint that works like this: -1. Client asks node what nodeIDs can be included for pledging a certain type (access, consensus) mana. -2. Node answers with either: +1. Client asks node what nodeIDs can be included for pledging a certain type (access, consensus) mana. +2. Node answers with either: - Don't care. Any node IDs are valid. - List of nodeIDs that are allowed for each type. -3. If a client sends back the transaction with invalid or empty mana fields, the transaction is considered invalid. +3. If a client sends back the transaction with invalid or empty mana fields, the transaction is considered invalid. This way node owners can decide who their transactions are pledging mana to. It could be only their node, or they could provide mana pledging as a service. They could delegate access mana to others, but hold own to consensus mana, or the @@ -222,7 +222,7 @@ type BaseManaVector struct { - `BookMana(transaction)`: Book mana of a transaction. Trigger `ManaBooked` event. Note, that this method updates `BaseMana` with respect to time and to new `Base Mana 1` and `Base Mana 2` values. -- `GetWeightedMana(nodeID, weight) mana`: Return `weight` \*` Effective Base Mana 1` + (1-`weight`)+`Effective Base Mana 2`. +- `GetWeightedMana(nodeID, weight) mana`: Return `weight` \* `Effective Base Mana 1` + (1-`weight`)+`Effective Base Mana 2`. `weight` is a number in [0,1] interval. Notice, that `weight` = 1 results in only returning `Effective Base Mana 1`, and the other way around. Note, that this method also updates `BaseMana` of the node with respect to time. - `GetMana(nodeID) mana`: Return 0.5*`Effective Base Mana 1` + 0.5*`Effective Base Mana 2` of a particular node. Note, that @@ -243,8 +243,8 @@ type BaseManaVector struct { There are two cases when the values within `Base Mana Vector` are updated: -1. A confirmed transaction pledges mana. -2. Any module accesses the `Base Mana Vector`, and hence its values are updated with respect to `access time`. +1. A confirmed transaction pledges mana. +2. Any module accesses the `Base Mana Vector`, and hence its values are updated with respect to `access time`. First, let's explore the former. @@ -587,8 +587,8 @@ is visualized for a node: There are two ways to visualize mana in GoShimmer: -1. Node Local Dashboard -2. Grafana Dashboard +1. Node Local Dashboard +2. Grafana Dashboard While `Local Dashboard` gives flexibility in what and how to visualize, `Grafana Dashboard` is better at storing historic data but can only visualize time series. Therefore, both of these ways will be utilized, depending on which suits the best. diff --git a/iota/docs/goshimmer/docs/protocol_specification/components/overview.md b/iota/docs/goshimmer/docs/protocol_specification/components/overview.md index 33c253f559c..7fd95fed302 100644 --- a/iota/docs/goshimmer/docs/protocol_specification/components/overview.md +++ b/iota/docs/goshimmer/docs/protocol_specification/components/overview.md @@ -103,8 +103,8 @@ After the objective checks, the following subjective checks are done: At this point, the missing steps are the most computationally expensive: -7. Inputs' conflicting conflicts check: it checks if the conflicts of the inputs are conflicting. As in the last step, if the block does not pass this check, the block is marked as `invalid` and not booked. If it passes the check, it goes to the next step. -8. Conflict check: it checks if the inputs are conflicting with an unconfirmed transaction. In this step, the conflict to which the block belongs is computed. In both cases (passing the check or not), the transaction is booked into the ledger state and the block is booked into the Tangle, but its conflict ID will be different depending on the outcome of the check. +7. Inputs' conflicting conflicts check: it checks if the conflicts of the inputs are conflicting. As in the last step, if the block does not pass this check, the block is marked as `invalid` and not booked. If it passes the check, it goes to the next step. +8. Conflict check: it checks if the inputs are conflicting with an unconfirmed transaction. In this step, the conflict to which the block belongs is computed. In both cases (passing the check or not), the transaction is booked into the ledger state and the block is booked into the Tangle, but its conflict ID will be different depending on the outcome of the check. [![Booker](/img/protocol_specification/booker.png 'Booker')](/img/protocol_specification/booker.png) diff --git a/iota/docs/goshimmer/docs/tooling/evil_spammer.md b/iota/docs/goshimmer/docs/tooling/evil_spammer.md index fb5c46eeee9..4689ad9bc4d 100644 --- a/iota/docs/goshimmer/docs/tooling/evil_spammer.md +++ b/iota/docs/goshimmer/docs/tooling/evil_spammer.md @@ -65,7 +65,7 @@ Example usage: go run . quick --urls http://localhost:8080,http://localhost:8090 --rate 50 --duration 1m --tu 1s --dbc 100ms ``` -### Go interactive! +### Go interactive Simply run @@ -265,7 +265,7 @@ clients := evilwallet.GetClients(1) clients[0].PostTransaction(txC) ``` -### Compose your own scenario! +### Compose your own scenario The most exciting part of evil wallet is to create whatever scenario easily! diff --git a/iota/docs/goshimmer/docs/tutorials/monitoring.md b/iota/docs/goshimmer/docs/tutorials/monitoring.md index 133e383f846..d4307ab3a28 100644 --- a/iota/docs/goshimmer/docs/tutorials/monitoring.md +++ b/iota/docs/goshimmer/docs/tutorials/monitoring.md @@ -41,15 +41,20 @@ One of the easiest ways to run a node is to use [Docker](https://www.docker.com/ 1. [Install docker](https://docs.docker.com/get-docker/). On Linux, make sure you install both the [Docker Engine](https://docs.docker.com/engine/install/) and [Docker Compose](https://docs.docker.com/compose/install/). 2. Clone the GoShimmer repository. + ```shell - $ git clone git@github.com:iotaledger/goshimmer.git + git clone git@github.com:iotaledger/goshimmer.git ``` + 3. Create a `config.json` from the provided `config.default.json`. + ```shell - $ cd goshimmer - $ cp config.default.json config.json + cd goshimmer + cp config.default.json config.json ``` + Make sure, that following entry is present in `config.json`: + ```json { "prometheus": { @@ -57,9 +62,11 @@ One of the easiest ways to run a node is to use [Docker](https://www.docker.com/ } } ``` + 4. From the root of the repo, start GoShimmer with: + ```shell - $ docker compose up + docker compose up ``` You should be able to reach the Monitoring Dashboard via browser at [localhost:3000](http://localhost:3000). Default login credentials are: @@ -77,6 +84,7 @@ If you run the [released binaries](https://github.com/iotaledger/goshimmer/relea ### GoShimmer Configuration 1. Make sure that the `prometheus.bindAddress` config parameter is set in your `config.json`: + ```json { "prometheus": { @@ -84,7 +92,9 @@ If you run the [released binaries](https://github.com/iotaledger/goshimmer/relea } } ``` + 2. Make sure, that the `prometheus` plugin is enabled in your `config.json`: + ```json { "node": { @@ -102,11 +112,14 @@ First, we take a look on how to configure and run Prometheus as a standalone app 1. [Download](https://prometheus.io/download/) the latest release of Prometheus for your system. 2. Unpack the downloaded file: + ```shell - $ tar xvfz prometheus-*.tar.gz - $ cd prometheus-* + tar xvfz prometheus-*.tar.gz + cd prometheus-* ``` + 3. Create a `prometheus.yml` in the unpacked directory with the following content: + ```yaml scrape_configs: - job_name: goshimmer_local @@ -116,11 +129,14 @@ First, we take a look on how to configure and run Prometheus as a standalone app # goshimmer prometheus plugin export - 127.0.0.1:9311 ``` + 4. Start Prometheus from the unpacked folder: + ```shell # By default, Prometheus stores its database in ./data (flag --storage.tsdb.path). $ ./prometheus --config.file=prometheus.yml ``` + 5. You can access the prometheus server at [localhost:9090](http://localhost:9090). 6. (Optional) Prometheus server is running, but observe that [localhost:9090/targets](http://localhost:9090/targets) shows the target being `DOWN`. Run GoShimmer with the configuration from the previous stage, and you will soon see the `goshimmer_local` target being `UP`. @@ -129,39 +145,50 @@ First, we take a look on how to configure and run Prometheus as a standalone app Note: you have to have root privileges with your user to carry out the following steps. 1. Create a Prometheus user, directories, and set this user as the owner of those directories. + ```shell - $ sudo useradd --no-create-home --shell /bin/false prometheus - $ sudo mkdir /etc/prometheus - $ sudo mkdir /var/lib/prometheus - $ sudo chown prometheus:prometheus /etc/prometheus - $ sudo chown prometheus:prometheus /var/lib/prometheus + sudo useradd --no-create-home --shell /bin/false prometheus + sudo mkdir /etc/prometheus + sudo mkdir /var/lib/prometheus + sudo chown prometheus:prometheus /etc/prometheus + sudo chown prometheus:prometheus /var/lib/prometheus ``` + 2. Download Prometheus source, extract and rename. + ```shell - $ wget https://github.com/prometheus/prometheus/releases/download/v2.19.1/prometheus-2.19.1.linux-amd64.tar.gz - $ tar xvfz prometheus-2.19.1.linux-amd64.tar.gz - $ mv prometheus-2.19.1.linux-amd64.tar.gz prometheus-files + wget https://github.com/prometheus/prometheus/releases/download/v2.19.1/prometheus-2.19.1.linux-amd64.tar.gz + tar xvfz prometheus-2.19.1.linux-amd64.tar.gz + mv prometheus-2.19.1.linux-amd64.tar.gz prometheus-files ``` + 3. Copy Prometheus binaries to `/bin` and change their ownership + ```shell - $ sudo cp prometheus-files/prometheus /usr/local/bin/ - $ sudo cp prometheus-files/promtool /usr/local/bin/ - $ sudo chown prometheus:prometheus /usr/local/bin/prometheus - $ sudo chown prometheus:prometheus /usr/local/bin/promtool + sudo cp prometheus-files/prometheus /usr/local/bin/ + sudo cp prometheus-files/promtool /usr/local/bin/ + sudo chown prometheus:prometheus /usr/local/bin/prometheus + sudo chown prometheus:prometheus /usr/local/bin/promtool ``` + 4. Copy Prometheus console libraries to `/etc` and change their ownership. + ```shell - $ sudo cp -r prometheus-files/consoles /etc/prometheus - $ sudo cp -r prometheus-files/console_libraries /etc/prometheus - $ sudo chown -R prometheus:prometheus /etc/prometheus/consoles - $ sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries + sudo cp -r prometheus-files/consoles /etc/prometheus + sudo cp -r prometheus-files/console_libraries /etc/prometheus + sudo chown -R prometheus:prometheus /etc/prometheus/consoles + sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries ``` + 5. Create Prometheus config file, define targets. To create and open up the config file: + ```shell - $ sudo nano /etc/prometheus/prometheus.yml + sudo nano /etc/prometheus/prometheus.yml ``` + Put the following content into the file: + ```yaml scrape_configs: - job_name: goshimmer_local @@ -171,15 +198,18 @@ Note: you have to have root privileges with your user to carry out the following # goshimmer prometheus plugin export - 127.0.0.1:9311 ``` + Save and exit the editor. 6. Change ownership of the config file. + ```shell - $ sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml + sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml ``` + 7. Create a Prometheus service file. ```shell - $ sudo nano /etc/systemd/system/prometheus.service + sudo nano /etc/systemd/system/prometheus.service ``` Copy the following content into the file: @@ -205,21 +235,25 @@ Note: you have to have root privileges with your user to carry out the following ``` 8. Reload `systemd` service to register the prometheus service. + ```shell - $ sudo systemctl daemon-reload - $ sudo systemctl start prometheus + sudo systemctl daemon-reload + sudo systemctl start prometheus ``` + 9. Check if the service is running. + ```shell - $ sudo systemctl status prometheus + sudo systemctl status prometheus ``` + 10. You can access the prometheus server at [localhost:9090](http://localhost:9090). 11. (Optional) Prometheus server is running, but observe that [localhost:9090/targets](http://localhost:9090/targets) shows the target being `DOWN`. Run GoShimmer with the configuration from the previous stage, and you will soon see the `goshimmer_local` target being `UP`. +1. When you want to stop the service, run: ```shell -$ sudo systemctl stop prometheus +sudo systemctl stop prometheus ``` Prometheus now collects metrics from your node, but we need to setup Grafana to visualize the collected data. @@ -234,10 +268,12 @@ Depending on where you install Grafana from, the configuration directories will 1. [Download Grafana](https://grafana.com/grafana/download) binary and extract it into a folder. For example: + ```shell - $ wget https://dl.grafana.com/oss/release/grafana-7.0.4.linux-amd64.tar.gz - $ tar -zxvf grafana-7.0.4.linux-amd64.tar.gz + wget https://dl.grafana.com/oss/release/grafana-7.0.4.linux-amd64.tar.gz + tar -zxvf grafana-7.0.4.linux-amd64.tar.gz ``` + 2. We will need couple files from the GoShimmer repository. Here we suppose, that you have the repository directory `goshimmer` on the same level as the extracted `grafana-7.0.4` directory: ``` @@ -261,16 +297,18 @@ Depending on where you install Grafana from, the configuration directories will We copy a couple configuration files from the repository into Grafana's directory: ```shell - $ cp -R goshimmer/tools/monitoring/grafana/dashboards/local_dashboard.json grafana-7.0.4/public/dashboards/ - $ cp goshimmer/tools/monitoring/grafana/provisioning/datasources/datasources.yaml grafana-7.0.4/conf/provisioning/datasources/datasources.yaml - $ cp goshimmer/tools/monitoring/grafana/provisioning/dashboards/dashboards.yaml grafana-7.0.4/conf/provisioning/dashboards/dashboards.yaml + cp -R goshimmer/tools/monitoring/grafana/dashboards/local_dashboard.json grafana-7.0.4/public/dashboards/ + cp goshimmer/tools/monitoring/grafana/provisioning/datasources/datasources.yaml grafana-7.0.4/conf/provisioning/datasources/datasources.yaml + cp goshimmer/tools/monitoring/grafana/provisioning/dashboards/dashboards.yaml grafana-7.0.4/conf/provisioning/dashboards/dashboards.yaml ``` 3. Run Grafana. + ```shell - $ cd grafana-7.0.4/bin - $ ./grafana-server + cd grafana-7.0.4/bin + ./grafana-server ``` + 4. Open Moitoring Dashboard at [localhost:3000](http://localhost:3000). Default login credentials are: @@ -291,22 +329,30 @@ then Grafana is configured to run as a system service without any modification. 1. Copy [datasource yaml config](https://github.com/iotaledger/goshimmer/blob/develop/tools/monitoring/grafana/provisioning/datasources/datasources.yaml) to `/etc/grafana`: (assuming you are at the root of the cloned GoShimmer repository) + ```shell - $ sudo cp tools/monitoring/grafana/provisioning/datasources/datasources.yaml /etc/grafana/provisioning/datasources + sudo cp tools/monitoring/grafana/provisioning/datasources/datasources.yaml /etc/grafana/provisioning/datasources ``` + 2. Copy [dashboard yaml config](https://github.com/iotaledger/goshimmer/blob/develop/tools/monitoring/grafana/provisioning/dashboards/dashboards.yaml) to `/etc/grafana`: + ```shell - $ sudo cp tools/monitoring/grafana/provisioning/dashboards/dashboards.yaml /etc/grafana/provisioning/dashboards + sudo cp tools/monitoring/grafana/provisioning/dashboards/dashboards.yaml /etc/grafana/provisioning/dashboards ``` + 3. Copy [GoShimmer Local Metrics](https://github.com/iotaledger/goshimmer/blob/develop/tools/monitoring/grafana/dashboards/local_dashboard.json) dashboard to `/var/lib/grafana/`: + ```shell - $ sudo cp -R tools/monitoring/grafana/dashboards /var/lib/grafana/ + sudo cp -R tools/monitoring/grafana/dashboards /var/lib/grafana/ ``` + 4. Reload daemon and start Grafana. + ```shell - $ sudo systemctl daemon-reload - $ sudo systemctl start grafana-server + sudo systemctl daemon-reload + sudo systemctl start grafana-server ``` + 5. Open Moitoring Dashboard at [localhost:3000](http://localhost:3000). Default login credentials are: diff --git a/iota/docs/goshimmer/docs/tutorials/setup.md b/iota/docs/goshimmer/docs/tutorials/setup.md index a9685d6ad69..f698165b93a 100644 --- a/iota/docs/goshimmer/docs/tutorials/setup.md +++ b/iota/docs/goshimmer/docs/tutorials/setup.md @@ -507,7 +507,7 @@ cp local_dashboard.json grafana/dashboards chmod -R 777 grafana ``` -#### Run GoShimmer with Prometheus and Grafana: +#### Run GoShimmer with Prometheus and Grafana ```shell docker compose up -d diff --git a/iota/docs/goshimmer/docs/tutorials/wallet_library.md b/iota/docs/goshimmer/docs/tutorials/wallet_library.md index a3bac02eb3e..3b2c3788408 100644 --- a/iota/docs/goshimmer/docs/tutorials/wallet_library.md +++ b/iota/docs/goshimmer/docs/tutorials/wallet_library.md @@ -38,6 +38,7 @@ The command line wallet and this tutorial are aimed at a developer audience, you 1. Download the latest cli-wallet for the system of your choice from the [GoShimmer GitHub Releases](https://github.com/iotaledger/goshimmer/releases) page. 2. If needed, make the downloaded binary executable. If you are using linux you can run: + ```shell chmod +x ``` @@ -285,7 +286,7 @@ date -d "+7 days" +%s Once you have a unix timestamp, you can execute the transfer by running: ```shell -$ ./cli-wallet send-funds -amount 500 -dest-addr 1E5Q82XTF5QGyC598br9oCj71cREyjD1CGUk2gmaJaFQt -lock-until 1621426409 +./cli-wallet send-funds -amount 500 -dest-addr 1E5Q82XTF5QGyC598br9oCj71cREyjD1CGUk2gmaJaFQt -lock-until 1621426409 ``` ### Conditional Sending diff --git a/iota/docs/hornet/docs/references/configuration.md b/iota/docs/hornet/docs/references/configuration.md index 05baca64c4a..d109e295d39 100644 --- a/iota/docs/hornet/docs/references/configuration.md +++ b/iota/docs/hornet/docs/references/configuration.md @@ -189,8 +189,8 @@ Example: | Name | Description | Type | | :------------------------ | :---------------------------------------------------- | :----- | -| [milestones](#Milestones) | Milestones based pruning | object | -| [size](#Size) | Database size based pruning | object | +| [milestones](#milestones) | Milestones based pruning | object | +| [size](#size) | Database size based pruning | object | | pruneReceipts | Whether to delete old receipts data from the database | bool | ### Milestones diff --git a/iota/docs/identity.rs/v0.5.0/docs/concepts/decentralized_identifiers/resolve.mdx b/iota/docs/identity.rs/v0.5.0/docs/concepts/decentralized_identifiers/resolve.mdx index 8de6f98889b..bc9e92d1887 100644 --- a/iota/docs/identity.rs/v0.5.0/docs/concepts/decentralized_identifiers/resolve.mdx +++ b/iota/docs/identity.rs/v0.5.0/docs/concepts/decentralized_identifiers/resolve.mdx @@ -117,7 +117,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/iota/docs/identity.rs/v0.5.0/docs/decentralized_identity.mdx b/iota/docs/identity.rs/v0.5.0/docs/decentralized_identity.mdx index 602b6546897..c6007a475b1 100644 --- a/iota/docs/identity.rs/v0.5.0/docs/decentralized_identity.mdx +++ b/iota/docs/identity.rs/v0.5.0/docs/decentralized_identity.mdx @@ -81,7 +81,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/iota/docs/identity.rs/v0.5.0/docs/libraries/wasm/api_reference.mdx b/iota/docs/identity.rs/v0.5.0/docs/libraries/wasm/api_reference.mdx index b49d8aec745..70f065d35d4 100644 --- a/iota/docs/identity.rs/v0.5.0/docs/libraries/wasm/api_reference.mdx +++ b/iota/docs/identity.rs/v0.5.0/docs/libraries/wasm/api_reference.mdx @@ -3660,7 +3660,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/iota/docs/identity.rs/v0.5.0/docs/libraries/wasm/getting_started.mdx b/iota/docs/identity.rs/v0.5.0/docs/libraries/wasm/getting_started.mdx index 0d0bcebec7b..0b4d46e6365 100644 --- a/iota/docs/identity.rs/v0.5.0/docs/libraries/wasm/getting_started.mdx +++ b/iota/docs/identity.rs/v0.5.0/docs/libraries/wasm/getting_started.mdx @@ -27,7 +27,7 @@ import Announcement from '../../../src/partials/_announcement.mdx'; ## [Low-Level 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, is stable and will have changelogs. @@ -120,7 +120,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`: @@ -146,7 +146,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/iota/docs/identity.rs/v0.5.0/docs/specs/didcomm/overview.mdx b/iota/docs/identity.rs/v0.5.0/docs/specs/didcomm/overview.mdx index 8c81f8ecfe1..8e4fcf0b7e7 100644 --- a/iota/docs/identity.rs/v0.5.0/docs/specs/didcomm/overview.mdx +++ b/iota/docs/identity.rs/v0.5.0/docs/specs/didcomm/overview.mdx @@ -32,7 +32,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/iota/docs/identity.rs/v0.5.0/docs/specs/didcomm/protocols/connection.mdx b/iota/docs/identity.rs/v0.5.0/docs/specs/didcomm/protocols/connection.mdx index aa00e7a546f..3bf62b2b44d 100644 --- a/iota/docs/identity.rs/v0.5.0/docs/specs/didcomm/protocols/connection.mdx +++ b/iota/docs/identity.rs/v0.5.0/docs/specs/didcomm/protocols/connection.mdx @@ -200,7 +200,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/iota/docs/identity.rs/v0.5.0/docs/tutorials/validate_university_degree.mdx b/iota/docs/identity.rs/v0.5.0/docs/tutorials/validate_university_degree.mdx index c4bb2f2e5a0..ba2ec507b39 100644 --- a/iota/docs/identity.rs/v0.5.0/docs/tutorials/validate_university_degree.mdx +++ b/iota/docs/identity.rs/v0.5.0/docs/tutorials/validate_university_degree.mdx @@ -66,7 +66,7 @@ For professional IOTA implementations we strongly recommend using our key manage ::: -### Example Weakhold file: +### Example Weakhold file ```json { @@ -91,7 +91,7 @@ For professional IOTA implementations we strongly recommend using our key manage In this process, you will complete the different steps from the perspective of one of the mentioned roles above: -### 1. **Holder**: Create a DID. +### 1. **Holder**: Create a DID The first thing you will need to do in this tutorial is to create a DID(Decentralized Identifier) Document for Alice. @@ -164,7 +164,7 @@ addVerificationMethod( ); ``` -###5. **Holder**: Set Up a Document +### 5. **Holder**: Set Up a Document You should set up a document representing Alice's degree, containing her DID which will later be signed by the **issuer**. @@ -251,7 +251,7 @@ let signedVpPath = './signedCredentials/offlineVerifiablePresentation.json'; checkVerifiablePresentation(signedVpPath); ``` -### 10. **Issuer**: Revoke the Verification for Alice's Credential. +### 10. **Issuer**: Revoke the Verification for Alice's Credential Unfortunately the University found out, that Alice had cheated on her final exam. Therefore, the University wants to revoke the verification of Alice's credential. @@ -274,7 +274,7 @@ removeVerificationMethod( ); ``` -#### 2. Only revoke the one Merkle key used for the signature. +#### 2. Only revoke the one Merkle key used for the signature - [removeMerkleKey.js](https://github.com/adrian-grassl/iota-identity-tutorial/blob/master/removeMerkleKey.js) diff --git a/iota/docs/identity.rs/v0.5.0/docs/workflow.mdx b/iota/docs/identity.rs/v0.5.0/docs/workflow.mdx index f1b16ce7f8e..2f78ca58a99 100644 --- a/iota/docs/identity.rs/v0.5.0/docs/workflow.mdx +++ b/iota/docs/identity.rs/v0.5.0/docs/workflow.mdx @@ -20,7 +20,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 @@ -63,7 +63,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 @@ -75,11 +75,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: @@ -95,17 +95,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 @@ -115,7 +115,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 @@ -137,7 +137,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. @@ -153,9 +153,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. @@ -166,13 +166,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/iota/docs/identity.rs/v0.6.0/docs/concepts/decentralized_identifiers/resolve.mdx b/iota/docs/identity.rs/v0.6.0/docs/concepts/decentralized_identifiers/resolve.mdx index 5968fb77465..1a1ce56102b 100644 --- a/iota/docs/identity.rs/v0.6.0/docs/concepts/decentralized_identifiers/resolve.mdx +++ b/iota/docs/identity.rs/v0.6.0/docs/concepts/decentralized_identifiers/resolve.mdx @@ -116,7 +116,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/iota/docs/identity.rs/v0.6.0/docs/decentralized_identity.mdx b/iota/docs/identity.rs/v0.6.0/docs/decentralized_identity.mdx index 602b6546897..c6007a475b1 100644 --- a/iota/docs/identity.rs/v0.6.0/docs/decentralized_identity.mdx +++ b/iota/docs/identity.rs/v0.6.0/docs/decentralized_identity.mdx @@ -81,7 +81,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/iota/docs/identity.rs/v0.6.0/docs/libraries/wasm/api_reference.mdx b/iota/docs/identity.rs/v0.6.0/docs/libraries/wasm/api_reference.mdx index 708eeae20d2..7a5cb28cd23 100644 --- a/iota/docs/identity.rs/v0.6.0/docs/libraries/wasm/api_reference.mdx +++ b/iota/docs/identity.rs/v0.6.0/docs/libraries/wasm/api_reference.mdx @@ -4385,7 +4385,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/iota/docs/identity.rs/v0.6.0/docs/libraries/wasm/getting_started.mdx b/iota/docs/identity.rs/v0.6.0/docs/libraries/wasm/getting_started.mdx index 112e9cbb806..a4960329066 100644 --- a/iota/docs/identity.rs/v0.6.0/docs/libraries/wasm/getting_started.mdx +++ b/iota/docs/identity.rs/v0.6.0/docs/libraries/wasm/getting_started.mdx @@ -27,7 +27,7 @@ import Announcement from '../../../src/partials/_announcement.mdx'; ## [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. @@ -120,7 +120,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`: @@ -146,7 +146,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/iota/docs/identity.rs/v0.6.0/docs/specs/didcomm/overview.mdx b/iota/docs/identity.rs/v0.6.0/docs/specs/didcomm/overview.mdx index e03d02200d5..436a2aa08e5 100644 --- a/iota/docs/identity.rs/v0.6.0/docs/specs/didcomm/overview.mdx +++ b/iota/docs/identity.rs/v0.6.0/docs/specs/didcomm/overview.mdx @@ -32,6 +32,7 @@ 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). ## Versioning diff --git a/iota/docs/identity.rs/v0.6.0/docs/specs/didcomm/protocols/connection.mdx b/iota/docs/identity.rs/v0.6.0/docs/specs/didcomm/protocols/connection.mdx index aa00e7a546f..3bf62b2b44d 100644 --- a/iota/docs/identity.rs/v0.6.0/docs/specs/didcomm/protocols/connection.mdx +++ b/iota/docs/identity.rs/v0.6.0/docs/specs/didcomm/protocols/connection.mdx @@ -200,7 +200,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/iota/docs/identity.rs/v0.6.0/docs/workflow.mdx b/iota/docs/identity.rs/v0.6.0/docs/workflow.mdx index f1b16ce7f8e..2f78ca58a99 100644 --- a/iota/docs/identity.rs/v0.6.0/docs/workflow.mdx +++ b/iota/docs/identity.rs/v0.6.0/docs/workflow.mdx @@ -20,7 +20,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 @@ -63,7 +63,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 @@ -75,11 +75,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: @@ -95,17 +95,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 @@ -115,7 +115,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 @@ -137,7 +137,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. @@ -153,9 +153,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. @@ -166,13 +166,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/iota/docs/integration-services/docs/explanations/services/SSI-bridge/use-cases.md b/iota/docs/integration-services/docs/explanations/services/SSI-bridge/use-cases.md index 2ecfdfc7c6d..607217670f8 100644 --- a/iota/docs/integration-services/docs/explanations/services/SSI-bridge/use-cases.md +++ b/iota/docs/integration-services/docs/explanations/services/SSI-bridge/use-cases.md @@ -55,7 +55,7 @@ customer and avoid threats and frauds in the distribution chain. 4. The customer receives the product delivery and presents the credential in a QR code to the courier scanner. 5. The courier acquires the credential and uses the Ecommerce-SSI Bridge to verify its authenticity. The delivery is safely handed over to the right customer. -6. (optional) The customer acquires the courier’s scanner credential (see [ Delivery Company Identity and Scanners Verification](#delivery-company-identity-and-scanners-verification)) +6. (optional) The customer acquires the courier’s scanner credential (see [Delivery Company Identity and Scanners Verification](#delivery-company-identity-and-scanners-verification)) and uses the Ecommerce-SSI Bridge to verify that it belongs to an authorized delivery company assuring the customer knows the delivery is legitimate. diff --git a/iota/docs/integration-services/docs/getting_started/installation/java/local_setup.md b/iota/docs/integration-services/docs/getting_started/installation/java/local_setup.md index 30d3f814b26..ca67f4225fe 100644 --- a/iota/docs/integration-services/docs/getting_started/installation/java/local_setup.md +++ b/iota/docs/integration-services/docs/getting_started/installation/java/local_setup.md @@ -59,12 +59,14 @@ implementation group: 'net.gradbase', name: 'iota.is.sdk', version: '0.0.1' Please set up the following files in order to run the code locally: - `env.properties` - with the following structure: + ``` api-key=XXXXXXX api-version=vX.X api-url=XXXXXXX identity-file=adminIdentity.json ``` + - `adminIdentity.json` - will contain the admin identity object (json file with elements `doc` and `key`) You are now ready to use the JAR and access the classes. Please remember to keep the `env.properties` _in the same folder as the JAR_. diff --git a/iota/docs/integration-services/docs/getting_started/installation/kubernetes/expose_apis.md b/iota/docs/integration-services/docs/getting_started/installation/kubernetes/expose_apis.md index 5d6cde81ddb..239d868c95a 100644 --- a/iota/docs/integration-services/docs/getting_started/installation/kubernetes/expose_apis.md +++ b/iota/docs/integration-services/docs/getting_started/installation/kubernetes/expose_apis.md @@ -50,7 +50,7 @@ curl -H 'Host: ensuresec.solutions.iota.org' http://192.168.49.2/info You can avoid using the `Host` header by mapping the host/IP association in your `/etc/hosts`. In that case you could use directly `http://ensuresec.solutions.iota.org/info` in your default browser. -If you want to change the domain name, please visit the[ configuration section](configuration.md) for more information. +If you want to change the domain name, please visit the [configuration section](configuration.md) for more information. ## Port Forwarding diff --git a/iota/docs/integration-services/docs/references/audit_trail_gw_api_reference.md b/iota/docs/integration-services/docs/references/audit_trail_gw_api_reference.md index a8ec7942165..d080b24e7cf 100644 --- a/iota/docs/integration-services/docs/references/audit_trail_gw_api_reference.md +++ b/iota/docs/integration-services/docs/references/audit_trail_gw_api_reference.md @@ -19,11 +19,11 @@ This is the API documentation for the Audit Trail Gateway of the [Integration Se #### GET -##### Summary: +##### Summary Search for a channel -##### Description: +##### Description Search for a channel. A client can search for a channel which it is interested in. @@ -63,11 +63,11 @@ Search for a channel. A client can search for a channel which it is interested i #### GET -##### Summary: +##### Summary Get information about a channel -##### Description: +##### Description Get information about a channel with address channel-address. @@ -87,11 +87,11 @@ Get information about a channel with address channel-address. #### DELETE -##### Summary: +##### Summary Delete information of a channel -##### Description: +##### Description Delete information of a channel with address channel-address. The author of a channel can delete its entry in the database. In this case all subscriptions will be deleted and the channel won’t be found in the system anymore. The data & channel won’t be deleted from the IOTA Tangle since its data is immutable on the tangle! @@ -120,11 +120,11 @@ Delete information of a channel with address channel-address. The author of a ch #### POST -##### Summary: +##### Summary Add an existing channel into the database -##### Description: +##### Description Add an existing channel into the database. Clients are able to add existing channels into the database so others can subscribe to them. This will be automatically called when a channel will be created. @@ -146,11 +146,11 @@ Add an existing channel into the database. Clients are able to add existing chan #### PUT -##### Summary: +##### Summary Update channel information -##### Description: +##### Description Update channel information. The author of a channel can update topics of a channel. @@ -174,11 +174,11 @@ Update channel information. The author of a channel can update topics of a chann #### POST -##### Summary: +##### Summary Create a new channel -##### Description: +##### Description Create a new channel. An author can create a new channel with specific topics where other clients can subscribe to. @@ -201,11 +201,11 @@ Create a new channel. An author can create a new channel with specific topics wh #### POST -##### Summary: +##### Summary Write data to a channel -##### Description: +##### Description Write data to a channel with address channel address. Write permission is mandatory. The type and metadata fields are not encrypted to have a possibility to search for events. The payload is stored encrypted for encrypted channels. @@ -233,11 +233,11 @@ Write data to a channel with address channel address. Write permission is mandat #### GET -##### Summary: +##### Summary Get data from the channel -##### Description: +##### Description Get data from the channel with address channel address. The first possible message a subscriber can receive is the time the subscription got approved all messages before are not received. Read permission is mandatory. @@ -272,11 +272,11 @@ Get data from the channel with address channel address. The first possible messa #### GET -##### Summary: +##### Summary Get the history of a channel. -##### Description: +##### Description Get all data of a channel using a shared key (in case of encrypted channels). Mainly used from auditors to evaluate a log stream. @@ -299,11 +299,11 @@ Get all data of a channel using a shared key (in case of encrypted channels). Ma #### POST -##### Summary: +##### Summary Validates channel data by comparing the log of each link with the data on the tangle. -##### Description: +##### Description Validates data of a channel. @@ -333,11 +333,11 @@ Validates data of a channel. #### POST -##### Summary: +##### Summary Re import the data from the tangle into the database. -##### Description: +##### Description The user can decide to re-import the data from the Tangle into the database. A reason for it could be a malicious state of the data. @@ -367,11 +367,11 @@ The user can decide to re-import the data from the Tangle into the database. A r #### GET -##### Summary: +##### Summary Get information about the server -##### Description: +##### Description Get information about the server like commitHash, server identity id and api version @@ -386,11 +386,11 @@ Get information about the server like commitHash, server identity id and api ver #### GET -##### Summary: +##### Summary Get a subscription state by identity id. -##### Description: +##### Description Get a subscription state of a channel by identity id. @@ -417,11 +417,11 @@ Get a subscription state of a channel by identity id. #### PUT -##### Summary: +##### Summary Updates an existing subscription -##### Description: +##### Description Updates an existing subscription @@ -452,11 +452,11 @@ Updates an existing subscription #### GET -##### Summary: +##### Summary Get all subscriptions of a channel. -##### Description: +##### Description Get all subscriptions of a channel. Use the is-authorized query parameter to filter for authorized subscriptions. @@ -486,11 +486,11 @@ Get all subscriptions of a channel. Use the is-authorized query parameter to fil #### GET -##### Summary: +##### Summary Get a subscription by identity id. -##### Description: +##### Description Get a subscription of a channel by identity id. @@ -518,11 +518,11 @@ Get a subscription of a channel by identity id. #### POST -##### Summary: +##### Summary Adds an existing subscription -##### Description: +##### Description Adds an existing subscription (e.g. the subscription was not created with the api but locally.) @@ -551,11 +551,11 @@ Adds an existing subscription (e.g. the subscription was not created with the ap #### PUT -##### Summary: +##### Summary Updates an existing subscription -##### Description: +##### Description Updates an existing subscription @@ -585,11 +585,11 @@ Updates an existing subscription #### DELETE -##### Summary: +##### Summary Deletes subscription -##### Description: +##### Description Deletes an existing subscription @@ -621,11 +621,11 @@ Deletes an existing subscription #### POST -##### Summary: +##### Summary Request subscription to a channel -##### Description: +##### Description Request subscription to a channel with address channel-address. A client can request a subscription to a channel which it then is able to read/write from. @@ -656,11 +656,11 @@ Request subscription to a channel with address channel-address. A client can req #### POST -##### Summary: +##### Summary Authorize a subscription to a channel -##### Description: +##### Description Authorize a subscription to a channel with address channel-address. The author of a channel can authorize a subscriber to read/write from a channel. Eventually after verifying its identity (using the SSI Bridge). @@ -690,11 +690,11 @@ Authorize a subscription to a channel with address channel-address. The author o #### POST -##### Summary: +##### Summary Revoke subscription to a channel. -##### Description: +##### Description Revoke subscription to a channel. Only the author of a channel can revoke a subscription from a channel. diff --git a/iota/docs/integration-services/docs/references/ssi_bridge_api_reference.md b/iota/docs/integration-services/docs/references/ssi_bridge_api_reference.md index 0c6978268d0..bfc443112bf 100644 --- a/iota/docs/integration-services/docs/references/ssi_bridge_api_reference.md +++ b/iota/docs/integration-services/docs/references/ssi_bridge_api_reference.md @@ -19,11 +19,11 @@ This is the API documentation for the SSI Bridge of the [Integration Services](h #### GET -##### Summary: +##### Summary Request a nonce which must be signed by the private key -##### Description: +##### Description Request a nonce which must be signed by the private key of the client and send it to /prove-ownership/{identity-id} endpoint via POST. This allows a user to prove ownership of its identity public key. @@ -43,11 +43,11 @@ Request a nonce which must be signed by the private key of the client and send i #### POST -##### Summary: +##### Summary Get an authentication token by signing a nonce -##### Description: +##### Description Get an authentication token by signing a nonce using the private key. If signature is verified, a JWT string will be returned in the response. The nonce can be received from GET /prove-ownership/{identity-id} endpoint. The JWT is used for any future API interaction. @@ -71,11 +71,11 @@ Get an authentication token by signing a nonce using the private key. If signatu #### POST -##### Summary: +##### Summary Verify a signed jwt -##### Description: +##### Description Check if the jwt was signed by the Integration Service. @@ -93,11 +93,11 @@ Check if the jwt was signed by the Integration Service. #### POST -##### Summary: +##### Summary Create a new decentralized digital identity (DID) -##### Description: +##### Description Create a new decentralized digital identity (DID). Identity DID document is signed and published to the ledger (IOTA Tangle). A digital identity can represent an individual, an organization or an object. The privateAuthKey controlling the identity is returned. It is recommended to securely (encrypt) store the privateAuthKey locally, since it is not stored on the APIs Bridge. @@ -120,11 +120,11 @@ Create a new decentralized digital identity (DID). Identity DID document is sign #### POST -##### Summary: +##### Summary Create a new keypair. -##### Description: +##### Description Create a new keypair. @@ -153,11 +153,11 @@ Create a new keypair. #### GET -##### Summary: +##### Summary Search for identities -##### Description: +##### Description Search for identities in the system and returns a list of existing identities. @@ -192,11 +192,11 @@ Search for identities in the system and returns a list of existing identities. #### GET -##### Summary: +##### Summary Get information about a specific identity -##### Description: +##### Description Get information (including attached credentials) about a specific identity using the identity-id (DID identifier). @@ -216,11 +216,11 @@ Get information (including attached credentials) about a specific identity using #### DELETE -##### Summary: +##### Summary Removes an identity from the Bridge -##### Description: +##### Description Removes an identity from the Bridge. An identity can only delete itself and is not able to delete other identities. Administrators are able to remove other identities. The identity cannot be removed from the immutable IOTA Tangle but only at the Bridge. Also the identity credentials will remain and the identity is still able to interact with other bridges. @@ -251,11 +251,11 @@ Removes an identity from the Bridge. An identity can only delete itself and is n #### POST -##### Summary: +##### Summary Register an existing identity into the Bridge -##### Description: +##### Description Register an existing identity into the Bridge. This can be used if the identity already exists or it was only created locally. Registering an identity in the Bridge makes it possible to search for it by using some of the identity attributes, i.e., the username. @@ -269,11 +269,11 @@ Register an existing identity into the Bridge. This can be used if the identity #### PUT -##### Summary: +##### Summary Update claim of a registered identity -##### Description: +##### Description Update claim of a registered identity. @@ -296,11 +296,11 @@ Update claim of a registered identity. #### GET -##### Summary: +##### Summary Get information about the server -##### Description: +##### Description Get information about the server like commitHash, server identity id and api version @@ -315,11 +315,11 @@ Get information about the server like commitHash, server identity id and api ver #### GET -##### Summary: +##### Summary Get the latest version of an identity document (DID) -##### Description: +##### Description Get the latest version of an identity document (DID) from the IOTA Tangle. @@ -341,11 +341,11 @@ Get the latest version of an identity document (DID) from the IOTA Tangle. #### POST -##### Summary: +##### Summary Adds Trusted Root identity identifiers (DIDs) -##### Description: +##### Description Adds Trusted Root identity identifiers (DIDs). Trusted roots are DIDs of identities which are trusted by the Bridge. This identity DIDs can be DIDs of other organizations. By adding them to the list Trusted Roots their Verifiable Credentials (VCs) are automatically trusted when checking at the Bridge. @@ -366,11 +366,11 @@ Adds Trusted Root identity identifiers (DIDs). Trusted roots are DIDs of identit #### GET -##### Summary: +##### Summary Returns a list of Trusted Root identity identifiers (DIDs) -##### Description: +##### Description Returns a list of Trusted Root identity identifiers (DIDs). Trusted roots are DIDs of identities which are trusted by the Bridge. This identity DIDs can be DIDs of other organizations. By adding them to the list Trusted Roots their Verifiable Credentials (VCs) are automatically trusted when checking at the Bridge. @@ -386,11 +386,11 @@ Returns a list of Trusted Root identity identifiers (DIDs). Trusted roots are DI #### DELETE -##### Summary: +##### Summary Remove Trusted Root identity identifiers (DIDs) -##### Description: +##### Description Remove Trusted Root identity identifiers (DIDs). Trusted roots are DIDs of identities which are trusted by the Bridge. This identity DIDs can be DIDs of other organizations. By adding them to the list Trusted Roots their Verifiable Credentials (VCs) are automatically trusted when checking at the Bridge. @@ -419,11 +419,11 @@ Remove Trusted Root identity identifiers (DIDs). Trusted roots are DIDs of ident #### POST -##### Summary: +##### Summary Verify the authenticity of an identity and issue a credential -##### Description: +##### Description Verify the authenticity of an identity (of an individual, organization or object) and issue a credential stating the identity verification status. Only previously verified identities (based on a network of trust) with assigned privileges can verify other identities. Having a verified identity provides the opportunity for other identities to identify and verify a the entity they interact to. @@ -446,11 +446,11 @@ Verify the authenticity of an identity (of an individual, organization or object #### POST -##### Summary: +##### Summary Check the verifiable credential of an identity -##### Description: +##### Description Check the verifiable credential of an identity. Validates the signed verifiable credential against the Issuer information stored onto the IOTA Tangle and checks if the issuer identity (DID) contained in the credential is from a trusted root. @@ -466,11 +466,11 @@ Check the verifiable credential of an identity. Validates the signed verifiable #### POST -##### Summary: +##### Summary Check the verifiable presentation of an identity -##### Description: +##### Description Check the verifiable presentation of an identity. @@ -486,11 +486,11 @@ Check the verifiable presentation of an identity. #### POST -##### Summary: +##### Summary Revoke one specific verifiable credential of an identity -##### Description: +##### Description Revoke one specific verifiable credential of an identity. In the case of individual and organization identities the reason could be that the user has left the organization. Only organization admins (with verified identities) or the identity owner itself can do that. diff --git a/iota/docs/introduction-docs/docs/how_tos/migration/snapshot_validation_bootstrapping.md b/iota/docs/introduction-docs/docs/how_tos/migration/snapshot_validation_bootstrapping.md index 0734e519569..234263cc80b 100644 --- a/iota/docs/introduction-docs/docs/how_tos/migration/snapshot_validation_bootstrapping.md +++ b/iota/docs/introduction-docs/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/iota/docs/iota-2.0-research-specifications/2.3_standard_payloads_layout.md b/iota/docs/iota-2.0-research-specifications/2.3_standard_payloads_layout.md index 8a49017aa34..4a11ed062db 100644 --- a/iota/docs/iota-2.0-research-specifications/2.3_standard_payloads_layout.md +++ b/iota/docs/iota-2.0-research-specifications/2.3_standard_payloads_layout.md @@ -684,7 +684,7 @@ The Table 2.3.7 describes the dRNG `Beacon` and `CollectiveBeacon` payload's ser TypeCollectiveBeacon
Defines payload data for CollectiveBeacon payload type. -
+ diff --git a/iota/docs/iota-2.0-research-specifications/3.4_neighbor_selection.md b/iota/docs/iota-2.0-research-specifications/3.4_neighbor_selection.md index 20243dca362..edb9366bd5a 100644 --- a/iota/docs/iota-2.0-research-specifications/3.4_neighbor_selection.md +++ b/iota/docs/iota-2.0-research-specifications/3.4_neighbor_selection.md @@ -62,7 +62,7 @@ The public salt must satisfy the following requirements: 2. Salts _must_ be chosen in a non-arbitrary way: if adversaries may choose their salt, they could manufacture malicious requests to any node. This section proposes to set the public salts using hash chains, while private salts can be randomly generated on the fly. -The nodes shall create a hash chain _ζ = {ζ_0, ζ_1, ..., ζ_m}_ where next chain element is created by hashing the previous one: _ζ\_{i+1} = hash(ζ_i)_. +The nodes shall create a hash chain `ζ = {ζ_0, ζ_1, ..., ζ_m}` where next chain element is created by hashing the previous one: `ζ\_{i+1} = hash(ζ_i)`. Then nodes shall make public the last element _ζ_m_ of their hash chain as their initial salt. Every future salt is the next element of the hash chain. Under this proposal, property 1 above holds because cryptographic hash functions are virtually irreversible. Property 2 holds fairly well: an adversary can only choose one element of their hash chain. Indeed, an adversary can pick a number to be their 300th salt, hash it 300 times, and post that as their initial salt. However, an adversary can only do this for one round since hash functions have effectively random outputs. Thus an adversary is limited in their ability to choose their own salt. @@ -115,9 +115,9 @@ The maximum number of neighbors is a parameter of the gossip protocol. This sect The operations involved during neighbor selection are listed in the following: -1. Get an up-to-date list of verified and known peers from the _Peer Discovery_ protocol. -2. Use `manaRank` to filter the previous list to obtain a list of peers to be potential neighbors. -3. Use the score function to request/accept neighbors. +1. Get an up-to-date list of verified and known peers from the _Peer Discovery_ protocol. +2. Use `manaRank` to filter the previous list to obtain a list of peers to be potential neighbors. +3. Use the score function to request/accept neighbors. The score between two nodes is measured through the score function _s_, defined by: diff --git a/iota/docs/iota-2.0-research-specifications/4.7_markers.md b/iota/docs/iota-2.0-research-specifications/4.7_markers.md index 72950b00e15..34d691500cf 100644 --- a/iota/docs/iota-2.0-research-specifications/4.7_markers.md +++ b/iota/docs/iota-2.0-research-specifications/4.7_markers.md @@ -183,22 +183,22 @@ For each message in the Tangle, the marker tool _shall_ maintain metadata that p - + - + - + - +
Name
FutureMarkers map[SID]MIDA list of the closest markers from different marker-sequences in the future cone of the message.A list of the closest markers from different marker-sequences in the future cone of the message.
MarkerBranchID BIDThe branch ID to which the marker is mapped, or nil if the message is no marker.The branch ID to which the marker is mapped, or nil if the message is no marker.
PayloadBranchID BIDThe branch ID to which the Payload is mapped in case it is a conflict, or nil otherwise.The branch ID to which the Payload is mapped in case it is a conflict, or nil otherwise.
IndividualBranchID BIDThe branch ID if there is need for mapping the message individually to a branch ID, or nil otherwise.The branch ID if there is need for mapping the message individually to a branch ID, or nil otherwise.
diff --git a/iota/docs/iota-2.0-research-specifications/5.3_mana.md b/iota/docs/iota-2.0-research-specifications/5.3_mana.md index c48f0e161d7..caca8904bce 100644 --- a/iota/docs/iota-2.0-research-specifications/5.3_mana.md +++ b/iota/docs/iota-2.0-research-specifications/5.3_mana.md @@ -107,6 +107,7 @@ Suppose that the last reference time is $t$ and the transaction timestamp is $t- - _b_) **Pledging and revoking cMana**. If the base cMana balance of node $i$ (before we added this transaction) was $\text{Old\_Base\_cMana}(\text{Node}_i)$ and the new base cMana balance (after the addition of this transaction) is $\text{Base\_cMana}(\text{Node}_i)$, then we update the cMana vector adding to all nodes' entry the term: $$ + (1-e^{-\alpha s})[\text{Base\_cMana}(\text{Node}_i)-\text{Old\_Base\_cMana}(\text{Node}_i)] $$ @@ -249,7 +250,7 @@ Suppose that the last reference time is $t-s$ and the transaction timestamp is $ where $\beta$ is the moving average parameter for the aMana and $\gamma$ is the base aMana decay factor. Notice that, here, the value of $\text{Base\_aMana(Node}_i)$ used is the one already updated. -#### Updating the aMana to a time larger than the last reference time without any new aMana pledging. +#### Updating the aMana to a time larger than the last reference time without any new aMana pledging Suppose that the last reference time is $t-s$ and new one is $t$. The update must be done in two steps, always in the order specified below: diff --git a/iota/docs/iota-2.0-research-specifications/6.2_opinion_setting.md b/iota/docs/iota-2.0-research-specifications/6.2_opinion_setting.md index 52e268eb007..59042691350 100644 --- a/iota/docs/iota-2.0-research-specifications/6.2_opinion_setting.md +++ b/iota/docs/iota-2.0-research-specifications/6.2_opinion_setting.md @@ -100,7 +100,7 @@ Recall that the `arrivalTime.messageID` is the time that the message was receive The initial opinion is set based on the question "did the transaction arrive before `currentTime - W`?". The level of knowledge is then set by the margin as a factor of the delay time. Specifically, under the assumption that all messages are delivered to all nodes within time `DLARGE` after the arrive (with high probability), then: - If `|arrivalTime +W - currentTime | < DLARGE`, then the node can make any conclusions about the arrival times of the message, and hence it has only level of knowledge 1. -- If one node has `|arrivalTime +W - currentTime | >= DLARGE `, then all nodes must have the same opinion, and hence that node has level of knowledge at least 2. +- If one node has `|arrivalTime +W - currentTime | >= DLARGE`, then all nodes must have the same opinion, and hence that node has level of knowledge at least 2. - If one node has `|arrivalTime +W - currentTime | >= 2*DLARGE`, then all nodes must have `|arrivalTime +W - currentTime | => DLARGE` guaranteeing level of knowledge 3. ![](https://i.imgur.com/a5or78c.png) diff --git a/iota/docs/iota-2.0-research-specifications/6.3_fast_probabilistic_consensus.md b/iota/docs/iota-2.0-research-specifications/6.3_fast_probabilistic_consensus.md index 4a0ca0fbaf1..72aa0e2d365 100644 --- a/iota/docs/iota-2.0-research-specifications/6.3_fast_probabilistic_consensus.md +++ b/iota/docs/iota-2.0-research-specifications/6.3_fast_probabilistic_consensus.md @@ -74,7 +74,7 @@ The proposed values of the parameters are (Table 6.3.2): | `ENDING_THRESHOLD` | 0.50 | | `DRNG_WAITING_TIME` | 0.20 | | `MAX_ROUND` | 100 | -| ` QUERY_SIZE` | 21 | +| `QUERY_SIZE` | 21 | | `ROUND_LENGTH` | 10 | | `TIME_OUT` | 6.5 | | `MIN_MANA_PROPORTION` | 0.50 | diff --git a/iota/docs/iota.rs/docs/libraries/java/examples/_09_transaction.mdx b/iota/docs/iota.rs/docs/libraries/java/examples/_09_transaction.mdx index 3c0980e3048..39373a07c98 100644 --- a/iota/docs/iota.rs/docs/libraries/java/examples/_09_transaction.mdx +++ b/iota/docs/iota.rs/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/iota/docs/iota.rs/docs/libraries/nodejs/api_reference.md b/iota/docs/iota.rs/docs/libraries/nodejs/api_reference.md index 4b67b1f1c0a..faccda711bb 100644 --- a/iota/docs/iota.rs/docs/libraries/nodejs/api_reference.md +++ b/iota/docs/iota.rs/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/iota/docs/iota.rs/docs/libraries/python/api_reference.md b/iota/docs/iota.rs/docs/libraries/python/api_reference.md index 39d32198b39..5b65a636d65 100644 --- a/iota/docs/iota.rs/docs/libraries/python/api_reference.md +++ b/iota/docs/iota.rs/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/iota/docs/iota.rs/docs/libraries/python/examples/_04_get_balance.mdx b/iota/docs/iota.rs/docs/libraries/python/examples/_04_get_balance.mdx index 479298051ae..b4b0b1fad3f 100644 --- a/iota/docs/iota.rs/docs/libraries/python/examples/_04_get_balance.mdx +++ b/iota/docs/iota.rs/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/iota/docs/iota.rs/docs/libraries/rust/examples/_01_get_info.mdx b/iota/docs/iota.rs/docs/libraries/rust/examples/_01_get_info.mdx index f5570ea1a07..7215e501b3c 100644 --- a/iota/docs/iota.rs/docs/libraries/rust/examples/_01_get_info.mdx +++ b/iota/docs/iota.rs/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/iota/docs/iota.rs/docs/libraries/rust/examples/_04_get_balance.mdx b/iota/docs/iota.rs/docs/libraries/rust/examples/_04_get_balance.mdx index c7d9ca992e3..58910d0b590 100644 --- a/iota/docs/iota.rs/docs/libraries/rust/examples/_04_get_balance.mdx +++ b/iota/docs/iota.rs/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/iota/docs/iota.rs/docs/libraries/wasm/examples/_03_generate_addresses.mdx b/iota/docs/iota.rs/docs/libraries/wasm/examples/_03_generate_addresses.mdx index d4112445cb0..8e8f2f0b0ed 100644 --- a/iota/docs/iota.rs/docs/libraries/wasm/examples/_03_generate_addresses.mdx +++ b/iota/docs/iota.rs/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/iota/docs/iota.rs/docs/specs.mdx b/iota/docs/iota.rs/docs/specs.mdx index 79eff65965f..9f8cb72c26f 100644 --- a/iota/docs/iota.rs/docs/specs.mdx +++ b/iota/docs/iota.rs/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/iota/docs/stronghold.rs/docs/reference/specs/engineering.md b/iota/docs/stronghold.rs/docs/reference/specs/engineering.md index 6d71bf6f555..ea7f2c8e6bc 100644 --- a/iota/docs/stronghold.rs/docs/reference/specs/engineering.md +++ b/iota/docs/stronghold.rs/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/iota/docs/stronghold.rs/docs/reference/specs/requirements.md b/iota/docs/stronghold.rs/docs/reference/specs/requirements.md index ee507aa6d24..ba30c9a5e28 100644 --- a/iota/docs/stronghold.rs/docs/reference/specs/requirements.md +++ b/iota/docs/stronghold.rs/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 - (1-e^{-\alpha s})[\text{Base\_cMana}(\text{Node}_i)-\text{Old\_Base\_cMana}(\text{Node}_i)] $$ @@ -249,7 +250,7 @@ Suppose that the last reference time is $t-s$ and the transaction timestamp is $ where $\beta$ is the moving average parameter for the aMana and $\gamma$ is the base aMana decay factor. Notice that, here, the value of $\text{Base\_aMana(Node}_i)$ used is the one already updated. -#### Updating the aMana to a time larger than the last reference time without any new aMana pledging. +#### Updating the aMana to a time larger than the last reference time without any new aMana pledging Suppose that the last reference time is $t-s$ and new one is $t$. The update must be done in two steps, always in the order specified below: diff --git a/next/docs/iota-2.0-research-specifications/6.2_opinion_setting.md b/next/docs/iota-2.0-research-specifications/6.2_opinion_setting.md index 52e268eb007..59042691350 100644 --- a/next/docs/iota-2.0-research-specifications/6.2_opinion_setting.md +++ b/next/docs/iota-2.0-research-specifications/6.2_opinion_setting.md @@ -100,7 +100,7 @@ Recall that the `arrivalTime.messageID` is the time that the message was receive The initial opinion is set based on the question "did the transaction arrive before `currentTime - W`?". The level of knowledge is then set by the margin as a factor of the delay time. Specifically, under the assumption that all messages are delivered to all nodes within time `DLARGE` after the arrive (with high probability), then: - If `|arrivalTime +W - currentTime | < DLARGE`, then the node can make any conclusions about the arrival times of the message, and hence it has only level of knowledge 1. -- If one node has `|arrivalTime +W - currentTime | >= DLARGE `, then all nodes must have the same opinion, and hence that node has level of knowledge at least 2. +- If one node has `|arrivalTime +W - currentTime | >= DLARGE`, then all nodes must have the same opinion, and hence that node has level of knowledge at least 2. - If one node has `|arrivalTime +W - currentTime | >= 2*DLARGE`, then all nodes must have `|arrivalTime +W - currentTime | => DLARGE` guaranteeing level of knowledge 3. ![](https://i.imgur.com/a5or78c.png) diff --git a/next/docs/iota-2.0-research-specifications/6.3_fast_probabilistic_consensus.md b/next/docs/iota-2.0-research-specifications/6.3_fast_probabilistic_consensus.md index 4a0ca0fbaf1..72aa0e2d365 100644 --- a/next/docs/iota-2.0-research-specifications/6.3_fast_probabilistic_consensus.md +++ b/next/docs/iota-2.0-research-specifications/6.3_fast_probabilistic_consensus.md @@ -74,7 +74,7 @@ The proposed values of the parameters are (Table 6.3.2): | `ENDING_THRESHOLD` | 0.50 | | `DRNG_WAITING_TIME` | 0.20 | | `MAX_ROUND` | 100 | -| ` QUERY_SIZE` | 21 | +| `QUERY_SIZE` | 21 | | `ROUND_LENGTH` | 10 | | `TIME_OUT` | 6.5 | | `MIN_MANA_PROPORTION` | 0.50 | diff --git a/next/docs/iota-sdk/docs/contribute.md b/next/docs/iota-sdk/docs/contribute.md index 1db06121036..1ccdc05608c 100644 --- a/next/docs/iota-sdk/docs/contribute.md +++ b/next/docs/iota-sdk/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/next/docs/iota-sdk/docs/getting-started/nodejs.mdx b/next/docs/iota-sdk/docs/getting-started/nodejs.mdx index 6fd6a711f8b..05ddb7799fe 100644 --- a/next/docs/iota-sdk/docs/getting-started/nodejs.mdx +++ b/next/docs/iota-sdk/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/next/docs/iota-sdk/docs/getting-started/python.mdx b/next/docs/iota-sdk/docs/getting-started/python.mdx index 15a87d1d898..876f8498f28 100644 --- a/next/docs/iota-sdk/docs/getting-started/python.mdx +++ b/next/docs/iota-sdk/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/next/docs/stronghold.rs/docs/reference/specs/engineering.md b/next/docs/stronghold.rs/docs/reference/specs/engineering.md index 6d71bf6f555..ea7f2c8e6bc 100644 --- a/next/docs/stronghold.rs/docs/reference/specs/engineering.md +++ b/next/docs/stronghold.rs/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/next/docs/stronghold.rs/docs/reference/specs/requirements.md b/next/docs/stronghold.rs/docs/reference/specs/requirements.md index ee507aa6d24..ba30c9a5e28 100644 --- a/next/docs/stronghold.rs/docs/reference/specs/requirements.md +++ b/next/docs/stronghold.rs/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 - (1-e^{-\alpha s})[\text{Base\_cMana}(\text{Node}_i)-\text{Old\_Base\_cMana}(\text{Node}_i)] $$ @@ -249,7 +250,7 @@ Suppose that the last reference time is $t-s$ and the transaction timestamp is $ where $\beta$ is the moving average parameter for the aMana and $\gamma$ is the base aMana decay factor. Notice that, here, the value of $\text{Base\_aMana(Node}_i)$ used is the one already updated. -#### Updating the aMana to a time larger than the last reference time without any new aMana pledging. +#### Updating the aMana to a time larger than the last reference time without any new aMana pledging Suppose that the last reference time is $t-s$ and new one is $t$. The update must be done in two steps, always in the order specified below: diff --git a/shimmer/docs/iota-2.0-research-specifications/6.2_opinion_setting.md b/shimmer/docs/iota-2.0-research-specifications/6.2_opinion_setting.md index 52e268eb007..59042691350 100644 --- a/shimmer/docs/iota-2.0-research-specifications/6.2_opinion_setting.md +++ b/shimmer/docs/iota-2.0-research-specifications/6.2_opinion_setting.md @@ -100,7 +100,7 @@ Recall that the `arrivalTime.messageID` is the time that the message was receive The initial opinion is set based on the question "did the transaction arrive before `currentTime - W`?". The level of knowledge is then set by the margin as a factor of the delay time. Specifically, under the assumption that all messages are delivered to all nodes within time `DLARGE` after the arrive (with high probability), then: - If `|arrivalTime +W - currentTime | < DLARGE`, then the node can make any conclusions about the arrival times of the message, and hence it has only level of knowledge 1. -- If one node has `|arrivalTime +W - currentTime | >= DLARGE `, then all nodes must have the same opinion, and hence that node has level of knowledge at least 2. +- If one node has `|arrivalTime +W - currentTime | >= DLARGE`, then all nodes must have the same opinion, and hence that node has level of knowledge at least 2. - If one node has `|arrivalTime +W - currentTime | >= 2*DLARGE`, then all nodes must have `|arrivalTime +W - currentTime | => DLARGE` guaranteeing level of knowledge 3. ![](https://i.imgur.com/a5or78c.png) diff --git a/shimmer/docs/iota-2.0-research-specifications/6.3_fast_probabilistic_consensus.md b/shimmer/docs/iota-2.0-research-specifications/6.3_fast_probabilistic_consensus.md index 4a0ca0fbaf1..72aa0e2d365 100644 --- a/shimmer/docs/iota-2.0-research-specifications/6.3_fast_probabilistic_consensus.md +++ b/shimmer/docs/iota-2.0-research-specifications/6.3_fast_probabilistic_consensus.md @@ -74,7 +74,7 @@ The proposed values of the parameters are (Table 6.3.2): | `ENDING_THRESHOLD` | 0.50 | | `DRNG_WAITING_TIME` | 0.20 | | `MAX_ROUND` | 100 | -| ` QUERY_SIZE` | 21 | +| `QUERY_SIZE` | 21 | | `ROUND_LENGTH` | 10 | | `TIME_OUT` | 6.5 | | `MIN_MANA_PROPORTION` | 0.50 | diff --git a/shimmer/docs/iota-sdk/docs/contribute.md b/shimmer/docs/iota-sdk/docs/contribute.md index 1db06121036..1ccdc05608c 100644 --- a/shimmer/docs/iota-sdk/docs/contribute.md +++ b/shimmer/docs/iota-sdk/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/shimmer/docs/iota-sdk/docs/getting-started/nodejs.mdx b/shimmer/docs/iota-sdk/docs/getting-started/nodejs.mdx index 6fd6a711f8b..05ddb7799fe 100644 --- a/shimmer/docs/iota-sdk/docs/getting-started/nodejs.mdx +++ b/shimmer/docs/iota-sdk/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/shimmer/docs/iota-sdk/docs/getting-started/python.mdx b/shimmer/docs/iota-sdk/docs/getting-started/python.mdx index 15a87d1d898..876f8498f28 100644 --- a/shimmer/docs/iota-sdk/docs/getting-started/python.mdx +++ b/shimmer/docs/iota-sdk/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/shimmer/docs/iota.rs/docs/getting_started/java.mdx b/shimmer/docs/iota.rs/docs/getting_started/java.mdx index 52ca0b685d2..0f4e704ff7c 100644 --- a/shimmer/docs/iota.rs/docs/getting_started/java.mdx +++ b/shimmer/docs/iota.rs/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](https://wiki.iota.org/shimmer/iota.rs/how_tos/run_how_tos/) 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](https://wiki.iota.org/shimmer/iota.rs/how_tos/run_how_tos/) 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/shimmer/docs/iota.rs/docs/libraries/python/how_to/_run_how_tos.md b/shimmer/docs/iota.rs/docs/libraries/python/how_to/_run_how_tos.md index bd4ddf3401e..119ae300515 100644 --- a/shimmer/docs/iota.rs/docs/libraries/python/how_to/_run_how_tos.md +++ b/shimmer/docs/iota.rs/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/shimmer/docs/stronghold.rs/docs/reference/specs/engineering.md b/shimmer/docs/stronghold.rs/docs/reference/specs/engineering.md index 6d71bf6f555..ea7f2c8e6bc 100644 --- a/shimmer/docs/stronghold.rs/docs/reference/specs/engineering.md +++ b/shimmer/docs/stronghold.rs/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/shimmer/docs/stronghold.rs/docs/reference/specs/requirements.md b/shimmer/docs/stronghold.rs/docs/reference/specs/requirements.md index ee507aa6d24..ba30c9a5e28 100644 --- a/shimmer/docs/stronghold.rs/docs/reference/specs/requirements.md +++ b/shimmer/docs/stronghold.rs/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 -