Attestations can be made for any Subject Event of any Kind. Proof of Place Attestations by @BTC Map? No problem. Proof of (software) Release on @Zapstore by your favourite dev? Attestations gotchu. The options are only limited by the number of Kinds, which are limitless.

Interesting! @Leo Wandersleb thoughts?

Well written. And actual web of trust stuff. Curious how you see the UX around this without overloading users with too much extra stuff they "have" to do.

And guess what, we can now define what Nostr itself is by Attesting to the Validity/Invalidity of Kind 30817 notes. We each get to signal what Nostr is to us. 🤯 @Alex Gleason 👀

Still skeptical on things like that. I don't know if attesting is needed is you already know I'm **using** (or interacting in other ways with) specific events → Specs in this case. We're starting with specifying the Specs we use in our App Releases and App events, for example. What is my incentive to then also attest for them?

Nice! Thanks for submitting to NostrHub!

Who is using it for what? @btc_remnant @dannybuntu is this compatible with our verifications/attestations? It sounds like their "attestations" are our "endorsements"?

What are endorsements? Do you have a NIP or some ref docs I can look at. Attestations are kind agnostic.

@Tim Bouma will be using it for #safebox. @arkinox for @Fanfares. @BTC Map for Proof of Place. I think it works really well for @Zapstore too. Hell, we can even define what Nostr is itself by using the NIP NIP @Alex Gleason has created.

I smell a PCR return

What’s PCR?

@AInostrOFFLINE what’s Plebchain Radio 🤣

Oh that PCR!

Sorry I was traveling during your show. Great work. 🫡

Ha! I was operating under the wrong model context. Was thinking biological.

polymerase chain reaction

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.

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. 🤔

@btc_remnant could answer that.

> 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.

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:

btc_remnant

> An Attestation event could optionally reference your (Release) Verification event in this way

Yeah, I guess we could use part of the NIP...

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:

GitLab

docs/verifications.md · 0b3387bfdfee889daebf604822a935d212d539f8 · WalletScrutiny / walletScrutiny · GitLab

The WS website and test scripts

Attestations allow the signalling of the validity of any other event. Now we have the NIP NIP by @Alex Gleason clients can effectively ACK/NAK those on a per NIP basis. Other devs/orgs can attest to the truthfulness/validity of those claims, along the same lines @npub1j9kt...uswx does. Attestations all the way down. A WoT for notes.

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.

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 @David 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”.

GitHub

GitHub - Pretty-Good-Freedom-Tech/graperank-nodejs

Contribute to Pretty-Good-Freedom-Tech/graperank-nodejs development by creating an account on GitHub.

@Nathan Day, 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'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!

Attestations fix this.

Nostr-based access control • Clip by @nathan_day • Listen on Fountain

Clipped from Free Cities Podcast • 136 - Ben Gunn: Three Rules For Life - Part 1 Privacy, Anonymity, NOSTR, Bitcoin, Digital Identity, Governanc...

Right, @Tim Bouma?

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.

Needs to be addressable and replaceable to support revocations. I did have revocations as a separate event to begin with, but was steered this way to keep it simpler and have a single event representing the current state.

Ah! Of course! What was I thinking? Thanks!

It would be something like this:

Nice.

Love seeing this! @Nathan Day was great listening to you on PCR. Eager to implement on Zapstore

Hey Nathan! Do we have an "oficial" nip for this Attestations spec?

Not in the merged sense. Community NIPs are the repo now. Maybe it gets merged one day, but I think the protocol can be more emergent now.