feat: Live path requests

[luckystriike22]

Hey!

First of all, I really love the site. It provides some great insights.

About the feature requests…

1. Slomo:
Currently, it’s possible to speed up the live view, but there’s no way to slow it down. It would be nice if we could send a message, switch to the site, and watch it flow through its path.

2. Clickable message:
It would be nice if we could click a message and have it show the path information. This would work especially well together with the slomo feature.

3. Only my repeater filter:
An option to filter all messages and show only those that pass through my repeater.

I know all this information is available on other pages, but it would be great to have links or this info directly on the main live map.

[Kpa-clawbot]

Design Spec: Live Path Requests

Three features requested, all complementary. Here's the concrete design with milestones.

---

Analysis (Doshi framework)

LNO classification: This is Leverage work. The live map is CoreScope's showcase — it's what makes the product viscerally compelling. These three features compound: slow-mo makes paths watchable → clickable paths make them explorable → "my repeater" filter makes it personal. Each one alone is N-tier; together they're L-tier.

Pre-mortem: The main risk is over-engineering. Slow-mo that requires precise timing sync with VCR state is complex. Clickable paths that try to replicate the full packets page are scope creep. Keep each feature surgical.

What we're NOT building:

• No new server endpoints — all data already exists client-side
• No path persistence or history beyond what VCR buffer already stores
• No "message content" display (privacy concern on public meshes)
• No drag-to-scrub on individual path animations

---

Milestone 1: Slow-Mo Playback

Problem: VCR speed cycles 1x → 2x → 4x → 8x. No way to go slower than real-time.

Design:

• Extend vcrSpeedCycle() speeds to: [0.25, 0.5, 1, 2, 4, 8]
• At sub-1x speeds, also scale DURATION_MS (hop animation duration, currently hardcoded 1100ms) by 1/speed — so at 0.25x, each hop animates over ~4.4s
• Speed button shows ¼x, ½x, 1x, etc.
• Works in both REPLAY and LIVE modes (in LIVE mode, buffer packets and release them at the slower rate)
• Store speed preference in localStorage (live-vcr-speed)

Tufte note: The speed button already exists. No new UI chrome needed — just extend the existing control's range. Maximum data-ink ratio preserved.

Tests: Unit test for speed cycle array. Playwright test: click speed button, verify sub-1x label renders.

Milestone 2: Clickable Paths (Packet Info Overlay)

Problem: Animated paths are visual-only. No way to inspect what a path represents.

Design:

• Each animated path already draws L.polyline segments on pathsLayer. After animation completes, keep a clickable invisible polyline (weight: 12, opacity: 0) on a new clickablePathsLayer for 30 seconds, with the packet data attached.
• On click → show a compact info card (Leaflet popup, not a panel) anchored to the click point:
  • Type badge (e.g., GRP_TXT) with color
  • From → To (resolved node names, not just hashes)
  • Path (full hop chain, e.g., Node1 → Rpt2 → Rpt3 → Node4)
  • Time (relative, e.g., "12s ago")
  • Link to #/packets/{hash} for full detail
• Auto-dismiss after 10s or on next click. Max 50 clickable paths retained (FIFO eviction).
• Prune layer on the existing _pruneInterval.

Tufte note: Information appears ON the data (the path itself), not in a separate panel requiring cross-reference. The popup is word-sized, data-dense, no decoration. Link to packets page for full detail respects the viewer's intelligence without overloading the map.

Deep linking: Clicking the packets link navigates to #/packets/{hash} (existing pattern). No new deep-link state needed for the popup itself — it's ephemeral by nature.

Tests: Unit test for clickable path eviction logic. Playwright test: trigger a packet in replay, click the path area, verify popup renders with type + path info.

Milestone 3: "My Repeater" Filter

Problem: On busy meshes, too many paths. Operators want to see only traffic through their node(s).

Design:

• Add a filter input to the existing live controls bar (next to the favorites toggle): a node-name autocomplete dropdown labeled "Filter by node"
• When set, only packets whose decoded path includes the selected node's pub key prefix are animated. Others are silently buffered (still stored in VCR buffer for replay without filter).
• Support multiple nodes (comma-separated or multi-select). Store in localStorage (live-node-filter).
• Reflect in URL hash: #/live?node=ABCD1234 (follows existing deep-linking convention).
• Clear button (×) to remove filter and show all traffic.
• Counter showing "Showing X of Y packets" when filter is active — so the operator knows traffic is being filtered, not absent.

Tufte note: The "X of Y" counter is critical. A filter that hides data without indicating it's hiding data violates graphical integrity. The counter provides context without taking space. The filter input itself is a standard control that earns its pixel-space by dramatically reducing noise.

Tests: Unit test for path-includes-node matching logic. Playwright test: set filter, verify only matching packets animate.

---

Milestone Order

M1 → M2 → M3. Each is independently shippable and useful. M1 is smallest scope (~30 lines changed). M2 builds the click infrastructure M3's filter makes more useful. M3 is largest scope (autocomplete + URL state + counter).

Config / Customizer

• M1: speed preference (localStorage, no customizer entry needed — it's a playback control, not a theme setting)
• M2: popup auto-dismiss timeout, max retained paths — hardcode initially, customizer later
• M3: default filter nodes — customizer candidate for operators who always want their repeater pre-selected

What NOT to Build

• No server-side filtering — all packet data is already on the client via WebSocket
• No "path replay" (scrub through a single packet's journey) — the slow-mo + click combo achieves this more naturally
• No message content display in popups — privacy risk on public meshes, and not requested
• No "follow my packet" camera mode — cool but scope creep, separate issue if wanted
• No changes to the packets page or analytics — this is live-map-only

[luckystriike22]

Nice!
Remarks:

• isn't 30sec invisible line a lot?
• isn't hiding data after 10sec to fast?

[efiten]

All three milestones implemented and submitted as separate PRs:

• M1 — Slow-mo playback → feat(live): slow-mo playback — sub-1x VCR speeds (closes #771 M1) #922: VCR speeds extended to [¼x, ½x, 1x, 2x, 4x, 8x]. Animation duration scales with speed. Preference persisted to localStorage.
• M2 — Clickable paths → feat(live): clickable path overlay — packet info popup (closes #771 M2) #923: After animation completes, an invisible hit-target polyline stays on the map for 30s. Clicking shows a popup with type badge, hop chain, relative time, and a link to the full packets page. Auto-dismisses after 20s, max 50 paths retained.
• M3 — Node filter → feat(live): node filter — show only traffic through a specific node (closes #771 M3) #924: Text input in the controls bar to filter animated paths by node. Only packets passing through the selected node(s) are shown. Counter displays "Showing X of Y" when active. Persisted to localStorage and URL hash (?node=…). Datalist autocomplete from live node data.