NIP Proposal: Static Content Integrity Verification through SHA-256 Checksums

[rikmeijer]

Abstract This proposal addresses the issue of misleading or deceptive edits to static media content (in event contents), often used to exploit emotions and drive unwanted interactions. This proposal suggests implementing SHA-256 checksums for static content in Nostr events to enhance content integrity, prevent abuse, and facilitate scalable, safe distribution across the network.

{
   ...,
   "content" : "....http://example.org/image.png..."
   ...
}

Problem Statement On social media, malicious actors commonly exploit the flexibility of post edits to deceive audiences. For instance, a widely shared post about a missing pet can later be edited to promote unrelated products. This practice erodes trust, making users reluctant to share or believe legitimate information. The same risk applies to Nostr, where URLs can be embedded in events to point to images or other static resources that, without verification, could be swapped for unrelated or malicious content.

Solution We propose adding a SHA-256 checksum as a “static-tag” in Nostr events to ensure the integrity of static resources. The tag will follow the format ['static', <url>, \<sha256-checksum>], allowing clients and relays to verify that the static content remains unchanged over time. This will protect users from deceptive edits while preserving trust in shared content.

Implementation Details

1. Static-Tag Definition: Each event containing a static resource will include a ['static', , ] tag. The checksum is a SHA-256 hash of the content at the URL when it is first posted.
2. Client-Side Validation: Clients can use this checksum to verify that the content at the specified URL has not been altered. Before displaying the content, the client can check the current SHA-256 hash of the resource against the hash in the event.
3. Relay Prefetching and Caching: To optimize content distribution, relays can prefetch and cache static resources tagged with checksums. Clients can then request these cached resources from the relay, reducing load on the original server and improving access speed.
4. Enhanced Security and Trust: By verifying resources with checksums, clients can prevent unauthorized edits to static content, ensuring that users see only the intended information. This will reduce the risk of deception and maintain trust in the platform.
5. Scalability: As relays cache and serve static content to clients, this solution offloads traffic from the original servers, making Nostr more scalable and efficient in distributing static resources.

{
   ...,
   "content" : "....http://example.org/image.png..."
   ...,
   "tags" : {
       ["static", "http://example.org/image.png", "5adbf884ce022d0fcb9977c6118b7e7f795c30eda25d643f99d298e25be3ce90"]
   }
}

Relays implementing this NIP MUST provide an HTTP interface for downloading cached static files:

>>> GET /static/5adbf884ce022d0fcb9977c6118b7e7f795c30eda25d643f99d298e25be3ce90
<<< ....image contents here...

Advantages • Integrity and Trust: Prevents malicious edits to embedded content, building user trust. • Efficiency: Reduces server load by distributing static content through relay caching. • Safety: Protects users from scams and manipulations that exploit emotional triggers.

Conclusion Incorporating SHA-256 checksums for static content in Nostr events provides a robust mechanism to maintain content integrity, build trust, and optimize scalability. This addition will enhance the Nostr ecosystem, making it safer and more reliable for users.

[staab]

This should already be covered by NIP 94 + blossom, it just needs to be adopted.

[rikmeijer]

Was looking for that, but could not find it. Thanks!!Op 8 nov 2024 17:42 schreef hodlbod @.***>: This should already be covered by NIP 94 + blossom, it just needs to be adopted.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[mikedilger]

NIP-92 defines the 'imeta' tag which can have a SHA-256 hash ('x' field): https://github.com/nostr-protocol/nips/blob/master/92.md

It refers to NIP-94 which defines the fields.

Relays can also be blossom servers https://github.com/hzrd149/blossom but don't have to be.

[rikmeijer]

That looks a lot like what I had in mind, but then worked out. Excellent!