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
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-designatd2c32a3.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
Acceptance Criteria
Out Of Scope
Suggested Validation
npm run typechecknpm run lintnpm run testnpm run buildnpm run test:e2egit diff --check