While this is definitely needed, I have my doubts about cramping everything into one kind. Are we going to make that table huge?

For example, nostr:npub1gm7tuvr9atc6u7q3gevjfeyfyvmrlul4y67k7u7hcxztz67ceexs078rf6 wants to position himself as a reproduceable attestation service provider. He's drafted an event for this response which would be too complicated for inclusion here.

Same for WoT, it is a contentious topic and I'm not even sure what 0-100 means. The response would likely require more data than an integer. nostr:npub176p7sup477k5738qhxx0hk2n0cty2k5je5uvalzvkvwmw4tltmeqw7vgup

Something like the DVM NIP that uses sub-kinds might be more useful.

Reply to this note

Please Login to reply.

Discussion

I agree. We don't need to put everything on 30382.

What we do need is to specify what the "service" is calculating so that the user can chose which provider of that calculation they trust and clients can know what the value means.

There will be some differences between providers, but the goal and the final result spec (type, range, tags, etc) should be just one.

Hopefully this NIP enables that multiple provider specification to come together.

> final result spec (type, range, tags, etc) should be just one

Did I understand correctly - you want to include type, range, tags etc for each service into this NIP?

In the early days, yes. As it grows we can break it off.

Right now we just need to start the work of specifying stuff.