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