On too many relays, people are putting npub keys into the 'pubkey' field of nip-11, such as wss://relay.mostr.pub/, wss://relay.current.fyi/, wss://nostr.fmt.wiz.biz/, wss://nostr.mom/ (some of those are strfry, I filed a bug there too).
To Reproduce
Steps to reproduce the behavior:
Fetch the NIP-11 for a relay and discover someone put an npub formatted key in the pubkey field. Clients that have strong typing fail to deserialize the NIP-11 structure.
Expected behavior
A hex public key
Screenshots
(see line at 2023-07-04T19:09:07.332724Z
System (please complete the following information):
OS: unknown
Platform: unknown
Version: 1.18.0
Logs
n/a
Additional context
NIP-11 states:
An administrative contact may be listed with a pubkey, in the same format as Nostr events (32-byte hex for a secp256k1 public key)
Could you (1) validate this and error or warn, or (2) make the comments/documentation very clear on this point so people don't make this mistake?
The gossip client is using strict typing and fails to deserialize these NIP-11 JSON objects, meaning the client is not providing any interesting relay information to the user, and gossip is presuming these clients do not support NIP-11 and not utilizing them fully.
Of course I could accept npub, but I fall into the camp of people who believe we should hold the line and defend the standards lest they proliferate into too many defacto variants.
cameri
commented
5 months ago
Describe the bug
On too many relays, people are putting npub keys into the 'pubkey' field of nip-11, such as wss://relay.mostr.pub/, wss://relay.current.fyi/, wss://nostr.fmt.wiz.biz/, wss://nostr.mom/ (some of those are strfry, I filed a bug there too).
To Reproduce
Steps to reproduce the behavior:
Fetch the NIP-11 for a relay and discover someone put an npub formatted key in the pubkey field. Clients that have strong typing fail to deserialize the NIP-11 structure.
Expected behavior
A hex public key
Screenshots
(see line at 2023-07-04T19:09:07.332724Z
System (please complete the following information):
Logs n/a
Additional context
NIP-11 states:
Could you (1) validate this and error or warn, or (2) make the comments/documentation very clear on this point so people don't make this mistake?
The gossip client is using strict typing and fails to deserialize these NIP-11 JSON objects, meaning the client is not providing any interesting relay information to the user, and gossip is presuming these clients do not support NIP-11 and not utilizing them fully.
Of course I could accept npub, but I fall into the camp of people who believe we should hold the line and defend the standards lest they proliferate into too many defacto variants.