adolforeyna/FamReynaBrain
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

daily auto-sync 2026-05-31

Browse Source
This commit is contained in:
aeroreyna
2026-05-31 23:00:01 -04:00
parent 27a904a580
commit 4a63bc324d
1 changed files with 24 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
projects/business_ideas.md
+24
View File
@@ -61,3 +61,27 @@ Tags: #business #mission #christian #tech
- Define compensation model (commission-only vs base + commission).
- Provide simple sales kit (story of origin, pricing tiers, sample workflow, reorder process).
- **Status**: Idea captured from A Reyna (DM) on 2026-05-27.
## MCP LAN Discovery Protocol
- **Concept**: A Bonjour-like local discovery protocol for MCP servers so LLM harnesses can discover nearby tools, devices, and services on the LAN without manual configuration.
- **Core Idea**: Hardware or local computers advertise themselves as MCP-capable services over mDNS/DNS-SD, then expose a manifest describing endpoint, transport, capabilities, auth, and safety requirements.
- **Possible Service Type**: `_mcp._tcp.local`
- **Potential Manifest Path**: `/.well-known/mcp.json`
- **Example Advertised Devices/Services**:
- Mac Mini MCP server.
- Raspberry Pi home harness.
- Smart displays, speakers, cameras, sensors, printers, scanners, NAS, or robotics hardware.
- Local app/server capabilities such as Immich, MongoDB Assistant, or household automation services.
- **Trust Model**:
- Discovery should not equal authorization.
- Devices should expose only basic metadata before pairing.
- Actual tool access should require explicit user approval, pairing code, OAuth/device flow, passkey, certificate trust, or a local token.
- **Why It Matters**:
- Makes local AI hardware plug-and-play for agents.
- Lets LLM harnesses discover available “hands” in the local environment.
- Reduces manual MCP config editing.
- Creates a path for safe, self-describing local devices that can be used by Hermes or other agent runtimes.
- **First Prototype Device**: Waveshare ESP32-S3-RLCD-4.2 board from Amazon link https://a.co/d/0claSFAh; specs found 2026-05-31: ESP32-S3-WROOM-1-N16R8 with 16MB Flash and 8MB PSRAM, 4.2-inch 300×400 reflective LCD, Wi-Fi/BLE, dual microphones, RTC, SHTC3 temperature/humidity sensor, TF card slot, and battery support.
- **MicroPython Firmware Note**: Official MicroPython ESP32_GENERIC_S3 firmware supports ESP32-S3 boards with external RAM and auto-detects SPIRAM, but MicroPython says to use the `ESP32_GENERIC_S3-SPIRAM_OCT` variant for boards with Octal SPIRAM. This board’s N16R8 module likely needs the SPIRAM_OCT build to use the 8MB PSRAM.
- **MicroPython Screen Driver Finding**: The display controller is ST7305. Exact MicroPython driver found on 2026-05-31: `micheleaiello/ESP32-S3-4.2inch-RLCD-Driver` (https://github.com/micheleaiello/ESP32-S3-4.2inch-RLCD-Driver). It targets the Waveshare ESP32-S3 4.2-inch RLCD, uses `framebuf`, pins MOSI=12, SCK=11, DC=5, CS=40, RST=41, and includes `rlcd.py`, `shtc3.py`, `sensors.py`, and `vector.py`. Related generic driver: `elulis/micropython_ST7302` supports ST7302/ST7305 but only documents smaller 2.13/2.9-inch reflective TFTs, so the exact Waveshare repo is the better starting point.
- **Status**: Idea captured from A Reyna (DM) on 2026-05-31; first hardware prototype identified on 2026-05-31; MicroPython screen driver identified on 2026-05-31.