CloudServices/Notifications

Info

What is "Notifications"?

Notifications is designed to allow brief messages to be sent to a user however they are connected. Somewhere between email and IM lies Notifications.

Notifications are built around a pseudonymous, 256bit+ entropy, public identifier. Sites post messages using that identifier to one of several methods. (URL, Email, etc.) Notifications may be human readable, or opaque, machine readable content. The user has full control over whether or not to receive notifications from a party, allowing for "chatty" or compromised IDs to be disabled or removed.

Get in touch

You can reach the developers of this project by:

email: services-dev

irc: irc.mozilla.org #services-dev

Issues and concerns

What about spam/viruses/evil?

That's a valid concern, and one we are thinking about. Here are our thoughts so far:

1. A big enough namespace.
   We're using 64 base36 characters (0-9a-z), which produces log₂(36) =~ 5.17 bits per character * 64 characters = 330 bits or just north of [2 duotrigintillion] possible combinations. Figuring out which one of that namespace is yours is fairly remote.
2. Limit who can talk to you
   A notification is an established relationship between yourself and a site. It's a one-to-one sort of thing. That means that you shouldn't be getting notifications supposedly for a specific tag from hundreds of IPs.
3. The first hit's free
   While we're doing our best to keep costs down, there is a potential that this can start costing money for us to support, particularly if large stream sites like Facebook, Twitter or other social streaming services want to send you constant updates. One idea we're kicking around is to charge sites a fee to cover the additional cost of sending millions of messages out. We're a non-profit, so the fee would cover the costs of supporting the service, and we'd also be able to grant SLAs, but it means that we have a legit reason not to allow farms of machines we don't know about sending thousands of messages to the system.
4. Making sure you're in control
   Ultimately, we want to make sure you're in control. Sites can't start sending you notifications until you allow them. You can also disable or delete a token should that site become too chatty or start acting strangely. If you want, you can restart the conversation later or create a new token.
5. Secure, if it needs to be
   Probably the best way to ensure that you're not getting things you don't want is to use encryption on the notification. Our specification allows for that. Since notifications can be processed by simple REST calls, browsers or even webapps can decrypt the content and toss messages that don't pass muster.

Why limit the token to 64 base36 characters?

Mostly because it's the largest, lowest common denominator. BiPostal is a mail based system that uses tokens. According to [RFC 5321] the local part of an email address (what comes before the '@') has a maximum length of 64 characters. From past experience and discussions with smarter Ops folks, limiting to 0-9a-z ensures that most systems won't choke on the address or improperly reformat it to something that breaks. Thus the format we're using. By the way, the value is completely random. There's no special content buried inside the token.

How fast are notifications delivered?

As fast as possible. They're not instant, since there can be some delay involved with various systems. Plus, you may not be running a device that can receive them at this time. In short, don't plan on using this system for your next First Person Shooter game or for your Day Trading application, but it should be fine for most other applications.

Will I get spammed by the same message over and over?

Ideally, no. While we can't make any promises when we send messages to third party services like iOS or Android, we are thinking about having the notifications server act like an IMAP service and note that you've read or deleted a given message. We're still working on that part.

Why not use SIP or any of the other well defined messaging protocols

We'd love to, and it's something we're looking at as well, but there are significant problems with many of them. Mostly around things like the fact that they require a dedicated socket (which is very expensive for us to support), or require fixed IP addresses (which is problematic both for mobile devices and for most ISP users) or other reasons. To solve some of those, we're looking at doing a sliding window polling loop similar to how Sync gets updates. (Frequent checks when active, then backing off to longer delays between checks). We've seen that's a fairly good compromise between speed and cost. Now, if folks are willing to pony up for us to be able to run lots of machines with dedicated connections (or if some other organization with far deeper pockets wants to provide that service) then more power to them.
That said, if we're missing a golden opportunity to use some protocol we may not know about (there are a lot of them), let us know!

Doesn't this mean you're the choke point for my notifications?

Yeah, unless you want to take our source code and build your own server. We'd be happy for you to do that, really.

When will this be ready to poke at?

See the Goals section that follows

Goals

• Q1
  • BIPOSTAL in staging supporting Apps/ID?
    • Production Dependant on Q1 blockers:
      • HW availability
      • Coordination with external mail partner
      • Coordination with BrowserID Team
      • Coordination with WebApps re: requirements
      • UX for client dashboard?
    • PUSH: product defined and on track for Q2 launch

• Q2
  • Integration of BIPostal and PUSH to unified Notifications structure
  • Finalization of Notification SLAs
  • Finalization of metrics and logging info
  • BIPostal to production
  • Shift notification token (ntoken) mapping from mysql to MySQL -> Queuey
  • Notifications to Nightly, Fennec, iOS, Android
  • Dependent on:
    • Mobile Team adoption of code
    • Coordination with WebApps on availability

• Q3
  • Full Production ready release of Notifications
  • Documentation and demonstration code
  • Customer support in place
  • Additional demand/work from Q2 integration work (e.g. new demands)

• Q4
  • Unknown at this time.

v.1

Older Notifications work

v.2

Push

Bipostal