announce: r/LocalLLaMA submission template

Author: WaylandYang

.github/announce/reddit_localllama.md

@@ -0,0 +1,171 @@
+# r/LocalLLaMA submission
+
+r/LocalLLaMA audience: people running Llama / Mistral / Qwen on consumer
+GPUs locally, MCP-savvy, anti-cloud-bias, hate marketing speak, love
+numbers and code. The post below is tuned to that.
+
+Subreddit rules: self-promo OK if you provide real technical context and
+clearly mark yourself as the author. Don't pitch.
+
+## URL field
+
+Leave empty. Use the text-post format so the body is what people read.
+
+## Flair
+
+Pick **`Resources`** or **`New Model`** — whichever the subreddit has
+active. (`Discussion` second choice.)
+
+## Title
+
+```
+I wanted my local LLM to control a $5 microcontroller safely. Built an open protocol for it.
+```
+
+(~88 chars, within Reddit's 300-char limit. The "I wanted... built" framing
+is personal-narrative, which r/LocalLLaMA upvotes more than "Show:" / "I made:".)
+
+## Body (paste exactly)
+
+```
+**TL;DR** — open protocol + Python bridge + ESP32 firmware so any
+MCP-compatible client (Ollama, LM Studio, Claude Desktop, llama.cpp +
+plugins, ...) can talk to a dollar-class microcontroller. 19-byte
+wire frames, ~14 KB firmware on ESP32, no cloud needed. MIT.
+
+Repo: https://github.com/device-context-protocol/dcp
+
+## Why I built this
+
+I have a box running Llama 3.3 70B + a drawer of ESP32s. Wanted
+natural-language control without sending anything to a cloud API.
+Surveyed what existed:
+
+- **Custom Python middleware per project** — every script reinvents
+  framing, no schema, no safety, no interop.
+- **"ChatGPT controls Hue lights"** — cloud LLM + vendor lock-in,
+  ignores the local LLM case entirely.
+- **IoT-MCP (arXiv:2510.01260)** — best academic attempt. But 74 KB
+  peak memory excludes the cheap Cortex-M0+ class I actually have
+  in bulk, and the underlying protocol is unchanged MCP, so it
+  inherits JSON-RPC overhead. No safety primitives beyond MCP's
+  defaults.
+
+So I wrote a protocol with the constraints I actually have:
+local LLM, cheap hardware, no cloud, MCP-compatible.
+
+## What's on the wire
+
+```
+LLM ── MCP ──▶ Bridge (asyncio)  ── 19B wire frame ──▶ ESP32
+                 │
+                 ├─ capability token (HMAC-SHA256, scoped, expiring)
+                 ├─ range / type / unit check from manifest
+                 └─ dry-run as a wire-format bit (kind=0x81)
+```
+
+Wire frame: 6-byte fixed header + CBOR map + optional 16-byte HMAC.
+A `set_brightness(50)` call is 19 bytes. MCP JSON-RPC equivalent
+is ~180 bytes. The difference is the difference between "fits on a
+$5 chip" and "doesn't."
+
+Bridge auto-translates MCP↔DCP. Tested with Claude Desktop, but the
+LLM side is just MCP — Ollama's MCP support, LM Studio's MCP
+extension, any other MCP host: all work zero-config.
+
+## Numbers (measured, not target)
+
+- **19 bytes** typical call frame, 35 with HMAC, 30 for CoAP-equivalent
+- **14 KB** pure DCP code over an empty Arduino-ESP32 sketch (full
+  binary 294 KB including Arduino runtime + FreeRTOS)
+- **22.7 KB** global vars, leaves 305 KB for stack/heap
+- **88 / 88** Python unit + conformance tests green
+- **10 / 10** round-trip tests against real ESP32-WROOM-32 over UART
+- **5 transports** ship: loopback (test), UART (COBS+CRC), MQTT,
+  BLE GATT, MCP-server-wrapper
+
+## What's NOT done yet (honest)
+
+- Only one MCU validated so far (ESP32-WROOM-32). T-Panel S3 + CAN
+  bus port coming next 2 weeks.
+- No empirical A/B vs IoT-MCP yet — that's the follow-up paper.
+- Spec is **draft (v0.3)**. v1.0 freeze gated on a second-language
+  port (community C or Rust would be amazing).
+- No demo video yet — firmware just landed working last week. Coming
+  with the v0.4 T-Panel demo.
+
+## Try it (10 minutes)
+
+```bash
+pip install "pydcp[mcp,serial]"
+dcp serve examples/lamp_manifest.yaml --simulator
+# point your MCP client at the running `dcp` process
+# LLM sees: set_brightness / set_color / read_brightness tools
+```
+
+Replace `--simulator` with `--serial COM5` (or `/dev/ttyUSB0`) once
+you flash an ESP32. Firmware source + Arduino library at
+`firmware/esp32/` in the repo.
+
+## What I want from this post
+
+If you have a local LLM + an ESP32 in a drawer:
+
+- Try it, tell me what MCP client you used and whether it worked
+- Tell me what primitive you wish the manifest schema had
+- Tell me what's wrong with the design (I'd much rather hear "your
+  capability model is naive because X" than "great project!")
+
+Also: looking for a **cs.NI arXiv endorser** if anyone here has
+published in cs.NI in the last 3 years.
+
+## Links
+
+- **Repo + spec**: https://github.com/device-context-protocol/dcp (MIT)
+- **PyPI**: https://pypi.org/project/pydcp/
+- **Paper draft** (12 pages, PDF): https://github.com/device-context-protocol/dcp/releases/download/v0.3.0/main.pdf
+- **Design rationale** (why not MCP / WoT / Matter / Sparkplug B / OpenAPI): docs/RATIONALE.md
+- **5-step "how to add a new intent"**: docs/ADDING_FEATURES.md
+
+Author here. Not posting on HN yet — my account is karma 1 and Show
+HN posts auto-hide. r/LocalLLaMA gets first read.
+```
+
+## Image to attach (optional but recommended)
+
+Reddit lets you put one image in a text post. Use **arch.png** from
+the repo (`docs/paper/figures/arch.png`). Caption: "the architecture
+in one image".
+
+## Timing
+
+- **US morning** (8-11 AM EST / Mon-Thu) is when r/LocalLLaMA is most
+  active in comments
+- Avoid weekends (vote slow, comments thin)
+- Avoid right after a big OpenAI / Anthropic / Mistral release
+  announcement (gets buried)
+
+## Reply tips
+
+- **Disclose the relationship to MCP again in replies** — people will
+  ask "isn't this just MCP?" Be specific: "MCP is the LLM-side, DCP
+  is the wire-format-side. Bridge translates."
+- **Don't compare to LangChain / LlamaIndex** — wrong audience layer.
+  This is below where those operate.
+- **If someone asks "but my LLM doesn't have MCP support"** — point
+  them at https://github.com/punkpeye/awesome-mcp-clients
+- **If criticized for "yet another protocol"** — read `RATIONALE.md`
+  out loud, don't argue
+- **If someone asks for benchmarks against direct UART text protocols**
+  — say "honest answer, those win on raw throughput; DCP wins on
+  schema, capability scoping, and dry-run. Different tradeoffs."
+
+## Cross-posts (after r/LocalLLaMA, with 1-2 day gap)
+
+- **r/embedded** — same content, different framing ("Open protocol for
+  LLM-driven embedded systems")
+- **r/esp32** — focus on the ESP32 firmware + flash size
+- **r/Anthropic** — focus on MCP compatibility (smaller subreddit but
+  responsive)
+- **r/RaspberryPi** — port to Pi (just use the Python Bridge; the
+  Pi can host the Bridge for multiple ESP32 devices)