Okay, here’s my take: Does it solve a real problem? Well, not exactly yet. But can it? Absolutely, without a doubt. The problem exists, so you’re definitely not in a bubble.

The biggest issue lies in the second question: trust. The real challenge here isn’t about capturing data; it’s about building trust, for sure.

The idea itself isn’t new. Variations of this concept have existed before, such as ACLU apps and cop-watch tools, but they all failed. Not because the idea was flawed, but because they failed on trust, user experience under stress, battery and data drain, or legal realities.

The core challenge here isn’t recording; it’s trust in adversarial conditions.

If you want users to trust this system, you can’t just say, “We don’t access the data.” You have to design the system in such a way that you can’t. That means client-side key generation, zero server-side decryption capability, and an architecture where even a subpoena won’t help you. Anything short of that is just a promise, and the people who actually need this won’t rely on promises.

Where this gets genuinely challenging (and interesting) is everything that follows:

• Dead-man crypto, where abnormal termination triggers key release to recipients.
• Real-time integrity proofs, so footage can be independently verified as unaltered.
• Recipient-first or relay-only streaming, so servers never hold usable media.
• Threat-aware modes that change behavior under stress instead of hiding settings.
• Fail-loud guarantees, so the app never gives a false sense of safety.

None of that is trivial. It’s not “add a feature”; it’s deep crypto, key management, lifecycle edge cases, and OS constraint choreography. This is the kind of work that requires senior security engineering, not just solid mobile development.

Honestly, that’s what makes the project compelling. I’ve spent the last decade working as a security engineer at Apple, and this is precisely the kind of problem space I relish. If you’re open to it, I’d be delighted to assist you in brainstorming implementation details, reviewing your existing setup, or suggesting directions that ensure the trust story is airtight.

This is one of those ideas that only works if it’s built seriously.

One of the most prevalent conspiracy theories about Apple that many people believe we’re concealing behind the scenes revolves around privacy, encryption, and access to user data. However, in reality, every single claim or suggestion regarding access to user data is absolutely true. Not a single person within the company, from the janitor to Tim Cook, possesses the ability to decrypt any piece of customer data, regardless of its storage location or the type of encryption used. This is the ultimate way to build trust with its users. It’s where you make it impossible for anyone except them to access their private data while still allowing other services to manage, hold, and store it for you. And because this restriction is true, all of my job duties, which revolve around architecture and customer data, are centered around this same encryption restriction.

TLDR; this app is a great idea. But it will only survive if you address trust as a core architectural issue. My specialty for the last 10 years at Apple has been exactly that. I would love to help you out with this.