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