Repository source: docs/plans/backlog/identity_rename_option_step1_solution_assessment.md
Identity Rename Option Step 1 Solution Assessment
Problem Statement
Users need a safe re-setup or change-name option that can create a public rename or link record and clarify approval implications. Source: thread-20260826034147-0f5e8193, submitted 2026-08-26T03:41:47Z.
Option A: Allow local display-name changes only
Pros:
Simple and low-risk.
Avoids changing public identity history.
Useful for browser-local correction.
Cons:
Does not create an auditable public rename.
May differ across devices.
Option B: Add a canonical public rename/link record
Pros:
Auditable and portable.
Can preserve identity continuity across old and new names.
Supports public profile history.
Cons:
Needs schema and read-model decisions.
Approval inheritance must be explicit.
Option C: Require a new identity for name changes
Pros:
Avoids rename semantics.
Keeps existing identity records immutable.
Cons:
Fragments profile history.
Creates confusing approval and authorship behavior.
Recommendation
Recommend Option B.
Brief justification:
The request is about public rename/link behavior, so an explicit canonical record is the most coherent path if approval rules are resolved first.