{"type":"rich","version":"1.0","title":"shocknet_justin wrote","author_name":"shocknet_justin (npub1xv…e64sa)","author_url":"https://nostr.now/npub1xvtwx6tduaxnn9v3y7uasskl277achgu0tu2qncmc7hdsz6y2zyqce64sa","provider_name":"njump","provider_url":"https://nostr.now","html":"The formatting here is a little hard to grasp fully, if this could be a proposed diff on the github PR that would be ideal for review\n\nWhat I do grasp I think I agree with, the NIP as currently constructed is mostly a registry... I don't think its a good idea to hard code a bunch of possible metric tags into the NIP itself... Mani's arbitrary string give it more forward-utility without future changes. \n\nAn example expansion in my case would be, if I want my paid services to signal that a user paid for something, or was invited/sponsored by another user, I might arbitrarily want to use NIP-85 to publish a paid_user attestation from that service so other services might whitelist them as a non-bot without their yet having a broader WoT in the form of followers etc.\n\n(open to suggestions for a paid_user/invitation NIP or NIP-85 adaptation to bootstrap WoT)\n\nI'm not sure I see the value in the W tag, seems superfluous with the kind and the fact I'd be looking for a specific tag anyway, but perhaps i'm missing something. \n\nI also think the categories themselves being part of the NIP is the same flaw as the registry, unless they're just meant as examples for a top/bottom leveling tags. This may be where formatting of the site as opposed to git makes things unclear. Basically if I were to make a diff the NIP would be half the size or less.\n\nUnfortunately can't make the call tomorrow but look forward to discussing further and reviewing a diff.\n"}