News for hackers. Stuff that matters.
Re:Show HN: Open-source private home security camera system ... by scottlamb on Sunday December 01, 2024 @04:25PM (#42290844)
That didn't answer my question.
Re:Show HN: Open-source private home security camera system ... by arrdalan on Sunday December 01, 2024 @05:56PM (#42291367)
Sorry, which question did I miss?
Re:Show HN: Open-source private home security camera system ... by scottlamb on Monday December 02, 2024 @12:00AM (#42293260)
The question of "What is the purpose of introducing the untrusted "server" component?". Looks like you've since replied to this, but it wasn't here or I didn't see it when I dropped the parent comment. The reply also doesn't compare alternatives such as direct use of an object store API. I've fielded a lot of user support questions about installation and would really hesitate to add that extra moving part if it's not strictly necessary.

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.

Re:Show HN: Open-source private home security camera system ... by arrdalan on Monday December 02, 2024 @08:28AM (#42295981)
Yes, we have different approaches/designs. In fact, I don't even of think of Privastead as an NVR solution. The choice of using a hub is mainly because I didn't have control of the camera firmware. As I've mentioned in other comments, if I could, I'd move the hub logic to directly run inside the camera.

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. :-)

Re:Show HN: Open-source private home security camera system ... by scottlamb on Monday December 02, 2024 @12:36PM (#42298368)
> The choice of using a hub is mainly because I didn't have control of the camera firmware. As I've mentioned in other comments, if I could, I'd move the hub logic to directly run inside the camera.

Yeah. I'm also frustrated with cameras in general. I've commented on this a few times here before, [1] but tl;dr: I don't even know what camera I'd recommend even if I had the perfect open source firmware to flash onto it easily.

> 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.

Okay, interesting, yeah that sounds like a significant step up for most folks.

> 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. :-)

Patches very welcome. It could use more attention than I've been able to give it recently but likely will interact well with your camera model as-is.

[1] https://news.ycombinator.com/item?id=37815064