Nostr NIP-05 defamation attacks

At the time of writing NIP-05 offers a way to retreive someone's Nostr public key by performing a GET request to a URL which can be determined by processing their human-readable identifier. As an example if we know that someone's identifier is bob@example.com then performing a request to https://example.com/.well-known/nostr.json?name=bob may return a response such as the one listed below which contains their Nostr public key.

{
  "names": {
    "bob": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"
  }
}

Unfortunately the returned data is not cryptographically signed which means that servers can arbitrarily assign identifiers to Nostr users. This can lead to a class of attacks which I would call "defamation attacks".

One example of such an attack could be creating a server which returns someone's public key under an unflattering identifier such as stinkyperson@example.com. This kind of an attack could of course be achieved through many other means therefore the problem is not just specific to NIP-05 however one consideraration is that this attack is likely to disproportionately affect already marginalized and vulnerable groups.

The same attack could be used to imply someone's existing or past relationship with a specific organisation. Such an organisation could associate someone's well known nickname with an identifier based on a domain controlled by them and therefore imply that a connection exists between the two. As an example this kind of an attack could be problematic for high-status individuals as it could be used to not only discredit them but also to attempt to promote a product or organisation using their standing in the community.

NIP-05 suggests that events with kind 0 should be cross checked when performing lookups to reduce the attack surface. That being said it is likely that not all clients follow this advice. Moreover this doesn't help when a fake past relationship is implied by an attacker.

Reviewing related work such attacks are partially-mitigated in other protocols by requiring cryptographic signatures when returning mappings between human-readable identifiers and public keys. For example SSB Rooms 2.0 specification from Secure Scuttlebutt requires the server to return a valid signature created using a public key pointed to by a given human-readable identifier.