Other clients would show the checkmark as long as the fake accounts are associated with some domain name. Users need to manually verify that the domain is the intended one. > But yeah I never understood the get a nip-5 at randoNostrappDomain.com services… as if that meant something. It's not *supposed* to mean anything. Imagine meeting someone in person and wanting to get them to follow you on Nostr. You might not always carry an electronic device, you might not always have a piece of paper with your whole public key and you might not remember it by hart. Giving them something mnemonic, for the sole purpose of finding you, is easier. Multiple addresses are important for several reasons. For example, some groups or institutions might give a NIP-05 address to member so that they can be found on Nostr by their name (like school email addresses, although it may not work well at that size). A person can belong to two groups or institutions and still wish to have only one account.
It's something I have suggested before, but didn't get traction. I actually still think it should be implemented. JSONs must stay compliant. Other than that, I don't care much how the implementation happens, as long as it does. One issue one might raise is performance. However, this is only a concern if clients load and verify NIP-05 identities for every account every time it's displayed. And the only real reason for doing so is the checkmark, which shouldn't be there anyways. I think "verification" should happen, for all domains, when the user actually checks the info page of an account, which wouldn't actually require much.
That's not even the only issue. What I was referring to is that anyone can pay a DNS registrar and have their very own domain name. And scammers create website with their own domain names very often, so the fact that they can isn't just hypothetical. If someone creates a domain name and a NIP-05 identity with that domain name, clients will show a checkmark. Of course users can manually check that the domain name is a trusted one, but a checkmark conveys that the user is "verified", while the only thing that's been verified is that the owner of the account controls a domain name, which tells us nothing about trustworthiness.
It can make sense to trust an account based on its NIP-05 identity if you know the domain. But the checkmark is shown besides the name of just any account that is associated with any domain name, trustworthy or not. Any scammer or spammer can trivially create a domain name and they are often very willing to pay. So the mere presence of a NIP-05 identity proves nothing. A checkmark doesn't signal that the user needs to manually verify that the domain is one they trust. The message it conveys is that the account is to be trusted. And, again, the presence of a random domain is no evidence for this. A solution could be to let users specify a pool of domain names that are to be trusted and have the checkmark for those domains. The issue is that NIP-05 only allow each user to have one identity. So if there are two domains that could verify me, for instance because I belong to two organizations (many people do), I have to pick one and only one. The people who don't know the organization that I picked, but do trust the other, won't see a checkmark, even though they logically should. Even for its intended purpose, NIP-05 should allow multiple identifiers. But verification is not its intended purpose.
I understand, and Markdown is easy to parse mentally, but it may create issues if users expect it to be a standard.
Really not good. I thought you might just have been using Markdown syntax because it's familiar, but Nostr clients aren't supposed to support it in kind 1 events.
You're like the clown of Nostr.
Does your client support Markdown in kind 1 notes? It shouldn't, it's highly non-standard.
I speak Italian.
Actual incitement is illegal, I think about everywhere. What makes violence kinda more likely is subjective and effectively the same as "whatever I disagree with".
Welcome to Aspie96 spacestr profile!
About Me
Interests
- No interests listed.