Page MenuHomePhabricator

Investigate using service workers to provide real-time Echo notifications in the browser (push notifications)
Open, LowestPublic

Related Objects

StatusSubtypeAssignedTask
ResolvedNone
InvalidNone
InvalidWikinaut
OpenNone
OpenFeatureNone
Resolved demon
DuplicateNone
Declined Quiddity
ResolvedNone
ResolvedGalorefitz
DeclinedNone
OpenFeatureNone
Resolvedkostajh
OpenNone
StalledNone
OpenNone
ResolvedLGoto
OpenNone

Event Timeline

Legoktm raised the priority of this task from to Lowest.
Legoktm updated the task description. (Show Details)
Legoktm added a project: Notifications.
Legoktm added subscribers: Legoktm, ori, Mooeypoo.
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Legoktm renamed this task from Investigate using service workers to provide real-time Echo notifications in the browser to Investigate using service workers to provide real-time Echo notifications in the browser (push notifications).Feb 17 2016, 11:05 PM
Legoktm set Security to None.

If anyone is interested I believe I have a good grasp of the requirements for this. I've been experimenting with this on pushipedia.wmflabs.org and trending.wmflabs.org

I played with push notifications over the past week in a non-MediaWiki related project, and was surprised at how powerful and easy to use they were.

We'll need to generate a public and private key, public key is served to users via JS, and private key is only used server-side.

Since we need a service worker, we probably only want to register it on one wiki (meta). Either as part of Special:Preferences or a separate Special:PushNotifications, there can be a user that users click on to install the service worker and asks the user's browser if we can send them notifications. Note that this preference is per-browser, which is why I didn't think it really fit in Special:Preferences.

If they agree to the notifications, we get a JS object that needs to be saved server-side - we can do that with an API call and a hidden preference maybe. (Probably a database table long-term?)

On the server-side we'll probably use a library like https://github.com/web-push-libs/web-push-php. And while data is sent encrypted, we can avoid sending any private data over 3rd party servers (operated via Mozilla or Google) by just sending the notification ID, and having the service worker make an API request to get the notification details, and then displaying an appropriate notification.

The storage requirements are the main thing that was blocking reading from doing anything here. Note you'd need to store a key for every service using push notifications (we'd not want to limit exclusively to Echo as that would limit us considerably to logged in users) and yes a new database would be ideal.

Current possible use cases off top of my head:

  • tell me when a page is trending
  • send me push notifications for my Echo notifications
  • send me a push notification when this page is edited
  • notify me about the featured article of the day (T108880)
  • notify me about the picture of the day
  • notify me every 3 months about donating

You might want to check the work already done by the services team here: https://phabricator.wikimedia.org/project/view/2699/ - there's a few docs on relevant tickets.

When I chatted to Mozilla about push, they were a little concerned about the traffic (note that since Firefox follows the spec, unlike Google which relies on gcm every subscriber needs to hit the Mozilla api endpoint. We'd need to stagger those requests rather than fire them off in one go.

The storage requirements are the main thing that was blocking reading from doing anything here. Note you'd need to store a key for every service using push notifications (we'd not want to limit exclusively to Echo as that would limit us considerably to logged in users) and yes a new database would be ideal.

This task is focused on just serving Echo notifications via HTTP push notifications. I'm sure there are cases outside of just logged in users, but we probably want to start with a smaller scope and expand if that is successful.

You might want to check the work already done by the services team here: https://phabricator.wikimedia.org/project/view/2699/ - there's a few docs on relevant tickets.

I glanced, but that seems significantly over complicated for what needs to be done for this ticket. There's no need for an alternative storage system or API, Echo already has all of those.

When I chatted to Mozilla about push, they were a little concerned about the traffic (note that since Firefox follows the spec, unlike Google which relies on gcm every subscriber needs to hit the Mozilla api endpoint. We'd need to stagger those requests rather than fire them off in one go.

AFAIK Google follows the same spec as Mozilla and our code won't differ at all for Firefox vs Chromium users. We can definitely implement rate limiting via PoolCounter though.

AFAIK Google follows the same spec as Mozilla and our code won't differ at all for Firefox vs Chromium users. We can definitely implement rate limiting via PoolCounter though.

Yes but the way they use their endpoints differs. Google does not follow the spec here.
Say you want to ping 50 users (say this is stored in a variable pingedIds)

For Google you'd send

			{
				"registration_ids": pingedIds
			}

in a single request to https://android.googleapis.com/gcm/send

However with Firefox you'd need to do 50 requests
e.g.

for( i = 0; i < pingedIds.length; i++ ) {
	 endpoint = 'https://updates.push.services.mozilla.com/push/' + pingedIds[i];
       ping(endpoint);
}

Most libraries you use will abstract this away for you, but please be aware of how it's happening if you are doing 1 to many broadcasts.

Gotcha. But I don't think we'll be using GCM here. When I use Chromium and register a push notification handler I get an endpoint URL like https://fcm.googleapis.com/fcm/send/<long_hash> (and Firefox gives a URL like https://updates.push.services.mozilla.com/wpush/v2/<longhash>).

Gotcha. But I don't think we'll be using GCM here

Hmm seems like chrome updated things from back when I used it so that's one less problem (also explains why my push notifications broke on one of my apps!) :) (but still we need to be careful when we broadcast but sounds like you have a handle on that)

but we probably want to start with a smaller scope and expand if that is successful.

Definitely and I think if you are using Special:Preferences this doesn't apply.

But.... if for whatever reason you go down the database route (e.g. want to support anons) please do think about the architecture here for them before storing anything as you'll be creating lots of work on the long term. Otherwise we'll be spending lots of time if this is successful - which I'm sure it will be - trying to untangle this. I think we are thinking along the same lines but I just want to make sure?

Change 371615 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/Echo@master] [WIP] Push notifications

https://gerrit.wikimedia.org/r/371615

kostajh added a subscriber: Catrope.

@Catrope and I might work on this at the hackathon, other collaborators welcome!

JTannerWMF subscribed.

This is in the realm of Hackathon.

Change 371615 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/Echo@master] [WIP] Push notifications

https://gerrit.wikimedia.org/r/371615

Trizek-WMF moved this task from To Triage to Not ready to announce on the User-notice board.
Trizek-WMF subscribed.

In short for Tech News: "In-browser push notifications for Echo"