Cyborg Signage

Did we already have this page? Not as digital signage / GFAVIP Display learning notes. Adjacent pages only:

• /signs — CBS photo-booth foam board copy ideas (not electronic)
• /cbs2025displays — Raspberry Pi kiosk + RegardingWork Display System for TVs
• /esp32display — ESP32 TFT to display.regardingwork.com (stuck-point notes)
• /cyborg-epaper · /cyborg-gadgets — agent desk hardware, including e-ink

The two X posts below are the trigger for this page — and for thinking harder about gfavip.com/display (central content + cheap endpoints).

Source posts

• @twid (Todd Dailey) — digital signage industry vs $40 ESP32 e-ink + Wi-Fi · golden age of making things with AI + standard hardware
• @cnxsoft — ZecTrix Note 4: 4.2″ ESP32-S3 e-ink “sticky note” with voice · CNX write-up

The argument (in one paragraph)

Digital signage is a huge industry that often sells mediocre products with sticky subscription fees. When the backend dies or the customer stops paying, operators fall back to masking tape on the screen (real restaurant example). Meanwhile a ~$40 Wi-Fi e-ink ESP32 board is enough hardware for conference-room door signs, menus, task boards — and AI can write the firmware and UI.

That does not mean “SaaS is worthless.” A sharp reply on the thread: the board is forty dollars; the hard part is keeping Wi-Fi credentials, certs, and an update path alive across fifty rooms for five years — that’s what the subscription is supposed to sell (often badly).

Our job for GFAVIP Display: own the hard part (content, identity, OTA, ops) and keep endpoints cheap.

Hardware classes for “signage”

Gadget directory context: /cyborg-gadgets (NOTE4 / NOTE4C already show up in the public gadgets list).

ZecTrix Note 4 — voice sticky note (snapshot)

From CNX / product notes (verify current SKU):

• 4.2″ e-ink · ESP32-S3 · 2.4 GHz Wi-Fi · Bluetooth 5.0
• Microphone + speaker · NFC · physical buttons · USB-C
• ~2000 mAh battery · GPIO expansion
• Use cases: reminders, notes, clocks, weather, images, templates
• Open-source firmware projects supported (ecosystem matters as much as PCB)

Cyborg angle: same architecture as desk agents — device does capture + display; cloud (or local) does STT/LLM; result lands on the panel. Personal “sticky note” is a cousin of conference-room “what’s next in this room.”

What GFAVIP Display should learn

Target product shape (working thesis): https://gfavip.com/display (or equivalent) as the brain — devices only load content.

MVP paths for GFAVIP Display

1. Web-first kiosk — URL per screen (works on Pi, Fire Stick browser experiments, old tablets). Prove content model before custom firmware.
2. E-ink room sign — poll GET /display/:id/frame every N minutes; show title, host, next slot, QR.
3. Event mode — CBS / mastermind: stage crawl, session now/next, sponsor slides — reuse CBS display lessons with GFAVIP identity instead of only RegardingWork.
4. Voice note path (later) — Note-4-class: voice → agent → approved sticky text on panel (same dump pattern as e-paper agent console).

Architecture sketch

GFAVIP Display (CMS)
  ├── screens / rooms / events
  ├── templates (agenda, status, menu, sponsor)
  ├── schedule + overrides
  └── device registry (API key, last seen, firmware)

Endpoints
  ├── Pi / tablet → Chromium kiosk → https://…/d/:token
  ├── ESP32 e-ink → poll JSON → render 1–3 text regions + QR
  └── Optional: Note-class → voice-in → agent → sticky frame

Ops
  ├── OTA or USB recovery image
  ├── dead-man’s switch (stale content → fallback “see host desk”)
  └── never hard-depend on a vendor that can brick the restaurant menu

Honest counter-argument (keep this)

Cheap hardware without ops is a hobby. Fifty conference rooms need:

• Network join that non-engineers can redo
• Content someone is accountable for
• Update path when TLS roots and Wi-Fi policies change
• A fallback when the internet dies (cached last frame, or static default)

If GFAVIP Display only sells “pretty screens” and not ops + identity + content, we’ll recreate the SaaS customers abandon with tape.

Near-term experiments (ordered)

1. One web kiosk URL that shows a GFAVIP/HEOS “now / next” template on an old tablet
2. One e-ink ESP32 polling that same content as text-only (Cart A class or Note 4)
3. Device registry fields: org, room name, last_seen, content_version
4. Document recovery: “how to re-flash when Mike isn’t in the building”
5. Only then: multi-room fleet + subscription-shaped support story

Related cyborg / display pages

Living notes

Product strategy, roadmap, and metrics live on /gfavipdisplay. This page stays hardware + industry field notes.