Problem
A bridge can verify and carry a complete event signed by an outside Nostr identity, but a Buzz channel currently accepts and renders the bridge's new kind:9 event. The UI therefore shows the bridge's name and avatar as the author, while the original signer can appear only in body text or custom tags.
That is cryptographically honest only at the transport layer and visually misleading at the author layer. A user who blocks, inspects, or attributes the visible author is acting on the bridge identity rather than the person who signed the source event.
Concrete use case
Waggle ingests an allowlisted public kind:1 or an admitted external participant event, verifies the original signature, and presents it inside a Buzz community. Its current best-effort rendering is:
Original Author · npub1… · via waggle
The original author's words
Buzz still places Waggle's avatar and identity on the message because the enclosing channel event is signed by Waggle. No body format can repair that mismatch.
Requested capability
Provide a native, moderation-safe representation for a verified foreign-signed event in a channel. A possible shape is a channel post containing the complete source wire event plus an explicit quote/repost relation, with the client and relay enforcing:
- verify the embedded event's id and signature;
- render the embedded signer’s kind:0 name/avatar/npub as the content author;
- visibly retain the admitting bridge/community as provenance, not as author;
- preserve normal community admission and moderation controls;
- make blocking and inspection distinguish the original signer from the admitting bridge;
- refuse malformed, unsigned, or signer-mismatched embedded events.
This does not ask Buzz to trust arbitrary attribution strings or let a bridge impersonate another key. The foreign identity is accepted only because its complete signed event verifies.
Why a tag alone is insufficient
Waggle can attach p/q provenance tags today, which is useful for machines, but the author chrome still follows the outer kind:9 signer. The requested feature is specifically native author-layer rendering and moderation of a verified inner event.
Reference design and limitation analysis: https://github.com/JAFairweather/waggle/blob/main/docs/SPEC_EXTERNAL.md#33-preserving-the-external-authors-identity
Problem
A bridge can verify and carry a complete event signed by an outside Nostr identity, but a Buzz channel currently accepts and renders the bridge's new kind:9 event. The UI therefore shows the bridge's name and avatar as the author, while the original signer can appear only in body text or custom tags.
That is cryptographically honest only at the transport layer and visually misleading at the author layer. A user who blocks, inspects, or attributes the visible author is acting on the bridge identity rather than the person who signed the source event.
Concrete use case
Waggle ingests an allowlisted public kind:1 or an admitted external participant event, verifies the original signature, and presents it inside a Buzz community. Its current best-effort rendering is:
Buzz still places Waggle's avatar and identity on the message because the enclosing channel event is signed by Waggle. No body format can repair that mismatch.
Requested capability
Provide a native, moderation-safe representation for a verified foreign-signed event in a channel. A possible shape is a channel post containing the complete source wire event plus an explicit quote/repost relation, with the client and relay enforcing:
This does not ask Buzz to trust arbitrary attribution strings or let a bridge impersonate another key. The foreign identity is accepted only because its complete signed event verifies.
Why a tag alone is insufficient
Waggle can attach
p/qprovenance tags today, which is useful for machines, but the author chrome still follows the outer kind:9 signer. The requested feature is specifically native author-layer rendering and moderation of a verified inner event.Reference design and limitation analysis: https://github.com/JAFairweather/waggle/blob/main/docs/SPEC_EXTERNAL.md#33-preserving-the-external-authors-identity