XSF Discussion - 2019-06-08

Anybody looked into https://developer.mozilla.org/en-US/docs/Web/API/Push_API and how that would work with 357 (push notifications)? From what I understand we don't need the App Server bits?

>pep.: From what I understand we don't need the App Server bits? I have implemented this with Converse and Openfire. You don't need app server to push the messages. Service worker talks direct to push service. You still need the subscription endpoint data to be stored securely for each client service worker on a server. In my case, I used user properties in Openfire. It would be nice to do a simpler version of XEP 357 for web clients that cuts out the app server and uses PEP or private Storage to store the push subscription endpoint data.

Where is the code? :)

We actually spent time today implementing it again in converse.. (and prosody)

What's a service worker in that context?

JS

https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorker

Dele Olajide, why PEP btw

The client should probably just enable web push each time it connects. If you put stuff in PEP you can't reliably identity yourself back anyway can you.

The server is able to GC dead endpoints by sending something to them, and the push server will reply with "it's dead Jim"

>Ge0rG: What's a service worker in that context? The persistent code that runs on the client that handles the push notification from the browser vendor push service

>pep.: Dele Olajide, why PEP btw no particular reason. I used non-standard user properties in my openfire server plugin implementation

Do you have a link to your implementation btw?

Dele Olajide: then I don't understand how you don't need an app server

Ge0rG, because the client dev doesn't have to register anything

The application itself can request a slot using the Web Push API. The Push server sends back an endpoint url that it passes to the XMPP server

I did not add that openfire was sending the push notifications by making direct requests to vendor push service

https://hackmd.io/bKFV8ew8TAuIzMTnuhmFPQ?view#Enabling-Flow Please don't look at the rest, it's ready just for testing between us today, nothing might stay the same

And since when can an xmpp server talk to web endpoints?

prosody has net.http apparently, an http client

**it's really just for us testing today

So you implemented the app service inside of openfire...

yeah you can say that

The App Server just being an http client

Sorry, i keep forgetting openfire is both an xmpp server and web server 😉

That's a Mozilla-only thing?

Holger, no

https://developers.google.com/web/ilt/pwa/introduction-to-push-notifications

nope. all browser vendors

Ah, thx.

So not standardized at W3C or IETF but the major vendors agreed on a spec?

https://w3c.github.io/push-api/

Merci.

I guess major vendors agreed on a spec anyway, it was worked on by google and mozilla people :p

Of course iOS doesn't implement it, as usual

It would be too easy

Are you sure. I don't have an iphone anymore, but I though it worked with chrome on IOS

I meant on their mobile device

On safari

so now we can write clients as a PWA and forget about our own push server?

That's the idea I guess. Unless you use Apple products

But they're often problematic anyway.. who would want to use that, right?

i don't know. there are people who use that stuff, like my parents. no idea why

i mean everybody would switch to iOS if it where open source, but it isn't