sky: notifications

[bonbud-macryg]

Sky should be the best client for using Urbit, and it should clear this bar soon. One essential part of this is notifications. Sky should store notifications; Sky should be able to make your phone buzz; third-party Urbit developers should be able to make your phone buzz.

This is achievable with a Sky PWA, which is well within our remit with the team and resources we have. With browser notifications and a PWA, we have one system that sends system notifications across macOS, Windows, iOS, Android, and Linux.

Sky notifications should satisfy these requirements:

• [ ] Sky should send system notifications to the user's device.
• [ ] Sky should store notifications in a Notifications tray. This could be the first of several permanent fixtures in the sidebar.
• [ ] Sky should give third-party developers a path to sending system notifications on the user's devices.
• [ ] Developers should find it trivial to work with; the system should be simple, code should be readable, everything should be well documented with copy-paste examples.
• [ ] Read/Unread status should be clear and unambiguous to Sky. I'm thinking every notification should have a path associated with it, and if the user opens that path (or a path below it?) in Sky the notification is marked as read. This is the base case for marking a notification as read.
• [ ] Users should be able to open Sky notifications in their system, and arrive at the relevant path in Sky.
• [ ] Users can manually mark notifications as read. Marking it as read anywhere should mark it as read everywhere.
• [ ] Notifications should probably be permanently archived in chronological order. If this is the reality of what's happening in the user's local namespace, it should be reflected in the UI. Notifications could be archived in an "Archive" tab separated from their main notifications tray.
• [ ] Users should be able to mute and/or block notifications from a specific path, which will also block all notifications from beneath that path in the namespace.
• [ ] There should be a privacy story like Tlon's notifications. If privacy comes at the cost of reliability, the more private notifications system should be opt-in. If privacy comes at no cost to reliability, it should be the default.

[tiller-tolbus]

These are nice long-term goals, but we should be thinking more about immediate next steps.

• what is the data structure of a notification?
• is an overlay necessary for read receipts?

My presumptive answer:

+$  notification  [=pith =time =text]

Missing in the above is read receipts and human-readable names for the addressing of paths. My path forward would be for Sky to later include primitives for tracking all of the page loads in its navigation, and "read" status of a notification will be a function on the path/time of the notification and the last known load of that path. Human-readable names will also be an overlay namespace, where a path can be configured to have a name and icon for the purposes of both notifications and the navigation bar. Ex. /home/dm/~zod would be assigned a human-readable name like "Messages with ~zod".

With this presumptive answer, we should instantiate a home/notifications and try a flow with something like imp/dm to hook into home/notifications as a dependency and send alerts when a new message is received. A con/notifications-htmx can be an "administrative view" of the notification tray.