Skip to content
The world does revolve around you.

Data flows#

This page traces every flow of data Ostler is involved in, end to end. It is paired with the Privacy model and is meant to agree with it down to the byte – if a flow appears here, the Privacy model accounts for it; if a flow does not appear here, Ostler is not doing it.

The general rule across every flow on this page: public data flows in, personal data does not flow out. The exceptions are explicitly marked.

How to read this page#

Each flow is described in three parts:

  1. What triggers it – what user action or schedule kicks the flow off.
  2. What crosses the wire – what bytes leave one component and enter another, and over what link.
  3. What ends up where – the resulting state, and on which device that state lives.

A flow is local if every wire mentioned is either inside one device or on your home network between two devices you own. A flow is outbound if it leaves your network. Outbound flows are flagged.

Local-only flows#

These are the flows that are entirely on your hardware. Nothing involved in any of these crosses your home network's perimeter.

Capture from macOS apps via Full Disk Access#

Trigger: Background sync on the Hub, or a manual "refresh" you ask for.

What crosses the wire: Nothing leaves your Mac. The Hub reads directly from each macOS app's local database file, in read-only mode, with the Full Disk Access permission you granted at install:

Source What is read
Safari History URLs, page titles, bookmarks, reading list
iMessage Conversation rows, participants, timestamps
Apple Mail Subjects, senders, recipients, dates (not bodies, by default)
Apple Notes Note titles, text, folders
Calendar Events, attendees, locations
Photos Face labels, GPS, dates (not image content)
Reminders Tasks, due dates, lists

What ends up where: Extracted records land in the Hub's local stores – the structured graph for relationships, the vector store for semantic search, the relational database for the conversation pipeline. All on your Mac.

Apple Mail FDA, not Google OAuth

For Gmail content, Ostler reads from your local Apple Mail database rather than authenticating to Google over OAuth. There is no third-party server in the email content path. See Apple Mail FDA vs Google OAuth for the full reasoning.

Capture from GDPR exports#

Trigger: You drop a downloaded export (LinkedIn, Facebook, Instagram, WhatsApp, Twitter / X, iCloud, an MBOX, a browser history file) into Ostler's import flow.

What crosses the wire: Nothing. The file is on your Mac; the parsers run on your Mac; the resulting records are written to the Hub's local stores.

What ends up where: Same as the FDA flow above – extracted records land in the local graph and vector stores.

Calendar via CalDAV (iCloud, optionally Google)#

Trigger: Background sync, when you have configured a calendar account inside Ostler.

What crosses the wire: Standard CalDAV traffic between your Mac and the calendar provider you chose. This is the same protocol your Mac's built-in Calendar app uses. Credentials are stored locally in macOS Keychain, used by the Hub on your behalf.

What ends up where: Calendar events, attendees, and locations are ingested into the local graph for "who am I meeting and when" queries. The credentials never leave your Mac except in the encrypted CalDAV session itself.

This is your account, not ours

The CalDAV connection is between your Mac and the calendar provider you chose. Creative Machines is not in the loop. We do not see the events, the attendees, or even the fact that you connected the account.

Hub-to-iPhone: real-time queries on home Wi-Fi#

Trigger: You open the Ostler iOS app on your iPhone and search, browse, or ask a question.

What crosses the wire: Short HTTP-over-TLS requests between your iPhone and your Mac, over your home Wi-Fi. The TLS connection uses the Hub's self-signed certificate, public-key-pinned by the iOS app at pairing time. Only your Mac can answer.

What ends up where: The query result is rendered on the iOS app. A small encrypted cache on the iPhone keeps recent items warm so the app feels fast. Your full data still lives on the Hub – the iOS app is a window, not a copy.

Hub-to-iPhone: capture queue when away from the Hub#

Trigger: You capture something on the iOS app while the Hub is asleep or off-network – a voice note, a photo, a quick text reminder.

What crosses the wire: Nothing, immediately. The capture is written to the iOS app's local encrypted cache. The next time the iOS app can reach the Hub on your home network (or via Tailscale), it drains the queue over the same TLS-pinned channel as a real-time query.

What ends up where: The captured item arrives on the Hub, the Hub processes it, and the canonical copy lives on the Hub from then on.

Local AI inference#

Trigger: Anything Ostler does that needs language understanding – extracting facts from a conversation, summarising a person, answering a question you typed.

What crosses the wire: Nothing. The Hub talks to a local Ollama process on the same Mac, over localhost. The model weights are a file on your disk, downloaded once during setup.

What ends up where: The model output goes back to the Hub component that asked for it, and is written to the appropriate local store. Your prompts and the model's responses do not leave your machine.

Voice capture and speaker identification#

Trigger: You start a conversation capture in the iOS app or tap the quick-capture complication on the Apple Watch. Region-aware consent applies first – see voice and speaker identification.

What crosses the wire: Microphone audio streams from the iPhone (or Watch via the iPhone) to the Hub over the same TLS-pinned local channel as an iOS app query. On the Hub, audio is transcribed with a local Whisper model and matched against your saved voice profiles by the local speaker-ID model. The audio buffer is discarded once transcription completes.

What ends up where: A labelled transcript on the Hub, in your local conversation store. No audio, transcripts, or voice profiles ever leave your hardware. There is no cloud STT and no cloud speaker-matching service.

iOS app-to-widget snapshot#

Trigger: The iOS app has new data to render on a widget – after a Hub sync, after a suggestions refresh, after a calendar update.

