NIP-92 and Blossom: how to handle different URLs in content vs imeta url tag?

[snarfed]

Hi all! I'm looking at how to handle Blossom images and video in notes. My understanding of NIP-92 is that the image or video URL in content needs to be the same URL as in the imeta url tag. However, I'm seeing clients like Snort (cc @v0l; thank you for Snort!) use Blossom and sometimes create notes with different URLs in content vs imeta, where one URL redirects to the other. Example below.

Blossom and NIP-B7's content addressing scheme seems to implicitly extend NIP-92 to say that any URLs that end in the same 64-char hex hash, excluding file extension, should be interpreted as the same. Is that right? If so, should we update NIP-92 to say so?

Thanks in advance!

---

Example event, now deleted so you may not be able to fetch it:

{
  "id": "eb85fb1a59dc9e6aee5c1a1f93bd833b96a3f52a15bf4a2192d4766ab8adbfd9",
  "pubkey": "86062523fd96df9a06132675a446455448517e840a624798030eb70a25e1bd26",
  "content": "https://npub1scrz2glajm0e5psnye66g3j923y9zl5ypf3y0xqrp6ms5f0ph5nqv9dcpn.blossom.band/b948506e1c71ffa70185795f3d7949bf3c9ad12b7bcf69842b8e9996fb8316ac.jpg",
  "kind": 1,
  "created_at": 1763156128,
  "tags": [
    [
      "imeta",
      "url https://image.nostr.build/b948506e1c71ffa70185795f3d7949bf3c9ad12b7bcf69842b8e9996fb8316ac.jpg",
      "m image/jpeg",
      "x b948506e1c71ffa70185795f3d7949bf3c9ad12b7bcf69842b8e9996fb8316ac",
      "ox b948506e1c71ffa70185795f3d7949bf3c9ad12b7bcf69842b8e9996fb8316ac",
      "size 547251",
      "dim 2000x1500",
      "blurhash LQFYy1%2Ndx]~W%3SgtRxt%Mjroe",
      "thumb https://image.nostr.build/thumb/b948506e1c71ffa70185795f3d7949bf3c9ad12b7bcf69842b8e9996fb8316ac.jpg"
    ],
    [
      "client",
      "Phoenix",
      "31990:84de35e2584d2b144aae823c9ed0b0f3deda09648530b93d1a2a146d1dea9864:app-profile"
    ]
  ],
  "sig": "d8c87c46dab1d77d53a6d5062a9cba18798debccf6a803a62b76223aadb99509782a8a2349395f47196d1e764e97f054f4673ba0c408ff63d33935c1c628ef24",
  "relays": [""]
}

[v0l]

Seems like a Snort bug, it wasnt supposed to work like that, even the snort client itself expects the URL to match