Nostr Rating Event Uses Inconsistent Pubkey Format in `d` Tag

[grunch]

Severity: Medium / Potential Bug
File: docs/SEPARATE_EVENT_KINDS_SPEC.md (lines 298-315)
Category: Protocol Consistency / Interoperability

Description

The Rating Event (kind 38384) specification shows a bech32-encoded npub in the d tag:

{
  "kind": 38384,
  "tags": [
    ["d", "npub1abc123..."]
  ]
}

However, Nostr events internally use hex-encoded pubkeys. Using bech32 (npub) format in the d tag creates inconsistencies with filtering and replacement logic.

Why This Matters

1. Parameterized Replaceable Events

Rating events (kind 38384) are likely parameterized replaceable events in Nostr (NIP-33). The d tag is used as the unique identifier for replacement. If some clients or relays normalize the pubkey to hex while others use bech32, you get:

• Duplicate entries: d: "npub1abc..." and d: "abc123..." (hex) are treated as different events.
• Failed replacements: A new rating won't replace the old one if the d tag format differs.

2. Relay Filtering

When querying relays with filters like {"#d": ["<pubkey>"]}, the format must match exactly. Mixing formats means some queries will miss results.

3. Cross-Client Compatibility

Different Nostr clients handle pubkey encoding differently. Specifying a clear canonical format prevents interoperability issues.

Suggested Fix

Option A: Use hex pubkey in d tag (Recommended)

This aligns with how Nostr events are stored and processed internally:

{
  "kind": 38384,
  "tags": [
    ["d", "a1b2c3d4e5f6..."]  // hex-encoded pubkey
  ]
}

Option B: Explicitly specify bech32 and convert on ingest

If bech32 is preferred for human readability, the spec should:

1. Explicitly state that d tags use bech32 npub format.
2. Require all implementations to convert hex pubkeys to bech32 before setting the d tag.
3. Require relay queries to use bech32 format for #d filters.

Action Required

1. Decide on the canonical format (hex recommended).
2. Update the spec in docs/SEPARATE_EVENT_KINDS_SPEC.md.
3. Verify that the implementation in source code matches the chosen format.
4. Ensure all places that create, query, or filter Rating Events use the same format.