Let someone ask whether a parcel is visible in one approved area without sharing your camera feed. The owner chooses the question, limits when it can be asked, reviews the image and releases only a short answer.

Inspiration

A parcel handoff can raise a small question: is it still on the doormat? Answering should not require giving someone ongoing access to a camera. Aperture explores a narrower permission: one object, one area and a limited opportunity to ask.

This is a proposed customer use case. I have not yet tested parcel handoffs with camera owners and recipients.

What it does

The owner saves a private reference, marks the approved area and previews the exact question. A pass sets an expiry, check budget and cooldown. Anyone holding its link can request that question, but cannot choose a different object or area.

The owner reviews each request and approves Visible, Not visible in the approved area or Cannot verify. The recipient receives the answer and its timing. Reference photos, review images, streams and private notes stay in the owner's workspace. The owner can revoke a pass while a check is pending.

The Ring integration discovers an authorized camera, retrieves recorded images and provides private live video. Definite Ring answers require a recent image with a verified source timestamp. A browser-saved live frame has unknown capture time, so it can produce only Cannot verify. Approval time is shown separately. Every answer requires owner review; the app does not recognize objects automatically.

How I built it

React, TypeScript and Vite provide the interface. A Node.js server stores accounts, references and checks in SQLite, while Sharp normalizes images and strips metadata. A Three.js illustration explains the permission model, with a keyboard-accessible SVG fallback.

The adapter calls official Ring endpoints and keeps the short-lived Playground credential in server memory. Permission is checked again after media retrieval and before an answer is released. Hashed pass tokens, transactional check budgets and recipient-specific responses keep access bounded.

Codex supported implementation and testing, Claude independently reviewed source, and Deepgram and FFmpeg were used for the demonstration. These development tools do not decide the app's answers.

Challenges

Early requests reached outside the Ring authorization window. After correcting that interval, some Playground image downloads returned MEDIA_NOT_FOUND even though live video worked. I added the explicitly uncertain browser-frame path instead of treating download or save time as capture time.

Revocation had to remain effective during slow requests. Recovery also needed to distinguish a definitely rejected request from an ambiguous one that might already have spent a check. The current implementation handles those cases separately.

Accomplishments

On 11 October, the timestamped official Ring Playground flow completed through the actual browser interface. A private reference captured at 12:08:37 was followed by a new recipient check and a separate Ring image captured at 12:18:44. Codex, acting as the operator, visually reviewed the parcel inside the approved area, selected Visible, confirmed the review and released the answer. The recipient displayed Visible with the Ring observation time and no image. After revocation, reloading that same pass showed that permission had closed. Times are IST.

This successful third pass is recorded separately from two earlier attempts that encountered timing or readiness problems. It adds browser evidence to the earlier local HTTP/provider verification; neither run establishes physical-device behavior or a real parcel handoff. The app itself does not automate image recognition.

The published 131-second demonstration uses fresh actual browser captures from the official Ring simulation. Edited reading holds and cuts keep the permission, private owner review, timestamped Visible result and revocation readable. An additional successful take is labeled separately, and the revocation returns to the original pass.

All 38 automated tests and ten browser recovery flows passed. Sanitized evidence distinguishes official provider checks from synthetic contract tests.

What I learned

A playing stream does not establish when its scene was recorded. Keeping source time and approval time separate lets that uncertainty remain visible to the recipient. Permission also needs checking when slow work finishes, not only when it begins.

What's next

Test the parcel workflow with camera owners and recipients, including authorized physical Ring-device media. Owner review remains an extra step; customer testing should establish when the bounded pass is useful compared with an ordinary message. Production OAuth account linking, password recovery, monitoring and retention controls remain future work.

Run and judge it

Source and local setup · Judge guide · Ring setup and acceptance · Friction log

Use Node.js 22.13+ and your own authorized Ring Developer Playground session. Enter its temporary credential only in the private Ring source screen. The Ring guide documents permitted download hosts and the timestamped image path. No physical Ring device is required for the simulator workflow. A simulator result is not proof of a real parcel's current location; absence from the approved area does not establish collection or theft.

Demo credits

Ring's Package simulation uses “Thief stealing our package” by frollard, licensed under CC BY 4.0. Ring provides a clipped version. Browser captures were edited into the walkthrough and the visible Ring watermark was preserved. English narration uses Deepgram Aura 2 Thalia, with captions and FFmpeg encoding.

Built With

Share this project:

Updates

Submission history