The remote access part can be solved by wireguard or tailscale for less hands-on approach. Ntfy.sh/telegram/whatever cool kids use these days for notifications.

This and my previous comment probably amount to a full Dropbox comment now :)

Can you elaborate on the sending video part -- do you transfer the whole file or a link to the file on the server? Curious about the replication piece I mentioned

Privastead uses end-to-end encryption between the hub and the app. The hub encrypts the whole video file and sends it (through an untrusted server) to the app. The app will have a local copy of the video. The hub deletes the video upon delivery to the app. The server never has access to the unecrypted video.

WebRTC might provide a good way to handle this.

Yes, indeed. Using WebRTC and MLS together should provide good performance and privacy. In fact, Discord recently did that: https://discord.com/blog/meet-dave-e2ee-for-audio-video

It's something I plan to look into at some point.

I've been using locally hosted NVRs going on two decades now and so I definitely appreciate another local NVR option. But given the current lack of common requirements (e.g. more than 1 camera), curious if you're seeing any usage outside of your own? As others have mentioned Frigate is filling a nice gap for many, currently. I can only connect to it via a VPN I control and I can easily get notifications via Home Assistant.

I feel as though I have protection of getting the feeds to my phone securely, already. And while I'd love to be able to trust exposing Frigate and making it more accessible, I really don't have a need nor would I as the barrier to entry is already low enough to not impose much friction.

My intent isn't to dissuade you (obviously you wrote it for yourself) but I'd be curious if implementing a more secure transport in an existing OSS NVR that has traction was something you considered?

Your local setup plus VPN/wireguard is a good design. For me, port forwarding on my router was a no-go due to the increased attack surface. Therefore, I wanted to use the cloud to route the videos and hence I decided to use a strong end-to-end encryption scheme (MLS).

Regarding the limitation you mentioned: I plan to address them. The next task on my plate is to support multiple cameras. :-)

I actually don't do any port forwarding for my VPN. I end up back hauling over a public termination point on existing tunnels. All tunnels originate outbound in this manner.

Looking forward to seeing your project progress!

FWIW, e2ee is a feature that mostly matters to me when I don't own the infrastructure, and my bytes are flowing over someone else's platform.

If I do own all the infra, it seems like a lot of extra effort and complexity in the application which could be farmed out to other solutions (I.e. wireguard).

That's right. My assumption is that the server is untrusted and that's why I use end-to-end encryption. This allows me to use any server, possibly even one operated by a third-party service in the future.

How is video streamed to the apps? Push notification services are not meant for real time video streaming.

RTSP

Push notifications are for notifying the apps of events (e.g., motion). The actual encrypted video (either motion-triggered video or livestreams) are transferred through the server.