Voyager Quest

Tracks

1. 01🛰️A Browser That Remembers One Person

   0/5 lessons

   The thesis, the bar, and the log that says when it is done

   Voyager starts from one sentence Dad said on 2026-10-03: these are browsers that do not remember me. This track opens there, before any WebKit, because the product decisions come first. You will see the friction a browser built for everyone leaves behind for one person (thirty pinned tabs, a bookmark file that stopped at 14 apps while the family grew to about 45, a permission prompt for his own microphone, several browsers open at once to hold two accounts of one site) and the bar Dad set against it: a superset of Chrome, Safari and Comet, never a subset, proven when he never reopens another browser. Then the boundary: what Voyager owns and what it pointedly leaves to WebKit, Firelink, cwkPippa and the kit. Then the parity contract, which keeps the word superset honest by naming every gap. Then the departure log, a small append-only event store that turns every trip to another browser into data, and the policy that asks why at most once a day, in a toast that never moves the page.

   Lesson list (5)

   • 01
     Built for One, Remembered by One~14 min · product, thesis, one-person-software, friction
   • 02
     What Voyager Owns, and What It Pointedly Does Not~14 min · architecture, boundaries, ownership, client
   • 03
     A Superset With Named Gaps~15 min · parity, requirements, evidence, gaps
   • 04
     Departures Are Data~15 min · event-sourcing, jsonl, instrumentation, swift
   • 05
     Asking Once a Day, Without Moving the Page~13 min · instrumentation, ux, appkit, layout

   ✓Quiz · 4 questions→

2. 02⚖️Reuse the Engine, Own the Browser

   0/5 lessons

   How a todo's engine choice was checked, priced, measured and overturned

   Voyager runs on the system's WebKit on the Mac, the iPhone and the iPad, but the todo that started it said Chromium through CEF on the Mac. This track is how that premise was tested before any code: every claim checked against CEF's own source and graded by who actually read it, then a cold read that downgraded four grades. You will see why the Swift window and Chrome's extensions come from two CEF styles that cannot share a Mac window, and what a Chromium fork really costs at each depth, including the duty no depth escapes. Then the reason Dad left Safari, pages dying under memory limits, is measured with a small probe, and the result changes the design: the limits turn on whether a page is in the window. Finally, what WebKit gives a browser of its own through public API, what it lacks by name, the eleven-case gate that ran before the first brick, and why Voyager uses public API only and presents Safari's token whole.

   Lesson list (5)

   • 01
     The Premise That Did Not Survive~15 min · engine choice, CEF, evidence, primary sources
   • 02
     What a Fork Really Costs~14 min · Chromium, fork, maintenance, security updates
   • 03
     Measuring the Reason Dad Left Safari~15 min · WebKit, memory, measurement, probes
   • 04
     What WebKit Gives, and What It Lacks~14 min · WebKit, public API, WKWebsiteDataStore, trade-offs
   • 05
     A Gate Before the First Brick, and Public API Only~14 min · engine gate, public API, user agent, testing

   ✓Quiz · 4 questions→

3. 03🧬One Swift Parent, One Engine Child

   0/5 lessons

   A browser whose rules never see WebKit, and the one place WebKit lives

   Voyager's architecture fits in one sentence: a Swift parent that never imports WebKit, and one engine child that is WebKit's home. This track reads that sentence in code. You start with the package itself, three targets and two test targets, and see which dependency arrows the compiler enforces and which one is only a promise. Then the root contract: one file of plain values and protocols, where questions go down to the engine and decisions come back up to the parent. Then the fake engine, a recorder that lets 242 tests check tabs, sessions, identities and trust without a browser, and an honest list of what a fake can never prove. Then the child: one data store per identity, WebKit's questions translated into the contract's, and a test that exists because WebKit stays silent when a delegate method's name is a little off. It ends with two shells, the Mac's and the phone's, on the same parent, and the two lines the parent had to change for the iPhone.

   Lesson list (5)

   • 01
     One Package, Three Targets~13 min · swiftpm, architecture, targets, modules
   • 02
     The Root Contract~15 min · protocols, polymorphism, architecture, contracts
   • 03
     Testing a Browser Without a Browser~15 min · testing, test-doubles, swift-testing, fakes
   • 04
     The One Child~15 min · webkit, delegates, objective-c, testing
   • 05
     One Parent, Two Shells~14 min · ios, macos, size-classes, architecture

   ✓Quiz · 4 questions→

