Discussion
What is the place nip? Also, nostr:nprofile1qqs83nn04fezvsu89p8xg7axjwye2u67errat3dx2um725fs7qnrqlgpzamhxue69uhhxetpwf3kstnwdaejuar0v3shjtc3uszjr is this attestation spec compatible with the one we discussed for apps? To me it looks to specific.
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 nostr:nprofile1qqsvfa085adgecmg84ffelcxx6zrn3ffu5jrc6cjtwng0zge3ptv43cpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0wfjkccte9ec8y6tdv9kzumn9wshszyrhwden5te0dehhxarj9ekk7mf0eglgxk ?
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.
Yeah, we could. We actually started there but concluded we needed something less open to interpretation, particularly as reactions are used for all sorts.
An Attestation should carry much more weight - like a notorisation.
Users and clients would need to weigh Attestations in accordance to their social graph and preferences using WoT. e.g. people may highly weight Proof of Place Attestations from BTC Map, but not music recommendations.
More context here:
And here:
https://docs.google.com/presentation/d/11RcCs25ziANe_THKTyvrDEgwhY6lqByqdtcYr9efKtY/edit?usp=sharing
I am on board with the choice not to use reactions, hzrd convinced me of that this fall. But what you linked doesn't address the problem of multiple oracles making an initial, identical declaration.
I'd btc map says person x owns place y, and some govt also says person x owns place y, how do you link attestations? Does a user have to sign 2 attestations that both pronouncements are true?
That's for clients to interpret with WoT.
The user doesn't sign anything.
In Proof of Place:
- The owner Asserts a Place
- Other entities then Attest to that being valid/invalid
- Users weigh those attestations how they like.
If I don't trust the government then I'll not weight their attestations on given kind types.
More directly in a swer to your question, the Attestations are linked by the Assertion Event (in this case a Place event).
Right, but there can be identical assertions made to the same place and I could trust both. If I'm at a location and attest to the veracity of a neighboring assertion are you saying that because they assertions are the same that two attestations (one for each assertion) should be signed.
Assertions can't be identical unless they are from the same key.
Attestations can also be attested to. 🙃
Ok not identical but 2 entities can assert the same thing (Is there a spec for the actual assertion events?)
What I'm trying to ask is if btc map and county gov say person x runs business as location y. I am there. I trust both entities. I click "verify" which would sign an assertion. Where would that attestation be linked to? Assertion a or b or both?
The spec is agnostic on the Assertion Event - it can literally be any other event of any kind. It's covered on the nostrhub link above.
The Assertion Event, to be useful, should be domain specific and as detailed as necessary such that a valid/invalid assesment can be made via an Attestation.
In your case directly above, you're not signing the assertion - that is the place event itself published by the merchant.
You would either be attesting to it directly, or attesting to the other attestations as you trust them implicitly. Both are fine.
I feel like we are talking past each other.
Are you saying that 2 entities cannot assert the same thing? Because that does not mirror reality. My understanding of the attestation spec above is that an attestation only can apply to 1 assertion, but if there are 2 assertions that are the same, how would that be handled, considering that a user attesting to the fact that the sky is blue isn't relevant whether God or the devil made that assertion.
Yeah, entities can make the same broad Assertion - the sky is blue.
I guess we could look at the hash of a subset of tags of a well-specified Assertion event to determine if it was the same?
Attestations basically amplify/dampen the views of a given entity as there is no base 'truth' - that is emergent and subjective.
The place example is a special case in that it is the *combination* of Place event content *and* npub we are interested in as we are seeking to link cyberspace ownership (nsec/npub) with meatspace ownership (physical address).
You should join the #wotathon calls by nostr:nprofile1qy88wumn8ghj7mn0wvhxcmmv9uq36amnwvaz7tmwdaehgu3wvf5hgcm0d9hx2u3wwdhkx6tpdshsqg97006aup5vrkzza5620sns2plvjs84afgkw88aqc4ft6wsjssdpgkmpnlv!
Is there a calendar of them?
My related spec on ‘acceptance’ - based on input and collaboration from nostr:npub1cn670f663n3ks02jnnlsvd5y88zjnefy8343ykaxs7y3nzzketrsrjwt8a and the #Wotathon folks
I distinguish between assertion, attestation and delegation
https://github.com/trbouma/safebox/blob/dev-change/docs/ACCEPTANCE-MODEL.md
I like your model.
Reading it makes me think the only think that is missing from the attestation spec is optional tags to "proof".
For example, when I assert a build is reproducible, i should also attest to my own assertion being true and link to the build pipelines outputs showing that.
Also makes me think there might be some convention that should (not required) be applied to assertions that they should be phrased as null hypotheseses.
Yeah, it's on my to-do for Attestations. Proof/evidence to support the validity/invalidity claim.
Lit. Ok I think I have enough information to get Fran what he needs to implement reproducible builds via assertions and attestations.
Step 0 for that is to just piggy back on izzyondroid scans
Step 1 do it via loom so it can be done on demand for those who don't want to farm out their trust.
Step 2 would be to add those in as attestations to the initial assertion
Step 3 would be figure out how to apply wot to who's assertions you care about in that specific context.
Step 4 drink coffee and take a walk
Thx. It’s little more than a skeleton, but I think the basic structure is right. As I implement, I may need more stuff, but at this time I don’t know if it will be an app specific requirement, or something that needs to go in the model.
As for the model itself, I did my best to just soft-fork nostr:npub1cn670f663n3ks02jnnlsvd5y88zjnefy8343ykaxs7y3nzzketrsrjwt8a ‘s NIP. The big discussion was how to differentiate between an assertion, attestation and delegation and whether these needed to be different events. My conclusion these could be differentiated in the same event kind whether you were asserting content, an event, or a npub. That is now captured in the NIP and you can call these things whatever you want, because it’s the structure that differentiates them, not how you name them.
🐢🐢🐢🐢🐢🐢🐢🐢🐢🐢
🛰️Off-Grid Relayed via satellite🛰️
--------------------------------
↩️ REPLY to nostr:npub16ux4qzg4qjue95vr3q327fzata4n594c9kgh4jmeyn80v8k54nhqg6lra7
Re: nostr:note153jyt20ka6stptjzaafzy70hjpv8pta6wsc5jczzkt26nezwd0qs3t4mrj
nostr:npub1cn670f663n3ks02jnnlsvd5y88zjnefy8343ykaxs7y3nzzketrsrjwt8a said:
Yeah, we could. We actually started there but concluded we needed something less open to interpretation, particularly as reactions are used for all sorts.
An Attestation should carry much more weight - like a notorisation.
Users and clients would need to weigh Attestations in accordance to their social graph and preferences using WoT. e.g. people may highly weight Proof of Place Attestations from BTC Map, but not music recommendations.
More context here:
And here:
https://docs.google.com/presentation/d/11RcCs25ziANe_THKTyvrDEgwhY6lqByqdtcYr9efKtY/edit?usp=sharing
--------------------------------
📡 BitSatRelay - Terminal-HQ
It's buried in a NIP repo PR. Let me publish it on NostrHub so it's more discoverable.
BRB ...