AOVIS Device Sharing Design — Family & Friends Access

Version: 0.1
Date: 2026-05-16
Status: Confirmed for Phase 1 development
Scope: AOVIS Account + Direct Store (aovis.app) device-level sharing for NEXA devices

1. Goal

Add a safe way for a NEXA device owner to share access with family or trusted friends without sharing the owner's password. Shared users must use their own AOVIS account and must not receive ownership, billing, SIM, order, or subscription management rights.

2. Competitor Patterns Referenced

• Ring Shared Users: invite-based access, device/location selection, 14-day invitation expiry.
• Arlo Grant Access: family/friends use their own accounts; non-admin users cannot add/remove devices or change system settings.
• Arlo privileges: base viewing access plus optional higher-level controls.
• Google Nest/Home: broad home-member sharing is powerful and not a good v1 default.
• Wyze device sharing: shared users can view/use camera features while owner keeps settings and sharing management.
• eufy sharing: device-level sharing and 5-user style limits are a practical v1 model.
• Blink account sharing: shared-password style full-account access is not suitable for AOVIS.

3. Confirmed v1 Product Rules

• Device-level sharing only; no Home/Household model in v1.
• Invite by email.
• Invitee accepts with their own AOVIS account.
• Roles for invitees: VIEWER and MEMBER.
• One physical device has one OWNER.
• Shared users cannot re-share.
• Max active + pending shared users per device: 5.
• Invite expiry: 14 days.
• No public camera links.
• No ownership transfer in this feature.
• No second trial, subscription, or entitlement is created for shared users.
• Owner-only: billing, cloud subscription management, SIM/data plans, orders, device sharing management, unbind/delete/reset/core settings.

4. Role Matrix

Capability	OWNER	MEMBER	VIEWER
Device appears in account	Yes	Yes	Yes
Live view	Yes	Yes	Yes
Playback/events if device has entitlement	Yes	Yes	Yes
Own notification preferences	Yes	Yes	Yes
Two-way talk	Yes	Yes	No
Snapshot/manual recording	Yes	Yes	No
Core settings	Yes	No	No
Manage sharing	Yes	No	No
Manage subscription/billing/SIM/orders	Yes	No	No
Unbind/delete/reset/transfer	Yes	No	No

5. Data Model Direction

Reuse existing DeviceOwnership as the accepted access source of truth:

• OWNER: physical owner.
• MEMBER / VIEWER: shared access.
• Add lifecycle status so revoked rows can remain auditable.

Add DeviceShareInvite for pending invitations:

• deviceId
• inviterUserId
• inviteeEmail
• role
• tokenHash
• status: PENDING, ACCEPTED, DECLINED, EXPIRED, REVOKED
• expiresAt
• accepted/revoked timestamps

Raw invite tokens must never be stored; only a hash is stored.

6. API Direction

Owner actions:

• Send invite.
• Change shared user role.
• Remove shared user.
• Revoke pending invite.

Invitee actions:

• View invite.
• Accept invite.
• Decline invite.

All device capability APIs should use a central role/capability guard instead of scattered owner-only checks.

7. UI Direction

Account → Devices:

• Owner sees Share access on owned devices.
• Owner can invite email + select Viewer/Member.
• Owner sees active shared users and pending invites.
• Owner can update role/remove/revoke.
• Shared users see the device labeled as shared access and do not see owner-only management actions.

Invite page:

• Requires sign-in.
• Shows inviter, device, role, expiry.
• Accept/decline actions.
• Wrong signed-in email is blocked.

8. Audit Events

Use AuditLog for:

• device_share_invite_created
• device_share_invite_revoked
• device_share_invite_accepted
• device_share_invite_declined
• device_share_role_changed
• device_share_access_revoked
• device_share_invite_expired

9. Implementation Acceptance

Before considering development complete:

• Add migration and schema.
• Add invite/share service and route tests.
• Update account devices UI.
• Ensure shared users do not receive new trial/subscription/entitlement.
• Run npm run test.
• Run npm run build.