ok, i looked into it.

i remember discussing this issue in a general way about both nip-42 and nip-98 and how the strict requirement to name the server URL was restrictive in other ways. i forget what my final thought on it was though.

i disagree that there is anything more required than making that field optional to prevent this issue.

the other point i'd make is, yeah, if you don't have a pecuniary relation with the blossom server, there's no incentive to not take privileged data and abuse it. a paid service doing this would be completely insane. buttt

like all the nostr auth insanity that is finally starting to dissolve thanks to moltbook, people are starting to realise that it's quite important to have incentives for providers and users to have a mutually beneficial economic relationship.

also, this "vulnerability" is very narrow. the blossom provider has to use it immediately because there is still a time window of validity that target hosts may not respect.

secondly, how the heck is the blossom provider going to, in that short period of time, determine where else to look?

very overstated vulnerability. not worth complicating the protocol. just make the provision that the blossom provider can require this, and clients, that this be added, the tag, which is present for all others.

in fact, i'm going to revise smesh and orly to require this, despite the fact that i half expect you protocol engineer activists to contradict this solution with piling on another big complex shit to it.