mirror of https://github.com/vacp2p/rfc.git
71/STATUS-Push-Notification-Server (#643)
This commit is contained in:
Jimmy Debe
GitHub
parent
f1496b3521
commit
f59ad44916
|
|
@ -0,0 +1,567 @@
|
|||
---
|
||||
slug: 71
|
||||
title: 71/STATUS-PUSH-NOTIFICATION-SERVER
|
||||
name: Push Notification Server
|
||||
status: raw
|
||||
category: Standards Track
|
||||
description: A set of methods to allow Status clients to use push notification services in mobile environments.
|
||||
editor: Jimmy Debe <jimmy@status.im>
|
||||
contributors:
|
||||
- Andrea Maria Piana <andreap@status.im>
|
||||
---
|
||||
|
||||
# Abstract
|
||||
A push notification server implementation for IOS devices and Android devices.
|
||||
This specification provides a set of methods that allow clients to use push notification services in mobile environments.
|
||||
|
||||
# Background
|
||||
Push notification for iOS and Android devices can only be implemented by relying on
|
||||
[APN](https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_ref/doc/uid/TP40008194-CH8-SW1),
|
||||
Apple Push Notification, service for iOS or
|
||||
[Firebase](https://firebase.google.com/) for Android.
|
||||
|
||||
For some Android devices, foreground services are restricted, requiring a user to grant authorization to applications to use foreground notifications.
|
||||
Apple iOS devices restrict notifications to a few internal functions that every application can not use.
|
||||
Applications on iOS can request execution time when they are in the background. This has a limited set of use cases for example,
|
||||
it will not schedule any time if the application was closed with force quit.
|
||||
Requesting execution time is not responsive enough to implement a push notification system.
|
||||
Status provides a set of methods to acheive push notification services.
|
||||
|
||||
Since this can not be safely implemented in a privacy-preserving manner, clients need to be given an option to opt-in to receive and send push notifications.
|
||||
They are disabled by default.
|
||||
|
||||
# Specification
|
||||
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
|
||||
|
||||
## Definitions
|
||||
|
||||
| Terminology | Description |
|
||||
| --------------- | --------- |
|
||||
| client | A node that implements the Status specifications. |
|
||||
| user | The owner of a device that runs a client. |
|
||||
| server | A service that performs push notifications. |
|
||||
| Waku-Store | A Waku node that decides to provide functionality to store messages permanently and deliver the messages to requesting clients. As described in [13/WAKU-STORE](/spec/13/) specification.|
|
||||
|
||||
|
||||
### Server Components
|
||||
|
||||
| Components | Description |
|
||||
| --------------- | --------- |
|
||||
| gorush Instance | Only used by push notification servers and MUST be publicly available.|
|
||||
| Push Notification Server | Used by clients to register for receiving and sending notifications. |
|
||||
| Registering Client | A client that wants to receive push notifications. |
|
||||
| Sending Client | A client that wants to send push notifications. |
|
||||
|
||||
|
||||
### Requirements:
|
||||
|
||||
The party releasing the app MUST possess a certificate for the Apple Push Notification service and it MUST run a
|
||||
[gorush](https://github.com/appleboy/gorush) publicly accessible server for sending the actual notification.
|
||||
The party releasing the app MUST run its own [gorush](https://github.com/appleboy/gorush).
|
||||
|
||||
## Push Notification Server Flow
|
||||
### Registration Process:
|
||||
|
||||
|
||||
|
||||
### Sending and Receiving Notification Process:
|
||||
|
||||
|
||||
|
||||
|
||||
## Registering Client
|
||||
Registering a client with a push notification service.
|
||||
|
||||
- A client MAY register with one or more push notification services in order to increase availability.
|
||||
|
||||
- A client SHOULD make sure that all the notification services they registered with have the same information about their tokens.
|
||||
|
||||
- A `PNR message` (Push Notification Registration) MUST be sent to the
|
||||
[partitioned topic](/spec/54/) for the public key of the node, encrypted with this key.
|
||||
|
||||
- The message MUST be wrapped in a [`ApplicationMetadataMessage`](/spec/62) with type set to `PUSH_NOTIFICATION_REGISTRATION`.
|
||||
|
||||
- The marshaled protobuf payload MUST also be encrypted with AES-GCM using the Diffie–Hellman key generated from the client and server identity.
|
||||
This is done in order to ensure that the extracted key from the signature will be considered invalid if it can’t decrypt the payload.
|
||||
|
||||
The content of the message MUST contain the following [protobuf record](https://developers.google.com/protocol-buffers/):
|
||||
|
||||
```protobuf
|
||||
message PushNotificationRegistration {
|
||||
enum TokenType {
|
||||
UNKNOWN_TOKEN_TYPE = 0;
|
||||
APN_TOKEN = 1;
|
||||
FIREBASE_TOKEN = 2;
|
||||
}
|
||||
TokenType token_type = 1;
|
||||
string device_token = 2;
|
||||
string installation_id = 3;
|
||||
string access_token = 4;
|
||||
bool enabled = 5;
|
||||
uint64 version = 6;
|
||||
repeated bytes allowed_key_list = 7;
|
||||
repeated bytes blocked_chat_list = 8;
|
||||
bool unregister = 9;
|
||||
bytes grant = 10;
|
||||
bool allow_from_contacts_only = 11;
|
||||
string apn_topic = 12;
|
||||
bool block_mentions = 13;
|
||||
repeated bytes allowed_mentions_chat_list = 14;
|
||||
}
|
||||
```
|
||||
|
||||
A push notification server will handle the message according to the following rules:
|
||||
- it MUST extract the public key of the sender from the signature and verify that the payload can be decrypted successfully.
|
||||
|
||||
- it MUST verify that `token_type` is supported.
|
||||
|
||||
- it MUST verify that `device_token` is non empty.
|
||||
|
||||
- it MUST verify that `installation_id` is non empty.
|
||||
|
||||
- it MUST verify that `version` is non-zero and greater than the currently stored version for the public key and `installation_id` of the sender, if any.
|
||||
|
||||
- it MUST verify that `grant` is non empty and according to the Grant Server specs.
|
||||
|
||||
- it MUST verify that `access_token` is a valid uuid.
|
||||
|
||||
- it MUST verify that `apn_topic` is set if token_type is APN_TOKEN.
|
||||
|
||||
- The message MUST be wrapped in a [`ApplicationMetadataMessage`](/spec/62) with type set to `PUSH_NOTIFICATION_REGISTRATION_RESPONSE`.
|
||||
|
||||
The payload of the response is:
|
||||
|
||||
```protobuf
|
||||
message PushNotificationRegistrationResponse {
|
||||
bool success = 1;
|
||||
ErrorType error = 2;
|
||||
bytes request_id = 3;
|
||||
|
||||
enum ErrorType {
|
||||
UNKNOWN_ERROR_TYPE = 0;
|
||||
MALFORMED_MESSAGE = 1;
|
||||
VERSION_MISMATCH = 2;
|
||||
UNSUPPORTED_TOKEN_TYPE = 3;
|
||||
INTERNAL_ERROR = 4;
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
A client SHOULD listen for a response sent on the [partitioned topic](/spec/54/) that the key used to register.
|
||||
If success is true the client has registered successfully.
|
||||
|
||||
If `success` is `false`:
|
||||
> If `MALFORMED_MESSAGE` is returned, the request SHOULD NOT be retried without ensuring that it is correctly formed.
|
||||
> If `INTERNAL_ERROR` is returned, the request MAY be retried, but the client MUST backoff exponentially.
|
||||
|
||||
### Handle Errors:
|
||||
- If the message can’t be decrypted, the message MUST be discarded.
|
||||
|
||||
- If `token_type` is not supported, a response MUST be sent with `error` set to `UNSUPPORTED_TOKEN_TYPE`.
|
||||
|
||||
- If `token`, `installation_id`, `device_tokens`, `version` are empty, a response MUST be sent with `error` set to `MALFORMED_MESSAGE`.
|
||||
|
||||
- If the `version` is equal or less than the currently stored `version`, a response MUST be sent with `error` set to `VERSION_MISMATCH`.
|
||||
|
||||
- If any other error occurs the `error` SHOULD be set to `INTERNAL_ERROR`.
|
||||
|
||||
- If the response is successful `success` MUST be set to `true` otherwise a response MUST be sent with `success` set to `false`.
|
||||
|
||||
- `request_id` SHOULD be set to the [`SHAKE-256`](https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.202.pdf) of the encrypted payload.
|
||||
|
||||
- The response MUST be sent on the [partitioned topic](/spec/54/) of the sender and
|
||||
MUST not be encrypted using the secure transport to facilitate the usage of ephemeral keys.
|
||||
|
||||
- If no response is returned, the request SHOULD be considered failed and
|
||||
MAY be retried with the same server or a different one, but clients
|
||||
MUST exponentially backoff after each trial.
|
||||
|
||||
## Push Notification Server
|
||||
A node that handles receiving and sending push notifications for clients.
|
||||
|
||||
### Query Topic:
|
||||
On successful registration the server MUST be listening to the topic derived from:
|
||||
> `0x` + HexEncode(Shake256(CompressedClientPublicKey))
|
||||
|
||||
Using the topic derivation algorithm described here and listen for client queries.
|
||||
|
||||
### Server Grant:
|
||||
A client MUST authorize a push notification server to send them push notifications.
|
||||
This is done by building a grant which is specific to a given client-server pair.
|
||||
When receiving a grant, the server MUST validate that the signature matches the registering client.
|
||||
|
||||
The grant is built as:<br />
|
||||
`Signature(Keccak256(CompressedPublicKeyOfClient . CompressedPublicKeyOfServer . AccessToken), PrivateKeyOfClient)`
|
||||
|
||||
### Unregistering with a Server:
|
||||
- To unregister a client MUST send a `PushNotificationRegistration` request as described above with `unregister` set
|
||||
to `true`, or removing their device information.
|
||||
- The server MUST remove all data about this user if `unregistering` is `true`, apart from the `hash` of the public key and
|
||||
the `version` of the last options, in order to make sure that old messages are not processed.
|
||||
- A client MAY unregister from a server on explicit logout if multiple chat keys are used on a single device.
|
||||
|
||||
### Re-registering with a Server:
|
||||
- A client SHOULD re-register with the node if the APN or FIREBASE token changes.
|
||||
- When re-registering a client SHOULD ensure that it has the most up-to-date `PushNotificationRegistration` and
|
||||
increment `version` if necessary.
|
||||
- Once re-registered, a client SHOULD advertise the changes.
|
||||
Changing options is handled the same as re-registering.
|
||||
|
||||
### Advertising a Server:
|
||||
Each user registered with one or more push notification servers
|
||||
SHOULD advertise periodically the push notification services they have registered with for each device they own.
|
||||
|
||||
```protobuf
|
||||
message PushNotificationQueryInfo {
|
||||
string access_token = 1;
|
||||
string installation_id = 2;
|
||||
bytes public_key = 3;
|
||||
repeated bytes allowed_user_list = 4;
|
||||
bytes grant = 5;
|
||||
uint64 version = 6;
|
||||
bytes server_public_key = 7;
|
||||
}
|
||||
|
||||
message ContactCodeAdvertisement {
|
||||
repeated PushNotificationQueryInfo push_notification_info = 1;
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
### Handle Advertisement Message:
|
||||
- The message MUST be wrapped in a [`ApplicationMetadataMessage`](/spec/62) with type set to `PUSH_NOTIFICATION_QUERY_INFO`.
|
||||
- If no filtering is done based on public keys, the access token SHOULD be included in the advertisement.
|
||||
Otherwise it SHOULD be left empty.
|
||||
- This SHOULD be advertised on the [contact code topic](/spec/53/) and
|
||||
SHOULD be coupled with normal contact-code advertisement.
|
||||
- When a user register or re-register with a push notification service, their contact-code SHOULD be re-advertised.
|
||||
- Multiple servers MAY be advertised for the same installation_id for redundancy reasons.
|
||||
|
||||
### Discovering a Server:
|
||||
To discover a push notification service for a given user, their
|
||||
[contact code topic](/spec/53/) SHOULD be listened to.
|
||||
A Waku-Store node can be queried for the specific topic to retrieve the most up-to-date contact code.
|
||||
|
||||
### Querying a Server:
|
||||
If a token is not present in the latest advertisement for a user, the server SHOULD be queried directly.
|
||||
|
||||
To query a server a message:
|
||||
|
||||
```protobuf
|
||||
message PushNotificationQuery {
|
||||
repeated bytes public_keys = 1;
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
### Handle Query Message:
|
||||
- The message MUST be wrapped in a [`ApplicationMetadataMessage`](/spec/62) with type set to `PUSH_NOTIFICATION_QUERY`.
|
||||
- it MUST be sent to the server on the topic derived from the hashed public key of the key we are querying,
|
||||
[as described above](#query-topic).
|
||||
- An ephemeral key SHOULD be used and SHOULD NOT be encrypted using the [secure transport](/spec/53/).
|
||||
|
||||
If the server has information about the client a response MUST be sent:
|
||||
|
||||
```protobuf
|
||||
message PushNotificationQueryInfo {
|
||||
string access_token = 1;
|
||||
string installation_id = 2;
|
||||
bytes public_key = 3;
|
||||
repeated bytes allowed_user_list = 4;
|
||||
bytes grant = 5;
|
||||
uint64 version = 6;
|
||||
bytes server_public_key = 7;
|
||||
}
|
||||
|
||||
message PushNotificationQueryResponse {
|
||||
repeated PushNotificationQueryInfo info = 1;
|
||||
bytes message_id = 2;
|
||||
bool success = 3;
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
### Handle Query Response:
|
||||
- A `PushNotificationQueryResponse` message MUST be wrapped in a
|
||||
[`ApplicationMetadataMessage`](/spec/62) with type set to `PUSH_NOTIFICATION_QUERY_RESPONSE`.
|
||||
Otherwise a response MUST NOT be sent.
|
||||
|
||||
- If `allowed_key_list` is not set `access_token` MUST be set and `allowed_key_list` MUST NOT be set.
|
||||
|
||||
- If `allowed_key_list` is set `allowed_key_list` MUST be set and `access_token` MUST NOT be set.
|
||||
|
||||
- If `access_token` is returned, the `access_token` SHOULD be used to send push notifications.
|
||||
|
||||
- If `allowed_key_list` are returned, the client SHOULD decrypt each token by generating an `AES-GCM` symmetric key from the Diffie–Hellman between the target client and itself.
|
||||
If AES decryption succeeds it will return a valid `uuid` which is what is used for access_token.
|
||||
The token SHOULD be used to send push notifications.
|
||||
|
||||
- The response MUST be sent on the [partitioned topic](/spec/54/) of the sender and
|
||||
MUST NOT be encrypted using the [secure transport](/spec/53/) to facilitate the usage of ephemeral keys.
|
||||
|
||||
- On receiving a response a client MUST verify `grant` to ensure that the server has been authorized to send push notification to a given client.
|
||||
|
||||
## Sending Client
|
||||
Sending a push notification
|
||||
|
||||
- When sending a push notification, only the `installation_id` for the devices targeted by the message SHOULD be used.
|
||||
|
||||
- If a message is for all the user devices, all the `installation_id` known to the client MAY be used.
|
||||
|
||||
- The number of devices MAY be capped in order to reduce resource consumption.
|
||||
|
||||
- At least 3 devices SHOULD be targeted, ordered by last activity.
|
||||
|
||||
- For any device that a token is available, or that
|
||||
a token is successfully queried,
|
||||
a push notification message SHOULD be sent to the corresponding push notification server.
|
||||
|
||||
```protobuf
|
||||
message PushNotification {
|
||||
string access_token = 1;
|
||||
string chat_id = 2;
|
||||
bytes public_key = 3;
|
||||
string installation_id = 4;
|
||||
bytes message = 5;
|
||||
PushNotificationType type = 6;
|
||||
enum PushNotificationType {
|
||||
UNKNOWN_PUSH_NOTIFICATION_TYPE = 0;
|
||||
MESSAGE = 1;
|
||||
MENTION = 2;
|
||||
}
|
||||
bytes author = 7;
|
||||
}
|
||||
|
||||
message PushNotificationRequest {
|
||||
repeated PushNotification requests = 1;
|
||||
bytes message_id = 2;
|
||||
}
|
||||
|
||||
```
|
||||
### Handle Notification Request:
|
||||
- A `PushNotificationRequest` message MUST be wrapped in a
|
||||
[`ApplicationMetadataMessage`](/spec/62) with type set to `PUSH_NOTIFICATION_REQUEST`.
|
||||
|
||||
- Where `message` is the encrypted payload of the message and `chat_id` is the `SHAKE-256` of the `chat_id`.
|
||||
`message_id` is the id of the message `author` is the `SHAKE-256` of the public key of the sender.
|
||||
|
||||
- If multiple server are available for a given push notification, only one notification MUST be sent.
|
||||
|
||||
- If no response is received a client SHOULD wait at least 3 seconds,
|
||||
after which the request MAY be retried against a different server.
|
||||
|
||||
- This message SHOULD be sent using an ephemeral key.
|
||||
|
||||
On receiving the message, the push notification server MUST validate the access token.
|
||||
If the access token is valid, a notification MUST be sent to the
|
||||
[gorush](https://github.com/appleboy/gorush) instance with the following data:
|
||||
|
||||
```yaml
|
||||
{
|
||||
"notifications": [
|
||||
{
|
||||
"tokens": ["token_a", "token_b"],
|
||||
"platform": 1,
|
||||
"message": "You have a new message",
|
||||
"data": {
|
||||
"chat_id": chat_id,
|
||||
"message": message,
|
||||
"installation_ids": [installation_id_1, installation_id_2]
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
Where platform is 1 for iOS and 2 for Firebase, according to the [gorush documentation](https://github.com/appleboy/gorush).
|
||||
|
||||
A server MUST return a response message:
|
||||
|
||||
```protobuf
|
||||
message PushNotificationReport {
|
||||
bool success = 1;
|
||||
ErrorType error = 2;
|
||||
enum ErrorType {
|
||||
UNKNOWN_ERROR_TYPE = 0;
|
||||
WRONG_TOKEN = 1;
|
||||
INTERNAL_ERROR = 2;
|
||||
NOT_REGISTERED = 3;
|
||||
}
|
||||
bytes public_key = 3;
|
||||
string installation_id = 4;
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
```protobuf
|
||||
message PushNotificationResponse {
|
||||
bytes message_id = 1;
|
||||
repeated PushNotificationReport reports = 2;
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
Where `message_id` is the `message_id` sent by the client.
|
||||
|
||||
### Handle Notification Response:
|
||||
- A `PushNotificationResponse` message MUST be wrapped in a [`ApplicationMetadataMessage`](/spec/62) with type set to `PUSH_NOTIFICATION_RESPONSE`.
|
||||
|
||||
- The response MUST be sent on the [partitioned topic](/spec/54/) of the sender and
|
||||
MUST not be encrypted using the [secure transport](/spec/53/) to facilitate the usage of ephemeral keys.
|
||||
|
||||
- If the request is accepted `success` MUST be set to `true`. Otherwise `success` MUST be set to `false`.
|
||||
|
||||
- If `error` is `BAD_TOKEN` the client MAY query again the server for the token and retry the request.
|
||||
|
||||
- If `error` is `INTERNAL_ERROR` the client MAY retry the request.
|
||||
|
||||
## Protobuf Description
|
||||
|
||||
### PushNotificationRegistration:
|
||||
`token_type`: the type of token. Currently supported is `APN_TOKEN` for Apple Push.<br />
|
||||
`device_token`: the actual push notification token sent by `Firebase` or `APN` and `FIREBASE_TOKEN` for firebase.<br />
|
||||
`installation_id`: the `installation_id` of the device.<br />
|
||||
`access_token`: the access token that will be given to clients to send push notifications.<br />
|
||||
`enabled`: whether the device wants to be sent push notifications.<br />
|
||||
`version`: a monotonically increasing number identifying the current `PushNotificationRegistration`.
|
||||
Any time anything is changed in the record it MUST be increased by the client, otherwise the request will not be accepted.<br />
|
||||
`allowed_key_list`: a list of `access_token` encrypted with the AES key generated by Diffie–Hellman between the publisher and the
|
||||
allowed contact.<br />
|
||||
`blocked_chat_list`: a list of `SHA2-256` hashes of chat ids. Any chat id in this list will not trigger a notification.<br />
|
||||
`unregister`: whether the account should be unregistered.<br />
|
||||
`grant`: the grant for this specific server.<br />
|
||||
`allow_from_contacts_only`: whether the client only wants push notifications from contacts.<br />
|
||||
`apn_topic`: the APN topic for the push notification.<br />
|
||||
`block_mentions`: whether the client does not want to be notified on mentions.<br />
|
||||
`allowed_mentions_chat_list`: a list of SHA2-256 hashes of chat ids where we want to receive mentions.<br />
|
||||
|
||||
DATA DISCLOSED
|
||||
- Type of device owned by a given user.
|
||||
|
||||
- The `FIREBASE` or `APN` push notification token,
|
||||
|
||||
- Hash of the `chat_id` a user is not interested in for notifications,
|
||||
|
||||
- The number of times a push notification record has been modified by the user,
|
||||
|
||||
- The number of contacts a client has, in case `allowed_key_list` is set.
|
||||
|
||||
### PushNotificationRegistrationResponse:
|
||||
`success`: whether the registration was successful<br />
|
||||
`error`: the error type, if any<br />
|
||||
`request_id`: the `SHAKE-256` hash of the `signature` of the request<br />
|
||||
`preferences`: the server stored preferences in case of an error<br />
|
||||
|
||||
### ContactCodeAdvertisement:
|
||||
`push_notification_info`: the information for each device advertised
|
||||
|
||||
DATA DISCLOSED
|
||||
- The chat key of the sender
|
||||
|
||||
### PushNotificationQuery:
|
||||
`public_keys`: the `SHAKE-256` of the public keys the client is interested in
|
||||
|
||||
DATA DISCLOSED
|
||||
- The hash of the public keys the client is interested in
|
||||
|
||||
### PushNotificationQueryInfo:
|
||||
`access_token`: the access token used to send a push notification<br />
|
||||
`installation_id`: the `installation_id` of the device associated with the `access_token`<br />
|
||||
`public_key`: the `SHAKE-256` of the public key associated with this `access_token` and `installation_id`.<br />
|
||||
`allowed_key_list`: a list of encrypted access tokens to be returned to the client in case there’s any filtering on public keys in place.<br />
|
||||
`grant`: the grant used to register with this server.<br />
|
||||
`version`: the version of the registration on the server.<br />
|
||||
`server_public_key`: the compressed public key of the server.<br />
|
||||
|
||||
### PushNotificationQueryResponse:
|
||||
`info`: a list of `PushNotificationQueryInfo`.<br />
|
||||
`message_id`: the message id of the `PushNotificationQueryInfo` the server is replying to.<br />
|
||||
`success`: whether the query was successful.<br />
|
||||
|
||||
### PushNotification:
|
||||
`access_token`: the access token used to send a push notification.<br />
|
||||
`chat_id`: the `SHAKE-256` of the `chat_id`.<br />
|
||||
`public_key`: the `SHAKE-256` of the compressed public key of the receiving client.<br />
|
||||
`installation_id`: the `installation_id` of the receiving client.<br />
|
||||
`message`: the encrypted message that is being notified on.<br />
|
||||
`type`: the type of the push notification, either `MESSAGE` or `MENTION`<br />
|
||||
`author`: the `SHAKE-256` of the public key of the sender
|
||||
|
||||
Data disclosed
|
||||
- The `SHAKE-256` hash of the `chat_id` the notification is to be sent for
|
||||
|
||||
- The cypher text of the message
|
||||
|
||||
- The `SHAKE-256` hash of the public key of the sender
|
||||
|
||||
- The type of notification
|
||||
|
||||
### PushNotificationRequest:
|
||||
`requests`: a list of PushNotification<br />
|
||||
`message_id`: the [Status message id](/spec/62)
|
||||
|
||||
Data disclosed
|
||||
- The status `message_id` for which the notification is for
|
||||
|
||||
### PushNotificationResponse:
|
||||
`message_id`: the `message_id` being notified on.<br />
|
||||
`reports`: a list of `PushNotificationReport`
|
||||
|
||||
### PushNotificationReport:
|
||||
`success`: whether the push notification was successful.<br />
|
||||
`error`: the type of the error in case of failure.<br />
|
||||
`public_key`: the public key of the user being notified.<br />
|
||||
`installation_id`: the `installation_id` of the user being notified.
|
||||
|
||||
## Anonymous Mode
|
||||
In order to preserve privacy, the client MAY provide anonymous mode of operations to propagate information about the user.
|
||||
A client in anonymous mode can register with the server using a key that is different from their chat key.
|
||||
This will hide their real chat key. This public key is effectively a secret and
|
||||
SHOULD only be disclosed to clients approved to notify a user.
|
||||
|
||||
- A client MAY advertise the access token on the [contact-code topic](/spec/53/) of the key generated.
|
||||
|
||||
- A client MAY share their public key contact updates in the [protobuf record](https://developers.google.com/protocol-buffers/).
|
||||
|
||||
- A client receiving a push notification public key SHOULD listen to the contact code topic of the push notification public key for updates.
|
||||
|
||||
The method described above effectively does not share the identity of the sender nor the receiver to the server, but
|
||||
MAY result in missing push notifications as the propagation of the secret is left to the client.
|
||||
This can be mitigated by [device syncing](/spec/62), but not completely addressed.
|
||||
|
||||
# Security/Privacy Considerations
|
||||
If anonymous mode is not used, when registering with a push notification service a client will disclose:
|
||||
- The devices that will receive notifications.
|
||||
|
||||
- The chat key.
|
||||
|
||||
A client MAY disclose:
|
||||
- The hash of the `chat_id` they want to filter out.
|
||||
|
||||
When running in anonymous mode, the client’s chat key is not disclosed.
|
||||
|
||||
When querying a push notification server a client will disclose:
|
||||
- That it is interested in sending push notification to another client, but
|
||||
querying client’s chat key is not disclosed.
|
||||
|
||||
When sending a push notification a client will disclose:
|
||||
- The `shake-256` of the `chat_id`.
|
||||
|
||||
# Copyright
|
||||
|
||||
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
|
||||
|
||||
# References
|
||||
1. [PUSH-NOTIFICATION-SERVER, Initial Specification](https://github.com/status-im/specs/blob/master/docs/raw/push-notification-server.md)
|
||||
2. [Push Notification, Apple Developer](https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_ref/doc/uid/TP40008194-CH8-SW1)
|
||||
3. [Firebase](https://firebase.google.com)
|
||||
4. [13/WAKU2-STORE](/spec/13/)
|
||||
5. [gorush](https://github.com/appleboy/gorush)
|
||||
6. [54/WAKU2-X3DH-SESSIONS](/spec/54/)
|
||||
7. [62/PAYLOAD](/spec/62)
|
||||
8. [SHAKE-256](https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.202.pdf)
|
||||
9. [Protocol Buffers](https://developers.google.com/protocol-buffers)
|
||||
10. [53/WAKU2-X3DH](/spec/53/)
|
||||
|
||||
|
|
@ -28,6 +28,7 @@ bookMenuLevels: 1
|
|||
- [64/WAKU2-NETWORK]({{< relref "/docs/rfcs/64/README.md" >}})
|
||||
- [66/WAKU2-METADATA]({{< relref "/docs/rfcs/66/README.md" >}})
|
||||
- [70/ETH-SECPM]({{< relref "/docs/rfcs/70/README.md" >}})
|
||||
- [71/STATUS-PUSH-NOTIFICATION-SERVER]({{< relref "/docs/rfcs/71/README.md" >}})
|
||||
- Draft
|
||||
- [1/COSS]({{< relref "/docs/rfcs/1/README.md" >}})
|
||||
- [3/REMOTE-LOG]({{< relref "/docs/rfcs/3/README.md" >}})
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 59 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 25 KiB |
Loading…
Reference in New Issue