CloudServices/Notifications/Push

Push

Overview

The next version of Notifications will focus on providing external sources a means to provide semi-anonymous data to a user, regardless of where the user is connected.

The input provided to the system will be one (or more) JSON formatted, valid Notification messages. These messages are verified, handed to the Post Office for dissemination to the Distribution nodes, based on user preferences. The Distribution nodes then broadcast the properly addressed notifications as appropriate to the channel type they represent.

Message processing should be simple, fast, and able to handle a large amount of traffic in the most efficient manner possible.

[whiteboard]

Input

The input process should be as simple and direct as possible. In this case, the Push input process receives a JSON token which follows the Notifications format:

   { "body": "{
       \"token\": \"Base64_Token\",
       \"timestamp\": CreationTimestamp,
       \"ttl\": SecondsToLive,
       \"ciphertext\": \"Base64_EncryptedMessageBody\",
       \"IV\": \"Base64_Nonce\"
       }",
     "HMAC": "Base64_HMACValueOfBody"
   }

Since the "token" content is enough to properly address the Push input packet, no other additional info is required.

The input process performs general validation including:

   * check message format (ensure it's a format valid Push input packet)
   * check HMAC
   * check the timestamp + TTL to verify the message is still valid.
  

The input process then sends validated, full Push input packet to the Post Office. Invalid input packet candidates are rejected with no error.

Post Office

Post Office is responsible for determining the routing of a Push input packet based on the token values of the message. It decrypts and validates the input packet, determines the user associated with the packet.

The Post Office only accepts valid JSON formatted Push input packets. Invalid input packets are ignored.

The Post Office outputs the data block to the Distribution utility including:

• user's mozilla ID
• ciphertext
• domain origin of input packet

Distribution

The distribution mechanism looks up the registered distribution channels assigned by the user, and then sends the ciphertext to the appropriate channels with associated destination info. (e.g. user has registered to be notified via iOS, Jabber, and Android when receiving an update from gmail.com)

Support Systems and requirements

Input

It has been requested that the Push system integrate with the CherryPicker project. This integration would use CherryPicker to monitor incoming mail messages, discover messages of interest and pass them to the Push Input node.

Questions:

• What information will come out of CherryPicker (ideally, just the JSON elements)?
• How will CherryPicker pass it's content to the input system (RPC, REST, command line, socket)?
• Can we trust the origin of the message, and if so, how should we pass that info to the Post Office?
• What other inputs would be useful/should we consider?

Post Office

Post Office will have to resolve a user from the token. This means that the user data must be feed and coordinated between the Post Office instances.

Notes:

• This will continue to use the existing architecture as much as possible. the *MQ will be used mostly for internal routing and will be d-emphasized as a client connector.

Distribution

Distribution will need to have:

• User Distribution registration and management
• simple Distribution rule engine
• Config Data storage (redis?)

In addition, the framework will have to be able to support multiple output formats, including potential candidates like Jabber, Server Sent Events, etc.