Notification Standard (Basics)

The Notification Standard (Basics) provides fundamental definitions and concepts to understand how notifications work within the NeoCast protocol:

1. Verification Proof:

   • A proof attached to each notification that allows the network to validate its authenticity.

   • Usually handled automatically by the Smart Contract or SDK.

2. Notification Identity:

   • Defines how the notification is formatted and stored.

   • For most interactions, this is abstracted away, but for Smart Contracts, you can refer to it for customization.

3. Identity Type:

   • Defines the format in which the notification JSON payload is sent to the network.

   • Common types include:

     • Type 0 (Minimal): Recommended for Smart Contracts.

     • Type 2 (Direct Payload): Recommended for NeoCast SDK.

4. Notification Type:

   • Defines the type of notification being sent:

     • Broadcast (Type 1): Sent to all users who have opted into your channel.

     • Targeted (Type 3): Sent to an individual user.

     • Subset (Type 4): Sent to a subset of users of your channel.

5. Notification Content:

   • Defines the content of the notification, including the Notification JSON Object and Payload JSON Object.

   • Recipients:

     • 0x0 for Type 1 (broadcast).

     • 0xTarget for Type 3 (Targeted).

     • [0x01, 0x02, 0x03, ..., 0xN] for Type 4 (Subset).

6. Content Markdown:

   • Defines how content markdown should be passed to enable various types of notifications (covered in the advanced section).

7. Sender:

   • Defines who is sending the message, represented in CAIP-10 format.

   • Supports Ethereum (Goerli) and Polygon (Mumbai) chains.

   • Exception: For smart contract to smart contract interactions, the native blockchain address is required, not CAIP-10.

8. Source:

   • Indicates where the notification is coming from.

   • Supports various sources, such as ETH_TEST_KOVAN, ETH_MAINNET, POLYGON_MAINNET, POLYGON_TEST_MUMBAI, and more.

   • Source is abstracted away unless you are interacting directly with NeoCast Nodes.

9. Recipient(s):

   • Defines the address to which the notification should be delivered, also in CAIP-10 format.

   • Supports Ethereum (Goerli) and Polygon (Mumbai) chains.

   • Exception: For smart contract to smart contract interactions, the native blockchain address is required, not CAIP-10.

Examples:

• It's recommended to start with Identity Type 0 (Minimal) for smart contracts.

• Notification Type 1 (Broadcast) should have the recipient as the channel.

• Notification Type 3 (Targeted) should have the intended recipient as the recipient.

• Notification Type 4 (Subset) is not supported yet.

Here's an example of sending a notification using the NeoCast SDK:

INeoCastCommInterface(EPNS_COMM_CONTRACT_ADDRESS_FOR_SPECIFIC_BLOCKCHAIN).sendNotification(
    YOUR_CHANNEL_ADDRESS, // From channel
    to, // To recipient
    bytes(
        string(
            // Notification identity
            abi.encodePacked(
                "0", // Notification identity
                "+", // Separator
                "3", // Payload type (1, 3, or 4) = (Broadcast, targeted, or subset)
                "+", // Separator
                "Title", // Notification title
                "+", // Separator
                "Body" // Notification body
            )
        )
    )
);

These concepts help you understand the basic building blocks of notifications within the NeoCast protocol, allowing for secure and customizable communication in the Web3 environment.