Well written. And actual web of trust stuff.

Curious how you see the UX around this without overloading users with too much extra stuff they "have" to do.

Reply to this note

Please Login to reply.

Discussion

Yes, this will be key.

I've built a Proof of Place prototype that just focuses on Proof of Place Attestors.

I'm working on a general Attestation Marketplace and would love any UX input you may have.

meatspacestr.io

And guess what, we can now define what Nostr itself is by Attesting to the Validity/Invalidity of Kind 30817 notes.

We each get to signal what Nostr is to us. 🤯

nostr:nprofile1qqsqgc0uhmxycvm5gwvn944c7yfxnnxm0nyh8tt62zhrvtd3xkj8fhgprdmhxue69uhkwmr9v9ek7mnpw3hhytnyv4mz7un9d3shjqghwaehxw309aex2mrp0yh8qunfd4skctnwv46z7qgewaehxw309aex2mrp0yh8xmn0wf6zuum0vd5kzmp033tada 👀

Still skeptical on things like that.

I don't know if attesting is needed is you already know I'm **using** (or interacting in other ways with) specific events → Specs in this case.

We're starting with specifying the Specs we use in our App Releases and App events, for example.

What is my incentive to then also attest for them?

Yeah, one is emergent based on observations of given events. An app could harvest that info for sure.

Attestation approach more formal I guess, without the need for git.

Git repos for protocol specs looking pretty stoneage right now.

To boost the signal.

But signal has to mean something by definition.

Like for app releases, I want a 3rd party dev I trust to Attest to it the release of another dev. Not just hash of the image, but actually read the code.