4. 04🌙Tabs That Sleep, Wake and Come Back

   0/5 lessons

   A tab's whole life, from the front of the window to 624 bytes and back

   A tab looks simple until you count what it has to survive. This track follows one through its whole life in Voyager: awake in front, behind for an hour, asleep with nothing but a title, an icon and a few hundred bytes of WebKit state, woken where Dad left it, ended by a crash or a memory limit, and restored after a relaunch or an install. You will see the tab and window model as plain Swift with one invariant, pinned tabs as a prefix; a sleep policy designed from a measurement of WebKit's memory limits rather than a guess; a session file that keeps an unreadable copy instead of overwriting it, and is written off the main thread; why Pippa herself stays in the window under every other tab; and how a crashed page comes back once a minute at most. It ends with the daily-use review of 2026-10-22, row by row: the address field, find's "3 of 17", mute, a strip that never loses a tab, and the AppKit details that make a browser feel right in the hand.

   Lesson list (5)

   • 01
     Tabs and Windows as a Model~14 min · tabs, state-model, pinned-tabs, swift
   • 02
     Sleep and Wake~15 min · webkit, memory, tab-sleep, measurement
   • 03
     Sessions That Survive~14 min · persistence, codable, concurrency, recovery
   • 04
     Pippa Stays in the Window, and Crashes Recover~14 min · appkit, webkit, recovery, pippa
   • 05
     The Daily-Use Review~16 min · usability, appkit, chrome-parity, review

   ✓Quiz · 4 questions→

5. 05🎭Several Accounts of One Site, Side by Side

   0/5 lessons

   An identity is a store, and a tab has exactly one

   Dad used to run several browsers at once to hold two accounts of one site. Voyager holds them side by side in one window, and the whole mechanism is one idea: an identity is a store. This track reads that idea in code. You start with three small value types and the one WebKit call that turns an identity's UUID into an isolated data store, and with the real-WebKit test that proves two identities share nothing. Then the paths a new page can take, pop-ups, links and redirects, and how each stays in its opener's identity by construction or by a guard, along with the one menu path that does not. Then Incognito, which is a reserved identity on a store that lives in memory, and the list of things Voyager refuses to write for it. Then the controls Dad touches: the identity menu, account shortcuts on Home, the colour mark on a tab, and a removal ordered so no sign-in is lost by accident. It ends with the one cookie the parent ever asks about, and how it gets one header without holding a jar.

   Lesson list (5)

   • 01
     An Identity Is a Store~15 min · webkit, identities, isolation, data-store
   • 02
     Pop-ups and Redirects Stay in Their Identity~14 min · webkit, identities, pop-ups, wkuidelegate
   • 03
     Incognito~13 min · webkit, privacy, incognito, data-store
   • 04
     Account Shortcuts and the Identity Menu~13 min · identities, appkit, ux, data-removal
   • 05
     The One Cookie the Parent Ever Asks About~14 min · cookies, least-privilege, contracts, webkit

   ✓Quiz · 4 questions→

6. 06🏡Family Apps by Name, Trust by Zone

   0/5 lessons

   A catalog read at run time, a sign-in reused as the credential, a home found by role, trust you can read in one function, and two gaps named out loud

   The family half is where other browsers are worst, and this track is how Voyager wins it. Voyager keeps no list of family apps. It reads Firelink's launch catalog at run time through the kit's shared client and holds it as a dated projection: a cache keyed by endpoint, and a generation ticket so a newer question beats an older reply. Away from the service host, the request carries the hub session Dad's own sign-in already left in the browser, as a cookie to one exact origin and never as a Bearer, because Dad chose no device pairing. You will see how Voyager finds home by asking the family registry which Mac holds the Pippa role, why loopback is spelled by name, and how one kit rule hides a role-bound target everywhere else. Then trust as code: a frame judged with its page, a verifier that sat uninstalled for nineteen days, and a tailnet zone that is honestly not built yet. Last, the same hosts denied to every extension, an address field that does not know a family name yet, and a phone widget that holds no address.

   Lesson list (5)

   • 01
     Read, Never Copied~15 min · single-source-of-truth, catalog, cache, concurrency
   • 02
     The Hub Session as the Credential~14 min · authentication, cookies, sessions, origins
   • 03
     Where Is Home?~13 min · registry, roles, migration, passkeys
   • 04
     Trust Zones as Code~15 min · permissions, origins, secure-contexts, honest-gaps
   • 05
     Denied to Extensions, Opened by Name~14 min · web-extensions, widgetkit, deep-links, honest-gaps

   ✓Quiz · 4 questions→

