fix: misc spelling (#1288)

Signed-off-by: Kranium Gikos Mendoza <[email protected]>
hyperledger · Aug 16, 2024 · 88efa9c · 88efa9c
1 parent c5846d1
commit 88efa9c
Show file tree

Hide file tree

Showing 14 changed files with 26 additions and 26 deletions.
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -43,7 +43,7 @@ If you would like to *implement* a new feature, please consider the size of the
 
 Before you submit an issue, please search the issue tracker. An issue for your problem might already exist and the discussion might inform you of workarounds readily available.
 
-You can file new issues by selecting a `Bug Report` template on our [Issues submition page](https://github.com/hyperledger/identus-cloud-agent/issues/new/choose).
+You can file new issues by selecting a `Bug Report` template on our [Issues submission page](https://github.com/hyperledger/identus-cloud-agent/issues/new/choose).
 
 ### <a name="submit-pr"></a> Submitting a Pull Request (PR)
 

diff --git a/README.md b/README.md
@@ -60,7 +60,7 @@ Before starting to use the Cloud Agent, it is important to understand the basic
 
 The next diagrams offer a concise architectural overview, depicting a Cloud Agent instance, a controller, the interconnections linking the controller and agent, as well as the external routes to other agents and public ledgers across the Internet.
 
-#### Identus Ecosystem Achitecture
+#### Identus Ecosystem Architecture
 
 ![Identus Architecture](docs/images/identus-architecture-dark.png#gh-dark-mode-only)
 ![Identus Architecture](docs/images/identus-architecture-light.png#gh-light-mode-only)

diff --git a/cloud-agent/service/README.md b/cloud-agent/service/README.md
@@ -13,12 +13,12 @@ see `./infrastucture/local/README.md` for instruction
 `cloud-agent` is a cloud agent that represents the digital identity (is a DID controller)
 of the Issuing / Verification organization. As a DID controller, it needs to perform
 the operation with private and public keys through the Wallet API abstraction level.
-The interface for key-mangement is heavily inspired by
+The interface for key-management is heavily inspired by
 [indy-sdk-java-wrapper](https://github.com/hyperledger/indy-sdk/tree/main/wrappers/java).
 
 There is an `wallet-api` subproject which is responsible for managing and storing DID key-pairs.
 The main goal is to wrap Castor and Pollux libraries which does not handle private-keys
-and ease the usage by providing key-mangement capabilities.
+and ease the usage by providing key-management capabilities.
 Similar to [Indy Wallet SDK - secret API](https://github.com/hyperledger/indy-sdk/tree/main/docs/design/003-wallet-storage#secrets-api),
 *it does not expose a private-key* for external use, instead it provide functions to perform cryptographic actions using internally stored private-keys.
 

diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md
@@ -184,10 +184,10 @@ Example response log
 < content-length: 0
 ```
 
-The response should return status `201 Created` indicating the new user is registerd with username `alice` with a password `1234`.
+The response should return status `201 Created` indicating the new user is registered with username `alice` with a password `1234`.
 The user ID can be observed from `Location` header of the response. This ID will be used for creating permission later in this tutorial.
 
-For in-depth user management, please consult the official Keycloaak administration documentation on [managing users section](https://www.keycloak.org/docs/latest/server_admin/index.html#assembly-managing-users_server_administration_guide).
+For in-depth user management, please consult the official Keycloak administration documentation on [managing users section](https://www.keycloak.org/docs/latest/server_admin/index.html#assembly-managing-users_server_administration_guide).
 
 ### 4. Grant the user permission to the wallet
 

diff --git a/docs/guides/deploying-node.md b/docs/guides/deploying-node.md
@@ -13,7 +13,7 @@ The Open Enterprise Agent communicates with the Node, with all operations conduc
 The Node consists of four separate executables:
 
 1. Node gRPC server
-2. Node PosgresQL database
+2. Node PostgreSQL database
 3. Cardano wallet backend
 4. DB sync
 
@@ -22,7 +22,7 @@ The Node consists of four separate executables:
 The Node gRPC is a service responsible for submitting transactions to the Cardano network with a configurable frequency, retrieving blocks, and processing the data for storage in a database.
 
 
-#### Node PosgresQL database
+#### Node PostgreSQL database
 
 The database used by the Node to store processed data, namely DID documents and their respective states.
 
@@ -52,15 +52,15 @@ graph TB
 
 ```
 
-### Node enviroment variables
+### Node environment variables
 
 
 | Environment Variable                    | Description                                                                           | Default Value   |  Data Type                       |
 |-----------------------------------------|---------------------------------------------------------------------------------------|-----------------|----------------------------------|
-| NODE_PSQL_HOST                          | Host and port of Node PosgresQL database                                              | localhost:5432  | String                           |
-| NODE_PSQL_DATABASE                      | Name of the database to connect to                                                    | node_db         | String                           | 
+| NODE_PSQL_HOST                          | Host and port of Node PostgreSQL database                                             | localhost:5432  | String                           |
+| NODE_PSQL_DATABASE                      | Name of the database to connect to                                                    | node_db         | String                           |
 | NODE_PSQL_USERNAME                      | Username for database authentication                                                  | postgres        | String                           |
-| NODE_PSQL_PASSWORD                      | Password for database authentication                                                  | postgres        | String                           |  
+| NODE_PSQL_PASSWORD                      | Password for database authentication                                                  | postgres        | String                           |
 | NODE_PSQL_AWAIT_CONNECTION_THREADS      | Maximum amount of database connections                                                | 8               | Int                              |
 | NODE_LEDGER                             | Ledger which will be used for txs and blocks                                          | in-memory       | Enum(in-memory, cardano)         |
 | NODE_REFRESH_AND_SUBMIT_PERIOD          | Time period between refreshing transaction statuses and submitting pending operations | 20s             | String                           |
@@ -74,15 +74,15 @@ graph TB
 | NODE_ID_CHAR_LIMIT                      | Maximum number of characters id field of pk and service can have                      | 50              | Int                              |
 | NODE_CARDANO_NETWORK                    | Cardano network node should operate on                                                | testnet         | Enum(testnet, mainnet)           |
 | NODE_CARDANO_WALLET_ID                  | ID (hex encoded) of the wallet to use for payments                                    |                 | String                           |
-| NODE_CARDANO_WALLET_PASSPHRASE          | Spending passphrase of NODE_CARDANO_WALLET_ID                                         |                 | String                           | 
+| NODE_CARDANO_WALLET_PASSPHRASE          | Spending passphrase of NODE_CARDANO_WALLET_ID                                         |                 | String                           |
 | NODE_CARDANO_PAYMENT_ADDRESS            | Address (hex encoded) to make payments to, can be NODE_CARDANO_WALLET_ID itself       |                 | String                           |
 | NODE_CARDANO_WALLET_API_HOST            | Cardano wallet backend API host                                                       | localhost       | String                           |
 | NODE_CARDANO_WALLET_API_PORT            | Cardano wallet backend API port                                                       | 8090            | Int                              |
 | NODE_CARDANO_WALLET_ROUTING_HEADER_NAME | Cardano wallet backend routing header name                                            |                 | String                           |
 | NODE_CARDANO_PRISM_GENESIS_BLOCK        | Index of the first block from which node should start syncing from                    | 1868381         | Int                              |
 | NODE_CARDANO_CONFIRMATION_BLOCKS        | Number of blocks to wait before transaction is considered to be confirmed             | 112             | Int                              |
 | NODE_CARDANO_DB_SYNC_HOST               | Db sync database host and port                                                        | localhost:5433  | String                           |
-| NODE_CARDANO_DB_SYNC_DATABASE           | databse name in DB sync PosgresQL database                                            | cexplorer       | String                           |
+| NODE_CARDANO_DB_SYNC_DATABASE           | database name in DB sync PostgreSQL database                                            | cexplorer       | String                           |
 | NODE_CARDANO_DB_SYNC_USERNAME           | Username for db sync database authentication                                          | postgres        | String                           |
 | NODE_CARDANO_DB_SYNC_PASSWORD           | Password for db sync database authentication                                          | password        | String                           |
 
@@ -110,8 +110,8 @@ Once you have these services up and running, specify their respective URLs in th
     - `NODE_CARDANO_WALLET_ROUTING_HEADER_NAME` for wallet routing header name
 * DB-sync
     - `NODE_CARDANO_DB_SYNC_HOST` for DB-sync host and port in a format `host:port`
-    - `NODE_CARDANO_DB_SYNC_DATABASE` the databse name in DB-sync postgres database
-    - `NODE_CARDANO_DB_SYNC_USERNAME` DB-sync Database username 
+    - `NODE_CARDANO_DB_SYNC_DATABASE` the database name in DB-sync postgres database
+    - `NODE_CARDANO_DB_SYNC_USERNAME` DB-sync Database username
     - `NODE_CARDANO_DB_SYNC_PASSWORD` DB-sync Database password
 
 When running the Node with Cardano ledger, you must specify which network to use, either `mainnet` or `testnet`, using the `NODE_CARDANO_NETWORK` environment variable. While this environment variable is essential for the correct operation of the Node, it does not define the usable network. As mentioned earlier, the interface communicates with the Cardano node; subsequently, the network is DB-sync and Cardano wallet backend. Therefore, when configuring those services, you must specify the network used in their respective configurations. It is possible to run DB-sync on testnet, and Cardano wallet backend on mainnet, and select either one via `NODE_CARDANO_NETWORK`. The Node won't report any errors, but this configuration would be incorrect and won't work correctly. You are responsible for syncing these three components. If you intend to use the testnet, set `NODE_CARDANO_NETWORK` to the testnet, but also run Cardano wallet backend connected to the testnet and start DB-sync to sync from the Node that is also running on the testnet as well. The same goes with mainnet.
@@ -139,4 +139,4 @@ Node DB is a simple PostgreSQL database.
 
 Cardano wallet is an application that communicates with the Cardano network; it functions as a server that you can start and connect to either the mainnet or testnet. You must provide the Node runnable's host and port as environment variables.
 
-DB-sync is an application responsible for syncing the Cardano blockchain with a PostgreSQL database. It would help if you used it to sync with either the mainnet or testnet and must provide the database host with port, database name, and credentials as environment variables to the Node runnable.
+DB-sync is an application responsible for syncing the Cardano blockchain with a PostgreSQL database. It would help if you used it to sync with either the mainnet or testnet and must provide the database host with port, database name, and credentials as environment variables to the Node runnable.
diff --git a/infrastructure/dev/README.md b/infrastructure/dev/README.md
@@ -31,7 +31,7 @@ echo $GITHUB_TOKEN | docker login ghcr.io -u YOUR_USERNAME_HERE} --password-stdi
 | Name     | Purpose                                                                                              | Notes                                                                                                                                                                                                                                  |
 | -------- | ---------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | build.sh | Compile and Publish libraries and docker images locally                                              | Requires sbt and Docker installed                                                                                                                                                                                                      |
-| run.sh   | Retrieves versions from local components and brings up a docker-compose stack using built components | Does not build images or libraries. Can be used to run multiple instances with command line paramaters [see below]                                                                                                                     |
+| run.sh   | Retrieves versions from local components and brings up a docker-compose stack using built components | Does not build images or libraries. Can be used to run multiple instances with command line parameters [see below]                                                                                                                     |
 | stop.sh  | Stops a running instance                                                                             | Used to stop a running instance if you've executed `run.sh` with the `-b/--background` option. Please note - you must supply the same `-n/--name` parameter to this script if you have used a non-default value in the `run.sh` script |
 | clean.sh | Clean local build cache                                                                              | Runs sbt clean;cleanFiles to clear local cache / state from build directories                                                                                                                                                          |
 | full.sh  | Runs `build.sh` followed by `run.sh`                                                                 | Use this to build and run the stack. Sometimes quite slow if not rebuilding all components                                                                                                                                             |

diff --git a/infrastructure/local/README.md b/infrastructure/local/README.md
@@ -36,7 +36,7 @@ To run the Atala `building-block` stack - execute the `run.sh` script. This can
 
 | Name   | Purpose                              | Notes                                                                    |
 | ------ | ------------------------------------ | ------------------------------------------------------------------------ |
-| run.sh | Run the Atala `building-block` stack | Runs using docker-compose and versions are controlled by the `.env` file. Can be used to run multiple instances with command line paramaters [see below] |
+| run.sh | Run the Atala `building-block` stack | Runs using docker-compose and versions are controlled by the `.env` file. Can be used to run multiple instances with command line parameters [see below] |
 | stop.sh  | Stops a running instance                                                                             | Used to stop a running instance if you've executed `run.sh` with the `-b/--background` option. Please note - you must supply the same `-n/--name` parameter to this script if you have used a non-default value in the `run.sh` script |
 
 ## run.sh

diff --git a/infrastructure/multi/README.md b/infrastructure/multi/README.md
@@ -1,6 +1,6 @@
 # Running multiple locally
 
-This folder contains scripts to run mulitple copies of the Atala `building-block` stack for end-user usage - without building any local components.
+This folder contains scripts to run multiple copies of the Atala `building-block` stack for end-user usage - without building any local components.
 
 This allows you to run an issuer, holder and verifier with a single run command - but - these are locked to fixed ports and cannot be customised at run time.
 

diff --git a/mercury/protocol-coordinate-mediation/Coordinate-Mediation-Protocol.md b/mercury/protocol-coordinate-mediation/Coordinate-Mediation-Protocol.md
@@ -1,6 +1,6 @@
 # Coordinate Mediation Protocol
 
-This Protocol is parte of the **DIDComm.org**
+This Protocol is part of the **DIDComm.org**
 
 Is a protocol to coordinate mediation configuration between a mediating agent and the recipient.
 

diff --git a/mercury/protocol-did-exchange/DidExchange-Protocol.md b/mercury/protocol-did-exchange/DidExchange-Protocol.md
@@ -1,6 +1,6 @@
 # DidExchange Protocol
 
-This Protocol is parte of the DIDComm Messaging Specification.
+This Protocol is part of the DIDComm Messaging Specification.
 
 Protocol to exchange DIDs between agents when establishing a DID-based relationship
 

diff --git a/mercury/protocol-invitation/Invitation-Protocol.md b/mercury/protocol-invitation/Invitation-Protocol.md
@@ -1,6 +1,6 @@
 # Invitation Protocol
 
-This Protocol is parte of the **DIDComm Messaging Specification** but also **Aries RFC 0434: Out-of-Band Protocol 1.1**
+This Protocol is part of the **DIDComm Messaging Specification** but also **Aries RFC 0434: Out-of-Band Protocol 1.1**
 
 Its a out-of-band style protocol.
 

diff --git a/mercury/protocol-report-problem/Report-Problem-Protocol.md b/mercury/protocol-report-problem/Report-Problem-Protocol.md
@@ -1,6 +1,6 @@
 # Report Problem Protocol 1.0 & 2.0
 
-This Protocol is parte of Aries (RFC 0035).
+This Protocol is part of Aries (RFC 0035).
 Describes how to report errors and warnings in a powerful, interoperable way.
 
 - Version 1.0 - see [https://github.com/hyperledger/aries-rfcs/tree/main/features/0035-report-problem]

diff --git a/mercury/protocol-revocation-notification/Revocation-notification-protocol.md b/mercury/protocol-revocation-notification/Revocation-notification-protocol.md
@@ -1,6 +1,6 @@
 # Revocation notification protocol
 
-This Protocol for an Isuser to notify the revocation of a credential to the holder.
+This Protocol for an Issuer to notify the revocation of a credential to the holder.
 
 
 

diff --git a/mercury/protocol-routing/Routing-Protocol.md b/mercury/protocol-routing/Routing-Protocol.md
@@ -1,6 +1,6 @@
 # Routing Protocol 2.0
 
-This Protocol is parte of the DIDComm Messaging Specification.
+This Protocol is part of the DIDComm Messaging Specification.
 
 See [https://identity.foundation/didcomm-messaging/spec/#routing-protocol-20]