Nostr Web Client

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!

Tim Bouma 2w ago

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

Reply to this note

Please Login to reply.

Discussion

AU9913 2w ago 💬 1

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.

AU9913 2w ago

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.

Nathan Day 2w ago

Yeah, it's on my to-do for Attestations. Proof/evidence to support the validity/invalidity claim.

AU9913 2w ago

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

Tim Bouma 1w ago

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.