Minor changes to documentation, spell-check and apply suggestion from…

… grammarly, add a cspell file

README.md

@@ -8,7 +8,7 @@
 [![Test Coverage](https://api.codeclimate.com/v1/badges/c1304869331b687e0aba/test_coverage)](https://codeclimate.com/github/ecadlabs/signatory/test_coverage)
 [![Go Report Card](https://goreportcard.com/badge/github.com/ecadlabs/signatory)](https://goreportcard.com/report/github.com/ecadlabs/signatory)
 
-_WARNING: This project is in active development. While we welcome users and feedback, please be warned that this project is a work in progress and users should proceed with caution._
+_WARNING: This project is in active development. While we welcome users and feedback, please be warned that this project is a work in progress, and users should proceed with caution._
 
 ## What is Signatory?
 
@@ -34,18 +34,18 @@ Signatory receives signing requests from either a baker or an endorser, signs th
 
 ### Observability
 
-Signatory is also focused on observability, meaning that it exposes metrics about its operations. Metrics allows operators to see historical trends, signing volumes, errors and latencies, enabling rich reporting and alerting capabilities.
+Signatory is also focused on observability, meaning that it exposes metrics about its operations. Metrics allow operators to see historical trends, signing volumes, errors and latencies, enabling rich reporting and alerting capabilities.
 
 ### Private-Key Import
 
-Private-key import is an important security consideration when choosing a Cloud HSM offering. Some HSM's allow you to generate the secret key internally so that no one can extract the private key from the HSM. Others allow for private-key import with different levels of security. The trade-offs in this context are essential to understand.
+Private-key import is an important security consideration when choosing a Cloud HSM offering. Some HSMs allow you to generate the secret key internally so that no one can extract the private key from the HSM. Others allow for private-key import with different levels of security. The trade-offs in this context are essential to understand.
 
 ---
 
 ## How it Works
 
 * Tezos sends a signing request to Signatory
-* Signatory checks that the operation is either `block` or `endorsement.`
+* Signatory checks that the operation is either `block` or `endorsement`
 * Signatory sends the operation to the configured backend for singing
 * Upon receiving the signing operation from the backend, Signatory validates the signature with a Tezos node (optional)
 * Signatory returns the operation signature to the Tezos node
@@ -54,13 +54,11 @@ Private-key import is an important security consideration when choosing a Cloud
 
 Signatory currently supports [Azure Key Vault][0]. Other backend signing services are either in the planning phase or are currently in development.
 
-We are adding support for additional backend Key Management Systems (KMS) for the secure handling of private keys. Most cloud-based KMS systems offer an HSM backed mode, which we strongly recommended.
+We are adding support for additional backend Key Management Systems (KMS) for the secure handling of private keys. Most cloud-based KMS systems offer an HSM-backed mode, which we strongly recommend.
 
-Our goal in supporting multiple Cloud KMS/HSM services is to help in preventing centralization on the _network_ or _infrastructure_ level. It is not optimal for Tezos to have the most decentralized network in terms of bakers, and of those bakers, a large majority operate on single infrastructure provider.
+Our goal in supporting multiple Cloud KMS/HSM services is to help in preventing centralization on the _network_ or _infrastructure_ level. A goal of Tezos is to have a highly decentralized network of bakers. That goal is not fully realized if, of those bakers, a large majority operate on a single infrastructure provider.
 
-In the first year of the Tezos network operation, there was anecdotal evidence that a lot of bakers run on AWS. AWS is a superb provider, but having a concentration of nodes on one cloud vendor centralizes the underlying infrastructure of the network, which is not desirable.
-
-By supporting multiple Cloud KMS/HSM systems, we hope to help the network from centralization on a particular Cloud offering. In the first year of the Tezos network operation, there was anecdotal evidence that many bakers run on AWS.  AWS is a superb provider, but having a concentration of nodes on one cloud vendor centralizes the underlying infrastructure of the network, which is not desirable.
+In the first year of the Tezos network operation, there was anecdotal evidence that a large percentage of bakers run on AWS. AWS is a superb provider, but having a concentration of nodes on one cloud vendor centralizes the underlying infrastructure of the network, which is not desirable. By supporting multiple Cloud KMS/HSM systems, we hope to prevent the network from centralization on a particular Cloud offering.
 
 ### Backend KMS/HSM Support Status
 
@@ -73,7 +71,7 @@ By supporting multiple Cloud KMS/HSM systems, we hope to help the network from c
 
 ### Tezos Address Types
 
-In Tezos, the signing algorithm you can infer from the first three characters of an address. For example, an address beginning with `tz3` uses the P-256 algorithm. HSM's and Cloud-based HSM's have support for a subset of the three algorithms supported by Tezos.
+In Tezos, you can infer the signing algorithm from the first three characters of an address. For example, an address beginning with `tz3` uses the P-256 algorithm. HSMs and Cloud-based HSMs have support for a subset of the three algorithms supported by Tezos.
 
 * `tz1` - [Ed25519](https://ed25519.cr.yp.to/)
 * `tz2` - [Secp256k1](https://en.bitcoin.it/wiki/Secp256k1) __aka: P256K__
@@ -106,17 +104,17 @@ Please use the [GitHub issue tracker](https://github.com/ecadlabs/signatory/issu
 
 To contribute, please check the issue tracker to see if an issue exists for your planned contribution. If there's no issue, please create one first, and then submit a pull request with your contribution.
 
-For a contribution to be merged, it is required to have complete documentation, come with unit tests, and integration tests where appropriate. Submitting a "work in progress" pull request is welcome!
+For a contribution to be merged, it is required to have complete documentation, come with unit tests and integration tests where appropriate. Submitting a "work in progress" pull request is welcome!
 
 ---
 
 ## Alternative Remote Signers
 
-At least three other remote signers are available to use with Tezos. Tezos also provides native support for baking with a Ledger Nano. We encourage bakers too, at a minimum, review these projects. We are eager to collaborate and be peers with these great projects.
+At least three other remote signers are available to use with Tezos. Tezos also provides native support for baking with a Ledger Nano. We encourage bakers to, at a minimum, review these projects. We are eager to collaborate and be peers with these great projects.
 
-* [Tezzigators Azure remote signer](https://github.com/tezzigator/azure-tezos-signer)
+* [Tezzigator's Azure remote signer](https://github.com/tezzigator/azure-tezos-signer)
 * [Tacoinfra's remote signer](https://github.com/tacoinfra/remote-signer)
-* [Polychain Lab's remote signer](https://gitlab.com/polychainlabs/tezos-hsm-signer)
+* [Polychain Labs' remote signer](https://gitlab.com/polychainlabs/tezos-hsm-signer)
 
 ## Disclaimer
 

cspell.json

@@ -0,0 +1,35 @@
+{
+  "words": [
+    "cloudkms",
+    "dpkg",
+    "ecadlabs",
+    "Grafana",
+    "jevonearth",
+    "keybase",
+    "kubernetes",
+    "libedit",
+    "libusb",
+    "libyubihsm",
+    "lsusb",
+    "Polychain",
+    "realpath",
+    "secp",
+    "Tacoinfra's",
+    "Tezos",
+    "Tezzigator's",
+    "unencrypted",
+    "XPOST",
+    "Yubi",
+    "Yubico",
+    "yubihsm"
+  ],
+  "ignoreRegExpList": [
+    "KT1[a-zA-Z0-9]{33}",
+    "o[a-zA-Z0-9]{50}",
+    "tz[1-3][a-zA-Z0-9]{33}",
+    "B[LMK][a-zA-Z0-9]{49}",
+    "[\"':][a-zA-Z0-9]{54}[\"':]",
+    " [a-zA-Z0-9]{54}\n",
+    "[\"':]p2sig[a-zA-Z0-9]{93}[\"':]"
+  ]
+}

docs/README.md

@@ -2,19 +2,19 @@
 
 ## Configuration
 
-Signatory configuration is specified in a YAML file. Use the `signatory.yaml` file as a template to getting started.
+Signatory configuration is specified in a YAML file. Use the `signatory.yaml` file as a template to get started.
 
-Each backend can be configured with one of more instances of the backend. The operator can add as many new backends as they wish, just append to the list.
+You can configure multiple `vault`s. Each `vault` should be configured to use a backend. Same backend can be used in more than one `vault`.
 
-Configuration file is shared between `signatory` and `signatory-cli`.
+The configuration file is shared between `signatory` and `signatory-cli`.
 
 ### Configuration example
 
 ```yaml
 server:
   # Address for the main HTTP server to listen on
   address: :6732
-  # Address for the utility HTTP server to listen on
+  # Address for the utility HTTP server (for Prometheus metrics) to listen on
   utility_address: :9583
   # List of authorized public keys. Sign operation must be authenticated if present
   # Nested lists are allowed
@@ -104,27 +104,27 @@ Flags:
 
 ### Prometheus metrics and health service
 
-Signatory exposes Prometheus metrics and a health status on address specified in `utility_address` configuration parameter. Default value is `:9583`.
+Signatory exposes Prometheus metrics and health status on the address specified in `utility_address` configuration parameter. The default value is `:9583`.
 
 #### Prometheus metrics
 
 Metrics include counters and histograms that track signing operations and errors.
 
-The metrics are intended to be scraped using the Prometheus time series database. We also publish a ready-made Grafana dashboard which users can use to visualize the operation of their signing operations. (TODO: publish Grafana dashboard)
+The metrics are intended to be scraped using the Prometheus time series database. We also publish a ready-made Grafana dashboard that users can use to visualize the operation of their signing operations. (TODO: publish Grafana dashboard)
 
 `localhost:9583/metrics`
 
 #### Health service
 
-Health service endpoint can be used to test if the service is running correctly, and ready to sign requests.
+The health service endpoint can be used to test if the service is running correctly and is ready to sign requests.
 
-This endpoints is useful for use in monitoring, or declarative tests as part of deployment playbooks or kubernetes manifests.
+This endpoint is useful for monitoring, or declarative tests as part of deployment playbooks or Kubernetes manifests.
 
 `localhost:9583/healthz`
 
 ### Testing
 
-To test the signing operation, you can send a post to signatory. In this example, we are sending a dummy operation of type `02`, which is a `endorsement` operation type. 
+To test the signing operation, you can send a post to Signatory. In this example, we are sending a dummy operation of type `02`, which is an `endorsement` operation type.
 
 ```sh
 curl -XPOST \

docs/localsecret.md

@@ -1,5 +1,5 @@
 ---
-id: filebased
+id: file_based
 title: File-Based Secret Storage (Insecure)
 ---
 
@@ -8,7 +8,7 @@ Signatory file-based signer mode allows operation without an HSM or Key Vault se
 
 ## Signatory configuration for file-based secret storage
 
-The documentation assumes you will use the official Signatory docker image, and that you have a Linux server operably configured with docker installed.
+This documentation assumes you will use the official Signatory docker image, and that you have a working Linux server with docker installed.
 
 Place the following YAML in a file named `signatory.yaml`
 

docs/start.md

@@ -15,7 +15,7 @@ The goal of the Signatory service is to make key management as secure as possibl
 
 Security and convenience are often opposed, but we hope to make it easier for the community to manage their keys in an adequately secure manner.
 
-By supporting multiple Cloud KMS/HSM systems, we hope to help the network from centralization on a particular Cloud offering. In the first year of the Tezos network operation, there's anecdotal evidence that many bakers run on AWS. AWS is a superb provider, but concentrating nodes on one cloud vendor centralizes the network’s underlying infrastructure, which is not desirable.
+By supporting multiple Cloud KMS/HSM systems, we hope to help the network from centralization on a particular Cloud offering. In the first year of the Tezos network operation, there was anecdotal evidence that many bakers run on AWS. AWS is a superb provider, but concentrating nodes on one cloud vendor centralizes the network’s underlying infrastructure, which is not desirable.
 
 Observability is a first-class concern. Signatory allows for rich reporting and alerting capabilities. It exposes metrics about its operation via Prometheus metrics, enabling teams to set up robust monitoring of their critical infrastructure and allowing operators to see historical trends, signing volumes, errors and latencies. Users can report feature requests, security issues, or bug reports can via the Github project page: 
 github.com/ecadlabs/signatory or via email to [email protected]

docs/yubihsm.md

@@ -28,7 +28,7 @@ This documentation assumes that you will be running Signatory and the YubiHSM2 d
 
 Signatory uses the `yubihsm-connector` daemon to interact with the YubiHSM USB device.
 
-The connector requires you to have the libusd package installed on your system.
+The connector requires you to have the libusb package installed on your system.
 
 ```
 apt-get install libusb-1.0-0
@@ -46,7 +46,7 @@ To manage the YubiHSM2 device, you will need the `yubihsm-shell` utility. This u
 apt-get install libedit2
 ```
 
-To install yubihsm-shell, you must install the yubihsm-shell package and the supporting YubiHSM2 libraries. The `yubihsm-shell` is not required for the operation of signatory and is only for the management of the YubiHSM2 device.
+To install yubihsm-shell, you must install the yubihsm-shell package and the supporting YubiHSM2 libraries. The `yubihsm-shell` is not required for the operation of Signatory and is only for the management of the YubiHSM2 device.
 
 ```
 dpkg -i yubihsm-shell_2.0.2-1_amd64.deb \
@@ -69,7 +69,7 @@ Run the command `yubihsm-shell`. You will get a prompt that looks like:
 yubihsm>
 ```
 
-To connect to the device type `connect`. It will automatically connect to localhost.
+To connect to the device, type `connect`. It will automatically connect to localhost.
 
 To open a new session with the device type. The default password on the YubiHSM2 is "password".
 
@@ -130,7 +130,7 @@ vaults:
 To import a secret key, we take the secret key from the above JSON examples. Do not include the "encrypted:" or "unencrypted:" prefix.
 
 ```
-signatory-cli import --config ./signatory.yaml --vault yubi edsk2rKA8YEExg9Zo2qNPiQnnYheF1DhqjLVmfKdxiFfu5GyGRZRnb 
+signatory-cli import --config ./signatory.yaml --vault yubi edsk2rKA8YEExg9Zo2qNPiQnnYheF1DhqjLVmfKdxiFfu5GyGRZRnb
 ```
 
 If the import is successful, the `signatory-cli` will report the PKH of your newly imported secret:
@@ -147,7 +147,7 @@ You can use the `yubihsm-shell` utility command `list objects 0 0` to verify tha
 
 ### Listing Tezos Addresses in the YubiHSM2
 
-You can use the command `signatory-cli list` to list all keys in the YubiHSM2. `signatory-cli` also prints the configuration status for each address
+You can use the command `signatory-cli list` to list all keys in the YubiHSM2. `signatory-cli` also prints the configuration status for each address.
 
 ```
 signatory-cli -c ./signatory.yaml list

website/docusaurus.config.js

@@ -40,7 +40,7 @@ module.exports = {
             },
             {
               label: 'Local Secret',
-              to: 'docs/filebased',
+              to: 'docs/file_based',
             },
             {
               label: 'YubiHSM',

website/sidebars.js

@@ -1,5 +1,5 @@
 module.exports = {
   someSidebar: {
-    Start: ['start', 'filebased', 'yubihsm', 'azure_kms'],
+    Start: ['start', 'file_based', 'yubihsm', 'azure_kms'],
   },
 };