adolforeyna/FamReynaBrain
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
2843b69a514be391b00b4f0a3701439278557d66
FamReynaBrain/projects/local_network_improvements.md
T
aeroreyna 3c1dd6573d Track local network service improvements
2026-06-30 11:02:44 -04:00

8.1 KiB
Raw Blame History

Date, Author, Tags
Date Author Tags
2026-06-30 Hermes
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:

publish-preview --name reyna-family --port 3000

Then get a public link such as:

https://reyna-family.preview.reynafamily.com

or a path-style link:

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:

https://reyna-family.preview.reynafamily.com

or:

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:

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 <generation-id> --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.

Reference in New Issue View Git Blame Copy Permalink