14 · Notifications

Notifications are the most formally demanding part of the engine, because the standard permits no shortcuts. The payload has to be encrypted with the particular recipient's key, the request signed with the site's key pair, and all of it conformant with a specification that does not forgive being one byte out.

Subscriptions live in the instance's database. The public key is public by nature, since it goes to the browser; the private key exists only as a secret on the platform side and is never in the repository.

The most interesting thing here is a decision forced by the constraint from the third entry: there are no processes living in the background, so there is nothing to wake at dawn and check whether a new entry exists. The solution is to attach that check to traffic that arrives anyway. While handling a request, the engine checks — rate limited, so as not to do it constantly — whether an entry has appeared that nobody was notified about.

This has a consequence that deserves an honest name: a notification for an entry published at dawn goes out on the first request after that hour, not on the hour. On a site with any traffic the difference is minutes. On a site with no traffic the notification waits for the first reader — which is logical, because there is nobody to deliver it to.

The alternative would be an external scheduled job. We chose the solution with no dependency, because a dependency that has to stay alive for the product to work is a maintenance cost forever.