Summary
When an @Name mention is ambiguous (the display name maps to two distinct channel members), the relay drops the mention and notifies nobody. The send is still accepted with "accepted":true, mention_pubkeys comes back empty, and nothing is logged relay-side or surfaced to the sender.
The dropping itself is deliberate and reasonable — resolve_mention_pubkeys in crates/buzz-relay/src/workflow_sink.rs documents that arbitrary selection would misroute and tagging every match would be a false-wake firehose. The problem is that it happens silently.
Impact
From the sender's point of view the message posts normally and the agent simply never answers. Every client-side signal reports healthy: the agent is connected, presence is online, the channel subscription succeeds. There is no error, no warning, and no log line on either side.
That indistinguishability from "the agent is slow" or "the agent is broken" is the real cost. We spent several hours across two sessions chasing a suspected relay delivery bug, a websocket reconnect bug, and agent-side wedging before finding the duplicate display name. A single warning would have ended it immediately.
Reproduce
- Register two members in one channel with the same
display_name and different pubkeys.
- Post a message containing
@ThatName.
- Observe:
{"accepted":true, "mention_pubkeys":[], ...} — no p tag, no notification, no diagnostic anywhere.
Suggested fix
Any one of these would be sufficient, in rough order of value:
- Return a warning in the send response when a matched name was dropped for ambiguity — e.g. an
ambiguous_mentions: ["ThatName"] field alongside mention_pubkeys. Clients could then show "that name matches two members."
- Log it relay-side at
warn, including the channel and the competing pubkeys.
- Reject the send with a clear error, so the sender must disambiguate. More disruptive, but unambiguous.
Option 1 is the smallest change with the highest diagnostic payoff, and it preserves current delivery behaviour.
Related
See #4303 for the underlying duplicate-identity condition and the channel-membership cleanup that resolves it.
Summary
When an
@Namemention is ambiguous (the display name maps to two distinct channel members), the relay drops the mention and notifies nobody. The send is still accepted with"accepted":true,mention_pubkeyscomes back empty, and nothing is logged relay-side or surfaced to the sender.The dropping itself is deliberate and reasonable —
resolve_mention_pubkeysincrates/buzz-relay/src/workflow_sink.rsdocuments that arbitrary selection would misroute and tagging every match would be a false-wake firehose. The problem is that it happens silently.Impact
From the sender's point of view the message posts normally and the agent simply never answers. Every client-side signal reports healthy: the agent is connected, presence is online, the channel subscription succeeds. There is no error, no warning, and no log line on either side.
That indistinguishability from "the agent is slow" or "the agent is broken" is the real cost. We spent several hours across two sessions chasing a suspected relay delivery bug, a websocket reconnect bug, and agent-side wedging before finding the duplicate display name. A single warning would have ended it immediately.
Reproduce
display_nameand different pubkeys.@ThatName.{"accepted":true, "mention_pubkeys":[], ...}— noptag, no notification, no diagnostic anywhere.Suggested fix
Any one of these would be sufficient, in rough order of value:
ambiguous_mentions: ["ThatName"]field alongsidemention_pubkeys. Clients could then show "that name matches two members."warn, including the channel and the competing pubkeys.Option 1 is the smallest change with the highest diagnostic payoff, and it preserves current delivery behaviour.
Related
See #4303 for the underlying duplicate-identity condition and the channel-membership cleanup that resolves it.