Redesign Trusted-Contact Flows Around Invite And Accept States

[TheSilkky]

Redesign Trusted-Contact Flows Around Invite And Accept States

Priority

Very high

Type

Product design / frontend planning

Labels

backlog, frontend, design, accessibility, security, documentation

Branch Scope

Created from docs/end-user-product-design at d2c32a3.

Background

The current contact-key route is centered on manual public-key metadata. The end-user design document describes a future trusted-contact flow where a user invites a person, the contact understands what accepting means, and required key metadata is handled automatically by the client and backend contract.

That future flow depends on backend trusted-contact lifecycle support, so this issue should start as design and API-contract work rather than runtime implementation.

Proposed Scope

• Define trusted-contact states for invite created, pending, accepted, declined or expired, unavailable, and removed.
• Design owner-facing and trusted-contact-facing screens for invite and acceptance.
• Confirm what server routes and payloads are required before implementation.
• Define what copy must explain about responsibility, emergency limits, access scope, and experimental status.
• Specify where technical key state can appear for security reviewers.

Acceptance Criteria

• A design or implementation plan describes the trusted-contact lifecycle without asking normal users to paste public keys or choose algorithms.
• The plan separates trusted-contact account access from bearer viewer-link access.
• Required backend contracts are documented as dependencies and are not implemented in this repository.
• The flow includes accessible loading, pending, accepted, expired, error, and empty states.
• The copy does not promise emergency dispatch, notification delivery, decryption, or production reliability.

Out Of Scope

• Backend trusted-contact lifecycle implementation.
• OAuth, JWT, push notifications, SMS, Messenger notifications, or emergency dispatch.
• Browser decryption, raw key storage, key escrow, break-glass access, or playable export.
• Deleting the existing manual technical path before a reviewed replacement exists.

Suggested Validation

• Product design review
• Security review of proposed states and boundaries
• Server API confirmation against open-proofline/server
• Full frontend validation if a later issue implements UI changes:
  • npm run typecheck
  • npm run lint
  • npm run test
  • npm run build
  • npm run test:e2e
  • git diff --check