Research a privacy-safe Scrypted ObjectsDetected adapter boundary

[elkampu]

Why this is the leading next input-family candidate

Scrypted exposes a public event callback carrying eventSource, eventDetails, and eventData, plus an ObjectsDetected model for object-detection events:

• EventListener and EventDetails
• ObjectDetectionResult and ObjectsDetected
• MQTT publication of serialized event data under the event-interface topic

That is a closer fit for OpenCamInterop than a streaming-only integration because there is a documented event object that can be reduced to synthetic offline fixtures.

Boundary to resolve before implementation

A first adapter must not guess over these ambiguities:

• The MQTT publication serializes eventData but does not include eventDetails.eventId or eventDetails.eventTime.
• ObjectsDetected.sourceId may identify a camera or a generating plugin, so it cannot automatically be treated as a camera identifier.
• A detection can contain label, embedding, bounding boxes, landmarks, clip paths, thumbnails, video resources, and other data that OpenCamInterop should not retain in a public fixture or normalized event.
• The public type alone does not establish whether one delivery means detected, updated, ended, or a point-in-time batch.

Proposed bounded first slice

Before writing production code:

1. Confirm from public documentation or a Scrypted user whether the MQTT ObjectDetector event payload follows ObjectsDetected in current releases. A safe description is enough; do not post a private payload.
2. Choose an explicit caller-provided, opaque camera identifier rather than deriving identity from a user-named topic or treating sourceId as a camera unconditionally.
3. Define deterministic occurrence time and event identity without relying on delivery time.
4. Allowlist only the minimum interoperable fields, likely a synthetic object id, className, score, zones, history timestamps, and payload timestamp.
5. Always omit recognized labels, embeddings, geometry, media resources, installation paths, and transport credentials.
6. Add one synthetic fixture, schema/manifest support, adapter tests, EventLab CLI support, and privacy assertions.

Acceptance gate

• The adapter remains transport-free and opens no Scrypted, MQTT, camera, or network connection.
• The supported input envelope and channel are traceable to public Scrypted behavior.
• Missing or ambiguous identity and time fail with stable diagnostics rather than guessed values.
• Duplicate JSON properties, excessive nesting/counts, invalid numbers/timestamps, and oversized input are rejected within existing bounds.
• Serialized CloudEvents contain none of the excluded biometric, geometry, media, credential, or private-installation fields.
• Windows and Ubuntu CI remain green.

This is maintainer-authored candidate research. Opening or completing it does not count as an external behavior contribution, independent consumer, or compatibility claim.