 So, we edited the comments for our YouTube videos, all right, for this series. I mean, yeah, yeah, we do. I think I should have said moderate, shouldn't I? Yeah, we do edit them. We do go in and make them say something different. I'll try that again. Oh, well, we can agree if we can go with, like, this is the greatest show I have ever seen. These people should get a raise. That's messing it up straight away. We are building the Chrome Dev Summit website. Yes, we are. And we are looking into using push notifications, because we're trying not to be annoying about them. Yeah, this is one thing that everyone loves on the web. It's push notifications. Everyone loves it. I can't stop myself from hitting a loud one. I'm like, oh, I'm just curious. Curiosity has got the best of me. I like my lock screen is full of notifications. I don't know what your website's about, but you have asked me if I want notifications. And my answer is always yes. Of course there's a website for the front. I don't even know what for. Like, what are you doing? Who approved this? Either way, we actually think we have a legit use case, namely that... It's not everyone's side, but OK, yes, we think we do. Because this conference is something that you can not only have in person, but obviously also watch with livestream from home, which might mean that you're in a different time zone. Yes. So what we want to do is that you can say, this session is interesting to me. Let me know 10 minutes ahead of time before it's about to start. We'll be asking for permission at a good time. Once they click, like, notify me, we will say, well, then we would need your permission to notify you. And that seems like a reasonable time to ask. Yes. Right, OK, yes. So I agree. Just as a context, why did I look into web push? And I did. And I was actually kind of scared because I'd never done it. I've never used web push. And I know that back in the day, Google Cloud Messaging had like their own proprietary API and I was like a competitor and it was incompatible with anything else. And I was like, I don't want to do this. And I looked into it and it's so much better. It's actually, I would say it's enjoyable now. So is our documentation for this still written by Monty Guanty? Is that? The out-of-date documentation is written by Monty Guanty. Yes. So you should say this is someone who was on the team, like, a few years ago. And then he bailed on us. He bailed on us. But we call him Monty Guanty because... Well, I'm sorry. Monty Guanty. Monty Guanty. Hopefully we can get this footage to display now. It exists. It's from the PWAsome in Amsterdam 2016, I want to say. Something like that. And it was, so his name, Matt Guanty. But while he was talking to camera, the editor is just called to Monty Guanty. It was like, I like his surname so much. We'll put it twice. So that was it. That was his name Guanty. I think that's why you had to leave the team. Because it was just like, all right, Monty. How's it going? Yes. So he was our push person. Push person. And he left. And Monty Guanty. Things changed and we had nobody update the documentation. Good. Excellent. This is how we work. Either way, moving on. All right. Web push. Good. Let's talk about this. So it is now an open protocol standardized by the IETF. All the browsers that do implement it, implement that specific protocol. And that is pretty much every browser apart from Safari. Yes. Safari doesn't have support for web push. All right. Let's take a look at this. The first thing that you need for push notifications is to have a push handler in your service worker. Right. And this could just be to show a notification irrespective of push. But you know, you need to show notifications. So what you do is you just add an event listener for push. Excellent. And then, you know, it's usually a good idea to check if you actually ever got permission from the user. Because otherwise, the certification call will throw. So it's interesting that actually, as far as I'm aware, every browser will bundle the push notification permission and the notification permission. Push permission and notification permission become the same thing. If I asked for a subscribe later on, the user will get asked for permission. But it doesn't mean that you couldn't get a push event without the user ever having consented to notifications. Not in Chrome. Really? Yeah. When you subscribe for push, the permission you get there that says, do you want push or not, if you say allow, it will give you notification permission as well. Exactly. You can still get a push event without the user ever having been asked for permission, I think. At least if you trigger it by a DevTools, for example. Oh, maybe, but I would say otherwise. I'm pretty sure not. It's definitely not in Chrome. Definitely not in Chrome. Definitely not a bad thing to check before. Okay, yes. So your code doesn't throw because throwing is usually. It's definitely possible that other browsers may, like, diverse things. Or you can still get a push event, but the user has since then rejected your, has removed your permission to show notifications. Also, I think a thing that could be happening. I'm not too sure about that. Either way, I'm just trying to justify, just do a check. All right, that's all I'm saying. That's good. So what happens in a push event? You get an event, and then the event has a dot data. I think it works very similar to a fetch response and then you can un-martial this text, JSON, array buffer, and that's what you get. And then you can use the show notification API to actually show a notification on the system. On Android, there will be a notification notification bar on macOS windows. Next, it will be like one of these on-screen display notifications. They're there for a couple of seconds. There you go. This is pretty much notification part, notification part of web push. Yep, yep. So that's done, but let's talk about the interesting thing. And in this part, we're going to talk about cryptography. Cryptography. Actually, we're not going to talk about it because one of the golden rules I think everybody knows is don't roll your own crypto. It's all like the spec is out there and it's actually very readable. How do you need to encrypt which data to actually be compatible to the protocol? But pretty much every language has a web push library that encapsulates all of that logic. So I would recommend not doing it yourself. Use the libraries and you will actually have a very pleasant experience of just making it work. I remember the days when this was specced and there was a lot of late. So the reason that we use crypto here is it's for the body of the push message. But not only that, but also just for being allowed to push in the first place. You can actually prove the user has granted you permission. Right, interesting. There's multiple levels here. But part of the reason that it came about was the service delivering the push messages, be it Chrome or maybe eventually Apple one day or Telefonica who I think certainly used to do the stuff for Firefox. They don't want to see your messages. We don't want them to see our messages, right? Yes, we don't, and they didn't either. It was like, let's reach this mutual understanding that as we are just delivering these messages, we don't want the ability to... For them it's just binary blobs and it should stay that way. Yes, we don't want Michael to know. We don't want to know that Michael has a new baby boy or something like that. It's just not interested. We just want to marshal that data around. But yes, we knew it was going to be slightly more effort for developers. Right, but to be fair, the libraries that came out of it, at least, so I've been looking at the web push npm package which is written by one of the engineers from Mozilla and it's not only very well written as in you can actually go in and read the code and understand what's going on, but the API is super simple, so you can actually get started quite quickly. So this is on the... Oh yes, this is on the server side. It might be so that it could actually be locally doing development. You just generate, you need a private key and a public key. Right. And so there is a function called this whole process called VAPIT. That's the name for the algorithm, I guess. It's voluntary, something, something, I don't remember, it doesn't even matter that much. But basically you need this private key and the public key. The private key is obviously private, so keep it safe. The public key, you can publicize, put it in your front end anywhere, but you will need the private key on your server side later, so make sure you get it there because that's what you need to sign with to actually be able to push the message to the provider. Right, but the public key will go to the client to do the decoding. Yes. Right, I see, I see. So yeah, this is basically the first call, just import the web push library and to generate your Keeper, and that's the first step done. So once you have those in place, we are now on the client side. So in there, I need to somehow get my public key. So you could bundle it with your web app via webpack or roll up, you could fetch it from your server as a resource. It doesn't really matter, you just need to get it in the public so you can just put it on the Internet and nobody cares. The public key is unique to your site, not per user. No, it's unique to a site. Yeah, right, I see it. I mean, technically you can even have multiple, but it doesn't quite make sense. But it's up to you. You can generate those. It's free. Okay. So yeah, once I have the public key, I will then wait for my service worker to be ready, available, and running because that is the one that takes care of anything that has to do with web push. And then I can use the push manager property on the service worker to ask for a subscription. And instead of asking the user to subscribe, basically implies the permission for notifications. So this will pop up the permission dialogue and wait for the response. And actually, user visible only has to be true. Currently on the web, we don't allow push notifications that don't trigger a visual notifications. Yes. So maybe at some point in the future, that would be possible to do like a background sync kind of thing. Don't know yet for now, only with a permission. Yeah. Well, one of the things that we would like to do with like user visible kinder. Well, so here's the situation. So I deliver a push message to your phone to say, you know, there's a new chat message. Yeah. But I know that you, by, you know, user ID, have just checked that message on your desktop machine. Right. The ideal thing would be then to hide the push message on your mobile. But then that is no longer a user visible thing because they, you know, if you granted the ability to do that, then you've granted the ability to do invisible push work because you would just show notification, hide notification, job done, who cares. Yeah. So, yeah, that's one of the things where there's a really good use case there for it. And the reason we don't just want to allow notifications without any visual effect is what? Well, it would give you the ability to just send a push message every 10 seconds, track the user through the different, you know, IP. Right. You're running a service work in the background. Why not do some Bitcoin mining? privacy, battery, exploitation, all kinds of things. All the bad, all the bad things. Yeah. As always, we're past to think about these things. Yes. So, yeah, basically a pattern is like, okay, I'm gonna promise I'm always gonna show notification. And if you don't, Chrome will show one for you. So it's not like you can get around it. And we provide our public key. So that way we can use our private key to sign things and the clients I can check it actually came from us. And this is how it's also going to decode the body. Yeah. Right, right, right. Gotcha. So, if you're a Mac, once the user actually presses allow, you can show me a notification or you can send me the push notifications. You will get a subscription. And I find this interesting because it's actually very little data in there. There is the endpoint that the server site later on will use to send push notifications out. And so in Chrome, it will be firebasecloudmessaging.googleapi.com. In Mozilla, it will be a Mozilla server. I'm pretty sure GIM is going to use a Microsoft server. I'm not sure about that. Safari, as you said, doesn't have it yet. There's an expiration time and there's the keys which are for the Diffie helmet and handshake, but that doesn't really matter right now. But basically, there's no other personal data in here. Like it's not like there's a lot of leakage happening about what the user is doing or what they're subscribing to. It's literally just the cryptographic keys that are needed to make this whole thing happen securely on like a zero-knowledge kind of approach. OK. So we get this back and now what we do, as I said, we need to send this to our server site. So one way to do this would be a fetch and we just post it to my serverless function, whatever you're running. You need to store that this subscription thing as a Stringify JSON blob on the server site because you need it to actually send the notification later on. And this is going to be unique to that user. So this is something that's very unique to that user. It's for every user who will get a different kind of subscription blob that you need. Right. So now on the server site, we are now at the point where maybe at some point in the future we want to send a push notification. Right. So we know we have our keys on the server site. We know we have subscriptions for a user on the server site. So we basically need to find all the users that we want to send something to, loop over them, and now do something. And again, web push, the library makes it quite easy because we get our keys, we get our subscription for that particular user. Yep. We set our vapid details, which is the public and the private key. They also demand a contact email or multiple contact emails in case something goes wrong, you just want to have a point of contact to send in lots of. And then you just send a notification. So basically we turn the push subscription back into a JSON blob, put our body there. It can be string. It can be another stringified JSON object, whatever that will take care of the inscription and hit that endpoint from the subscription and send it to the user. And that's it. And that's it. That's all. That's how you do push notifications. That was quite amazing because I literally just ran through this library, put it out, and it worked on the first try. And that never happens. So this is the thing, because I know bits about the service worker side of push because we were doing spec worker at a time, but I've never done the service side of it because it involves keys. It's probably going to be hardened. I'm not going to touch that until I really need to. It's all right. Pretty approachable, isn't it? So yeah, we now have this on a branch in our Chrome desktop side. We still have some tuning, some edge cases and stuff to work out and help allow people to unsubscribe if they don't want notifications anymore because they want to be nice about this. But other than that, I got it up and running. We look forward to spamming everyone with pointless stuff. Subscribe to this YouTube channel. We moderate the comments for our YouTube stuff. Yes. Right? A couple of episodes ago, there was a guy posted a comment and he was saying, I think you could have edited out the disgusting flatulence noise at one. Do you see this comment go past? I didn't see the comment. Did you go and listen to the actual time stamp it was? I think it was me going, well, I thought it was me, but it was one of us doing that. It was just because I said, you know, have a look at that. And that guy posted 15 comments. Really? It was 15 of just variations on that theme. He was so angry about that. But is that what his flatulence sounds like? Yes. It's you gasping.