minor style fixes

docs/architecture/benchmark.md

@@ -31,7 +31,7 @@ Consequently, it is important to consider that the performance on these hardware
 ![Live Data msg per sec](./live.png)
 
 ::: details
-\* Redis discards messages for clients because they cannot be processed in time. resulting in dataloss.
+\* Redis discards messages for clients because they cannot be processed in time. Resulting in data loss.
 :::
 
 
@@ -43,7 +43,8 @@ Raw data:
 
 These results are quite interesting. High and mid-end hardware are about equal even for 100 clients. And the low-end hardware is not so far of. capable of handling atleast 10 clients.
 
-Note that one block contains alot of transactions and actions resulting in alot more then one redis message per block. therefore even if there is just 2 blocks per second. There is alot more redis messages sent out.
+Note that one block contains a lot of transactions and actions resulting in a lot more then one Redis message per block.
+Therefore even if there is just 2 blocks per second. There is a lot more Redis messages sent out.
 
 ## Replay
 
@@ -66,6 +67,9 @@ it is just as 10xlow, not usable.
 ## Conclusion
 
 By looking at the live data graphs they process roughly the same amount of messages per second. That is because the bottleneck is the blockchain
-itself. If we look at the replay data, redis clients can't keep up as number of clients increases. however, it is still pretty fast. consider that all 10x clients performs roughly equal.
+itself. If we look at the replay data, redis clients can't keep up as number of clients increases.
+However, it is still pretty fast. Consider that all 10x clients performs roughly equal.
 
-Also the fact that the benchmark tests fetchees **all** messages. That is pretty unrealistic as applications should in 99% of the cases only care about actions on a subset of contracts. Only case where you would want all actions is if you are building some sort of blockexplorer.
+Also the fact that the benchmark tests fetches **all** messages. That is pretty unrealistic as applications
+should in 99% of the cases only care about actions on a subset of contracts.
+Only case where you would want all actions is if you are building some sort of blockexplorer.

docs/architecture/index.md

@@ -37,7 +37,10 @@ However, these advantages can also be considered drawbacks in certain situations
 
 - **Immediate message consumption**: Pub/Sub requires subscribers to consume messages immediately upon publication. If a client is unable to read a message promptly, it is discarded.
 
-In contrast, Streams in Redis provide built-in message persistence. Messages are stored as entries in the stream and can be consumed at any time, even if they were published before the subscriber connected.
+In contrast, Streams in Redis provide built-in message persistence.
+Messages are stored as entries in the stream and can be consumed at any time, even if they were published before the subscriber connected.
 This feature addresses the drawbacks of immediate message consumption and message loss associated with Pub/Sub.
 
-Currently, Streams are not implemented in Thalos. However, there are plans to consider implementing Streams in the future, based on the demand for such functionality. It's important to note that Streams introduce additional complexity to the client implementation.
+Currently, Streams are not implemented in Thalos.
+However, there are plans to consider implementing Streams in the future, based on the demand for such functionality.
+It's important to note that Streams introduce additional complexity to the client implementation.

docs/installation/index.md

@@ -19,7 +19,7 @@ There are several ways to install thalos, via package manager, downloading a pre
 
 You can get the latest archive package [here](https://github.com/eosswedenorg/thalos/releases/latest)
 
-Simply download using your webbrowser or via curl:
+Simply download using your web browser or via curl:
 
 ```shell
 curl -Ls https://github.com/eosswedenorg/thalos/releases/download/<version>/thalos-server-<version>-linux-amd64.tar.gz | tar -z --one-top-level=thalos -xvf -
@@ -51,4 +51,4 @@ After building the binary you can install it along with basic config file and st
 
 ```shell
 ./install.sh /path/to/your/directory/of/choice
-```
+```

docs/redis/security/acl.md

@@ -12,7 +12,8 @@ The special account called `default` serves as the default account for unauthori
 configured with a password. Connections can authenticate against this account without specifying a username.
 Thalos utilizes this account as the default user account.
 
-Additionally, it is advisable to restrict the Thalos server account as an added precaution against any unauthorized actions it may inadvertently perform, although such occurrences are highly unlikely.
+Additionally, it is advisable to restrict the Thalos server account as an added precaution against any
+unauthorized actions it may inadvertently perform, although such occurrences are highly unlikely.
 
 The ACL in thalos is simple and uses 2 accounts:
 
@@ -112,4 +113,4 @@ user thalos-client on >client_password resetchannels &ship::* +@connection +subs
 ## Useful links
 
 * [Config File Example](https://redis.io/docs/management/config-file)
-* [Official ACL Documentation](https://redis.io/docs/management/security/acl)
+* [Official ACL Documentation](https://redis.io/docs/management/security/acl)

docs/redis/security/index.md

@@ -1,9 +1,15 @@
 
 # Securing redis
 
-This documentation primarily focuses on setups where Redis is exposed to the internet or an internal network where there is not complete control over the clients. For example, you may want to grant access to your Thalos instance to a friend. While trusting your friend is reasonable, it is essential to consider potential future scenarios where trust may no longer exist or their server could be compromised.
+This documentation primarily focuses on setups where Redis is exposed to the internet or an internal
+network where there is not complete control over the clients.
+For example, you may want to grant access to your Thalos instance to a friend.
+While trusting your friend is reasonable, it is essential to consider potential future scenarios where
+trust may no longer exist or their server could be compromised.
 
-If you intend to run Thalos for internal use only, such as having internal applications that are relying on a blockchain stream, it is perfectly acceptable to skip these steps if you have complete control over all involved servers and do not expose the instance over a public IP.
+If you intend to run Thalos for internal use only, such as having internal applications that are relying on a blockchain stream,
+it is perfectly acceptable to skip these steps if you have complete control over all involved
+servers and do not expose the instance over a public IP.
 
 ## Isolating redis
 
@@ -35,8 +41,8 @@ bind * -::*                     # like the default, all available interfaces
 
 ## Firewall
 
-Make sure you setup your firewall rules correctly. only allowing the ip's you trust to access the redis port.
-This is out of scope of this documentation. consult your operating system or router manuals.
+Make sure you setup your firewall rules correctly. Only allowing the IP addresses you trust to access the Redis port.
+This is out of scope of this documentation. Consult your operating system or router manuals.
 
 ## Useful links