I don’t particularly trust mega-corporations with a history of everywhere I go.

I do, however, want reminders that arrive when I can act on them. Imagine a reminder to replace an air-purifier filter: useful at home, pointless halfway through a day out.

Those positions are not contradictory. Location is useful. A persistent account of my movements, available for purposes I did not have in mind when I enabled a feature, is a different proposition.

This morning I started connecting those two thoughts in a practical way: the OpenClaw app on my iPhone, a private Tailscale connection to my server, and a deliberately small home/away signal for my own automations.

The first foreground and unattended checks have worked. That is a useful start, not a promise of always-available location.

The phone becomes a node

Until now, Telegram has been my main interface to Closp, my OpenClaw assistant. The gateway runs on a VPS, where it coordinates scripts, scheduled jobs, and other devices, including my Raspberry Pi.

The native iPhone app adds something beyond another chat window: the phone can become a node. It offers specific capabilities to the gateway, subject to device permissions and gateway approval. Location is one; voice interaction, camera access, and opt-in Health summaries are other possibilities.

The assistant is not suddenly running entirely on the phone, and this is not unrestricted remote control of iOS. The useful change is that my existing system can ask a device I carry with me for a particular piece of context.

That makes the question of permission much more concrete. I can want a home/away check without wanting to expose everything the phone knows.

Tailscale supplies the connection

My first attempt to generate a pairing QR code failed because the gateway was bound to loopback. It was available to processes on the server, but not directly to my phone.

I did not need to make the OpenClaw port publicly reachable. We installed Tailscale on the VPS, joined it to the same private network as the iPhone, and enabled OpenClaw-managed Tailscale Serve. That gives the app an HTTPS and secure WebSocket route while the ordinary gateway listener stays on loopback. Gateway authentication remains enabled.

Tailscale Serve is the private-network option. Tailscale Funnel, which exposes a service publicly, is not what I am using here.

For the location reminder, the path is roughly:

iPhone location capability
    → encrypted Tailscale connection
    → OpenClaw gateway on my VPS
    → local home / away / unknown decision
    → reminder eligibility

Tailscale uses end-to-end encryption between devices, including when traffic needs a relay. That is a useful transport property; it is not a statement about what happens to data after an application receives it. Tailscale’s security explanation makes that distinction worth understanding.

A location is more information than this reminder needs

Consider that hypothetical filter reminder. A maintenance schedule can say that a replacement is due. It cannot tell the assistant whether this is a useful moment to ask.

The presence gate I built has three possible states:

  • Home: a fresh, sufficiently accurate fix is confidently inside the home region. A home-only reminder can proceed if its other conditions hold.
  • Away: the fix is confidently outside that region. Suppress the home-only reminder.
  • Unknown: the fix is stale, inaccurate, unavailable, or too close to the boundary to decide. Defer the routine reminder.

Unknown is important. A phone dropping its connection does not mean I have left home. Nor does a location from earlier in the morning prove I am still there.

We calibrated the home reference from a real fix while I explicitly confirmed I was at home. Its reported accuracy was about ten metres. The implementation uses separate inner and outer boundaries and includes the uncertainty of both the reference and the new fix. It expires old observations instead of quietly turning them into permanent facts.

The coordinate-to-presence calculation is ordinary Python on my server. It does not need a language model. The helper’s persistent current-state record contains the coarse result and the timestamps and accuracy needed to judge it, not a trail of coordinates. The home reference itself does need to be stored, in a restricted-permission configuration file.

For this workflow, raw fixes are processed without putting them into the model conversation. That is a more useful privacy measure than collecting everything and hoping a prompt will persuade the assistant not to misuse it.

The phone remains a proxy for me, not proof that I am available or permission to perform some unrelated action. And this gate applies to home-only chores; bills, appointments, and things I can handle remotely should not disappear because I went out.

There is another boundary to respect: notification delivered does not mean task completed. In the hypothetical filter example, sending a reminder must never mark the filter as replaced. Completion needs explicit confirmation or separate evidence; knowing somebody is home is not enough.

The setup exposed two different kinds of uncertainty

The first was permission state. I had enabled location sharing in the app and selected Always in iOS Settings, yet the gateway still appeared to say location was off.

