2006年，罗伯特·安德森(Robert Andersen)发出了第一条提到另一位用户的推文，一个互联网惯例由此诞生。
在一个没有智能手机的世界里，Twitter的主要界面是短信。没有线程，没有@UserName自动完成。如果用户说了什么，而你想回复，你唯一的选择就是给40404写一条新的文本，在手机的短信文本框中手动键入@提及。短信也是推特最初的140个字符限制的由来：
Twitter最初是一项基于短信的短信服务。这将最初的推文长度限制为140个字符(部分原因是SMS的160个字符限制，其中20个字符保留给命令和用户名)。
同样是短信时代的遗留问题，Twitter不允许任何格式化或富文本。如今的用户通过使用Unicode提供的各种可能性来绕过这一限制。文本生成器将ASCII字符转换为𝔲𝔫𝔲𝔰𝔲𝔞𝔩𝔘𝔫𝔦𝔠𝔬𝔡𝔢𝔠𝔥𝔞𝔯𝔞𝔠𝔱𝔢𝔯𝔰。模因利用重复的空格来定位文本，或者绘制Unicode房屋。(当然，屏幕阅读器完全无法访问所有这些内容。)。表情符号修饰符允许使用肤色和性别修饰符来表达广泛的情感。
重要的是，这个“纯”文本完全可以复制粘贴到任何支持Unicode的应用程序中。虽然2006年的许多Twitter用户可能仅限于GSM-7编码，T9键盘的局限性，以及他们的手机有限的文本呈现和整形，但现代用户已经找到了使用完整的Unicode字符空间来表达自己的新方式。如今，推文、名称、URL、标签，基本上所有东西都可以包含Unicode字符。当然，除了“提及”之外，一切都可以。
Twitter上的用户名要求与短信时代大同小异a-z最多15个字母，0-9之间的数字和下划线_。这一要求与许多其他网站类似：GitHub只允许字母数字字符和非重复连字符，而Facebook只允许字母数字字符和句点。
想象一下，如果GitHub允许用户名只由数字0-9和中文字符组成，而不是字母数字。那会很令人沮丧的，对吧？如果被迫使用这样的系统，我们很可能会忽略中文字符，只使用数字作为用户名。这经常发生在不使用拉丁文的国家的社交媒体平台上。在中国，QQ即时通讯服务(最初始于1999年)完全摆脱了AOL等类似服务使用的用户名。取而代之的是，每个用户都被分配了一个唯一的号码，即他们的QQ ID。这个号码不能由用户选择，并且是不可变的。类似地，微信在用户注册时会分配一个随机数字，尽管这确实让每个用户只有一次机会将其更改为他们选择的字母数字字符串。打长数字并不是特别符合人体工程学，这可能有助于解释二维码在中国的广泛使用。
即使在拉丁语国家，AOL风格的用户名也有问题。通过在登录时要求用户名，并要求用户名在所有用户中是唯一的，用户经常被迫在不同的服务上使用不同的用户名，从而创建他们必须记住的第二个密码。值得庆幸的是，大多数服务至少已经解决了这个小问题，通过使用电子邮件登录而不是基于用户名登录。
在世界各地，用户名只能由字母数字组成。为什么我们不能只允许Unicode，这样用户名就可以包含中文、西里尔字母或其他非拉丁字母呢？不幸的是，Unicode用户名也有自己的问题-看看世界上最大的用户名系统，域名系统和允许非ASCII字符的扩展名就知道了。这是一次必要的升级，但它也有不完善之处，允许注册如下网站：
这是截至2020年7月的最新Firefox，显示的似乎是一家大型医疗保健公司的网站“epic.com”。然而，正如你所看到的，内容实际上是一些随机的博客，提醒人们喝水。这怎麽可能？如果我们将代码放入Unicode字符检查器中，我们可以看到发生了什么：
按字节计算，真实的“epic.com”和虚假的网站“еріс.com”是完全不同的。但从视觉上看，它们在地址栏中彼此难以区分，从而使网络钓鱼问题肆无忌惮地运行。Unicode规范化和规范化可以帮助解决此问题的某些情况，但对我们的epic.com示例无济于事。
这个特殊的例子在Chrome中是不可见的，相反，它向https://xn--e1awd7f.com/，显示了域名的“双关码”表示。这要归功于Chrome复杂的13个步骤，用于检测域名是否可能是Unicode网络钓鱼。“嗯，这可能很复杂，”你告诉我，“但至少它解决了钓鱼问题！”不幸的是，事实并非如此。
我们已经向Chrome报告了IDN同形异义词攻击的具体实例，我们会不断更新我们的IDN策略，以防范这些攻击。
Unicode规范显然太大了，不能100%完美地解决这个问题，所以他们的“解决方案”是向任何发现新的边缘案例的人支付2000美元。这实际上也没有解决非拉丁字母的问题--例如，如果我拥有一个中文域名，它将永远不会显示Punycode，并且攻击者可以使用这些中文字符的重复编码对我的站点进行网络钓鱼。Chrome只是试图解决一个小得多的问题，即视觉上看起来像拉丁字母的众多Unicode字符。
这可能会让人感到沮丧，您可能想指责Unicode，因为它没有为一系列字素提供规范的编码。或者我们可以责备域名注册商，因为他们允许进行视觉上相同的注册。但我认为真正的罪魁祸首是我们拉丁文字用户在我们的系统中构建用户名时的错误假设。我们假设两个视觉上相同的打印文本标记将具有相同的字节编码。对于很大一部分计算机用户来说，情况并非如此，这是当今基于用户名的系统的根本缺陷。唯一的解决方案是开发没有用户名的系统。
即使在没有不良行为者的受信任系统中，也不能保证重新键入打印文档中的非拉丁文用户名的用户最终会得到与原始文档相同的字节。
假设您正在构建一个仅供英语使用的站点，因此即使在阅读完所有这些内容之后，您仍然认为使用用户名可能是可以的。毕竟，您可能会发现，就像Twitter一样，这使得@提及的文本输入更容易实现。您可以只使用纯文本字段，而不是构建可以插入自定义@提及对象的输入字段。
不幸的是，您仍然会遇到某人更改用户名的问题。这通常是一个极其复杂的问题。以GitHub为例。在那里更改用户名会将旧的存储库链接重定向到新的存储库链接。但是，其他人可以进入并使用您的旧用户名。如果他们创建了与您的旧回购同名的回购，会发生什么情况？
如果旧用户名的新所有者创建了与您的存储库同名的存储库，这将覆盖重定向条目，并且您的重定向将停止工作。
URL不是唯一使用GitHub用户名的地方。在某些情况下，使用Web界面会使用电子邮件[电子邮件受保护]创建提交。这些提交将与您的帐户永久断开连接，除非您能够以某种方式强制将编辑过的提交头推送到您曾经贡献过的每个存储库。那就祝你好运。
Instagram在更改用户名方面也存在问题。在2015年前，更新您的用户名将导致您丢失之前所有的@提及。他们后来修复了这个问题；旧的@提及的内容最终会更新。推特应该也会保存你的回复，尽管我的测试显示这充其量是一个不可靠的功能。更新tweet中列出的实际@提及还会有其他问题，因为如果280个字符的tweet中提到的用户在其用户名中添加5个字符，您会突然得到285个字符的tweet。希望你的推特客户都能支持这一点。
用户名转换痛苦的最后一个例子是我在谷歌的那一年。我很幸运，从来没有更换过我的用户名，每天早上当我打开笔记本电脑，看到登录屏幕上的[电子邮件受保护]时，我都非常满意。但那里的工程师使用的无数内部系统都假设用户名是不可变的，这使得用户名切换需要数天的时间，而且永远不会真正完成。
当然，有一个简单的“解决方案”可以解决所有这些问题，那就是不能更改您的用户名。这就是Gmail做的事情：
如果您的帐户的电子邮件地址以@gmail.com结尾，您通常无法更改它。
我喜欢“通常”。我猜在某些神秘的情况下有可能改变它？在任何情况下，将随机的数字用户ID设置为不可变是可以的。但是，如果该用户ID包含字母并且是用户选择的，则使其不可更改对于实际情况来说是不可接受的解决方案。无论它包含用户的死名，还是他们不再使用的旧昵称，甚至对于我们这些在六年级时就认为“lordjubjub”将是一个优秀而专业的电子邮件地址(当然，只是一个假设的例子)的人来说，用户名都需要是可编辑的。如果它们是可编辑的，为什么不避免所有这些用户名问题，而直接使用完全Unicode、非唯一的显示名称呢？
已有2.5亿人注册了Discorde，这是一款类似于Slake或IRC的聊天应用程序。但是，与Slake和IRC的用户名对于特定服务器而言是本地的不同，Discorde只有一台服务器，并且用户名是通用的。由于2.5亿用户在一个用户名空间中，冲突成为一个巨大的问题，找到简短或合理的用户名几乎是不可能的，你开始看到用户大规模注册账户来出售比特币的用户名。
为了避免所有这些问题，Discorde放弃了唯一性要求。多个用户都可以有相同的用户名，尽管它们不完全是显示名称，因为在某些上下文中，用户名的末尾会出现一个不协调生成的#1234鉴别器编号。这甚至允许他们使用完全Unicode的用户名；当用户期望重复的用户名，并且您的系统都不依赖于用户名唯一性时，用户名仿冒就不是什么问题了。
Sack走得更远，2017年决定完全淘汰用户名，只使用显示名称。用户@通过键入@(人名的几个字符)并单击下拉菜单来提及彼此。在某些情况下，当存在重复的显示名称时，不从下拉列表中选择将导致错误：
作为一名文本编辑工程师，我也忍不住通过文本编辑技术的镜头来看待这一点。(是的，没错！它总是与文本编辑有关。)。用户名是过去几十年来使用的文本输入和编码系统的产物-只要看看Twitter的用户名需求是如何受到短信协议的影响就知道了。Slake和Discorde提供的用户名改进之所以成为可能，只是因为它们能够构建富文本编辑器(现代框架很难实现！)。它允许嵌入的、自动完成的@提及，而不依赖于文本标记的唯一性。您可能会感到惊讶，文本编辑方面的这些变化和进步在很大程度上推动了UI环境的发展。
我只有最后一个注意事项：虽然用户名非常常见，但它远不是将文本作为唯一令牌的唯一示例。JSONAPI无处不在地使用文本标记；我们最近才看到具有可重命名字段的协议(如协议buf和capnproto)越来越受欢迎。编程语言中的变量也是常见的文本标记，虽然可以说更改名称对于局部变量来说不是什么大问题，但在我知道的大多数语言中，更改公共类的名称是一个突破性的更改。文件系统目录也是唯一的文本标记，在两位软件具有相同的命令名或将它们的设置存储在同一目录的情况下，可能会出现命名冲突。
提议取消变量标签或文件名听起来可能不可能，或者很疯狂，或者没有必要，但我们的行业对用户名的喜爱正在减弱，这表明避免基于文本的唯一令牌有很多好处。如果我们想要摆脱这些限制，我们不应该指望修复令牌本身。从技术上讲，我们已经知道如何生成唯一的数字标识符，而且我们可以很容易地为目录或编程语言实体生成唯一的数字。相反，松弛和不和谐向我们展示了主要的问题-纯文本编辑迫使我们将我们的身份模型与我们的标签模型混为一谈。
事实证明这不是文本令牌问题。这是一个文本编辑问题。