Show HN: 1-FPS encrypted screen sharing for introverts

Original Article ↗ Hacker News Discussion ↗

A minimalist tool for 1‑frame‑per‑second, end‑to‑end‑encrypted screen sharing is prompting debate over when low‑FPS, no‑audio sharing is preferable to traditional video calls or remote desktop tools. Commenters explore use cases such as introvert‑friendly collaboration, remote monitoring, and “always‑on” views of a machine, while also warning about potential misuse for employee surveillance. Much of the technical focus centers on the project’s cryptography (with several concrete flaws and fixes identified), trade‑offs between JPEG snapshots and real video codecs, platform quirks, and how to deliver genuine end‑to‑end security in a browser‑based workflow.

Concept & Intended Use Cases

  • Tool shares encrypted screenshots at ~1 FPS plus smooth cursor tracking, pitched as “screenshots + chat” rather than full video calls.
  • Suggested uses:
    • For introverts or people who dislike calls but still want to show what’s on screen.
    • Long meetings where someone wants to keep sharing their screen but focus on coding.
    • Lightweight remote monitoring of a home or work machine, including checking on bots or long-running tasks.
  • Some see it as a neat, minimalist workflow that pairs well with existing chat tools.

Skepticism & Privacy / Management Concerns

  • Some question screensharing without audio: text-chat plus delayed visuals can be clumsy; sometimes a static screenshot may be easier.
  • Concerns raised about potential misuse for workplace surveillance (continuous desktop feeds) and ethical / legal boundaries (e.g., GDPR, worker rights). Others argue that collaboration tools can be policy‑bound and even monetized in enterprise settings.

Compression, Bandwidth & Performance

  • Implementation appears to take periodic JPEG screenshots. Commenters question efficiency versus real video codecs (AV1, H.264/HEVC) that exploit frame-to-frame similarity.
  • JPEG is noted as suboptimal for UI/text; PNG or screen-optimized codecs (like those used in VNC/RDP or game streaming) may yield better quality and bandwidth use.
  • Author notes experiments with ffmpeg felt too CPU‑heavy on their hardware; prefers trading extra bandwidth for simplicity and low CPU.
  • Ideas floated:
    • Detect and transmit only changed regions of the screen.
    • Heuristics to pick “stable” frames.
    • Hardware-accelerated encoding and codec tuning for low-latency, low-CPU use.

Cryptography & Security Model

  • Detailed critique finds several crypto issues: misuse of PBKDF2 on already-random keys, unsafe AES-GCM nonce strategy, reduced keyspace due to character-set restrictions, and the risk that a malicious server could exfiltrate keys embedded in URL fragments via injected JS.
  • Recommendations include using XSalsa20-Poly1305 via a misuse-resistant library (e.g., NaCl secretbox), generating full-entropy keys then encoding them, and rethinking how the web UI is delivered (e.g., from a trusted local binary).
  • Broader discussion underscores that “don’t roll your own crypto” applies to protocols and key distribution, not just primitives.

Implementation & Ecosystem Issues

  • Linux users report needing extra X11/XTest dev packages; Wayland support is unclear.
  • Windows users encounter build and cursor-position issues; some dispute characterizations of the Go Windows toolchain as “often broken.”
  • Multi-monitor cursor tracking bugs are reported.
  • The service domain is flagged as malware by OpenDNS in at least one environment.

Alternatives & Distribution

  • Comparisons and alternatives mentioned: VNC/RDP variants, WebRTC tools (Jitsi, Brave Talk, Nextcloud Talk), Moonlight/Parsec/game-streaming style solutions.
  • WebRTC scaling and TURN/SFU infrastructure costs are highlighted as a barrier for free, large-scale screen-sharing services.
  • Some dislike requiring a Go toolchain for installation and urge distributing self-contained binaries; others accept this for hobby projects.