A camera-first, encrypted handoff designed to make image collection more auditable and private.
The most useful way to understand this project is to start with the friction behind it, then examine the system choices made to address that friction.
A recipient who needs a fresh photo—such as a remote verifier—may receive a recycled, edited, or unrelated image through ordinary file uploads. At the same time, sending an unencrypted source image through a centralized upload service exposes it to unnecessary storage and account-access risks.
Capture uses a requester-generated keypair and a sender-side camera flow. The sender captures an image through the browser’s camera interface, encrypts it for the requester, and shares an opaque `.capture` artifact through an ordinary channel. The requester decrypts it with a private key retained in their own browser. The goal is to reduce raw-image exposure and make the expected capture workflow stricter.
A strong implementation has a bounded audience and context. These are the use cases supported by the current design—not a claim that all of them have been validated at scale.
Small verification workflows where someone needs a fresh image from a remote person and both parties want to avoid storing an unencrypted original on a new central service. It is a technical proof-of-concept for a privacy-preserving handoff, not a legal identity-verification product.
An overview of key capabilities and system features.
The requester creates a capture request and local keypair.
The sender grants camera permission and captures inside the browser workflow.
The source image is encrypted before the resulting artifact leaves the sender’s browser.
The `.capture` file can be sent by email or messaging without a new image-hosting backend.
The requester uses their private key from local browser storage to view the result.
Architecture and system flow overview.
Creates keypair and retains private key locally.
Transfers only the public/request-specific information needed to start capture.
Uses MediaDevices camera input and encrypts the image with TweetNaCl-based cryptography.
Opaque artifact goes through an ordinary channel; requester decrypts locally.
React, Vite, TypeScript, Tailwind CSS, TweetNaCl.js, IndexedDB, MediaDevices camera APIs.
Engineering choices and design decisions behind the implementation.
Key technical details and system scope considerations.
The next step is not simply adding features. It is increasing reliability, evidence quality, user trust, and clarity about the boundaries of the system.
Add request expiry, replay protection, and clearly scoped challenge text.
Make key backup/recovery trade-offs explicit without silently uploading private keys.
Document the threat model and test that malformed or reused request artifacts are rejected.
Use it only as one control in a larger verification process when consequences are high.
Project repositories and resource links.