The missing step was a separate node-capability approval. Closp initially checked the device-pairing queue, but the request to add location was waiting in the node queue. The status we were reading reflected the previously approved capabilities, not everything the phone was now offering.

Approving that specific upgrade resolved the mismatch. Pairing a phone once should not silently grant every capability I enable later. The separation made the setup less obvious, but it also provided a real control over what the server could request.

The second uncertainty is still operational. Foreground location retrieval worked and home calibration succeeded. Unattended requests then encountered an app lifecycle-transition error and timeouts.

“Always” is a location permission, not a promise that an iPhone app will behave like a continuously running server. Apple explicitly describes background pushes as system-managed and subject to throttling. That does not prove throttling caused my failures; it does explain why repeatedly waking the phone is not a sound reliability test.

We added one bounded retry for the specific lifecycle-transition error and spaced out the next unattended test. That later check succeeded: the system classified the phone as home using an observation about a second old, without asking me to reopen the app. It was a fresh result, not the earlier calibration being reused.

That is progress, not proof of continuous background availability. Failed refreshes still produce unknown, and I am keeping longer-term reliability under observation. One successful unattended check does not establish weeks of dependable behaviour.

The focused test suite has 36 passing tests covering the decision and failure paths. Those tests are useful evidence about the code, not a substitute for observing the phone in ordinary use.

What I mean by more private and more secure

For my use case, this arrangement improves privacy by narrowing the purpose and the data flow. It improves security in a specific way: the gateway does not need a new public entry point, access is authenticated, and capabilities are explicitly approved.

It does not make the whole system independent of companies I do not control.

Apple still supplies the phone platform, permissions system, and push infrastructure. The official OpenClaw iOS build also uses a hosted push relay. My VPS runs on somebody else’s hardware. Tailscale’s coordination service handles device and network metadata, even though it cannot decrypt the encrypted application traffic passing through its relays.

And self-hosting an AI gateway does not make a cloud model local. Anything I send to a model or voice provider crosses another boundary. A health summary sent through the assistant can reach that provider and remain in conversation history. “On my server” is not an adequate description of the entire journey.

The practical advantage is being able to make smaller decisions: which capability to approve, which calculation to perform locally, which information to retain, and which result genuinely needs to reach an AI service. I can inspect the implementation and revoke access without giving up every other part of the system.

That also gives me work to do. A poorly maintained personal server is not automatically safer than a well-run hosted service. Updates, authentication, backups, logs, and device access remain my responsibility. I am choosing a more limited and inspectable arrangement, not claiming immunity from mistakes.

The next jobs are already in my task list

Location is the starting point. The related tasks I created make the broader direction clearer.

Explore Talk mode. I want to try a more natural voice interface to the same assistant and its existing context. This is still an experiment, not a claim that I have built an always-listening phone assistant. Speech and voice-provider choices need the same attention to data flow as text chat.

Move health summaries towards the native app. My existing Apple Health reporting workflow involves an export and upload step. The native app’s HealthKit summary capability aggregates selected metrics on the device and returns a read-only summary. But its documented scope is the current calendar day, not my complete historical archive. Replacing weekly imports means checking coverage and continuity, not just turning on a switch. This migration is planned, not completed, and the health command needs its own approval.

Bring the Pi and CCTV access onto the private network. Two connected tasks are to install Tailscale on the Raspberry Pi, assess whether it can replace the current SSH tunnel, and move access to the video-history portal directly onto the Pi over Tailscale. The aim is to retire the existing public-facing entry point once the replacement works. That has not happened yet.

Work out which other location-aware behaviours are actually worth having. An errand relevant to where I am, or a home task reconsidered after I return, could be useful. Each needs its own rule and failure behaviour. I do not need a universal location diary first. For now, a return is handled by reevaluating conditions on the next scheduled reminder check; there is no instant arrival-triggered system to boast about.

These are extensions of a system I already use, rather than reasons to start collecting a new category of data just in case.

My immediate goal is modest: leave the house, use my phone normally, and have the assistant make fewer irrelevant demands on my attention. If it cannot establish enough context to send a routine home-maintenance reminder, it can wait. Silence can be a useful feature too.