Who is using it for what? nostr:npub1qw6sxmwrmwpxqsc8cxty62ujvst6j8pmz8hhtwnv54gpn6dh5c4qms4882 nostr:npub1r709glp0xx2zvgac45wswufjst5xgr7cear5a8me7x9vazhjzmksp2sf7d is this compatible with our verifications/attestations? It sounds like their "attestations" are our "endorsements"?
Discussion
What are endorsements? Do you have a NIP or some ref docs I can look at.
Attestations are kind agnostic.
Our "Endorsements" are so much simpler. It's just this event type, but we haven't implemented them yet. We're still thinking on the best way to do it:
Yep, equivalent. The simplest form of an Attestation is v simple too. All other events in the NIP are optional, as are most of the tags in the base kind.
Would be cool to have you using it also! You would simply use your verification event (30301) as the Subject Event.
My primary interest was to keep this super simple and generic so I can use to attest records that could be relied on as verifiable credentials. I’m a few weeks out on the implementation as I am getting the basic record transmission stuff working (offers, grants, presentations). I’ll then graft on the attestations as per the NIP.
I'll give a look at it in 2 weeks, and we (the team) will talk about it first, but I think we could end up using it. Thanks a lot Nathan!
Hey Nathan,
Is this NIP more or less stable now? Should we expect to have changes to it yet?
Another question. In the event 31871, what's the "d" tag for?
Pretty stable I think, especially the basics. Tweaks expected as clients implement and we learn what we got wrong.
It would be something like this:
Nice.
Love seeing this!
nostr:nprofile1qyghwumn8ghj7mn0wd68ytnhd9hx2tcprpmhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0qqsvfa085adgecmg84ffelcxx6zrn3ffu5jrc6cjtwng0zge3ptv43c5xzlap was great listening to you on PCR.
Eager to implement on Zapstore
nostr:nprofile1qqsw3mfhnrr0l6ll5zzsrtpeufckv2lazc8k3ru5c3wkjtv8vlwngkspz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszythwden5te0dehhxarj9emkjmn99uq3vamnwvaz7tmwdaehgun9d35hgetn9ehhyee0k52r6j for nostr:nprofile1qqsd0kqsnmjrv47wvpt2mfr9xqrthdjp7v09p6zjgd5pcfey2puprmqppemhxue69uhkummn9ekx7mp0qythwumn8ghj7urpw3jhytnwdaehgu339e3k7mf0qyfhwumn8ghj7ur4wfcxcetsv9njuetn9ucut0gy.
nostr:nprofile1qqsra2ey033mkdwl5w8q0jss9ak69zafh82xsuvhwsaauw3trkq2amgpz9mhxue69uhkummnw3ezuamfdejj7qgcwaehxw309anxjmr5v4ezumn0wd68ytnhd9hx2tck28qzu for Proof of Place.
I think it works really well for nostr:nprofile1qqs83nn04fezvsu89p8xg7axjwye2u67errat3dx2um725fs7qnrqlgzqtdq0 too.
Hell, we can even define what Nostr is itself by using the NIP NIP nostr:nprofile1qqsqgc0uhmxycvm5gwvn944c7yfxnnxm0nyh8tt62zhrvtd3xkj8fhgprdmhxue69uhkwmr9v9ek7mnpw3hhytnyv4mz7un9d3shjqghwaehxw309aex2mrp0yh8qunfd4skctnwv46z7qgewaehxw309aex2mrp0yh8xmn0wf6zuum0vd5kzmp033tada has created.
I smell a PCR return
What’s PCR?
We’ve been talking about trust attestations for almost two years.
After many panel discussions and Nostr threads, a “few of us” came to the realization that, while having a NIP for “explicit trust attestation” would be great, getting clients to implement and end users to author “explicit attentions” reliably … would be a big ask … with little actual reward in the end.
In order to determine “actual” trustworthiness (of content or users), having an incomplete (low usage) or imprecise (poor usage) collection of “explicit” trust markers will not replace the need for algos to process any number of “implicit” trust markers that are already abundant and available to harvest on Nostr.
This is why nostr:npub1e2vcfcr6yea25e67ryktrtd0a24dsedzwlprj6v45997uhw27p3qtzkq3u and I developed the GrapeRank library … a pluggable, extensible, and configurable algo engine for determining trusted users and content. It can (easily be extended to) ingest any number of content “kinds” (including explicit attestations) to calculate a weighted list of trusted users on any given topic in “your network”.
https://github.com/Pretty-Good-Freedom-Tech/graperank-nodejs
nostr:npub1cn670f663n3ks02jnnlsvd5y88zjnefy8343ykaxs7y3nzzketrsrjwt8a, I’m glad you’re working on explicit trust attestations … but in the end we’re still gonna need algos to extract implied trust from Nostr. Happy to discuss further.
I agree re the algos. Attestation can form part of the raw data that the algos needs to surface and extrapolate from.
Will dive into GrapeRank; looks cool.
Trust is a vector: about what and to what extent. Direction AND magnitude.
Our existing system is a powerful, specific implementation of what the Attestations NIP aims to generalize. Our "verifications" are a highly specialized form of their "attestations." The NIP is not a replacement for our testing infrastructure but a potential protocol for broadcasting our results. Adopting the NIP could significantly increase the reach and interoperability of our findings within the broader Nostr ecosystem, making WalletScrutiny a foundational "Attestor" for app reproducibility.
We use a sophisticated, automated testing infrastructure to perform reproducible build verifications for cryptocurrency wallets, primarily for Android and hardware wallets. The goal is to determine if the publicly available application binary matches the publicly available source code. The results are published as detailed "Review Pages" on our website.
Attestations NIP: This is a new, generic proposal for making, tracking, and revoking truthfulness claims about any event on Nostr. It is not specific to wallets or reproducible builds. As it's a new proposal, it currently has no widespread adoption, but it aims to be a foundational layer for any "web of trust" application, from fact-checking to reputation systems.
Yeah, looks like you are a specialised Attestor.
Would some form of Evidence tag work for your usecase?
An Attestation event could optionally reference your (Release) Verification event in this way.
We refer to the process of arriving at an Attestation state (valid/invalid) as the verification process, but we are silent on what that process is as it's Subject Event - and often Attestor specific - and is down for the WoT to weigh those.
Some form of evidence expectation could optionally be included in the Attestation Request. 🤔
> An Attestation event could optionally reference your (Release) Verification event in this way
Yeah, I guess we could use part of the NIP. Probably not the full one, as I don't see us requesting attestations to other users. Maybe I'm wrong. Also, is this mechanism meant to be implemented by general purpose clients? I mean, I don't expect a lot of clients showing our "verifications" events, so I don't know if any client will show the "request for attestation" to our event kinds.
No, I don't think it'll be in general clients.
Specific clients will show relevent Attestations base on the kind type of the Subject Event.
e.g. nostr:nprofile1qqsra2ey033mkdwl5w8q0jss9ak69zafh82xsuvhwsaauw3trkq2amgpz9mhxue69uhkummnw3ezuamfdejj7qgcwaehxw309anxjmr5v4ezumn0wd68ytnhd9hx2tck28qzu will show Place Attestations.
Attestation marketplaces will emerge as specialist clients.
Yes, it's kind of the same concept. I still have to read it more carefully, but maybe we could implement some parts of the nip, not all of it:
https://primal.net/e/nevent1qqsfl6r8uzvnqsf5v005xt4szss505nhfs9f3xk3waadr2y64u3ssusdxqame