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

This is key to the claim that Privastead offers superior privacy to other solutions, but it's not explained.

My NVR [1] only uses a trusted server that is intended to be in the same building as the cameras. I similarly recommend not allowing the cameras to access the Internet, as their closed-source software is typically a complete nightmare in terms of privacy and security.

[1] https://github.com/scottlamb/moonfire-nvr

My NVR's based on the assumption that you want to record continuously (as called out in the schema design doc here [1]) rather than trust event detection to be perfectly reliable. I've set up other systems in parallel that are based on a different assumption (e.g. Frigate) but have found they miss things, so this is the design I'm comfortable with.

If you are also constrained on upstream bandwidth, continuous recording means you must buy a local hard drive. It costs $100–$200 to buy one that can hold many camera-months of video at good quality, which I find pretty reasonable.

Some folks might want to also upload stuff off-site in case the NVR itself is stolen or destroyed, but I haven't felt the need. There are a bunch of missing features from my system I'd like to add when I have time; that one doesn't make my top 10. YMMV.

[1] https://github.com/scottlamb/moonfire-nvr/blob/master/design...

Overall, we must be coming at this with quite different expectations of what a NVR should do. Not just this but also "when the app fetches a video, the server deletes the ciphertext (in order to be memory efficient)". Some installations of my NVR software are multi-user; I personally use it from multiple devices; etc. So the idea the whole pipeline exists just to transfer event videos to a single Android device results in a system that I would not find useful.

There certainly is space for different approaches. E.g. Frigate's approach is quite different than Moonfire NVR's but obviously is useful in a lot of ways to a lot of people. But my take is that Privastead's approach is going to be pretty niche, and the claim that other NVRs don't offer strong privacy assurance using "end-to-end" (on-prem server to client) encryption is untrue.

Also, I find it inaccurate to say it's mostly implemented in Rust which "provides higher security assurance for the hub". The Amcrest camera you've chosen is essentially developed by a hostile nation-state, and the protocol code you're using to interact with it (ffmpeg) is all written in C, which I find incongruous with the privacy/security goals. In fact, ffmpeg's RTSP and Matroska code is probably the majority of lines of code in the system.

And my main comparison has been with security camera solutions that use their cloud solution to transfer videos (e.g., Ring). I think an open source solution that uses MLS and treats the cloud as fully untrusted is a superior alternative.

Regarding the multi-user support: yes, that's on the to-do list. A nice aspect of MLS is the notion of groups that it provides. In Privastead, each camera will have a separate MLS group and it could add multiple devices/smartphones to the group. The hub will then try to deliver the video to all devices in the group. Many aspects of the multi-user support still needs to be figured out, but it's technically feasible.

Regarding ffmpeg: I agree. I'm aware of it and I have it in my to-do list to replace that with a Rust-based implementation. In fact, I'll be looking into your retina library as one potential replacement. :-)