fix: Minor suggestions

Author: david-cermak

content/blog/2025/09/esp-wifi-remote/index.md

@@ -86,15 +86,15 @@ The backend solutions could perform a consistency check but cannot reconfigure t
 
 ### Choosing the backend solution
 
-The default and recommended option is `esp_hosted` as your backend solution for most use-cases, providing the best performance, integration, maturity and support.
+The default and recommended option as your backend solution for most use-cases is `esp_hosted`, providing the best performance, integration, maturity, and support.
 
 You can also switch to `eppp` or `at` based implementation or implement your own backend solution.
 Here are the reasons you might prefer some other implementation than `esp_hosted`:
 * Your application is not aiming for the best network throughput.
 * Your slave (or host) device is not an ESP32 target and you want to use some standard protocol:
   - choose `eppp`: it uses PPPoS protocol and works seamlessly with `pppd` on linux.
   - choose `at`: it uses standard AT commands and integrates nicely with `esp-at` as a slave device.
-* You prefer encrypted communication between host and slave device, especially when passing Wi-Fi credentials.
+* You prefer encrypted communication between host and slave devices, especially when passing Wi-Fi credentials.
 * You might need some customization on the slave side.
 
 To choose the backend solution, go to the Wi-Fi Remote component configuration menu and select the preferred one by:
@@ -116,27 +116,27 @@ idf.py add-dependency "espressif/wifi_remote_over_at"
 
 #### Comparison of backend solution components
 
-This section compares backend solutions, focusing on how different methods marshall (i.e., encode and transmit) Wi-Fi commands, events and data to the slave device.
+This section compares backend solutions, focusing on how different methods marshall (i.e., encode and transmit) Wi-Fi commands, events, and data to the slave device.
 
 **Principle of operation**
 
 
-**`esp-hosted`** uses a plain text channel to send and receive Wi-Fi API calls and events. It uses other plain text channels for data packets (Wi-Fi station, soft-AP, BT/BLE). The TCP/IP stack runs only on the host side and esp-hosted passes Ethernet frames (802.3) from host to slave, where they are queue directly to the Wi-Fi library.
+**`esp-hosted`** uses a plain text channel to send and receive Wi-Fi API calls and events. It uses other plain text channels for data packets (Wi-Fi station, soft-AP, BT/BLE). The TCP/IP stack runs only on the host side and esp-hosted passes Ethernet frames (802.3) from host to slave, where they are queued directly to the Wi-Fi library.
 
 {{< figure
     default=true
     src="hosted.webp"
     >}}
 
-**`wifi_remote_over_eppp`** creates a point to point link between host and slave device, so each side have their IP addresses. Wi-Fi API calls and events are transmitted using SSL/TLS connection with mutual authentication. The data path uses plain text peer to peer connection by means of IP packets. Both host and slave device run TCP/IP stack. The slave device runs network address translation (NAT) to route the host IP packets to the Wi-Fi network -- this is a limitation, since the host device is behind NAT, so invisible from the outside and the translation has a performance impact (to overcome this, you can enable Ethernet frames via custom channels, so the data are transmitted the same way as for `esp-hosted` method, using 802.3 frames).
+**`wifi_remote_over_eppp`** creates a point to point link between host and slave device, so each side have their IP addresses. Wi-Fi API calls and events are transmitted using SSL/TLS connection with mutual authentication. The data path uses plain text peer to peer connection by means of IP packets. Both host and slave devices run TCP/IP stack. The slave device runs network address translation (NAT) to route the host IP packets to the Wi-Fi network -- this is a limitation, since the host device is behind NAT, so invisible from the outside and the translation has a performance impact (to overcome this, you can enable Ethernet frames via custom channels, so the data are transmitted the same way as for `esp-hosted` method, using 802.3 frames).
 
 {{< figure
     default=true
     src="eppp.webp"
     >}}
 
 
-**`wifi_remote_over_at`** uses `esp-at` project as the slave device, so the host side only run standard AT commands. It's implemented internally with `esp_modem` component that handles basic Wi-Fi functionality. Note that not all configuration options provided by *esp-wifi-remote* are supported via AT commands, so this method is largely limited.
+**`wifi_remote_over_at`** uses `esp-at` project as the slave device, so the host side only runs standard AT commands. It's implemented internally with `esp_modem` component that handles basic Wi-Fi functionality. Note that not all configuration options provided by *esp-wifi-remote* are supported via AT commands, so this method is largely limited.
 
 {{< figure
     default=true
@@ -189,8 +189,8 @@ The below tips emerge from this exploration:
 **1. Use `esp-hosted` as your backend solution** -- Provides optimal performance, mature integration, and comprehensive support.
 
 **2. Consider alternative backends** for specific scenarios:
-- If sending Wi-Fi commands between *host* and *slave* unencrypted is not acceptable: Checkout `wifi_remote_over_eppp` backend or [esp-extconn](https://github.com/espressif/esp-extconn/).
-- If you need to use some standard communication protocol (e.g. using non-ESP slave): Checkout `wifi_remote_over_eppp` for PPPoS protocol, or `wifi_remote_over_at` for AT commands.
+- If sending Wi-Fi commands between *host* and *slave* unencrypted is not acceptable: Check out `wifi_remote_over_eppp` backend or [esp-extconn](https://github.com/espressif/esp-extconn/).
+- If you need to use some standard communication protocol (e.g. using non-ESP slave): Check out `wifi_remote_over_eppp` for PPPoS protocol, or `wifi_remote_over_at` for AT commands.
 
 **3. Mind the Wi-Fi slave configuration** -- `esp-wifi-remote` operates as a compile-time configuration system. Developers must manually configure slave-side Wi-Fi options and rebuild the slave application. When migrating from Wi-Fi-enabled devices, configuration options must be prefixed with `WIFI_RMT_` instead of `ESP_WIFI_`.