fix typos in the README (metaplex-foundation#58)

README.md

@@ -2,7 +2,7 @@
 
 This repo houses a validator plugin that is a key part of the Metaplex's Digital Asset RPC API. It is responsible for getting
 information out of the Solana validator and sending it to a message bus in a binary format. While this component was
-built to serve the API's it was designed to allow any message bus tech to be used. That being sai, it can be used for many use cases.
+built to serve the APIs, it was designed to allow any message bus tech to be used. That being said, it can be used for many use cases.
 
 ## WARNING
 
@@ -12,7 +12,7 @@ Solana 1.10.41 or greater is required. Your calling components must support V2 G
 
 It is built on the following principles.
 
-- Do a little work in the validator process as possible.
+- Do as little work in the validator process as possible.
 - Allow any message bus tech to work.
 - Opinionated and efficient Wire format as a standard.
 - Async first
@@ -75,16 +75,16 @@ RUST_LOG=warn
 PLUGIN_MESSENGER_CONFIG='{ messenger_type="Redis", connection_config={ redis_connection_str="redis://redis" } }'
 ```
 
-The PLUGIN_MESSENGER_CONFIG determins which compiled messenger to select and a specific configuration for the messenger.
+The PLUGIN_MESSENGER_CONFIG determines which compiled messenger to select and a specific configuration for the messenger.
 
 
 #### Additional Configuration Examples
 
 ***Producer Configuration***
 
-- "pipeline_size_bytes" - Maximum command size, roughly equates to the payload size. This setting locally buffers bytes in a queue to be flushed when the buffere grows past the desired amount. Default is 512mb(max redis command size) / 1000, maximum is 512mb(max redis command size) / 1000. You should test your optimal size to avoid high send latency and avoid RTT.
+- "pipeline_size_bytes" - Maximum command size, roughly equates to the payload size. This setting locally buffers bytes in a queue to be flushed when the buffer grows past the desired amount. Default is 512MB (max redis command size) / 1000, maximum is 512MB (max redis command size) / 1000. You should test your optimal size to avoid high send latency and avoid RTT.
 - "local_buffer_max_window" - Maximum time to wait for the buffer to fill be for flushing. For lower traffic you dont want to be waiting around so set a max window and it will send at a minumum of every X milliseconds . Default 10
-- "confirmation_level" - Can be one of "Processed", "Confirmed", "Rooted". Defaults to Processed this is the level we wait for before sending. "Processed" is essentially when we first see it which can on rare cases be reverted. "Confirmed" has extremley low likley hood of being reverted but takes longer (~1k ms in our testing) to show up. "Rooted" is impossible to revert but takes the longest.
+- "confirmation_level" - Can be one of "Processed", "Confirmed", "Rooted". Defaults to Processed which is the level we wait for before sending. "Processed" is essentially when we first see it which can on rare cases be reverted. "Confirmed" has extremley low likley hood of being reverted but takes longer (~1k ms in our testing) to show up. "Rooted" is impossible to revert but takes the longest.
 - "num_workers" - This is the number of workers who will pickup notifications from the plugin and send them to the messenger. Default is 5
 - "account_stream_size" - default value 100_000_000
 - "slot_stream_size" - default value 100_000
@@ -106,11 +106,11 @@ PLUGIN_MESSENGER_CONFIG='{pipeline_size_bytes=50000000,local_buffer_max_window=5
 
 ***Consumer Configuration***
 
-- "retries" - Amount of times to deliver the message. If delivered this many times and not acked, then its deleted
+- "retries" - Amount of times to deliver the message. If delivered this many times and not ACKed, then it is deleted
 - "batch_size" - Max Amout of messages to grab within the wait timeout window.
 - "message_wait_timeout" - Amount of time the consumer will keep the stream open and wait for messages 
 - "idle_timeout" - Amount of time a consumer can have the message before it goes back on the queue
-- "consumer_id" - VERY important. This is used to scaler horizontally so messages arent duplicated over instances.Make sure this is different per instance
+- "consumer_id" - VERY important. This is used to scale horizontally so messages arent duplicated over instances.Make sure this is different per instance
 
 ```
 
@@ -136,7 +136,7 @@ The plugin exposes the following statsd metrics
 
 ### Building With Docker
 
-This repo contains a docker File that allows you to run an test the plerkle plugin using a test validator.
+This repo contains a docker file that allows you to run and test the plerkle plugin using a test validator.
 To test it you can build the container with`docker compose build` and run it with `docker compose up`.
 
 You will want to change the programs you are listening to in `./docker/runs.sh`. Once you spin up the validator send your transactions to the docker host as you would a normal RPC.