A Plan to Publish From My Phone

TL;DR

• Goal: record a voice note on my phone and have it published without touching a computer.
• Existing Go server exposes an endpoint, maybe at api.ryer.io, as the trigger.
• iCloud metadata plus unique identifiers in Postgres tracks which recordings are already processed.
• Go orchestrates; Python does the transcription and LLM work via the OS command interface.
• The endpoint needs real authentication before it goes anywhere near the public internet.

I started recording voice notes on my phone rather than my computer today, to test iCloud saving and processing on the Mac. Stepping outside the usual setup, and it feels good.

That raised the obvious question: why does the publishing step still need a computer at all? Here’s the plan.

The pieces

An endpoint on the Go server. I already run one, so exposing a specific endpoint — possibly at api.ryer.io — gives me a trigger I can hit from anywhere.

iCloud file access. The hard part. The approach is to authenticate, fetch metadata, and store unique identifiers alongside file paths in Postgres. That’s what makes the operation idempotent — without a record of what’s been processed, every trigger would reprocess everything or require me to track state by hand.

Python for the work. The Go server invokes the existing Python script through the OS command interface. Go orchestrates, Python does the transcription and the OpenAI calls. No reason to port working code across languages just for architectural tidiness.

The publish cycle. Save the transcript and markdown, commit to GitLab, and let the existing CI pipeline deploy. That part already works — this is about triggering it from somewhere new.

The part I have to get right

Security. An unauthenticated endpoint that runs scripts, calls paid APIs, and commits to my repository is not something to leave open. Authentication through my existing app is the plan, so the endpoint only answers to me.

That constraint is worth stating plainly because it’s the one that could turn a convenience feature into a genuine problem. Everything else here is plumbing.

A lighter option

Rather than a full app, a small React Native interface sending authenticated requests would be enough — one button, one endpoint. Worth exploring as the minimal version.

The appeal of all this is that the friction between having a thought and publishing it drops to roughly zero. Whether that’s entirely a good thing is a separate question.