Push

Project Overview

Push notifications are a way for websites to send small messages to users when the user is not on the site. iOS and Android devices already support their own push notification services, but we want to make notifications available to the whole web.

Intro Blog: http://jbalogh.me/2012/01/30/push-notifications/

Code Repository

Devel - https://github.com/jbalogh/push

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

Email Notice - A webapp provider wishes to communicate with their audience. The provider has a set of user tokens for their customers. They then send messages to token@mozillamessaging.com (domain tbd). Notifications parses the message, wraps the message in a useful wrapper, and then relays the message to the registered user address, thus providing the user the ability to quiet noisy providers, drop compromised addresses and otherwise manage their message delivery.

In addition, these alerts may be passed on to other devices/platforms that are running the webapp. (Note, some care should be exercised to prevent user from being "spammed" by these sorts of notifications. e.g. Same Notifications appearing on every device, email and other notification system they possess.)

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.)

UX and Design

Services/Notifications/Push/UX

Etherpads

Security Review: https://etherpad.mozilla.org/NotificationsSecReview

UX and Design: https://etherpad.mozilla.org/NotificationsDesign

https://etherpad.mozilla.org/NotificationsUsers - Desires and Detractors for various parties associated with Notifications (End User, Notification Provider, etc.)

Stand alone demo server: https://etherpad.mozilla.org/NotificationsInABox

AWS Websocket maximum connection count discoveries: https://etherpad.mozilla.org/AWS-Socket-Discoveries