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.

  • 58
    Just a warning: if this feature is implemented, I will change my username over and over again, each time choosing another user's name, until either all comments begin with "@Pesto" or the system collapses under the strain. – Hilarious Comedy Pesto Dec 4 '09 at 17:17
  • 3
    Like Smith in the matrix... only I can stop you Pesto – juan Dec 4 '09 at 17:21
  • 16
    It is quite a bummer, however, that this can't be done as is. I've seen several comment streams that have become difficult to follow after none of the names match up any longer. – beska Dec 4 '09 at 18:13
  • 31
    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. – Brian R. Bondy Dec 4 '09 at 19:28
  • 7
    @Hilarious Comedy Pesto: Regarding collapsing under the strain, there could be a "username change" maximum in place per day. – Brian R. Bondy Dec 4 '09 at 19:34
  • 8
    I don't think this is so impossible. The same way that SE detects which user you are "@referencing" so that it can notify them, it can know which "@references" to map to which usernames. – Hod - Monica's Army Jan 18 '12 at 17:20
  • 4
    Doing this would not be hard; doing it accurately would be impossible for the reasons outlined below. It would also be quite expensive. – Shog9 Mar 25 '15 at 18:07
  • 2
    Newbie here, just posted a related question and then found this one. The thing is, this leads to big privacy issues: some users have changed their names for legitimate privacy reasons, but if the mentions in comments don't subsequently update, then the name-change is moot. – artificial_moonlet Jun 14 '19 at 14:48

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.

  • 20
    Unfortunately, that part of the penalty for switching names is not borne by the user who switched names, but by other users who later visit that discussion. As an argument against, it is utterly worthless - the indirect effect is not enough to deter anyone from changing names. – muru Jun 13 '15 at 7:18
  • Your last sentences makes sense and are also an argument in favor of not allowing one to change their user name. Why allow it? Just be careful when you set up your account to select one you can live with. If you come to regret it, too bad. Create a new account. – raven Jun 14 '15 at 17:57
  • @muru: agreed. Thus, the system should have been designed to store UIDs and disallow duplicate names. I'm not completely convinced it's too late now, either--without any data to support this guess, I'd guess there are a few hundred ambiguous cases. – Mathieu K. Feb 9 '16 at 16:42
  • @MathieuK. as a tangent, it would allow for better anonimization of deleted accounts. For example, this comment is to a now deleted user on that site but the comment still hints at who the user was. However, should have been is... well, that horse is out of the barn now. It is all based on reasonable design goals with this outcome as a consequence. – user213963 Feb 9 '16 at 17:03
  • 7
    As soon as someone leaves a comment, you need to figure out who to notify - at that point you can update the original comment to have a user ID instead of a username. When loading a page, you already get the user ID / username combination of any user the comment could've replied to*, so all you need is a client-side insertion of the username. Or at least you get all ID/name combinations of comments that are still around, but if the comment is replying to a non-existent comment, it wouldn't really matter what the @-username displays. Seems simple enough. Edge case is hidden comments though. – Bernhard Barker Jul 16 '18 at 14:23

I could see this causing some problems because:

  • Maybe someone refers to an unrelated @Brian on twitter, and then @Brian changes his name on stackoverflow.
  • Comments can be stolen by renaming your name to someone and then back to someone else.
  • Sometimes people will refer to me as @Brian; however, a real @Brian may change his name to @Bob and then no one would know people were referring to me.
  • This wasn't implemented since day #1, so there are probably a lot of @Name's out there that can be stolen to be renamed to an unrelated person.
  • How do you differentiate between @Brian the developer, and a user named "@Brian the developer". Spaces could cause bad renames.
  • Search / replace for name changes could be a costly operation on all text comments
  • You are changing the text strings of people's comments, so changing their original comments may make them mad.

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.

  • As I said, only references to your actual user name could be changed. "@Brian" would not be changed if you changed your name to "Minihaha", only "@Brian R. Bondy" would be changed to "@Minihaha". – raven Dec 4 '09 at 17:27
  • Every one of my points are still valid even after your rehash comment here. My concern was that if @Brian changes his name to @Tom then so will the comments that are supposed to refer to @Brian R. Bondy, but actually refer to @Brian. SO it will look like there is an @Tom in the conversation. No one would link that to @Brian R. Bondy, people will link @Brian to @Brian R .Bondy. – Brian R. Bondy Dec 4 '09 at 17:33
  • Now I see, that's a good point. – raven Dec 4 '09 at 17:36
  • @BrianR.Bondy Rather than just changing every @Brian, wouldn't the system store comments as references to specific users rather than their names, then just render their names after? – Redwolf Programs May 19 '19 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.

  • 31
    You're just showing off your user id again, aren't you? – mmyers Dec 4 '09 at 19:58
  • 27
    If you had a user-id of 1337, wouldn't you show it off? – Brad Gilbert Dec 4 '09 at 20:16
  • 6
    No. I mean... wait... who am I kidding? – mmyers Dec 4 '09 at 22:46

No. Usernames are not unique, so this fails horribly.

  • So? Then you need a much bigger and more expensive query to try to guess which instances of "@foo" need changing, and you still can't guarantee that you'll get it right. The only right solution would be to build comment referencing support in, and the team has resisted that. – dmckee --- ex-moderator kitten Dec 4 '09 at 17:35
  • I deleted my comment before I saw your response. You're right. I now understand how this can't work. – raven Dec 4 '09 at 17:39
  • 5
    This, to me, highlights another reason why usernames should be unique. – beska Dec 4 '09 at 18:12
  • 3
    @beska: So what do all the people with common names like "John Smith" do when more than one try to work under their own name? – AnonJr Dec 4 '09 at 19:48
  • @AnonJr: Good point, although I wonder if they would then have been in a worse trouble than if, under the present circumstances, they happened to answer the same question (or couldn't resist answering one another's question). – Andriy M Jan 21 '13 at 9:27
  • 3
    "Usernames aren't unique"... So does this mean everyone can rename himself to Jon Skeet? It would be funny... – Calmarius Sep 26 '13 at 13:42

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.

  • 4
    Its sometimes difficult to tell the difference between a name change, and someone deleting a comment. – Brad Gilbert Aug 29 '14 at 13:43

Would this solution work?

  1. add a NotifiedUserId column to your Comments table
  2. populate that column on comment creation. At that point, you know how to map the notification to a precise user: that is the same logic that you already use to notify them in the first place.
  3. when a username is changed, edit the text of all comments in which the user has been notified (which you can now get with a select * 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.


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.

  • 1
    Comments could be restricted so that name tags have to exist. Similar to how it already stops you from entering multiple names. – Paul Fleming Dec 29 '12 at 16:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .