So, the core concept is simple. I put an object on a server somewhere, and I want other people to know that it's legitimate. Using this NIP, I create an event that identifies that object, tells others where to find it, and attests to it with my Nostr identity, all at once.
Beyond just Git, this NIP can form the basis of SharePoint or Google Drive services, software release verification, authentication of images, and many other use cases besides. The only limit is imagination.
So this proposal would only verify that a URI is associate with an npub, but not sign for the content located at the URI. Even if content changes, verification remains in tack until revoked “manually”. Is this correct?
The proposal contains the suggestion that the note contain a hash of the object referred to.
I can imagine using this to have multiple people "sign off" on a document or a change to a document, like a social media note, an advertising image, or a new version of a company webpage.
You could simply have pull-requests run on any object identified by the PR, before it be considered "released", and define who has to approve the PR.
If you use a simple ID, then you can replace the contents at that URI without breaking the association. In that case, the even attests to a URI more so than an object.
If you use a hash of the object as the ID, then you can validate the object, even if it moves, at any number of URIs.
So can serve dual purpose… nice. But how does a client know which kind ID an event is using? Is there a standard verifying what the decrypted hash “should” equate to?
If you create an event that uses a hash-based identifier, the protocol requires you to include the name of the hashing algorithm you used as an event tag. So a client could read the event, download the object from the URI, run the specified hash function (e.g., SHA-256), and compare it to the ID of the Nostr event. It's kind of like a checksum.
Right. Now this is a bit out of my wheelhouse… but I do imagine such verification could be needed on other “not single object” web accessible data. Namely, descrete content embedded (and only accessible) within an HTML page.
EG:
Suppose a nostr user wants to verify a single post on a shared blog. Such a blog may have sidebar and footer data that changes periodically. The page content cannot be verified, but the post content could be.
Would this proposal suggest a “standard” by which “verifiable data” could be discovered at such a URI with mixed data?
I'm hesitant to prescribe a particular solution, because any number of possible situations and solutions may exist for what you are describing.
One very simple approach would be to provide some additional verification details in the `content` field of the event. My proposal doesn't make any requirements on what must be in the `content` field, so a client for verifying a web page could give a specific URI, like "myblog.com/post1#section" to sign that specific section of the page. The in the content of the event, a copy of the content of that section of the page could be provided. If it changes at the source, that would be immediately apparent to the client.
Thanks. I wonder if this should be specified with more detail in order for this NIP to fit “many other use cases besides. The only limit is imagination.”
You could then run an enterprise search engine over a relay and be able to find objects, like an Internet search machine, and rate how relevant or trustworthy they are.
Instead of Google PageRank, you could have Nostr SignRank.
My dream would to be able to ⭐ people's software releases. I'm always getting asked which software I recommend in which version and I'd like to have a list of everything I'd favorited or rated or whatever.
And I'd like to be able to see the ratings my favorite developers, testers, and power users have given. Then I could see what they'd ⭐, check it out and maybe add my own star.
2 ⭐ confirmations
45 ⭐ confirmations
147 ⭐ confirmations
Now, show me the most-⭐ repos in category "budgeting" or "Bitcoin memes". Show me the trending repos (those most actively receiving stars). Etc.
I think it's quite revolutionary because, until this NIP, you had to go to a particular website to ⭐ stuff. Now you can ⭐ anything, anywhere you can point to it with some sort of internet identifier, using any client that writes and signs ⭐ notes, and your star can be evaluated by anyone reading from any relay you've written your ⭐ to.
You can star Beave's Blacksmithy webpage, Beth's Baked Goods e-bay site, Vitor's Amethyst release, Michael's newest NIP, whatever.
nostr:nevent1qqsrm8zpsegx3qhe8ps3823wtupsdvurawrg5n5c6s784ugcwd9529qprfmhxue69uhhg6r9vehhyetnwshxummnw3erztnrdaksygxavex4usqkgvage45lqpdwzjqgqs630zd4nhj67p38dhn9vv7nrypsgqqqqqqsq5he6p
This NIP proposal looks promising as a verification tool for ANY user owned web property, including user profiles on other services.
Cause NIP-39 needs updating or replacement…
nostr:note1q0xay5052cwgxpxk9zd8xqwpgz8pgxg8ftlxxl3n2k0qyakhspwslk77ru
I hadn't even thought of that use case, but I can definitely see the possibility!
Also … when artists post their cool creations (see bellow) to social media… I wonder if such a NIP could be used to help them verify original ownership? (Maybe a stretch, but just an example of the many ways that verification of external web properties could be valuable on nostr)
mostr:note1lqcy0gcqdxhzrcgnwtatm3pkahv2465lhr62kewwqyhh3lvyvxjs3474y9