├── .gitignore ├── PIPs ├── pip-1-workflow-index.md ├── README.md └── consideration │ └── pip-1-workflow-index.md ├── assets ├── template │ └── pip_lifecycle.png └── definitions │ └── standard_notification_composable.png ├── definitions ├── Standard │ ├── Networking │ │ └── README.md │ ├── Core │ │ └── README.md │ ├── Interface │ │ └── README.md │ ├── PRC │ │ ├── README.md │ │ ├── Chat │ │ │ ├── README.md │ │ │ ├── Encryption │ │ │ │ └── README.md │ │ │ ├── Verification │ │ │ │ ├── README.md │ │ │ │ ├── Message │ │ │ │ │ └── README.md │ │ │ │ └── User │ │ │ │ │ └── README.md │ │ │ └── Payload │ │ │ │ └── README.md │ │ └── Notification │ │ │ ├── README.md │ │ │ ├── Identity │ │ │ └── README.md │ │ │ ├── Content │ │ │ └── README.md │ │ │ ├── Verification │ │ │ └── README.md │ │ │ └── Payload │ │ │ └── README.md │ └── README.md ├── Meta │ └── README.md ├── Informational │ └── README.md └── README.md ├── pip-lifecycle.md ├── pip-template.md └── README.md /.gitignore: -------------------------------------------------------------------------------- 1 | **/.DS_Store 2 | -------------------------------------------------------------------------------- /PIPs/pip-1-workflow-index.md: -------------------------------------------------------------------------------- 1 | [PIP-1 is in living state and can be found here](./consideration/pip-1-workflow-index.md) 2 | -------------------------------------------------------------------------------- /assets/template/pip_lifecycle.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/push-protocol/PIPs/HEAD/assets/template/pip_lifecycle.png -------------------------------------------------------------------------------- /assets/definitions/standard_notification_composable.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/push-protocol/PIPs/HEAD/assets/definitions/standard_notification_composable.png -------------------------------------------------------------------------------- /definitions/Standard/Networking/README.md: -------------------------------------------------------------------------------- 1 | # Networking 2 | 3 | `Networking` - includes networking specifications and proposals around how push nodes communicate and interoperate. 4 | -------------------------------------------------------------------------------- /definitions/Standard/Core/README.md: -------------------------------------------------------------------------------- 1 | # Core 2 | 3 | `Core`: improvements requiring a consensus fork or changes in Push nodes, as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions, and the miner/node strategy changes. 4 | -------------------------------------------------------------------------------- /definitions/Standard/Interface/README.md: -------------------------------------------------------------------------------- 1 | # Interface 2 | 3 | Interface - : includes improvements around client API/RPC specifications and standards, and also certain language-level standards like method names and contract ABIs. The label “interface” aligns with the [interfaces repo] and discussion should primarily occur in that repository before an PIP is submitted to the PIPs repository. 4 | -------------------------------------------------------------------------------- /definitions/Standard/PRC/README.md: -------------------------------------------------------------------------------- 1 | # About PRC - Push Request Comments - Definition / Specs 2 | 3 | A PRC is subcategory of `PIPs` types which comes under Standard Track. It signifies, application-level standards and conventions, including notification, chat payloads, and content markdown. PRCs are currently broken down into the following subcategories. To learn more about individual subcategory, please drill down to the specific folder. 4 | 5 | 1. **Notification**: Allows Push Notifications protocol to be sent through the network. Contains rules, specs, definitions for ways to verify, form identity, payload or the content interpretation rules for developers to send notification out. 6 | 7 | 2. **Chat**: Allows chat to be sent through the netwok. Contain rules, spec and definitions for users to start sending chat out to each other or for developers to build on top of the protocol. 8 | -------------------------------------------------------------------------------- /definitions/Standard/PRC/Chat/README.md: -------------------------------------------------------------------------------- 1 | # About Push Chat - Definitions / Specs 2 | 3 | ## What is Push Chat? 4 | 5 | Push Chat is a web3 messaging protocol that enables wallet addresses to send and receive messages, offering a secure and privacy-focused alternative to traditional messaging apps. By leveraging blockchain technology, users can communicate directly via their wallet addresses without personal identifiers like phone numbers. Designed for mainstream adoption, Push Chat serves as a protocol that any dApp, web3 wallet, or backend can integrate to provide their users with messaging capabilities. Additionally, chat messages in Push Chat come with built-in notifications, similar to what users are accustomed to in web2 messaging platforms, ensuring a familiar and convenient user experience. This combination of features makes Push Chat a vital tool for anyone seeking to harness Web3 communication's full potential. 6 | -------------------------------------------------------------------------------- /definitions/Standard/README.md: -------------------------------------------------------------------------------- 1 | # About Standard Type PIP - Definition / Specs 2 | 3 | A Standards Track PIP describes any change that affects most or all Push protocol implementations, such as changes in core, interface, networking or application level standards. They are broken down into the following categories. 4 | 5 | 1. **Core**: includes improvements for changes in the network including incentives and rewards, syncing, consensus mechanism changes and processes that might require fork cause of breaking changes. 6 | 7 | 2. **Interface**: includes improvements around client API/RPC specifications and standards, and also certain language-level standards that may help in standardizing interfacing. 8 | 9 | 3. **Networking**: includes networking specifications and proposals around how push nodes communicate and interoperate. 10 | 11 | 4. **PRC**: Signifies, application-level standards and conventions, including verification, identity, payloads, content markdown for notifications, chats or any communication standard that is added. 12 | -------------------------------------------------------------------------------- /PIPs/README.md: -------------------------------------------------------------------------------- 1 | # PUSH Improvement Proposals (PIPs) 2 | 3 | Before you initiate a pull request, please read the [PIP-1](./PIPs/pip-1-workflow-index.md) process document. Ideas should be thoroughly discussed on [Push discord](https://discord.gg/YVPB99F9W5) or [Push forum](https://gov.push.org/c/pip/29) . 4 | 5 | ## What are PIPs? 6 | 7 | PIPs defines the standards in the Push protocol ecosystem in which anyone can create, amend these proposals by submitting them. The goal of the PIP project is to document standardized protocols for Push nodes, payload standards, applications and to document them in a high quality and implementable way. 8 | 9 | ## How to submit a PIP? 10 | 11 | Start by duplicating the [template](../pip-template.md) and submitting a PR in /consideration folder. Read the [proposal lifecycle](../pip-lifecycle.md) to understand the lifecycle of the proposal. 12 | 13 | ## What are different Types, Categories, Subcategories, Niche in PIP? 14 | 15 | Read [definitions](../definitions) to understand types, categories, subcategories, and niches. 16 | 17 | ## Understanding nomenclature of PIP submission? 18 | 19 | All PIPs rest under /consideration folder. Once a PIP is finalized, it is duplicated and moved to the PIPs folder. If a PIP is living, then its link is moved here. 20 | -------------------------------------------------------------------------------- /pip-lifecycle.md: -------------------------------------------------------------------------------- 1 | ## What is the lifecycle of PIP? 2 | 3 | The following is the standardization process for all Push Protocol Standards Improvement Proposals: 4 | 5 | ![Proposal Process](/assets/template/pip_lifecycle.png) 6 | 7 | **Idea** - An idea that is pre-draft. It can be done over Push [Discord](https://discord.gg/Ftv83Dgw) or [Push forum](https://gov.epns.io/c/general-discussions/18) . 8 | 9 | **Draft** - The first formally tracked stage of a proposal in development. To create draft, you should submit PR request against an issue in 10 | `epns-protocol-standards` repository. Make sure the draft should be in the respective payload standards subdirectory. 11 | 12 | **Last Call** - This is the final review window for a PIP before moving to Final. A PIP editor will assign Last Call status and set a review end date (last-call-deadline), typically 14 days later. 13 | 14 | If this period results in necessary normative changes, it will revert the PIP to Review. 15 | 16 | **Review** - An Author marks a proposal as ready for and requests Peer Review. This is the final window for the proposal before moving to the final. 17 | 18 | **Final** - This represents the final standard. A Final proposal exists in a state of finality and should only be updated to correct errata and add non-normative clarifications. 19 | 20 | **Stagnant** - Any proposal in Draft or Review or Last Call if inactive for a period of 4 months or greater, is moved to Stale. The proposal may be resurrected from this state by Authors or Editors by moving it back to Draft or its earlier status. If not resurrected, a proposal may stay forever in this status. 21 | 22 | **Withdrawn** - The Author(s) have withdrawn the proposed submission. This state has finality and can no longer be resurrected using this proposal number. If the idea is pursued at a later date it is considered a new proposal. 23 | 24 | **Living** - A special status for PIPs that are designed to be continually updated and not reach a state of finality. This includes most notably PIP-1. 25 | -------------------------------------------------------------------------------- /definitions/Standard/PRC/Notification/README.md: -------------------------------------------------------------------------------- 1 | # About Notification - Definitions / Specs 2 | ## What is Notification? 3 | Notifications follow composable blocks that helps achieve modular structure and helps in building on top of them. Any developer can utilize the notification protocol to send out notifications (on-chain or off-chain) to their users from a variety of platforms including web3 protocols, smart contracts, dapps, backend, etc. These notifications are tied to wallet address of the user and are indexed by push nodes allowing any crypto frontend such as wallet, dapp or mobile app to query and display these notifications for the wallet users along with sending them out as push notifications. 4 | 5 | ![EPNS Protocol Hierarchy](../../../../assets/definitions/standard_notification_composable.png) 6 | 7 | ## Specifications 8 | ``` 9 | Verification - To verify the notification 10 | Identity - To understand the storage format and rules to interpret the notification payload 11 | Payload - To understand what is the type of notification, what data it contains and to whom it should be addresses to 12 | Content - To interpret or extend format types for content inside the notification 13 | ``` 14 | 15 | * `Verification` - It defines the way to verify that the payload is valid by checking sender, source, and authenticitiy of the payload content. 16 | 17 | * `Identity` - Notification Identity Payload is the standard through which notification payload can be sent to Push Nodes for processing. There are multiple ways by which these payloads can be stored (storage-independent behavior) and identity ensures that the push node are able to understand and construct the notification payload from the data. 18 | 19 | * `Payload` - Each notification sent to the protocol is essentially a JSON payload which contains data about things a notification contains, notification recipients and even data to encrypt these notifications. This json payload is what makes Push Protocol payload content-independent and allows for expansion to several new types of notifications based on the community needs and as the communication protocol develops further. 20 | 21 | * `Content` - Notification Content Markdown standardize the content markdown and create a standard for styling and formatting. 22 | -------------------------------------------------------------------------------- /definitions/Standard/PRC/Chat/Encryption/README.md: -------------------------------------------------------------------------------- 1 | # About Encryption - Definition / Specs 2 | 3 | ## What is Chat Encryption? 4 | 5 | On this section we describe all the encryption algorithms and processes used to secure the chat messages. 6 | 7 | ## Specifications 8 | 9 | This document outlines the first version of our chat messaging system's encryption process. We employ a double encryption methodology, leveraging the Advanced Encryption Standard (AES) for encrypting the message content and Pretty Good Privacy (PGP) for securing the AES key itself. This approach guarantees message confidentiality and integrity, ensuring that only the intended recipients can decipher the original message. The subsequent sections will provide detailed explanations of our encryption and decryption mechanisms, emphasizing the robust security measures we've implemented to protect your communications. 10 | 11 | Here below are the encryption types (versions) that we currently support: 12 | 13 | | encryption type | Description | 14 | | --------------- | -------------------------------------------------------- | 15 | | `pgp` | Double encryption schema that leverages both AES and PGP | 16 | 17 | ## Encryption type: `pgp` 18 | 19 | ### Message Encryption Process 20 | 21 | 1. Generate a Random AES Key: For each message, a random AES key is generated. This is a symmetric key that will be used to encrypt the actual message content. 22 | 23 | 2. Encrypt the Message Payload: The generated AES key is then used to encrypt the message payload. The output of this process is a ciphertext - a scrambled version of your message that can only be decrypted using the same AES key. 24 | 25 | 3. Encrypt the AES Key: This is where asymmetric encryption comes into play. We take the AES key and encrypt it using the PGP private keys of all users involved in the conversation. This means that only the users who hold the corresponding PGP public keys can decrypt this AES key. 26 | 27 | 4. Add Encrypted AES Key to Payload: The encrypted AES key is then added to the message payload. 28 | 29 | ### Message Decryption Process 30 | 31 | 1. Retrieve PGP Public Key: When a user receives a message, they first retrieve their PGP public key from the server. 32 | 33 | 2. Decrypt the AES Key: The user then uses their PGP public key to decrypt the encrypted AES key that was sent along with the message payload. 34 | 35 | 3. Decrypt the Message Content: Once the AES key has been decrypted, it is then used to decrypt the message content. What they get is the original plaintext message that was sent. 36 | -------------------------------------------------------------------------------- /definitions/Standard/PRC/Chat/Verification/README.md: -------------------------------------------------------------------------------- 1 | # About Verification - Definitions / Specs 2 | 3 | ## What is Verification? 4 | 5 | Push Chat incorporates a rigorous verification process divided into User Verification and Chat Verification. User Verification ensures the authenticity of user data during creation or modification, while Chat Verification is responsible for validating the messages exchanged within the chat system. This dual-layered verification mechanism serves to uphold the integrity of both users and their communication, fortifying the overall security of our system. 6 | 7 | ## Specifications 8 | 9 | In Push Chat, we place a strong emphasis on the verification process to ensure data integrity and user authenticity. To achieve this, we implement two levels of verification: User Verification and Chat Verification. 10 | 11 | ### User Verification 12 | 13 | User verification is primarily conducted when there's any creation or modification of user data. This includes details such as the user's name, chosen encryption type (which determines how the PGP private key is encrypted), and an encrypted password (particularly relevant for NFT chat). 14 | 15 | This verification process is designed to ensure the integrity and authenticity of the user information being created or modified. When such changes occur, the system automatically triggers the verification process to validate the authenticity of the user and the legitimacy of the changes being made. It's an integral step in maintaining the security of the user accounts and in turn, the overall integrity of our chat system. 16 | 17 | ### Chat Verification 18 | 19 | On the other hand, chat verification is the validation of the messages exchanged within the chat system. Every time a message is sent or received, the system and the client both execute a verification process. 20 | 21 | This process involves verifying the signature attached to each message. As each message is signed with the sender's private key, the system and the client can use the sender's public key to verify the signature, thus confirming the authenticity and integrity of the message. Both Push Nodes and client applications participate in this verification process. 22 | 23 | By utilizing the Push Nodes for this verification, we ensure a layer of server-side security. Additionally, client-side verification adds an extra layer of security, verifying the message upon receipt, ensuring its integrity hasn't been compromised during transmission. 24 | 25 | Through these two verification processes, our chat system aims to provide a secure environment for users to communicate, ensuring the authenticity of users and the integrity of the messages being exchanged. 26 | -------------------------------------------------------------------------------- /pip-template.md: -------------------------------------------------------------------------------- 1 | 2 | | title | description | author | status | type | category | subcategory | niche | created | 3 | |---|---|---|---|---|---|---|---|---| 4 | | The PIP title is a few words, not a complete sentence | Description is one full (short) sentence | The list of the author's name(s) and username(s), or name(s) and email(s). | Draft / Living / Review / Final | One of Standards Track, Process, or Informational | (Optional field, only needed for Standards Track PIPs) One of Core, Network, Interface, Storage, or PRC | (Optional field, only needed if proposal is to improve subcategory) | (Optional field, only needed if proposal is to improve a niche of a subcategory) | YYYY-MM-DD Date the PIP was created on (ISO 8601 format) | 5 | 6 | This is the suggested template for new PIP. More info about type, category, subcategory, niche can be found in [PIP-1](./PIPs/PIP-1-workflow-index) or in [Definitions & Specs](./definitions). Note that a PIP number will be assigned by an editor. When opening a pull request to submit your PIP, please use an abbreviated title in the filename, `pip-number-title-abbrev.md`. 7 | 8 | **The title should be 64 characters or less. It should not repeat the PIP number in title, irrespective of the category.** 9 | 10 | Each Proposal should have the following parts: 11 | 12 | * **Abstract** - Abstract is a multi-sentence (short paragraph) technical summary. This should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does. 13 | 14 | * **Motivation** - A motivation section is critical for Proposals that want to change or amend the Standards. It should clearly explain why the existing Standard specification is inadequate to address the problem that the proposed solves. Proposals without sufficient motivation may be rejected outright. 15 | 16 | * **Specification** - The technical specification should describe the syntax and semantics of any new feature. 17 | 18 | * **Rationale** (*optional)- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale should discuss important objections or concerns raised during discussion around the Proposal. 19 | 20 | * **Test Cases** - Test cases for an implementation are mandatory for PIPs that are affecting consensus changes. If the test suite is too large to reasonably be included inline, then consider adding it as one or more files in ../assets/pip-####/. 21 | 22 | * **Reference Implementation** (*Optional)- An optional section that contains a reference/example implementation that people can use to assist in understanding or implementing this specification. 23 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # PUSH Improvement Proposals (PIPs) 2 | 3 | Push Improvement Proposals (PIPs) enable Push protocol to form standardized, community-driven improvements, specs and standards with the mission to create a seamless, standardized, community-built communication protocol of web3 to be used by all web3 actors (protocols, dapps, smart contracts, wallets, backend and users). 4 | 5 | ## What are PIPs? 6 | 7 | PIPs define the standards in the Push protocol ecosystem in which anyone can create, amend these proposals by submitting them. The goal of the PIP project is to document standardized protocols for Push nodes, payload standards, applications and to document them in a high quality and implementable way. 8 | 9 | ## How to submit a PIP? 10 | 11 | Before you initiate a pull request, please read the [PIP-1](./PIPs/consideration/pip-1-workflow-index.md) process document. Read [definitions](./definitions) to understand types, categories, subcategories, and niches. Ideas should be thoroughly discussed on [Push discord](https://discord.gg/YVPB99F9W5) or [Push forum](https://gov.push.org/c/pip/29). 12 | 13 | Read this to learn about how to [submit proposal](./pip-lifecycle.md) and [template](./pip-template.md) of standard PIPs. 14 | 15 | # Accepted PIPs 16 | 17 | | ID | Desc | Type | Category | Subcategory | Niche | Status | 18 | |---|---|---|---|---|---|---| 19 | [PIP-1](./PIPs/pip-1-workflow-index.md) | Workflow Index | Standard | -- | -- | -- | Living | 20 | 21 | # PIPs in consideration 22 | 23 | | ID | Desc | Type | Category | Subcategory | Niche | Status | 24 | |---|---|---|---|---|---|---| 25 | 26 | Note: Finalized PIPs will be listed in Accepted PIPs, while PIPs that are going through the lifecycle but are not stale or withdrawn will appear in **PIPs in consideration**. 27 | 28 | ## PIPs Standards Editors 29 | 30 | The current editors are: 31 | 32 | * Pranshu Rastogi [@pranshurastogii](https://twitter.com/pranshurastogii) 33 | * Harsh Rajat [@harshrajat](https://twitter.com/harshrajat) 34 | 35 | ## Contact us 36 | 37 | Stay in touch! [Website](https://www.push.org), [Twitter](https://twitter.com/pushprotocol), [Discord](https://discord.gg/YVPB99F9W5), [Docs](https://docs.push.org), [Whitepaper](https://whitepaper.push.org/), [Telegram](https://t.me/epnsproject), [Medium](https://medium.com/ethereum-push-notification-service), [YouTube](https://www.youtube.com/c/EthereumPushNotificationService) 38 | 39 | ## History 40 | 41 | This document was derived heavily from [Ethereum's EIP-1](https://eips.ethereum.org/EIPS/eip-1), which was derived from [Bitcoin's BIP-0001](https://github.com/bitcoin/bips) written by Amir Taaki, which in turn was derived from [Python's PEP-0001](https://www.python.org/dev/peps/). In many places text was simply copied and modified. 42 | 43 | Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the PUSH Improvement Process, and should not be bothered with technical questions specific to Push or the PIP. Please direct all comments to the [PIP editors](https://github.com/ethereum-push-notification-service/PIPs#pips-standards-editors). 44 | -------------------------------------------------------------------------------- /definitions/Meta/README.md: -------------------------------------------------------------------------------- 1 | # Types 2 | 3 | There are three major categories of PIPs, as well as more specific subcategories: 4 | 5 | 1. A Standards Track PIP describes any change that affects most or all EPNS implementations, such as—a change to the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Ethereum. Standards Track EIPs consist of three parts—a design document, an implementation, and (if warranted) an update to the formal specification. Furthermore, Standards Track EIPs can be broken down into the following categories: 6 | 7 | * `Core`: improvements requiring a consensus fork or changes in Push nodes, as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions, and the miner/node strategy changes. 8 | 9 | * `Interface` - : includes improvements around client API/RPC specifications and standards, and also certain language-level standards like method names and contract ABIs. The label “interface” aligns with the [interfaces repo] and discussion should primarily occur in that repository before a PIP is submitted to the PIPs repository. 10 | 11 | * `Networking` - includes networking specifications and proposals around how push nodes communicate and interoperate. 12 | 13 | * `PRC` - signifies, application-level standards and conventions, including notification, chat payloads, and content markdown. It also includes subcategories. 14 | 15 | * `Notifications` - follow composable blocks that help achieve modular structure and help in building on top of them: 16 | 17 | * `Chat` - \ 18 | 19 | 2. A Meta PIP describes a process surrounding EPNS or proposes a change to (or an event in) a process. Process PIPs are like Standards Track PIPs but apply to areas other than the EPNS protocol itself. They may propose an implementation, but not to EPNS codebase; they often require community consensus; unlike Informational PIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in EPNS development. Any meta-PIP is also considered a Process PIP. 20 | 21 | 3. An Informational PIP provides general guidelines or information to the EPNS community, but does not propose a new feature. Informational PIPs do not necessarily represent a EPNS community consensus or recommendation, so users and implementors are free to ignore Informational PIPs or follow their advice. 22 | 23 | It is highly recommended that a single PIP contain a single key proposal or new idea. The more focused the PIP, the more successful it tends to be. e.g. - A typo or single change in payloads doesn't require PIP. It should be contributing as major improvement or change multiple clients. 24 | 25 | A PIP must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly. 26 | -------------------------------------------------------------------------------- /definitions/Informational/README.md: -------------------------------------------------------------------------------- 1 | # Types 2 | 3 | There are three major categories of PIPs, as well as more specific subcategories: 4 | 5 | 1. A Standards Track PIP describes any change that affects most or all EPNS implementations, such as—a change to the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Ethereum. Standards Track EIPs consist of three parts—a design document, an implementation, and (if warranted) an update to the formal specification. Furthermore, Standards Track EIPs can be broken down into the following categories: 6 | 7 | * `Core`: improvements requiring a consensus fork or changes in Push nodes, as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions, and the miner/node strategy changes. 8 | 9 | * `Interface` - : includes improvements around client API/RPC specifications and standards, and also certain language-level standards like method names and contract ABIs. The label “interface” aligns with the [interfaces repo] and discussion should primarily occur in that repository before an PIP is submitted to the PIPs repository. 10 | 11 | * `Networking` - includes networking specifications and proposals around how push nodes communicate and interoperate. 12 | 13 | * `PRC` - signifies, application-level standards and conventions, including notification, chat payloads, and content markdown. It also includes subcategories. 14 | 15 | * `Notifications` - follow composable blocks that help achieve modular structure and help in building on top of them: 16 | 17 | * `Chat` - \ 18 | 19 | 2. A Meta PIP describes a process surrounding EPNS or proposes a change to (or an event in) a process. Process PIPs are like Standards Track PIPs but apply to areas other than the EPNS protocol itself. They may propose an implementation, but not to EPNS codebase; they often require community consensus; unlike Informational PIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in EPNS development. Any meta-PIP is also considered a Process PIP. 20 | 21 | 3. An Informational PIP provides general guidelines or information to the EPNS community, but does not propose a new feature. Informational PIPs do not necessarily represent a EPNS community consensus or recommendation, so users and implementors are free to ignore Informational PIPs or follow their advice. 22 | 23 | It is highly recommended that a single PIP contain a single key proposal or new idea. The more focused the PIP, the more successful it tends to be. e.g. - A typo or single change in payloads doesn't require PIP. It should be contributing as major improvement or change multiple clients. 24 | 25 | A PIP must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly. 26 | -------------------------------------------------------------------------------- /definitions/Standard/PRC/Notification/Identity/README.md: -------------------------------------------------------------------------------- 1 | # About Notification Identity - Definitions / Specs 2 | 3 | ## What is Notification Identity? 4 | Identity defines where the notification is coming from and the rules by which we can get the payload json of that specific notification. Current supported identities are Minimal, IPFS, Direct and Subgraph. 5 | 6 | ## Specifications 7 | Each notification identity carries at the least two parameters which are joined by **+** delimeter, the first parameter represents the identity type used (Minimal, IPFS, Direct, etc) and the second parameter represents either the hash or identifying information that can be used to fetch the necessary JSON which can also be made of composable information. 8 | 9 | | Parameter | Definition | 10 | | ------------- | ------------- | 11 | | Identity Type | The type id representing from where the payload is stored or coming from | 12 | | Identity Info | Hash of the payload representing proof or pointer from which the storage can be retrieved | 13 | 14 | #### Types of _payloadstorage 15 | | Id | Type | Definition | 16 | | ------------- | ------------- | ------------- | 17 | | 0 | Minimal | Recommended for Smart Contract | 18 | | 1 | IPFS | Indicates storage on IPFS | 19 | | 2 | Direct Payload | Indicates storage of direct payload | 20 | | 3 | Subgraph (TheGraph) | Indicates storage on the subgraph | 21 | 22 | ### Payload identity implementation - 23 | 24 | ##### **Type 0** :arrow_right: 25 | >```Payload Storage + Notification Type + Title + body ``` 26 | 27 | 28 | * ```Notification Payload Type``` - Type of notification (Broadcast, Subset, Targetted, Secret, etc) 29 | 30 | * ```Title``` - This will be the title of the Message. 31 | 32 | * ```Body``` - This will be the body/description of the Message. 33 | 34 | 35 | > ```Example``` :thinking: 0+1+Hello+This is brodacasted notification 36 | 37 | * ```_payloadstorage``` is represented as **0** 38 | 39 | * ```_payloadhash``` is represented as **1+Hello+This is brodacasted notification** 40 | 41 |
42 | 43 | ##### **Type 1** :arrow_right: 44 | >`Payload Storage + IPFS HASH (cid)` 45 | Using type 2 is recommened as it's faster 46 | 47 | * ```IPFS HASH``` - The hash of the json payload when uploaded to IPFS, is also called cid 48 | 49 | 50 | >```Example``` :thinking: 1+b45165ed3cd437b9ffad02a2aad22a4ddc69162470e2622982889ce5826f6e3d 51 | 52 | * ```_payloadstorage``` is represented as **1** 53 | 54 | * ```_payloadhash``` is represented as **b45165ed3cd437b9ffad02a2aad22a4ddc69162470e2622982889ce5826f6e3d** 55 |
56 | 57 | ##### **Type 2** :arrow_right: 58 | > Payload Storage + JSON PAYLOAD SHA-256 HASH 59 | > - `JSON PAYLOAD` - The json payload 60 | 61 | > Example 🤔 2+{\"notification\":{\"title\":\"Push x LISCON\",\"body\":\"Dropping payload directly on push nodes at LISCON 2021.\"},\"data\":{\"acta\":\"\",\"aimg\":\"\",\"amsg\":\"Current BTC price is - 47,785.10USD\",\"asub\":\"\",\"type\":\"3\",\"secret\":\"\"}} 62 | > 63 | - `_payloadstorage` is represented as **2** 64 | - `_payloadhash` is represented as {\"notification\":{\"title\":\"Push x LISCON\",\"body\":\"Dropping payload directly on push nodes at LISCON 2021.\"},\"data\":{\"acta\":\"\",\"aimg\":\"\",\"amsg\":\"Current BTC price is - 47,785.10USD\",\"asub\":\"\",\"type\":\"3\",\"secret\":\"\"}} 65 | 66 |
67 | 68 | ##### **Type 3** :arrow_right: 69 | >`Payload Storage + GraphId + notification number[counter]` 70 | 71 | * ```GraphId``` - This will be the id of subgraph. It is usually represented as `githubid/subgraph name` e.g - epns/epnssubgraph. 72 | 73 | * ```notification number[counter]``` - It will keep the count of Notifications and will process in a successive manner 74 | 75 | 76 | >```Example``` :thinking: 3+graph:aiswaryawalter/graph-poc-sample+3 77 | 78 | * ```_payloadstorage``` is represented as **3** 79 | 80 | * ```_payloadhash``` is represented as **graph:aiswaryawalter/graph-poc-sample+3** 81 | 82 | -------------------------------------------------------------------------------- /definitions/README.md: -------------------------------------------------------------------------------- 1 | # Definitions about Types, Category, Subcategory and Niche of PIPs 2 | 3 | The folder contains specific information about individual Types, Categories, Subcategories and Niche of Push Protocol along with current specs derived from finalized PIPs. Definitions of these topics and things inside them will keep on changing as PIPs are finalized. If you are looking to submit a PIP, please [head over here](../PIPs). 4 | 5 | ## Understanding PIP Types, Categories, Subcategories and Niche 6 | 7 | PIP proposals are classified into **type** which can then optionally be categorized into **category** -> **subcategory** -> **niche**. Type describes the high level standard which the PIP wants to address. Category describes the type drilldown which a specific PIP is created to address. Subcategory dives deeper into a particular category while niche describes the low level component of that subcategory. 8 | 9 | ### Type 10 | 11 | Type describes the high level standard which the PIP wants to improve. 12 | 13 | 1. **Standard** PIP describes any change that affects most or all Push protocol implementations, such as changes in core, interface, networking or application level standards. 14 | 15 | 2. **Meta** PIP describes a process surrounding Push or proposes a change to (or an event in) a process. Process PIPs are like Standards Track PIPs but apply to areas other than the Push protocol itself. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Push development. Any meta-PIP is also considered a Process PIP. 16 | 17 | 3. **Informational** PIP provides general guidelines or information to the EPNS community, but does not propose a new feature. Informational PIPs do not necessarily represent a EPNS community consensus or recommendation, so users and implementors are free to ignore Informational PIPs or follow their advice. 18 | 19 | ### Category 20 | 21 | Categories are only required for **Standard** Type PIPs and define the branch of PUSH Protocol which it targets to improve. 22 | 23 | 1. **Core**: includes improvements for changes in the network including incentives and rewards, syncing, consensus mechanism changes and processes that might require fork cause of breaking changes. 24 | 25 | 2. **Interface**: includes improvements around client API/RPC specifications and standards, and also certain language-level standards that may help in standardizing interfacing. 26 | 27 | 3. **Networking**: includes networking specifications and proposals around how push nodes communicate and interoperate. 28 | 29 | 4. **PRC**: Signifies, application-level standards and conventions, including verification, identity, payloads, content markdown for notifications, chats or any communication standard that is added. 30 | 31 | ### Subcategory 32 | 33 | Subcategory are optional and mainly required for **PRC** category, they define the particular topic within the Category. 34 | 35 | 1. **Notification**: Available under Standard > PRC > Notification which addresses specs, proposals and improvements for everything related to push notification protocol. 36 | 37 | 2. **Chat**: Available under Standard > PRC > Chat which addresses spec, proposals and improvements for everything related to push chat protocol. 38 | 39 | ### Niche 40 | 41 | Niche are optional and are required in some **Subcategory** sections. they define the specific low level functionality that needs to be changed, improved or addressed. 42 | 43 | For Subcategory: **Notification** 44 | 45 | 1. **Verification**: Addresses different types of verifications that can be used while sending a notification to Push node. 46 | 47 | 2. **Identity**: Identitifies from where a notification payload is coming along with what is the storage mode, protocol to transform it to json payload, etc. 48 | 49 | 3. **Payload**: Addresses what payload of the notification should contain including the way notification should be encrypted, things payload can carry and how they transform and the recipients for which it is intended to be. 50 | 51 | 4. **Content**: Defines how content inside the notification can be displayed, mostly markdown for title and the body of notification. 52 | 53 | For Subcategory: **Chat** 54 | 55 | {TBD} 56 | -------------------------------------------------------------------------------- /definitions/Standard/PRC/Notification/Content/README.md: -------------------------------------------------------------------------------- 1 | # About Content - Definition / Specs 2 | ## What is Notification Content? 3 | Notification have the ability to display customized content both for the asub and amsg field of the data payload. By adopting and standardizing the notification content markdown, it ensures that we can keep on advancing the ways notification are presented on the frontend / UI. 4 | 5 | ## Specifications 6 | ``` Current Markdown standards are - ``` 7 | 8 | | Previous Markdown | Cuurrent Markdown | Use Case | Styling effects | 9 | |---|---|---|---| 10 | | [b: textcontent] | \*\***Bold**** | For Emphasis | For Bold | 11 | | [i: textcontent] | \**Italic** | For Emphasis | For Italics | 12 | | [bi: textcontent] | \*\*\*Bold&Italics\*** | For Emphasis | For Bold and Italics | 13 | | \n | \n | For Segregation | For new line | 14 | | [w: textcontent] | \Hello World\ | For colored text | For white color | 15 | | | \ Hello world \ | For colored text | Supports any color by hexcode | 16 | | [d: textcontent] | \Hello World \ | For colored text | EPNS Primary colored Text | 17 | | [s: textcontent] | \Hello World \ | For colored text | EPNS Secondary colored Text | 18 | | [t: textcontent] |\Hello World \ | For colored text | EPNS Tetiary colored Text | 19 | |[u: textcontent] | \ EPNS website \ | For URL’s | Underlined, Red Colored Text | 20 | 21 | 22 | ## Reference Implementation - 23 | 24 | > Note : We strongly recommend to use new current markdown structure, for the backward compatibility we still have previous markdown, these are intended to get deprecated in future. 25 | 26 | * **For Bold** - 27 | ``` 28 | > Use case - For Emphasis 29 | > Current Markdown - **Bold** 30 | > Backward compatibility - [b: textcontent] 31 | > Implementation - **PUSH IMPROVEMENT PROPOSAL** 32 | ``` 33 | 34 | * **For Italics** - 35 | ``` 36 | > Use case - For Emphasis 37 | > Current Markdown - *Italics* 38 | > Backward compatibility - [i: textcontent] 39 | > Implementation - *Slant text* 40 | ``` 41 | * **For Bold and Italics** - 42 | ``` 43 | > Use case - For Emphasis 44 | > Current Markdown - ***Bold&Italics*** 45 | > Backward compatibility - [bi: textcontent] 46 | > Implementation - ***Push guidelines*** 47 | ``` 48 | * **For new Line** - 49 | ``` 50 | > Use case - For Segregation 51 | > Current Markdown - \n 52 | > Backward compatibility - \n 53 | > Implementation - Sub category of Notification PRC - \n 54 | * Content 55 | ``` 56 | 57 | * **For white color** - 58 | ``` 59 | > Use case - For colored text 60 | > Current Markdown - PUSH 61 | > Backward compatibility - [w: textcontent] 62 | > Implementation - w2w chat 63 | ``` 64 | * **For any color in hexcode** - 65 | ``` 66 | > Use case - For colored text 67 | > Current Markdown - Hello world 68 | > Backward compatibility - Not present in previous version 69 | > Implementation - Push Nodes 70 | ``` 71 | * **EPNS Primary colored Text** - 72 | ``` 73 | > Use case - For colored text 74 | > Current Markdown - Hello World 75 | > Backward compatibility - [d: textcontent] 76 | > Implementation - Analytics dashboard 77 | ``` 78 | * **EPNS Secondary colored Text** - 79 | ``` 80 | > Use case - For colored text 81 | > Current Markdown - Hello World 82 | > Backward compatibility - [s: textcontent] 83 | > Implementation - EPNS Dapp 84 | ``` 85 | * **EPNS Tetiary colored Text** 86 | ``` 87 | > Use case - For colored text 88 | > Current Markdown - Hello World 89 | > Backward compatibility - [t: textcontent] 90 | > Implementation - EPNS Browser extension 91 | ``` 92 | * **For Underlined, Red Colored Text** 93 | ``` 94 | > Use case - For URL’s 95 | > Current Markdown - [EPNS Website](https://www.epns.io) 96 | > Backward compatibility - [u: textcontent] 97 | > Implementation - Hello World 98 | ``` 99 | -------------------------------------------------------------------------------- /definitions/Standard/PRC/Chat/Payload/README.md: -------------------------------------------------------------------------------- 1 | # About Chat Payload - Definitions / Specs 2 | 3 | ## What is Chat Payload? 4 | 5 | This section outlines the specifications for the chat payload in Push Chat. Messages are a JSON object that serves as the blueprint for every message sent and received in our system. 6 | 7 | This current version of the chat payload includes a diverse range of properties, from user identifiers and message content to encryption details and timestamps. This structure is designed to be extensible, allowing for the incorporation of additional properties in future versions to suit emerging needs. 8 | 9 | ## Specifications 10 | 11 | ```typescript 12 | { 13 | fromCAIP10: string 14 | toCAIP10: string 15 | fromDID: string 16 | toDID: string 17 | messageType: string 18 | messageContent: string 19 | signature: string 20 | sigType: string 21 | timestamp?: number 22 | encType: string 23 | encryptedSecret: string 24 | link: string | null 25 | } 26 | ``` 27 | 28 | | Property | Description | 29 | | ----------------- | -------------------------------------------- | 30 | | `fromCAIP10` | address from where message was sent | 31 | | `toCAIP10` | address to where message was sent | 32 | | `fromDID` | DID from where message was sent | 33 | | `toDID` | DID to where message was sent | 34 | | `messageType` | type of message | 35 | | `messageContent` | content of message | 36 | | `signature` | signature of message | 37 | | `sigType` | signature type | 38 | | `timestamp` | timestamp of message | 39 | | `encType` | encryption type | 40 | | `encryptedSecret` | encrypted AES secret | 41 | | `link` | link to previous message on this linked list | 42 | 43 | ### Examples 44 | 45 | Here below is an example of a message: 46 | 47 | ```json 48 | { 49 | "fromCAIP10": "eip155:0x98821462cB7Aa6fca72c6590D04bEA098c4483D0", 50 | "toCAIP10": "eip155:0xd9c1CCAcD4B8a745e191b62BA3fcaD87229CB26d", 51 | "fromDID": "eip155:0x98821462cB7Aa6fca72c6590D04bEA098c4483D0", 52 | "toDID": "eip155:0xd9c1CCAcD4B8a745e191b62BA3fcaD87229CB26d", 53 | "messageContent": "U2FsdGVkX1/QZM2yDFmx783OK3lQP5QARUBlAeeTGaU=", 54 | "messageType": "Text", 55 | "signature": "-----BEGIN PGP SIGNATURE-----\n\nwsBzBAEBCAAnBYJkYgPZCZBQPfS2j6Sx+xYhBDE96UHaT4+RRqqEklA99LaP\npLH7AACVDgf/RQdGa4wNAxaNd8rWufD3yG3E7O8Xc7siSmbvMlgFDYNB7XuA\nq/LnhUbaIIacmBTCftDi1Q1XWdXbOjb5I8wx8k/gsZjqDAt/WL1zZj/GYi6E\nNZq9pk7hcbBTX6DfqhrsACGJspIrywz0hYGKMMnY5unGbFrm0tS38YkuHUmd\nFeR9ovjq8R9kbD+XqkgpgMFo0nFalWXoj5U2hbMA6gaa/oMTsUmNGTrCDPDD\nuMkocPC1UHP9KpBg9ZCQFL81SLN9v4AmAvSsPc/n9zKzFIHgY/uYgSrx5VQA\ni8LeMPTS9A49mI4jY1ksoHqHNS1FXRPfEgMq/jWQXJtm1pzhfo4VQA==\n=AXqq\n-----END PGP SIGNATURE-----\n", 56 | "timestamp": 1684145115101, 57 | "sigType": "pgp", 58 | "encType": "pgp", 59 | "encryptedSecret": "-----BEGIN PGP MESSAGE-----\n\nwcBMA4mIJ0ko6s8yAQf/f+XZEY13wPrWyjulvE65tt2qws98qfc1h4E5531r\nvBilZBK5bwIlucH4pcRVi+6IlFPN561ycAu6D/FwZS6tubDqD2qbo6ZlZU1S\nOA7qn2WEZp0LBvGeEzQR4ySltn9a3Z0wrunIReOARLyXCI7lQJsJOp4PmePv\no5/ygSrCxTCdf6gVZwfBuDZQMlGW0LoGImnzRkdvx/zGh/zo1H5x/WwVR/hK\nXPyi9jRaC64mD7QWYAboHsFEl1P5LusEz6gzQtSDxzHbXh3FwM1xbUoZ9aGJ\nb82ADySCIlZgQlsiI0YIai4xbKYmp5LddxDIqIWY4CT6jWUIfYSbTK17+5cf\nCcHATANHghddxYDNPAEIAIDUT1RwJkfQgqchNqj65jzt1XOu1MaQhlM8hEDm\nilspf4OMGRMjApu8ihe/xVHYt10UNUOz6gLeU5VlGWgoqHLCkAvHMVGnMoJb\nOmlOIV16A5U1q2uha0vmJDLIYk7ESNn3xF5G/7TsjFLWNlEHK/f4EVsu8bWh\nlVACUmStm3IS96KCuqzFMqMcgfASUONLHHgoYZ7P1Y365gLZrnQB2OMyh0yM\na7JbfGEDjxXqlKyYC8ESzGCirO4esLzX904Zrj1+3cTC9f8QM8Qkd+bWliII\nwZtkSvU5NCDH5SPYGq4ycnkufU9Nk2f7bdWy7xh6H1kdR4QgSeMEXAupv3c2\nOGTSQAHA75mcgbyJuncFI6mtcYt7lkp6IWwYq5Tjph7a9csImcETJwwTjQeU\nmuE+9vAPCCnuZg9GktXmWZRA2tzHRyo=\n=VoM8\n-----END PGP MESSAGE-----\n", 60 | "link": "bafyreibvcco53h7aptxipmt7gzi5x73cw4upceto7vt2vgire2puqoeoku" 61 | } 62 | ``` 63 | 64 | ## Linked list 65 | 66 | In Push Chat, we've implemented a linked list data structure to maintain the order and integrity of the messages within each chat. In a linked list, each element points to its preceding element, thereby creating a chain of connected elements. In the context of our system, each message contains a reference to the previous message in the conversation. 67 | 68 | This connection is facilitated by the `link` property within our Message. The `link` property holds the unique identifier of the immediately preceding message. This ensures that each message is intrinsically linked to its predecessor, creating a seamless thread of conversation that can be easily navigated and traced back. 69 | 70 | When initiating a new conversation, the `link` property for the very first message is set to null, indicating that there's no previous message in the conversation thread. This property is then updated with the identifier of each subsequent message, ensuring the chain of connectivity is maintained. This linked list structure not only maintains the order of the messages, but also adds an additional layer of security and integrity to the chat system. 71 | 72 | ## Storage 73 | 74 | In Push Chat, we've adopted a robust and distributed storage strategy for messages to ensure high availability and redundancy. Each message is stored on Push Nodes, which are servers optimized for real-time message delivery and notifications. These nodes provide a fast and efficient means of accessing and delivering the chat messages in real time. 75 | 76 | To further enhance data durability and accessibility, we also replicate each message on the InterPlanetary File System (IPFS). IPFS is a peer-to-peer distributed file system that allows data to be stored and accessed in a decentralized manner. This replication process ensures that even in the case of a Push Node failure or network outage, the messages remain accessible via IPFS, thereby providing an extra layer of data redundancy and resilience. 77 | -------------------------------------------------------------------------------- /definitions/Standard/PRC/Chat/Verification/Message/README.md: -------------------------------------------------------------------------------- 1 | # About Verification - Definition / Specs 2 | 3 | ## Specifications 4 | 5 | | sigType | Definition | 6 | | ------------------ | ---------------------------------------------------------------------- | 7 | | pgp | First version of PGP message signature | 8 | 9 | 1. `pgp` - PGP message signature 10 | 11 | When sending a message, for this verification proof, we first encrypt the `messageContent` and then we sign it with the user's PGP private key. For more information on how the `messageContent` is encrypted, see the [Message Encryption](../../Encryption/README.md) section. 12 | 13 | The signature is added to the message payload as a new field called `signature` along with the `sigType` field which specifies the type of signature used. 14 | 15 | ### Example 16 | 17 | On the example below, the message content is `Hello world`. 18 | 19 | Here is the PGP key pair for the message sender: 20 | 21 | - Sender PGP Private Key 22 | 23 | ``` 24 | -----BEGIN PGP PRIVATE KEY BLOCK----- 25 | 26 | xcLYBGMxvJkBCACELO5PIZQvNS0q5e8h7cjQGfh+IXLsJLBfhPEGre+Q8r08 27 | G7e4K0OE5jNiGXXKYV+4YdVHwgwlxY5zCzOrbHCWwrNnouIhddbl2NVIJl09 28 | pBP514vkAmxsUNXVpLjxWQC9yXjut1OhCHxfgfDz03G+jMrrZAqXLBQXmDxJ 29 | zUPKU5X+PGz2qiKbOZ0BF+1ggPxP4ZMTuLs2v9O9Zhk+AllvLKFxYfsTF5XI 30 | 9Y0i9LJk7IX9dKYb0vfr3FbVTFRQIjdrvKvd+RU6zbheqWhM69uyUEMcxwzX 31 | rw4hBXgd7zzsHL1KhLxpP/YktvKtT63nE35qNVvDuggbQF1Xmi0TFCLjABEB 32 | AAEAB/4ozEmeyUmZLLvNYv3mJiR2/50xKZf0hfqe8UUIf8XToumAVTnnMgt8 33 | SSYRILS4DEhkfGY96Qqg2hL3Nbz0K9uw3VZNJfzQwTPc7Iog5B6huTSlSMAY 34 | WBspb+YhNOAVNxjAfCDE5nd83EavoEdEq76PR5wW/mE6elOVWNs7GI3VNHgR 35 | ZhWH69KpDKjyhEBlWVah9klk6sjdCZyw2mkoLX3HV13NDnIwmHStmBiP2P0Y 36 | NFQkgN6VBaw4ciDX+tFoDgANXESu5k+pYG1sfXEGG/NdO9gG9vNRwDqIxL9s 37 | e/4kvvBdtTFUDp2G7obgSclI3nWkNeiJSM7ux4ZAOqLhZMGRBACw2UlE+C8P 38 | PtejIohuwLZN0wnWlj1JQHzz4+zq4X6Cftz9MQRa1YZjtUMOrNxOhKpcqteC 39 | aSrsgTcIvbLMCCbHIPT5qLGKdOqlUjrfBT9ISof5iI2Wuomuyx6cKIh6ZnvN 40 | E13YI62nvhJsNrBms24bLRADUle2scgkyr+D1yA0iwQAv1Ujdi1dCafxOBrc 41 | C+KtYqETRiZWQS3F6+DtCdTRnk8sAMe4tteL1suKbQxxi8mp6or6v4V/8z5s 42 | pP5OdRkAVbY6/wW/OhaJbZ9FRiz44UuST2Penpaw95oLwlEBoz3sgCI52Tu9 43 | PNQowsRq1z8W6Ptrxjk0JkNo8iCxQ82eHgkD/Rs4njNWpieMM8JIupyvJJJe 44 | 1VRM7CBTGKcFURI7YxqKnklhcslhzCPLjKp897+hQFYEBerZFq5nobayxXuO 45 | Ih+ZDa3ZNThfdYXeVC+NtfMKy0EfaUThkVaB4h3MC3/wv8QZaS4EOCpXaaDZ 46 | HnDU01heJ84D9Fo6XeiogJQBhOpGPGHNAMLAigQQAQgAPgUCYzG8mQQLCQcI 47 | CRBeEbVDt5a7xQMVCAoEFgACAQIZAQIbAwIeARYhBHQ+379eiEJ1zw1bcF4R 48 | tUO3lrvFAAAzewf+Lo5zOrvWNgj5sr3XanqcM8VJLsm8O5XJVVla7yJyfBy+ 49 | UgYlVBWjSYhr0dPX5VYSlV+nyCgxzveLlWkD15b64NxTpPLwGvav+yk8S18G 50 | N/EUqX4WZdeouN3B1jUpWoTCLNHhGyjBQn/rnQ3xN5SvGnSWliVNvR5unIvQ 51 | AsDC7Yf8TCfx5ekpGWjuFGiN65rhMByAFUeD5HhSjpEVUWaQc7cNA2hnYre1 52 | TDmFB8jY7uptMDR+6MD0LTvgApNKG1sph7n5EFV4haPqNKtbu21MQqiw29MT 53 | aeCS/IvQyyzYb1lAAKiv+z4AZq74+J0mjGVI4P9clcgJCBPb1Qj3WINrRsfC 54 | 2ARjMbyZAQgAvWfut6Gk8LvQrzep0eNz6VCwJ0gTwrogbHOxMX8r+Ft3MIUz 55 | AF/eKpAmUnhw592ubVFbBkNiZcG+h6Xb4bf79kVuvBCgp52OqtG43HeTLfJL 56 | 1WdUrJT3BadBXlIb0iWniRqx3ebZ3a+KFNiDAMCLTl0ZRGjqVY/8vZ8UnOR3 57 | OEobqOgIJrCbKZ3l+BxLkBy2G+NYzC0PuPr9xHu7iePUBjlGqDEaXNSwlFMV 58 | ZDdae6c0C17wqtfCusYSY3/IO8nvYlHO/0nxl6Vrjh4eW0mH1JcvwEEefkhM 59 | LlN+Os3XeBOxx1RhmWrHJPRTwCOSMzvKaeYCsdTxhxIzXIehNu0gPQARAQAB 60 | AAf/WXEPBaBLp3LJpTR/+SGTxwXXaXVb/4StcwlfD6SiOvHWYw9DelXLMAZK 61 | Un+Vsai5id31QgvoF21ab+we3YRoc29uT1j6xKxehsPqrBG7auMUdH4LOkRO 62 | Mlk9QTE8+gvWBaSZgdRV5Z3TcuybUGucXTERkYCJyEXqcBEDRuOMeQOVpc70 63 | CcM64ACY30po+ybxYRKsfAztThJjsnlBOeBZtPQx7XA36RELnKYxkBFoZclP 64 | RdRRiLRBFGcjNy7gWi79Eix8IAcEqO3hSkR2yreVegyAtVILerb+cBjJPqj1 65 | NCKtR7DyjRfo452wQOnWDrt36FDLttD6yvkz5+E+jLLogQQA0ASLXfx2MkLc 66 | fIoJf45+N7mQfAkp6kg3olLaYj+heYreP3MXCDI9LqyBu6jdEL53y396pkSZ 67 | jZRPpD2dT9CxTcJUnIVyCw4sUQwPsCBDEoFdiwQ6nWPoFC0Tb0MVjNVibBNa 68 | mB6L26/uf5zYfFsPC+/QYwlxJYnw5cuEHb1BDzUEAOkYXNkT1XQoVv6OtDJd 69 | 70Gq++UTzQlbdQYaeB+5fLlEeveTlS3ql5nhUVDQAgoExeH8U804TWnJlV7X 70 | nWMRZpefcmAAHt47f05BjcbQMsLeipYgsE3YA7IjqvysuYzNT3x6DcDksrsv 71 | nc1EZZjeBMkInuePiQHbJiSgwQUpyUXpA/4oYr1ivHnI61v2TgmQdpmCnsUa 72 | PFK16ybn1GyMq9EIixKUht4NR2+FpEO8xvRV5OK5eByMkDtkJoxXB1Jv8dZd 73 | Zx2lTd2Aqr0eRrrqfPYBD1UvWnNH7oniHQW6e5qbDbwEtgwuw4O4lcDy0hkT 74 | duWAFuRSaGPIc9DI9/hf0ea+TjldwsB2BBgBCAAqBQJjMbyZCRBeEbVDt5a7 75 | xQIbDBYhBHQ+379eiEJ1zw1bcF4RtUO3lrvFAAD3QQf+O9IuYDDv/3qPTICN 76 | 8ymTY6rddVBv2GE3idiMfFfEwEoup8ZzGYjRWZ0bCVl823yw4l8G27YxaWds 77 | hasH+XQAAj8ZhjWZGHrgl+inqk4DAC1X1vn9jtgcRnaXYRsInFYDvGouL0qk 78 | hOWutyF9Mog8cc66s473xKcY9NvK+jrlSzibCBWt9FFuZAZuYxsPwaFqyWBe 79 | BsnkyDM921FFSxmxN9ZP3pG2qMkqK6/jZGob9HCf5oRYNeUbOmAovVJpC2gz 80 | X/81K+ArvN0XrNvVEjZ2LcyNqFIw2Y3K+NLsthGiE1BdRu93hmMsIL73MnC1 81 | wBRozZKOhwwFcufqmoBwpATLuA== 82 | =gK7u 83 | -----END PGP PRIVATE KEY BLOCK----- 84 | ``` 85 | 86 | - Sender PGP Public Key 87 | 88 | ``` 89 | -----BEGIN PGP PUBLIC KEY BLOCK----- 90 | 91 | xsBNBGMxvJkBCACELO5PIZQvNS0q5e8h7cjQGfh+IXLsJLBfhPEGre+Q8r08 92 | G7e4K0OE5jNiGXXKYV+4YdVHwgwlxY5zCzOrbHCWwrNnouIhddbl2NVIJl09 93 | pBP514vkAmxsUNXVpLjxWQC9yXjut1OhCHxfgfDz03G+jMrrZAqXLBQXmDxJ 94 | zUPKU5X+PGz2qiKbOZ0BF+1ggPxP4ZMTuLs2v9O9Zhk+AllvLKFxYfsTF5XI 95 | 9Y0i9LJk7IX9dKYb0vfr3FbVTFRQIjdrvKvd+RU6zbheqWhM69uyUEMcxwzX 96 | rw4hBXgd7zzsHL1KhLxpP/YktvKtT63nE35qNVvDuggbQF1Xmi0TFCLjABEB 97 | AAHNAMLAigQQAQgAPgUCYzG8mQQLCQcICRBeEbVDt5a7xQMVCAoEFgACAQIZ 98 | AQIbAwIeARYhBHQ+379eiEJ1zw1bcF4RtUO3lrvFAAAzewf+Lo5zOrvWNgj5 99 | sr3XanqcM8VJLsm8O5XJVVla7yJyfBy+UgYlVBWjSYhr0dPX5VYSlV+nyCgx 100 | zveLlWkD15b64NxTpPLwGvav+yk8S18GN/EUqX4WZdeouN3B1jUpWoTCLNHh 101 | GyjBQn/rnQ3xN5SvGnSWliVNvR5unIvQAsDC7Yf8TCfx5ekpGWjuFGiN65rh 102 | MByAFUeD5HhSjpEVUWaQc7cNA2hnYre1TDmFB8jY7uptMDR+6MD0LTvgApNK 103 | G1sph7n5EFV4haPqNKtbu21MQqiw29MTaeCS/IvQyyzYb1lAAKiv+z4AZq74 104 | +J0mjGVI4P9clcgJCBPb1Qj3WINrRs7ATQRjMbyZAQgAvWfut6Gk8LvQrzep 105 | 0eNz6VCwJ0gTwrogbHOxMX8r+Ft3MIUzAF/eKpAmUnhw592ubVFbBkNiZcG+ 106 | h6Xb4bf79kVuvBCgp52OqtG43HeTLfJL1WdUrJT3BadBXlIb0iWniRqx3ebZ 107 | 3a+KFNiDAMCLTl0ZRGjqVY/8vZ8UnOR3OEobqOgIJrCbKZ3l+BxLkBy2G+NY 108 | zC0PuPr9xHu7iePUBjlGqDEaXNSwlFMVZDdae6c0C17wqtfCusYSY3/IO8nv 109 | YlHO/0nxl6Vrjh4eW0mH1JcvwEEefkhMLlN+Os3XeBOxx1RhmWrHJPRTwCOS 110 | MzvKaeYCsdTxhxIzXIehNu0gPQARAQABwsB2BBgBCAAqBQJjMbyZCRBeEbVD 111 | t5a7xQIbDBYhBHQ+379eiEJ1zw1bcF4RtUO3lrvFAAD3QQf+O9IuYDDv/3qP 112 | TICN8ymTY6rddVBv2GE3idiMfFfEwEoup8ZzGYjRWZ0bCVl823yw4l8G27Yx 113 | aWdshasH+XQAAj8ZhjWZGHrgl+inqk4DAC1X1vn9jtgcRnaXYRsInFYDvGou 114 | L0qkhOWutyF9Mog8cc66s473xKcY9NvK+jrlSzibCBWt9FFuZAZuYxsPwaFq 115 | yWBeBsnkyDM921FFSxmxN9ZP3pG2qMkqK6/jZGob9HCf5oRYNeUbOmAovVJp 116 | C2gzX/81K+ArvN0XrNvVEjZ2LcyNqFIw2Y3K+NLsthGiE1BdRu93hmMsIL73 117 | MnC1wBRozZKOhwwFcufqmoBwpATLuA== 118 | =63nV 119 | -----END PGP PUBLIC KEY BLOCK----- 120 | ``` 121 | 122 | Here is the AES key: 123 | 124 | ``` 125 | oeE0kKQ22oHGmlB 126 | ``` 127 | 128 | After encrypting the message content with the AES key above, we get: 129 | 130 | ``` 131 | U2FsdGVkX1829XhNvWDq1f1CNR4yHfzQ1Dm79agXAek= 132 | ``` 133 | 134 | Then the `pgp` signature type for the encrypted message content above is: 135 | 136 | ``` 137 | -----BEGIN PGP SIGNATURE-----\n\nwsBzBAEBCAAnBQJka1GDCRBeEbVDt5a7xRYhBHQ+379eiEJ1zw1bcF4RtUO3\nlrvFAABfCQf+OTryGm59OOh8nYIvKHntnG9/Zc7ekPGXaKoj0GB6vEWJPq0I\ngYlDGWcBvU0k8drd7V9CAiG+d+TuoOnxJlLI/hLTy35W4hpvT7Pzu6e7Lqx9\nP93B2AX/5EGbi0904oCvLVinvGI7vmJlRwmjzvtZGzJdG9y50ayrJSM7uil6\n/l14oqIAb6hb9uROsxuEwoFZxBDk7S7WtZ7TXq9gTddJr16Sd5PwUN3RCBrY\ndV0BLLiPKwQz10CxEUlEElTpdJPMY0/Al9jNM1kZV89o/ITj8cILS+LhNFng\nPuSn6DC2WbgTCP3XJlpipzvqqPbC5pteN7pVxaLU1Sx7CMob2LlC6Q==\n=QQE5\n-----END PGP SIGNATURE-----\n 138 | ``` 139 | 140 | The message payload will then contains those fields related to the signature: 141 | 142 | ```json 143 | { 144 | ... 145 | "messageContent": "U2FsdGVkX1829XhNvWDq1f1CNR4yHfzQ1Dm79agXAek=", 146 | "messageType": "Text", 147 | "signature": "-----BEGIN PGP SIGNATURE-----\n\nwsBzBAEBCAAnBQJka1GDCRBeEbVDt5a7xRYhBHQ+379eiEJ1zw1bcF4RtUO3\nlrvFAABfCQf+OTryGm59OOh8nYIvKHntnG9/Zc7ekPGXaKoj0GB6vEWJPq0I\ngYlDGWcBvU0k8drd7V9CAiG+d+TuoOnxJlLI/hLTy35W4hpvT7Pzu6e7Lqx9\nP93B2AX/5EGbi0904oCvLVinvGI7vmJlRwmjzvtZGzJdG9y50ayrJSM7uil6\n/l14oqIAb6hb9uROsxuEwoFZxBDk7S7WtZ7TXq9gTddJr16Sd5PwUN3RCBrY\ndV0BLLiPKwQz10CxEUlEElTpdJPMY0/Al9jNM1kZV89o/ITj8cILS+LhNFng\nPuSn6DC2WbgTCP3XJlpipzvqqPbC5pteN7pVxaLU1Sx7CMob2LlC6Q==\n=QQE5\n-----END PGP SIGNATURE-----\n", 148 | "sigType": "pgp", 149 | ... 150 | } 151 | ``` -------------------------------------------------------------------------------- /definitions/Standard/PRC/Notification/Verification/README.md: -------------------------------------------------------------------------------- 1 | # About Verification - Definition / Specs 2 | 3 | ## What is Verification Proof? 4 | Verification Proof is the outermost composable block that is sent along with then notification to help the network validate notification sender, chain from which the notification is sent and the content of the notification along with any other validation that might be required. Verification proofs differ based on the platform from which they are sent. ie: Smart contracts verification proof can be validated on-chain and smart contract based notifications will usually carry tx hash proofs while off-chain / gasless notifications usually carry eip712 proofs, though they are capable of carrying smart contract verification proof as well which makes it composable. 5 | 6 | ## Specifications 7 | 8 | | Verification Proof | Definition | Proof of Verification | 9 | |---|---|---| 10 | | eip155:chainId:txHash::uid::optionaluid | Verification proof generated from tx hash of EPNSComm smart contracts on Ethereum or polygon.| The type can be proven by on-chain activity | 11 | | eip712v1:signature::uid::optionaluid | Verification proof generated from off-chain EIP-712 signing of payload | The type is proven by verifying the signature of eip712. | 12 | | eip712v2:signature::uid::optionaluid | Verification proof generated from off-chain EIP-712 signing of payload | The type is proven by verifying the signature of eip712 | 13 | | thegraph:graphid+notifcounter::uid::optionaluid | Verification proof generated from any subgraph | The type is proven by validating if the subgraph is attached to the channel and then the counter id is used to pick the message and compare the payload with the payload stored on the graph | 14 | 15 | **Note**: **::uid::** is an optional delimeter which if present along with **optionaluid** allows the proof to be uniquely different. 16 |
17 | 18 | 1. `eip155:chainId:txHash::uid::optionaluid` - This signifies the verification from the on-chain, currently Ethereum and Polygon are supported networks and it can be verified by resolving the transaction hash from the respective chains and make sure that identity is present in the block. **::uid::** is an optional delimeter which if present along with **optionaluid** allows the proof to be uniquely different. 19 | 20 | 2. `eip712v1` - This signifies the verification from the off-chain, the verification is done through EIP-712 based signature. **::uid::** is an optional delimeter which if present along with **optionaluid** allows the proof to be uniquely different. 21 | 22 | Note: eip-712v1 has limitation to support only completed old payload which include all the params of the payload which are part of notification, data and recepients. As the identity formats like 0,1 and 3 have single string payload that's the reason only identity 2 is compatiable with eip-712v1. To overcome this limitation eip-712v2 is identity independent. 23 | 24 | 3. `eip712v2` - eip712v2:\, it contains payload that is future compatiable. It means payload can be dynamic and can be extended for future reference. **::uid::** is an optional delimeter which if present along with **optionaluid** allows the proof to be uniquely different. 25 | 26 | 4. `thegraph` - Notification can be triggered through subgraph. They need to call addSubgraph function from EPNS Core Contract to add the subgraph. The Push Node will pick up the same, verification proof of the same consist of - 27 | 28 | - `GraphId` - This will be the id of subgraph. It is usually represented as `githubid/subgraph name` e.g - epns/epnssubgraph. 29 | 30 | - `notification number[counter]` - It will keep the count of Notifications and will process in a successive manner 31 | 32 | - `::uid::optionaluid` - **::uid** is an optional delimeter which if present along with **optionaluid** allows the proof to be uniquely different. 33 | 34 | ### Examples 35 | 36 | * `Transaction hash` - This signifies the verification from the on-chain, currently Ethereum and Polygon are supported networks and it can be verified by resolving the transaction hash from the respective chains and make sure that identity is present in the block. The payload either can be fetched from the events, add route or graph. This can be the scenarios - 37 | 38 | 1. For Identity 0 39 | 40 | ``` 41 | { 42 | "verificationProof":"eip155::", 43 | "channel": "0xd8634c39bbfd4033c0d3289c4515275102423681", 44 | "recipient": "0xd8634c39bbfd4033c0d3289c4515275102423681", 45 | "source": "ETH_TEST_GOERLI or POLYGON_TEST_MUMBAI or ETH_MAINNET" 46 | "identity": "0+++<body>" 47 | } 48 | ``` 49 | 2. For Identity 1 50 | 51 | ``` 52 | { 53 | "verificationProof":"eip155:<chainId>:<TX-Hash>", 54 | "channel": "0xd8634c39bbfd4033c0d3289c4515275102423681", 55 | "recipient": "0xd8634c39bbfd4033c0d3289c4515275102423681", 56 | "source": "ETH_TEST_GOERLI or POLYGON_TEST_MUMBAI or ETH_MAINNET" 57 | "identity": "1+<IPFS-HASH>" 58 | } 59 | ``` 60 | 61 | 3. For Identity 3 62 | 63 | ``` 64 | { 65 | "verificationProof":"eip155:<chainId>:<TX-Hash>", 66 | "channel": "0xd8634c39bbfd4033c0d3289c4515275102423681", 67 | "recipient": "0xd8634c39bbfd4033c0d3289c4515275102423681", 68 | "source": "THE_GRAPH", 69 | "identity": "3+graph:<subgraph-id>+<notification number>" 70 | } 71 | ``` 72 | 73 | 4. For Identity 2 74 | 75 | ``` 76 | { 77 | "verificationProof":"eip155:<chainId>:<TX-Hash>", 78 | "channel": "0xD8634C39BBFd4033c0d3289C4515275102423681", 79 | "recipient": "0xD8634C39BBFd4033c0d3289C4515275102423681", 80 | "source": "ETH_TEST_GOERLI or POLYGON_TEST_MUMBAI or ETH_MAINNET", 81 | "identity": "2+<Payload-in-form-of-string>", 82 | } 83 | ``` 84 | 85 | * `EIP-712` - This signifies the verification from the off-chain, the verification is done through EIP-712 based signature. 86 | 87 | > `EIP-712v1` - eip712v1:<Proof>, it contains fully loaded old payload. This is present to provide backward compatibility. 88 | 89 | 1. eip-712v1 has limitation to support only completed old payload which include all the params of the payload which are part of notification, data and recepients. As the identity formats like 0,1 and 3 have single string payload that's the reason only identity 2 is compatiable with eip-712v1. 90 | To overcome this limitation eip-712v2 is identity idependednt. 91 | 92 | ``` 93 | { 94 | "verificationProof": "eip712v1:<Proof>", 95 | "channel": "0xD8634C39BBFd4033c0d3289C4515275102423681", 96 | "recipient": "0xD8634C39BBFd4033c0d3289C4515275102423681", 97 | "source": "ETH_TEST_GOERLI or POLYGON_TEST_MUMBAI or ETH_MAINNET", 98 | "identity": "2+<Payload-in-form-of-string>", 99 | } 100 | ``` 101 | 102 | > `EIP-712v2` - eip712v2:\<Proof>, it contains payload that is future compatiable. It means payload can be dynamic and can be extended for future reference. 103 | 104 | 1. 105 | 106 | ``` 107 | { 108 | "verificationProof":"eip712v2:<Proof>", 109 | "channel": "0xd8634c39bbfd4033c0d3289c4515275102423681", 110 | "recipient": "0xd8634c39bbfd4033c0d3289c4515275102423681", 111 | "source": "ETH_TEST_GOERLI or POLYGON_TEST_MUMBAI or ETH_MAINNET", 112 | "identity": "0+<Notification-Payload-Type>+<Title>+<body>" 113 | } 114 | ``` 115 | 116 | 2. 117 | 118 | ``` 119 | { 120 | "verificationProof":"eip712v2:<Proof>", 121 | "channel": "0xd8634c39bbfd4033c0d3289c4515275102423681", 122 | "recipient": "0xd8634c39bbfd4033c0d3289c4515275102423681", 123 | "source": "ETH_TEST_GOERLI or POLYGON_TEST_MUMBAI or ETH_MAINNET", 124 | "identity": "1+<IPFS-HASH>" 125 | } 126 | ``` 127 | 3. 128 | 129 | ``` 130 | { 131 | "verificationProof":"eip712v2:<Proof>", 132 | "channel": "0xd8634c39bbfd4033c0d3289c4515275102423681", 133 | "recipient": "0xd8634c39bbfd4033c0d3289c4515275102423681", 134 | "source": "THE_GRAPH", 135 | "identity": "3+graph:<subgraph-id>+<notification number>" 136 | } 137 | ``` 138 | 4. 139 | 140 | ``` 141 | { 142 | "verificationProof": "eip712v2:<Proof>", 143 | "channel": "0xD8634C39BBFd4033c0d3289C4515275102423681", 144 | "recipient": "0xD8634C39BBFd4033c0d3289C4515275102423681", 145 | "source": "ETH_TEST_GOERLI or POLYGON_TEST_MUMBAI or ETH_MAINNET", 146 | "identity": "2+<Payload-as-string>", 147 | } 148 | ``` 149 | 150 | 151 | 152 | * `The Graph` - Notification can be triggered through subgraph. They need to call addSubgraph function from EPNS Core Contract to add the subgraph. The Push Node will pick up the same, verification proof of the same consist of - 153 | 154 | - `GraphId` - This will be the id of subgraph. It is usually represented as `githubid/subgraph name` e.g - epns/epnssubgraph. 155 | 156 | - `notification number[counter]` - It will keep the count of Notifications and will process in a successive manner 157 | 158 | ``` 159 | { 160 | "verificationProof":`thegraph:<subgraph-id>+<notification number>`, 161 | "channel": "0xD8634C39BBFd4033c0d3289C4515275102423681", 162 | "recipient": "0xD8634C39BBFd4033c0d3289C4515275102423681", 163 | "source":'THE_GRAPH', 164 | "identity": `3+graph:<subgraph-id>+<notification number>`, 165 | } 166 | ``` 167 | -------------------------------------------------------------------------------- /definitions/Standard/PRC/Notification/Payload/README.md: -------------------------------------------------------------------------------- 1 | # About Notification Payload - Definitions / Specs 2 | ## What is Notifcation Payload? 3 | Each notification sent to the protocol is essentially a JSON payload, bytes data or hash / pointer of the JSON payload. The protocol distinguishes payloads content which will contain the content which needs to be displayed, rules to display / morph the content, the recipients for which the content is meant to be delivered to along with the encryption method used if the content is encrypted. 4 | 5 | <br> 6 | 7 | Notification payload type for Push is infinitely extensible and opens a huge range of possibilities including multi-factor authentication, payments, blacklisting address (Multi-sig contract as a channel with exchanges as their subscribers), etc. The data defined in the JSON payload they carry is used to interpret and extend that functionality. 8 | 9 | **Note** Due to Identity Type Minimal, it is recommended to not touch the order of invidual JSON object but add things right at the end to maintain compatibility. 10 | 11 | ## Specifications 12 | 13 | ``` 14 | { 15 | "notification": { 16 | "title": "The title of your message displayed on screen (50 Chars)", 17 | "body": "The intended message displayed on screen (180 Chars)" 18 | }, 19 | "data": { 20 | "type": "1" or "3" or "4", // 1 is broadcast, 3 is targetted, 4 is subset 21 | "sectype": null or [Encryption_Method], // for example: aes+eip85 22 | "asub": "encrypted by secret using sectype | [Optional] The subject of the message displayed inside app (80 Chars)", 23 | "amsg": "encrypted by secret using sectype | [Optional] The intended message displayed inside app (500 Chars)", 24 | "acta": "encrypted by secret using sectype | [Optional] The cta link parsed inside the app", 25 | "aimg": "encrypted by secret using sectype | [Optional] The image url which is shown inside the app", 26 | "etime": "[Optional] if given, notif will be deleted after this in epoch", 27 | "hidden" :"[Optional] if given, notif will not show in user feed", 28 | "additionalMeta": { 29 | "type": "contains uniform data identifying the kind of data present along with a version separated by `+`", 30 | "data": "conatins the metadata", 31 | "domain": "[Optional]" 32 | } 33 | }, 34 | "recipients": 0x0 for type 1, 0xtarget for type 3 or [ 35 | 0x1: null or [{ 36 | secret: [secret used to encrypt] 37 | }], 38 | 0x2: null or [{ 39 | secret: [secret used to encrypt] 40 | }], 41 | ... 42 | 0xn: null or [{ 43 | secret: [secret used to encrypt] 44 | }] for type 4 45 | } 46 | 47 | ``` 48 | <br> 49 | 50 | | Payload Variable | Description| 51 | |---|---| 52 | |**notification** | [Required] Represents the notification typically delivered on the home screen of the platform (mobile, tablet, web, extension, etc), the icon of the channel is automatically added to outline where the notification is coming from.| 53 | |**title** | [Required] The title of the message displayed on the screen, this differs from the data json because the title while transforming the payload can be different than the title presented. For example, secret notification title are always transformed to say Channel has sent you a secret notification. | 54 | |**body** | [Required] The body of the message displayed on the screen, this differs from the data json because the title while transforming the payload can be different than the title presented. For example, secret notification body are always transformed to say Please open the dApp / app to view your notification.| 55 | |**data** | [Optional] The data field present here forms the visual feedBox for the user. Indicates the data field the payload will carry. This allows the notification to transform according to the payload type and the content defined on the platform frontend (ie: app, dApp, wallet, etc). | 56 | |**type** | [Required] Each payload has a type which tells how the data should be interpreted, this type is mirrored on the protocol function call as well. | 57 | |**sectype** | [Required] is the encryption technique used for the secret/encrypted notification. In open notifs it can be entered null.| 58 | |**asub** | [Optional] is the subject shown in the feed item.| 59 | |**amsg** | [Optional] is the message shown in the feed item, has rich text formatting.| 60 | |**acta** | [Optional] is the call to action of that feed item.| 61 | |**aimg** | [Optional] is the image shown in the feed item, this field is also capable of carrying youtube links.| 62 | |**etime** | [Optional] if given, notif will be deleted after this in epoch| 63 | |**hidden** | [Optional] If given, notif wont be shown in the feeds 64 | |**additionalMeta**| [Optional] Contains additional meta data to give a more personalised and contextual data 65 | |**type**| contains uniform data identifying the kind of data present along with a version separated by `+`. 66 | |**data**| conatins the metadata. 67 | |**domain**| [Optional] conatins details about the entity for which the `additionalMeta` is defined. 68 | |**recipients** | [required] Recipents address needs to be defined depending on the payload type, if 0x00 is provided it will represents all the subscribers of the channeland in the case of secret payload each subscriber address will be mapped with the secret.| 69 | |**secret** | [Optional] is required to encryption and decryption of payload data, this will be mappeed with user address as key value pair.| 70 | 71 | 72 | ### Examples 73 | ## Standard Payload - 74 | 75 | Notification payload type for Push is infinitely extensible and opens a huge range of possibilities including multi-factor authentication, payments, blacklisting address (Multi-sig contract as a channel with exchanges as their subscribers), etc. The data defined in the JSON payload they carry is used to interpret and extend that functionality. 76 | 77 | ``` 78 | { 79 | "notification": { 80 | "title": "The title of your message displayed on screen (50 Chars)", 81 | "body": "The intended message displayed on screen (180 Chars)" 82 | }, 83 | "data": { 84 | "type": "1" or "3" or "4", // 1 is broadcast, 3 is targetted, 4 is subset 85 | "sectype": null or [Encryption_Method] // for example: aes+eip85 86 | "asub": "encrypted by secret using sectype | [Optional] The subject of the message displayed inside app (80 Chars)", 87 | "amsg": "encrypted by secret using sectype | [Optional] The intended message displayed inside app (500 Chars)", 88 | "acta": "encrypted by secret using sectype | [Optional] The cta link parsed inside the app", 89 | "aimg": "encrypted by secret using sectype | [Optional] The image url which is shown inside the app", 90 | "etime": "[Optional] if given, notif will be deleted after this in epoch" 91 | "hidden" :"[Optional] if given, notif will not show in user feed" 92 | }, 93 | "recipients": 0x0 for type 1, 0xtarget for type 3 or [ 94 | 0x1: null or [{ 95 | secret: [secret used to encrypt] 96 | }], 97 | 0x2: null or [{ 98 | secret: [secret used to encrypt] 99 | }], 100 | ... 101 | 0xn: null or [{ 102 | secret: [secret used to encrypt] 103 | }] for type 4 104 | } 105 | 106 | ``` 107 | 108 | ### Reference Implementation 109 | 110 | ##### **Targetted Payload** :arrow_right: 111 | ``` 112 | { 113 | "notification": { 114 | "title": "The title of your message displayed on screen (50 Chars)", 115 | "body": "The intended message displayed on screen (180 Chars)" 116 | }, 117 | "data": { 118 | "type": "3" 119 | "sectype": null 120 | "asub": "[Optional] The subject of the message displayed inside app (80 Chars)", 121 | "amsg": "[Optional] The intended message displayed inside app (500 Chars)", 122 | "acta": "[Optional] The cta link parsed inside the app", 123 | "aimg": "[Optional] The image url which is shown inside the app", 124 | "etime": "[Optional] if given, notif will be deleted after this in epoch" 125 | "hidden" :"[Optional] if given, notif will not show in user feed" 126 | }, 127 | "recipients": { 0xtarget : null } 128 | } 129 | ``` 130 | <br> 131 | 132 | ##### **Brodcast Payload** :arrow_right: 133 | 134 | ``` 135 | { 136 | "notification": { 137 | "title": "The title of your message displayed on screen (50 Chars)", 138 | "body": "The intended message displayed on screen (180 Chars)" 139 | }, 140 | "data": { 141 | "type": "1" 142 | "sectype": null 143 | "asub": "[Optional] The subject of the message displayed inside app (80 Chars)", 144 | "amsg": "[Optional] The intended message displayed inside app (500 Chars)", 145 | "acta": "[Optional] The cta link parsed inside the app", 146 | "aimg": "[Optional] The image url which is shown inside the app", 147 | "etime": "[Optional] if given, notif will be deleted after this in epoch" 148 | "hidden" :"[Optional] if given, notif will not show in user feed" 149 | }, 150 | "recipients": 0x0 151 | } 152 | 153 | ``` 154 | <br> 155 | 156 | ##### **Subset Payload** :arrow_right: 157 | 158 | ``` 159 | { 160 | "notification": { 161 | "title": "The title of your message displayed on screen (50 Chars)", 162 | "body": "The intended message displayed on screen (180 Chars)" 163 | }, 164 | "data": { 165 | "type": "4" 166 | "sectype": null 167 | "asub": "[Optional] The subject of the message displayed inside app (80 Chars)", 168 | "amsg": "[Optional] The intended message displayed inside app (500 Chars)", 169 | "acta": "[Optional] The cta link parsed inside the app", 170 | "aimg": "[Optional] The image url which is shown inside the app", 171 | "etime": "[Optional] if given, notif will be deleted after this in epoch" 172 | "hidden" :"[Optional] if given, notif will not show in user feed" 173 | }, 174 | "recipients": [ 175 | 0x1: null, 176 | 0x2: null, 177 | ... 178 | 0xn: null 179 | } 180 | 181 | ``` 182 | <br> 183 | 184 | ##### **Secret Payload** :arrow_right: 185 | 186 | ``` 187 | { 188 | "notification": { 189 | "title": "The title of your message displayed on screen (50 Chars)", 190 | "body": "The intended message displayed on screen (180 Chars)" 191 | }, 192 | "data": { 193 | "type": "4" 194 | "sectype": "aes+eip85" 195 | "asub": "encrypted by secret using sectype | [Optional] The subject of the message displayed inside app (80 Chars)", 196 | "amsg": "encrypted by secret using sectype | [Optional] The intended message displayed inside app (500 Chars)", 197 | "acta": "encrypted by secret using sectype | [Optional] The cta link parsed inside the app", 198 | "aimg": "encrypted by secret using sectype | [Optional] The image url which is shown inside the app", 199 | "etime": "[Optional] if given, notif will be deleted after this in epoch" 200 | "hidden" :"[Optional] if given, notif will not show in user feed" 201 | }, 202 | "recipients": [ 203 | 0x1:[{ 204 | secret: [secret used to encrypt] 205 | }], 206 | 0x2: [{ 207 | secret: [secret used to encrypt] 208 | }], 209 | ... 210 | 0xn: [{ 211 | secret: [secret used to encrypt] 212 | }] 213 | ] 214 | } 215 | 216 | ``` 217 | <br> 218 | 219 | ##### **Additional Meta Payload** :arrow_right: 220 | 221 | ```ts 222 | { 223 | "data": { 224 | "acta": "", 225 | "aimg": "", 226 | "amsg": "VideoCall", 227 | "asub": "VideoCall", 228 | "type": "3", 229 | "additionalMeta": { 230 | "type": "1+1", // <type>+<version> 231 | "data": '{"chatId":"c04c90ba7057c10c59925f36ec7952bd7e7f9436517977115da2bdcd5b28ec30","status":4,"senderAddress":"0x842a882b4c054801F06d52181231A77e467BE41f","signalingData":null,"recipientAddress":"0x459AB94401A00AdD8C6e230596Bde9B2F113E8BE"}', 232 | "domain": "push.org" // optional 233 | } 234 | }, 235 | "recipients": "0x459AB94401A00AdD8C6e230596Bde9B2F113E8BE", 236 | "notification": { 237 | "body": "Video Call from 0x842a882b4c054801F06d52181231A77e467BE41f", 238 | "title": "Video Call from 0x842a882b4c054801F06d52181231A77e467BE41f" 239 | } 240 | } 241 | ``` -------------------------------------------------------------------------------- /PIPs/consideration/pip-1-workflow-index.md: -------------------------------------------------------------------------------- 1 | | pip | title | status | type | author | created | 2 | |---|---|---|---|---|---| 3 | | 1 | PIP Purpose and Guidelines | Living | Process | Harsh Rajat <Harsh@epns.io>, Pranshu Rastogi <Pranshu@epns.io> | 2022-08-07 | 4 | 5 | # What is an PIP? 6 | 7 | PIP stands for PUSH Improvement Proposal. A PIP is a design document providing information to the Push community, or describing a new feature, processes or environment. The PIP should provide a concise technical specification of the feature and a rationale for the feature. The PIP author is responsible for building consensus within the community and documenting dissenting opinions. 8 | 9 | # PIP Rationale 10 | 11 | We intend PIPs to be the primary mechanisms for proposing new features, for collecting community technical input on an issue, and for documenting the design decisions that have gone into Push ecosystem. Because the PIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal. 12 | 13 | For Push community, PIPs are a convenient way to track the progress of their implementation. Ideally each implementation maintainer would list the PIPs that they have implemented. This will give end users a convenient way to know the current status of a given implementation or library. 14 | 15 | # Understanding PIP Types, Categories, Subcategories and Niche 16 | 17 | PIP proposals are classified into **type** which can then optionally be categorized into **category** -> **subcategory** -> **niche**. Type describes the high level standard which the PIP wants to address. Category describes the type drilldown which a specific PIP is created to address. Subcategory dives deeper into a particular category while niche describes the low level component of that subcategory. 18 | 19 | Please see [definitions](../../definitions) to learn more about them. 20 | 21 | ### Type 22 | 23 | Type decribes the high level standard which the PIP wants to improve. 24 | 25 | 1. **Standard** PIP describes any change that affects most or all Push protocol implementations, such as changes in core, interface, networking or application level standards. 26 | 27 | 2. **Meta** PIP describes a process surrounding Push or proposes a change to (or an event in) a process. Process PIPs are like Standards Track PIPs but apply to areas other than the Push protocol itself. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Push development. Any meta-PIP is also considered a Process PIP. 28 | 29 | 3. **Informational** PIP provides general guidelines or information to the PUSH community, but does not propose a new feature. Informational PIPs do not necessarily represent a PUSH community consensus or recommendation, so users and implementors are free to ignore Informational PIPs or follow their advice. 30 | 31 | ### Category 32 | 33 | Categories are only required for **Standard** Type PIPs and define the branch of PUSH Protocol which it targets to improve. 34 | 35 | 1. **Core**: includes improvements for changes in the network including incentives and rewards, syncing, consensus mechanism changes and processes that might require fork cause of breaking changes. 36 | 37 | 2. **Interface**: includes improvements around client API/RPC specifications and standards, and also certain language-level standards that may help in standardizing interfacing. 38 | 39 | 3. **Networking**: includes networking specifications and proposals around how push nodes communicate and interoperate. 40 | 41 | 4. **PRC**: Signifies, application-level standards and conventions, including verification, identity, payloads, content markdown for notifications, chats or any communication standard that is added. 42 | 43 | ### Subcategory 44 | 45 | Subcategory are optional and mainly required for **PRC** category, they define the particular topic within the Category. 46 | 47 | 1. **Notification**: Available under Standard > PRC > Notification which addresses specs, proposals and improvements for everything related to push notification protocol. 48 | 49 | 2. **Chat**: Available under Standard > PRC > Chat which addresses spec, proposals and improvements for everything related to push chat protocol. 50 | 51 | ### Niche 52 | 53 | Niche are optional and are required in some **Subcateory** sections. they define the specific low level funcationality that needs to be changed, improved or addressed. 54 | 55 | For Subcategory: **Nofification** 56 | 57 | 1. **Verification**: Addresses different types of verifications that can be used while sending a notification to Push node. 58 | 59 | 2. **Identity**: Identitifies from where a notification payload is coming along with what is the storage mode, protocol to transform it to json payload, etc. 60 | 61 | 3. **payload**: Addresses what payload of the notification should contain including the way notification should be encrypted, things payload can carry and how they transform and the recipients for which it is intended to be. 62 | 63 | 4. **content**: Defines how content inside the notfication can be displayed, mostly markdown for title and the body of notification. 64 | 65 | For Subcategory: **Chat** 66 | 67 | {TBD} 68 | 69 | ### Important 70 | 71 | It is highly recommended that a single PIP contain a single key proposal or new idea. The more focused the PIP, the more successful it tends to be. e.g. - A typo or single change in payloads doesn't require PIP. It should be contributing as major improvement or change multiple clients. 72 | 73 | A PIP must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly. 74 | 75 | # PIP Process 76 | 77 | The following is the standardization process for all Push Protocol Standards Improvement Proposals: 78 | 79 | ![Proposal Process](../../assets/template/pip_lifecycle.png) 80 | 81 | **Idea** - An idea that is pre-draft. It can be done over [Push Discord](https://discord.com/invite/YVPB99F9W5) or [Push Forum](https://gov.push.org/c/pip/29) . 82 | 83 | **Draft** - The first formally tracked stage of a proposal in development. To create draft, you should submit PR request against an issue in 84 | `PIPs` repository. Make sure, draft should be in respective payload standards subdirectory. 85 | 86 | **Last Call** - This is the final review window for an PIP before moving to Final. A PIP editor will assign Last Call status and set a review end date (last-call-deadline), typically 14 days later. 87 | 88 | If this period results in necessary normative changes it will revert the PIP to Review. 89 | 90 | **Review** - An Author marks a proposal as ready for and requesting Peer Review. This is the final window for proposal before moving to final. 91 | 92 | **Final** - This represents the final standard. A Final proposal exists in a state of finality and should only be updated to correct errata and add non-normative clarifications. 93 | 94 | **Stagnant** - Any proposal in Draft or Review or Last Call if inactive for a period of 4 months or greater is moved to Stale. The proposal may be resurrected from this state by Authors or Editors through moving it back to Draft or it's earlier status. If not resurrected, a proposal may stay forever in this status. 95 | 96 | **Withdrawn** - The Author(s) have withdrawn the proposed submission. This state has finality and can no longer be resurrected using this proposal number. If the idea is pursued at later date it is considered a new proposal. 97 | 98 | **Living** - A special status for PIPs that are designed to be continually updated and not reach a state of finality. This includes most notably PIP-1. 99 | 100 | ## What belongs in a successful Push Protocol Standards Improvement Proposal? 101 | 102 | Each Proposal should have the following parts: 103 | 104 | * **Abstract** - Abstract is a multi-sentence (short paragraph) technical summary. This should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does. 105 | 106 | * **Motivation** - A motivation section is critical for Proposals that want to change or amend the Standards. It should clearly explain why the existing Standard specification is inadequate to address the problem that the proposed solves. Proposals without sufficient motivation may be rejected outright. 107 | 108 | * **Specification** - The technical specification should describe the syntax and semantics of any new feature. 109 | 110 | * **Rationale** (*optional)- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale should discuss important objections or concerns raised during discussion around the Proposal. 111 | 112 | * **Reference Implementation** (*Optional)- An optional section that contains a reference/example implementation that people can use to assist in understanding or implementing this specification. 113 | 114 | # PIP Formats and Templates - 115 | 116 | PIPs should be written in [markdown](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) format. There is a [template](../../pip-template.md) to follow. 117 | 118 | # Linking to External Resources 119 | 120 | Links to external resources SHOULD NOT be included. External resources may disappear, move, or change unexpectedly. 121 | 122 | # Linking to other PIPs 123 | 124 | References to other PIPs should follow the format PIP-N where N is the PIP number you are referring to. Each PIP that is referenced in an PIP MUST be accompanied by a relative markdown link the first time it is referenced, and MAY be accompanied by a link on subsequent references. The link MUST always be done via relative paths so that the links work in this GitHub repository, forks of this repository, the main PIPs site, mirrors of the main PIP site, etc. For example, you would link to this PIP with [PIP-1](./pip-1-workflow-index.md). 125 | 126 | # Auxiliary Files 127 | 128 | Images, diagrams and auxiliary files should be included in a subdirectory of the assets folder for that EIP as follows: assets/pip-N (where N is to be replaced with the PIP number). When linking to an image in the PIP, use relative links such as ../assets/pip-1/image.png. 129 | 130 | # Transferring PIP Ownership 131 | 132 | It occasionally becomes necessary to transfer ownership of PIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred PIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the PIP process, or has fallen off the face of the 'net (i.e. is unreachable or isn't responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the PIP. We try to build consensus around an PIP, but if that's not possible, you can always submit a competing PIP. 133 | 134 | If you are interested in assuming ownership of an PIP, send a message asking to take over, addressed to both the original author and the PIP editor. If the original author doesn't respond to the email in a timely manner, the PIP editor will make a unilateral decision (it's not like such decisions can't be reversed :)). 135 | 136 | # PIP Editors 137 | 138 | The current PIP editors are - 139 | 140 | * Harsh Rajat [@harshrajat](https://twitter.com/harshrajat) 141 | * Pranshu Rastogi [@pranshu3196](https://twitter.com/pranshu3196) 142 | 143 | # PIP Editor Responsibilities 144 | 145 | For each new PIP that comes in, an editor does the following: 146 | 147 | ``` 148 | * Read the PIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to get to final status. 149 | * The title should accurately describe the content. 150 | * Check the PIP for language (spelling, grammar, sentence structure, etc.), markup (GitHub flavored Markdown), code style 151 | * If the PIP isn't ready, the editor will send it back to the author for revision, with specific instructions. 152 | ``` 153 | 154 | Once the PIP is ready for the repository, the PIP editor will: 155 | 156 | ``` 157 | * Assign an PIP number (generally the PR number, but the decision is with the editors) 158 | * Merge the corresponding pull request 159 | * Send a message back to the PIP author with the next step. 160 | * The PIP editors monitor PIP changes, and correct any structure, grammar, spelling, or markup mistakes we see. 161 | ``` 162 | 163 | # History 164 | 165 | This document was derived heavily from [Ethereum's EIP-1](https://eips.ethereum.org/EIPS/eip-1), which was derived heavily from [Bitcoin's BIP-0001](https://github.com/bitcoin/bips) written by Amir Taaki which in turn was derived from [Python's PEP-0001](https://www.python.org/dev/peps/). The bulk of the text was copied from [Ethereum's EIP-1] and modified as necessary. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, 166 | they are not responsible for its use in the Push Improvement Proposals (PIPs), and should not be bothered with technical questions specific to **Push**, **Push Protocol** or the **PIP**. Please direct all comments to the [PIP editors](https://github.com/ethereum-push-notification-service/PIPs#pips-standards-editors). 167 | -------------------------------------------------------------------------------- /definitions/Standard/PRC/Chat/Verification/User/README.md: -------------------------------------------------------------------------------- 1 | # About Verification - Definition / Specs 2 | 3 | ## What is Verification Proof? 4 | 5 | Verification Proof is the outermost composable block that is sent along when updating the state to help the Push Nodes validate the sender and the content of the request, along with any other validation that might be required. Verification proofs differ based on the state change. In the case of creating users, usually carry eip191 proofs. These proofs allow for a flexible and composable structure to validate and process user creation requests on the Push Nodes. 6 | 7 | ## Specifications 8 | 9 | | Verification Proof | Definition | Proof of Verification | 10 | | ------------------ | ---------------------------------------------------------------------- | -------------------------------------------------------- | 11 | | eip712v2:signature | Verification proof generated from off-chain EIP-712 signing of payload | The type is proven by verifying the signature of eip712. | 12 | | eip191:signature | Verification proof generated from off-chain EIP-191 signing of payload | The type is proven by verifying the signature of eip191. | 13 | 14 | 1. `eip712v2:signature` - Verification proof generated from off-chain EIP-712 signing of payload. 15 | 16 | When creating a user, for this verification proof we take the SHA-256 hash of the below object then eip712 sign it. 17 | 18 | ```typescript 19 | { 20 | caip10: string, 21 | did: string, 22 | publickey: string, 23 | encryptedprivatekey: string, 24 | encryptionType: string, 25 | name: string, 26 | encryptedPassword: string, 27 | nftOwner: string 28 | } 29 | ``` 30 | 31 | 2. `eip191:signature` - Verification proof generated from off-chain EIP-191 signing of payload. 32 | 33 | When creating a user, for this verification proof, we take the SHA-256 hash of the below object then eip191 sign it. 34 | 35 | ```typescript 36 | { 37 | caip10: string, 38 | did: string, 39 | publickey: string, 40 | encryptedprivatekey: string, 41 | encryptionType: string, 42 | name: string, 43 | encryptedPassword: string, 44 | nftOwner: string 45 | } 46 | ``` 47 | 48 | ### Examples 49 | 50 | 1. `eip712v2:signature` 51 | 52 | For generating this verification proof, we first generate the JSON below: 53 | 54 | ```json 55 | { 56 | "caip10": "eip155:0xFad30edeBA90EC446eC4148E74101C37b3bCc2E0", 57 | "did": "eip155:0xFad30edeBA90EC446eC4148E74101C37b3bCc2E0", 58 | "publicKey": "-----BEGIN PGP PUBLIC KEY BLOCK-----\n\nxsBNBGRYseABCACzV4wPnoFKqn49R1ASznhsRqz+13wRHUBWA2N2wpuJ9wBp\nfDaGm8KAr0M1lC8YW3pM5EB5dbgqYie54lV63Ghg5Fhu0b7puTL1LgY3lUdN\nyFjsz6I6KbKYWdmpKjcQ3skaSqoBNQLIYVKTk2w4yzlrn/VCXitnUAZDHpL9\nviwU2bS84CddUR10vXEQZ/sqeZT0cpJfJdsIdXeLLzFmiDAlCg1xXxalpl+X\nUlAGdC6s+IYbq6cd/GI7WVxUC+1WzJGZ7VMMODK+/V11ssfdLLwaYftKaNpF\nGthJ6JSE2W0Q7rx1yL1TH27j8SFmsIfvzMIdqA5kpTdbJ0QPCUDUHel5ABEB\nAAHNAMLAigQQAQgAPgWCZFix4AQLCQcICZANc5g1cHcBMgMVCAoEFgACAQIZ\nAQKbAwIeARYhBE3kIxo8N7eBrLPSVA1zmDVwdwEyAADlxwgAg+3FcUDHoyrU\nWQteq5UNmYLJrlEgY8lBNiWZat29eDP36cKs7l93jcHjN8xjUGde6jbFt2vT\nAq5ZKQ8Y3qb+HNLpxj0Ye+Qb8Iq8De6YNDMyfV//tkPL0z5PRc9+TMQA5QP0\np8wmAFdV4YjGj1/3vVJlwfgpk/L7bZLpbVhaqWN6xY9dULWGV1HpR0DXtI4N\nPd4WKtly5o7UVFsVzYObwBfksbkoLPOPSrunHgjR++i/pU3MtHXXGVStT8yb\nJSIcEwKXYVt6WWrX8nT6mXXhdHfyDG0jNqZDIiXuLCF+JpMLAExH4XOMVKd6\n9avMfFE3TmKJnF7v31BKBKZhamuTpM7ATQRkWLHgAQgAxEdWqtNLHYMGS/Gt\nf6gAXbH2GfHrWNwWT1D6i8G2wjsmTfrDHiQN3T/XRbfJKTZTt6dAnemWRxX9\no2LnJnS4wkyGYgwziVPeQIZgo0BB+yq2kZgKkGopkzqxErP+aAshF1l+HeCT\nkPBnfSkoCgRI0OH6orWLYEtFLfxpPzQXnzx6Mxl1hQPFKpdJh8lC9aPay8qW\nEKfF5BDGRXkLP1cCGIvGeLzTSvWCcLZWhhCdi94TQ4MuujWhTtoiQF6a83NT\nxx7cF+gVlDDeHD5FETn5drJQe9mM8ONXUEUNTLnorJzX8ggb0sYgu/kmyPRX\ntNKcGgJe2b/uNx/dQ8iBlaHyqwARAQABwsB2BBgBCAAqBYJkWLHgCZANc5g1\ncHcBMgKbDBYhBE3kIxo8N7eBrLPSVA1zmDVwdwEyAAB6FQgAiDWd1p0cBL8z\nCsk721ci9g3pIEe9vbp7Z5vyxcpF3Vmc+bO2zAg7ENIQgvLrkvrYe4QRg98T\nG8yXkRIn5sK2jvQtKzu4fCY9nImaEJGrjO3Dvz3oMhc0NiM9wTFjz/5TxTQX\nEO7pLS0gpHeWlhvKzw++wMqm2Nj9XlIVUVXriXqUyMvxedpRNA3EipdP1tjC\nC4d1erKn5b6ahnMHQkHFARCR+E60ZH3HyKiqDkNqGp9bK6sN2PbjMEqbugzw\nmK9gvA3uw0UfNG0F8HxHey5ogi+iXKAfAN98LMgyoYLQzmzxLmt6XQVTkLU1\nn25fX3HDl4lC2pXCK44AtEwJyykAWg==\n=QJRV\n-----END PGP PUBLIC KEY BLOCK-----\n", 59 | "encryptedPrivateKey": "{\"ciphertext\":\"7daaeb771050f7905c60905a14fda0070c6adf5dd34b9bc614234d23335e52c2d002da8ff6f54f99b622aaed140d5d0d7600d53bf32cf1088a6acf6732aa61e7d0ebe8419d019d77b9b544c77ad5dfe7777a8fdf5b552d1b7c4b07d43d5f068199066a0c20807dd56aa5cb4e4b2c12b274bd041ca8b86ab6fd48573740d75bb0527e30c97534081146773da68d34815d456f008d527078d837bed47d6b3198a704b302363dd07897d6701183dfcfd5a003f74975db85b9f3e6ce1f5b065408d64c43f92b95f57901f0b259aae49070a3b6d71cc21d11a10d741e175b9971cdb14ff78028d5f80bcf23f0c68dc4c40d8923ae8fd2c010435917f2a9d683cab4e38f56781c48f20d0146414a2dbecb868659b38ac2469b60ec48156c54a48916438d971c8ce981b9ee462986219c7139092f77c1c06dc355e2feb7a5cf5456887965a2d51c579657d209930fc55a46b283ed171ef93f69e011bbb4abf9df5e0734d9aa5f5e2e489f92c39606081cfbf84e8295e28cfe1edeaab9ccf7d64927c8821b0315b81ea89f4b215f19677abe5062a24f1c33ce99dc3b690b9df9c0765e073fc631501dcca374a45d42120b657199f2dd1417371b5e8a9b10b6535949b398c2d259160c5066eeefd121c706b161f810b8ce050a7fe50a6897dcdbf162ba0dac07c182bd8eda66be77ac8ac1b42f273b6b8d63c1510533375fab6a2f2613cd977507022668e984bcb393f017178f28b47ce2cba11f5b117cdf23e1a38dec08fb69942c28f61b524efe877e9b9ee91a807822168fe340c9bcfbc3dea18c3b04dd48902994bc015b4227199aa7ae89aee3a771b4a28e5cf0c3cf048095e47ddb8fb91aa50bc4265d7dbe18d263d342f290a4417ed578840620db447f427fab9732056d4348acc6baadde64ccdd94f61205163f736480dd0c595cce23c2762b6a5fe1580caa4ff866aa085068879287814be973613c73d00e299be28d3106e301878c15bce8237148cb68df3b3d24a0aac6d14bbfd64f78fcd93051ec898fe80ca01dc85e51778562ffd1e7c74cab09a2d1f9c54b8b588fc6a06db81cfdd26fb791849f38bbdf085221ed3d8b78cac6022371140c3f7f4541c557930dd4dcd2f02357f95574bffd0019234d8c88aed37161dd0c601564591f92f464af128ee3460b9ce970fcc9295a91eb1ac7db97b2396392181693eae1f556b24867575a7d0212591a1c467c85f62736282843367456994a06f198d439f5eca24558b3647bad1ebd4b1aa75535866573195454a5581521c5f0117dc34f38f10a9abcace07ea77d5f611d318f3de1de0327251121e2482e8f9cf527165b5ac4c9daf1d748ba79540cbd0ba0e4c5806cab3496e385235be8653ad271c31f8ac9d48fabe676c81a6be1bf6a239966da88db2c5a17839891c0d2040ed7a2cd9cb205e9c26e7fd6c819277146e981335b6dac005a5f00df5a443e15e750d58f97f5610fc3f6c94e397ad7f4ac174de62995c4bfd41881fa2e35ad354e726695c3bb4fbfb1fcc0acb7aa26b2a8b0570b2ed0d3603a71d2bd69683e43620df8041d9ceaff5131792bef57ff7c4d1239508cede2dd968e616a2d4e457090eede7cbb77b49185a472b725d2c9cafb85ff363fd70a454f9e9bf861e28e3689a3432c6318ed380b38f1f03170f0ef5310e2839d4e3181341ce26f1343486a73e4a16c77e25569dcb5f2046915311ba1dd7a3d6cf892caf342b613c6d1555c32589a32f676f30adef1f281449bf4246b29d922210ec6b048998104ccb9e242b46a0f47b880c7cffa0f6dd4e4408391120d92dab5bd6c3816156d5eaed03e0e34bf662907547d809401a25c597c293e90251ae714f9c8f84c6e6ee419c5963faaec0445c63c1fa43352a13a55afb5a0c8dcdeff1f36e49fdc479bfc96138a40b5b04cec938ef628839e4d02fd3022be59c2d1723362d19c02f9a24ff34fe1cdf9705b8201751470afc91143fa68d9f12780e4acdfc99a2c5f284e6c6ae1af58411f4df8b394e684e531adfa4ac2dcc2d179481729601adae8aa8eb0da030ac899cd49e6e027ebd068c8d0e2b7373c9ac3cb704fb6bfa3085f4ef526528fbdc4e8cf4d9deadd2aca49316f4d27eb4d5c62ee34475dea36b17ff1cabf025eb6b1909f7b9a746da3f66f856dd579edde9115fed1a0747fb7524cf7a8ba0265a520c6b237d28f22727472b467e7b75bb8b97055fe02bf5428d6ee8602385ae708abfef17d8786364ee4bcfd5c6cd639e7e1874b4aca8a23bb62e556e1af86a0b5a8c8f9d2f6cc50e294737185e7d60f6707f61f3d66ac5a1407cbf83a8be221edd18f7c2a28c889c98efd8874a32f18775d0e97ebe0433b9e6843be80c10e1a760da681dc788740b9a3be5611c730d2d81529e0e903f5cbebd4137ea2f4c4b4a5f1477f7b0724110a5e289ff134565cf9578f1673bb397653b1312834a1eb641beca725d53929dfba39133b3c79dd049fd3f39ae3874656d1ca5820328afadcc08a77d2299aed0325796f31d934cec0a9cabd1e253a4ea161c594973a180113665a33c9d8e8b45057cabce4eaa9c680ff01ce94b0779cc1b52d9440326cc03cdf8d81fdbd878a2a47bc9b4a1ecdf38fd9e9665eac77a0a505c3fe1eb3f22bac6673529ef1763fbe2663c4ad21f9162840480852d476e5af70b87616dfdc6eb37bc1eed44828809d586d2fc640ac653e5ee7c3278ac3f6319efd48dc347693ee88130898e7c2eb43beaa878a50d30044042fd051658b03be83207dee36f2ce5d2e69dc3c0ccd5c13884b6e3ce2ebc772b98288a184dba5d366e834597ebf5b50c53308d5350e39053f3aa7aa3848abae0e865483e16efb8bce43705c1aeecd55a7aab572feed54586ecd75cfca30de77dc4392f6f1329ddf7c2b904e0037ba1df9fa353cfc452845bb44b1d6b5a573026f8db28ecabf3ab67df6db783c2f82b0570e0ccf0f4e5a093a66aa30550f47a27d488a56fb36697aff88eae85fd4ff03cb4c488587aba8436f93b3cbb95d7a45283f117fbc05a6238eabb4b8d7a308fe396e9b75d6a5fe3220d3e3b75531f7f299f45bad43691c6f3f76a1210146152ec5f8337a1268e11f989a4abc38a725ff1177229b8e78597906b5de2a018a3a34735e2efca8d9e16162309cd5942339f23daff8929ff9cea6241e3ca76dc651b6f4eda8427cf4365f12fdd6d20097e06358699610f71ce87d0f2efc89cdea694d543fa0df503141f8ff76ec7863427e8c16db78001ea976c720031473caf1de9c3f9eeb503abaf9f96f56de18ab8c00ad87555e00affcd256ad1828561559420bd2869edfb7116aa7e506a0de2b1d674ca4eb25c1226ee8f875e60f529f6bcd5dde626b14cd76576d67c454004739cd67fb1e97c17a9f791a037d702063a5ad25b0192c87c77dbc43f29f28ca221ff953dfc1d84ed02fa2799bacb5dab6ad835f89fe62efe6dc2cf82d96577cdff964aa5657e117c60bf1aa96188afaaac665d0fb61eff5f07e0cdc4020ba33cd9c46aa2b78f548478269f5a1063c48dce0a51627bfb1da0726030f860e8e63d46e09d2ae50860b13d540853967998fa128d912539f49d0aa1a1cf8719a401a3eac9383da8ab0bc04b0d0f9b055d2c4ff2c05aa2a1077e241bba92e0061f2e42a9b4af15a79a3ae299bf22b972716694bb66f6e257a37320c56c787eae73d9efb8ba557c5dc17808fd44b8b6830b270524a6a4d8abb95ff3d64431baa25480e7f9f224732dbc9485838a5e20c3bbcf0322acb1ea079ce116c189ed3dca6991cd880f1260f09a88684c2ed911ccac0ab6feb599fc86ef268a10d2e58a8d7c3c09a9a890dfe5e5632563b725f48cdcbe87238702ee059916c52327c43e8fc16f9f24c99baee16a346eb6ec891efe8846179f72056147ec9dfe944c5bb233965985c38bce5f6839e233c7c19233f2979d25df3d64daac19325a027d7cf8bdce8c4f756ce32b0aaf041bec5a2ea613488434a5040a13347b8648e38a3819a5930989bc43b18bf490f6d3295ff951b14d3afb9d09fa83ecba31fcb3e633b8bd0d380e097e4e45eb3d7894b6764e40e9a233c99a62a3de57b50443533b68d649cb7fa42c18e2241bee72d685ac93fbe4d3d1116d3f1973d113e1fee52d8c1fbf93dead7a3df8cb1d49aa6c9e834b5f465b84920b3c399d97fe30c4b45463d3b80d616efeea3377828358822987d82d4a4a73a8242731699e7de258abbce25af1d25837cefe41d5f6381007032ed845817ff9d71226032a4dbab7655b28f8343fc091644d65ebe31a4a6f0503ce7e21c2f25303613b03d9d930610f01dc40d597ee7af159ed150856c60d89717c5d33c9996dabbc05759a2f0e6a57d3140ed4e4bc890842e53597f33e956e82354e0132f47f1a09805f880333e4ffea0fc81fa8148ed530e2f5a2055b6680269b434186d8e757a5b7f53124b8e36f5e55fde382f02dafe7ee7e17e2eda31eefa4440786b9849b732a6ed3e451f917697943ad6cfbc1ede4ad902d4c900183620344fb7f00b013c800029c95e24121b40ace9a5dce983ea77965f2722dcb2828df94a2e21f9df2b205d47cc5399c5ec5e84d5e6aefeed606a4aa05b0ea6dd1bb2202905e437bcc3e049f98478f1814e3d76e07ba339b2cf033f6035444995c1dbb0854c6c1ba71ae2a42b28502a46741fded0b4c3837711c13a569129a8867e056e7c22723877921d509fd9314e5adc5f40aecaf500da64b2bff854e7548755edfc9794da2b62cbcdd24a4098bf95a3a97dafce543ab740328e92049feb4e6120b5677a2c68fdef03205e930fae9c283805f7c7d1f5700a69d65148572d401b2f158b0afac742ed0b4f8164fdd6ec80a172e76d1d5fb7f420216d55cca8dd11444e031486d48ef6ab33fb97e99b42bcd65137\",\"salt\":\"8ced948fe77075e789364c410f15e74d5ac1164b64dbc54ba40be9b18780f636\",\"nonce\":\"5e7706c9e812e36ec6806126\",\"version\":\"eip191-aes256-gcm-hkdf-sha256\",\"preKey\":\"26741dacd90412b1c276c80731ab61939be6211da8741aba9240db40a90f86df\"}", 60 | "encryptionType": "eip191-aes256-gcm-hkdf-sha256", 61 | "name": null, 62 | "encryptedPassword": null, 63 | "nftOwner": null 64 | } 65 | ``` 66 | 67 | The SHA-256 of the JSON below is: 68 | 69 | ``` 70 | f6c91236c48797deb2e330242862c510a0fc8dadd479041b7b507899d4ded90b 71 | ``` 72 | 73 | Then we take the EIP-712 signature of the hash above using a wallet with this private key: 74 | 75 | ``` 76 | 0x5c94c6cf5f338894339ee0cc4f60b02b493e9ee69d0a4c27c719d17d44cf3cc3 77 | ``` 78 | 79 | And we get the verification proof below: 80 | 81 | ``` 82 | eip712v2:0x78dfaf4f86d6a8583b61e5c1a193fd151bda74decf206e6d8f91d764109d2b0e0687f0c5c28c58d746e74edc6742626fea02c118b46a4b87f0d4835b9e1645471b 83 | ``` 84 | 85 | 86 | 2. `eip191:signature` 87 | 88 | For generating this verification proof, we first generate the JSON below: 89 | 90 | ```json 91 | { 92 | "caip10": "eip155:0x3E3D52D24b1D96cF275e4fd8bc4F5638Edd1fe51", 93 | "did": "eip155:0x3E3D52D24b1D96cF275e4fd8bc4F5638Edd1fe51", 94 | "publicKey": "{\"key\":\"-----BEGIN PGP PUBLIC KEY BLOCK-----\\n\\nxsBNBGRT92IBCADDYYObUwK+dPmGzzEZPBWhzAM/cznZyy3StJhaE7uFBXlP\\nktBsoDr9KYmoCmbqVw65Qpaire6x5Y1e/U60/BpFgTtxH/fCHGRAcmAcAf40\\n459hmfhX8g4U0zO/ShBV1Up+9bsRB1ZBiiKE8YtOeTF7UxIx32jhjmDLJfhj\\nivRxwUv7Q8L+tL7V+7TE/L8r8/msYk6Ex6RJVDkVf9OlSJ7kPbBypFbSRaFJ\\nd9DY/tVu5I6rPJMHkhdh4MIcCxxZKLnYcNG1YzE4QW7ZFBpJLzsGXMlMY7AI\\n4Wwx0nvfKTRCeFsrI9ZUDEu6gd0uU1+z9fHGHVW1uy2UIyQMKhFmJrtxABEB\\nAAHNAMLAigQQAQgAPgWCZFP3YgQLCQcICZAOd8K7O81EfwMVCAoEFgACAQIZ\\nAQKbAwIeARYhBKekDJE9u2pk4A+sHQ53wrs7zUR/AADmugf/eNvYR1CnFbbN\\nYGybgK4vIaJ4tB2PZyUvFUgFhiEtGbRezJtCIn4v4QEGIKvvmxca5GjzVUy4\\ntaAVP3NqX+eCfJXONdhixn3F2YNDDSju1v0Z1XIrntPP7PGflNwx/HDXq1dP\\nKAYVz/XhlJlOCLdNUp3qYnAI1p2FwOHfKUidOeC2q5B8tijZHp0DMgkhqXBf\\nR7yFryBoBCUyu8n7xUVaTpU5Zv4jiajY/f/gs6RBRFS+vR83CJMXm4XKcWn2\\nD0Hdmls1+WS/lW260YF6HeIzGqgVaGeLTUC2wUMiUp0JBtHQTTdI+vEnfDFh\\nhDPnRVjPbs32/Btpq2EXefFVKFaTFs7ATQRkU/diAQgA7K4txK+jduioSHmm\\nSGK9WHgKtdgCOqHAZA9ud262iS5f4aEDrn5yrkm+IzRm32V4qZrvwyogQUjf\\n69YBjhSB4DsNON7vLeQnfvjoKGoc48t9ditrXRBKl6MCVcoSIM4W3HCmapR2\\nqzH42R2grPa4kDrmS+YISq4aRkBUFRRJ8M0joZhcup5iJfWGvDTg4Yd7ntOH\\nPCxTVq9nLxz52lBidPawFD678yMrP6H5TmdBEq8rWQPCK3aF6fTvk4qgK6xd\\nOHeGT/LNwi0ZYcLABzrjJ3BLCkNWYSkkb6lUOw4D8ybIFeTuq6AF7SRysqs/\\nONfF35a+TCXsWvYHcZzqptQ4oQARAQABwsB2BBgBCAAqBYJkU/diCZAOd8K7\\nO81EfwKbDBYhBKekDJE9u2pk4A+sHQ53wrs7zUR/AABn0Qf+L+LaoUIyFAYg\\n2XePeU0UeBvY99l+mp7GhGpQ0HtWUs6yS7khGg+rFjRBSKNUSbtZVJzOkzVl\\nsE1IfjblyexRnlnk1qmKETuYPVGR1bMTZleO9iMjrohE+/NSl1HNC5ZMOMiL\\n2HHBVcDHZNVgq24mnt37lusvOU/5MxxuubIstiejapnu0fYU4GTHwD2BNiH/\\nYb9R3XExYwZMREtr9QrZgUrFXY/pUsxugLE1jxLh2a6vbd3lTeiVXF5CUJe5\\npM4TKZ43667CJkHH2ebPCvpdLjmApsk52Z9fZhAxJw9xBYrD4Xwt4VSbZYNC\\nM6W68qhpO52JLKexdGhHxv2lf9t9Hg==\\n=AWPc\\n-----END PGP PUBLIC KEY BLOCK-----\\n\",\"signature\":\"eip191:0x10dc44a1395f85acb7dbf2222ab84574e2bcc1880e31cb5b643953e1943cccee034b04da1f856009604b1cc05b6b8c74ecaa774d51d769de93e1336b2093ed831b\"}", 95 | "encryptedPrivateKey": "{\"ciphertext\":\"c7465deac68328c5ff32ddf6242aa3765df065b507403f88135d5509d189062c138a8a1cce6a7b375d569214bd3e821a25a472b0711c4ef3792eb941903801800db0afb5c2fbf3d8930c70901348d549ffa57f3cd6da5839a3df471054766688b701d43d5e248521c45d19f653d035467b6c3b165cfeaab3f4f1351251e1879f33776bdf7d0b52f6130584bb93529a282029200c757b630e3f87f0cb438a1a48fb19c13e0ae84babcdbdc6c8d78a3d4c941a8a8803e93d6ace71c70ae076e1c54d9f45caccd867f7eb2098d055aef765ef61bc585f777a0194199674ec04d7422d5271dd3736a11292a33431840be1cfc40440d41c825ac0386d2acd507aaf11c74156f15d3f61efb24412bbe65caa04c525d048ad1fde96bc781588f9e1967fcfa7f83f054166053efec00d0d1c8829a6f0d7551443327967dd869f64ec20e251704f08f49511b3445f9bf9b1d8c6fbaf6f2f3c73056e9e48d151d5e30b84034e7906d6239ceb2c50723df99e371c931d069ab838338071b03117a4276727b73e471a4daf172ee62b9dc12a1309645a9809b91b154fb9139797ca8ece29cfa6f960997e1eb7f530ec05f191acb0892c948f4f46d7142b7835ff6c6ee188c7caabc10343d287eeaef7cbc729505f0a137101d2665854049e57810f395114da29f833f6f65dacfaba6e97b4df31b38f375c0caaee09fbc02aca9c2f66f5b39618bc204bd129463a12deb1c925ccdbc96519971f241fcb485c04a7bd7eb641f8e744da21bea0d36a2dc2db62b94583d7a9533a6f3242641f282f65167a751a3a95575fa4c40862474d797249e1dfbe54a6a4f99910482f60fdfbf4ef5872c387f9813c96694d94d04a2010d76c9da2df65c2a62fe4d0b958ba3d6838538405f1fd3c9af870c0dac68b76adceb768462cdc9f00ce0d724e6c1e97885886237e743de776916548d1205540fdae735631ee17bc5ef641f8799151c1e693436cc1d53e944f69e0821b56106f478bca79ecb6286b1372df43ed4a3ce073229395cb8b387919fee8b2ecc32ba29ede8271b943142691ffe8473e2a594e361bdd8576bf4601787d35b237bda2f0564d67aa2f60eeb375b52b2b6154ccedbbc2e404b4b9326690ac9d398bd6aa53212bbd78a4e2461073f90b007ceca3bc789f33a6516e23266c04383b7fc812cff1f5574a516adb420ecd7b4d1895aee58118645167a97e7216420c1e5a2d7ffb77f744fa9c1999400899c177bb5b165312ef265edc03349af8daf14f4160a7af31b75451150e3da8ccebba5db6fc4e92c963ef0f8bcbcc815cc1d18c7deea719ef569dd59a16ec7597966133437589592a594065ea15167cae608566e16cdad9e3b3bdcccde4d89a7dceaf8cf155f5c34fc6994016422e50e74dd4d4be44d8357d1bab3ecf263399d428605f9f0d7528410657a1dfdd6ac32e3184397d0677695dcad46bff065ab6db432dcde97784e17285d5fad7eac828eba0f5835662220a14a7893c6c53c283c2c4c217e8770dc4b3d322b207fed414dc354279da21750195e2d821b8dae4e45f8ad8e8f917f46b4cb2833660fcfed59b3e5c998ec7c2b82b2dc6283e5c5b3c6a3cea7089e80400286c980afdc2852b7cf04dad0defc647f0c91ab057a43b002c605d447dfdd186c6b81d4ab6459c230d0dbfa56d8c4e7e898d66b2b0b47aad7fa3013fa3b92a121dd6fdf8eab65cc48b47997c9fd3eeee0ef5f61e6cb3362b61d07b60cce878bf934b5745902aebfb8e8b50f16b6ae721ab1276d9e894859f7fa0e374097bcfff5d569ae93aec5e20465c5aad5ff89ed6e35f71159ffb4279e3008ac4616dbad7f5058f6108a26699abaeb62e6d83b332679acac2010f6e5272a81aeb968d59bdc30996c8ae0022bbf5b0585623dd4bab9a12707c658e3f8355ef3a41c7e657c72614c464c4ec6ec187a132e56b875a245e9634e1181d23ad18d8e6c722ec9c57182e548ea39f5954c783492ce8218d1e529d3cf3cf84b0ee9e440e5fefde4734d4e003eab83f500eaf526f8a695df011df02fa3a752835458ba28ad4a7e63eef6fd63077d52a93bf142741d542752d430822534cd07df4f5960b654bede3f9dbe461d022771ccb8df8e6774295a8407cabdbfe1abf7d1437784e458a2583194e8b39bd09b4bacdacc10aa41c0e03972b337d58439de868f27e277633fdb0162ceb5f95c2c774be15248d5140d25f46874e74d39f4e5105bb5b3c7d9b0454c3137ad75a183f58fa64dcd892a0515e482e74b3271230da09f94980ad77a4ea1be85b45037bafa6729d282d620ca2e37c2ce9f68f1e11285c1d81bd464a3191d7dfbb10ac82780d971007b14614bca9688c957973b3931028663aa0f5231ae8e554932266d4f312f22739dec983fdf22ebcc9a1b4867304e392767b00276b7c263ecaac19ec0fa9b09db763127ce9e4e98687c85d892e9cc5545e59037e42936f9357ac1a8cbb73bacf30cd011dcae533febc43ab24bbf55b3aa364f7dd0ce2975c27ccdfffb1dbda26f90a8e7bd944a2746283cd139424539cb5f958804d2f5326fd2e6d54189c5a39560f417688d0518b06aeb1c8fd4a95cff62ba72caa16be1e76d1ba5ee67ded8dada16102f2f8bb8a23d561e7a363e12cf30b67088083dc1d38e040c9e0a2df03bcf65a9a8937863624fd1fbdb0d4db68cdeaf00d13e9e745b6bc7ebd9fbbb6f6fb004dd2094ef39105d54f75670a66de19f31a28cbf18f27627185d60458a482ece43d52e7b1249be46cf8d3fca80004a3826540816c8435d6ff7963eb906900e20250189043d362c2574775592f55125948581ede19a3bebb21794cbe7d708b52c8b83493a74a312737e2eb5aaae563d25c42b10b7ba98439cd4d44cecd2302436aea8c833f3f3d559f5c86bf427c1fd23875a87d0cad78612490527a12e82fa0ef1159a697e715875e56bed50ad3b6ce07b00729f8b00eff8563697c80916a050c7de07adaf8d5f6300e83480bfa15484e7b3930761c95bf9f57542990c3e0cad7c250269e494faa1f3e7048c67eb6948c5448f4c01c08074a941b52186a78d7fe56117e6ec869628ad8d162385c0a4c9e064ae71f69ddf136a92220ce2911f18af20430c473c985ed9fef1037d2d206555e4e01fb0a415fa50ff597a64b7dfd81d89829838587c278dc19c3378e8972ac11e73c2bbf8ab65f32180cbb3396ca924a7248e401c6a8cc495e575121784ceab8e30ecb2689fdfa8af09f653be8f643ccf6139177da7337c5139e966ad8ec5f0293ebbe8658da40d5dc81ed5fed0d726e8559b78d84aaaf97517984935abfc25178a48e572b9a6a188dbdb58177b0ee05e9ac00bf17f35d326231aa51f1f6646c7d0cb87dfe6cda560ca7d5e096a5fff58d166147ccfc68c85fd47b6b1627f37f4796c293e109f5ad15c8454549a865ac1080fb76d1121039891f348f395b567474a3e7adef0057b181fea9ab2d0645b7cd3a6e4a6ce2368068ac82a0b89a1cc204beec44669c06d53cb6eb67e9514e0bb27ecb7182c24262ff88c14cd2ecbe37a3a79857773ad6a52d9bc1381218593a4ee9603c977ed74a75773b0c9c4644489da137b9b9e1c148279e528997d2c5926296530959fc77021133663ad3836b219f4296f1ac81c5297c061261c8c3fb2de1f9c786bb366030ecbb4c7d401cd020ced38ab9d6a2d534853d1db42e902c6eb1983178f69c61c69f70130190f473f88ef2c71d163c0c1e487d1a1b69eefd3d5ee0e8c3b37e0349ec3598e75745070384afb0566e26e4b43cc4b12c1d38d45bbf9833e4ff4ea1bd4e09a6336e862a40161075a94e45f119c47b15e8b5365762e5f916ba5ce3fdc873b1be1240b50936d4670507769fc9fff3f9b2ee505784a8a591df5bf8fdafbbaa0ad0b21f5650feefc7850ef63a6546a2587bfa7a8b89b17fce5d28e5e6ee9fa8e1eb1fb1273fec53c0401573dc4cf8d52b7d10ae3cad0d6f712cf7361dc79aa2fcc4e071e19de33f326f6ba90c303f309d66969756b3a34358472553a6ff52c5b1535f2d8209d4e7695293fc4aeb79a4b6006f7fbb2ed4f83aab799ec647935a53b3bd5245210dd173f56053cbdb9c1c1cfc393a60030d88ba34e4033b60b1265256c66811f25e53d92e012e1f303ad1322e7702b7c83db259d79860e78ba0a087c1ff038afbda2b833a9adda6ae816cebdb7df039b7aada5b45bce27222d1485437ac8663ee4f756ce0d287835e014cdc1c9a6e1e56fb6e455a8545ad1c0c51d4d116fc7d41ac401ed17f10c9632949c12f37ead415d1e2fb4fc757600c3f0d88bcb4a77d9667b85c3912cf54d870029714eaccfff3ed87ed64a5696c877b850b56c9922fe746e1c36d971095d7f6d6720f959bc41fe923a269128e96f30221a093d42a1bc5245977a8489b2ec4c6c3fc75a4f301251280ac03f815ab9f34fbec647d9adcb2870d8cb126de8717d9870bfbcf153dcdda06fb6ee08a639ba11b70749a69470ba16fd910cb363af7cdca8bf51484477b1cb9328101dcdec1154431c9d7f3cd49db7b1b916d1b7aa526f68f3bc62f8810ff4d38f9bda33510dbaec4db116c2e60cbff1df3a0022c1b1b4d780a9f671f98c27feb0fe9967c08759827dbb25f3c8dcab3cf984ab2b2a7e789b97c19c7ae483a3e771d7f41b14996f62d5e48666c29ecb5270b702a0f32189005f2bd6e66050e141a1cd1c9aff7cb902f42b9c1a85b48b09b90dd7b4fa37fb8f5c41a5ef96f0896d6df6f83395a910b99536fe628e4a83dec574125013e50c8600e06c88f0802bdd9c87556269ccac616428d3d727b5086820e35e2f853e8cd67827501384ac6dbdd674ac88164bc255e5b0e05cb18bb55aaf78184910d1cf24eb7b2bba63d0f681fedf32618a1f6e3905cfb1adcdce67ac69e4af8\",\"salt\":\"f0714db48256fad25f38c0f8e8f12fdd1958a9856657ce56c313308a671ef64c\",\"nonce\":\"dbbc53ca498420eb03b9e181\",\"version\":\"eip191-aes256-gcm-hkdf-sha256\",\"preKey\":\"348d42f2faa246114c8c62c75812cb66df873d5bb57e8ec106974871a08189ee\"}", 96 | "encryptionType": "eip191-aes256-gcm-hkdf-sha256", 97 | "name": "", 98 | "encryptedPassword": null, 99 | "nftOwner": null 100 | } 101 | ``` 102 | 103 | The SHA-256 of the JSON below is: 104 | 105 | ``` 106 | 9c5f42d8842845e64e1c50c59f487810f78d3063153c7a77bd8c2a453f248518 107 | ``` 108 | 109 | Then we take the EIP-191 signature of the hash above using a wallet with this private key: 110 | 111 | ``` 112 | 0x25d2c7144ca6ff91412f6c7340f9c352e4eb4bac283b4a1a6195cd6e97ea58c4 113 | ``` 114 | 115 | And we get the verification proof below: 116 | 117 | ``` 118 | eip191:0x5b614e0f9196f0982ef4cba8381bacd128e6ab6eea2f34f28ae682c0dbb655fc433068ce7fc64e9da27516f02377eb887aad50ab8240339f670c62cea16d8c961b 119 | ``` 120 | --------------------------------------------------------------------------------