fixes

src/apis/eth_provider.md

@@ -1,8 +1,11 @@
 # ETH Provider API
 
-**Note: Most processes will not use this API directly. Instead, they will use the `eth` portion of the[`process_lib`](../process_stdlib/overview.md) library, which papers over this API and provides a set of types and functions which are much easier to natively use. This is mostly useful for re-implementing this module in a different client or performing niche actions unsupported by the library.**
+**Note: Most processes will not use this API directly. Instead, they will use the `eth` portion of the[`process_lib`](../process_stdlib/overview.md) library, which papers over this API and provides a set of types and functions which are much easier to natively use.
+This is mostly useful for re-implementing this module in a different client or performing niche actions unsupported by the library.**
 
-Processes can send two kinds of requests to `eth:distro:sys`: `EthAction` and `EthConfigAction`. The former only requires the capability to message the process, while the latter requires the root capability issued by `eth:distro:sys`. Most processes will only need to send `EthAction` requests.
+Processes can send two kinds of requests to `eth:distro:sys`: `EthAction` and `EthConfigAction`.
+The former only requires the capability to message the process, while the latter requires the root capability issued by `eth:distro:sys`.
+Most processes will only need to send `EthAction` requests.
 
 ```rust
 /// The Action and Request type that can be made to eth:distro:sys. Any process with messaging
@@ -30,7 +33,8 @@ pub enum EthAction {
 }
 ```
 
-The `Request` containing this action should always expect a response, since every action variant triggers one and relies on it to be useful. The ETH provider will respond with the following type:
+The `Request` containing this action should always expect a response, since every action variant triggers one and relies on it to be useful.
+The ETH provider will respond with the following type:
 
 ```rust
 /// The Response type which a process will get from requesting with an [`EthAction`] will be
@@ -67,7 +71,9 @@ pub enum EthError {
 }
 ```
 
-The `EthAction::SubscribeLogs` request will receive a response of `EthResponse::Ok` if the subscription was successfully created, or `EthResponse::Err(EthError)` if it was not. Then, after the subscription is successfully created, the process will receive *Requests* from `eth:distro:sys` containing subscription updates. That request will look like this:
+The `EthAction::SubscribeLogs` request will receive a response of `EthResponse::Ok` if the subscription was successfully created, or `EthResponse::Err(EthError)` if it was not.
+Then, after the subscription is successfully created, the process will receive *Requests* from `eth:distro:sys` containing subscription updates.
+That request will look like this:
 
 ```rust
 /// Incoming `Request` containing subscription updates or errors that processes will receive.
@@ -91,11 +97,13 @@ pub struct EthSubError {
 }
 ```
 
-Again, for most processes, this is the entire API. The `eth` portion of the `process_lib` library will handle the serialization and deserialization of these types, and provide a set of functions and types that are much easier to use.
+Again, for most processes, this is the entire API.
+The `eth` portion of the `process_lib` library will handle the serialization and deserialization of these types and provide a set of functions and types that are much easier to use.
 
 ### Config API
 
-If a process has the `root` capability from `eth:distro:sys`, it can send `EthConfigAction` requests. These actions are used to adjust the underlying providers and relays that the module uses, and its settings regarding acting as a relayer for other nodes.
+If a process has the `root` capability from `eth:distro:sys`, it can send `EthConfigAction` requests.
+These actions are used to adjust the underlying providers and relays used by the module, and its settings regarding acting as a relayer for other nodes (public/private/granular etc).
 
 ```rust
 /// The action type used for configuring eth:distro:sys. Only processes which have the "root"
@@ -183,6 +191,8 @@ pub struct AccessSettings {
 }
 ```
 
-A successful `GetProviders` request will receive a response of `EthConfigResponse::Providers(SavedConfigs)`, and a successful `GetAccessSettings` request will receive a response of `EthConfigResponse::AccessSettings(AccessSettings)`. The other requests will receive a response of `EthConfigResponse::Ok` if they were successful, or `EthConfigResponse::PermissionDenied` if they were not.
+A successful `GetProviders` request will receive a response of `EthConfigResponse::Providers(SavedConfigs)`, and a successful `GetAccessSettings` request will receive a response of `EthConfigResponse::AccessSettings(AccessSettings)`.
+The other requests will receive a response of `EthConfigResponse::Ok` if they were successful, or `EthConfigResponse::PermissionDenied` if they were not.
 
