Nostr Web Client

nostr:nprofile1qqsydl97xpj74udw0qg5vkfyujyjxd3l706jd0t0w0turp93d0vvungpz9mhxue69uhkummnw3ezuamfdejj7qgwwaehxw309ahx7uewd3hkctcpremhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet59udpecz0 thoughts?

Attestations can be made for any Subject Event of any Kind.

Proof of Place Attestations by nostr:nprofile1qqsra2ey033mkdwl5w8q0jss9ak69zafh82xsuvhwsaauw3trkq2amgpz9mhxue69uhkummnw3ezuamfdejj7qgcwaehxw309anxjmr5v4ezumn0wd68ytnhd9hx2tck28qzu? No problem.

Proof of (software) Release on nostr:nprofile1qqs83nn04fezvsu89p8xg7axjwye2u67errat3dx2um725fs7qnrqlgzqtdq0 by your favourite dev? Attestations gotchu.

The options are only limited by the number of Kinds, which are limitless.

Zapstore 6mo ago

Interesting!

Leo Wandersleb 6mo ago

Who is using it for what? nostr:npub1qw6sxmwrmwpxqsc8cxty62ujvst6j8pmz8hhtwnv54gpn6dh5c4qms4882 nostr:npub1r709glp0xx2zvgac45wswufjst5xgr7cear5a8me7x9vazhjzmksp2sf7d is this compatible with our verifications/attestations? It sounds like their "attestations" are our "endorsements"?

What are endorsements? Do you have a NIP or some ref docs I can look at.

Attestations are kind agnostic.

https://gitlab.com/walletscrutiny/walletScrutinyCom/-/blob/0b3387bfdfee889daebf604822a935d212d539f8/docs/verifications.md#endorsement

Our "Endorsements" are so much simpler. It's just this event type, but we haven't implemented them yet. We're still thinking on the best way to do it:

Yep, equivalent. The simplest form of an Attestation is v simple too. All other events in the NIP are optional, as are most of the tags in the base kind.

Would be cool to have you using it also! You would simply use your verification event (30301) as the Subject Event.

My primary interest was to keep this super simple and generic so I can use to attest records that could be relied on as verifiable credentials. I’m a few weeks out on the implementation as I am getting the basic record transmission stuff working (offers, grants, presentations). I’ll then graft on the attestations as per the NIP.

I'll give a look at it in 2 weeks, and we (the team) will talk about it first, but I think we could end up using it. Thanks a lot Nathan!

Hey Nathan,

Is this NIP more or less stable now? Should we expect to have changes to it yet?

btc_remnant 5mo ago

Another question. In the event 31871, what's the "d" tag for?

Nathan Day 5mo ago

Needs to be addressable and replaceable to support revocations.

I did have revocations as a separate event to begin with, but was steered this way to keep it simpler and have a single event representing the current state.

btc_remnant 5mo ago

Ah! Of course! What was I thinking? Thanks!

Nathan Day 5mo ago

Pretty stable I think, especially the basics. Tweaks expected as clients implement and we learn what we got wrong.

btc_remnant 5mo ago

It would be something like this:

Nathan Day 5mo ago

Nice.

Zapstore 5mo ago

Love seeing this!

nostr:nprofile1qyghwumn8ghj7mn0wd68ytnhd9hx2tcprpmhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0qqsvfa085adgecmg84ffelcxx6zrn3ffu5jrc6cjtwng0zge3ptv43c5xzlap was great listening to you on PCR.

Eager to implement on Zapstore

btc_remnant 4mo ago

Hey Nathan!

Do we have an "oficial" nip for this Attestations spec?

Nathan Day 4mo ago

Not in the merged sense.

Community NIPs are the repo now.

Maybe it gets merged one day, but I think the protocol can be more emergent now.

nostr:nprofile1qqsqddupn4l3cl65wggcyehd009g0pwuatsfudh28f90vewx68vrylqprfmhxue69uhhyetvv9ujuem9w3skccne9e3k7mf0wccszenhwden5te0ve5kcar9wghxummnw3ezuamfdejj7mnsw43rzufkd43hywr5d3erxmp5va6hxvmnveh8wd3hxue8xdm6v9jnv6r3de3k6ae4wa4rydm9df6kgdthvduxvdm3xph8sdmyx5lkyun0v9jxxctnws7hgun4v5q3gamnwvaz7tmjv4kxz7fwv3sk6atn9e5k7nznd8h will be using it for #safebox.

