TLDR; Decentralized applications need (mobile) notifications that arrive with certainty at a group of devices.
Notification systems for mobile devices and desktops are required to be tunneled through the services by Google and Apple. These services are deeply tied to the the Developer ID, making the developer ID responsible for abuse. This means: any decentralized application needs a centralized server setup for notifications. 😔
The goal is to provide a zero-knowledge, efficient notification server that can pass notifications from one client to another without being able to look inside the envelope while still preventing spam to clients. The server is to utilize WebSockets when the application is in the foreground for quicker processing and to only use push services when necessary.
We are particularly motivated to see the Signal Notification System. It functions similar to what we have in mind. It is quick and proven in practice but it lacks a few details important to use. It stops a little short in terms of the security we need.
With the v2 of the Consento Notification server we would like to make it as usable for any kind of future Notification system.
For the first version of Consento we already developed a notification-server which taught us important lessons for a second version
- Devices need to be grouped in order to make sure that the notification arrives at the device needed.
- A notification that arrived needs view-receipts in order to stop distributing the notification to unused devices.
- Request Limiting needs to be as restrictive as possible.
- It is a good idea to register devices tokens on every startup.
- Notifications by Apple & Google can not be relied on.
- Restructure notification code to use hypercore synching and groups.
- Enable sharding of the notification servers to remove possible bottle necks.
- Investigate possibility of background notification polling using a DHT instead of signalling servers.