fix(ui): prevent sender color of past messages #201
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #200
Description
Previously, the sender was identified by comparing
message.sender
(a nickname string) tocurrentUserNickname
. This caused issues when the nickname changed, since past messages would then match or not match incorrectly, leading to inconsistent color assignments.The updated logic compares
message.senderPeerID
tomeshService.myPeerID
, which is a unique and stable identifier for the user. This ensures that the correct color (colorScheme.primary
) is applied consistently to the user's own messages, regardless of any nickname changes.Why this matters
Fixes a bug where changing your nickname would retroactively change the color of your past messages.
Prevents conflicts where multiple users with the same nickname might get the same sender color.
Makes message ownership checks more reliable by using a unique ID instead of a mutable nickname.
Screenshots/Screen recordings
pr-video.mp4
Checklist