Re: NOSTR Censorship Improvement Proposal

út 18. 3. 2025 v 9:00 odesílatel Bitcoin_Fan_1 <Bitcoin_Fan_1@protonmail.com>
napsal:

> Hello everyone, I just wanted to pass along a draft of a proposal that I
> created this evening to try to eliminate or greatly reduce censorship on
> NOSTR. Please review it when you can and feel free to share any feedback
> that you have. Thank you.
>
> ---
>
> # **NIP-21mm: Hash-Linked Messages and Lightweight Client Relays for
> Censorship Resistance**
>
> **Date**: March 17, 2025
> **Author**:Bitcoin_Fan_1@protonmail.com
> **Status**: Draft
> **Category**: Protocol Improvement
>
> ---
>
> ## **Abstract**
>
> This proposal introduces a method to enhance censorship resistance in the
> Nostr protocol by implementing hash-linked message structures and
> lightweight client relay functionality. The goal is to ensure that users
> can verify the integrity and authenticity of their messages while
> minimizing reliance on external relays. This approach creates a
> cryptographically verifiable chain of messages for each user and allows
> users to act as the first relay for their own messages.
>
> ---
>
> ## **Motivation**
>
> Currently, Nostr relies on relays to distribute user-signed messages
> across the network. However, there is no way for users to ensure that
> relays are not censoring or tampering with their messages. This lack of
> transparency undermines the protocol's censorship resistance.
>
> The proposed solution addresses this issue by:
> 1. Structuring messages in a hash-linked format, enabling verifiable
> integrity across a user's entire message history.
> 2. Introducing lightweight relay functionality within client software,
> allowing users to act as the first relay for their own messages.
> 3. Providing mechanisms for other clients to verify message authenticity
> against the user's original relay.
>
> ---
>
> ## **Specification**
>
> ### **1. Message Structure**
> Each message sent by a user will include additional fields to create a
> cryptographically verifiable chain of messages. The structure is as follows:
>
> #### **First Message (Message 0)**
> The first message sent by a user includes:
> - The standard Nostr message data (e.g., `content`, `pubkey`,
> `created_at`, etc.).
> - A SHA256 hash of:
>   - The message content.
>   - The Unix timestamp (`created_at`) in seconds when the message was
> created.
>   - A sequential message number (`msg_number`), starting at `0`.
> - A digital signature of the above hash using the user's private key.
>
> #### **Subsequent Messages**
> Each subsequent message includes:
> - The standard Nostr message data.
> - A SHA256 hash of:
>   - The current message content.
>   - The Unix timestamp (`created_at`).
>   - The sequential message number (`msg_number`).
>   - The hash of the previous message in the sequence.
> - A digital signature of the above hash using the user's private key.
>
> This creates a hash-linked chain of messages, similar to a blockchain but
> specific to each user.
>
> ### **2. Lightweight Client Relay**
> Each Nostr client will include optional lightweight relay functionality to
> act as the first point of transmission for its user's messages. This relay
> will:
> - Store all messages sent by the user locally.
> - Broadcast these messages to one or more external relays for wider
> distribution.
> - Publicly display the hash of each transmitted message for verification
> purposes.
>
> ### **3. Verification by Receiving Clients**
> Receiving clients can verify the authenticity and integrity of a user's
> messages by:
> 1. Querying the user's personal relay (if available) to retrieve the
> original message and its hash.
> 2. Comparing the retrieved hash with hashes stored on other relays.
> 3. Validating that each message's hash matches its signature and that the
> chain of hashes is intact.
>
> ---
>
> ## **Rationale**
>
> The proposed changes enhance censorship resistance by:
> 1. Ensuring that any attempt to censor or tamper with messages is
> detectable through cryptographic verification.
> 2. Reducing reliance on external relays by allowing users to act as their
> own initial relay.
> 3. Preserving compatibility with existing Nostr infrastructure while
> introducing optional enhancements.
>
> By linking messages in a cryptographically verifiable chain, users gain
> greater control over their data without requiring significant changes to
> existing protocols.
>
> ---
>
> ## **Backward Compatibility**
>
> This proposal is backward-compatible with existing Nostr clients and
> relays, as it does not alter the core protocol's requirements. Clients and
> relays that do not implement these changes can still process standard Nostr
> messages but will not benefit from enhanced verification features.
>
> ---
>
> ## **Security Considerations**
>
> 1. **Hash Collision Resistance**: The use of SHA256 ensures that it is
> computationally infeasible to generate two different inputs with the same
> hash, preserving message integrity.
> 2. **Private Key Security**: As with existing Nostr functionality, users
> must safeguard their private keys to prevent unauthorized signing of
> messages..
> 3. **Relay Availability**: If a user's personal relay is offline,
> verification may be delayed until it becomes available again. External
> relays can serve as backups in such cases.
>
> ---
>
> ## **Implementation Plan**
>
> 1. Add support for hash-linked message structures in Nostr clients.
> 2. Develop lightweight relay functionality as an optional feature in
> client software.
> 3. Update receiving clients to verify hashes against personal relays when
> available.
>
> ---
>
> ## **Future Work**
>
> 1. Explore incentives for external relays to store and distribute
> verifiable hash-linked messages.
> 2. Investigate additional cryptographic techniques (e.g., Merkle trees) to
> optimize storage and verification processes.
>
> ---
>
> ## **Conclusion**
>
> This proposal enhances Nostr's censorship resistance by introducing
> cryptographically verifiable message chains and empowering users with
> lightweight client relay functionality. By enabling transparent
> verification of message authenticity and integrity, it strengthens trust in
> the protocol while preserving its decentralized nature.
>

Hi, this looks great!

So it's like a personal blockchain that links each of your messages
together, making it easy to detect if anything’s been censored or tampered
with?


>
> ---
>
>
>