Skip to content

Remove Manual Public-Key Entry From Primary Trusted-Contact UX #69

Description

@TheSilkky

Remove Manual Public-Key Entry From Primary Trusted-Contact UX

Priority

Very high

Type

Frontend design / security hardening

Labels

backlog, frontend, design, security, accessibility, testing

Branch Scope

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

Background

The current contact-key page asks users to work directly with public-key metadata, wrapping algorithms, fingerprints, and reviewed state. The end-user design document says normal users should manage trusted people and invite states, while manual public-key entry remains only an advanced, reviewed, technical path.

This should be a separate issue from the broader invite/accept redesign so the manual path is preserved intentionally until a safer primary path exists.

Proposed Scope

  • Move manual public-key entry out of the primary trusted-contact journey once an invite-based journey exists.
  • Mark the manual path as advanced or technical and explain when it is appropriate.
  • Keep security-review fields available without making them the normal user task.
  • Review visible copy for confusing crypto-first terminology.
  • Update route tests and accessibility coverage for the revised interaction path.

Acceptance Criteria

  • Normal users are not prompted to paste public keys, choose wrapping algorithms, or compare fingerprints as the primary contact-management path.
  • A reviewed advanced/manual path remains available for local testing, migration, or security review if still needed.
  • The UI clearly separates person/invite state from technical key metadata.
  • Error and empty states do not push users toward unsafe manual key handling.
  • Tests cover the default contact-management path and the advanced/manual path.

Out Of Scope

  • Implementing backend lifecycle routes in this repository.
  • Removing manual key functionality before replacement behavior is available.
  • Browser decryption, raw private key handling, raw media key handling, key escrow, or break-glass access.
  • Notification delivery.

Suggested Validation

  • Product copy review
  • Security review of the remaining advanced path
  • npm run typecheck
  • npm run lint
  • npm run test
  • npm run build
  • npm run test:e2e
  • git diff --check

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions