The event thumbnail in your alert lives on cy-<serial>.local, not on a vendor CDN in another time zone.

A camera-and-sensor bundle plus a cloud subscription. ADT, SimpliSafe, Ring Alarm Pro, Vivint, Cove, Frontpoint, Brinks, Abode, Kangaroo, and Nest Aware all converge on the same architecture: a base station at the home, motion sensors and door contacts wired into it, a few cameras that upload their clips to the vendor's cloud, and a call center on the end of a signaling line. When an event fires, the clip lands on the vendor's CDN first, then gets distributed to your phone's push notification and to a staffed operator. The thumbnail in the notification is an HTTPS URL under the vendor's domain (nest.com, ring.com, simplisafe.com, etc.) served from a POP somewhere on the internet. None of the top results describe an architecture where the thumbnail is served from inside your own home network.

On a Cyrano home deployment, the thumb_url field in every event payload points at the unit itself by mDNS hostname. A real example from a production unit: https://cy-8f3a21.local/thumbs/evt_01HX6N4P9Z.jpg. The cy-8f3a21 part is the unit's 6-character serial; the .local suffix is the mDNS TLD resolved on your home WiFi by Bonjour (on iPhone and macOS) or Avahi (on Linux, Android's mDNS resolver, and most modern routers). The unit runs an HTTPS server on port 443 serving 480x270 JPEG tile crops from /var/lib/cyrano/thumbs. A self-signed CA cert is installed on your phone during provisioning so the SMS link opens without a browser warning. When you tap the thumbnail from the couch, the request goes to your router and straight back to the Ethernet port next to your DVR. It does not leave the LAN.

Four reasons. First, privacy: the event picture is never cached on a vendor CDN, never indexed in a vendor's data warehouse, never available to a vendor breach. Second, latency: LAN round-trip on a home WiFi is 5 to 15 ms. Vendor CDN round-trip is 40 to 150 ms plus an edge TLS handshake; for a thumbnail fetch this is the difference between a notification opening instantly and opening after a perceptible stall. Third, bandwidth: every event thumbnail on a cloud system consumes uplink bandwidth for the upload and downlink bandwidth for the homeowner fetch. On a starlink, LTE failover, or DSL link, a busy day can noticeably eat the cap. On Cyrano, the thumbnail is written locally and read locally; the WAN is untouched for viewing. Fourth, offline behavior: if the internet drops, a Cyrano unit still serves thumbnails to anyone on the WiFi because the HTTP server is on the LAN. A cloud system's notifications become broken links.

Six hops, all on your local network. First, iOS Messages parses the https://cy-8f3a21.local/thumbs/evt_01HX6N4P9Z.jpg URL and hands it to Safari. Second, Safari asks the OS to resolve cy-8f3a21.local; the OS's Bonjour resolver multicasts a DNS-SD question for _services._dns-sd._udp.local on 224.0.0.251:5353. Third, the Cyrano unit, which has been advertising itself via the avahi-daemon systemd unit since boot, replies with its A record (the 192.168.1.x IP the router handed out). Fourth, Safari opens a TLS connection to that IP on port 443. Fifth, the unit's local nginx-tls process presents a cert signed by the Cyrano CA (which was installed as trusted during provisioning), so the handshake succeeds with no warning. Sixth, nginx reads /var/lib/cyrano/thumbs/evt_01HX6N4P9Z.jpg from disk and returns the 480x270 JPEG. Total time: 20 to 80 ms. Round trips to the public internet: zero.

The unit optionally mirrors the thumbnail to a short-lived signed URL on a relay the homeowner controls (for example, a 10-minute pre-signed S3 URL or a Tailscale funnel to the unit's LAN IP), and the SMS carries both links: a primary cy-XXXXXX.local link and a fallback remote link. When you are home, the primary resolves first and the remote fetch is never made. When you are away, the primary fails silently after one second (mDNS does not resolve off-LAN), and Safari falls back to the remote link. The vendor model inverts this: the remote link is the only link, and the on-LAN fetch is never on the table. If your goal is 'the picture lives inside my house whenever possible,' Cyrano's dual-link default is the inverse of the SERP norm.

No. mDNS resolution is invisible. You tap the notification, the picture opens. The homeowner never types 'cy-8f3a21.local' into anything; it is the value of the thumb_url field that the SMS carries. What the .local hostname buys you is not a UX change. It is a physical guarantee about where the picture is coming from. For the homeowner who cares about where the event artifact lives (and for the homeowner whose threat model includes a cloud breach), that guarantee is the difference. For the homeowner who does not care, the tap feels the same as Ring.

On a normal home network, mDNS is allowed within the LAN by default because the multicast address 224.0.0.251 is scoped to the local link and never routed to the WAN. Modern routers from Netgear, TP-Link, Asus, Eero, Google Nest Wifi, and Ubiquiti all forward mDNS within the LAN (subject to any guest-network isolation that is turned on). If a router is unusually locked down with multicast snooping disabled or has multiple VLANs with no mDNS reflector, the unit falls back to publishing its LAN IP via a small companion service on the home router so the phone can still resolve cy-8f3a21 via unicast DNS. In practice, 95%+ of home routers work with mDNS out of the box.

One JPEG per emitted event, named by ULID: evt_01HX6N4P9Z.jpg, evt_01HX6NC3K2.jpg, and so on. Each is a 480x270 crop of the exact tile on the DVR multiview where the event was classified. The crop is taken once at emit time, written synchronously, and rotated out of the directory on a 90-day TTL (tunable in cyranod.toml). A busy home with one Cyrano unit and 4 to 8 cameras typically accumulates 50 to 500 JPEGs per week at roughly 20 KB each, so the thumbs directory stays comfortably under a gigabyte over any 90-day window. The file atomicity guarantee matters: a thumbnail is either not in the SMS (because the write did not complete) or fully there when the LAN GET fires.

ADT's RedLINK and Ring's cloud backbone are vendor-hosted signaling protocols. The base station at your home speaks their proprietary protocol to their cloud, and their cloud speaks to their call center and their mobile app. Events, state, and artifacts live in the vendor's infrastructure; the homeowner has no direct access to the unit other than through the vendor-hosted UI. On a Cyrano home deployment, the unit is a Linux box you can SSH to, the thumbs directory is a filesystem path you can ls, and the event log is a journalctl you can read. The 'cloud' is functionally absent from the event-viewing path. If the vendor went out of business tomorrow, the LAN server and the SMS links back to it would still work.

Yes, but it runs in the direction most homeowners want. Because the thumbnails are on your LAN, anyone with access to your WiFi and the cy-XXXXXX.local hostname can request them via HTTPS, protected by the self-signed CA and optional HTTP Basic auth configured in cyranod.toml. This is the opposite of the cloud architecture, where every event is in the vendor's datastore under the vendor's key-management policy. The tradeoff is: you become responsible for your home network's hygiene (WPA3 on the WiFi, no sharing the guest SSID with strangers), and in exchange the thumbnails are never in a vendor breach. Most homeowners we deploy with consider that a win.