Amplifier Case Study

The Ghost in
the Network

How a "broken HTTPS" bug turned out to be a phantom DNS problem — and how Amplifier's multi-agent debugging traced it across three sessions, two machines, and a disconnected iPhone.

AMP Browser • February 2026
The Project

AMP Browser

A self-hosted file browser built as a Progressive Web App. It runs on a Mac Mini and a Raspberry Pi, accessible anywhere over Tailscale — a mesh VPN that gives every device a private, encrypted connection. The interface is a glass-morphism UI that feels native on iOS, installable right to the home screen.

📱
PWA
iOS-native feel. Installed to the home screen, works like a real app — offline caching, full-screen, touch-first.
🔒
Tailscale + HTTPS
Mesh VPN with MagicDNS and Let's Encrypt certificates. Encrypted access from anywhere, no port forwarding.
🖥️
Multi-Device
Mac Mini as primary server, Raspberry Pi as secondary. Single Python server, one HTML file, zero frameworks.
Act I

Recovering Lost Context

The developer opened a new Amplifier session. They'd been working on HTTPS fixes earlier — but couldn't remember the details. Which session was it? What had they changed? What was left to do?

"There was a session running previous to this one where we were making some edits. Can you find and pull that session back up?"
Session Archaeology

Three Prior Sessions — Recovered

The session-analyst agent searched the project's Amplifier history and reconstructed the full timeline of prior work:

02:25 AM — Implementer
The Big Migration
An 8-task plan executed: renamed the entire project from "PiBrowser" to "ampbrowser" — README, systemd service, shell scripts, and the project directory itself.
03:01 AM — Implementer
The HTTPS Fix
Fixed certificate detection. socket.gethostname() was returning "mac.lan" instead of the Tailscale hostname. HTTPS was silently degrading to HTTP.
03:18 AM — Git Ops
The Commit
Committed the hostname fix: c8c98ab. Clean history, clear message.
The Pattern

The Silent Failure

The root of the original bug was a design choice in the server: when HTTPS certificates can't be found, the server silently falls back to HTTP. No error. No warning. Just... unencrypted.

# server.py — the silent fallback if https and cert_file.exists() and key_file.exists(): context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER) context.load_cert_chain(cert_file, key_file) server.socket = context.wrap_socket(server.socket, server_side=True) # If certs not found? Nothing. No else clause. No log. # Server just runs as HTTP and hopes you don't notice.

The hostname fix (hostname = "home-server") had resolved this — HTTPS was working again. But the developer had come back with a new problem.

Act II

The Real Problem

With prior context recovered, the developer revealed what was actually bothering them:

"HTTPS works on my MacBook browser and as a PWA. But I can't access via any mobile browser. It just returns 'the site can't be reached — server's IP address could not be found.'"

HTTPS was fine. The server was fine. Something else was broken — and it only affected the iPhone.

The Investigation

Three Agents, One Problem

Amplifier dispatched a coordinated investigation across multiple agents — each probing a different layer of the stack simultaneously:

🔍
Explorer Agent
Deep-surveyed the entire server.py networking stack: bind address, SSL config, CORS headers, PWA manifest, service worker, all shell scripts.
⚡
Live Diagnostics
Real-time bash probes: tested HTTPS on localhost and Tailscale IP, checked firewall rules, verified certs, confirmed ports were open.
📋
Session Analyst
Dug deeper into the prior session transcripts, tracing the full chain of hostname-related fixes across multiple commits.
The Findings

The Server Was Fine

Every diagnostic came back green. The problem wasn't where anyone expected:

✓ HTTPS Active
Server running with --https flag, PID 43784, port 8080. TLS handshake completing successfully.
✓ Tailscale Reachable
HTTPS responding on both localhost and Tailscale IP 100.x.x.x.
✓ Certs Valid
Let's Encrypt cert via Tailscale. ECDSA, valid through May 2026. Correct SAN for the hostname.
✓ Port Open
Port 8080 accepting connections on the Tailscale interface. No firewall blocks detected.

If the server, the certs, the port, and the network were all fine... where was the ghost?

Act III

The Smoking Gun

The critical clue was in the Tailscale status output — one tiny character that explained everything:

$ tailscale status 100.x.x.x home-server user@ macOS active 100.x.x.x ampworker user@ linux active 100.x.x.x iphone user@ iOS -

That - next to the iPhone. Tailscale wasn't connected.

Without Tailscale active on the iPhone, MagicDNS can't resolve *.example.ts.net hostnames. The phone can't route to 100.x.x.x addresses. It's not a server problem. It's not an HTTPS problem. It's a DNS resolution failure — the phone literally cannot find the server.

Diagnosis

Layer-Cake Debugging

What looked like one problem was actually a stack of three distinct issues uncovered across multiple sessions:

Reported As
"HTTPS isn't working on my iPhone"
→
Layer 1 — Hostname
socket.gethostname() returning "mac.lan" instead of "home-server". Certs not found. Fixed.
Layer 2 — Paths
Cert directory was /etc/pibrowser/certs — old project name. Service file still had /home/pi/ paths. Fixed.
Layer 3 — DNS/VPN
iPhone's Tailscale disconnected. MagicDNS not resolving. Diagnosed.
The Amplifier Difference

What Made This Work

🧠
Session Continuity
The developer couldn't remember what they'd done or which session it was in. Session-analyst recovered the full context of 3 prior sessions — every commit, every fix, every test — in seconds. No manual log-digging. No guessing.
🔬
Multi-Agent Diagnosis
Explorer surveyed the code, bash ran live diagnostics, session-analyst cross-referenced history. Three agents, three angles, one complete picture. Each agent contributed knowledge the others couldn't.
🧅
Peeling Back Layers
The problem presented as "HTTPS broken" but was actually stacked: hostname mismatch → stale paths → VPN disconnect. Each layer required different investigation tools. Amplifier coordinated them all.
🎯
Correct Diagnosis
Rather than "fixing" HTTPS again (which was already working), the investigation correctly identified the real issue: an iOS Tailscale VPN disconnect causing DNS resolution failure. No wasted effort.
Impact

By the Numbers

3
Prior Sessions
Recovered
4
Agents
Coordinated
3
Hidden Layers
Uncovered
1
Correct Root
Cause Found
Lessons

Takeaways

1. Silent failures are the worst failures
The HTTPS fallback had no error, no log, no warning. It just silently served HTTP. Design your systems to fail loudly.
2. The reported problem is rarely the actual problem
"HTTPS doesn't work on my phone" was actually "my VPN client isn't connected." Start from the symptom, not the assumed cause.
3. Session memory turns debugging into archaeology
The ability to recover full context from prior sessions — what was changed, what was tested, what was committed — transforms how you approach persistent bugs.
4. Multi-agent investigation beats linear debugging
Code review, live diagnostics, and history analysis running in parallel found the answer faster than stepping through any single thread would have.
Sources

Research Methodology

Data as of: February 26, 2026

Project: AMP Browser (ampbrowser) — private repository

Session data source: Amplifier events.jsonl files for three recovered sessions:

Diagnostic methods:

Git commits referenced: c8c98ab, 939fa92, dfcc4ba, 8f78fa4

Key finding: iPhone Tailscale status showed - (disconnected), confirmed as root cause of DNS resolution failure.

Gaps: iPhone-side Tailscale logs not available for review. Diagnosis based on status indicator only.

More Amplifier Stories