nostr:nprofile1qqsw3mfhnrr0l6ll5zzsrtpeufckv2lazc8k3ru5c3wkjtv8vlwngkspz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszythwden5te0dehhxarj9emkjmn99uq3vamnwvaz7tmwdaehgun9d35hgetn9ehhyee0k52r6j for nostr:nprofile1qqsd0kqsnmjrv47wvpt2mfr9xqrthdjp7v09p6zjgd5pcfey2puprmqppemhxue69uhkummn9ekx7mp0qythwumn8ghj7urpw3jhytnwdaehgu339e3k7mf0qyfhwumn8ghj7ur4wfcxcetsv9njuetn9ucut0gy.

nostr:nprofile1qqsra2ey033mkdwl5w8q0jss9ak69zafh82xsuvhwsaauw3trkq2amgpz9mhxue69uhkummnw3ezuamfdejj7qgcwaehxw309anxjmr5v4ezumn0wd68ytnhd9hx2tck28qzu for Proof of Place.

I think it works really well for nostr:nprofile1qqs83nn04fezvsu89p8xg7axjwye2u67errat3dx2um725fs7qnrqlgzqtdq0 too.

Hell, we can even define what Nostr is itself by using the NIP NIP nostr:nprofile1qqsqgc0uhmxycvm5gwvn944c7yfxnnxm0nyh8tt62zhrvtd3xkj8fhgprdmhxue69uhkwmr9v9ek7mnpw3hhytnyv4mz7un9d3shjqghwaehxw309aex2mrp0yh8qunfd4skctnwv46z7qgewaehxw309aex2mrp0yh8xmn0wf6zuum0vd5kzmp033tada has created.

I smell a PCR return

What’s PCR?

nostr:nprofile1qqs0wgf8etnayvkcs4c636fdvepy73jc9q2xlcln64srjdm5e98p8ncpzfmhxue69uhhqatjwpkx2urpvuhx2ucpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhg32edh4 what’s Plebchain Radio 🤣

Ha! I was operating under the wrong model context. Was thinking biological.

polymerase chain reaction

Oh that PCR!

nostr:nevent1qqsf7tzr2s6pq44sx7v72pc2a9xumlkal0rzkzyyyuc86806jzn2jzgzyr0k07d8usgj2azuheavl0wdqd530qxxg00hhtts7hfppredflpqqqcyqqqqqqgpzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgqg5waehxw309aex2mrp0yhxgctdw4eju6t0wghut4

Sorry I was traveling during your show. Great work. 🫡

ManiMe 6mo ago

We’ve been talking about trust attestations for almost two years.

After many panel discussions and Nostr threads, a “few of us” came to the realization that, while having a NIP for “explicit trust attestation” would be great, getting clients to implement and end users to author “explicit attentions” reliably … would be a big ask … with little actual reward in the end.

In order to determine “actual” trustworthiness (of content or users), having an incomplete (low usage) or imprecise (poor usage) collection of “explicit” trust markers will not replace the need for algos to process any number of “implicit” trust markers that are already abundant and available to harvest on Nostr.

This is why nostr:npub1e2vcfcr6yea25e67ryktrtd0a24dsedzwlprj6v45997uhw27p3qtzkq3u and I developed the GrapeRank library … a pluggable, extensible, and configurable algo engine for determining trusted users and content. It can (easily be extended to) ingest any number of content “kinds” (including explicit attestations) to calculate a weighted list of trusted users on any given topic in “your network”.

https://github.com/Pretty-Good-Freedom-Tech/graperank-nodejs

nostr:npub1cn670f663n3ks02jnnlsvd5y88zjnefy8343ykaxs7y3nzzketrsrjwt8a, I’m glad you’re working on explicit trust attestations … but in the end we’re still gonna need algos to extract implied trust from Nostr. Happy to discuss further.

I agree re the algos. Attestation can form part of the raw data that the algos needs to surface and extrapolate from.

Will dive into GrapeRank; looks cool.

Trust is a vector: about what and to what extent. Direction AND magnitude.

dannybuntu 6mo ago

Our existing system is a powerful, specific implementation of what the Attestations NIP aims to generalize. Our "verifications" are a highly specialized form of their "attestations." The NIP is not a replacement for our testing infrastructure but a potential protocol for broadcasting our results. Adopting the NIP could significantly increase the reach and interoperability of our findings within the broader Nostr ecosystem, making WalletScrutiny a foundational "Attestor" for app reproducibility.

