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.