-All of these types are serialized to a JSON string via `serde_json` and stored as bytes in the request/response body. [The source code for this API can be found in the `eth` section of the Kinode runtime library.](https://github.com/kinode-dao/kinode/blob/main/lib/src/eth.rs)
+All of these types are serialized to a JSON string via `serde_json` and stored as bytes in the request/response body.
+[The source code for this API can be found in the `eth` section of the Kinode runtime library.](https://github.com/kinode-dao/kinode/blob/main/lib/src/eth.rs)

src/cookbook/reading_data_from_eth.md

@@ -3,7 +3,8 @@
 For the purposes of this cookbook entry, all reads will be done from Ethereum Mainnet, but the same methods can easily be used on other networks by changing the `chain_id` parameter.
 
 <div class="warning">
-If a node does not have a provider for the given chain ID, calls and subscriptions will fail. To fix this, add some code on either the frontend or backend of your app that handles these failures by prompting the user to add a provider for the desired chain.
+If a node does not have a provider for the given chain ID, calls and subscriptions will fail.
+To fix this, add some code on either the frontend or backend of your app that handles these failures by prompting the user to add a provider for the desired chain.
 </div>
 
 Using the provider system starts in a process by importing the `eth` library from `kinode_process_lib`:
@@ -17,8 +18,8 @@ let provider = eth::Provider::new(chain_id, 30);
 ```
 The timeout set here will apply to all requests sent through the provider.
 If a request takes longer than the timeout, the request will fail with a timeout error.
-Generally, ETH calls can take longer than other requests in Kinode, because the call must be sent to an external RPC which may or may not be fast.
-Note also that larger calls will generally take longer for an RPC to respond to.
+Generally, ETH calls can take longer than other requests in Kinode, because the call must be sent to an external RPC that may or may not be fast.
+Note also that an RPC endpoint will generally take longer to respond to larger calls.
 If you need to adjust the timeout or chain ID, simply create another provider object with the new desired parameters.
 
 Calling various functions on the `Provider` allows the process to execute RPC calls like `get_balance`, `get_logs`, and `send_raw_transaction`.

src/read_and_write_to_chain.md

@@ -1,16 +1,28 @@
 # Read+Write to Chain
 
-Kinode OS comes with a built-in provider layer for Ethereum and other EVM chains/rollups. This runtime module lives in `eth:distro:sys` and is usable by any package which acquires the messaging capability for it. In addition to allowing connections directly to WebSocket RPC endpoints, the provider can also connect via the Kinode networking protocol to other Kinodes and use their provider as a relay. The node must be configured to allow relay connections, which can be done with a public/private flag or explicit allow/deny list.
+Kinode OS comes with a built-in provider layer for Ethereum and other EVM chains/rollups.
+This runtime module lives in `eth:distro:sys` and is usable by any package which acquires the messaging capability for it.
+In addition to allowing connections directly to WebSocket RPC endpoints, the provider can also connect via the Kinode networking protocol to other Kinodes and use their provider as a relay.
+The node must be configured to allow relay connections, which can be done with a public/private flag or explicit allow/deny list.
 
-As with other runtime modules, processes should generally use the [kinode_process_lib](https://github.com/kinode-dao/process_lib) to interact with the provider. See [Reading Data from ETH](./cookbook/reading_data_from_eth.md) for an example of doing this in a process. For more advanced or direct usage, such as configuring the provider, see the [API Reference](./apis/eth_provider.md).
+As with other runtime modules, processes should generally use the [kinode_process_lib](https://github.com/kinode-dao/process_lib) to interact with the provider.
+See [Reading Data from ETH](./cookbook/reading_data_from_eth.md) for an example of doing this in a process.
+For more advanced or direct usage, such as configuring the provider, see the [API Reference](./apis/eth_provider.md).
 
 ### Supported Chains
 
-The provider is capable of using any RPC endpoint that follows the [JSON-RPC API](https://ethereum.org/developers/docs/apis/json-rpc) that is used by Ethereum and most other EVM chains and rollups. The runtime uses the [Alloy](https://github.com/alloy-rs) family of libraries to connect to WS RPC endpoints. It does not currently support HTTP endpoints, as subscriptions are vastly preferable for many of the features that Kinode OS uses.
+The provider is capable of using any RPC endpoint that follows the [JSON-RPC API](https://ethereum.org/developers/docs/apis/json-rpc) that is used by Ethereum and most other EVM chains and rollups.
+The runtime uses the [Alloy](https://github.com/alloy-rs) family of libraries to connect to WS RPC endpoints.
+It does not currently support HTTP endpoints, as subscriptions are vastly preferable for many of the features that Kinode OS uses.
 
 ### Configuration
 
-In the [API Reference](./apis/eth_provider.md), one can see the way to format requests to `eth:distro:sys` that adjust the configuration during runtime. This includes adding and removing providers and adjusting the permissions for other nodes to use this node as a relay. However, most configuration is done in an optional file named `.eth-providers` inside the home folder of a node. If this file is not present, a node will boot using the default providers hardcoded for testnet or mainnet, depending on where the node lives. If it is present, the node will load in those providers and use them. The file is a JSON object with the following shape (example data):
+The [API Reference](./apis/eth_provider.md) demonstrates how to format requests to `eth:distro:sys` that adjust its config during runtime.
+This includes adding and removing providers and adjusting the permissions for other nodes to use this node as a relay.
+However, most configuration is done in an optional file named `.eth-providers` inside the home folder of a node.
+If this file is not present, a node will boot using the default providers hardcoded for testnet or mainnet, depending on where the node lives.
+If it is present, the node will load in those providers and use them.
+The file is a JSON object with the following shape (example data):
 
 ```json
 [
@@ -42,7 +54,9 @@ In the [API Reference](./apis/eth_provider.md), one can see the way to format re
 ]
 ```
 
-One can see that the provider list includes both node-providers (other Kinodes that will hopefully allow use as a relay) and url-providers (traditional RPC endpoints). Nodes that wish to maximize their connectivity should supply themselves with url-providers, ideally trusted ones -- they can even be running locally, with a light client such as [Helios](https://github.com/a16z/helios). In fact, a future update to the provider will likely integrate Helios which will allow nodes to convert untrusted endpoints to trusted ones. This is the reason for the `trusted` flag in the provider object.
+One can see that the provider list includes both node-providers (other Kinodes that are permissioned for use as a relay) and url-providers (traditional RPC endpoints).
+Nodes that wish to maximize their connectivity should supply themselves with url-providers, ideally trusted ones—they can even be running locally, with a light client such as [Helios](https://github.com/a16z/helios).
+In fact, a future update to the provider will likely integrate Helios, which will allow nodes to convert untrusted endpoints to trusted ones. This is the reason for the `trusted` flag in the provider object.
 
 Lastly, note that the `kns_update` object must fully match the onchain PKI data for the given node, otherwise the two nodes will likely not be able to establish a connection.