We use a sophisticated, automated testing infrastructure to perform reproducible build verifications for cryptocurrency wallets, primarily for Android and hardware wallets. The goal is to determine if the publicly available application binary matches the publicly available source code. The results are published as detailed "Review Pages" on our website.

Attestations NIP: This is a new, generic proposal for making, tracking, and revoking truthfulness claims about any event on Nostr. It is not specific to wallets or reproducible builds. As it's a new proposal, it currently has no widespread adoption, but it aims to be a foundational layer for any "web of trust" application, from fact-checking to reputation systems.

Yeah, looks like you are a specialised Attestor.

Would some form of Evidence tag work for your usecase?

An Attestation event could optionally reference your (Release) Verification event in this way.

We refer to the process of arriving at an Attestation state (valid/invalid) as the verification process, but we are silent on what that process is as it's Subject Event - and often Attestor specific - and is down for the WoT to weigh those.

Some form of evidence expectation could optionally be included in the Attestation Request. 🤔

dannybuntu 6mo ago

nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgkwaehxw309aex2mrp0yhxummnw3ezumn9wshsqgqrk5pkms7msfsyxp7pjexjhynyz753cwc3aa6m5m992qv7ndax9gk27w9w could answer that.

> An Attestation event could optionally reference your (Release) Verification event in this way

Yeah, I guess we could use part of the NIP. Probably not the full one, as I don't see us requesting attestations to other users. Maybe I'm wrong. Also, is this mechanism meant to be implemented by general purpose clients? I mean, I don't expect a lot of clients showing our "verifications" events, so I don't know if any client will show the "request for attestation" to our event kinds.

No, I don't think it'll be in general clients.

Specific clients will show relevent Attestations base on the kind type of the Subject Event.

e.g. nostr:nprofile1qqsra2ey033mkdwl5w8q0jss9ak69zafh82xsuvhwsaauw3trkq2amgpz9mhxue69uhkummnw3ezuamfdejj7qgcwaehxw309anxjmr5v4ezumn0wd68ytnhd9hx2tck28qzu will show Place Attestations.

Attestation marketplaces will emerge as specialist clients.

https://primal.net/e/nevent1qqsfl6r8uzvnqsf5v005xt4szss505nhfs9f3xk3waadr2y64u3ssusdxqame

Yes, it's kind of the same concept. I still have to read it more carefully, but maybe we could implement some parts of the nip, not all of it:

Niel Liesmons 6mo ago

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.

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

nostr:nprofile1qqsqgc0uhmxycvm5gwvn944c7yfxnnxm0nyh8tt62zhrvtd3xkj8fhgprdmhxue69uhkwmr9v9ek7mnpw3hhytnyv4mz7un9d3shjqghwaehxw309aex2mrp0yh8qunfd4skctnwv46z7qgewaehxw309aex2mrp0yh8xmn0wf6zuum0vd5kzmp033tada 👀

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

Niel Liesmons 6mo ago

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.

MK Fain 6mo ago

Nice! Thanks for submitting to NostrHub!

Does MKStacks look at the community NIPs when building?

We should add all the NIPs there as native Nostr events.

And it wasn't submitted 😉

You're just showing the NIP Note. ✊

https://fountain.fm/clip/FJOollZwURM8kEE2p44m

Attestations fix this.

Right, nostr:nprofile1qqsqddupn4l3cl65wggcyehd009g0pwuatsfudh28f90vewx68vrylqprfmhxue69uhhyetvv9ujuem9w3skccne9e3k7mf0wccszenhwden5te0ve5kcar9wghxummnw3ezuamfdejj7mnsw43rzufkd43hywr5d3erxmp5va6hxvmnveh8wd3hxue8xdm6v9jnv6r3de3k6ae4wa4rydm9df6kgdthvduxvdm3xph8sdmyx5lkyun0v9jxxctnws7hgun4v5q3gamnwvaz7tmjv4kxz7fwv3sk6atn9e5k7nznd8h?

nostr:nevent1qqsrqslwy8fhhs36pa2a7r3edvvxfwwwgsq9tun89ny90477jz057hqpz3mhxw309ucnydewxqhrqt338g6rsd3e9upzp384u7n44r8rdq74988lqcmggww998jjg0rtzfd6dpufrxy9djk8qvzqqqqqqyq46qx0