Oddbean new post about | logout
▲ ▼
ManiMe | 10 months ago (raw) | root | parent | reply | flag +1 
 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?
▲ ▼
Michael J | 10 months ago (raw) | root | parent | reply | flag +1 
 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 | 10 months ago (raw) | root | parent | reply | flag +1 
 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?
▲ ▼
Michael J | 10 months ago (raw) | root | parent | reply | flag +1 
 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 | 10 months ago (raw) | root | parent | reply | flag +2 
 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.”