Push notifications - Where we are at
- 1 Push notifications: where we are at
- 1.1 Goal of this document
- 1.2 Context
- 1.3 Current state
- 1.4 Resources
- 1.5 Options
- 1.6 Addendum October 2
- 1.7 Addendum October 3
- 1.8 Links
Push notifications: where we are at
September 22th by Oskar Thorén. Updated with addendum
October 2 and
Goal of this document
Make sure people are on the same page when it comes to
- The current state of push notifications,
- What the limitations are,
- Who is working on it and, most importantly,
- To decide on priority to work on for the next weeks.
Going to quote what I wrote in the initial push notification proposal document  as it is just as relevant now as then:
Work under the name of “push notifications” has been a work in progress for six months as far as I can tell. There are many reasons why it hasn’t been implemented yet, but one of the reasons is that it hasn’t been scoped properly. By the power law of projects (</span>https://www.johndcook.com/blog/2015/12/21/power-law-projects/), it is expected to take another six months at current pace. The only way to stop that from happening is to aggressively cut scope[a], break things down into their essence and then deliver on those.
Since then you can add another 50ish days to the above.
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 background, so that I don't have to have the app in the foreground all the time.
Limitations of the current design and implementation[e]
- 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) 
- L4 UX: Notification doesn’t include sender or message, so message might be lost[f][g]
- 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 binary 
- L7 Technical/Spam: User A can trigger unlimited notifications at B
- L8 Technical/Dark routing: User A has FCMToken of B, and </span>Firebase knows A and B[h][i]
- L9 Technical/Tracking: Firebase Analytics included is included in in react-native-fcm [FIXED] 
- L10 UX&Technical: Notifications are sent to a device, not account
As Ricardo is leaving Status, currently Oskar is the only one working on it. As far as I see it, there’s room for </span>one more person on the Clojure side and one more person on the Go side[l][m][n][o][p], in terms of work there is to be done. Depending on priority, I could keep working on it alone (Clojure & Go) but then it’ll obviously take longer / fewer things can be done in parallel.
Here are the main strands of work as I see it. These can obviously done in parallel if we have multiple people working on this.
- Android: get data payload when resuming app from bg (status-go changes) [6, 7]
- Extend status-go API to take notification and data payloads
- Figure out routing from open app to adding payload to relevant chat db
- When sending notification, include necessary info add payload to relevant chat db
- Encrypting notification with key receiver (contact) can decrypt upon opening app
- If you send 10 messages, each notification alert has to be clicked on to see it in app
- Leave it as it is and use offline inboxing to retrieve messages when user opens app
B) Increase basic UX capabilities (L1-L3)
Address UX weaknesses. Combating L1 requires figuring out how to exchange FCMToken among many participant, extending status-go public API, and it also increases L8 risk.
C) Use something like a notification service (L7 and L8, L4? L10?)
Continue work done by Victor and Ricardo. This is the part I’m least familiar with. 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 L7, L8 and possibly L4 (but w/o E2E encryption for actual Firebase notification?) and L10. What limitations in the current implementation this addresses should be made explicit, as well as what problems it introduces. For example, it currently introduces another failure mode & increase centralization by requiring a Whisper node to be run in a cluster that we control. If we use this it should be added in small pieces in a way that augments the current design and implementation and can be done and used in a timely manner.
See [8-13] 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 get rids 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 shape 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.
Addendum October 3
It was decided at devcon3 release meeting yesterday (Monday) that basic user story together with removing FB Analytics (https://github.com/status-im/status-react/issues/1877, pending QA) is good enough of a deliverable for devcon. Next step in this general sphere of problems is probably offline inboxing; this will be elaborated on in a separate document.
[a]agreed, we need to do this with many aspects of our development, get to MVP as fast as possible
[b]Really like this, again I would like to see this happen across all features, and as suggested, we should have a discussion about this vs eliminating epic/ branches
[c]Can we have a reference link to the recent build with the feature enabled? I was trying 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.
[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.
[p]ok, we have the squad 3 for PN now