Idea: 086
Title: Push Notifications v2
Status: In Progress
Created: 2018-03-01
Q2 Objective: #core 1.2


The current push notification system is sort of in an MVP stage. It works, but there are lots of important improvements which we need to accomplish in order to meet basic expectations from end users, such as supporting group chats and previewing the message sender and content on the notification itself.

Swarm Participants

Product Overview

The user expects push notifications to be reliable and helpful while maintaining security. Some familiar behaviors illustrate some fundamental inter-connected qualities:

We want to end up with a notification system which works on as many devices as possible and is resistant to censorship. There are countries which block certain notification providers (an example being China blocking Google Cloud Messaging). For that to be possible, we need to allow users to select their notification provider (with a reasonable default being Pushy or FCM), and to incentivize the creation of a paid notification provider economy. Per Oskar’s description:

“Alice and Bob are chatting with Eve the masternode/mailserver listening. Bob uses F-Droid / lives in Cuba and thus can’t/doesn’t want to use Firebase/GCM (see whitepaper). Eve sees this as an opportunity to host a node which can serve Bob. Alice does not know any of this. Bob registers their method of choice for PN with Eve, so that when Alice sends a message to Bob, Eve also picks it up and triggers a push notification on Bob’s device. Eve cannot inspect the payload.”

We also want a solution that doesn’t involve talking directly to the notification provider, as that would require keeping authentication elements embedded in the app (currently the case), and might expose us to quota theft.

Flow Diagram (1:1 chat)


Alt text

For group chats, the flow is similar, but it’s the chat admin which ensures that each chat member gets a notification channel for every other chat member. Notifications from chat members who left/were removed should be ignored.


At a high-level, we want to move up the current solution a notch regarding some of the critical qualities mentioned in the Product Overview which are currently lagging behind. The specific steps to reach that goal are:

Requirements & Dependencies

Security and Privacy Implications

Exit criteria

There are undoubtedly enough issues identified to span several months of effort, so it seems reasonable to have a Swarm that tackles the problems which have the most impact on the user in the short term and leave the rest for a future Swarm to form around. There is value however in documenting the shortcomings of the current implementation, even if they are too far away on the horizon to be addressed in this Swarm (e.g., 3rd party PN provider support).

With that in mind, the exit criteria are as follows:

Success Metrics



Minimum Viable Product

Goal Date: 2018-05-21

Description: Show more information on notification

Iteration 1

Goal Date: 2018-05-21

Description: Implement notification server mode on statusd

Iteration 2

Goal Date: 2018-06-04

Description: Support simple deep-linking

Iteration 3

Goal Date: TBD

Description: TBD

Supporting Role Communication


Copyright and related rights waived via CC0.