Problem

We often find it difficult to see what is new on the sites+documents we care about. Also it is easy to miss mentions and replies. We may have email notifications set up, but the notifications are not aggregated anywhere in the UI, like they are on linear or github.

Solution

Generally, there needs to be an approach that allows syncing of notification state between devices. This can be handled by a centralized solution, or with a lot more work, a decentralized inbox is possible.

In any case, we would introduce a new Inbox to the main navigation sidebar of the desktop app, and the inbox would also be available on web.

Option A - TypeScript solution

This proposal involves a centralized server to track read state across all devices and web.

We would add a table on the notification server to keep track of all notifications. Every notification to each account would be added to a single table at the time when it happens.

The notification code would share logic with the email notification system. For the first implementation, notification settings would apply to both emails and the inbox. If you don't want to receive emails, you'd remove the email address for your account.

The TypeScript "middle end" of the electron app would have a mirror of the notifs DB for your local accounts, so that the inbox continues working when offline. This would sync read state with the server. Notifications would be saved offline and would save read state. But new notifications would only be created from the centralized (gateway) server.

We would use the same approach to authenticate to the server as we do for notification settings. Each request would be timestamped and signed by the local account key, and validated on the server to make sure you are allowed to configure and retrieve notifications.

Alternatively, the inbox could be entirely dependent on the server with no local db mirror. This is an easier implementation but results in an entirely broken inbox when the device is disconnected from the central server.

Option B - Golang Daemon solution

The go server could also manage notifications. This could use a centralized server built in TS or golang.

Or, the notifications system could work entirely decentralized. This has obvious benefits but would be more difficult to implement. It would privately sync notification settings and "is read" state to other devices with the same account key (or agents). The indexing process would check to see if a notification should be generated based on the new information. As a result, you must be subscribed to everything that you are getting notified for.

This is a more elegant solution because it would effectively mean that subscriptions are synced to several devices. To "enable notifications" you must be "subscribed".

Rabbit Holes / Concerns

There is no garbage collection- so notifications will pile up forever in the server.

If we are not careful, its possible for notifications to come in without the required reference materials. This would result in a bad user experience. So, the middle end would be responsible for downloading reference materials before showing the notification to the user.

This is not a problem in the case of decentralized notifications, but it needs to ensure that we do p2p subscription+syncing for all content where notifications is enabled.

If there are decentralized notifications, the read state needs to be securely synced between authorized devices. Maybe this could share the same infrastructure as the upcoming syncing of private documents.