PR #142 mention labels: measurement on why the p-tag is the only load-bearing identity, and the display_name drift window that leaves open

[mfethe1]

Measurement from a parallel tree: the label is presentation-only all the way down, so the drift window is the one thing worth guarding

We maintain a long-lived block/buzz fork and have been working the same mention-addressing seam from the client end. PR #142 here (bb8c1911c publish nostr:npub1… as the member's current display_name; aba43d612 follow the mobile receiver's alias rule with hex fallback; 571152ea6/97d57c434 roster reconcile from .buzz/routing.json) lands on a conclusion we reached independently and can now put a number against, so sharing the measurement rather than re-litigating the design.

What we measured. Our upstream PR block/buzz#6578 ("mobile: consume agent mention acks (kind 44102)", +659/-0, 6 files) makes mobile consume the agent-side accept/decline ack for an @-mention. Building it forced us to decide what a mention is on the receiving end, and the answer matches your PR body's premise exactly:

• The visible @Label is inert text on both clients. Desktop renders the literal string; mobile pills any @word. Nothing on the read path resolves a label back to an identity, so a wrong label is invisible to every automated check and only a human notices.
• The only load-bearing identity in the event is the p tag — and we found it is not safe as an attribution key either. In mobile: consume agent mention acks (kind 44102) block/buzz#6578 we attribute every ack to the event signer, never the p tag, and drop acks whose signer was not itself tagged in the mention. The p tag carries the mention's author, and treating it as an identity claim is forgeable in a pure fan-out relay. 19 store tests cover exactly that (signer attribution, untagged-signer rejection, unknown/absent/empty/wrong-case status, idempotent double delivery, bounded eviction).
• Regression evidence for the surrounding surface: full mobile flutter test 1758 pass / 14 fail, and the same 14 fail on untouched upstream main (1647/14) with comm -23 ours baseline empty — identical failure name sets. flutter analyze 6 issues, unchanged. cargo test -p buzz-acp --lib pool::tests 131/0, publisher tag shape unchanged.

The open question your approach raises and ours does not answer. messages send freezes display_name into the event body at signing time, from the kind:0 fetch the mention preflight already does. That makes the published event indistinguishable from a desktop-composed mention — which is the right call for compatibility — but it also means the label is a point-in-time snapshot of mutable metadata embedded in an immutable event, while the p tag stays authoritative forever. After a member renames (or publishes a kind:0 your CI fetched mid-flight), the archive holds @OldName p-tagged to the right pubkey, and there is no render-time reconciliation on either client to notice.

So: do you treat that drift as acceptable (the label documents who they were then), or does .buzz/routing.json become the thing you diff against to detect it? Concretely — 571152ea6 reconciles rosters and 97d57c434 bootstraps routing from the head when the base lacks the file, so the reviewer/coder/owner pubkeys already live in one place. Does anything in the mirror or watchdog compare a published event's @Label against the current kind:0 for its p tag, or is the rewrite strictly write-side with no read-side audit?

Related: does aba43d612's hex fallback ever produce a label that mobile's @word pill regex splits differently than desktop's literal render? We hit no cases in block#6578 because we never parse the label, but you now have a producer that can emit a 64-char hex token into that position.

Happy to run any of the above against our tree if a specific measurement would help — we have the mobile suite and the acp publisher tests wired for it.