status-im
/
swarms
mirror of https://github.com/status-im/swarms.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Push Notifications v2: Improve the structure of the document

This commit is contained in:
Pedro Pombeiro 2018-04-11 19:21:40 +02:00 committed by GitHub
parent 3b88cff2db
commit ee16e9b27a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 41 additions and 46 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

87
ideas/86-push-notif-v2.md
View File

@ -5,32 +5,11 @@
Status: Draft
Created: 2018-03-01
Requires: [#87](https://github.com/status-im/ideas/issues/87)
Q2 Objective:
Q2 Objective: 1.2
## Summary
The [current push notification system](https://docs.google.com/document/d/1OgjnY8ps8lVA4dIohwkfGK9HVt0nZxEWbuNdb7BX5-o/edit#) is sort of in a MVP stage. It works, but there are lots of important improvements which should be done in order to meet basic expectations from end users. Namely, the user expects push notifications to be reliable and helpful while maintaining security. A number of common behaviors illustrate some fundamental inter-connected qualities:
- Reliable:
- A user expects that he will receive a notification in the following scenarios:
- His screen is turned off and he receives a message.
- His screen is on and the app is running in the background.
- The app is in the foreground and he receives a new message on a room which is not visible.
- A user expects that his conversation partners will be notified in a timely manner.
- A user expects that the notifications he finds on his device accurately reflect unread messages.
- Helpful:
- A user expects that the notifications he finds on his device accurately reflect unread messages. If he has browsed through a conversation that included messages mentioned in a PN, the PN should be updated accordingly, so the user is not mislead and can actually trust the notification system.
- A user expects to be able to see message details from notifications without needing to open the app (perhaps configurable due to privacy concerns?).
- A user expects to be able to be able to ping other users selectively user @-type addressing (individual and group notifications), in order to reduce unnecessary noise.
- Timely:
- A user expects that relevant events are received as notifications in a timely fashion (i.e. < 15 seconds from actual event).
- Secure:
- A user expects that by receiving PNs, he is not giving up the degrees of anonymity and plausible deniability which are afforded by the app's underlying communication protocol.
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 own 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 see this as an opportunity to host a node which can serve Bob. Alice doesn't 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 can't 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.
The [current push notification system](https://docs.google.com/document/d/1OgjnY8ps8lVA4dIohwkfGK9HVt0nZxEWbuNdb7BX5-o/edit#) 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
@ -44,28 +23,44 @@ We also want a solution that doesn’t involve talking directly to the notificat
## Product Overview
Energy consumption is a crucial part of the mobile experience, and even though it is related to performance, it is worth having a separate.
The end goal is:
The user expects push notifications to be reliable and helpful while maintaining security. Some familiar behaviors illustrate some fundamental inter-connected qualities:
- to provide a toolkit and guidelines to test energy efficiency of different parts of an app on different platforms;
- using this toolkit to fix the top battery drainers;
- notice regressions early by having tests in place.
- Reliable:
- A user expects to receive a notification in the following scenarios:
- His screen is turned off, and he receives a message.
- His screen is on, and the app is running in the background.
- The app is in the foreground, and he receives a new message in a chat room which is not visible.
- A user expects his conversation partners to be notified in a timely manner.
- A user expects that the notifications he finds on his device accurately reflect unread messages.
- Helpful:
- A user expects that the notifications he finds on his device accurately reflect unread messages. If he has browsed through a conversation that included messages mentioned in a PN, the PN should be updated accordingly, so the user is not misled and can trust the notification system.
- A user expects to be able to see message details from notifications without needing to open the app (perhaps configurable due to privacy concerns?).
- A user expects to be able to be able to ping other users selectively user @-type addressing (individual and group notifications), to reduce unnecessary noise.
- Timely:
- A user expects that relevant events are received as notifications in a timely fashion (i.e., < 15 seconds from actual event).
- Secure:
- A user expects that by receiving PNs, he is not giving up the degrees of anonymity and plausible deniability which are afforded by the app's underlying communication protocol.
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.
### Goals
At a high-level, we want to move up the current solution a notch in terms of some of the key qualities mentioned in the [summary](#Summary) which are currently lagging behind. The specific steps to reach that goal are:
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](#Product_Overview) which are currently lagging behind. The specific steps to reach that goal are:
- Improve usability of notifications by:
- allowing the app to match a push notification with a specific chat message. That way we can:
- Allowing the app to match a push notification with a specific chat message. That way we can:
- [`P1`] support navigating to the correct chat when the user taps on the message, and conversely.
- [`P2`] support [dismissing notification when user has seen](https://github.com/status-im/status-react/issues/3487) the respective message in a chat.
- [`P3`] adding "quick actions" buttons on mobile notifications, so the user can directly "mark as read" or "delete" specific messages.
- Improve helpfulness by:
- [`P0`] [retrieving the message body and displaying it](https://github.com/status-im/status-react/issues/3451) in the notification body so that the user can see who is talking and what is being said without needing to unlock the phone or opening the app.
- [`P2`] supporting simplistic deep-linking. Clicking on a push notification should take you to the specific chat that is mentioned. This could be achieved by looking for message in all chats that match the ID from the notification.
- [`P3`] making Push Notifications work in group chats. By default, participants would only receive notifications when being mentioned with an `@` symbol, in order to avoid creating a noisy environment that would degrade the whole experience.
- [`P3`] supporting full deep-linking. This might require mapping screens to specific URLs. Useful beyond push notifications.
- [`P2`] supporting simplistic deep-linking. Clicking on a push notification should take you to the specific chat that is mentioned. We could achieve this functionality by looking for the message in all chats that match the ID from the notification.
- [`P3`] making Push Notifications work in group chats. By default, participants would only receive notifications when being mentioned with an `@` symbol, to avoid creating a noisy environment that would degrade the whole experience.
- [`P3`] supporting full deep-linking. Support for it might require mapping screens to specific URLs. Useful beyond push notifications.
- Improve security of the solution by:
- [`P0`] not [embedding FCM](https://github.com/status-im/status-go/issues/343) (Firebase Cloud Messaging) server key in source code or app binary.
@ -80,35 +75,35 @@ At a high-level, we want to move up the current solution a notch in terms of som
## Exit criteria
There is clearly 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 in the horizon to be addressed in this Swarm (e.g. 3rd party PN provider support).
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 is as follows:
With that in mind, the exit criteria are as follows:
- All `P0` and `P1` goals mentioned in the [goals](#Goals) section are addressed.
- The swarm has addressed all `P0` and `P1` goals mentioned in the [goals](#Goals) section.
## Success Metrics
KRs:
- 100% of the messages that should generate a notification on the receiving device do so within 15 seconds, under different network conditions (i.e. Wi-Fi, cellular)
- TODO performance metrics? (e.g. device sleep improvements, network traffic)
- 100% of the messages that should generate a notification on the receiving device do so within 15 seconds, under different network conditions (i.e. Wi-Fi, cellular).
- TODO performance metrics? (e.g. device sleep improvements, network traffic).
## MVP(s)
- Single notification provider phase:
- Iteration 1: Show more information on notification (date: *TBD*)
- Send only envelope hash on PN to destination device so that it knows to refresh messages and to match them to notification.
- Send only envelope hash on PN to destination device so that it knows to refresh messages and to match them to the notification.
- Update message body from retrieved Whisper message.
- Iteration 2: Implement notification server mode on `statusd` (date: *TBD*)
- will connect to FCM, only 1 instance, no load-balancing
- add logic to statusd (accept special P2P messages from clients, and trigger notifications in response)
- deploy service with Ansible
- change client so that it communicates with notification server in order to send notifications indirectly to contact.
- Connects to FCM, only 1 instance, no load-balancing.
- Add logic to statusd (accept special P2P messages from clients, and trigger notifications in response).
- Deploy service with Ansible.
- Change client so that it communicates with notification server to send notifications indirectly to contact.
- Iteration 3: Support simple deep-linking (date: *TBD*)
- Open respective chat when taping on notification.
- Hide notification when message is viewed in chat.
- Open respective chat when taping on a notification.
- Hide notification when the user views the respective message in chat.
- Iteration X: TBD
- Multiple notification provider phase:
- "Multiple notification provider" phase:
- TBD
## Supporting Role Communication