What crosses the wire: Nothing. The iOS app writes a small key-value snapshot (a name, a count, a timestamp, a freshness flag) into a sandboxed App-Group container shared with the widget extension on the same device. The widget extension reads from that container on its next timeline tick.

What ends up where: The widget renders from the snapshot. The widget never calls the Hub itself – widget extensions have a tight iOS memory budget and the App Store's reviewer flags background network activity from a widget. See widgets and Watch complications for the privacy posture that controls what goes into the snapshot in the first place.

Inbound-only flows#

These flows do reach the public internet, but the direction is towards your machine, not away from it. They pull public reference data in. They do not carry personal data out.

Public reference data: Wikidata and Wikipedia#

Trigger: When Ostler enriches a person or organisation page with public biographical information.

What crosses the wire: Outbound HTTP requests for publicly known names – companies, public figures, places. The query is the public name; the response is the public Wikidata or Wikipedia entry.

What is not carried in the request: who in your contact list the name belongs to, why you are interested in it, or anything from your graph beyond the name being looked up.

What ends up where: Public biographical or organisational data lands in the Hub's graph alongside the existing record.

Web search via SearXNG#

Trigger: You explicitly ask the assistant to search the web for something.

What crosses the wire: Your search query, sent to a SearXNG instance. SearXNG is a privacy-respecting metasearch engine – it proxies queries to public search engines without sending your IP or identity downstream the same way Google would.

What ends up where: The search results come back to the Hub. What you do with them next is local: summarising, fact-extracting, following a link.

You control what you search for

Web search is an explicit, you-asked-for-it action. Ostler does not silently background-search the web on your behalf. If a query you typed contained personal context, that personal context leaves your machine in that query – use the same judgement you would typing into any search box.

Software updates#

Trigger: Hub update check, container image pull, model download for a new model you choose to install.

What crosses the wire:

  • The Sparkle-based Hub updater asks our appcast server whether a newer version of Ostler exists. The request carries the Ostler version string and basic OS information. It does not carry anything about your data.
  • Docker pulls container images from public registries.
  • Ollama's model registry hosts the AI model files.
  • Homebrew packages may be updated as part of installation or upgrade.

What ends up where: A newer Ostler binary, or a newer container, or a newer model, ends up on your Mac.

AI model downloads#

Trigger: First-time install, or you choose to switch to a different local model.

What crosses the wire: A download request to Ollama's public model registry, the model file itself coming back. This is a one-time, sometimes-occasional, public-data-in flow.

What ends up where: A model file on your disk, ready to be loaded by the local Ollama process.

These flows leave your network only when you have made a deliberate choice to enable them.

Connected external accounts you bring yourself#

Trigger: You configure an external account – an IMAP mailbox, a CalDAV server, a calendar provider – inside Ostler.

What crosses the wire: Standard protocol traffic between your Mac and the third party you chose. Credentials are held locally in macOS Keychain. The traffic is between your machine and the third-party server – it does not pass through any Creative Machines infrastructure.

What ends up where: The data your account permits is ingested into the Hub's local stores.

This is the same trust model as configuring an account in your built-in Mail.app or Calendar.app. The decision to connect a third party is yours; Ostler does not default to it.

Reaching the Hub remotely via Tailscale#

Trigger: You install Tailscale on both your Mac and your iPhone, log them into the same Tailscale identity, and use the iOS app from outside your home network.

What crosses the wire: Encrypted, peer-to-peer Tailscale traffic between your iPhone and your Mac, with Tailscale handling NAT-traversal. The application-layer payload is the same TLS-pinned HTTP traffic as on home Wi-Fi.

What ends up where: The same place real-time queries end up on home Wi-Fi – your iPhone gets a result; your Mac is the source of truth. Creative Machines is not running a relay. Tailscale is a third-party tool you have installed yourself.

Optional diagnostic send-by-email#

Ostler Doctor (at http://localhost:8089/doctor) includes an optional Send-by-Email flow for users who want help debugging their Hub remotely. It is not on by default; you click the button when you want to send a report. When you do, the flow:

  • Send only system status data (container states, model names, service health, disk usage, OS version).
  • Never send knowledge graph data, contact names, conversation content, email content, calendar details, or file contents.
  • Show a transparent payload panel before every send, so you can read every field and approve or deny each one.
  • Keep a local, browsable log of every payload ever sent.

The marketing Security page describes the planned diagnostic add-on in more detail. Until it ships, no diagnostic data leaves your machine, full stop.

What does not flow#

A negative inventory matters here, because privacy claims are easier to evaluate when the things we don't do are written down. Ostler does not:

  • Send any telemetry, analytics, or usage metrics.
  • Send any crash report, automatically or otherwise.
  • Send your contacts, messages, calendar, conversations, or graph to any server we operate or any server we use.
  • Carry email content through a server we operate. (Reading email is via Apple Mail FDA on your Mac.)
  • Carry personal context to web search engines. The query is what you typed; we do not augment it with information from your graph.
  • Phone home on launch, on lock, on unlock, on idle, or on quit.

You can verify this by disconnecting from the internet. Ostler keeps working. You lose web search and Wikidata enrichment; you do not lose your data, your AI assistant, or your ability to read your graph.

Cross-checking against the Privacy section#

Every outbound network call described above also appears, by purpose, in What leaves the device. If you spot a discrepancy between the two pages, please tell us – this is the kind of mistake we treat as a documentation bug.