Push notifications - Where we are at

From Status Wiki
This is the approved revision of this page, as well as being the most recent.
Jump to: navigation, search
Up to date on 9 June 2018


Push notifications: where we are at

Written September 22th, 2017 by Oskar Thorén. Updated with addendum October 2nd, 2017. Rewritten June 6th, 2018 by Pedro Pombeiro.

Goal of this document

Make sure people are on the same page when it comes to

  1. The current state of push notifications,
  2. What the limitations are,
  3. Who is working on it and, most importantly,
  4. To decide on priority to work on for the next weeks.

Context

We have a basic version of Push Notifications working for Status closed beta release. It has several known limitations and weaknesses, which we will try to address in a future swarm.

Current state

An MVP of push notifications has been implemented. The MVP solves this specific user story: As a user, I want to receive a push notification alert when a person in my contacts messages me and I have the app in the background so that I'm not required to have the app in the foreground all the time.

Limitations of the current design and implementation

  • L1 UX: It only works in 1on1 chat
  • L2 UX: You have to have the person added as a contact
  • L3 UX: It only works for text messages, not commands (like /send, /location, etc) [3]
  • L4 UX: Notifications stop working for contact if contact reinstalls his app (FCM token changes)
  • L5 Technical/3rd-party risk: It depends on Firebase and is tightly coupled with it
  • L6 Technical/General security: Firebase SERVER_KEY is included in the sources and binary [4]
  • L7 Technical/Spam: User A can trigger unlimited notifications at B
  • L8 Technical/Dark routing: User A has FCMToken of B, and Firebase knows A and B[h][i]
  • L9 Technical/Tracking: Firebase Analytics included is included in react-native-fcm [FIXED] [5]
  • L10 UX&Technical: Notifications are sent to a device, not account

Resources

Ricardo (who has since left Status) and Oskar did the initial work on the MVP. For v2, a swarm has been created with 4 developers (and put temporarily on hold in order to focus on the Beta release).

Options

Here are the main strands of work as I see it. These can obviously be done in parallel if we have multiple people working on this.

Use data notifications as a signal to sync messages from network/mail server (L4)

This requires:

  • Android, iOS: get data payload when resuming app from bg [6]
  • Extend status-go API to take message ID as data payload
  • Encrypting notification with key receiver (contact) can decrypt upon opening app
  • Filter messages received in push notifications to see if they are still meaningful (e.g. are they from a chat that the user has since left?)
  • Create local notification only when it passes filter. Do notification grouping

Increase basic UX capabilities (L1-L3)

Address UX weaknesses. Combating L1 requires figuring out how to exchange a notification server address and token among many participants, extending status-go public API, and at the same time addressing L4 risk.

Use something like a notification service (L6, L7 and L8, L10?)

Creating a notification server which can be installed by users and incentivized so as to ensure a decentralized structure could be the solution and is the main idea behind the Push Notifications v2 swarm. The work has unfortunately mostly been done in the past, and, recently, in isolation from the current status-react app and real devices. As far as I can tell it addresses limitations L6, L7, L8 and L10. What limitations in the current implementation this addresses should be made explicit, as well as what problems it introduces.

See [7-8] below.

Addendum October 2

Initially a comment by Oskar.

In retrospect, I could've written the state of PN document a bit differently. It is assuming that the work which *can be done* with PN are necessarily highest prio. I think if we could get a basic proof of concept for offline inboxing, which really has nothing to do with PN, then this would have big consequences for PN. PN work A would disappear and work C would probably be changed, at least somewhat.

To me, as an end user, offline inboxing is a much bigger problem for real use right now. It'd be pretty cool if we could get a very basic version of this working before devcon.

Additionally, I think the general notifications problem can best be seen as one instance of a "signal" of sorts in an attention market. I think this is what @jarradhope hinted at in the whitepaper, but generalized and ties into reputation systems for normal messages etc too. I'm still formulating my thinking around this problem. I think this can be one of the main differentiators between Status and other IMs/browsers/app-stores.

The use of the word "decentralized" should also be qualified and we have to be more precise about language and what problems are we solving. I tried to outline the main limitations of the current approach in the above google doc, and the only thing that makes it not decentralized is Firebase. So unless a proposal actually gets rid of that, it doesn't make any difference in that respect. in fact, introducing a specific role for a Whisper node in our cluster *increases* centralization and failure modes/robustness.

This is also why I'm a bit against these static squads. Now we are talking in a squads-notifications channel. The language we use shapes our thoughts, and the way I personally conceptualize many of the immediate problems we want to solve have very little to do with push notifications per se (offline inboxing, attention market). I think this easily leads to clouded thinking. The things that are related to push notifications per se (getting rid of Firebase, design for actual push notification and deep linking into app, etc) are not thing we are talking much about at all, and they don't necessarily seem like highest prio right now either.

Links

  1. http://bit.ly/2ff3Cw5
  2. https://github.com/status-im/status-react/issues/1866
  3. https://github.com/status-im/status-react/issues/1876
  4. https://github.com/status-im/status-go/issues/343
  5. https://github.com/status-im/status-react/issues/1877
  6. https://github.com/status-im/status-react/issues/3451
  7. https://github.com/status-im/status-go/issues/222
  8. https://github.com/status-im/status-go/wiki/Whisper-Push-Notifications
[a]agreed, we need to do this with many aspects of our development, get to MVP as fast as possible

[h]What does Firebase know about A and B?

[i]Since request to Firebase comes from A, it at least knows A's IP. It also knows about B's device in the sense that a FCMToken is tied to a device. It's a fairly advanced threat model though. There might also be other similar unknown unknowns too of course.

[j]I recognize the need for this, but it cannot make it into a production release.

[k]I agree. I'll see how hard it is to remove this and if it requires upgrading React Native or not over the next few days.

[l]I think features should have team sizes of minimum 3 moving forward. Literature I've read 5 seems to be sweet spot, so we should aim for 5 and reduce amount of things we are working on.

[m]Focusing on fewer things and getting them done faster would indeed be desirable. The main concern here is to make sure the work can be parallelized, so we aren't stepping on each other's toes / people in a squad are blocked a lot.

[n]FYI I am happy to join this project from status-go side. It looks pretty interesting to me.

[o]Cool!

[p]ok, we have the squad 3 for PN now


to test it but realized that I didn't have the right build on one of the two devices.

[d]Latest nightly build should work fine

[e]All these limitations are fine.

[f]Can we clarify this? It means that if a notification is seen, the message it refers to might be already not available because of the nature of the protocol?

[g]Since there currently is nothing in the notification payload, if you click no notification and more than X minutes have passed the message will have disappeared (since we don't have offline inboxing yet)

[h]What does Firebase know about A and B?

[i]Since request to Firebase comes from A, it at least knows A's IP. It also knows about B's device in the sense that a FCMToken is tied to a device. It's a fairly advanced threat model though. There might also be other similar unknown unknowns too of course.

each other's toes / people in a squad are blocked a lot.

[n]FYI I am happy to join this project from status-go side. It looks pretty interesting to me.

[o]Cool!

[p]ok, we have the squad 3 for PN now