Self-Heaing ESP32 Nostr-Arduino Based Mesh-Network
The similicty of the nostr-protocol, makes it ieal for use with mesh-networking.
While utilizing WiFi for node connections imposes a range limitation of less than 200 meters, it significantly boosts bandwidth, thereby enabling the sharing of internet access across the mesh network.
ESP32 microcontrollers are both highly affordable and widely accessible. With a mere $1 cost for the basic controller, nodes can be effortlessly integrated into passive electronics such as light bulbs, facilitating the creation of a robust mesh network.
- Establish a WiFi station
- Set up a websocket server
- Connect to a websocket
- Run a stateless nostr relay for sending and receiving events using Nostr-Arduino
- Run a nostr client using Nostr-Arduino
ESP-MDF (ESP Mesh Development Framework) and MQTT (Message Queuing Telemetry Transport) are the two popular approaches to creating mesh networks with ESP32 microcontrollers.
-
ESP-MDF (ESP Mesh Development Framework): ESP-MDF is a comprehensive mesh development framework provided by Espressif Systems specifically for ESP32 microcontrollers. It is built on top of the ESP-IDF (ESP32 IoT Development Framework) and provides a high-level API for creating and managing mesh networks. ESP-MDF supports the ESP-MESH protocol, which is based on the IEEE 802.11s standard, enabling devices to form self-healing and self-organizing mesh networks. The framework includes features such as automatic topology construction, network management, and remote configuration. ESP-MDF simplifies the development process by providing a set of tools and APIs to handle mesh network operations, allowing developers to focus on the application logic rather than the underlying mesh infrastructure.
-
MQTT (Message Queuing Telemetry Transport) Protocol: MQTT is a lightweight and efficient messaging protocol commonly used in IoT applications. It can also be leveraged to create mesh networks with ESP32 microcontrollers. In this approach, each ESP32 node in the mesh network can act as both a publisher and a subscriber. The nodes connect to a central MQTT broker, which manages the message distribution across the network. MQTT's publish-subscribe model enables easy communication between nodes, allowing data to be efficiently shared. MQTT supports topics, which act as message channels, enabling data organization and efficient filtering of relevant messages. This approach provides flexibility in terms of network architecture and allows for the integration of other MQTT-enabled devices in the mesh network.
To connect to a peer a node must:
- Be in close enough proximity
- Share a "similar" SSID and identical WiFi password
WiFi station format:
SSID: <shared-mesh-key>-<node-id>
Password: <shared-mesh-password>
Once connected to a node a node will subscribe to the other nodes nostr relay (hosted at 127.0.0.1:4545)
The opening event request-header User-Agent must be set as a "nostrmesh node"
The nodes will continue to look for other nodes to connect to. Each node will connect to the 3 nodes with the strongest WiFi signal
the mesh can be separated into multiple networks.
If networks sharing the same <shared-mesh-key> are in close enough they will heal.
External devices can connect to any node using the nodes SSID, WiFi password and then the nodes relay on 127.0.0.1:4545.
To share data through the network tag: r proposed here nostr-protocol/nips#594, or something similar will used.
When a device connects to a node that is not User-Agent: nostrmesh node, the node being connected publishes NIP-01 event with content simply set as "content": "map", all nodes then publish from there clients a NIP-01 event listing the nodes they are directly connected to
{"node-id": <node-id>, "friends": "<node-id>,<node-id>,<node-id>"}
Each node builds a json map of the netork from the data.
[
{"node-id": <node-id>, "pubkey": <nodes-public-key>, "friends": "<node-id>,<node-id>,<node-id>"},
{"node-id": <node-id>, "pubkey": <nodes-public-key>, "friends": "<node-id>,<node-id>,<node-id>"}
]
Using mapping, and something like tag: r, a client can send data in a unicast or broadcast way through the relay network.