Off-grid radio for sovereign AI. LoRa mesh comms via Meshtastic — no internet required.
v0.1.0Send and receive messages via Meshtastic LoRa mesh network. Use for off-grid messaging, mesh network status, reading recent mesh messages, or sending texts via LoRa radio.
⭐ 3· 1.7k·0 current·0 all-time
by@lukevr
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Suspicious
medium confidencePurpose & Capability
Name/description match the included files: bridge, CLI, MCP server, monitor and digest scripts. All binaries, files, and network endpoints (mqtt.meshtastic.org, optional map broker) are consistent with a Meshtastic LoRa bridge and local agent integration.
Instruction Scope
SKILL.md instructs the agent to read local artifacts (/tmp/mesh_messages.txt, /tmp/mesh_*), run systemctl commands, and set up cron or spawned agent sessions that 'Check /tmp/mesh_messages.txt' and 'deliver: true' to channels such as Telegram. Those instructions grant the agent broad discretion to collect, filter, translate, and forward local radio traffic to external channels — this is within the advertised feature set (alerts/digests) but the examples are vague and can lead to automated exfiltration of messages if misconfigured. Also instructs creating a systemd service and socket server on localhost (expected) but these increase runtime privileges and persistence on the host.
Install Mechanism
There is no external install spec; the repository contains Python scripts and README/SETUP instructions (pip install meshtastic paho-mqtt). No downloads from unknown URLs or archive extraction; install is manual/standard Python package usage. This is low risk from an installer perspective, but the code will be executed locally when run.
Credentials
The skill declares no required env vars, which aligns with the metadata. However CONFIG.md contains hard-coded MQTT credentials (mqtt.meshtastic.org, user 'meshdev', pass 'large4cats') and default broker/topic entries — these appear to be convenience/test defaults and not strictly necessary, but you should treat them as configuration values to review. The MCP server supports overrides via env vars (MESH_SOCKET_HOST, etc.), which is reasonable. There are no unrelated credentials requested, but the skill will read local config and /tmp files as part of normal operation.
Persistence & Privilege
always:false (good). The skill's instructions explicitly encourage installing a systemd service and scheduling cron/agent sessions to run periodic monitoring and digesting. That persistence is consistent with a bridge/monitoring tool, but combined with autonomous agent invocation and 'deliver: true' examples it can cause repeated autonomous reads of local logs and posting to external channels. The skill does not modify other skills or request system-wide tokens, but it does create long-running local services and files under /tmp and may run as a systemd-managed process (requires user to set proper User in service).
What to consider before installing
This package appears to implement the Meshtastic bridge you expect, but review a few items before installing:
- CONFIG.md contains default MQTT credentials and broker settings — verify and replace them with your own values or set map publishing off if you don't want to relay to public brokers. Treat those as configuration, not secrets provided by the skill.
- The skill logs inbound mesh traffic to /tmp/mesh_messages.txt and provides mechanisms (cron, spawned agent sessions, MCP tools) to read, filter, translate, and post those messages to external channels (Telegram, Discord, etc.). If you enable automated delivery, the agent may forward radio traffic off your machine. Make sure you control destination channels and understand potential privacy/legal concerns for relaying third-party radio messages.
- The SKILL.md examples for monitoring are intentionally permissive ("Alert me of interesting ones with translations") — consider tightening the rules: explicit keyword lists, stricter filters, and disable automatic 'deliver: true' until you test manually.
- The package suggests installing a systemd service that will run a long-lived bridge process. Ensure the service runs as a non-privileged user and check file permissions on /tmp logs and state files so other local users cannot read them if that matters.
- The MCP server exposes tools that can operate the device and read logs; only run the MCP server if you trust the local environment and any clients that will connect to it. Audit which MCP clients you register it with (e.g., Claude Desktop) to avoid unintended remote control.
If you want to proceed safely:
- Audit the CONFIG.md and replace any defaults.
- Run the bridge in an isolated environment (dedicated user account, container, or VM) until you are comfortable.
- Disable map publishing and external MQTT publish by default.
- Test manual commands (mesh.py send/status/messages) before enabling cron/agent automation or MCP exposure.
Confidence notes: assessment is based on included SKILL.md and Python scripts; nothing obviously malicious was found, but the skill's automation examples can cause privacy-relevant data to be forwarded if misconfigured, so treat as suspicious until you confirm configuration and intended delivery targets.Like a lobster shell, security has layers — review code before you run it.
latestvk970r1n1d4wj7ytz7436zx33bs80ex1e
License
MIT-0
Free to use, modify, and redistribute. No attribution required.