Flow
From read-only to replies
1Short list of jobs
Status, chats, messages, prepare, confirm. Nothing else.
2Keys stay on the Mac
The gateway password lives in the Mac's keychain.
3Ship with sending off
The switch lives in the agent's config on the Mac.
4Run the checklist
Wrong address gets nothing, gateway unreachable, replays fail, logs clean.
5Then allow replies
Still two steps, with a one-use ticket each time.
Reading my texts on my hub's control panel was what I wanted. But the messages live on one Mac, signed in to my Apple account, and the hub runs on a VM somewhere else.
The easy way is to run a gateway on the Mac and hand the hub its password. That gives a web app all the power of my account. I didn't want that, so the hub gets as little as I could manage.
The Mac keeps the keys
A small agent runs on the Mac. It sits in front of the gateway, and the gateway only listens to the Mac itself, never the network. The gateway's password stays in the Mac's keychain. The hub gets a signing secret and the agent's certificate, and nothing else. The gateway wants its password in the URL, so the agent only talks to it on the Mac and won't follow a redirect.
A short list of things it will do
The agent can report status, list recent chats, show recent messages from one chat, prepare a reply and confirm a reply. That's it. No photos, no deleting, no new chats, no texting a new number. Each of those would be its own decision later.
Every input has a size limit, checked on both the hub and the Mac. Reading messages uses a POST, so chat IDs, which can hold phone numbers, stay out of the hub's logs.
Every request is signed
Each request carries a time, a random one-time value and a signature. The agent checks:
- the caller's address is the one allowed,
- the time is within about a minute,
- the signature matches,
- the one-time value hasn't been used.
So a copied, stale or edited request gets refused. The agent keeps no request logs. The one weak moment is right after the agent restarts, when it forgets which values it has seen.
Replies take two steps
First the hub asks to prepare a reply to a chat that already exists. The agent stores the chat and the exact words and hands back a one-use ticket. Then the hub sends back the ticket, and the agent sends the words it stored. The ticket dies after about a minute, after one use, or when the agent restarts. It's burned before the send, so a failed send means preparing it again. I'd rather retype than send twice.
Sending starts switched off, and the switch lives on the Mac. The runbook lists checks that must pass first: wrong addresses get nothing, the gateway can't be reached from outside, replays fail, and logs hold no message text.
Locking down the panel
Only admins can open the panel or see its link. If a link names a role the hub doesn't know, it's treated as admin-only.
Setting up the Mac
Setup is a guided page plus a double-click helper. The helper checks the gateway password before saving it and never sends anything. The two setup files go to the hub by hand, not by email or chat.
What it can't stop
The signing secret is shared. If someone took over the hub, they could read recent chats, and with sending on they could do both reply steps themselves. The ticket proves the same caller came back. It doesn't prove I was the one who clicked.