Show HN: Open-source private home security camera system (end-to-end encryption)

Original Article ↗ Hacker News Discussion ↗

Project goals & architecture

  • Privastead aims to be a fully open-source, privacy-focused home camera system.
  • Architecture: IP camera → local “hub” → untrusted relay server → Android app.
  • The server only sees ciphertext; videos are deleted from the server after delivery and from the hub after acknowledgment by the app.
  • Currently oriented toward motion/event-triggered clips and occasional live viewing, more like Ring than continuous NVR recording.

Encryption, MLS, and “end-to-end”

  • Uses Messaging Layer Security (MLS) between hub and app for forward secrecy and post‑compromise security, similar in spirit to secure messaging protocols.
  • Proponents argue this is stronger than iCloud’s model, where one account secret can decrypt everything.
  • Critics note that:
    • The camera–hub leg is plaintext (often including camera credentials) on the LAN.
    • The “ends” are hub and app, not camera and app, so some consider “end‑to‑end” terminology misleading and closer to transport encryption on that segment.
  • Author acknowledges LAN plaintext and mentions interest in porting hub logic into camera firmware (e.g., via OpenMiko) and eventually replacing ffmpeg with Rust code.

Comparison with existing solutions

  • Many users report success with Frigate, Home Assistant, moonfire‑nvr, Scrypted, Shinobi, ZoneMinder, and Ubiquiti Protect.
  • Typical pattern: cameras on isolated VLANs, local NVR, remote access via WireGuard/Tailscale/ZeroTier; some see this as simpler than adding a custom relay server and MLS layer.
  • Some question the claim that there was a “void,” pointing to several existing open-source NVRs (including Rust-based ones) with strong privacy when self‑hosted.

Networking, cloud, and notifications

  • Several commenters avoid any inbound port forwarding; instead use VPNs or tunnels.
  • Privastead uses a cloud server plus Google FCM for push notifications but treats both as untrusted.
  • Concerns raised about long‑term dependence on FCM; alternatives like UnifiedPush and ntfy.sh are suggested and may be explored.

Features, limitations, and wishes

  • Current prototype: single tested camera model, no built‑in object/human detection, Android‑only client.
  • Commenters want:
    • Reliable human/vehicle detection and rich automations (lights, sounds, alarms).
    • APIs/MQTT integration.
    • Multi-user and multi-device support.
  • Multi-camera and multi-user support are on the roadmap; MLS groups are seen as a good fit.

Hardware and broader security concerns

  • Discussion of camera brands (Reolink, Amcrest/Dahua, Hikvision, Ubiquiti, Axis) centers on:
    • Firmware “phone home” behavior, insecure defaults, and bans in some jurisdictions.
    • Mitigations: PoE, no Internet access, camera-only VLANs, strong firewalls.
  • Some emphasize that local NVRs can still be physically stolen; others doubt most burglars will find or disable them.
  • Broader worries include cloud vendors’ relationships with law enforcement and the usability/UX failures of many commercial cloud camera apps.