OK, will plan for that – I’ll start migrating the logic into core then.
4 Likes
You mean that as moving all logic into core, or just adding the plugin to core here ?
It makes no sense to maintain code for both doing this the “Web Notification” way and the “Push API” way.
So my call is that we replace the existing code in core with the Push API implementation, so Safari lose out on a feature they used to have till they catch up. AFAIK Safari already support service workers so there could be an easy way to add cross compatibility if we REALLY wanted.
We keep all the UI we have and replace the implementation with push api.
And we correct all copy to reflect this change.
Plugin gets junked.
5 Likes
I discussed this with @tgxworld today on the call and there are complications.
What we have is this:
Current way
-
Every tab listens on message bus
-
If a notification lands, we present to user
-
When all tabs are closed desktop gets no notifications -
Simple with no vendor lock in
Push notification way
-
Service worker registers with Mozilla or Google or Microsoft
-
Server gets a notification for a user
-
Server sends encrypted blob to Mozilla or Google or Microsoft
-
Mozilla or Google or Microsoft send encrypted notification to browser
-
When all tabs are closed desktop still gets notifications
-
vendors like Mozilla etc. have user IP addresses and know when we ship the IP addresses notifications
So it is not clear-cut here, if we move to pure push notifications we give up on privacy which we have no choice on mobile but plenty of choice on Desktop.
I still feel like having 2 ways of doing the same thing is not ideal so my suggestion would be:
Have 1 UI for both features, get rid of plugin
-
On Android where we have no choice we just use the push feature (which uses the same ui we already have).
-
On Desktop
-
Phase 1: we keep exactly what we have now, no changes needed
-
Phase 2: we can look at having the service worker talk directly to message bus so you still get notifications when tabs are closed (which it should probably stop after N hours of not visiting site)
-
Phase 3 (probably next year): centralize all message bus work so it happens from the service worker
-
@codinghorror thoughts?
Note: there was another alternative @tgxworld was going to investigate to see if a Discourse server can act as a push server, but I am not sure this is a 
hole we want to go down.
4 Likes
Yes, this is how I’d like us to handle it as well. Honestly I love the way it works now on laptop / desktop and I’d prefer not to change it, so doing the “special thing” only on Android sounds best to me (and we can extend that to iOS, when Safari eventually supports it).
1 Like
I want to be careful here because phase 2 and phase 3 is not going to be any different from the messageBus approach because of the life cycle that service workers follow.
According to Mozilla’s service worker docs,
Once successfully registered, a service worker can and will be terminated when idle to conserve memory and processor power. An active service worker is automatically restarted to respond to events, such as
ServiceWorkerGlobalScope.onfetchorServiceWorkerGlobalScope.onmessage.
Once a service worker is put in idle, the messageBus subscription to the server would be closed so we’re back to square one here.
Privacy
-
The payloads that we push to the external push services are encrypted. You can read more about the web push payload encryption here.
-
Unfortunately, the chrome team hasn’t published any web push library for Ruby so we’re depending on GitHub - zaru/webpush: webpush, Encryption Utilities for Web Push protocol which handles the encryption for us. The risk here is that there could be a bug and we end up sending un-encrypted data to the push services.
-
The Rails server is now talking to an external service so we’re leaking the IP of the server to the various push services that we depend on.
-
The push services would end up pushing a message to the user’s browser so the client’s IP is leaked as well. In theory, the push services would also be able to track the number of messages being sent to a particular client.
I don’t feel like we actually benefit in terms of privacy by adopting the hybrid approach. Once push notifications has been enabled on mobile, data like “number of messages received” by a client is already being leaked. Having push notifications enabled on desktop just mean that an extra client ip is leaked.
6 Likes
Just like we do with onebox. It’s more controlled because it will be restricted only the browser vendors.
All those “standard” browsers already keep track of those users, like the Google Play Services in Android (which will provide the push service for Chrome).
I feel the same. I think keeping a disable_push_notification switch is enough for people who want to deploy a privacy focused Discourse, much like we did with the private email site setting. The situation here is already way better than email, because we encrypt the payload.
That is up to the user.
A privacy-concerned user can run GitHub - mozilla-services/autopush: Python Web Push Server used by Mozilla and change the value dom.push.serverURL on Firefox about:config.
5 Likes
Oo nice! I was talking to @sam about potentially offering a push service for our customers but I wasn’t able to find an open sourced push server from my brief googling efforts.
5 Likes
Where both me and Jeff are struggling big time is that neither of us particularly feel like desktop notifications are a problem now. I am pretty happy that Chrome does not nag me about stuff on meta when all the tabs to meta are closed.
The proposal here makes Chrome on desktop more “naggy” AND definitely increases the amount of visibility Mozilla / Microsoft and Google have over people using Discourse sites.
Yes, on Android we got to do this. However on Android/iPhone it is already game over. If you want any kind of notifications you are going to have to go via Apple/Google cause that is how the game is played.
The core of my objection here is for Desktop.
-
We (Me and @codinghorror ) don’t really consider it a problem that users are not notified when all tabs to site are closed, in fact I consider this a feature
-
Having notifications go via Google/Microsoft/Mozilla make me uneasy, especially when this is a feature we don’t really feel we need.
My proposal here is.
-
Junk old plugin, bring into core, on Android the whole push notification thing is fine and pretty much the only option we have. We like the idea that an app is less and less required on Android.
-
Introduce a new plugin if you wish for “desktop push notifications” for site admins who want Chrome/Firefox to be more naggy. (possibly make this a per-site switch without a plugin, undecided on this)
-
Unify the UX.
2 Likes
Seeing as we already need to ship this functionality for Android, I think a per-user switch that affects all of your devices is the best. Make it a checkbox, “Receive push notifications even while not on the site” with helper text.
Android would get a … disabled checkbox, or something. I was thinking that out and not quite sure how to represent that. mmmm
Also have a site setting that disables (not enables) this for privacy-sensitive forums.
required states for UI:
Notifications (this device): [[ Enabled | Disabled-LocalStorage | Need-Permission | Denied-Permission ]]
Push notifications (account): [[ Enabled | Disabled | Enabled-Android | Disabled-Android | Enabled-NeedPermission | Enabled-Android-NeedPermission ]]
Desktop:
[[ Notifications button ]]
[ x ] Receive push notifications even while not on the site (account setting)Privacy note: Your browser vendor will be able to see the timing and quantity of notifications you receive.
Android:
[[ Notifications button ]]
<input type=checkbox checked disabled>Receive push notifications even while not on the siteNon-push notifications are not available on Android.
[ x ] Receive push notifications even while not on the site (account setting)
This only applies to your non-Android devices.
3 Likes
Thing is you definitely want that on your Android phone, and you may or may not want it on desktop. So the choice here is per device I guess, which makes things a bit more complicated settings wise.
1 Like
There is a simple way to handle this if the admins are the ones to decide whether they want notifications at all (or not)
Suggestion would be to add two settings as follows:
Setting #1 : Enable Notifications (Global)
Setting #2 : Enable Push notifications for all Devices.
Where the former decides if someone wants notifications for their forum at all or they want them disabled permanently. If enabled, this defaults to Push notifications on mobile and desktop notifications for desktop.
The latter configures everything to be Push notification be it mobile or desktop.
Eventually, admins should decide upon what kind of notifications they want on their forum and the users should be given a notification banner with link to a popup clarifying difference between both.
It’s still better than email, where the payload isn’t even encrypted, and most of my forums’ users are using GMail.
2 Likes
I just want to clarify that even in service worker land, it is possible to have no notifications when there are no windows, just keep track of the # of windows open (count # of clients connected to the service worker) and don’t notify when it’s 0. Personally on mobile I’d like to keep it as it is, as chrome on android has a tendency to clean old/inactive tabs which might play hell with the client counts, cutting your notifications off.
I think the main point issue is the privacy. When and how naggy the messages are is still 100% up to us.
I am already planning on porting over the “when active on the site, do not notify” feature from desktop to the push notifications on android, as I think it’s an excellent way of cutting down on unnecessary spammy notifications.
6 Likes
This feature is enabled by default now. It was enabled here for 6 months, and we got a lot of UX and copy improvements in the meantime. 
8 Likes