Re: [w3c/push-api] A javascript api for sending push notifications to others (#303)

Yeah, like I said, I'm not hugely opposed to DOM level webpush subscription creation and use, and I've got a test page from the very early days of Push that basically does it. (I've also learned that one of the reasons that we have CORS enabled isn't for security, but because we were getting flooded by folks looking for security bounties because "Hey! This endpoint doesn't have CORS enabled!". Technical problems having non-techincal solutions and all...) 

All that aside: what is required to do Push is to have a ServiceWorker to handle the incoming push request (for very good security reasons) and a trusted publisher to handle the outbound requests. That trusted publisher could be a python script sharing space on your server that gets called via a simple FastCGI that limits to the local server, and gets fed the remote user's subscription info. 

You still need to have a way for the remote party to agree to get subscription updates (again, could be a simple FastCGI callback on your server that offers a PushSubscription link) and run the corresponding service worker, which means all the fun you normally have with trying to get two devices talking to each other (DNS, Firewalls, etc.). After that, you'd have two peers essentially sending push notifications to each other.

All of this seems like, frankly, a lot of work, just so that you can still rely on an outside party (in this case, Mozilla / Google / Apple / Microsoft) to enable very limited data exchange between two devices.

I'd probably just cut out the literal middleman in this case and use something like WebRTC.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/push-api/issues/303#issuecomment-1482000583
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/push-api/issues/303/1482000583@github.com>