The fact that a user can change their name at will can lead to some confusion in the comments. For instance, suppose a user named "foo" changes his name to "bar", all those comments signed by "foo" are now signed by "bar", but responses to "bar"'s comments still start with "@foo".
Could those "@foo" references in comments be changed to "@bar"?
A brief discussion on this has set me straight. I didn't think it through. Request withdrawn.
This isn't likely to happen. The reason is that comments are rather limited in the database. Why? Well, there are nearly 40M of them active in the database for Stack Overflow. Compare this with 25M active posts (questions, answers and a few other things).
A decision was made early on that comments need to render fast. This is especially important when a you've got dozens of comments with the questions and answers on a single page. One trip to the database to get all of the comments and we're done.
We could store the text user name (as it is currently done) and we get @MichaelT there is an issue with this. As noted, user names are not unique. The problem is that whenever someone named MichaelT changes his or her name you don't know which comments to update. It gets particularly hairy if two or more of the same name are in the same set of comments making trying to reverse the business logic impractical.
Notifications can work on partial names too. If I am the only Mich... to comment, then @Mich this works works too. This makes reversing the business logic even more impractical.
We could try reprocessing the submitted text to change the pinged user to an ID.
This means that storing @{4228} or something similar in the text requires multiple passes through the database. Once to fetch the text, (process the text), another to fetch the corresponding user names in the text.
If we were to go back and try to store the information about the pinged user (to try to reduce the business logic backtracking issue), we now have another table that would look something like:
id (pk)
commentid (fk)
userid (fk)
noting that this is a one to many relationship.... for 40M comments. And this still doesn't get around the problem of multiple identities in a comment thread. Someone change their name, but who was this referring to?
It really gets ugly and a lot of work for little gain. The book keeping on comments for names needs to not be expensive.
I'm going to bring you to one of my favorite texts about online communities: A Group Is Its Own Worst Enemy. I'm going to also point out that the author of this is a mentor/hero of Jeff's and last I checked had some relationship to the board of directors for Stack Exchange. The point I'm making here is that his works are influential on the thoughts of Stack Exchange.
Four Things to Design For
1.) If you were going to build a piece of social software to support large and long-lived groups, what would you design for? The first thing you would design for is handles the user can invest in.
Now, I say "handles," because I don't want to say "identity," because identity has suddenly become one of those ideas where, when you pull on the little thread you want, this big bag of stuff comes along with it. Identity is such a hot-button issue now, but for the lightweight stuff required for social software, its really just a handle that matters.
...
Users have to be able to identify themselves and there has to be a penalty for switching handles. The penalty for switching doesn't have to be total. But if I change my handle on the system, I have to lose some kind of reputation or some kind of context. This keeps the system functioning.
Part of the penalty for switching names is that loss of context in past comments.
Switching names is something that is recognized as being mildly disruptive. Trying to make it a smooth transition to change your name works against having a more cohesive community.
I could see this causing some problems because:
I think it would be possible this way:
I think this could be accomplished though for future comments via some new username insertion schema. At the time of posting the comment, the server would not store the string @username, but instead @userGUID, then at the time of displaying it would resolve those.
If the server replaced the @userGUID, it could also put a link to the @username's account, so that the poster of the comment could ensure it referenced the correct user.
Still I'm not sure that would be worth the effort.
@Brian, wouldn't the system store comments as references to specific users rather than their names, then just render their names after?
Commented
May 19, 2019 at 21:22
This would happen automatically if my answer on a related question, was implemented.
@[1337] Hey, look I'm talking to myself.
Would get turned into:
@Brad Gilbert Hey, look I'm talking to myself.
<a href="https://meta.stackoverflow.com/users/1337/brad-gilbert">@Brad Gilbert</a> Hey, look I'm talking to myself.
This could get problematic to comments on questions which later get migrated. That hopefully doesn't happen with enough regularity for it to be that big of a problem.
No. Usernames are not unique, so this fails horribly.
Would this solution work?
NotifiedUserId column to your Comments tableselect * from Comments where NotifiedUserId=1337), to update the part following the @ with the new userid. This may be an expensive operation, but it does not need to be done synchronously.This would allow updating usernames on all comments created after this database modification. Changing notifications retroactively on older comments is impossible, because username history is already lost.
Variant: one could replace the current system in which notifications may appear everywhere in the comments into one in which the username of the notified user must be at the beginning of the comment (many users already use notifications in this way, in practice). Then this username would not be part of Comments.Text anymore, and can be rendered directly from the NotifiedUserId field. In this way, the most expensive point 3. is eliminated, but one incurs in a little additional work at every page view (which may be undesirable, I understand).
This looks to me simpler than the solution @user213963 proposed in the accepted answer, which has a much higher cost: it needs one more table and a join. It also seems to fix most of the issues described in the other answers.
In case an user changes its username to Brian when there is already another Brian involved in the conversation, then it becomes impossible for readers to understand which Brian is the pinged one. But this is an edge case in which the users were already looking for trouble in the first place. (And note that one of the two Brians can then change his username again without issues.)
IANADBAdmin, so let me know if I am overlooking any obvious problems.
I think that changing the usernames is a good idea because there is a personal safety issue related to not changing the updated username, one that I have just encountered on Workplace.SE:
@<original name> replies.The abusive employer could easily come across the question, read the comments and see the user's real name, which then results in negative consequences...
While I agree with the sentiment behind it, I'm not convinced its that big a problem.
Normally/Usually/Generally you can tell from the context who is talking at whom, and even if you can't it doesn't detract appreciably from the information value (if any) in the comment.
Another suggestion similar to Brad Gilbert‘s and Federico Poloni‘s answers
When saving comments, change @username to @username[@12345], where [@12345] is an id of referred user. The system resolves names to id anyway to send notifications. The notation can use any other characters, but [@ ] seems consistent how other references are used.
When reading comments, [@12345] can be just ignored, or (imho better) replaced with https://meta.stackoverflow.com/users/12345/.
Background process to replace @username[@12345] to @newUsername[@12345] can run asynchronously and at any time later. There is no requirement that the names should be changed immediately.
The difference with Federico Poloni‘s answer is that no extra column is required, but some parsing of the text in the comment.However extra column may be beneficial for indexing of userId to make replacement process less expensive.
The difference with Brad Gilbert‘s answer is that @username is stored in the comment, which makes name replacement process asynchronous and not urgent.
Update of existing comments is optional and ,if decided to do, will be done only for comments if it is still possible to uniquely (within the post) resolve @username to userid. Some extra consideration for such tool are in the other discussion Name changes: updating past comments, alerts, and similar upon specific request
No, this won't work. Beyond what has been mentioned so far, it won't work correctly because some people do not respond to the full name also. Like the user Jon Skeet, Many people would just say @Jon. Besides that, the username is not the identifier of the user, so I can't see this ever being implemented.
