The current notification policy sends a notification when a new node is added to local storage that meets the following criteria:
Unfortunately, this means that a user connecting for the very first time from a new device gets notified of every new conversation from the past.
The question is, what's the right policy to suppress this? I think that a sane choice would be to limit notifications for new conversations back to a particular point in time, but which point? 24 hours? What if you just don't open the app for 2 days? Do we care that you miss conversations that occurred a day ago?
We could also try recording the last time you had the app running and notify only for conversations since that point in time. If that point is undefined, then we don't notify at all. This seems compelling, but it may have some downside that I haven't seen yet.
I would like to merge this issue with https://todo.sr.ht/~whereswaldon/arbor-dev/115. My idea is to add a
NotificationPolicyto the settings file at
~/.config/settings.json. Valid settings could be:
noneto have no notifications
launched-onlyto only have notifications for messages sent after the client started
retroactiveto have notifications for all messages since the client closed
I think we will need a more granular set of notification policies. In addition to what we've discussed here so far (time-based metrics), there's also policy around whether a given message warrants a notification. Options there include:
- notify if it's a direct response to me
- notify if it's a descendant of a message I wrote
- notify if it's in any branch of a conversation that I have participated in
- notify if it mentions one of a set of keywords (including my username)
- notify if it's the start of a new conversation
These settings likely need to exist on a per-community basis, and I suspect that the time-based settings would as well.
I guess my overall point is that we probably can't distill the notification policy into a single field in that JSON blob. It will likely be an object with a default policy for each of these settings that can be overridden on a per-community basis (though we may wait to implement this until later).
I do think a master switch for turning notifications off is warranted though. If you'd like to build that ~caton101, be my guest!
The other aspect is that a user normally has more than one device. Does the system have a presence state ? Because then you could control when and where for the notifications also
~athorp96 is working on our presence system right now! Not sure when it will be rolled out, but using that as a way to direct notifications isn't something that we'd discussed before. Great idea!
It will require us to get cross-device identity working more easily (it's a real headache right now), but that's tractable
thanks for the comments.
Cross device. Sometimes you need a Device ID, as well as the UserID. You basically you to know all the devices the user is logged in on.
Also you need to push over a few channels normally due to the many devices world we live in. See: https://github.com/appleboy/gorush
- Where you need to send notifications via the Apple and Google Gateway.
- Used in order to "wake up" you app if you know what i mean.
So as always we have to support native and PWA Service workers perhaps.
With the PWA situation, and the Service Worker allows Web Push Notifications. The OS "should" then allow the notifications to create OS level notifications because the Service Worker is "always on" based on the contract that PWA and Service workers guarantee. See the Gorush Features list where is says "Support Web API to send push notification." - so should work.
IOS Safari is however is a little behind the times here i think. See: https://caniuse.com/#feat=notifications.
- Lets se if Apple play ball going forward. Good chance they will i think. But you never know...
Then you need something on the Server that acts as a store and forward relay. Why ? Because User X writes a chat message to a group and then goes offline, and so the message needs to be delivery to all the others in the group. Whatever way arbor models this as data is nether here nor there - you got to sent something to the other users to tell them about the new data...
One candidate is LiftBridge. See: https://github.com/liftbridge-io/liftbridge The code is very clean and has a simple GRPC API. Its golang all the way down too and designed for HA world. Its basically Kafka but in golang. Also you need to store and forward images data too. Use case woudl be when a user adds a Picture to the chat, and then goes offline. I am currently quite impressed with SeaweedFS. See: https://github.com/chrislusf/seaweedfs/issues/1394
Hope that this is useful for Arbor...
Thank you for all of the links and feedback! Our initial focus is on non-push notifications (just ones sent from the background) because that's significantly simpler. However, we will eventually want push notifications, and I'm curious to look at those resources then.
The store&forward component for messaging will be especially important once direct messaging is implemented. Right now, a message sent within a community is stored (at least temporarily) by the relay that receives it and is additionally stored by each peer online when it is sent. This largely eliminates that class of problem, but will no longer function when messages become private. I'll definitely be looking into these links soon!