The following page contains a list of open discussion points about the Mozilla Push Notifications server.

Hide Broker Behind HTTP REST API

Pros

• Can pool multiple connections into one connection (using multiple channels on that one connection)
• Simpler for developers to build their own client (just do long-lived HTTP requests)
• Better security by preventing direct access to broker (if broker has a security hole, we would need to wait for a fix)
• Allows us to abstract away how messages are routed
• Allows us to support idea #7 by returning a 302 directing client to the new POST Office

Cons

• Extra server overhead

Enforce Exclusive Queues

Pros

• Easy to do with AMQP
• Extra security: can tell if someone else is "snooping" on your queue and take action (create a new one, forward all messages to new queue, delete old queue)

Cons

• Can't "share" single queue amongst multiple clients (not sure if we even want this -- does it even make sense?)

Persistent POST Office Connections

Pros

• Makes it easier for us to detect a DoS attack? (Apple uses this approach with APNS)
• Allow web apps to send bulk transfer of notifications (very useful for bulk senders like GMail)

Cons

• Makes it more complicated for providers as it requires they have a pool of persistent connections with which to send notifications
• Adds complexity to POST Office so we can support it?

Implement TTLs for Queues (and Messages)

Pros

• Easy to do with RabbitMQ extensions (see http://www.rabbitmq.com/extensions.html#queue-ttl and http://www.rabbitmq.com/extensions.html#queue-leases)
• Prevents server from being flooded with old messages that will never be read

Cons

• Could this be annoying for users? Probably not so long as we have a long enough TTL and make it clear to users it's enforced.

Alert Providers When Subscription Cancelled

Pros

• Providers only send notifications to "active" subscriptions (saves resources)

Cons

• To return error message from POST Office would be time consuming and would probably make the service incapable of large spikes in traffic (so we shouldn't do this)
• To return an error message asynchronously would require providers build a separate service for accepting cancellation messages. Another option is to have clients send a cancellation message, but this really should be done by the Client Agent to maintain users' anonymity (or should it?)

Send ACK to Provider When Notification Received

Pros

• Can support messages for which delivery must be assured

Cons

• Requires we build an entire messaging system that goes the other way? OR we could just reuse the current framework and have providers subscribe as a client. OR (even better) we could just spec a special notification type that allows the client to confirm the receipt of a notification (i.e. include a URL client can send ACK to).

Provide Mechanism to Move Client to a Different POST Office

Pros

• Allows us to re-balance our servers
• Gives users the power to move from Mozilla to their own server

Cons

• Could have security implications? (if attacker took control of Mozilla's servers and moved all its users to another notification server, for example)

Make POST Office in Charge of Generating Subscription Token

Pros

• One less thing clients can screw up (also prevents generation of insecure tokens such as AAAAAAA...A)

Cons

• If other users implemented a POST Office, they could assign tokens that are personally identifying (is this really something we need to worry about? Who would even bother doing this?)