What is the place nip? Also, @Zapstore is this attestation spec compatible with the one we discussed for apps? To me it looks to specific.

If you want to direct me to where those discussions are happening I would gladly contribute.

Kind 31871 looks simple enough? What I ideally want is more of a "vouch" and not sure how the s field and others would look like. Suggestions @Nathan Day ?

It's buried in a NIP repo PR. Let me publish it on NostrHub so it's more discoverable. BRB ...

Yeah, we discussed this a while back. There was some other project doing binary attestations too, but I can't recall it. At its core, an Attestation Event is a simple valid/invalid on the referenced assertion event (e.g. an app release). Zapstore and others could interpret this as a simple vouch. Another way is to actually publish some kind of specific app vouch event with more detail in it that some expert can publish (perhaps even zapstore) that other experts can attest to. I think the later is more robust, the former simpler though. Both can be used in parallel I guess.

Looking at this definition, how is it any different than nip25 reactions? You could just interpret ✅☑️✔️💯 as positive attestations and ✖️❌❎⛔🚫 as negative ones. I am think about this in terms of two use cases: Attesting that a location accepts bitcoin AND An application has a reproducible build. So I guess what you're saying is that there should be a separate kind(s) for assertions or declarations, which would then be attested to separately? In the case of a location accepting bitcoin, the initial assertion could be represented by a bitcoin badge and the asserts could be like a number the same way notifications on a phone work, but it could be negative if more people asset that something is false than true. The only issue I guess I have is what if multiple people make the same declaration? Let's say multiple people create workflows to check the reproducibility of some application. Then wouldnt the client have to basically determine which one to attach the attestations to? Because you wouldn't just want to force the attestations just to go to whichever assertion is first, because it means different things for the app owner to declare that their build is reproducible vs another entity vs some random not technical person or bot. This is really only relevant to the assertion discussion because assertions only apply to other events.