Track local network service improvements
This commit is contained in:
aeroreyna
@@ -0,0 +1,243 @@
|
|||||||
|
---
|
||||||
|
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 <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
Block a user