Current behavior
An agent cannot wake itself by mentioning itself, and the gate is in the SDK,
before signing: normalize_mention_pubkeys strips any pubkey matching the
sender (crates/buzz-sdk/src/mentions.rs:227-234, comment: "you don't
@mention yourself"). The p tag never exists on the wire, so the agent's own
mention-gated subscription ("#p" filter, crates/buzz-acp/src/relay.rs:3198)
never delivers the event. --no-ignore-self in buzz-acp doesn't change this —
it's downstream of a tag that was never written.
This is a reasonable default: it prevents accidental self-trigger loops on
ordinary chatter.
Why we'd like an opt-in
For a single agent identity working across many channels, self-mention is the
natural primitive for "continue this later" / fan-out: post a message in
channel B that wakes the same agent there, with the relay as the queue. Today
the only working triggers are a workflow posting the mention, or a second
agent identity minted just to poke the first.
We're fine with workflows for now — this is a discussion issue, not a blocking
request. Mostly we'd like to know whether the project is open to it before
anyone writes a patch.
Observed shape of a fix
The capability already exists and is unconditionally suppressed at the call
site: normalize_mention_pubkeys(pubkeys, None) preserves self-mentions and
has a test asserting exactly that (mentions.rs:642). An opt-in (per-send
flag or agent-level setting) that passes None/skips the sender filter would
be a small patch. Loop safety could stay where it already lives — the
receiving side's ignore_self / mention gating — or a self-mention could
require an explicit flag on send so it can never happen by accident.
Questions for discussion
- Is self-wake something Buzz wants to support at all, or is "mint a second
identity / use a workflow" the intended pattern?
- If opt-in: per-message flag on send, or per-agent config on the receiving
subscription?
- Any loop-protection invariants the relay should enforce (e.g. hop count,
rate limit on self-p-tagged events)?
Current behavior
An agent cannot wake itself by mentioning itself, and the gate is in the SDK,
before signing:
normalize_mention_pubkeysstrips any pubkey matching thesender (
crates/buzz-sdk/src/mentions.rs:227-234, comment: "you don't@mention yourself"). The
ptag never exists on the wire, so the agent's ownmention-gated subscription (
"#p"filter,crates/buzz-acp/src/relay.rs:3198)never delivers the event.
--no-ignore-selfin buzz-acp doesn't change this —it's downstream of a tag that was never written.
This is a reasonable default: it prevents accidental self-trigger loops on
ordinary chatter.
Why we'd like an opt-in
For a single agent identity working across many channels, self-mention is the
natural primitive for "continue this later" / fan-out: post a message in
channel B that wakes the same agent there, with the relay as the queue. Today
the only working triggers are a workflow posting the mention, or a second
agent identity minted just to poke the first.
We're fine with workflows for now — this is a discussion issue, not a blocking
request. Mostly we'd like to know whether the project is open to it before
anyone writes a patch.
Observed shape of a fix
The capability already exists and is unconditionally suppressed at the call
site:
normalize_mention_pubkeys(pubkeys, None)preserves self-mentions andhas a test asserting exactly that (
mentions.rs:642). An opt-in (per-sendflag or agent-level setting) that passes
None/skips the sender filter wouldbe a small patch. Loop safety could stay where it already lives — the
receiving side's
ignore_self/ mention gating — or a self-mention couldrequire an explicit flag on send so it can never happen by accident.
Questions for discussion
identity / use a workflow" the intended pattern?
subscription?
rate limit on self-p-tagged events)?