7. 07💬Pippa Built In

   0/5 lessons

   How a browser makes room for the family's one Pippa without becoming a second one

   Dad's rule for this part of Voyager was short: plant Pippa in the UI itself, and never make her a click away. This track is where I explain how a browser does that without turning into a second Pippa. You will meet my two surfaces, myself in a pinned voyager://pippa tab and my web-page Sidekick beside the page in front, and see why both are one host class drawn by the engine child. Then the wire: the pippa:* requests my panel asks in cwkPippa's own words, the payload with its chrome_tab_key, and the rule that nothing is ever injected into my prompt. Then the reading itself: the Chrome extension's reader kept the same on purpose, with every secret named by its label and its value never read. Then the gates: at most three companion tabs that Dad chooses, one origin, the main frame only, a 256 KB cap, and a microphone for my own page alone. It ends with how I am reached: this Mac, the tailnet or an address, the family PIN through the kit's door, and a session that rides as a cookie and in a fragment.

   Lesson list (5)

   • 01
     Two Surfaces, One Pippa~14 min · pippa, sidekick, architecture, webkit
   • 02
     The Wire Speaks cwkPippa's Words~14 min · pippa, protocol, postmessage, sidekick
   • 03
     Reading a Page for Her~15 min · privacy, webkit, content-world, pippa
   • 04
     Companion Sources and the Panel's Gates~14 min · privacy, security, webkit, sidekick
   • 05
     Reaching Her~14 min · networking, auth, tailscale, cookies

   ✓Quiz · 4 questions→

8. 08🧩Extensions, 1Password and a Password Store of Its Own

   0/5 lessons

   The least certain phase of the build, told the way it really went

   Dad's daily browser had to run the Chrome extensions he already uses, and WebKit offers Apple's WKWebExtension API to host them. This track follows Voyager through that phase, the least certain one in the build. You will see how one extension controller and a context per package make a Chrome package at home in a Swift browser, and why the host has to exist before the first page. You will meet the diagnostic that found exactly three kinds of difference between a Chrome package and WebKit, and the compatibility layer that answers each one. Then native messaging as Chrome speaks it, and the spawn rule a password manager's helper enforces. 1Password is told as a debugging case study that ends where it really ends: Voyager listed as a connected browser, authentication through the extension never holding, and Dad parking it with the root cause unknown. The track closes on the fallback Dad ruled in, Voyager's own password store, with every password in the Keychain.

   Lesson list (5)

   • 01
     Hosting Chrome Extensions on WebKit~15 min · webkit, extensions, wkwebextension, lifecycle
   • 02
     Three Kinds of Difference, Measured~15 min · extensions, compatibility, diagnostics, javascript-proxy
   • 03
     Native Messaging and the Spawn Rule~14 min · native-messaging, posix-spawn, process-groups, extensions
   • 04
     1Password, Honestly~14 min · debugging, 1password, case-study, stopping-conditions
   • 05
     A Password Store of Its Own~15 min · passwords, keychain, privacy, consent

   ✓Quiz · 4 questions→

9. 09📦Shipping It

   0/4 lessons

   Signing, checks and TestFlight: the last mile of correctness

   Shipping is the last mile of correctness, and this track walks it for Voyager on the Mac and on the phone. It starts with a signing identity chosen by measurement: 1Password accepts a browser only under the paid team's identity with the hardened runtime, and a designated requirement that pins the team rather than the certificate keeps every macOS grant through a renewal. Then the one script that builds, signs, verifies and installs as a single transaction, replacing a running copy without losing Dad's session; a doctor that only reads; and a smoke run that walks a separate verification build twice against a stand-in Pippa, so no check touches Dad's state. Then the test pyramid, from 242 parent tests and 63 real WebKit tests to the kit drift check, the smoke run and the phone's hosted suite, with what each layer cannot prove. Last, the family's one TestFlight pipeline, four delivery facts never merged into one, and the internal-only rule that cost the phone a default-browser entitlement.

   Lesson list (4)

   • 01
     A Signing Identity Chosen by Measurement~14 min · code signing, macOS, hardened runtime, designated requirement
   • 02
     Build, Install, Doctor, Smoke~15 min · build scripts, installation, rollback, smoke test, isolation
   • 03
     The Test Pyramid~14 min · testing, swift-testing, XCTest, drift check
   • 04
     TestFlight, Internal Only~14 min · TestFlight, iOS, release pipeline, delivery

   ✓Quiz · 4 questions→