NIP-52 Badges (prev Issued Claims).md

[neilck]

Submission of initial draft. Actively seeking review and comments.

[fiatjaf]

I've read everything but didn't understand what is a claim and how it can be issued.

[Giszmo]

This nip is much too long if you ask me. I stopped reading half way through as at that point it was still not getting to the point.

$ wc -w ??.md | sort -n
   71 06.md
   83 36.md
  114 03.md
  114 15.md
  131 14.md
  145 07.md
  206 08.md
  227 04.md
  269 25.md
  292 16.md
  317 40.md
  322 33.md
  341 26.md
  370 09.md
  410 02.md
  416 22.md
  436 19.md
  443 12.md
  479 11.md
  508 10.md
  515 13.md
  572 20.md
  580 42.md
  657 28.md
  850 05.md
 1197 01.md
 1426 52.md
11491 total

Please get it down to 50% the words you used.

Please add an introduction to tell what this is about in simple terms.

[neilck]

Thanks for the comments. Major revisions coming.

[mikedilger]

Every nostr event is digitally signed and can be thought of as a claim: the pubkey claims the contents. But such claims in English are not meant for machine use. A claim as formulated by this NIP is a machine-parsable statement about things outside of nostr (domain specific), such as "UC Davis claims Mike Dilger graduated from UCD with a Masters of Science in Computer Science in 1995".

Since the claims are about concepts outside of nostr, how would one prevent collisions in the space? Would people just use long claims and hope that provides uniqueness? We can't be a registry, we are decentralized.

It's a great concept, but I have trouble attaching it to a real world problem that I want to solve. Partly because of a chicken-and-egg situation. UC Davis doesn't have a nostr public key. I don't really care if people know about my MS degree. I can prove my twitter identity in other ways already. Etc. This would then benefit from a motivating example that can't be easily solved through other means.

[neilck]

I have made some revisions based on earlier comments, but haven't processed mikedilger's feedback yet, so more to come.

[neilck]

Every nostr event is digitally signed and can be thought of as a claim: the pubkey claims the contents. But such claims in English are not meant for machine use. A claim as formulated by this NIP is a machine-parsable statement about things outside of nostr (domain specific), such as "UC Davis claims Mike Dilger graduated from UCD with a Masters of Science in Computer Science in 1995".

Since the claims are about concepts outside of nostr, how would one prevent collisions in the space? Would people just use long claims and hope that provides uniqueness? We can't be a registry, we are decentralized.

It's a great concept, but I have trouble attaching it to a real world problem that I want to solve. Partly because of a chicken-and-egg situation. UC Davis doesn't have a nostr public key. I don't really care if people know about my MS degree. I can prove my twitter identity in other ways already. Etc. This would then benefit from a motivating example that can't be easily solved through other means.

Based on your feedback, I wrote this NIP to focus purely on Badges, one of the use cases identified. A problem not easily solved by any other means is allowing users to carry their reputation (badge achievements, membership statistics) from one app to another.

[fiatjaf]

I like this idea more now. I just think the NIP is very bloated. There are a thousand zillion fields on these JSON objects.

I think we could start simple, with a single tag denoting the name of the badge.

Issuer is implied, id is implied (event id), remove this refresh and expiration stuff, message could be an optional string inside content. "score", "followers" and so on are not applicable or can be added later as tags if necessary. These are application-specific things.

I think even the image could be implied or resolved based on a set of hardcoded rules instead of a URL. URLs could change while badges are forever.

For example, the image URL of a badge could be the badge name written on top of the kind:0 profile URL of the issuer. So if an entity (not a person) issues a badge that will be clear from the image.

For very important badges that many people have (i.e. achievements from a popular videogame), clients can add hardcoded custom designs. Or fetch nicer badges from third-party providers that do these designs.

OK, I understand I've basically rewritten the NIP and my proposal is not the same as yours, but what can I do?

[neilck]

I like this idea more now. I just think the NIP is very bloated. There are a thousand zillion fields on these JSON objects.

The fields come from a comparison of user fields available when making OAuth requests to Twitter, Instgram, LinkedIn, Discord, etc. However, not all Nostro apps care about this, so I think I will move them out of the NIP, keep the adding of additional fields as optional, and move them somewhere else.

I think we could start simple, with a single tag denoting the name of the badge. Issuer is implied, id is implied (event id), remove this refresh and expiration stuff, message could be an optional string inside content. "score", "followers" and so on are not applicable or can be added later as tags if necessary. These are application-specific things.

Yes, I agree, other than expiry_date. At some point, client / relay owners will likely need to charge some type of fee for their services. Having an expiry_date associated with a membership badge, enables a client to set this based on a user's paid subscription, and then relays using the membership badge to determine if the pubkey is not subject to rate limits. I've only looked at Nostream, but see there is an existing limits.event.whitelists.pubkeys configuration setting.

I think even the image could be implied or resolved based on a set of hardcoded rules instead of a URL. URLs could change while badges are forever. For example, the image URL of a badge could be the badge name written on top of the kind:0 profile URL of the issuer. So if an entity (not a person) issues a badge that will be clear from the image.

I agree that badge image urls probably shouldn't be hardcoded in the event, as it makes them fragile, and some automated rule, based on some data the app owner can update should be used. Kind 0: metadata is the obvious choice. Kind 0's content string may become bloated in the future if a lot of other NIPs also want to store things there (NIP-05, NIP-53, etc.), but I think this potential issue is mitigated by using different pubkeys used for different purposes.

For very important badges that many people have (i.e. achievements from a popular videogame), clients can add hardcoded custom designs. Or fetch nicer badges from third-party providers that do these designs.

Nice.

OK, I understand I've basically rewritten the NIP and my proposal is not the same as yours, but what can I do?

I haven't implemented anything yet, so now is the time to figure out what makes sense.

[Giszmo]

This is one of those nips where I feel like rule one for acceptance might be quite a hurdle:

All these details? How should Astral show badges in all these variants? Can you convince Damus to implement the whole nip? Do you have your own client that implements all this?

[neilck]

This is one of those nips where I feel like rule one for acceptance might be quite a hurdle:

All these details? How should Astral show badges in all these variants? Can you convince Damus to implement the whole nip? Do you have your own client that implements all this?

Getting the comments and feedback here has been essential for the early stages of this NIP, and has been wonderful. It's been simplified further since your comment.

I can only control myself, and it's up to others to determine if they find it useful enough to implement. I plan to implement this as a prototype either in my own client or as a branch of another client, which will likely result in more changes to the NIP while it's still in draft.

[neilck]

Superseded by NIP-58