fix(blog): Minor corrections

Author: david-cermak

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

@@ -12,13 +12,13 @@ This blog post explores the esp-wifi-remote ecosystem, its components, architect
 
 ## Introduction
 
-The ESP-IDF's `esp_wifi` API powers WiFi connectivity across ESP32 chipsets. However, new ESP32 series chips like ESP32-P4 and ESP32-H2 lack native WiFi hardware. With **esp-wifi-remote**, you can use the same `esp_wifi` APIs on non-WiFi ESP chipsets as on WiFi-enabled ones. This compatibility lets developers leverage existing knowledge and codebase with minimal changes.
+The ESP-IDF `esp_wifi` API powers WiFi connectivity across ESP32 chipsets. However, new ESP32 series chips like ESP32-P4 and ESP32-H2 lack native WiFi connectivity. With **esp-wifi-remote**, you can use the same `esp_wifi` APIs on non-WiFi ESP chipsets as on WiFi-enabled ones. This compatibility lets developers leverage existing knowledge and codebase with minimal changes.
 
 ### Terminology
 
 Before diving into the details, let's establish the key terminology used throughout this post:
 
-**Backend Solution**: The communication layer that handles the transport of WiFi commands, events, and data between host and slave devices. Examples include esp-hosted, eppp, and AT-based implementations.
+**Backend Solution**: The communication layer that handles the transport of WiFi commands, events, and data between host and slave devices. Examples include [esp-hosted](https://github.com/espressif/esp-hosted-mcu), [eppp](https://github.com/espressif/esp-wifi-remote/tree/main/components/wifi_remote_over_eppp), and [AT-based](https://github.com/espressif/esp-wifi-remote/tree/main/components/wifi_remote_over_at) implementations.
 
 **Host-side**: The device running your application code (e.g., ESP32-P4, ESP32-H2, or ESP32 with WiFi).
 
@@ -119,7 +119,7 @@ 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 WiFi commands, events and data to the slave device.
+This section compares backend solutions, focusing on how different methods marshall (i.e., encode and transmit) WiFi commands, events and data to the slave device.
 
 **Principle of operation**
 
@@ -166,11 +166,11 @@ The `esp-wifi` component interface depends on WiFi hardware capabilities. `esp-w
 
 ## Other connectivity options
 
-This blog post focuses on *esp-wifi-remote* solutions only. It doesn't discuss Bluetooth, BLE connectivity, `esp-extconn` component or other means of using Wi-Fi library on remote targets.
+This blog post focuses on *esp-wifi-remote* solutions only. While there are other connectivity options available, we provide only a brief overview with references and links for those interested in exploring alternatives like Bluetooth, BLE connectivity, `esp-extconn` component, or other means of using Wi-Fi library on remote targets.
 
 ### esp-extconn
 
-This solution doesn't fall into *esp-wifi-remote* category and needs a special target for the slave side (ESP8693), but provides the best throughput (up to 80Mbps). See [esp-extconn repository](https://github.com/espressif/esp-extconn/)
+This solution doesn't fall into *esp-wifi-remote* category and needs a special target for the slave side (ESP8689), but provides the best throughput (up to 80Mbps). See [esp-extconn repository](https://github.com/espressif/esp-extconn/)
 
 ### Custom connectivity other options