Notification Payload Specs
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 and the storage medium it is on by assigning payload types to each notification.
The JSON Payload can differ with payload types ensuring flexibility of the content, data, storage interpretation and delivery.
Notification JSON Payload
If no data is carried in the payload (or only atime is carried), it is assumed that the notification is not important and hence persist (or appearance) in the frontend feedBox of the user.
Payload Types
The following are few payload types that are already defined, though they can change as we move forward. Notification payload type for EPNS 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.
Direct Protocol Payload (Type 0)
Direct payloads are special payloads meant for sending directly to the protocol, the delimiter + divides the subject and message which are the only two fields it carries.
It's always recommended to use other payloads for dApp or server interaction. This payload should be used sparingly when it's absolutely necessary. The 'type' here is a special field which is different from the type in identity.
Always recommended to interface with EPNS JS Library for abstracting these details out.
Broadcast Payload (Type 1)
Broadcast notification goes to all subscriber of a channel, the notification payload in this case is not encrypted.
Secret Payload (Type 2)
Secret notifications are intended to be delivered to one subscriber of the channel, these are encrypted using ECC(Elliptic Curve Cryptography) [4]
and AES(Advanced Encryption Standard) [5]
. The secret which is generated by the channel using whatever means they prefer should be kept to 15 characters or less, this secret (plain version) uses AES to encrypt the fields: asub, amsg, acta, aimg.
The rationale behind using ECC with AES is to ensure that the payload is not over bloated.
Why not just use ECC? ECC increases the length of the cipher text and hence the payload which will be delivered. Using ECC with AES ensure the payload length is kept at a manageable level and allows channels to send more information in the notification while still keeping the best encryption practices.
The discussion on using a public key - private key encryption or a derivation of it is still under discussion. Even if we decide to go with the above encryption for secret messages, we can in the future create a payload type that can offer encryption / decryption in a different way.
Example Notification Payload (Plain)
Recommended to use the EPNS JS Library to handle the generation of encrypted payload easily, it can talk to our protocol to also fetch the public key required.
Example Notification Payload (Encrypted)
Targeted Payload (Type 3)
Targeted notifications go to a single subscriber of a channel, the notification payload in this case is not encrypted.
Extending for Future Payload
The following payloads are in discussion and form an example of how the payload specs is ever expanding and can include more than just information as notification.
Multi-Targeted Payload (Type x)
Multi-Targeted notifications go to a more than one subscriber of a channel, the notification payload in this case is not encrypted. The total number of subscribers supported is TBA.
Blacklist Payload (Type x)
Blacklist payload are a future forward payload meant to only demonstrate how the payload data and type defines what information the payload will carry.
The support for payload types is left to third party frontend / infrastructure services to implement. The accompanying EPNS products however will implement all payloads types which are accepted as official after community discussion.
Last updated