--- Date: 2026-06-30 Author: Hermes Tags: - local-network - infrastructure - self-hosting - previews --- # Local Network Improvements ## Self-hosted quick web preview service Potential improvement: build a self-hosted Cloudflare Tunnel / ngrok-style service for quickly sharing local websites online through the family server. Goal: from any local machine, publish a local web app or static preview to a clean HTTPS URL without needing an external tunnel account. ## Proposed user experience Run a command like: ```bash publish-preview --name reyna-family --port 3000 ``` Then get a public link such as: ```text https://reyna-family.preview.reynafamily.com ``` or a path-style link: ```text https://preview.reynafamily.com/reyna-family/ ``` ## Recommended architecture Use FamReynaServer as the public relay: Local machine running preview site → outbound tunnel to FamReynaServer → Caddy HTTPS reverse proxy → public subdomain under `preview.reynafamily.com` Recommended stack options: 1. FRP / frp - Best for a reusable family preview platform. - Supports multiple tunnels and subdomains. - More full-featured than a raw SSH tunnel. 2. Rathole - Lightweight, fast, simple reverse tunnel. - Good if the goal is dependable simple tunnels with less config. 3. SSH reverse tunnel - Fastest to implement because SSH already works. - Good first prototype. - Less polished for many named previews. ## Safety features to include - Random preview names by default. - Optional password protection for previews. - Auto-expire old previews after 7 or 30 days. - Caddy-managed HTTPS. - No direct exposure of local LAN services. - Local machines only make outbound connections to FamReynaServer. - Consider access logs and simple preview cleanup command. ## Related context FamReynaServer already runs Caddy and has existing `reynafamily.com` subdomains. Candidate preview domains discussed: - `preview.reynafamily.com` - `tmp.reynafamily.com` Initial recommendation: build with Caddy + FRP on FamReynaServer, with SSH reverse tunnel as the simplest prototype path. ## Other discussed services not yet implemented These are related infrastructure/service ideas that have come up in conversation and should stay on the local-network / family-server improvement backlog. ### Podcast publishing service Potential improvement: create a self-hosted podcast/audio publishing pipeline for family and ministry content. Possible use cases: - EMI teachings converted into audio-only episodes. - Sermons or conference sessions published as podcast feeds. - Kids nightly readings / family devotional mini-podcasts. - Audio versions of selected YouTube or Subsplash recordings. Possible service shape: - Host RSS feeds and episode audio on FamReynaServer. - Candidate subdomains: `podcast.reynafamily.com`, `podcast.emmint.com`, or `audio.reynafamily.com`. - Generate episode metadata from transcripts: title, speaker, date, topic, language, summary, scripture references, and links back to video. - Optionally publish to Apple Podcasts / Spotify later, but keep the source of truth self-hosted. Related future automation: - Drop an MP3/WAV into an inbox folder. - Automatically normalize audio volume. - Generate transcript and summary. - Produce show notes. - Add episode to RSS feed. - Optionally create a WhatsApp/shareable link. ### Searchable media archive service Potential improvement: build a searchable local archive for livestream recordings, teachings, transcripts, clips, and metadata. Goal: make the video/audio archive reusable instead of only storing raw recordings. Possible features: - Store recordings on NAS / Jellyfin media storage. - Generate transcripts for each teaching or event. - Search by speaker, topic, scripture, language, date, event, or phrase. - Link transcript segments back to video timestamps. - Mark sections that are private or should not be published publicly. - Support EMI content planning, YouTube publishing, podcast creation, and short clip extraction. ### AI-assisted content repurposing service Potential improvement: create a repeatable pipeline that turns long-form services or teachings into outreach assets. Possible outputs: - Full YouTube description and title. - Shorts/Reels clip suggestions. - Captions/subtitles. - Quote graphics. - WhatsApp-shareable short clips. - Podcast/audio episode. - Written summary or devotional article. - Translation drafts. This connects to the EMI media outreach strategy and the livestream/video generation process. ### Open Design / local preview publishing bridge Potential improvement: connect Open Design previews directly to the self-hosted preview service. Goal: when Open Design creates a project, publish it automatically to a clean phone-friendly URL, for example: ```text https://reyna-family.preview.reynafamily.com ``` or: ```text https://preview.reynafamily.com/reyna-family/ ``` This would avoid sending raw `127.0.0.1` or LAN-only preview links. ### Kids voice gateway speaker identification service Potential improvement: add local speaker identification before or inside the kids Hermes voice gateway. Goal: identify whether the speaker is Grace, Elias, Adolfo, Nicole, or unknown, then tailor responses safely. Recommended approach discussed: - Run the model on a local server, not on the ESP32. - Enroll short voice samples for each family member. - Use speaker embeddings, likely SpeechBrain ECAPA-TDNN as the first practical model. - Treat speaker ID as context only, not authentication. - Unknown or low-confidence speakers should default to child-safe responses. ### Kids ESP32 voice/image experience improvements Potential improvement: continue improving the child-facing ESP32 assistant experience. Possible features: - Voice requests from kid devices routed to the separate `kids` Hermes profile. - Short age-appropriate spoken replies. - Image-aware interactions when a device sends a photo. - Simple visual replies or animations on ESP32 screens. - Parent-safe tool permissions and no admin/system tools exposed to children. - Possible integration with local speaker identification. ### Brain MCP / local knowledge service Potential improvement: continue the PARA brain MCP server idea so local notes can be searched, read, and eventually written through a safer structured service. Known open questions from the brain MCP project: - Should it be a long-lived service or launched on demand by Hermes? - Should write access start read-only/search-only first? - How should Git commits and pushes be automated after writes? - How can it preserve frontmatter, Obsidian links, and PARA filing rules? ### Mac mini Voicebox voice generation service Implemented in Reyna CLI on 2026-06-30 as `reyna-cli voicebox` and `reyna-cli macmini voicebox`. Observed service state: - Mac mini host: `192.168.68.102` / `Mac-mini-M4.local`. - Voicebox app server process: `/Applications/Voicebox.app/Contents/MacOS/voicebox-server`. - Voicebox REST API: `http://127.0.0.1:17493` on the Mac mini. - Direct LAN access from the Pi to `http://192.168.68.102:17493` was still refused during verification, so Reyna CLI tries the LAN URL first and falls back to SSH-local access on the Mac mini. - Verified commands: health, profiles, generate, generation lookup. Useful commands: ```bash reyna-cli voicebox health --json reyna-cli voicebox profiles --json reyna-cli voicebox generate "Hello from Reyna CLI" --profile Nicole --engine kokoro --json reyna-cli voicebox generation --json ``` Potential future improvement: if Voicebox should truly be reachable directly from LAN, adjust the Voicebox server bind host or run a small localhost-only reverse proxy on the Mac mini that binds to the LAN interface with appropriate access controls. ### Local service registry / subdomain map Potential improvement: maintain a single local service registry for family infrastructure. Goal: reduce scattered knowledge about which services run where. Possible contents: - Service name. - Host machine. - Internal IP and port. - Public subdomain. - Caddy reverse proxy target. - Auth method. - Backup/restore notes. - Owner / intended audience. - Whether it is private, family-only, EMI, or public. This would pair well with Caddy, FamReynaServer, and the brain.