Default
The app fixes it.
A failing node, route, protocol or DNS path triggers a bounded recovery policy. The kill switch remains closed until verification passes.
Delight · the customer reversal
Can one star become five?
Can Mysterium turn a furious one-star customer into a fan who cannot stop talking about why this VPN is superior? One real customer had already wanted to give five stars. Weeks of failed connections and support that felt absent turned that goodwill into one.
“I wanted to give it a 5 start, but for the past weeks I’ve been experiencing a big mess with your app.”
Annual customer. Connection failed across every country they tried. Support contact compounded the failure.
Current portfolio position Inside #2 Retention Economics. Strongest challenger to #5. It has not earned a separate top-five slot.
What Delight would do
protected
- 01Failure detectedConnection and route health break
- 02Traffic containedNo unsafe fallback to the open connection
- 03Connection repairedEligible node, route or protocol recovered
- 04Protection verifiedPublic IP, DNS and data path healthy
Target customer story
The VPN failed. Mysterium caught it, fixed it, and proved I was protected before I had to ask.
Illustration of the target experience — not a claim about the current product or an observed review conversion.
Error 7040 · three days1 / 5“I use this VPN for my business… why is this error still persisting for over three days?”
No network · three hours1 / 5“For over 3hours now. VPN has been blocking all network connection on my phone.”
The opportunity
These customers still wanted the product to work. Delight asks whether MN can own the failure so completely that the story reverses.
Quoted wording is preserved; ellipses mark omitted text.
The standard Recover before support. Verify before reassurance. Learn before the same failure happens again.
In plain words
Delight turns a VPN failure from a customer problem into a product action.
Most of the time, the customer sees nothing because the app recovers safely on its own. When a choice or explanation is useful, the app shows what happened and what it learned.
The system never guesses whether protection returned. It proves it with route, public IP, DNS and data-path checks.
01 · Customer experience
Invisible recovery first. Precise rescue when needed.
The product earns trust by keeping the connection safe and useful. Conversation is a fallback interface, not the event.
When useful
The app explains it.
One calm receipt: what failed, what changed, what was verified and whether the customer wants the learned policy to persist.
When recovery fails
Support starts informed.
A privacy-safe incident packet arrives with release, protocol, reason, attempted repairs and verified outcomes. The customer does not repeat the investigation.
02 · Evidence now
Material enough to test. Too uncertain to crown.
Current access is exhausted. It proves scale and support prevalence; it does not prove recovery incidence, causal retention, or a Mysterium advantage.
Residential trafficWorking tier
77.72%
of positive per-user traffic-counter growth over 30 days was residential.
How to read: residential use is substantial, not a fringe mode. Counter semantics still need owner confirmation.Support prevalenceWorking tier
889 / 9,060
90-day Intercom conversations matched the locked human-tag failure taxonomy.
9.81% of all conversations; 21.67% of the 4,103 human-tagged conversations. Nearly 55% were untagged.The result that prevents overclaiming
The apparent churn signal nearly disappears when event opportunity is considered.
Customers who generate more app events have more chances to record both errors and later outcomes. The crude comparison confuses activity with exposure.
Crude8.52×
Observed days2.00×
+ event opportunity1.18×
How to read: the final 1.18× association is non-causal and could still be confounded. It is a reason to measure the intervention, not a retained-value claim.
What the data supports
- Residential traffic is a material part of actual usage.
- Failure conversations are a material support class.
- MN already records many ingredients needed to observe reliability.
- A bounded recovery pilot is worth designing.
What remains unproven
- The true customer-visible failure and recovery rates.
- Incremental retained revenue from recovery.
- Whether network heterogeneity creates more advantage than instability.
- Whether customers want or trust a conversational operator.
03 · Market signal
The direction is validated. The complete experience is still open.
Two major implementations prove that both halves are buildable. Their public claims do not prove real-world success rates.
SSurfshark EverlinkAutomatic recovery
Surfshark says Everlink reconfigures a WireGuard tunnel to another working server during failure or maintenance, without manual intervention.
Lesson for Delight: protection-critical recovery can be invisible and deterministic.
Official product explanationEExpressVPN MCPExternal agent control
ExpressVPN exposes local, allowlisted controls for connection state, protocol, diagnostics and settings to compatible AI tools such as Codex.
Lesson for Delight: the operator interface can live outside the VPN app and remain tightly bounded.
Official product explanation
Open product space
Combine invisible recovery, verified outcomes, learned local policy, and a privacy-safe operator interface. The differentiator would be measured reliability—not the presence of an AI chat box.
04 · Additional technical information
MN does not start from zero.
The current product already contains meaningful reconnect, refresh and node-replacement primitives. The open question is whether they form one bounded loop that proves protection has returned.
Corrected technical framing
Delight is not “add auto-reconnect.” It is: turn MN’s existing reconnect, refresh and node-replacement machinery into one verified recovery loop that never confuses tunnel state with working protection.
01Verified in the public client
- The installed app is Mysterium VPN
2.4.8, build219; it matches public tag2.4.8at commitbc6f8eab. - The residential onboarding copy promises automatic reconnection when the current IP becomes unavailable.
- On Apple platforms,
OVpnExtension/PacketTunnelProvider.swiftwatches reachability and asks the OpenVPN adapter to reconnect after five seconds when Wi-Fi returns. refreshIPConnectiondefaults to true and feedsresetConnectionwhen the app requests a fresh configuration. Manual Refresh IP and reconnect routes also exist.- The client subscribes to
mysterium-vpn/connection/$connectionIDand its/killedtopic; connection messages can update the displayed exit IP and location. - WireGuard exposes tunnel status, transfer counters and latest handshake in the client.
02Present, but not enough to prove the loop
- The Apple
PacketTunnelProvideris a Network Extension tunnel provider. It is not evidence of an OS-kernel recovery controller. - The inspected client surfaces WireGuard handshake and traffic state, but no clear client-side feedback loop was found that turns those signals into bounded recovery actions.
- Mapped Grafana includes
dvpn_node_replacements_total, titled “Exit node replacements.” That establishes an operational signal, not the trigger, policy or verified customer outcome behind each replacement. - MQTT connection updates are compatible with backend-driven replacement. The backend state machine and its current production semantics remain unverified.
03Observed and historical failure seams
- One controlled reconnect remained on Connecting for more than 30 seconds, beyond the app’s compiled 15-second timeout copy, without a useful error.
- After one forced provider death, direct traffic resumed while the app still displayed Connected. Restarting the app cleared the stale state.
- An ordinary app quit can leave the tunnel provider and protected traffic alive. This may be intended persistence, but the app, OS and tunnel can disagree about who owns the state.
- Historical internal records describe auto-reconnect recovering only after long backoff, sleep/wake hangs, failed IP refresh, kill-switch loops and requests for node disconnect/reconnect measurement.
04What Delight still has to add
- Detectworking protection, not UI state alone
- Containprevent unsafe fallback during uncertainty
- Recoverbounded node, route or protocol action
- Verifypublic IP, DNS and usable data path
- Recordattempt, result, exposure and customer impact
- Escalatetruthful rescue when automation cannot close
Substantial primitives already exist. High confidence from installed-version matching and public client inspection.
The complete closed loop is not established. Moderate confidence because public client behavior and direct tests expose gaps, while private backend behavior remains unknown.
Current backend recovery semantics. Resolve with read-only config/backend evidence and an outcome series, not inference from MQTT names or replacement counters.
05 · Product system
One protection loop. Two interfaces.
Security decisions remain deterministic and auditable. AI can interpret context, explain, recommend and assemble evidence inside explicit controls.
Protection kernelDeterministic
- Detecttunnel, route, DNS, node, reachability
- Containkeep unsafe traffic closed
- Recoverbounded node, route or protocol policy
- Verifypublic IP, DNS and data-path checks
- Recordaction, outcome and customer impact
Recovery receipt
Silent by default. A short explanation and safe preference only when useful.
External operator
A local allowlisted interface lets an agent inspect state, run diagnostics and request bounded actions.
Rapid response
Support receives the incident trail and attempted repairs, with sensitive data minimized.
Hard boundary
A language model never decides whether traffic is protected. It can call allowed diagnostics and recovery actions; deterministic checks decide state and success.
06 · Six-week decision pilot
Prove the loop before building the theatre around it.
One platform, a narrow failure set, comparable controls and a kill criterion. The purpose is to learn whether recovery changes outcomes.
Define
Lock event semantics, privacy boundary, target failure classes and verification checks.
Instrument
Capture failure, containment, attempted action and verified result at one coherent grain.
Recover
Ship bounded policies for the highest-volume recoverable failures on one platform.
Measure
Compare recovery, exposure time, support contact and retention/value against an eligible control.
Required scorecard
Every recovery attempt ends in an observable outcome.
ProtectionUnsafe exposure timeIP and DNS verified
ReliabilityRecovery success rateTime to verified recovery
CustomerSupport contact avoidedRepeat failure by context
EconomicsRetention/value deltaCost per recovered incident
Recovery improves verified protection and customer outcomes without creating new failure or privacy risk.
Failures are too rare, recovery is not better than reconnect, controls cannot be made safe, or retained value does not move.
07 · Kairos decision
Authorize the evidence-producing pilot.
Do not promote Delight into the independent top five yet. Keep it inside #2 Retention Economics, fund the minimum one-platform R4 loop, and decide from measured recovery and retained value.
Authorize nowDefinitions · instrumentation · bounded recovery · comparable control
DeferBroad AI support product · portfolio promotion · retention claim
Promotion gate: incremental verified recovery, a credible retention or value improvement, and evidence that Mysterium’s network can produce an advantage competitors cannot easily copy.
08 · Evidence record
Sources, definitions and limits.
This surface is a living working brief. Git preserves prior states; the current page carries the latest evidence judgment.
- Internal evidence
- Kairos — VPN Self-Healing Data Signal (2026-08-27), including the embedded R1–R3 and Slack/Grafana receipts.
- Opening reviews
- Three one-star Apple App Store records in the Kairos public-review archive:
12147401613(US, 5 January 2025),12763074981(Nigeria, 11 June 2025) and12306751156(Great Britain, 13 February 2025). Quotations are short excerpts; the five-star outcome is explicitly illustrative. - Market sources
- Surfshark Everlink and ExpressVPN MCP Server, official product pages checked 27 August 2026.
- Client source
- Mysterium VPN public tag 2.4.8, matched to installed build 219 and inspected at commit
bc6f8eab00472f8b3785a5a937481e653273020c. Public master was separately inspected at03c451ac28e27fa6acdebac550c3bb64ba987548. - Technical limit
- Client and tunnel-extension evidence is source-backed. Backend recovery policy is an inference; no current backend/config read or verified recovery-outcome series was available.
- Evidence ceiling
- Working tier. Query mechanics are verified in the underlying programme; product incidence, causal retained value, recovery outcome and Mysterium-specific advantage remain unsupported.
- Authorship
- Prepared by Talos (GPT-5.6 Sol) on behalf of Lee Matulis. Lee commissioned the work but did not approve these exact words as his own before release.
- Independent review
- Not completed for this edition. Fable 5 and Tris were unavailable at release; deterministic gates and Talos self-review do not count as independent judgment.
- Machine record
- The canonical structured payload is embedded as
kairos-opportunity-brief/v1in this document head.