2-1. ntfy로 가족 연락망 만들기

A developer’s implementation note for the ntfy family channel described in Part 2: the goals, how messages were sent and guarded, and what was actually checked during the trip. “Operational record” means results checked during the trip in October 2026, not a fresh check of the current runtime or every device. “Reproduction examples” (Compose, Python, pseudocode) were rewritten for this article; they are not copies of production code and have not been newly deployed or run. Real server addresses, tokens, topics, and family accounts are omitted. Official documentation was checked on October 13, 2026 (KST).

I was unsure whether calls and texts would be reliable even with roaming, and our ten-year-old had a data-only SIM. The goals were to send short messages to connected family members, provide transport and cost guidance an hour before the next activity, and reflect on-the-ground changes in later notifications.

Responsibilities were split into itinerary sources (Calendar and the travel Markdown), message preparation (Luan, per recipient), scheduling, publishing, and result recording. Because messages were finalized in advance, nothing had to be generated at send time. The design centers on publish/subscribe; it does not by itself provide family chat, read receipts, or acknowledgment of an emergency request. Without data, ntfy cannot guarantee real-time contact, so urgent communication also needs direct confirmation and family arrangements such as a meeting point.

We ran ntfy on the home server with recipient-specific routes. The scaffold above follows the official Docker documentation: pin an image version you have tested, prepare writable storage with suitable ownership, and bind only to localhost behind an HTTPS proxy. Configure HTTPS and per-user topic permissions before registering subscriptions on each phone; hard-to-guess topic names do not replace access control.

iOS needs an extra check: a self-hosted server alone may not deliver prompt notifications to a locked iPhone. The official docs describe an upstream-base-url path through ntfy.sh for this. Review that dependency and information flow, then test on a real device. The October 1 setup record confirms an iOS upstream was enabled.

The publishing layer can be isolated as one small HTTP request. The example uses only the Python standard library. Inject a previously authorized token from a protected runtime environment; never embed real tokens or log request headers. JSON publishing and Bearer authentication follow the publishing and authentication docs. A production publisher also needs recipient validation, duplicate protection, and persistent result storage. The output classifies the server response; it is not a read receipt.

The first scheduled briefing was run manually about four minutes late. Execution then moved to a user-level systemd timer on the home server, and the next scheduled run produced exit code 0 and four HTTP 200 responses. Verifying an actual run mattered more than creating a schedule. The rules: never send early, allow up to ten minutes late, use stable identifiers for duplicate protection, and stop to inspect when a send is uncertain. Times used Asia/Tokyo; Korea and Japan were both UTC+9 on this trip, but other destinations need explicit timezone and DST handling.

The pseudocode is a reproduction design, not the original implementation. Checking obsolete before the ledger keeps an uncertain record from an older revision from blocking the latest one. If the connection drops after sending but before the response, the server may already have accepted the message, so blind retries risk duplicates; keep an explicit uncertain state. A lock and persistent ledger still do not guarantee exactly-once delivery across an external server.

Before sending, Calendar and the travel Markdown were checked again. A sync error or a Day itinerary cache older than thirty minutes blocked an unchecked send. Destination, transport, and whether a cost was confirmed or estimated also had to match the message; an unknown cost stayed unknown. The clearest case was the October 4 change to a 14:00 bus departure (Part 3): Calendar, Markdown, and briefings were reconciled, the old 14:30 notification was removed, and the already-past 13:00 briefing was not sent late. At that checkpoint, twenty-nine briefing start times were checked against Calendar — a count of consistency checks, not of successful sends.

October 4, 10:00 — four advance briefings for the 11:00 dolphin show were accepted with HTTP 200: the adult version to the parents, the child version to a parent and the child; delivery records were checked against the intended variants. October 3 — a separate request produced three successful send records: two copies of the next-day guidance and one letter from Luan to the child. Setup — ntfy 2.28.0, a private container network, default-deny access, HTTP 403 for anonymous reads and writes, and disabled signup; the Day message screen offered four recipient roles, enforced a 100-character body limit and an authenticated sender label, and published only to four designated topics (the limit applied only to Day’s short-message input).

One notable issue was Cache: no on Day’s publish requests: notifications appeared, but messages could not be retrieved later. After removing it, user-origin messages were verified in the 24-hour cache, and forty server tests plus sender-label regression checks passed; persistence in the iOS app list was not verified end to end. Prompt delivery and later retrieval are separate test cases. A reproduction should test valid publishing, bad credentials, wrong recipients, duplicate runs, restarts, network loss, schedule changes, and locked-screen reception. ntfy accepting a request does not mean Luan replies; conversation handling needs its own integration.

For a public repository, I would document the boundaries of reproduction before the code. The structure above is a proposal, not an existing repository; it excludes real itineraries, recipients, and tokens and uses synthetic data to test duplicate protection and change handling. The README should cover requirements, tested versions, prerequisite permissions, device subscription steps, and troubleshooting order. Environment secrets, token files, auth databases, delivery histories, and real itineraries stay out, and log bodies and screenshots need a separate privacy check. Success criteria should separate server acceptance, device display, and human acknowledgment.

Even a short message depended on the source itinerary, execution time, recipient, revision history, and result verification. The home server coordinated these parts, and ntfy carried the brief guidance. A future version would design acknowledgment and fallback contact procedures as separate features.