WEBVTT 00:30.000 --> 00:37.000 You probably remember the flooding in our Lensier last year. 00:37.000 --> 00:41.000 You probably remember the flooding in Valencia last year. 00:41.000 --> 00:44.000 Similar thing happened in Germany a few years back, 00:44.000 --> 00:48.000 where it looks like better alerting might have 00:48.000 --> 00:51.000 reduced the number of casualties there. 00:51.000 --> 00:56.000 And at the same time, mobile phones 00:56.000 --> 01:00.000 have become the most important alert distribution channel, 01:00.000 --> 01:03.000 like that used to be silence or media broadcast, 01:03.000 --> 01:05.000 now it's the fault. 01:05.000 --> 01:09.000 So for the, especially for the free platforms, 01:09.000 --> 01:12.000 we now of course have to look at our users there, 01:12.000 --> 01:14.000 sufficiently covered as well with, 01:14.000 --> 01:16.000 which we got to alerting. 01:16.000 --> 01:19.000 The first thing that comes to mind 01:19.000 --> 01:23.000 in that context is a said broadcast. 01:24.000 --> 01:27.000 There is ongoing work to bring that to Linux as well, 01:27.000 --> 01:31.000 but that's what we are going to talk about here. 01:31.000 --> 01:35.000 I mean, said broadcast is very useful and very important, 01:35.000 --> 01:37.000 but it does have some limitations. 01:37.000 --> 01:42.000 For example, it only supports a very small text only payload. 01:42.000 --> 01:45.000 So if you, for example, want to show a map of the affected area, 01:45.000 --> 01:49.000 that's problem or if you want to have messages in multiple languages, 01:49.000 --> 01:51.000 that's also a problem. 01:52.000 --> 01:57.000 And then it's, it's push only broadcast approach means that, 01:57.000 --> 01:59.000 if you missed the alert for some reason, 01:59.000 --> 02:01.000 you have no way to get it back, right? 02:01.000 --> 02:04.000 So if you enter the affected area after the fact, 02:04.000 --> 02:07.000 you will know that there's a problem. 02:07.000 --> 02:13.000 So there is a few other things that augment cell broadcast. 02:13.000 --> 02:19.000 One such approach are regional or national warning apps. 02:20.000 --> 02:22.000 Since you have a dedicated app for that, 02:22.000 --> 02:26.000 you have a lot more flexibility in how you present information. 02:26.000 --> 02:31.000 So a map or items or multiple languages, all of that is not a problem. 02:31.000 --> 02:37.000 Those, however, are usually limited to the proprietary platforms only, 02:37.000 --> 02:41.000 very often also close source. 02:41.000 --> 02:45.000 And very often that is due to the use of the proprietary 02:45.000 --> 02:47.000 push notification infrastructure. 02:47.000 --> 02:51.000 So even if you get the ATK on the Google free Android, 02:51.000 --> 02:54.000 it's not going to work. 02:54.000 --> 02:56.000 And the other limitation there, of course, 02:56.000 --> 02:59.000 is those 10 to the first, for just one country. 02:59.000 --> 03:02.000 And I mean, how many of you, not from Belgium, 03:02.000 --> 03:05.000 check before coming here if there is such a net for Belgium and then 03:05.000 --> 03:09.000 scroll that, it's hardly anybody does that. 03:09.000 --> 03:13.000 Another thing in that area is what Google does. 03:14.000 --> 03:17.000 I think they cover about 40 countries. 03:17.000 --> 03:22.000 And they integrate a lot of information in various of their products. 03:22.000 --> 03:27.000 So you see that on the map or you have it in routing before entering 03:27.000 --> 03:31.000 an affected area, for example. 03:31.000 --> 03:36.000 So functionality wise, we basically want all of the above, 03:36.000 --> 03:40.000 but without the proprietary stuff, without Google, 03:40.000 --> 03:44.000 and without the limitation to any borders. 03:44.000 --> 03:46.000 And I mean, you know how this goes, right? 03:46.000 --> 03:50.000 If you want to have nice things, we have to build that ourselves. 03:50.000 --> 03:54.000 So how are we going to do that? 03:54.000 --> 04:01.000 The first thing we need is some kind of universal data model, 04:01.000 --> 04:07.000 something that we can use to work all over the world. 04:07.000 --> 04:11.000 And fortunately, there is something like that already in form 04:11.000 --> 04:14.000 of the common alerting protocol cap. 04:14.000 --> 04:18.000 That is a 20 year old or a standard, 04:18.000 --> 04:23.000 which defines an XML format to describe an alert. 04:23.000 --> 04:29.000 So in there, we have things like a human readable description of what happened 04:29.000 --> 04:33.000 and what I should do in response. 04:33.000 --> 04:37.000 There is a description of the affected area, 04:37.000 --> 04:40.000 both in human readable and in machine readable. 04:40.000 --> 04:43.000 So basically geographic geometry. 04:43.000 --> 04:47.000 Something very important for what we want to do. 04:47.000 --> 04:50.000 Then there are some structured data in there, 04:50.000 --> 04:57.000 which is useful for filtering or to know how aggressive we should alert the user. 04:57.000 --> 05:02.000 So in there, we have things like the category of events, 05:02.000 --> 05:09.000 whether related or whether it's a file or whatever. 05:13.000 --> 05:17.000 Then the severity, so is there, 05:17.000 --> 05:22.000 are we talking about something life-splitening or just minor property damage, 05:22.000 --> 05:26.000 the urgency, so is there the need for immediate action or is to something 05:26.000 --> 05:30.000 I should eventually prepare for and the certainty, 05:30.000 --> 05:34.000 so is there something that has already happened or something that might happen in the future 05:34.000 --> 05:37.000 and a few more things like that. 05:37.000 --> 05:41.000 And then also very important there is built in support for multiple languages. 05:41.000 --> 05:48.000 I mean here in a multilingual country, that is very much necessary. 05:48.000 --> 05:54.000 But even beyond that, I get the alert and don't understand what it flies to tell me. 05:54.000 --> 05:59.000 I don't gain all that much. 05:59.000 --> 06:07.000 Cap is widely used all over the world to usually connect a lotting authorities to alert distribution. 06:07.000 --> 06:17.000 So this is what goes to network operators to send out cell broadcasts or to media broadcasts or cybernsystems and whatnot. 06:17.000 --> 06:21.000 And even in the places where the format as such isn't used, 06:21.000 --> 06:25.000 usually at least the data model of Cap is used. 06:25.000 --> 06:30.000 I don't think we have encountered anything that significantly deviates from that, 06:30.000 --> 06:36.000 which is perfect right so then we can use that as a globally working data model. 06:36.000 --> 06:43.000 The next thing we need is actually get the alert data. 06:43.000 --> 06:54.000 Fortunately there is also already existing standards for that, so called Cap Feeds. 06:54.000 --> 07:01.000 That is essentially as SOR atom, like you know it from news readers, just containing cap messages. 07:01.000 --> 07:06.000 So that's something you'll probably want to minute and check if something has changed. 07:06.000 --> 07:12.000 There's also created lists with Cap Feeds from all over the world, 07:12.000 --> 07:19.000 from organizations like the International Red Cross or the UN Red organization. 07:20.000 --> 07:24.000 And alert app that is the most unissuming looking one of those, 07:24.000 --> 07:29.000 but that's actually the people driving the whole cap community. 07:29.000 --> 07:37.000 If we combine all of that we get about 200 feeds from about 100 countries, 07:37.000 --> 07:42.000 so that isn't perfect worldwide coverage just yet, 07:42.000 --> 07:47.000 but that is a very solid foundation to build on. 07:48.000 --> 07:51.000 There is a lot of work left in the defense there, 07:51.000 --> 07:57.000 but I think that would fill an entire talk on its own. 07:57.000 --> 08:04.000 So we continue here with what we actually have built. 08:05.000 --> 08:18.000 Okay, yeah. Next we have to build the actual server to subscribe to an area. 08:18.000 --> 08:25.000 We decided to use jungle for this and post-cus as database and cellular task schedule. 08:25.000 --> 08:31.000 It's a quite robust system, so every feed gets its own task. 08:31.000 --> 08:35.000 We can paralyze these tasks and the front feed is broken. 08:35.000 --> 08:39.000 Other feeds are not affected. 08:39.000 --> 08:44.000 And yes, the next thing we have to do is to resolve the geocodes into polygon. 08:44.000 --> 08:49.000 Some cap feeds use geocodes instead of polygones. 08:49.000 --> 08:56.000 And for us to actually work with these alerts, we have to resolve them because 08:56.000 --> 08:59.000 we use a cancer structure for an area. 08:59.000 --> 09:03.000 And if we don't know the area of an alert, we cannot distribute the alert. 09:03.000 --> 09:05.000 This task can be challenging. 09:05.000 --> 09:10.000 For some geocodes, we already found the right data to do that. 09:10.000 --> 09:13.000 For example, we could extract data from open speedmap. 09:13.000 --> 09:16.000 But for other geocodes, we still searching for the right data. 09:16.000 --> 09:20.000 That's an open task, so to say. 09:20.000 --> 09:27.000 The next thing is some basic endpoints to the subscription. 09:27.000 --> 09:30.000 We move our subscription. 09:30.000 --> 09:36.000 And of course, send the actual push notification in case there is any alert. 09:36.000 --> 09:44.000 Additional, we build some monitoring tools to evaluate the feed quality. 09:44.000 --> 09:45.000 Yes. 09:45.000 --> 09:50.000 So the next thing is to build actual clients. 09:50.000 --> 09:57.000 We currently have one client that is in an early beta phase. 09:57.000 --> 09:58.000 It's called FOS1. 09:58.000 --> 10:01.000 I don't know if someone knows it. 10:01.000 --> 10:04.000 It's previously for Germany only. 10:04.000 --> 10:08.000 But I'm integrating currently the first public alert server. 10:08.000 --> 10:13.000 So it will work for the world. 10:13.000 --> 10:17.000 We will use a unified push for push notification. 10:17.000 --> 10:24.000 And if you want to try that out, there is a release on GitHub. 10:24.000 --> 10:28.000 But it's not ready for production yet, so be careful. 10:28.000 --> 10:34.000 But there's another client for Linux in the making from Volker. 10:34.000 --> 10:39.000 But I'm not sure how far this is already this thing is. 10:40.000 --> 10:43.000 It starts to do something on the train here. 10:43.000 --> 10:45.000 Okay, that's good. 10:45.000 --> 10:48.000 Yeah, for FOS1, it's currently entered only. 10:48.000 --> 10:51.000 But we are working on Linux support. 10:51.000 --> 10:54.000 So it's flutter, so it's open, it's cross platform. 10:54.000 --> 11:01.000 And hopefully we have a Linux support soon. 11:01.000 --> 11:05.000 Yeah, here are some screenshots about from the app. 11:05.000 --> 11:07.000 So it's nothing special. 11:07.000 --> 11:12.000 We have a view to subscribe from the area and select the radios. 11:12.000 --> 11:19.000 You can over view and you can, of course, read the actual alerts. 11:19.000 --> 11:24.000 So yeah, we have two last steps on our to-do list. 11:24.000 --> 11:27.000 So the first one is to tell everyone about your project. 11:27.000 --> 11:31.000 We actually did it with this talk, so I guess we can like this as done. 11:31.000 --> 11:39.000 The last step is to look for contributors and to give you a trick outline of the next steps. 11:39.000 --> 11:47.000 So hopefully we will have a first stable release in the next month of FOS1 and the first public alert server. 11:47.000 --> 11:51.000 After that, we want to also build more clients. 11:51.000 --> 11:55.000 For example, for smart home systems, that would be really cool. 11:55.000 --> 12:02.000 So a MQTT client, so that you could integrate it in your smart home system. 12:02.000 --> 12:08.000 Also, the Linux application and also some integrations into, for example, open street map. 12:08.000 --> 12:15.000 It would be really cool so that you can have routing and get alerts. 12:15.000 --> 12:20.000 If there's an alert on your route somewhere. 12:20.000 --> 12:29.000 Also, yeah, some other cool features we want to build is, for example, automatic registration of train travel routes. 12:29.000 --> 12:33.000 Just actually the starting point of focus travel there. 12:33.000 --> 12:41.000 And of course, a CVS like subscription for the current location based on GPS or cell towers. 12:41.000 --> 12:44.000 Yeah, how can you help us? 12:44.000 --> 12:48.000 Of course, you can help us to build more clients from our platforms. 12:48.000 --> 12:50.000 You can help us test the software. 12:50.000 --> 12:54.000 You can help us translate, if you want, on what we have played. 12:54.000 --> 12:57.000 You can give us feedback, we have a metrics space. 12:57.000 --> 13:00.000 You can join there and write us. 13:00.000 --> 13:04.000 Also, if you have contact to your local alerting infrastructure. 13:04.000 --> 13:06.000 You can talk to us. 13:06.000 --> 13:08.000 We are really interested in that. 13:08.000 --> 13:11.000 We have a bit insight into the German infrastructure. 13:11.000 --> 13:16.000 But we actually don't know much about, for example, the Beijing structure. 13:16.000 --> 13:21.000 So please get in touch with us if you can help us there. 13:21.000 --> 13:27.000 Also, if you have knowledge there, you can check if your country is supported by us. 13:27.000 --> 13:34.000 There's a list, you can click on the PDF in the link and check the list. 13:34.000 --> 13:40.000 And if you find a few myths, if you miss the cap feed that you would like to add, 13:40.000 --> 13:43.000 you can talk to us or open a pull request. 13:43.000 --> 13:47.000 And of course, you can tell your friends about your project. 13:47.000 --> 13:50.000 And yes. 13:50.000 --> 13:53.000 Yeah, it's all from us. 13:53.000 --> 13:56.000 I used to source code and contact information. 13:56.000 --> 13:58.000 Can follow us and must add on. 13:58.000 --> 14:04.000 And yeah, thank you for your attention and your here for our questions. 14:05.000 --> 14:10.000 Thank you. 14:10.000 --> 14:39.000 Okay, so the question is, what a client for this sort of look like? 14:39.000 --> 14:41.000 What would do? 14:41.000 --> 14:49.000 Basically, what the server side provides is a very simple API that allows you to create what is currently. 14:49.000 --> 14:51.000 What are the known alerts in the given area? 14:51.000 --> 14:57.000 And you can subscribe to push notifications for alerts in a specific area. 14:57.000 --> 15:02.000 So a client would need to know which area is of interest to you. 15:02.000 --> 15:08.000 Could be your current location, could be a specifically selected location where there's people you care about. 15:08.000 --> 15:10.000 So whatever, right? 15:10.000 --> 15:12.000 And then you subscribe for that area. 15:12.000 --> 15:18.000 And when there is a notification that something happens there, the client decides how to show this, right? 15:18.000 --> 15:23.000 So in case of the app, it's a notification and then showing you the details. 15:23.000 --> 15:29.000 In case of the smart home integration that could be flashing your lights or basically whatever you want to do. 15:29.000 --> 15:32.000 What the server provides is the information. 15:32.000 --> 15:36.000 Both are the alerts in a specific area, basically. 15:36.000 --> 15:42.000 Yeah, notification about that. 15:48.000 --> 15:54.000 So the client should be not only in German, so it's localized into multiple languages. 15:54.000 --> 15:59.000 So maybe on an effort, it's not quickly displayed and not sure. 15:59.000 --> 16:03.000 But it should be on English too. 16:03.000 --> 16:06.000 We can talk to later. 16:24.000 --> 16:37.000 So the question was what kind of delay we have until the official alert from the publisher reaches the device. 16:37.000 --> 16:42.000 And we cannot surely answer the question yet. 16:42.000 --> 16:44.000 We haven't measured it. 16:44.000 --> 16:52.000 But we currently pull every cap feed every one minute. 16:52.000 --> 16:57.000 But we could actually do that often after. 16:57.000 --> 16:59.000 So to reduce the delay. 16:59.000 --> 17:02.000 But it's about one minute, I guess. 17:05.000 --> 17:14.000 During the national alert testing day last year in Germany, I think we were within 90 seconds from the cell broadcast. 17:14.000 --> 17:18.000 To notification actually shows up on. 17:18.000 --> 17:24.000 That was the little client, but I guess the, the more we're trying for the same. 17:24.000 --> 17:30.000 One minute doesn't sound too bad, but I mean that the institution should be interested again. 17:30.000 --> 17:32.000 The alert is pretty quick. 17:32.000 --> 17:36.000 Is there any kind of talks to go to some push service? 17:36.000 --> 17:40.000 That the official situation is pushed towards your server. 17:40.000 --> 17:44.000 Are they just breaking that process? 17:44.000 --> 17:52.000 So the question is if there is something like the push API from the alert authority towards 17:52.000 --> 17:55.000 Accuration Services like this. 17:55.000 --> 17:58.000 There is to my knowledge, no standard for this. 17:58.000 --> 18:05.000 We have been in this question with some of the people doing this in Germany, which suggests that there is something like. 18:05.000 --> 18:08.000 This is not publicly available. 18:08.000 --> 18:15.000 We are of course interested in integrating this if we get access to that. 18:15.000 --> 18:19.000 In terms of the 90 seconds. 18:19.000 --> 18:25.000 There is a few use cases where we will never be fast enough, like earthquake warnings. 18:25.000 --> 18:31.000 They actually, there is some battle within 10 seconds. 18:31.000 --> 18:35.000 You need it if people should still have time to get themselves to safety. 18:35.000 --> 18:39.000 That isn't going to work with any of the mobile stuff, right? 18:39.000 --> 18:44.000 For things like within the next hour there will be a flood. 18:44.000 --> 18:47.000 The one minute is probably okay, right? 18:47.000 --> 18:57.000 But yeah, one needs to be realistic on what we can deliver and whatnot. 18:57.000 --> 19:01.000 Question from the internet is the API endpoint. 19:01.000 --> 19:06.000 Can we integrate the service into more maps? 19:06.000 --> 19:12.000 So the question is, is there an API endpoint and can this be integrated in GNOMEB? 19:12.000 --> 19:14.000 Yes, that is the whole point of this. 19:14.000 --> 19:16.000 What we built is the server side. 19:16.000 --> 19:19.000 It's running on Alerts KVORK. 19:19.000 --> 19:24.000 There is API documentation. Open API documentation there. 19:24.000 --> 19:31.000 So you can both either use that or run your instance of the server. 19:31.000 --> 19:38.000 And there is like it's a handful of rest API endpoints that allow that kind of integration. 19:38.000 --> 19:45.000 For the map scenario, we might need additional API to make that more efficient. 19:45.000 --> 19:48.000 If you look at larger scale, right? 19:48.000 --> 19:53.000 For the entire world, it might not scale, but that's a separate discussion. 19:53.000 --> 20:03.000 But the whole point is to provide the infrastructure so people can integrate that as many places as it makes sense. 20:03.000 --> 20:13.000 Okay, I think the time is up anyway.