文件列表:

Architecture.md (1247, 2022-02-14)
Notification-provider-manual.md (2636, 2022-02-14)
User-manual.md (3535, 2022-02-14)
notification-contract-management/ (0, 2022-02-14)
notification-contract-management/.eslintrc.json (497, 2022-02-14)
notification-contract-management/package-lock.json (75410, 2022-02-14)
notification-contract-management/package.json (442, 2022-02-14)
notification-contract-management/src/ (0, 2022-02-14)
notification-contract-management/src/contracts/ (0, 2022-02-14)
notification-contract-management/src/contracts/NotificationContract.js (3254, 2022-02-14)
notification-contract-management/src/contracts/giver.abi.json (687, 2022-02-14)
notification-contract-management/src/main.js (6413, 2022-02-14)
pics/ (0, 2022-02-14)
pics/Evernode-NQ.svg (55344, 2022-02-14)
pics/Screenshot_from_2021-09-13_17-02-53.png (13792, 2022-02-14)
pics/Screenshot_from_2022-01-12_16-52-15.png (100442, 2022-02-14)
pics/Screenshot_from_2022-01-12_17-01-44.png (40750, 2022-02-14)
pics/Screenshot_from_2022-01-12_17-04-35.png (43401, 2022-02-14)
pics/Screenshot_from_2022-01-12_17-11-17.png (124486, 2022-02-14)

# Evernode-NQ This repository contains documents that describe the architecture of a solution for delivering encrypted messages from the blockchain to end-users. The solution ensures that neither the sender nor the "man in the middle" can decrypt message or match which smart contracts (e.g. wallets) belong to which recipient. To achieve this goal, the process of creating/encrypting and delivering messages was separated, and the following entities were introduced: ### Queue Provider Queue Provider knows what to send (has access to the data) but it does not have any information about the real address of the recipient. It creates encrypted messages based on user-defined rules containing a list of addresses and message types (internal, external incoming or outgoing). ### Notification Provider Notification Provider knows where to send (has delivery address, e.g. IP address, URL, email, APN ID, FCM ID, etc.) but has no knowledge of the data itself since it is encrypted. There can be several types of notification providers depending on the type of recipient and transport (browser, http server, smartphones, email, etc.). Schematically, the process can be represented as follows: ``` +---------------+ User------>`CONSTANT_HASH + Rules`------->| Queue | | | Provider | | +-------+-------+ | | | `CONSTANT_HASH + EncryptedMessage` | | | +---------------+ +-->`CONSTANT_HASH + DeliveryAddress`-->| Notification | | Provider | +---------------+ | Provider sends encrypted message to the recipient ``` Note that the user sends the same **CONSTANT_HASH** to both the Queue Provider and the Notification Provider. Using this value, Notification Provider understands where to send a particular encrypted message. ### Next reading - [How to create a notification via debot](https://github.com/tonlabs/Evernode-NQ/blob/master/User-manual.md) - [How to create a notification with client libraries](https://github.com/tonlabs/Evernode-NQ/blob/master/notification-contract-management/) - [Notification-provider-manual](https://github.com/tonlabs/Evernode-NQ/blob/master/Notification-provider-manual.md) - [Evernode-NQ technical architecture](https://github.com/tonlabs/Evernode-NQ/blob/master/Architecture.md)

近期下载者：

相关文件：

评论：[我要评论] [举报此文件]

收藏者：