Confirmed users
1,022
edits
CloudServices/Notifications/Push: Difference between revisions
Jump to navigation
Jump to search
CloudServices/Notifications/Push (view source)
Revision as of 20:37, 20 September 2011
, 20 September 2011no edit summary
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
=Push= | =Push= | ||
== Overview == | == Project 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 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. | 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. | Message processing should be simple, fast, and able to handle a large amount | ||
of traffic in the most efficient manner possible. | |||
[[https://wiki.mozilla.org/File:Push_Whiteboard_20110726.jpg whiteboard]] | [[https://wiki.mozilla.org/File:Push_Whiteboard_20110726.jpg whiteboard]] | ||
== Input == | |||
== Get Involved == | |||
=== Code Repository === | |||
''Stable'' - TBD | |||
''Devel'' - https://github.com/jrconlin/moz_push | |||
''IRC'' - TBD | |||
''Email'' - TBD | |||
== Requirements == | |||
* Transparency: Process MUST be transparent to user. For example, other than clicking "Yes" or "No" to a dialog of the web app requesting to send notifications, the user should not be aware of the underlying mechanics of the process. | |||
* Security: From the point a message leaves the sender until it arrives at its intended recipient, all communications may not be easily readable by unauthorized persons (e.g. anyone besides the sender and the recipient). By "easily" we mean it should not be trivial to decrypt a message, but take a long enough time and resources so that such effort is not viable. Encryption is optional, but the key should be provided by the client service. | |||
* Anonymity: Web apps MUST not know anything about user (insofar as the communication between the web app and server is concerned; if the user is logged in to GMail and signs up for notifications, then obviously Google can associate the resulting subscription with the user who created it). | |||
* Portability: Service MUST work with any device that supports the protocol. | |||
* Control: The user should be able to disable or delete any created notification channel. Upon deletion, the user should not see any additional messages sent to that channel. The sender should be notified that messages to that channel are no longer being accepted. | |||
== Use Cases == | |||
''Event Alert'' - | |||
A user wishes to receive alerts when an event of interest is about to | |||
happen. The user signs up with a service, and the service receives a user token. At a significant time, the service then sends a JSON notification to that user token, which causes the notification to appear on any browser that the user is currently using. | |||
''Cancel Alert'' - | |||
A user no longer wishes to receive alerts for a given notification. The user | |||
loads their admin and control panel and disables the queue. The user can either temporarily silence a given notification queue (in which case, notifications are still collected, but not immediately alerted to the user) or delete the queue (in which case, incoming notifications are rejected, existing notifications are removed, and the queue is no longer associated with the user.) | |||
== Operational Requirements == | |||
The operational system is designed to run on a minimal configuration. Because of large scale cost issues, the Mozilla hosted system will not be using constant connections in order to provide real-time message updates, but will instead rely on polling. Smaller sites (with under one million subscribers) may wish to take advantage of the long session Server Sent Event based notification system. | |||
For production the system currently uses: | |||
1. a Redis based index system (for queue management, token resolution, and housekeeping) | |||
2. a file, stored in a shared directory based on the user's token, containing the message body. | |||
For non-production systems (or smaller footprint installs) you may wish to use the mongo storage option, which stores all index data and messages into a simple mongo db. | |||
== Releases / Roadmaps | |||
TBD | |||
== Design | |||
=== 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: | 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: | ||
| Line 31: | Line 82: | ||
The input process then sends validated, full Push input packet to the Post Office. Invalid input packet candidates are rejected with no error. | 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 === | ||
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. | 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. | ||
| Line 42: | Line 93: | ||
* domain origin of input packet | * domain origin of input packet | ||
== Distribution == | === 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) | 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) | ||
The secondary notification system is TBD. | |||
===Input=== | === 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. | 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. | ||
| Line 57: | Line 110: | ||
* What other inputs would be useful/should we consider? | * What other inputs would be useful/should we consider? | ||
===Post Office=== | ====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. | 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. | ||
| Line 63: | Line 116: | ||
* 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. | * 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==== | ||
Distribution will need to have: | Distribution will need to have: | ||
* User Distribution registration and management | * User Distribution registration and management | ||
| Line 72: | Line 125: | ||
= Push v. 0.5 Technical Overview = | == Push v. 0.5 Technical Overview == | ||
=== Definitions: === | === Definitions: === | ||
Client – A third party requesting the ability to send or receive notifications from a User via the User Agent. | Client – A third party requesting the ability to send or receive notifications from a User via the User Agent. | ||
| Line 83: | Line 136: | ||
== Overview: == | === Overview: === | ||
Push allows for small, semi-anonymous messages between a Client and a User Agent via a Distributor. The User Agent can be one or more devices, allowing the push notification to reach the User Agent where-ever or whenever they connect to the web. The notification content is secured from tampering and unauthorized viewing by encryption with keys provided by the User Agent to the Client. | Push allows for small, semi-anonymous messages between a Client and a User Agent via a Distributor. The User Agent can be one or more devices, allowing the push notification to reach the User Agent where-ever or whenever they connect to the web. The notification content is secured from tampering and unauthorized viewing by encryption with keys provided by the User Agent to the Client. | ||
| Line 89: | Line 142: | ||
Clients receive a token representing a party that wishes to be notified of an event. When an event of interest occurs, the Client notifies the Distributor, which then passes the encrypted push notification to the User Agent for processing. | Clients receive a token representing a party that wishes to be notified of an event. When an event of interest occurs, the Client notifies the Distributor, which then passes the encrypted push notification to the User Agent for processing. | ||
== Components: == | === Components: === | ||
=== User Agent Configuration: === | ==== User Agent Configuration: ==== | ||
The first requirement of the system is that the User Agent register with the Distributor. This may be accomplished in any suitable manner, however once the User has properly authenticated against the Distributor, the User Agent makes a <tt>new_subscription</tt> request. This call will create a new subscription with the Distributor system (or return the subscription information for a previously created session for the user). | The first requirement of the system is that the User Agent register with the Distributor. This may be accomplished in any suitable manner, however once the User has properly authenticated against the Distributor, the User Agent makes a <tt>new_subscription</tt> request. This call will create a new subscription with the Distributor system (or return the subscription information for a previously created session for the user). | ||
| Line 100: | Line 153: | ||
=== Client Javascript: === | ==== Client Javascript: ==== | ||
See (lib/main.js for most code related to the client) | See (lib/main.js for most code related to the client) | ||
| Line 107: | Line 160: | ||
Once auth has completed, the server args are passed to the Client element for processing. | Once auth has completed, the server args are passed to the Client element for processing. | ||
=== Server Distribution: === | ==== Server Distribution: ==== | ||
A server wishing to notify a client of a new notification has several methods available to do so, however for this discussion we'll focus on the PostOffice process. | A server wishing to notify a client of a new notification has several methods available to do so, however for this discussion we'll focus on the PostOffice process. | ||
| Line 135: | Line 188: | ||
The serialized JSON string can be sent to the PostOffice URL via a POST call, with the notification as the POST body. | The serialized JSON string can be sent to the PostOffice URL via a POST call, with the notification as the POST body. | ||
== QA == | |||
== Support == | |||
== Localization == | |||
== Security & Privacy == | |||
== Legal Considerations == | |||
== Other Notes / Whiteboards == | |||