Nostr Web Client

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.

ManiMe 2y ago

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?

Reply to this note

Please Login to reply.

Discussion

MichaelJ 2y ago

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.

ManiMe 2y ago

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