HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
scottlamb
moonfire-nvr
Rust2016–2025
scottlamb / moonfire-nvr

moonfire-nvr

Moonfire NVR, a security camera network video recorder

Web DevelopmentSystems & InfrastructureSecurity & PrivacyCreative & MediaNetworking
Explore on GitHubRead Hacker News discussions
2Distinct people
32Mentions
0Explicit recommenders
1.8KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Moonfire NVR, a security camera network video recorder

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year32 dated mentions

Observed mentions: 2016-12-27 05:52:55 UTC to 2025-10-24 16:37:24 UTC.

02462016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC101
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC000
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC000
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC303
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC505
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC606
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC606
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC505
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC505
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC101

What Hacker News says

32 sources
scottlamb·Oct 24, 2025
I think if you've hit this problem and are looking for solutions, this article looks like a helpful read. There are lots of ideas there. I wouldn't say this is a super common problem (though I have hit it). The opening example here is that logic outside `Parent` is maintaining its summary state based on its children. That's unusual; typically `Parent` itself would be responsible for that, and so you can inline the logic without having to expose the fields. Sometimes inlining the logic gets impractical though if the logic is super long. In that case it can be helpful to split it into sub-structs so that you can easily call a method on a group of fields. I did that here, for example: <https://github.com/scottlamb/moonfire-nvr/blob/ff383147e4ff7...> There have been language proposals to define "view types" which are basically groups of field
Read the rest
s that are borrowed. <https://smallcultfollowing.com/babysteps/blog/2021/11/05/vie...> IMHO, they're not worth the extra language complexity.
In Rust Contagious Borrow Issue
scottlamb·Dec 1, 2024
Probably, but I'd like to hear the author's take on a key design decision rather than guess. This is also not the only option to achieve some fraction of that goal—another approach would be for the camera hub to encrypt and upload directly to a cloud object storage API (AWS S3 and competitors) and give the client presigned URLs to access it. 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
Read the rest
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...
In Show HN: Open-source private home security camera system (end-to-end encryption)
scottlamb·Dec 1, 2024
What is the purpose of introducing the untrusted "server" component? Is it intended to run in a different place than the trusted "camera hub" component, such as on a cloud server? 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
In Show HN: Open-source private home security camera system (end-to-end encryption)
0points·Dec 1, 2024
Certainly interesting project, but I do encourage people to do more thorough research before starting a new project and claiming they needed to fill a void. > However, I could not find one that I could trust due to privacy concerns. > Many of them upload the plaintext of videos to their servers and none is fully open-source as far as I know. There's Frigate [1] which is off-cloud, opensource and self-hosted and it does person detection using GPU or Google Coral. It relays camera streams over WebRTC using ssl and works well with Home Assistant [2], which is your self-hosted off-cloud smart home solution. Then there's moonfire-nvr [3] which is written in rust and less feature complete than frigate. And then there's sentryshot [4], another option written in rust. Interestingly, your project got more stars since you posted it on HN than sentr
Read the rest
yshot has in total, and they have had a product out since 2021 while yours only support a single camera model and has no object detection. I suppose this reflects how unknown these option are, which is kind of unexpected since googling "rust nvr" lists them all in the first page. 1: https://frigate.video/ 2: https://www.home-assistant.io/ 3: https://github.com/scottlamb/moonfire-nvr 4: https://github.com/SentryShot/sentryshot > The prototype currently has a lot of limitations: mainly that it has only been tested with one IP camera Since you use rust, you should maybe have a look at retina: https://github.com/scottlamb/retina Personally, I use frigate with Home Assistant linked to HomeKit, so I get snapshots & video from frigate straight into my iPhone lock screen as soon as it detects moving people or cars outside my house.
In Show HN: Open-source private home security camera system (end-to-end encryption)
scottlamb·Aug 24, 2024
Temporal will be really nice in that it supports remote time zones, allows you to iterate through daylight saving transitions, etc. I can't wait for it to be fully taken advantage of by things such as mui's date time picker. Imagine if after selecting the fall back day, it saw the transition and let you pick a time during the extra hour. If after selecting the spring forward day, it wouldn't let you pick a time during the hour that doesn't exist. Today that doesn't work because everyone uses different crappy third-party libraries and mui functions on top of a lowest-common adapter that certainly doesn't do stuff like "show me the DST transitions in this day". This stuff matters sometimes; a user of my NVR wanted to save a clip during the fall back hour and got the wrong result because these things just don't work right today. https://gith
Read the rest
ub.com/scottlamb/moonfire-nvr/issues/244
In JavaScript dates are about to be fixed
scottlamb·Jul 17, 2024
I've been looking for a camera to recommend for use with my open-source NVR. [1] This sounds promising, but I have a few questions. * What's the status of Uniview? Are their cameras allowed in the US under the 2019 NDAA? still receiving FCC approvals since the Secure Equipment Act of 2021? Does Uniview participate in the Uyghur genocide? * Do you have any models with large sensors, e.g. 1/1.8" or wider? I prefer good night performance if possible, which I believe requires each pixel to be physically somewhat large. There are a lot of many-megapixel cameras with 1/3" sensors out there, which aren't so great there. * What's the pricing? Your camera page [2] has "contact us for info" instead of a price, and when that happens I usually assume it's too expensive for the DIY crowd and drop out. [1] https://github.com/scottlamb/moonfire-nvr [2]
Read the rest
https://monitoreal.com/product/monitoreal-perimeter-cameras-...
In Reverse-Engineering an IP Camera (2019)
scottlamb·Nov 18, 2023
> I’m currently thinking of moving over to continuous recording, perhaps trying out moonfire-nvr or mayhaps handwriting a gstreamer pipeline. Simple software -> fewer failure modes. Moonfire's author here. Please do give it a try! Right now it's a little too simple even for me, lacking any real support for motion or events. [1] But I'd like to keep that simple server core that just handles the recording and database functionality, while allowing separate processes to handle Frigate-like computer vision stuff or even just on-camera motion detection, and enhance the UI and add stuff like MQTT/HA integration to support that well. I'd definitely welcome help with those areas. (And UI is really not an area of expertise of mine, as you can see from e.g. this bug: <https://github.com/scottlamb/moonfire-nvr/issues/286>.) For now I actually run Mo
Read the rest
onfire and Frigate side-by-side. They're almost complete opposites in terms of what they support, but I find both are useful. [1] The database schema has the concept of "signals" (timeseriesed enums like motion/still/unknown or door open/door closed/unknown), but my code to populate that based on camera or alarm system events is in my separate "playground" of half-finished stuff, and the crappy UI for it is rotting in one of my working copies. I'd like Moonfire's database/API layer to also have a more Frigate-like concept of "events" and one of "object tracks".
In Frigate: Open-source network video recorder with real-time AI object detection
scottlamb·Nov 9, 2023
Maybe, but (and I say this as the author of an NVR [1]) security cameras only accomplish so much. It helps that in this case Amazon/etc. theoretically knows who opened your garage so with their cooperation (not a given), you should be able to match the video to the suspect, but even then it may not provide the expected standard of proof much less get your stuff back... [1] https://github.com/scottlamb/moonfire-nvr/
In Home Assistant blocked from integrating with Garage Door opener API
scottlamb·Oct 23, 2023
How do folks test timing-related stuff with MSW? AFAIK, MSW doesn't get along with jest.useFakeTimers. It drives me nuts; I have a bunch of disabled tests in an open-source project and at least one that is flaky because it uses real timers where I'd like to be using fake timers. [1, 2] I've been thinking about ripping out MSW from my tests in favor of my own API-level mock for this reason. But it seems like many other folks are happy with MSW. I have to assume there's something I'm not getting. I'm a fish out of water with frontend stuff in general... [1] https://github.com/scottlamb/moonfire-nvr/blob/5ea5d27908f1a... [2] https://github.com/scottlamb/moonfire-nvr/blob/5ea5d27908f1a...
In MSW 2.0 – Mock Service Worker
scottlamb·Oct 8, 2023
> I wonder how hard it would be to run your own streamer pipeline or whatnot on these things? Agree with the_biot: The actual streaming component is not too hard. If this were the biggest problem, I'd be thrilled to contribute to (or just write) an open source streaming server to complement my open source NVR. [1] The driver situation is indeed a bit harder—these things don't just have mainline Linux support with v4l2 for the video capture and encoding. Or open source drivers of any kind to crib from AFAIK. The biggest problem IMHO is that there just aren't any good cameras to buy, even completely ignoring the software aspect. I want a camera that: 1. doesn't support genocide. Nothing that involves Dahua, Hikvision, or Huawei. See IPVM articles on the subject. And a lot of available cameras are relabeled Dahua/Hikvision stuff and/or use H
Read the rest
uawei components. 2. is legal for sale / authorized for use in the US. (See the Secure Equipment Act of 2021.) Mostly this excludes the same companies. 3. has good night mode performance: IR/day switch, a sensor that is at least 1/1.8", reasonable resolution (somewhere from HD to 4k). 4. has an "eyeball" or "turret" form factor rather than "bullet". The latter seems to really attract spiders, so you end up with a really nice video of a web... 5. supports PoE. 6. is weatherized (IP54 or so). 7. is reasonably priced. If you ignore #1 and #2, there's some nice hardware out there, but I'm not willing to do that. If you ignore #3, there are a few options (GeoVision, maybe Reolink, maybe Hanwha.) If you ignore #4 and #7, there might be a couple (Axis, maybe Hanwha.) Nothing that ticks all the boxes. Hard to get excited about investing a lot in the software when the hardware isn't there. [1] https://github.com/scottlamb/moonfire-nvr
In OpenIPC: Alternative open firmware for your IP camera
scottlamb·Jan 10, 2023
Still depends. As it happens, I'm developing my own open source NVR software, [1] so I know a bit about this. Some cameras are fairly good about this, supporting the following features: * "Temporal SVC", in which the frame dependencies are structured so you can discard down to 1/2 or 1/4th of the nominal frame rate and still decode the remainder. * Three output streams, which you could configure for say forensics (high-bandwidth/high-resolution/high-fps), inference (mid-bandwidth/mid-resolution/low-fps), and viewing multiple streams / over mobile networks (low-bandwidth/low-resolution/mid-fps). * On-camera ML tasks too. (Although I haven't seen one that lets you upload your own model.) But other cameras are less good. E.g. some Reolinks [2] only support two streams, and the "sub" stream is fixed at 640x352, which is uncomfortably low. You
Read the rest
r inference network may not take more resolution than that, but even if not, you might want to crop down to the area of interest (where there's motion and/or where the user has configured an alert) to improve quality. (You probably wouldn't pair that cheap Reolink camera with this expensive inference card, but the point stands in general.) Even the "better" cameras' timestamp handling is awful, so it's hard to reliably match up the main stream, sub stream, analytics output, and wall clock time. Given that limitation it'd be desirable to just use the main stream for everything but the on-NVR transcoding's likely unaffordable. [1] https://github.com/scottlamb/moonfire-nvr [2] https://github.com/scottlamb/moonfire-nvr/wiki/Cameras:-Reol...
In AMD Alveo V70 AI inference accelerator card
scottlamb·Oct 20, 2022
The ONVIF SOAP APIs aren't really that important IMHO. They're mostly used for configuration. Configuring your camera is something you do rarely, and if you have to put up with some crappy web interface, proprietary plugin, or Windows-only desktop software for it, oh well. The most important part is getting the video. The popular open standard is RTSP. Many cameras have astonishingly poor RTSP implementations. See https://github.com/scottlamb/moonfire-nvr/wiki/Cameras:-Reol... for some of what I'm talking about. That ONVIF page (https://www.onvif.org/conformant-products/) says everything is fine for several Reolink models, but I don't believe it! After that would be some way to get the analytics, assuming the camera has them and they're any good. If the ONVIF API works well, great, but a proprietary API isn't that bad IMHO as long as it's
Read the rest
simple.
In Managing and using ONVIF IP cameras with Linux
scottlamb·Oct 20, 2022
That exists, but AFAIK the list drops down to nothing again if you add: 1. manufacturers don't actively support genocide (rules out anything involving Dahua, Hikvision, Huawei, as IPVM has described extensively), are allowed in the US (look up the Secure Equipment Act of 2021) 2. has a nice large sensor (the 1/1.8" models are great, but see point 1) 3. supports open source firmware (none of them do AFAIK) 4. reasonably affordable (surprisingly, this part is not the biggest problem) 5. nice-to-have: has an NPU for on-camera analytics (there are cameras with this but mostly from the genocidal manufacturers...) The best I've got is GeoVision. No open-source firmware, sensors aren't as large as I'd like, no NPU, but relatively decent otherwise. https://github.com/scottlamb/moonfire-nvr/wiki/Cameras:-Geov... edit: actually, some of these 6MP H
Read the rest
anwha cameras look promising. Several say they have 1/1.8" sensors. Not cheap though, and no eyeball/turret form factor.
In Managing and using ONVIF IP cameras with Linux
scottlamb·May 14, 2022
> WebRTC largely prefers dropping packets to stay real-time In my experience, this doesn't work as well as people say. I haven't played with WebRTC yet, but my understanding is it's based on RTP over an unreliable transport, which I am familiar with. Dropping packet by packet (no mechanism to either retransmit the dropped packet or skip sending the rest of the packets in the frame) isn't great. When you lose one packet, you lose a full frame but waste bandwidth sending the data anyway. Worse, it's usually a reference frame, so all the following frames are suspect until the next IDR frame. RTP over TCP (interleaved RTSP channels) can be better, by retransmitting lost packets belonging to a frame once you've decided to send that frame, and by skipping whole frames at once when things fall behind (observed within the application as insuffici
Read the rest
ent buffer space). TCP has more rapid feedback, too. (ACKs are far more frequent than RTCP RRs.) > while HLS buffers and preserves every frame by default rather than drop frames to stay real-time. One is designed for calls (real-time) and one is not (streaming). That’s why HLS seems over-complicated. It’s not designed around real-time signalling, instead it’s designed around making requests for frames/bytes effectively sequentially. Sure, and the WebSocket protocol I mentioned also can preserve every frame, more simply. The most justifiable complexity IMHO in HLS is multiple encodings (variants) of different quality so you can switch between them. But not everyone needs/wants that, or trusts the user agent to do a good job with the selection. > MSE would be a way of capturing packets, but if the protocol doesn’t let you sequentially access bytes starting from a timestamp, you’re stuck when trying to resume a stream, no? MSE lets you specify your own protocol. Mine [1] lets you seek to arbitrary timestamps. It has its own complexity (around clock uncertainty/drift due to cheap/unreliable hardware setups) but will be more complex if I have to deal with HLS's complexity also. [1] https://github.com/scottlamb/moonfire-nvr/blob/master/design...
In Safari Technology Preview Release Notes

Showing the 15 most recent of 32 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.