In your vault, each account can specify what server will be handling notifications.

If not specified, we fall back to the notify service from your identity server, or hyper.media/notify where our notification service will live. For now, we can skip the configuration feature, and use the same server as your identity server. If you have no identity server (you are using the mnemonic keys), then you can opt-in to our central notify server.

To change notification settings, you sign your notify configuration and send it to your notify server. This will include app and email notification settings.

To read notification settings, you will sign a request and send it to the notify server, who will tell you the notification info.

There will be additional signed messages that you send to the notify server for associating an email. You can set, change, or remove your email by signing a message and sending your email to the notify server.

The notify server will respond with the validation status, which will be false until the user has clicked the validation link.

When you read a notification from any platform, you will sign a message that says "I read this" and send it to your notify server.

To know what you have read or not, you will sign a message saying "What do I have as unread?" and send it to the notification server, who will give you your read/unread status.

When a user clicks a link from email, we will track that event as "read", so it will appear as read from your desktop app and web UI.

This may be super fine-grained in the future, like: notify me immediately if somebody responds to this comment. Or, notify me if somebody mentions me in this document, but nowhere else. For now we will keep things pretty simple, but we should anticipate the schema of fine-grained notify settings, so we won't have to perform migrations in the future.

Do we save a list of unreads? (that is how the desktop app works right now). Or do we have a more sophisticated method?